Subject: Re: [Roll] Suresh Krishnan's No Objection on draft-ietf-roll-useofrplinfo-29: (with COMMENT)

From: Ines Robles <[email-masked]>
Date: Tue, 25 Jun 2019 18:19:56 +0300

Hi Suresh,

Thank you very much for your review. we believe that version 30 addressed
your concerns. Please find answers in-line.

On Thu, May 30, 2019 at 3:14 PM Suresh Krishnan via Datatracker <
[email-masked]> wrote:

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> * Section 3.1
>
> This text following the RFC8200 quote is not supported or implied by the
> quote
>
> "This means that while it should be avoided, the impact on the Internet of
> leaking a Hop-by-Hop header is acceptable."
>
> Is this text necessary?
>

<author>

We deleted that text

</author>

>
> * Section 3.2
>
> It is not clear if nodes are required to change option types when the
> config
> flag transitions from 0 to 1 (e.g. after the reboot mentioned). Can you
> please
> clarify?
>
> <author>

New text: “

  <t>

            In case of rebooting, the node (6LN or 6LR) does not remember
the RPL Option Type, that is if the flag is set, so DIO messages sent by
the node would be set with the flag unset until a DIO message is received
with the flag set indicating the new RPI value. The node sets to 0x23 if
the node supports this feature.

          </t> “

</author>

> * Section 6
>
> In the cases where a hop-by-hop options header needs to be added (denoted
> by
> "hop" in the table), I am assuming that the destination address is copied
> from
> the inner packet into the encapsulating packet. If this is right, I think
> it
> might be useful to explicitly mention it as the dst field of the table
> does not
> provide the required information.
>

<author>

New text added: “ In the hop-by-hop basis, the destination address

    for the next hop is the link-layer address of the next hop.”

</author>

Thank you very much again,

Ines, Michael and Pascal.