This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Review of draft-ietf-roll-rnfd: I have one question from the transport perspective about the number of messages and thereby potentially increase in traffic volume of this extension and one more question/comment about a specific sentence. I think these are essential things that should be addressed before publications. Further, I noticed a couple of cases where the use of normative language is unclear (see some examples below). I recommend to double-check that. And third, I have a couple of editorial comments but I know those are often a matter of writing style and may or may not be addressed. Here are my detailed comments: 1) For the transport perspective my understanding is that this extension might produce additional messages based on the Tickle timer. However, there are no further recommendations given how to configure this time and especially how to ensure to not overload the network if the timer is selected way to low. Particularly, I think this should be further specfied in the following cases: In Section 5.2: “Internally, in turn, it is RECOMMENDED that RNFD take action whenever there is a change to its local CFRCs, so that a node can have a chance to participate in detecting potential problems even when normally it would not exchange packets over the link with the DODAG root during some period. “ I not sure what is actually meant by “take action”? Does it mean it should send additional packets? If so this needs to be better specified, when to send what and how often…? In Section 5.3: “It is RECOMMENDED to use for RNFD a dedicated Trickle timer, different from RPL’s original DIO Trickle timer.” How is the Trickle timer supposed to be configured? Section 5.5: “However, it is RECOMMENDED that it sends sufficiently many messages with the option to the link-local all-RPL-nodes multicast IPv6 address to allow its neighbors to learn that RNFD has been deactivated in the current DODAG version. “ What is sufficiently here? Also it would be important to discuss to not send to much messages to not overload the network. 2) Further I have a question about this sentence: Section 4.2: “Finally, if PosCFRC has all its bits equal to 1, then NegCFRC MUST also have all its bits equal to 1.” I might be confused but isn’t this sentence the wrong way around? 3) Here are a couple of examples where the normative language to very vague, too unclear, or potentially wrongly used: In section 5.2.: “Care SHOULD be taken not to overload the DODAG root with traffic due to simultaneous probes, …” and “RNFD also MUST make use of RPL’s independent knowledge.” and “An implementation SHOULD thus try to minimize false-positive transitions from “UP” and “SUSPECTED DOWN” to “LOCALLY DOWN”.” These don’t seems like good use of normative language because it doesn’t specify a specific protocol action. Section 5.4 “ Furthermore, the DODAG root SHOULD either generate a new DODAG Version or increase the bit length of its CFRCs if saturated(PositiveCFRC) becomes TRUE.” Why is this a SHOULD and not a MUST? “The DODAG root MAY thus perform this operation also in other situations.” Which situations? This is very unspecific for a normative MAY. Section 5.5 “However, the activation and deactivation SHOULD be done at the DODAG root node; other nodes MUST comply.” Why is this a SHOULD and not a MUST. And was does “MUST comply” actually mean? I think the MUSTs should in the following sections are sufficient. Section 5.6: “A node thus MUST be prepared to receive...” This is also a MUST without clear instruction, or actually the normative instructions follow later which is sufficient. Section 61.: “In either of the solutions, Sentinel nodes SHOULD preferably be stable themselves and have stable links to the DODAG root.” Not sure what this even means or what action this implies. “Although as a mitigation the number of such transitions and switches per node MAY be limited, having Sentinels stable SHOULD be preferred.” What does the SHOULD here imply? 4) Some smaller editorial notes mainly on the abstract and intro: I find the first two sentence in the abstract a bit generic and recommend to actually just remove them. You don’t need a motivation in the abstract for a protocol spec. Just say straight away what the protocol is about. Also I actually had to look up the term “by and large”…. again seems that term is actually not needed and doesn’t help t make anything actually more clear. And then even though this doc defines an extension to RPL for me as a non-expert it was actually not clear what the acronym stands for or what an “RPL network” is supposed to be. Further I highly recommend you to expand the acronym RNFD already in the abstract. Also note that the first time this term is used is in section 1.2 on design principles. I would have expected that the intro would already early on say that this is the name of the extension specified in this doc. Generally, note that the RFC style guide actually says that the abstract is usually in part constructed from material in the introduction section (see https://datatracker.ietf.org/doc/html/rfc7322#section-4.3). Or I would say this also the other way around, I recommend to also repeat anything you say in the abstract in the intro to some extend; sometimes this is even done using the same wording. And finally on the abstract it say “expedites […] even by an order of magnitude”, however, compared to what? One editorial comment on the doc body: I know this is probably a matter of taste, but I personally find the definition of zero(), infinity(), and self() not very helpful, rather than just sending in word, e.g. also bits set to zero.