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]
