Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-44

Thanks for addressing my DISCUSSes and COMMENTs.

I strongly support Roman's DISCUSS - the scaling *seems* like it would end poorly, and I'm a bit confused about what exactly is being recommended. 
I'm not 100% sure I understand how the deployment will actually occur, and so perhaps the IPSEC scaling doesn't cause an issue?

The revised ID has fixed all my DISCUSS points. Thank you to the authors.

Thanks to everyone who worked on this document. I have only one minor comment.

I'm a bit perplexed by the interplay between sections 3.1 and 3.3.

Section 3.1 says:

>  This change creates a flag day for existing networks which are
>  currently using 0x63 as the RPI value.

And then section 3.3 says:

>  In order to avoid a Flag Day caused by lack of interoperation between
>  new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag
>  in the DIO Configuration Option...

Which leaves me wondering whether the net effect of this document does or does
not create a flag day for networks. Please consider updating these sections to
be consistent with each other.

= Section 1 =

"An interim meeting went through the 24 cases defined here to discover
   if there were any shortcuts, and this document is the result of that
   discussion."

These details seem unnecessary to include in an archival document.

= Section 3.1 =

"[RFCXXXX] represents this document."

This is not necessary to include.

= Section 9 =

"Related to the deployment of RPL, there are no known multivendor
   deployments outside of the research groups!  All known deployments of
   RPL are in market verticals, with a single vendor providing all
   components.  Research groups typically are using Contiki, RiotOS, or
   OpenWSN, and these are easily adapted to 0x23 functionality."

It seems like this text should be dropped or marked for removal once the RFC is published, since it will likely become out-of-date soon enough.

Thank you for addressing my Discuss (and Comment) points!

I just have a few more minor notes on the -29:

the "(1)" footnote is no longer present.

I'm also not sure about the global change from "<foo>_i are the 
intermediate routers" to "<foo>_i is the intermediate router", since the
general case can still have more than one intermediate in each
direction.  But perhaps we should leave this to the RFC Editor.

Section 11

nit: "especially if the target of the attack is targeting another LLN" 
had redudant "target" added -- just "especially if attack is targeting
another LLN" would be fine.

I think the claim that "[i]n the end, the IPsec tunnels would be
providing only BCP38-like origin authentication!" could use some
additional justifcation.

I only did a quick read of this document but I would like to echo the TSV-ART review (Thanks Colin!) that a pointer to RFC6040 could be good in order to highlight support of ECN for any tunnelling solutions. Also there is draft-ietf-intarea-tunnels which could be a good pointer/read for this spec.

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

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

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