Hi Toerless, Thanks for the updates and explanation! It does seem like further experimentation for CC for PIM is warranted, but I understand that doesn’t necessarily fit within the scope of this document. Best, Tommy > On Mar 8, 2023, at 6:04 PM, Toerless Eckert <tte@xxxxxxxxx> wrote: > > Thanks again Tommy > > All textual fixes for your review are integrated into revision -09. > > I did not add more text to explain your transport related questions as > i felt that it is basic PIM assert understanding that readers who want to > use/implement PIM (with or without assert packing) should have > Hence only the prior explanation email to you, which i summarized in > changelog for benefit of possible later reviewers too. > > Cheers > Toerless > >> On Sun, Feb 26, 2023 at 11:41:50AM -0800, Tommy Pauly via Datatracker wrote: >> Reviewer: Tommy Pauly >> Review result: Ready with Nits >> This document has been reviewed as part of the transport area review team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the document's >> authors and WG to allow them to address any issues raised and also to the IETF >> discussion list for information. >> When done at the time of IETF Last Call, the authors should consider this >> review as part of the last-call comments they receive. Please always CC >> tsv-art@xxxxxxxx if you reply to or forward this review. >> Thanks to the authors for this clear and useful document. Reducing the overhead >> of redundant multicast packets is a good improvement! >> The main transport-related comment I have is for section 3.3.1: >> “ Routers MAY support a configurable option for sending PackedAssert messages >> twice in short order (such as 50msec apart), to overcome possible loss, but >> only when the following two conditions are met.” >> How will an end point decide to retransmit like that or not? How is loss >> detected? >> I did find several nits: >> “RP” is mentioned in the introduction before it is defined. It would be useful >> to expand this here. It would also be good to expand “AT” on first use. >> Section 3.2 seems to have a formatting issue, with “ If the P)acked flag is 0”. >> Do you mean “ If the (P) flag is 0”? This section also says “If the (P) flag is >> 2”; how can a 1-bit flag have a value of 2? >> In section 3.3, “Only the compactness of their encoding” is a sentence >> fragment, not a complete sentence. >> In section 3.3.1, this normative requirement is confusingly worded: “ >> Implementation SHOULD NOT send only Asserts, but no PackedAsserts under all >> conditions, when all routers on the LAN do support Assert Packing.” Can you >> rephrase? >> In the same section, please add a reference when discussing DSCP markings. >> In section 4: In the packed form, are the version/flags fields repeated? Do we >> need to mandate normatively that the packed flags are not nested? It’s implied >> but not normatively said. >> In section 4.4.1, the field description order doesn’t seem to match the >> structure values in the diagram. > > -- > --- > tte@xxxxxxxxx > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
