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

[Ines Robles <[e-mail]>]

Dear Eric,

Thank you very much for your comments and suggestions, we believe that
version 43 (diff) addresses your concern, please find comments inline:

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-43



On Mon, Dec 14, 2020 at 6:17 PM Éric Vyncke via Datatracker <
[e-mail]> wrote:

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. It is long but also clear
> and
> easy to read.
>
> Malisa's IoT directorate review indicates nothing to be addressed (thank
> you
> again Malisa !):
>
> https://datatracker.ietf.org/doc/review-ietf-roll-useofrplinfo-42-iotdir-lc-vucinic-2020-12-09/
>
> The changes since my latest "no objection" ballot appear to be mainly
> editorial
> beside a couple of big changes (rightfully causing a new IETF last call).
> 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 ==
>
> -- Section 2 --
>   "As an IPv6 node, a RPL Leaf is expected to ignore a
>    consumed Routing Header and as an IPv6 host, it is expected to ignore
>    a Hop-by-Hop header.  "
>
> Suggest to define what is a "consumed RH".
>

<authors> New text added in Terminology:

Consumed: A Routing Header is consumed when the Segments Left field
    is zero, which indicates that the destination in the IPv6 header is
    the final destination of the packet and that the hops in the Routing
    Header have been traversed.

</ authors >


>
> Suggest to be clear about the HbH: some options in HbH can be ignored
> indeed
> but by all *nodes*, there is nothing specific for *hosts* (as they are also
> nodes) per section 4.3 of RFC 8200.
>

< authors >
hosts replaced by nodes.  New text:

...nodes that are pre-RFC8200, or simply intolerant.  Those nodes will
drop packets that continue to have RPL artifacts in them.  In
general, such nodes can not be easily supported in RPL LLNs....

</ authors >

>
> "RPL Packet Information (RPI): The abstract information" why is this
> 'abstract'
> ?
>

< authors > New text that clarifies the use of abstract in the document:

RPL Packet Information (RPI): The information defined abstractly in
[RFC6550] to be placed in IP packets.  The term is commonly used,
including in this document, to refer to the RPL Option [RFC6553] that
transports that abstract information in an IPv6 Hop-by-Hop Header.
[RFC8138] provides an alternate (more compressed) formating for the
same abstract information.

</ authors >

>
> I also find the definition of 'flag day' confusing... can 2 values of RPI
> Option Types co-exist in the network?
>
> < authors >
New definition of flag day

Flag Day: It is a mechanism for resolving an interoperability
 situation (e.g. lack of interoperation between new RPI Option Type
(0x23) and old RPI Option Type (0x63) nodes) by making an abrupt,
disruptive changeover from one to the other.

</ authors >

-- Section 4.2 --
>   "When originating new packets, implementations SHOULD have an option
>    to determine which value to originate with, this option is controlled
>    by the DIO option described below."
>
> Unsure whether normative language should be used in the above text.
> Moreover,
> if the option type is controlled by the DIO option, then there is no more
> 'option' to determine the value as it is specified.
>

<authors> Normative language eliminated, new text is as follows:

When originating new packets, implementations should have an option
to determine which value to originate with, this option is controlled
by the DIO Configuration option (Section Section 4.1.3).

</authors>

>
> -- Section 7.2.2 --
> Should the text also include 'decapsulate from IPv6-in-IPv6" in addition to
> "When the packet arrives at the RAL the RPI is removed " ?
>

< authors > New text:
When the packet arrives at the RAL, the packet is decapsulated, which
removes the RPI before the packet is processed.
</ authors >

>
> == NITS ==
>
> Is Ines' affiliation still correct?
>

< authors > Yes </ authors >

>
> -- Section 4.1.1 --
> Suggest to start a new paragraph from "In the other direction, ..."
>

< authors > done </ authors >

Thank you very much again,

Ines, Michael and Pascal