Last Call Review of draft-ietf-6lo-blemesh-08

Request Review of draft-ietf-6lo-blemesh
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-10-21
Requested 2020-10-07
Authors Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk
Draft last updated 2020-12-04
Completed reviews Rtgdir Last Call review of -08 by Acee Lindem (diff)
Secdir Last Call review of -08 by Catherine Meadows (diff)
Genart Last Call review of -08 by Pete Resnick (diff)
Iotdir Last Call review of -08 by Dominique Barthel (diff)
Assignment Reviewer Pete Resnick 
State Completed
Review review-ietf-6lo-blemesh-08-genart-lc-resnick-2020-12-04
Posted at
Reviewed rev. 08 (document currently at 09)
Review result Ready with Issues
Review completed: 2020-12-04


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


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.