| Pete, thanks for your review. Carles, thanks for making the updates. I entered a No Objection ballot.
Alissa
Hi Pete,Thanks a lot for your review of the draft!We just submitted -09, which aims at addressing the last round of reviewcomments, including yours:https://tools.ietf.org/html/draft-ietf-6lo-blemesh-09https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-blemesh-09Please 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 listGen-art@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/gen-art
|
