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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-roll-useofrplinfo-42: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/



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


Section 1

   Most of the use cases described therein require the use of IPv6-in-

nit: s/therein/herein/

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

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

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

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?

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.

Section 8.2.4

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

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.