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://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) -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
