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

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke 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:
----------------------------------------------------------------------

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

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.

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

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

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

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

== NITS ==

Is Ines' affiliation still correct?

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