Hi Konrad, Thank you for responding to our questions! We updated the document accordingly. Note that we did not make any changes per question #6 as there should not be any confusion for readers and the current is consistent with RFC 6550 (thanks for pointing that out!).
In a separate email, we will ask the AD to approve the changes that involve 2119 keywords (we consider those changes to be “above editorial”). Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. Here are the updated files (you may need to refresh): Updated XML file: https://www.rfc-editor.org/authors/rfc9866.xml Updated output files: https://www.rfc-editor.org/authors/rfc9866.txt https://www.rfc-editor.org/authors/rfc9866.pdf https://www.rfc-editor.org/authors/rfc9866.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9866-auth48diff.html https://www.rfc-editor.org/authors/rfc9866-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9866-diff.html https://www.rfc-editor.org/authors/rfc9866-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9866-alt-diff.html (shows changes where text is moved or deleted) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9866 Thank you, Rebecca VanRheenen RFC Production Center > On Sep 24, 2025, at 3:19 PM, Konrad Iwanicki <[email protected]> wrote: > > Dear Kaelin and Rebecca, > > Thank you for your suggestions! I really appreciate how much effort they > involved. Please, find my comments inline. > > On 23/09/2025 19:57, [email protected] wrote: >> 1) <!-- [rfced] FYI - This document contained many non-ASCII characters used >> for >> punctuation, such as smart quotes and en dashes. We updated to use the >> ASCII equivalents per the Web Portion of the Style Guide (see >> https://www.rfc-editor.org/styleguide/part2/#nonascii). >> To help you with your review, we created the following alt-diff file that >> does >> not contain any of those changes (i.e., changes from non-ASCII punctuation to >> ASCII equivalent): >> https://www.rfc-editor.org/authors/rfc9866-alt-diff.html >> This diff file includes all of changes: >> https://www.rfc-editor.org/authors/rfc9866-diff.html >> --> > > Approved. > >> 2) <!-- [rfced] Please note that the title of the document has been updated >> as >> follows. We expanded abbreviations per Section 3.6 of RFC 7322 ("RFC >> Style Guide") and also revised "Fast Border Router Crash Detection" to >> improve readability. Let us know any concerns. >> Original: >> RNFD: Fast border router crash detection in RPL >> Current: >> Root Node Failure Detector (RNFD): Fast Detection of Border Router Crashes >> in the Routing Protocol for Low-Power and Lossy Networks (RPL) >> --> > > Approved. > >> 3) <!-- [rfced] We were unable to find the terms "control traffic", "Trickle >> algorithm", or "DODAG" in RFC 6202. Should this citation be updated to >> RFC 6206? >> Original: >> Finally, switching a parent or discovering a loop can also generate >> cascaded bursts of control traffic, owing to the adaptive Trickle >> algorithm >> for exchanging DODAG information [RFC6202]. >> --> > > Approved. Of course this should be RFC 6206. > >> 4) <!-- [rfced] Is "if possible" needed here? >> Original: >> Given the consequences of LBR failures, if possible, it is also worth >> considering other solutions to the problem. >> Perhaps: >> Given the consequences of LBR failures, it is also worth >> considering other solutions to the problem. >> --> > > Approved. The proposed version makes more sense. > >> 5) <!-- [rfced] Would including a reference for "generic format of RPL >> Control >> Message Options" be helpful to readers? >> Original: >> The format of the RNFD Option conforms to the generic format of RPL >> Control Message Options: >> --> > > Yes, certainly. In case you need it, it is in Section 6.7.1 of RFC 6550. > >> 6) <!-- [rfced] Section 4.2: We note that "Type" appears in Figure 2, but >> that it >> is defined as "Option Type" in the definition list that follows. Are any >> updates needed for consistency? >> --> > > I put "Type" in the figure, because "Option Type = 0x0E" would not fit. This > approach is consistent with RFC 6550: compare in particular Figure 19 with > Figures 20, 21, 22, and the like. However, it makes sense to make this more > explicit. What I would do, if possible, would be changing the legend under > the figure as follows. > > OLD: > Option Type: 0x0E > > NEW: > Type: RPL Option Type = 0x0E. > >> 7) <!-- [rfced] We have updated this long sentence to be two sentences to >> improve >> readability. Please review to confirm these updates do not change your >> intended meaning (in particular, our addition of another "MUST" in the >> second sentence). >> Original: >> * for “UP” and “SUSPECTED DOWN”, the node MUST set its LORS to “UP”, >> MUST NOT modify it PositiveCFRC, but MUST add itself to >> NegativeCFRC, that is, replace its NegativeCFRC, denoted oldnc, >> with newnc = merge(oldnc, selfc), where selfc is the counter >> generated with self() when the node last added itself to its >> PositiveCFRC. >> Current: >> * For "UP" and "SUSPECTED DOWN", the node MUST set its LORS to "UP" and >> MUST NOT modify its PositiveCFRC, but it MUST add itself to >> NegativeCFRC. That is, it MUST replace its NegativeCFRC (denoted >> oldnc) >> with newnc = merge(oldnc, selfc), where selfc is the counter >> generated with self() when the node last added itself to its >> PositiveCFRC. >> --> > > The split is fine, but I would leave the commas instead of the parentheses: > > OLD: > replace its NegativeCFRC (denoted oldnc) with > > NEW: > replace its NegativeCFRC, denoted oldnc, with > >> 8) <!-- [rfced] We are having trouble understanding this sentence. We >> updated the >> introductory clause ("Whenever...DODAG root") as follows. Please review >> to ensure the updated text accurately conveys the intended meaning. >> Original: >> Whenever having its LORS set to “UP” RNFD concludes — based on either >> external or internal inputs — that there may be problems with the >> link with the DODAG root, it MUST set its LORS to either “SUSPECTED >> DOWN” or, as an optimization, to “LOCALLY DOWN”. >> Updated: >> Whenever its LORS is set to "UP" and RNFD concludes (based on either >> external or internal inputs) that there may be problems with the >> link with the DODAG root, it MUST set its LORS either to "SUSPECTED >> DOWN" or, as an optimization, to "LOCALLY DOWN". >> --> > > The updated clause sounds somewhat weird to me, especially the combination of > "its ... and RNFD ...". How about putting commas around "having its LORS set > to “UP”": > > OLD: > Whenever its LORS is set to "UP" and RNFD concludes (based on either > external or internal inputs) that there may be problems with the > link with the DODAG root, it MUST set its LORS either to "SUSPECTED > DOWN" or, as an optimization, to "LOCALLY DOWN". > > NEW: > Whenever, having its LORS set to “UP”, RNFD concludes (based on either > external or internal inputs) that there may be problems with the > link with the DODAG root, it MUST set its LORS to either “SUSPECTED > DOWN” or, as an optimization, to “LOCALLY DOWN”. > > >> 9) <!-- [rfced] Would updating "previous conditions 2–4" as following make >> this >> text easier for readers to follow? >> Original: >> In such a case, it SHOULD set its LORS back to >> “UP” but MUST NOT do this before the previous conditions 2–4 >> necessary for a node to change its role from Acceptor to Sentinel all >> hold (see Section 5.1). >> Perhaps: >> In such a case, it SHOULD set its LORS back to >> "UP" but MUST NOT do this before conditions 2-4 in Section 5.1, which are >> necessary for a node to change its role from Acceptor to Sentinel, all >> hold. >> --> > > Approved. > >> 10) <!-- [rfced] Is "again" needed in these sentences? >> Original: >> By symmetry, if there is a transition from “LOCALLY >> DOWN” to “UP”, the node MUST add itself to its PositiveCFRC, again, >> as explained previously. >> ... >> In addition, if its LORS is “LOCALLY >> DOWN”, then it MUST also add itself to its NegativeCFRC, again, as >> explained previously. >> ... >> In this way, again, a sufficient bit length can be >> dynamically discovered or the root can conclude that a given bit >> length is excessive for (some) nodes and resort to the previous >> solution. >> Perhaps (remove "again"): >> By symmetry, if there is a transition from "LOCALLY >> DOWN" to "UP", the node MUST add itself to its PositiveCFRC, >> as explained previously. >> ... >> In addition, if its LORS is "LOCALLY >> DOWN", then it MUST also add itself to its NegativeCFRC, as >> explained previously. >> ... >> In this way, a sufficient bit length can be >> dynamically discovered or the root can conclude that a given bit >> length is excessive for (some) nodes and resort to the previous >> solution. >> --> > > Approved. > >> 11) <!-- [rfced] We split this long sentence into two sentences and updated >> "for >> example, replying" to "For example, it MAY reply". Please review >> (especially our addition of another "MAY") and let us know any objections. >> Original: >> In particular, it MAY reset its Trickle timer to this end but also MAY use >> some reactive mechanisms, for example, replying with a unicast DIO or DIS >> containing the RNFD Option with no CFRCs to a message from a neighbor that >> contains the option with some CFRCs, as such a neighbor appears not to >> have >> learned about the deactivation of RNFD. >> Current: >> In particular, it MAY reset its Trickle timer to this end but MAY also use >> some reactive mechanisms. For example, it MAY reply with a unicast DIO or >> DIS containing the RNFD Option with no CFRCs to a message from a neighbor >> that contains the option with some CFRCs, as such a neighbor appears not >> to >> have learned about the deactivation of RNFD. >> --> > > Approved. > >> 12) <!-- [rfced] May we rephrase these as follows to form complete sentences? >> Original: >> In general, the higher the value the longer the detection period but the >> lower the risk of false positives. >> The higher the value the longer the duration of detecting true crashes >> but the lower the risk of increased traffic due to verifying false >> suspicions. >> The higher the value >> is, the higher the probability of bit collisions, and hence the >> more erratic the results of function value(c) may be. >> Perhaps: >> In general, when the value is higher, the detection period is longer, but >> the risk of false positives is lower. >> When the value is higher, the duration of detecting true crashes is >> longer, >> but the risk of increased traffic due to verifying false >> suspicions is lower. >> When the value is higher, the probability of bit collisions is higher, and >> the results of function value(c) may thus be more erratic. >> --> > > Approved. > >> 13) <!-- [rfced] Will readers understand what is being connected with the >> second >> "and" in this sentence? >> Original: >> One approach to node role and CFRC size selection is to manually >> designate specific nodes as Sentinels in RNFD, assuming that they >> will have chances to satisfy the necessary conditions for attaining >> this role (see Section 5.1), and fixing the CFRC bit length to >> accommodate these nodes. >> Perhaps (to designate...and...to fix): >> One approach to node role and CFRC size selection is to manually >> designate specific nodes as Sentinels in RNFD, assuming that they >> will have chances to satisfy the necessary conditions for attaining >> this role (see Section 5.1), and to fix the CFRC bit length to >> accommodate these nodes. >> Or (for attaining...and...for fixing): >> One approach to node role and CFRC size selection is to manually >> designate specific nodes as Sentinels in RNFD, assuming that they >> will have chances to satisfy the necessary conditions for attaining >> this role (see Section 5.1) and for fixing the CFRC bit length to >> accommodate these nodes. >> --> > > Approved the version after "Perhaps". The one after "Or" is wrong. The > original statement was also incorrectly constructed. > >> 14) <!-- [rfced] Section 5.8 appears to describe three thresholds. Should >> the text >> below be updated accordingly? >> Original: >> This SHOULD be taken into account in the policies for node >> role assignment, CFRC size selection, and, possibly, the setting of >> the two thresholds (Section 5.8). >> Perhaps: >> This SHOULD be taken into account in the policies for node role >> assignment, >> CFRC size selection, and, possibly, the setting of the three thresholds >> (Section 5.8). >> --> > > Approved. > >> 15) <!-- [rfced] We updated this text as follows to form a complete >> sentence. However, due to context (see text prior to this sentence), >> should this read "This information SHOULD be" rather than the current >> "This information is"? >> Original: >> accompanied by the recommended monitoring parameters provided by RPL >> itself [RFC6550], notably the DODAG Version number and the Rank. >> Current: >> This information is accompanied by the recommended monitoring parameters >> provided by RPL >> itself [RFC6550], notably the DODAG Version number and the Rank. >> Perhaps: >> This information SHOULD be accompanied by the recommended monitoring >> parameters provided by RPL >> itself [RFC6550], notably the DODAG Version number and the Rank. >> --> > > Neither. Instead, see my proposal below. The rationale is that one cannot > interpret the new bits of information without the information from RPL. > > OLD: > This information is accompanied by the recommended monitoring parameters > provided by RPL itself [RFC6550], notably the DODAG Version number and the > Rank. > > NEW: > This information MUST be accompanied by the recommended monitoring parameters > provided by RPL itself [RFC6550], notably the DODAG Version number and the > Rank. > > >> 16) <!-- [rfced] Note that we removed several instances of "in turn" to >> improve >> readability of the text. Please review those in the diff file and let us >> know any concerns. >> --> > > Approved, with the following remarks: > > OLD: > They are also used by nodes to periodically report their connectivity upward > to the LBR, which allows for directing packets downward from the LBR to these > nodes (for instance, by means of source routing [RFC6554]). > > NEW: > They are also used by nodes to periodically report their connectivity upward > to the LBR, which allows for directing packets downward from the LBR to these > nodes (e.g., by means of source routing [RFC6554]). > > OLD: > Internally, it is RECOMMENDED that RNFD take action whenever there is a > change to its > NEW: > Internally, in turn, it is RECOMMENDED that RNFD take action whenever there > is a change to its > > OLD: > During a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", the node > MUST add itself to its NegativeCFRC, as explained previously. > > NEW: > In contrast, during a switch from "UP" or "SUSPECTED DOWN" to "LOCALLY DOWN", > the node MUST add itself to its NegativeCFRC, as explained previously. > > OLD: > Those that pass undetected are likely not to have major negative > > NEW: > Those that do pass undetected are likely not to have major negative > >> 17) <!-- [rfced] We note that the terms below appear both capitalized and >> lowercase in this document. Should these be uniform? If so, please let us >> know which form is preferred. >> DODAG Version v. DODAG version >> Note: RFC 6550 uses the capitalized form. >> Rank v. rank >> --> > > They can (and probably should) be made uniform. The capitalized form is > preferred as in RFC 6550. > >> 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online >> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> and let us know if any changes are needed. Updates of this nature typically >> result in more precise language, which is helpful for readers. >> Note that our script did not flag any words in particular, but this should >> still be reviewed as a best practice. >> --> > > I did not find any violations, but if necessary, I will try to read more > carefully during a next revision. > >> Thank you. > > Thank you again! > > Best regards, > -- > - Konrad Iwanicki. > > >> Kaelin Foody and Rebecca VanRheenen >> RFC Production Center >> On Sep 23, 2025, at 10:50 AM, [email protected] wrote: >> *****IMPORTANT***** >> Updated 2025/09/23 >> RFC Author(s): >> -------------- >> Instructions for Completing AUTH48 >> Your document has now entered AUTH48. Once it has been reviewed and >> approved by you and all coauthors, it will be published as an RFC. >> If an author is no longer available, there are several remedies >> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> You and you coauthors are responsible for engaging other parties >> (e.g., Contributors or Working Group) as necessary before providing >> your approval. >> Planning your review >> --------------------- >> Please review the following aspects of your document: >> * RFC Editor questions >> Please review and resolve any questions raised by the RFC Editor >> that have been included in the XML file as comments marked as >> follows: >> <!-- [rfced] ... --> >> These questions will also be sent in a subsequent email. >> * Changes submitted by coauthors >> Please ensure that you review any changes submitted by your >> coauthors. We assume that if you do not speak up that you >> agree to changes submitted by your coauthors. >> * Content >> Please review the full content of the document, as this cannot >> change once the RFC is published. Please pay particular attention to: >> - IANA considerations updates (if applicable) >> - contact information >> - references >> * Copyright notices and legends >> Please review the copyright notice and legends as defined in >> RFC 5378 and the Trust Legal Provisions >> (TLP – https://trustee.ietf.org/license-info). >> * Semantic markup >> Please review the markup in the XML file to ensure that elements of >> content are correctly tagged. For example, ensure that <sourcecode> >> and <artwork> are set correctly. See details at >> <https://authors.ietf.org/rfcxml-vocabulary>. >> * Formatted output >> Please review the PDF, HTML, and TXT files to ensure that the >> formatted output, as generated from the markup in the XML file, is >> reasonable. Please note that the TXT will have formatting >> limitations compared to the PDF and HTML. >> Submitting changes >> ------------------ >> To submit changes, please reply to this email using ‘REPLY ALL’ as all >> the parties CCed on this message need to see your changes. The parties >> include: >> * your coauthors >> * [email protected] (the RPC team) >> * other document participants, depending on the stream (e.g., >> IETF Stream participants are your working group chairs, the >> responsible ADs, and the document shepherd). >> * [email protected], which is a new archival mailing list >> to preserve AUTH48 conversations; it is not an active discussion >> list: >> * More info: >> >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> * The archive itself: >> https://mailarchive.ietf.org/arch/browse/auth48archive/ >> * Note: If only absolutely necessary, you may temporarily opt out >> of the archiving of messages (e.g., to discuss a sensitive matter). >> If needed, please add a note at the top of the message that you >> have dropped the address. When the discussion is concluded, >> [email protected] will be re-added to the CC list and >> its addition will be noted at the top of the message. >> You may submit your changes in one of two ways: >> An update to the provided XML file >> — OR — >> An explicit list of changes in this format >> Section # (or indicate Global) >> OLD: >> old text >> NEW: >> new text >> You do not need to reply with both an updated XML file and an explicit >> list of changes, as either form is sufficient. >> We will ask a stream manager to review and approve any changes that seem >> beyond editorial in nature, e.g., addition of new text, deletion of text, >> and technical changes. Information about stream managers can be found in >> the FAQ. Editorial changes do not require approval from a stream manager. >> Approving for publication >> -------------------------- >> To approve your RFC for publication, please reply to this email stating >> that you approve this RFC for publication. Please use ‘REPLY ALL’, >> as all the parties CCed on this message need to see your approval. >> Files >> ----- >> The files are available here: >> https://www.rfc-editor.org/authors/rfc9866.xml >> https://www.rfc-editor.org/authors/rfc9866.html >> https://www.rfc-editor.org/authors/rfc9866.pdf >> https://www.rfc-editor.org/authors/rfc9866.txt >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9866-diff.html >> https://www.rfc-editor.org/authors/rfc9866-rfcdiff.html (side by side) >> Alt-diff of the text (allows you to more easily view changes >> where text has been deleted or moved): >> https://www.rfc-editor.org/authors/rfc9866-alt-diff.html >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9866-xmldiff1.html >> Tracking progress >> ----------------- >> The details of the AUTH48 status of your document are here: >> https://www.rfc-editor.org/auth48/rfc9866 >> Please let us know if you have any questions. >> Thank you for your cooperation, >> RFC Editor >> -------------------------------------- >> RFC9866 (draft-ietf-roll-rnfd-07) >> Title : RNFD: Fast border router crash detection in RPL >> Author(s) : K. Iwanicki >> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
