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

[Ines Robles <[e-mail]>]

Dear Benjamin,

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 Thu, Dec 17, 2020 at 10:48 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Unfortunately, I only had time to review the diff from the -29 (that
> addressed my previous batch of comments) and the -42, and was not able
> to attempt to look closely at the new tables and their depiction of the
> added/modified/removed/untouched headers.  As such, I do not have many
> comments.
>
> Since we are marking MOP value 7 as reserved, do we expect this document
> to be listed as a reference for that entry in the registry?
>

<authors> New text in Section 11.2
This document requests to be mentioned as a reference for this change.
</authors>

>
>
> Section 1
>
>    Most of the use cases described therein require the use of IPv6-in-
>
> nit: s/therein/herein/
>

<authors> fixed </authors>

>
> Section 2
>
>    Flag Day: In this document, refers to a transition that involves
>    having a network with different values of RPI Option Type.
>
> Is the flag day the act of transitioning the network from one value to
> the other, or only the sub-case when it is a disruptive transition, or
> ...?
>
> <authors> The new description of flag day is as follows:

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 3
>
>    routed.  A RPL Instance is either fully storing or fully non-storing,
>    i.e. a RPL Instance with a combination of storing and non-storing
>    nodes is not supported with the current specifications at the time of
>    writing this document.
>
> (I assume there is no conflict between this statement and the behavior
> described in Section 4.1.1 whereby external routes are advertised with
> non-storing-mode messaging even in a storing-mode network.)
>

<authors> we added clarification in order to avoid confusion, the proposed
new text is as follows:

RPL supports two modes of Downward internal traffic: in storing mode
(SM), it is fully stateful; in non-storing mode (Non-SM), it is fully
source routed.  A RPL Instance is either fully storing or fully non-
storing, i.e. a RPL Instance with a combination of a fully storing
and non-storing nodes is not supported with the current
specifications at the time of writing this document.  External routes
are advertised with non-storing-mode messaging even in a storing mode
network, see Section 4.1.1

</authors>

>
> Section 4.1.1
>
>    In order to enable IP-in-IP all the way to a 6LN, it is beneficial
>    that the 6LN supports decapsulating IP-in-IP, but that is not assumed
>    by [RFC8504].  If the 6LN is a RUL, the Root that encapsulates a
>    packet SHOULD terminate the tunnel at a parent 6LR unless it is aware
>    that the RUL supports IP-in-IP decapsulation.
>
> Is there anything useful to say about how the Root would know that the
> RUL supports IP-in-IP decapsulation?  ("No" is a valid answer :)
>

<authors> Not in the scope of this document </authors>

>
> Section 4.3
>
>    This modification is required in order to be able to decompress the
>    RPL Option with the new Option Type of 0x23.
>
> nit(?): is it the RPL Option or the entire header that is decompressed?
>

<authors> decompress the option </authors>

>
> Section 6
>
>       - For traffic leaving a RUL, if the RUL adds an opaque RPI then
>       the description of the RAL applies.  The 6LR as a RPL border
>       router SHOULD rewrite the RPI to indicate the selected Instance
>       and set the flags.
>
> I'm not sure that I fully understand this point (specifically, "the
> description of the RAL applies").  Similar text also appears in the
> Security Considerations.
>

<authors> New proposed text :
For traffic leaving a RUL, if the RUL adds an opaque RPI then
the 6LR as a RPL border router SHOULD rewrite the RPI to indicate
the selected Instance and set the flags.
 </authors>

>
> Section 8.2.4
>
> There seem to be some changes in the table compared to the -29; were
> these verified to be correct?
>

<authors> yes, it is correct, we moved the -modified headers - to be
located after the -added headers- in all the tables </authors>

>
> Section 12
>
>    Also, this applies in the case where the leaf is aware of the RPL
>    instance and passes a correct RPI, the 6LR needs a configuration that
>    allows that leaf to inject in that instance.
>
> nit: the second comma should probably be a colon or em dash.
>
> <authors> fixed </authors>

Thank you very much again,

Ines, Michael and Pascal.