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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 15 Dec 2020 08:08:07 -0800

É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."

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Dec 2020 18:23:41 +0000

Hello Eric

Many thanks for your review! Always appreciated as you well know.

I pushed the result here: https://github.com/roll-wg/roll-unaware-leaves/commit/b5cc06f224389d1a436dbb4468cb7f07a6307b17

You'll find the diffs combined with Elwyn's review here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-25

Please see below for the details:

> 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).

Added this in the intro, sorry if it does not show well in email with your default font

         ------+---------
               |          Internet
               |
            +-----+
            |     | <------------- 6LBR / RPL Root
            +-----+                     ^
               |                        |
         o    o   o  o                  | RPL
     o o   o  o   o  o     o    o       |
    o  o o  o o    o   o  o   o  o      |  +
    o   o      o     o   o   o    o     |
   o  o   o  o   o  o    o    o  o      | 6LoWPAN ND
      o  o  o  o        o   o           |
     o       o            o    o        v
   o      o     o <------------- 6LR / RPL Border Router
                                        ^
                                        | 6LoWPAN ND only
                                        v
                u <------------- 6LN / RPL-Unaware Leaf

> 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).
> 

Yes, Elwyn also mentioned it. There's an action in Alvaro's side to allow the DOWNREF exception

> writing that RFC 6550 is RPL could help the reading of the abstract.

RPL is awful to spell spell out. I changed the abstract to
"
   This specification updates RFC6550, RFC6775, and RFC8505, to provide
   routing services to IPv6 Nodes that implement RFC6775, RFC8505, and
   their extensions therein, but do not support RFC6550.
"

> receive/originate packets\ ?

Done

> "packets going down" could probably be rewritten in a more formal way.

Actually that's a RPL term defined in RFC 6550.
Changed the terminology section to 
"
   "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
   a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
   Protocol for Low-Power and Lossy Networks" [RFC6550].
"

> 
> 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).

Yes, it's a sad collision, but it's quite late. We also use the acronym in the RPL space. 
See RFC 6554 and RFC 8138. We should ask for Royalties ; )
I hope that with the context people will expect we're not using a SR RH here.

> 
> -- 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.

The sentence was weird; I changed to 
"
   This specification defines a new flag, "Root Proxies EDAR/EDAC" (P), in the
   RPL DODAG Configuration option ..
"

> Prefix field is 128 bits regardless of the value" is not really normative...
True, changed to:
"
   This specification defines the new 'F' flag. When it is set to 1, the size of
   the Target Prefix field MUST be 128 bits and it MUST contain an IPv6 address
   of the advertising node taken from the advertised Prefix. In that case, the
   Target Prefix field carries two distinct pieces of information: a route that
   can be a Host route or a Prefix route depending on the Prefix Length, and an
   IPv6 address that can be used to reach the advertising node and validate the
   route.
"

> 
> 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.

The problem is in the future, when we want to extend the option with yet another field. 
If we did not indicate the size of the ROVR, then where does it end and the new field start?
We faced that issue in the EDAR message, had to steal even more expensive bits. See https://tools.ietf.org/html/rfc8505#section-4.2

> Nothing blocking, just a comment of mine, no need to reply.

It's really transporting the ND status in RPL so it can be fed back in ND.
My original intent was that RPL would be ND for NBMA, when broadcast  emulation like MARS is too expensive.

> Is there a reason why "Extended DAR" and "EDAR" coexist in figure 6 ?

Because there was room : ) I did not expect a confusion. Changed all to the short form.

> 
> 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

Argl. No idea. I hope I'll get a recommendation from a native speaker. Elwyn made great comments and did not object here.

> Most significant bit to 1 ?

Argl. In RFC6550 you're actually correct but here it's ND and arguably it was not defined that way and I'd rather not do it now. Changed to "non-zero status". Which are strictly positive values but indicate failures which is a negative outcome. Also changed one occurrence of "positive status" to "status indicating success"
> 
> -- Section 11 --
> Should a rate limit of EDAR/DAO message by the 6LR be recommended ? RFC
> 4941 could be our enemy here...

