Root-initiated Routing State in RPL
draft-ietf-roll-dao-projection-40

Thanks to Klaas Wierenga for their secdir review.

Here are two easy comments, and one that can possibly be explained pretty easily:  

Section 3.1, para 4, 'ships passing in the night':  I can't tell if this quote from the Henry Wadsworth Longfellow poem is being used properly (two ships that greet each other with flashing lights and then sail off into the night).  In any case, I don't think it helps the non-native English speakers.  Either provide a reference to explain the quote, or remove.

Section 10:  The mitigation recommendations here (or in the references) are very general - encrypt using algorithm x with mode y, perform good key management, etc. type of advice.  I'd be curious to see how many implementations can take action on these recommendations. Note:  I have not studied all the references here in great detail.  If there is one that covers my point, then please make it more obvious.

Section 10, para 2:  I'd suggest replacing 'so as to avoid threats such as black-holing' with 'avoiding sinkhole attacks' (as is done in RFC 7416).

Thank you addressing the blocking DISCUSS and considering the non-blocking COMMENTS

(original position https://mailarchive.ietf.org/arch/msg/roll/hxeSBgadv06wlwm1VpeePdOrdCU/ )

** Section 11.1
   IANA is requested to add [THIS RFC] as a reference for MOP 7 in the
   RPL Mode of Operation registry

Technically the name of the registry is “Model of Operation” registry, without the “RPL”.

** Section 11.12
| 0 (Suggested) | "S" flag: Sibling in   | THIS RFC  |
          |               | same DODAG as Self     |           |

Why is 0 being "suggested" if this section is creating the registry?

Thanks for addressing my previous block DISCUSS points and changing the text to also address the other non-blocking COMMENT points.

See https://mailarchive.ietf.org/arch/msg/roll/j7XHxmR5TZfiXAMsZtLiJks7lIU/ for the archived version.

The WG state includes the flag "Doc Shepherd Follow-up Underway".  Anything we should know about?

Section 6.7 (mainly, but it's also true in a few other places) have SHOULD [NOT]s that would benefit from some explanation of when one might legitimately not do what it advises.  Or, if there's no reason for choice, maybe they should be MUST [NOT]s?  Or if there's broad discretion, maybe MAY [NOT]s?

Thank you for writing this, and also thanks to Ran Chen for the OpsDir review -- https://datatracker.ietf.org/doc/review-ietf-roll-dao-projection-39-opsdir-telechat-chen-2025-03-05/

This has some useful nits, and I'd recommend addressing these.

Thanks for working on this specification. Thanks to Michael Scharf for his TSVART review, based on that and my read I have no objection.