Pete, thanks for your review. Carles, thanks for making the updates. I entered a No Objection ballot.
Alissa > On Dec 8, 2020, at 3:37 AM, Carles Gomez Montenegro <carle...@entel.upc.edu> > wrote: > > Hi Pete, > > Thanks a lot for your review of the draft! > > We just submitted -09, which aims at addressing the last round of review > comments, including yours: > https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09 > <https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09> > https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09> > > Please find below our inline responses to your comments: > >> Reviewer: Pete Resnick >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: draft-ietf-6lo-blemesh-08 >> Reviewer: Pete Resnick >> Review Date: 2020-12-04 >> IETF LC End Date: 2020-10-21 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: Looks good to me, with two items that seemed confusing enough >> that >> they should be addressed. >> >> Note that this review is being done well after the close of the Last Call. >> Since this is not yet scheduled for a telechat, the AD asked that I go >> ahead >> and complete the review anyway. >> >> Major issues: None >> >> Minor issues: >> >> 3.3.2, #4: >> >> Implementations of this specification MAY support >> the features described in sections 8.1 and 8.2 of RFC 6775, as >> updated by RFC 8505, unless some alternative ("substitute") from some >> other specification is supported by the implementation. >> >> This bit confused me. I think it was the "unless". Do you mean it MAY >> support >> the 6775/8505 features, or MAY support some substitute, or MAY support >> neither, >> or do you mean that it MUST support either the 6775/8505 features or MUST >> support some substitute? I think you want to rewrite this to make it clear >> which one you mean. > > Agreed. We modified the text as follows: > > NEW: > Implementations of this specification MUST either > support the features described in sections 8.1 and 8.2 of RFC 6775, > as updated by RFC 8505, or some alternative ("substitute") mechanism. > >> 3.3.3, last two paragraphs: >> >> When a 6LN transmits a packet, with a non-link-local source address >> that the 6LN has registered with EARO in the next-hop router for the >> indicated prefix, the source address MUST be fully elided if it is >> the latest address that the 6LN has registered for the indicated >> prefix (SAC=1, SAM=11). If the source non-link-local address is not >> the latest registered by the 6LN, then the 64 bits of the IID SHALL >> be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of >> the IID match with the latest address registered by the 6LN, then the >> last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10). >> >> When a router transmits a packet to a neighboring 6LN, with a non- >> link-local destination address, the router MUST fully elide the >> destination IPv6 address if the destination address is the latest >> registered by the 6LN with EARO for the indicated context (DAC=1, >> DAM=11). If the destination address is a non-link-local address and >> not the latest registered, then the 6LN MUST either include the IID >> part fully in-line (DAM=01) or, if the first 48 bits of the IID match >> to the latest registered address, then elide those 48 bits (DAM=10). >> >> Both of these were a bit confusing to me. I think you want to reverse the >> order >> of the last two choices. Say something like (for the first paragraph), "If >> the >> source non-link-local address is not the latest registered by the 6LN and >> the >> first 48 bits match..., then the last 16 bits SHALL be carried in-line. >> Otherwise, if first 48 bits do not match, then the 64 bits shall be >> carried >> inline." Similarly for the second. As it is, it takes a while to figure >> out >> what it means. > > We modified the two paragraphs as per your suggestion. > >> Nits/editorial comments: Do fix the reference nits noted by the nits tool; >> they >> appear to be simple typos. > > Done! > > Cheers, > > Carles (on behalf of the authors) > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
