Subject: [Last-Call] Genart last call review of draft-ietf-6lo-blemesh-08

From: Pete Resnick via Datatracker <[email-masked]>
Date: Fri, 04 Dec 2020 13:05:51 -0800

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.

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.

Nits/editorial comments: Do fix the reference nits noted by the nits tool; they
appear to be simple typos.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 8 Dec 2020 09:37:10 +0100

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

> and complete the review anyway.

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.

> inline." Similarly for the second. As it is, it takes a while to figure

We modified the two paragraphs as per your suggestion.

> appear to be simple typos.

Done!

Cheers,

Carles (on behalf of the authors)