Konrad, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
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 --> 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) --> 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]. --> 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. --> 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: --> 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? --> 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. --> 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". --> 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. --> 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. --> 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. --> 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. --> 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. --> 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). --> 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. --> 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. --> 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 --> 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. --> Thank you. 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]
