Hi Ketan, As AD, please review and approve the changes listed below. These are best viewed in the following diff file: https://www.rfc-editor.org/authors/rfc9866-alt-diff.html.
- addition of “MUST” in last sentence of third bullet in Section 5.1 - addition of “MAY” in last sentence in Section 5.5 - addition of “MUST” in second paragraph in Section 6.3 Thank you, Rebecca VanRheenen RFC Production Center > On Sep 25, 2025, at 6:54 PM, Rebecca VanRheenen > <[email protected]> wrote: > > 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]
