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

["Pascal Thubert (pthubert)" <[e-mail]>]

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
> -----Original Message-----
> From: Eric Vyncke (evyncke) <[e-mail]>
> Sent: mercredi 16 décembre 2020 11:17
> To: Pascal Thubert (pthubert) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> JADHAV Rahul <[e-mail]>; [e-mail];
> [e-mail]
> 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.
> 
> 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]" <draft-ietf-roll-unaware-
> [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
>