Hi Rebecca, It seems good to me. However, I would like either Ines or Aris (ROLL WG chairs) to also confirm this is ok to go without a check with the WG.
Thanks, Ketan On Fri, Sep 26, 2025 at 7:29 AM Rebecca VanRheenen < [email protected]> wrote: > 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”
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
