Note: This ballot was opened for revision 25 and is now closed.
= 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.
Thanks for addressing my DISCUSSes and COMMENTs.
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.
* 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.
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?
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.
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.
The revised ID has fixed all my DISCUSS points. Thank you to the authors.