[Roll] Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-roll-unaware-leaves-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. While the authors spent a lot of
time in detailed explanations, I found this document hard to read, perhaps some
additional diagrams may have helped (like those in section 9).

Big thanks to Peter Van der Stock for his Last Call review at:
https://datatracker.ietf.org/doc/review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08/
Peter completed his review at the same time as -23 was published, so, authors,
please have a look.

I appreciate that the shepherd and RTG AD have contacted the 6LO WG for review
(even if no comments were received).

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Be aware of a down-ref: Normative reference to an Informational RFC: RFC 7102

-- Abstract --
Suggest to expand some acronyms in the abstract: RPL, ND. In the same vein,
writing that RFC 6550 is RPL could help the reading of the abstract.

-- Section 1 --
s\whereas others will only terminate packets\whereas others will only
receive/originate packets\ ?

-- Section 3 --
"packets going down" could probably be rewritten in a more formal way.

The use of "Source Routing Header (SRH)" is commonly linked to RFC 8754 Segment
Routing Header... May I suggest to use 'RH' (as the "source" is always implicit
in RH).

-- Section 6 --
Does the "reserved" word have any value in "encodes it in one of these reserved
flags of the RPL DODAG" ? With the publication of this document, it is no more
reserved IMHO.

-- Section 6.1 --
Should the normative uppercase language be used ? E.g., "length of the Target
Prefix field is 128 bits regardless of the value" is not really normative...

I also wonder in which case the ROVR length cannot be derived from the Option
Length and the Prefix Length (the HbH option length is expressed in octets per
RFC 8200). Wasting valuable flags space for a length seems a bold decision to
me. The text describing the option is convoluted so I am not sure about my
point else I would have balloted a DISCUSS.

-- Section 6.3 --
While I appreciate that there are severe constraints and while I admire the
authors' imagination, the mix of status codes looks like a chimera to me.
Nothing blocking, just a comment of mine, no need to reply.

-- Section 9.1 --
Is there a reason why "Extended DAR" and "EDAR" coexist in figure 6 ?

Not the first time that "aligned" is used, e.g., in "This flow requires that
the lifetimes and sequence counters in 6LoWPAN ND and RPL are aligned." but is
this term well defined and well accepted?

What is the meaning of "negative" in "an NA message with a negative status " ?
Most significant bit to 1 ?

-- Section 11 --
Should a rate limit of EDAR/DAO message by the 6LR be recommended ? RFC 4941
could be our enemy here...

== NITS ==

Unsure whether capitalized "Host" and "Router" and "Leaf" are required.

The companion document uses "IPv6-in-IPv6" rather than "IP-in-IP"

-- Section 5.3 --
Please expand HbH in the section title.

-- Section 5.4 --
Suggest to drop " and the packet is dropped otherwise."