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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, 15 December 2020 at 19:24
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, JADHAV Rahul <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-roll-unaware-leaves-24: (with COMMENT)

    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:

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

    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

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

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


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

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


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

    Done

    > -- Section 3 --
    > "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 ..
    "

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



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

    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.


    > -- Section 9.1 --
    > 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
    > this term well defined and well accepted?

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

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

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

    Done

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