Hi Konrad, Thank you for your reply. We made the changes listed in your last email and also marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9866).
We will now await discussion and resolution of the suggestions from Ines Robles regarding the new normative key words. 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 files showing just the last round of AUTH48 changes: https://www.rfc-editor.org/authors/rfc9866-lastdiff.html https://www.rfc-editor.org/authors/rfc9866-lastrfcdiff.html (side by side) Diff files 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 27, 2025, at 7:52 AM, Konrad Iwanicki <[email protected]> wrote: > > Dear Rebecca, > > Thank you again for your work! I reviewed the entire document. I APPROVE it, > but leave the following tiny suggestions to your discretion (not requiring > further approval): > > 1. > > OLD: > Detecting a crash of a link by a node normally happens when the node has > sufficiently observed many forwarding failures over the link. > > NEW: > Detecting a crash of a link by a node normally happens when the node has > observed sufficiently many forwarding failures over the link. > > OR: > Detecting a crash of a link by a node normally happens when the node has > observed a sufficient number of forwarding failures over the link. > > [This is because "sufficiently observed" seems vague to me.] > > 2. > > OLD: > However, when a node (acting as a Sentinel) starts suspecting that the root > may have > > NEW: > However, when a node acting as a Sentinel starts suspecting that the root may > have > > [This is to emphasize the need for being a Sentinel.] > > > 3. > > OLD: > (for instance, link-layer triggers about missing hop-by-hop acknowledgments > > NEW: > (e.g., link-layer triggers about missing hop-by-hop acknowledgments > > 4. > > OLD: > (for example, a significant growth in the number of Sentinels > > NEW: > (e.g., a significant growth in the number of Sentinels > > [These two are for consistency with the rest of the text.] > > Thank you again for doing the edits! > > Best regards, > -- > - Konrad Iwanicki. > > > On 26/09/2025 03:54, Rebecca VanRheenen 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 >>> > > -- > - Konrad Iwanicki. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