This is RFC 8505 at work.  It lists some security protections but I've not seen that it is explicit in that regard. 
RFC 6550 has it in section 18.2.6.

   An implementation should support rate-limiting the sending of DAO
   messages.
"

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

Uncapitalized, but in the form RPL-Unaware Leaf that I left capitalized

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

Changed

> Please expand HbH in the section title.

Done

> Suggest to drop " and the packet is dropped otherwise."

Done

A great many thanks Eric!

Please let me know if I need to do more.

Take care and enjoy well-deserved vacations : )

Pascal

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 16 Dec 2020 10:17:23 +0000

Bonjour Pascal,

Thank you for the prompt reply as usual. Nice ASCII art __ and sad that SRH was already used in RPL foundation RFC. Thank you for the explanation about ROVR length field but as with the ND status transport in RPL status; as I do not have alternative proposals, I won't object but still find these techniques smart and ugly at the same time.

I still think that the abstract is not very useful for the casual reader in the current form.

Else, thank you for all the changes

Thanks as usual for your prompt reply and enjoy well-deserved vacations as well !

A+

-éric

-----Original Message-----
From: Pascal Thubert <[email-masked]>
Date: Tuesday, 15 December 2020 at 19:24
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, JADHAV Rahul <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24: (with COMMENT)

    Hello Eric

             ------+---------
                   |          Internet
                   |
                +-----+

    Done

    True, changed to:
    "

    Changed

    Done

    Done

    Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Dec 2020 11:08:13 +0000

Hello Eric:

For the abstract, would "
  This specification updates RFC6550, RFC6775, and RFC8505. It provides a
  mechanism for a host that implements a routing-agnostic interface based
  on 6LoWPAN Neighbor Discovery to obtain reachability services across a
  network that leverages RFC6550 for its routing operations.
"
Be better?

Take care,

Pascal
> From: Eric Vyncke (evyncke) <[email-masked]>
> Sent: mercredi 16 décembre 2020 11:17
> To: Pascal Thubert (pthubert) <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> JADHAV Rahul <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24:
> (with COMMENT)
> 
> Bonjour Pascal,
> 
> Thank you for the prompt reply as usual. Nice ASCII art __ and sad that SRH was
> already used in RPL foundation RFC. Thank you for the explanation about ROVR
> length field but as with the ND status transport in RPL status; as I do not have
> alternative proposals, I won't object but still find these techniques smart and
> ugly at the same time.
> 
> Cc: "[email-masked]" <draft-ietf-roll-unaware-
> [email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, JADHAV Rahul <[email-masked]>,
> "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
>     I pushed the result here: https://github.com/roll-wg/roll-unaware-
> leaves/commit/b5cc06f224389d1a436dbb4468cb7f07a6307b17
> 
>     > https://datatracker.ietf.org/doc/review-ietf-roll-unaware-leaves-23-iotdir-
> lc-
>     > van-der-stok-2020-12-08/
>     We faced that issue in the EDAR message, had to steal even more expensive
> bits. See https://tools.ietf.org/html/rfc8505#section-4.2
> 
> 
> 
>     > -- Section 6.3 --
>     Argl. No idea. I hope I'll get a recommendation from a native speaker. Elwyn
> made great comments and did not object here.
> 
> 
>     >
>     > What is the meaning of "negative" in "an NA message with a negative status
> "
>     > ?
>     Argl. In RFC6550 you're actually correct but here it's ND and arguably it was
> not defined that way and I'd rather not do it now. Changed to "non-zero
> status". Which are strictly positive values but indicate failures which is a negative
> outcome. Also changed one occurrence of "positive status" to "status indicating
> success"
>     >
>     > -- Section 11 --