Hello Karen Please see below
> Le 11 mars 2026 à 20:23, Karen Moore <[email protected]> a écrit : > > Hello Pascal, > > We have made the requested terminology changes. Please review and let us > know if any further updates are needed (“P-DAO-REQ” was the missing piece! > Ties it all in nicely.). > > 1) How would you like to handle “PDAOReqSequence” - perhaps “PDAOREQSequence”? Pascal > this question s a field not a message name so I do not feel the need to do a change. I’d leave it as is. > > 2) In Table 25, since “P-DAO-REQ" was expanded, we expanded “PDR-ACK”. It is > expanded as "P-DAO Request Acknowledgment (PDR-ACK)” earlier in the text so > we used that, but if you prefer “Projected DAO Request Acknowledgment > (PDR-ACK)”, please let us know (only 2 instances). > Pascal> yes I would prefer with Projected expanded > 3) FYI: We updated the expansion of “P-DAO-ACK” to "Projected DAO > Acknowledgment” (no ‘e’) to match use throughout this document (including > registry names). (However, if you prefer “Acknowledgement” (with an ‘e’) > throughout, we can make that change.) We also added this term to the > glossary. Pascal> I’m good with no e > > 4) In Table 32, should “Projected DAO-ACK (P)” be updated as "P-DAO-ACK (P)” > or “Projected DAO Acknowledgment (P)” for consistency? > Pascal> The latter please, expanded. Many thanks! Pascal > > —Files (please refresh)— > > We will await approvals from each author prior to moving forward in the > publication process. > > Updated XML file: > https://www.rfc-editor.org/authors/rfc9914.xml > > Updated output files: > https://www.rfc-editor.org/authors/rfc9914.txt > https://www.rfc-editor.org/authors/rfc9914.pdf > https://www.rfc-editor.org/authors/rfc9914.html > > Diff files showing all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9914-auth48diff.html > https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side by side) > > Diff files showing only the changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9914-lastdiff.html > https://www.rfc-editor.org/authors/rfc9914-lastrfcdiff.html (side by side) > > Diff files showing all changes: > https://www.rfc-editor.org/authors/rfc9914-diff.html > https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9914 > > Thanks! > > Karen Moore > RFC Production Center > >> On Mar 11, 2026, at 8:57 AM, Pascal Thubert <[email protected]> wrote: >> >> On second (or maybe tenth so sorry) I’d uppercase REQ like ACK so we get >> P-DAO-REQ for the third short name. >> >> Does the make sense? >> >> Pascal >> >>>> Le 11 mars 2026 à 08:34, Pascal Thubert <[email protected]> a écrit >>>> : >>> >>> Hello Karen >>> >>> Many thanks for the PDR-ACK roll back. >>> >>> Please change on first use >>> >>> Projected DAO-ACK to Projected DAO Acknowledgement >>> —- >>> P-DAO Request toProjected DAO Request >>> —- >>> >>> PDAOReq >>> >>> To >>> >>> P-DAO-Req >>> >>> —- >>> >>> I believe we will be all set after that., >>> >>> Again many thanks! >>> >>> Pascal >>> >>>> Le 10 mars 2026 à 22:13, Karen Moore <[email protected]> a écrit >>>> : >>>> >>>> Hello Pascal, >>>> >>>> We went ahead and reverted “PDAOAck” and “PDAORAck” to “PDR-ACK” so we can >>>> start fresh (and we removed these terms from the glossary). We also >>>> updated "0 | PDAOAck request (K)” to "0 | PDAOAck requested (K)” in Table >>>> 27. >>>> >>>> Please confirm how you would like to proceed from here with the >>>> terminology or if you would like to make the last updates, if needed, and >>>> provide an updated XML file to us. >>>> >>>> >>>> —Files (please refresh)— >>>> >>>> We will await approvals from each author prior to moving forward in the >>>> publication process. >>>> >>>> Updated XML file: >>>> https://www.rfc-editor.org/authors/rfc9914.xml >>>> >>>> Updated output files: >>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>> https://www.rfc-editor.org/authors/rfc9914.html >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9914-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side by >>>> side) >>>> >>>> Dif files showing only the changes made during the last edit round: >>>> https://www.rfc-editor.org/authors/rfc9914-lastdiff.html >>>> https://www.rfc-editor.org/authors/rfc9914-lastrfcdiff.html (side by side) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) >>>> >>>> For the AUTH48 status of this document, please see: >>>> https://www.rfc-editor.org/auth48/rfc9914 >>>> >>>> Thank you! >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>>> On Mar 10, 2026, at 10:33 AM, Pascal Thubert <[email protected]> >>>>> wrote: >>>>> >>>>> Hello Karen >>>>> >>>>> We’re certainly getting there. Once so, I guess Michael and I will need a >>>>> complete reread before green-lighting. >>>>> >>>>> Please see below >>>>> >>>>>> Le 10 mars 2026 à 00:57, Karen Moore <[email protected]> a >>>>>> écrit : >>>>>> >>>>>> Hello Pascal, >>>>>> >>>>>> Thank you for working closely with us on the terminology updates. We >>>>>> have attempted to (cautiously) make updates per your guidance. Please >>>>>> review the updated files carefully and let us know if any further >>>>>> changes are needed. >>>>>> >>>>>> We have some additional questions. >>>>>> >>>>>> 1) In Sections 6.4.1 and 6.4.2, we updated "DAO-ACK" to "P-DAO-ACK". >>>>>> Please review and let us know if any further updates are needed. >>>>>> >>>>> >>>>> Pascal > all good >>>>> >>>>> >>>>>> 2) We added the following to the glossary - is this correct? >>>>>> >>>>>> PDAOAck: P-DAO Acknowledgment >>>>>> PDAORAck: P-DAO Request Acknowledgment >>>>> >>>>> Pascal > we have to be consistent in the topic above we are using >>>>> P-DAO-ACK and now it becomes PDAOAck. I believe P-DAO-ACK is more >>>>> consistent with RFC 6550. >>>>> >>>>> For the new messages maybe we should have followed the same logic? Like >>>>> P-DAOR-ACK? >>>>> >>>>> Note that in 5.1 the acknowledgment for P-DAO-REQ has become P-DAOack as >>>>> well which is very wrong. It is a P-DAOR-ACK . >>>>> >>>>> The recent changes have distorted the spec confusing the ack for a P-DAO >>>>> message and the ACK for a “P-DAO request “ message. I believe we need to >>>>> roll back to the version where we used PDR and maybe leave it at that. >>>>> Our tentatives to differentiate from packet delivery ratio created more >>>>> problems than it solved. >>>>> >>>>> >>>>>> 3) In Section 5.2, we updated “PDAOAck” to “PDAORAck”. Please review and >>>>>> let us know if any further updates are needed to the text in other >>>>>> sections (we weren’t sure if changes were only to be made to Section 5.2 >>>>>> and the corresponding IANA registry per your comment). >>>>>> >>>>> >>>>> Pascal > the change is good insofar we retain the acronym. Same as above, >>>>> we need only one version, ideally something in line with RFC 6550 >>>>> >>>>> >>>>>> 4) Are any further changes required to the IANA sections? >>>>>> >>>>>> a) In Section 11.5 ("RPL Control Codes” registry), we updated the >>>>>> following: >>>>>> >>>>>> Old: >>>>>> 0x0A | P-DAO Request Acknowledgement (PDAOAck) >>>>>> >>>>>> Current: >>>>>> 0x0A | P-DAO Request Acknowledgement (PDAORAck) >>>>> >>>>> Pascal > insofar again >>>>> >>>>>> >>>>>> b) Is this description correct in Table 27, or should it be "PDAORAck >>>>>> (K)” >>>>>> >>>>>> Current: >>>>>> 0 | PDAOAck request (K) >>>>> >>>>> Pascal > maybe request -> requested >>>>> >>>>> >>>>> Sorry for the roll back but at the moment the spec is unstable… >>>>> >>>>> All the best >>>>> >>>>> Pascal >>>>>> >>>>>> c) IANA registry names - are these ok as is or should any be updated to >>>>>> “PDAORAck”? >>>>>> >>>>>> Current: >>>>>> "PDAOAck Flags" registry >>>>>> "PDAOAck Acceptance Status Values” registry >>>>>> "PDAOAck Rejection Status Values" registry >>>>>> >>>>>>> Pascal > In fact there’s the pdao message and the pdao request >>>>>>> message .These are 2 different messages. Each has an ack. Those acks >>>>>>> should be named differently. Section 5.2 is about the ack to the pdao >>>>>>> request. So the replacement of PDR ack to pDAOack created a confusion. >>>>>>> I suggest we use PDAO-Request Acknowledgment (PDAORAck) as replacement >>>>>>> to the PDR-ack throughout, meaning in particular in the IANA section >>>>>>> and in 5.2. >>>>>> >>>>>> >>>>>> >>>>>> —Files (please refresh)— >>>>>> >>>>>> We will await approvals from each author prior to moving forward in the >>>>>> publication process. >>>>>> >>>>>> Updated XML file: >>>>>> https://www.rfc-editor.org/authors/rfc9914.xml >>>>>> >>>>>> Updated output files: >>>>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9914.html >>>>>> >>>>>> Diff files showing all changes made during AUTH48: >>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Dif files showing only the changes made during the last edit round: >>>>>> https://www.rfc-editor.org/authors/rfc9914-lastdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9914-lastrfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Diff files showing all changes: >>>>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9914 >>>>>> >>>>>> Thank you! >>>>>> >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>>> On Mar 9, 2026, at 3:06 PM, Pascal Thubert <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> Hello Karen: >>>>>>> >>>>>>> Please see below: >>>>>>> >>>>>>>>> Le 9 mars 2026 à 21:26, Karen Moore <[email protected]> a >>>>>>>>> écrit : >>>>>>>> >>>>>>>> Hi Pascal, >>>>>>>> >>>>>>>> Thanks for your clarifications. We have updated the document >>>>>>>> accordingly. Please note that we have a few more clarifications >>>>>>>> (almost there!). >>>>>>>> >>>>>>>> 1) Should “PDAOAck” be added to the glossary? >>>>>>>> >>>>>>> >>>>>>> Pascal > see below if we’re talking about pdaor-ack >>>>>>> >>>>>>>> 2) We noted one instance of “PDRLifetime” in Section 5.1. Per Figure >>>>>>>> 13, we believe this is intended to be “ReqLifetime” and have updated >>>>>>>> it as such. Please let us know if this is agreeable or incorrect. >>>>>>>> >>>>>>>> Old: >>>>>>>> A PDR with a fresher PDRSequence refreshes the lifetime, and a >>>>>>>> PDRLifetime of 0 indicates that the Track MUST be destroyed, e.g., >>>>>>>> when the application that requested the Track terminates. >>>>>>>> >>>>>>>> New: >>>>>>>> A PDAOReq with a fresher PDAOReq Sequence refreshes the lifetime, and a >>>>>>>> ReqLifetime of 0 indicates that the Track MUST be destroyed, e.g., >>>>>>>> when the application that requested the Track terminates. >>>>>>>> >>>>>>> Pascal > perfect >>>>>>> >>>>>>>> 3) We believe the terms below are different then “PDR” and “PDR-ACK” >>>>>>>> and have left them as is. However, is “DAO-ACK” correct, or should it >>>>>>>> be “P-DAO-ACK” for consistency? Please review. >>>>>>>> >>>>>>>> Projected DAO-ACK (P-DAO-ACK) >>>>>>>> P-DAO-ACK >>>>>>>> P-DAO >>>>>>>> DAO-ACK >>>>>>>> Projected DAO-ACK (P) (IANA) >>>>>>> >>>>>>> In sections 6.4.1 / 6.4.2 the DAO-ACK is really a P-DAO-ACK. It’s >>>>>>> probably better if you can do the change. Note that a P DAO is a DAO >>>>>>> that is being projected as opposed to injected so the text is not >>>>>>> incorrect, just correctible. >>>>>>> >>>>>>>> >>>>>>>> 4) We updated the name of the "PDR-ACK Flags” registry to "PDAOAck >>>>>>>> Flags” registry; however, if you prefer "P-DAO Request Acknowledgment >>>>>>>> (PDAOAck)” registry, please let us know. >>>>>>>> >>>>>>> >>>>>>> Pascal > In fact there’s the pdao message and the pdao request >>>>>>> message .These are 2 different messages. Each has an ack. Those acks >>>>>>> should be named differently. Section 5.2 is about the ack to the pdao >>>>>>> request. So the replacement of PDR ack to pDAOack created a confusion. >>>>>>> I suggest we use PDAO-Request Acknowledgment (PDAORAck) as replacement >>>>>>> to the PDR-ack throughout, meaning in particular in the IANA section >>>>>>> and in 5.2. >>>>>>> >>>>>>> All the best >>>>>>> >>>>>>> Pascal >>>>>>>> >>>>>>>> —Files (please refresh)— >>>>>>>> >>>>>>>> We will await approvals from each author prior to moving forward in >>>>>>>> the publication process. >>>>>>>> >>>>>>>> Updated XML file: >>>>>>>> https://www.rfc-editor.org/authors/rfc9914.xml >>>>>>>> >>>>>>>> Updated output files: >>>>>>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9914.html >>>>>>>> >>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Dif files showing only the changes made during the last edit round: >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-lastdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-lastrfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff files showing all changes: >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by side) >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9914 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Karen Moore >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 6, 2026, at 11:18 PM, Pascal Thubert >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Hello Karen >>>>>>>>> >>>>>>>>> Thanks a million for your deep support on this heavyweight >>>>>>>>> specification! >>>>>>>>> >>>>>>>>> Please see below >>>>>>>>> >>>>>>>>>>> Le 7 mars 2026 à 01:28, Karen Moore <[email protected]> a >>>>>>>>>>> écrit : >>>>>>>>>> >>>>>>>>>> Hi Pascal, >>>>>>>>>> >>>>>>>>>> Thank you for your in-depth review and detailed reply. We have >>>>>>>>>> updated our files accordingly; please review (the files are below). >>>>>>>>>> We also have some clarifications. >>>>>>>>>> >>>>>>>>>> 1) In Section 2.3, we added “DIO” to the glossary. Is the current >>>>>>>>>> ordering okay, or would you like to list the terms in alphabetical >>>>>>>>>> order? >>>>>>>>> >>>>>>>>> Pascal > Please use alphabetical order. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> 2) In Section 2.4.3, we removed the quoted text from RFC 9473 and >>>>>>>>>> removed RFC 9473 from the Informative References section (as it is >>>>>>>>>> not used elsewhere). We updated the text as follows. Please let us >>>>>>>>>> know if this is agreeable or if you prefer otherwise. >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> See Section 3.1.1 of [RAW-ARCH] for a longer, more modern definition >>>>>>>>>> of path. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Perfect >>>>>>>>> >>>>>>>>>> … >>>>>>>>>> 3) We updated the sentences in question to reflect 2 instances of >>>>>>>>>> “MUST” as we think this is clearer, and it matches similar phrasing >>>>>>>>>> in Section 6.4.1. Please let us know of any objections. >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> ... MUST be set to 0 by the sender and MUST be ignored by the >>>>>>>>>> receiver ... >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > OK >>>>>>>>> >>>>>>>>>>> 29) <!--[rfced] We note the following variation - "MUST" occurs >>>>>>>>>>> once in >>>>>>>>>>> the first sentence and twice in the second. May we update the >>>>>>>>>>> latter sentences to reflect two instances of "MUST" for >>>>>>>>>>> consistency and clarity (i.e., update to "MUST be set to 0 by the >>>>>>>>>>> sender and MUST be ignored by the receiver")? >>>>>>>>>>> Original: >>>>>>>>>>> (6 instances) >>>>>>>>>>> ... MUST be set to 0 by the sender and MUST be ignored by the >>>>>>>>>>> receiver ... >>>>>>>>>>> (4 instances) >>>>>>>>>>> ... MUST be set to 0 by the sender and ignored by the receiver ... >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use ‘Perhaps’ >>>>>>>>>> >>>>>>>>>> … >>>>>>>>>> 4) We made “ingress” and “egress” lowercase in the running text. >>>>>>>>>> Note that these terms are capitalized in Figures 7, 18, and 19 (per >>>>>>>>>> the context, we left them as is). If you prefer lowercase in the >>>>>>>>>> figures, please let us know. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Please leave as is >>>>>>>>> >>>>>>>>> >>>>>>>>>> … >>>>>>>>>> 5) Before making these vast changes, we’d like to confirm that each >>>>>>>>>> instance of “Storing Mode” and “Non-Storing Mode” should be preceded >>>>>>>>>> by “RPL” and that “Mode” should be made lowercase. Is that correct? >>>>>>>>>> (Updating these terms in the next edit round should help to make the >>>>>>>>>> diff file review a little easier too.) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Hum all things considered I’m happier if we do not proceed >>>>>>>>> with this broad change. Those modes are specific to RPL so RPL is >>>>>>>>> already implicated there >>>>>>>>> >>>>>>>>> >>>>>>>>>> Would this update be correct: "In a Non-Storing mode RPL domain” -> >>>>>>>>>> "In a RPL Non-Storing mode domain” >>>>>>>>> >>>>>>>>> Pascal > Please leave as is. This would not be quite correct >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> RPL Storing Mode vs. Storing Mode >>>>>>>>>>> Pascal > please use ' RPL Storing Mode " >>>>>>>>>> >>>>>>>>>>> f) Regarding "Non-Storing Mode" vs. "Non-Storing Mode of Operation >>>>>>>>>>> (MOP)" and "Non-Storing MOP", should any of the instances below be >>>>>>>>>>> "Non-Storing Mode" or are they correct as is? >>>>>>>>>>> Pascal > they refer to the same thing. When we speak we say "mode", >>>>>>>>>>> and we mean RPL MOP. Please lowercase "mode" or leave the full MOP >>>>>>>>>>> expanded or not. >>>>>>>>>> >>>>>>>>>> … >>>>>>>>>> 6) Before applying these terminology changes, we would like to >>>>>>>>>> confirm that the following should be updated as shown below. >>>>>>>>>> >>>>>>>>>> a) We will update: >>>>>>>>>> - "P-DAO Request (PDR)” to "P-DAO Request (PDAOReq)” >>>>>>>>>> - all instances of “PDR” to “PDAOReq” >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Yes >>>>>>>>> >>>>>>>>>> - "P-DAO Request Acknowledgement (PDR-ACK)” to >>>>>>>>>> "P-DAO Request Acknowledgement (PDAOAck)” >>>>>>>>>> - all instances of "PDR-ACK" to “PDAOAck” >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Yes please >>>>>>>>> >>>>>>>>>> b) Should these field names be updated as well? Any others we may >>>>>>>>>> have missed? >>>>>>>>>> >>>>>>>>>> PDRSequence -> PDAOReqSequence >>>>>>>>>> PDR-ACK Status -> PDAOAck Status >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Yes please >>>>>>>>> >>>>>>>>>> c) Should all of these IANA-related updates be made? >>>>>>>>>> >>>>>>>>>> Registry names: >>>>>>>>>> "Projected DAO Request (PDR) Flags” registry -> "Projected DAO >>>>>>>>>> Request (PDAOReq) Flags" registry >>>>>>>>>> "PDR-ACK Flags” registry -> >>>>>>>>>> 1) "PDAOAck Flags" registry or 2) "P-DAO Request Acknowledgement >>>>>>>>>> (PDAOAck)" registry >>>>>>>>>> "PDR-ACK Acceptance Status Values” registry -> "PDAOAck Acceptance >>>>>>>>>> Status Values" registry >>>>>>>>>> "PDR-ACK Rejection Status Values” registry -> "PDAOAck Rejection >>>>>>>>>> Status Values" registry >>>>>>>>>> >>>>>>>>>> Values: >>>>>>>>>> 0x09: Projected DAO Request (PDR) -> Projected DAO Request >>>>>>>>>> (PDAOReq) >>>>>>>>>> 0x0A: PDR-ACK -> P-DAO Request Acknowledgement (PDAOAck) >>>>>>>>>> >>>>>>>>>> 0: PDR-ACK request (K) -> PDAOAck request (K) >>>>>>>>>> >>>>>>>>>> Table titles: >>>>>>>>>> Table 24: Initial PDR Flags -> Initial PDAOReq Flags >>>>>>>>>> Table 27: Initial PDR Flags -> Initial PDAOReq Flags >>>>>>>>>> Table 28: Acceptance Values of the PDR-ACK Status -> PDAOAck >>>>>>>>>> Acceptance Status Values >>>>>>>>>> Table 29: PDR-ACK Rejection Status Values -> PDAOAck Rejection >>>>>>>>>> Status Values >>>>>>>>>> >>>>>>>>> >>>>>>>>> Pascal > Yes to all, sorry for not catching the collision earlier! >>>>>>>>> >>>>>>>>> Again many thanks!!! >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> >>>>>>>>>>> e) We note the following inconsistencies with the companion >>>>>>>>>>> document. Please review and let us know if any changes to this >>>>>>>>>>> document are necessary or if these variations are okay. >>>>>>>>>>> "packet delivery ratio (PDR)" (in draft-ietf-raw-architecture-30) >>>>>>>>>>> vs. >>>>>>>>>>> "P-DAO Request (PDR)" (in this document) >>>>>>>>>>> Pascal > I suggest we use PDAOReq and PDAOAck in this spec >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> —Files— >>>>>>>>>> >>>>>>>>>> Note that it may be necessary for you to refresh your browser to >>>>>>>>>> view the most recent version. Please review the document carefully >>>>>>>>>> to ensure satisfaction as we do not make changes once it has been >>>>>>>>>> published as an RFC. >>>>>>>>>> >>>>>>>>>> Please contact us with any further updates or with your approval of >>>>>>>>>> the document in its current form. We will await approvals from each >>>>>>>>>> author prior to moving forward in the publication process. >>>>>>>>>> >>>>>>>>>> Updated XML file: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.xml >>>>>>>>>> >>>>>>>>>> Updated output files: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.html >>>>>>>>>> >>>>>>>>>> Diff files showing all changes made during AUTH48: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-auth48rfcdiff.html (side >>>>>>>>>> by side) >>>>>>>>>> >>>>>>>>>> Diff files showing all changes: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by >>>>>>>>>> side) >>>>>>>>>> >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9914 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Karen Moore >>>>>>>>>> RFC Production Center >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 5, 2026, at 6:18 AM, Pascal Thubert via auth48archive >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Dear Karen, Rebecca, and all: >>>>>>>>>>> Many thanks for this huge piece of work! >>>>>>>>>>> Pascal > Can you please make sure that you align my author snippet >>>>>>>>>>> of that of RFC 9912 ? >>>>>>>>>>> <author initials='P' surname='Thubert' fullname='Pascal Thubert' >>>>>>>>>>> role='editor'> >>>>>>>>>>> <organization>Independent</organization> >>>>>>>>>>> <address> >>>>>>>>>>> <postal> >>>>>>>>>>> <city>Roquefort-les-Pins</city> >>>>>>>>>>> <code>06330</code> >>>>>>>>>>> <country>France</country> >>>>>>>>>>> </postal> >>>>>>>>>>> <email>[email protected]</email> >>>>>>>>>>> </address> >>>>>>>>>>> </author> >>>>>>>>>>> Let's see below: >>>>>>>>>>> Le ven. 27 févr. 2026 à 23:02, <[email protected]> a écrit : >>>>>>>>>>> Authors, >>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>>>> necessary) the following questions, which are also in the source >>>>>>>>>>> file. >>>>>>>>>>> 1) <!--[rfced] Please note that the document title has been updated >>>>>>>>>>> as >>>>>>>>>>> follows. Abbreviations have been expanded per Section 3.6 of RFC >>>>>>>>>>> 7322 ("RFC Style Guide"). Please review. >>>>>>>>>>> The short title that spans the header of the PDF file has also been >>>>>>>>>>> updated to more closely match the document title. Please let us know >>>>>>>>>>> of any objection. >>>>>>>>>>> Original (document title): >>>>>>>>>>> Root-initiated Routing State in RPL >>>>>>>>>>> Current: >>>>>>>>>>> Root-Initiated Routing State in the Routing Protocol for >>>>>>>>>>> Low-Power and Lossy Networks (RPL) >>>>>>>>>>> ... >>>>>>>>>>> Original (short title): >>>>>>>>>>> DAO Projection >>>>>>>>>>> Current: >>>>>>>>>>> Root-Initiated Routing State in RPL >>>>>>>>>>> --> >>>>>>>>>>> Pascal > OK >>>>>>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>>>>>> appear in >>>>>>>>>>> the title) for use on https://www.rfc-editor.org/search. --> >>>>>>>>>>> Pascal > IOT SDN DetNet RAW >>>>>>>>>>> 3) <!-- [rfced] Because this document updates RFCs 6550 and 8138, >>>>>>>>>>> please review the errata reported for RFC 6550 >>>>>>>>>>> (https://www.rfc-editor.org/errata/rfc6550) and RFC 8138 >>>>>>>>>>> (https://www.rfc-editor.org/errata/rfc8138) and let us know >>>>>>>>>>> if you confirm our opinion that none of them are relevant >>>>>>>>>>> to the content of this document. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > I confirm >>>>>>>>>>> 4) <!-- [rfced] We have two questions about the text below. >>>>>>>>>>> First, we believe the intention is to cite RFC 6550 as a >>>>>>>>>>> reference for the term "RPL", so we have updated the text >>>>>>>>>>> accordingly. If that is not correct and you would like to include >>>>>>>>>>> the exact title of RFC 6550 in quote marks instead, please let us >>>>>>>>>>> know. >>>>>>>>>>> Pascal > Good >>>>>>>>>>> Second, would using "as opposed to" rather than "versus" be more >>>>>>>>>>> clear >>>>>>>>>>> in this context? Note that we included parentheses around the phrase >>>>>>>>>>> starting with "versus" to improve readability of this long sentence. >>>>>>>>>>> Original: >>>>>>>>>>> RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] >>>>>>>>>>> (LLNs), is a Distance Vector protocol, which is well-suited for >>>>>>>>>>> application in a variety of low energy Internet of Things (IoT) >>>>>>>>>>> networks where constrained nodes cannot maintain the full view of >>>>>>>>>>> the >>>>>>>>>>> topology, and stretched P2P paths are acceptable vs. the signaling >>>>>>>>>>> and state overhead involved in maintaining the shortest paths >>>>>>>>>>> across. >>>>>>>>>>> Current: >>>>>>>>>>> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >>>>>>>>>>> is a Distance Vector protocol that is well-suited for application >>>>>>>>>>> in a variety of low-energy Internet of Things (IoT) networks where >>>>>>>>>>> constrained nodes cannot maintain the full view of the topology >>>>>>>>>>> and stretched P2P paths are acceptable (versus the signaling and >>>>>>>>>>> state overhead involved in maintaining the shortest paths across). >>>>>>>>>>> Perhaps: >>>>>>>>>>> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >>>>>>>>>>> is a Distance Vector protocol that is well-suited for application >>>>>>>>>>> in a variety of low-energy Internet of Things (IoT) networks where >>>>>>>>>>> constrained nodes cannot maintain the full view of the topology >>>>>>>>>>> and stretched P2P paths are acceptable (as opposed to the signaling >>>>>>>>>>> and >>>>>>>>>>> state overhead involved in maintaining the shortest paths across). >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 5) <!-- [rfced] Section 2.2 is titled "References". This may cause >>>>>>>>>>> confusion with Section 13, which is also titled "References". >>>>>>>>>>> Would you like to title Section 2.2 as "Terms and Concepts" or >>>>>>>>>>> other for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> 2.2 References >>>>>>>>>>> Perhaps: >>>>>>>>>>> 2.2 Terms and Concepts >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 6) <!-- [rfced] To improve readability, may we update this text to >>>>>>>>>>> be an >>>>>>>>>>> unordered list? >>>>>>>>>>> Original: >>>>>>>>>>> In this document, readers will encounter terms and concepts that are >>>>>>>>>>> discussed in the "Routing Protocol for Low Power and Lossy Networks" >>>>>>>>>>> [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic >>>>>>>>>>> Networking Architecture" [RFC8655], the "Using RPI Option Type, >>>>>>>>>>> Routing Header for Source Routes, and IP-in-IP Encapsulation in the >>>>>>>>>>> RPL Data Plane" [RFC9008], the "Reliable and Available Wireless >>>>>>>>>>> (RAW) >>>>>>>>>>> Architecture" [RAW-ARCHI], and "Terminology in Low power And Lossy >>>>>>>>>>> Networks" [RFC7102]. >>>>>>>>>>> Perhaps: >>>>>>>>>>> In this document, readers will encounter terms and concepts that are >>>>>>>>>>> discussed in the following: >>>>>>>>>>> * "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" >>>>>>>>>>> [RPL] >>>>>>>>>>> * "An Architecture for IPv6 over the Time-Slotted Channel Hopping >>>>>>>>>>> Mode >>>>>>>>>>> of IEEE 802.15.4 (6TiSCH)" [RFC9030] >>>>>>>>>>> * "Deterministic Networking Architecture" [RFC8655] >>>>>>>>>>> * "Using RPI Option Type, Routing Header for Source Routes, and >>>>>>>>>>> IPv6-in-IPv6 >>>>>>>>>>> Encapsulation in the RPL Data Plane" [RFC9008] >>>>>>>>>>> * "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH] >>>>>>>>>>> * "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102] >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 7) <!-- [rfced] Please clarify "to take the routing decision". Is >>>>>>>>>>> the >>>>>>>>>>> intended meaning "in order to make the routing decision"? >>>>>>>>>>> Original: >>>>>>>>>>> This requires additional control to take the routing decision >>>>>>>>>>> early enough along the Track to route around the failure. >>>>>>>>>>> Perhaps: >>>>>>>>>>> This requires additional control in order to make the routing >>>>>>>>>>> decision early enough along the Track to route around the >>>>>>>>>>> failure. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 8) <!--[rfced] Questions related to the Glossary >>>>>>>>>>> a) Should "DIO" be included in this glossary since SIO, TIO, and >>>>>>>>>>> VIO are >>>>>>>>>>> listed? >>>>>>>>>>> Pascal > yes >>>>>>>>>>> b) FYI: We updated the expansions/descriptions of "NSM-VIO" and >>>>>>>>>>> "SM-VIO" for consistency with the other entries (i.e., expansion >>>>>>>>>>> first >>>>>>>>>>> and then the description). Please let us know of any objection. >>>>>>>>>>> Pascal > Good >>>>>>>>>>> Also, is "Strict" VIO" correct, or should it be "Stateful VIO" per >>>>>>>>>>> Table 26? >>>>>>>>>>> Original: >>>>>>>>>>> NSM-VIO: A Source-Routed Via Information Option, used in >>>>>>>>>>> Non-Storing Mode >>>>>>>>>>> P-DAO messages >>>>>>>>>>> SM-VIO: A strict Via Information Option, used in Storing Mode >>>>>>>>>>> P-DAO messages >>>>>>>>>>> Current: >>>>>>>>>>> NSM-VIO: Non-Storing Mode Via Information Option. Source-routed >>>>>>>>>>> VIO used in Non-Storing Mode P-DAO messages. >>>>>>>>>>> SM-VIO: Storing Mode Via Information Option. Strict VIO used >>>>>>>>>>> in Storing Mode P-DAO messages. >>>>>>>>>>> Pascal > Both strict and stateful are correct. please leave as is >>>>>>>>>>> c) FYI: For consistency, we removed a few instances of "RPL" and >>>>>>>>>>> "IPv6" as they >>>>>>>>>>> were not a part of the expansions. >>>>>>>>>>> Pascal > OK >>>>>>>>>>> --> >>>>>>>>>>> 9) <!-- [rfced] Section 2.4.3. The definition of "path" has changed >>>>>>>>>>> since >>>>>>>>>>> [I-D.irtf-panrg-path-properties] was published as RFC 9473. See >>>>>>>>>>> Section 2 >>>>>>>>>>> of RFC 9473 >>>>>>>>>>> (https://www.rfc-editor.org/rfc/rfc9473.html#name-terminology) >>>>>>>>>>> and let us know if we may update this document to match RFC 9473. >>>>>>>>>>> Pascal > Please replace by a reference to RFC 9912: Reliable and >>>>>>>>>>> Available Wireless (RAW) Architecture section 3.3.1 since we appear >>>>>>>>>>> to duplicate the definition text >>>>>>>>>>> Current: >>>>>>>>>>> Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, >>>>>>>>>>> more modern definition of path, which begins as follows: >>>>>>>>>>> | A sequence of adjacent path elements over which a packet can be >>>>>>>>>>> | transmitted, starting and ending with a node. A path is >>>>>>>>>>> | unidirectional. Paths are time-dependent, i.e., the sequence of >>>>>>>>>>> | path elements over which packets are sent from one node to >>>>>>>>>>> another >>>>>>>>>>> | may change. A path is defined between two nodes. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Section 2 of [RFC9473] points to a longer, more modern definition of >>>>>>>>>>> path: >>>>>>>>>>> | A sequence of adjacent path elements over which a packet can >>>>>>>>>>> | be transmitted, starting and ending with a node. >>>>>>>>>>> | >>>>>>>>>>> | Paths are unidirectional and time dependent, i.e., there can be a >>>>>>>>>>> | variety of paths from one node to another, and the path over >>>>>>>>>>> which >>>>>>>>>>> | packets are transmitted may change. A path definition can be >>>>>>>>>>> | strict (i.e., the exact sequence of path elements remains the >>>>>>>>>>> | same) or loose (i.e., the start and end node remain the same, but >>>>>>>>>>> | the path elements between them may vary over time). >>>>>>>>>>> --> >>>>>>>>>>> 10) <!--[rfced] We are having trouble parsing this sentence. Should >>>>>>>>>>> "and" >>>>>>>>>>> be "versus" (i.e., the RPL does not behave the same way "downwards" >>>>>>>>>>> versus "upwards")? If not, please let us know how we may update for >>>>>>>>>>> clarity. >>>>>>>>>>> Original: >>>>>>>>>>> RPL does not behave the same way "downwards" (root towards >>>>>>>>>>> leaves) with _multicast_ DIO messages that form the DODAG and >>>>>>>>>>> "upwards" (leaves towards root) with _unicast_ DAO messages that >>>>>>>>>>> follow the DODAG. >>>>>>>>>>> Perhaps: >>>>>>>>>>> RPL does not behave the same way "downwards" (root towards leaves) >>>>>>>>>>> with _multicast_ DODAG Information Object (DIO) messages that form >>>>>>>>>>> the DODAG versus "upwards" (leaves towards root) with _unicast_ DAO >>>>>>>>>>> messages that follow the DODAG. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 11) <!--[rfced] FYI: For Figure 1, we moved the information about >>>>>>>>>>> the >>>>>>>>>>> segments and paths out of the figure. Please review and let us >>>>>>>>>>> know any concerns. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > good >>>>>>>>>>> 12) <!-- [rfced] How may we clarify what "and" is connecting in >>>>>>>>>>> this sentence? >>>>>>>>>>> Original: >>>>>>>>>>> To reach this goal, RPL is primarily designed to minimize the >>>>>>>>>>> control >>>>>>>>>>> plane activity, that is the relative amount of routing protocol >>>>>>>>>>> exchanges vs. data traffic, and the amount of state that is >>>>>>>>>>> maintained in each node. >>>>>>>>>>> Perhaps A: >>>>>>>>>>> To reach this goal, RPL is primarily designed to minimize the >>>>>>>>>>> control >>>>>>>>>>> plane activity (i.e., the relative amount of routing protocol >>>>>>>>>>> exchanges versus data traffic) and the amount of state that is >>>>>>>>>>> maintained in each node. >>>>>>>>>>> or >>>>>>>>>>> Perhaps B: >>>>>>>>>>> To reach this goal, RPL is primarily designed to minimize the >>>>>>>>>>> control >>>>>>>>>>> plane activity (i.e., the relative amount of routing protocol >>>>>>>>>>> exchanges versus data traffic and the amount of state that is >>>>>>>>>>> maintained in each node). >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps A' >>>>>>>>>>> 13) <!--[rfced] Does "upon traffic" mean "upon receiving traffic"? >>>>>>>>>>> Current: >>>>>>>>>>> The maintenance is lazy, either reactive upon traffic or as >>>>>>>>>>> slow background process. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The maintenance is lazy; it is either reactive upon receiving >>>>>>>>>>> traffic or a slow background process. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps' >>>>>>>>>>> 14) <!--[rfced] Does "join the dots" mean "connect" in these >>>>>>>>>>> sentences? In >>>>>>>>>>> the second sentence, are Storing Mode P-Routes deployed to >>>>>>>>>>> connect segments to the Track Instance? >>>>>>>>>>> Original: >>>>>>>>>>> In the simplest mode of this specification, Storing-Mode P-Routes >>>>>>>>>>> can be deployed to join the dots of a loose source routing header >>>>>>>>>>> (SRH) in the main DODAG. >>>>>>>>>>> Perhaps: >>>>>>>>>>> In the simplest mode of this specification, Storing Mode P-Routes >>>>>>>>>>> can be deployed to connect a loose SRH in the main DODAG. >>>>>>>>>>> ... >>>>>>>>>>> Original: >>>>>>>>>>> As for the main DODAG, segments associated to the Track >>>>>>>>>>> Instance may be deployed to join the dots using Storing-Mode >>>>>>>>>>> P-Routes. >>>>>>>>>>> Perhaps: >>>>>>>>>>> As for the main DODAG, Storing Mode P-Routes may be deployed to >>>>>>>>>>> connect segments to the Track Instance. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > "join the dots of" means "complete the path between". >>>>>>>>>>> Original: >>>>>>>>>>> In the simplest mode of this specification, Storing-Mode P-Routes >>>>>>>>>>> can be deployed to join the dots of a loose source routing header >>>>>>>>>>> (SRH) in the main DODAG. >>>>>>>>>>> Proposed: >>>>>>>>>>> In the simplest mode of this specification, Storing-Mode P-Routes >>>>>>>>>>> can be deployed to complete the path between the hops described in >>>>>>>>>>> the loose source routing header >>>>>>>>>>> (SRH) in the main DODAG. >>>>>>>>>>> ... >>>>>>>>>>> Original: >>>>>>>>>>> As for the main DODAG, segments associated to the Track >>>>>>>>>>> Instance may be deployed to join the dots using Storing-Mode >>>>>>>>>>> P-Routes. >>>>>>>>>>> Proposed: >>>>>>>>>>> As for the main DODAG, segments associated to the Track >>>>>>>>>>> Instance may be deployed to establish the complete path between >>>>>>>>>>> loose Source-Routing hops using segments expressed as Storing-Mode >>>>>>>>>>> P-Routes. >>>>>>>>>>> 15) <!-- [rfced] Should "The first and strict order" and "The >>>>>>>>>>> second strict and >>>>>>>>>>> partial order" be updated as follows to "The first strict order" >>>>>>>>>>> and "The >>>>>>>>>>> second strict order", respectively? >>>>>>>>>>> Original: >>>>>>>>>>> The first and strict order relates to the forwarding method and the >>>>>>>>>>> more specifically the origin of the information used in the next-hop >>>>>>>>>>> computation. >>>>>>>>>>> ... >>>>>>>>>>> The second strict and partial order is between RPL Instances. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The first strict order relates to the forwarding method and, more >>>>>>>>>>> specifically, the origin of the information used in the next-hop >>>>>>>>>>> computation. >>>>>>>>>>> ... >>>>>>>>>>> The second strict order is between RPL Instances. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please retain the original text for the second. Strict >>>>>>>>>>> means < as opposed to <= . Partial means that not all are compared. >>>>>>>>>>> Proposed: >>>>>>>>>>> The first order is strict and complete, and relates to the >>>>>>>>>>> forwarding method and, more >>>>>>>>>>> specifically, the origin of the information used in the next-hop >>>>>>>>>>> computation. >>>>>>>>>>> ... >>>>>>>>>>> The second order is strict and partial, and applies between RPL >>>>>>>>>>> Instances. >>>>>>>>>>> 16) <!--[rfced] We are having trouble parsing this sentence. Please >>>>>>>>>>> clarify what defines a DODAG of underlays with the main Instance >>>>>>>>>>> as the Root. >>>>>>>>>>> Original: >>>>>>>>>>> That order must be defined by the administrator for the RPL domain >>>>>>>>>>> and defines a DODAG of underlays with the main Instance as Root. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > >>>>>>>>>>> Proposed: >>>>>>>>>>> That order must be defined by the administrator for the RPL domain >>>>>>>>>>> and defines a DODAG of underlay RPL instances with the main >>>>>>>>>>> Instance as Root. >>>>>>>>>>> 17) <!--[rfced] Please clarify what "it" refers to in "When it is >>>>>>>>>>> not >>>>>>>>>>> communicated". >>>>>>>>>>> Original: >>>>>>>>>>> When it is not communicated, the RPL nodes consider by default >>>>>>>>>>> that all Track instances are children of the main instance, and >>>>>>>>>>> they do not attempt to validate the order for nested Tracks, >>>>>>>>>>> trusting the PCE implicitly. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > "it" refers to "the DODAG of underlay instances", which is >>>>>>>>>>> optionally provided >>>>>>>>>>> Proposed: >>>>>>>>>>> When the DODAG of underlay instances is not provided, the RPL nodes >>>>>>>>>>> consider by default >>>>>>>>>>> that all Track instances are children of the main instance, and >>>>>>>>>>> they do not attempt to validate the order for nested Tracks, >>>>>>>>>>> trusting the PCE implicitly. >>>>>>>>>>> 18) <!-- [rfced] Is "coma-" here is correct? Should this be updated >>>>>>>>>>> to "comma-" or >>>>>>>>>>> something else? >>>>>>>>>>> Original: >>>>>>>>>>> We use "-to-", such as in C==>D==>E-to-F to represent >>>>>>>>>>> coma-separated Targets, e.g., F is a Target for segment C==>D==>E. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use "comma-" >>>>>>>>>>> 19) <!--[rfced] We note that several of the tables have the same >>>>>>>>>>> title; >>>>>>>>>>> will this be confusing for readers? For instance, Tables 3, 6, 9, >>>>>>>>>>> 15, 18, 19, and 20 are all titled "Packet Header Settings". >>>>>>>>>>> Would you like to make these titles more descriptive like Table >>>>>>>>>>> 12, which is titled "Packet Header Settings Between C and E"? If >>>>>>>>>>> so, please provide the wording. If not, should the title of Table 12 >>>>>>>>>>> be updated for consistency with the other titles (i.e., update >>>>>>>>>>> as "Packet Header Settings")? >>>>>>>>>>> Note that Tables 2, 5, 8, 11, 14, and 17 are all titled "RIB >>>>>>>>>>> Settings", >>>>>>>>>>> and Tables 1, 4, 7, 10, 13, and 16 are all titled "P-DAO Messages". >>>>>>>>>>> --> >>>>>>>>>>> Pascal > I'd leave as is. Michael ? >>>>>>>>>>> 20) <!--[rfced] Please clarify the meaning of "participates to" in >>>>>>>>>>> the >>>>>>>>>>> following sentence. >>>>>>>>>>> Current: >>>>>>>>>>> Two protection paths of the same Track may cross at a common node >>>>>>>>>>> that participates to a segment of each protection path or that >>>>>>>>>>> may be joined by additional segments. >>>>>>>>>>> --> >>>>>>>>>>> Pascal> >>>>>>>>>>> Proposed: >>>>>>>>>>> Two protection paths of the same Track may cross at a common node >>>>>>>>>>> that is a member of a segment of each protection path or >>>>>>>>>>> may be joined by additional segments. >>>>>>>>>>> 21) <!--[rfced] The following text is difficult to read. May we add >>>>>>>>>>> parentheses as shown below for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> Note that while this specification enables building both segments >>>>>>>>>>> inside a protection path, for instance segment 2 above which is >>>>>>>>>>> within protection path 1, and Inter-protection-path segments (i.e., >>>>>>>>>>> North-South), for instance segment 5 above which joins protection >>>>>>>>>>> path 1 and protection path 2, it does not signal to the Ingress >>>>>>>>>>> which >>>>>>>>>>> Inter-protection-path segments are available, so the use of North- >>>>>>>>>>> South segments and associated path redundancy functions is currently >>>>>>>>>>> limited. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Note that while this specification enables building both segments >>>>>>>>>>> inside a protection path, for instance, segment 2 above (which is >>>>>>>>>>> within protection path 1) and Inter-protection-path segments (i.e., >>>>>>>>>>> North-South) such as segment 5 above (which joins protection paths >>>>>>>>>>> 1 and 2), it does not signal which Inter-protection-path segments >>>>>>>>>>> are available to the Ingress, so the use of North-South segments >>>>>>>>>>> and associated path redundancy functions is currently limited. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > yes please >>>>>>>>>>> 22) <!-- [rfced] Please clarify this section title. We are unsure >>>>>>>>>>> what >>>>>>>>>>> "Positioning" refers to. In addition, not all of the RFCs mentioned >>>>>>>>>>> in >>>>>>>>>>> the section are Standards Track documents, so another term like >>>>>>>>>>> "Specifications" is more accurate. >>>>>>>>>>> Original: >>>>>>>>>>> 3.7.2. Positioning vs. Related IETF Standards >>>>>>>>>>> Perhaps A: >>>>>>>>>>> 3.7.2. Related IETF Specifications >>>>>>>>>>> or >>>>>>>>>>> Perhaps B: >>>>>>>>>>> 3.7.2. Relationship to Other IETF Specifications >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'perhaps B' >>>>>>>>>>> 23) <!--[rfced] Does "In that case" refer to when the PCE is >>>>>>>>>>> collocated >>>>>>>>>>> with the Root or when it resides in an external controller? What >>>>>>>>>>> does "one possibility" refer to? >>>>>>>>>>> Original: >>>>>>>>>>> The PCE may be collocated with the Root, or may reside in an >>>>>>>>>>> external Controller. In that case, the protocol between the Root >>>>>>>>>>> and the PCE is out of scope and mapped to RPL inside the DODAG; one >>>>>>>>>>> possibility is for the Root to transmit to the PCEs the information >>>>>>>>>>> it received in RPL DAOs including all the SIOs that detail the >>>>>>>>>>> parent/child and sibling information. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > the latter case, external. "One possibility" means "One >>>>>>>>>>> possible control protocol between the root and the external PCE" >>>>>>>>>>> 24) <!--[rfced] May we revise this text to be two sentences to >>>>>>>>>>> improve >>>>>>>>>>> readability? >>>>>>>>>>> Original: >>>>>>>>>>> The RAW Architecture [RAW-ARCHI] extends the definition of Track, >>>>>>>>>>> as being composed of forward directional segments and North-South >>>>>>>>>>> bidirectional segments, to enable additional path diversity, using >>>>>>>>>>> Packet ARQ, Replication, Elimination, and Overhearing (PAREO) >>>>>>>>>>> functions over the available paths, to provide a dynamic balance >>>>>>>>>>> between the reliability and availability requirements of the flows >>>>>>>>>>> and the need to conserve energy and spectrum. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The RAW architecture [RAW-ARCH] extends the definition of Track as >>>>>>>>>>> being composed of forward directional segments and North-South >>>>>>>>>>> bidirectional segments to enable additional path diversity using >>>>>>>>>>> PAREO functions over the available paths. This provides a dynamic >>>>>>>>>>> balance between the reliability and availability requirements of >>>>>>>>>>> the flows and the need to conserve energy and spectrum. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > We finally abandoned the term PAREO in RFC 9912. Please >>>>>>>>>>> use PREOF instead. and replace references to PAREO The text above >>>>>>>>>>> becomes: >>>>>>>>>>> " >>>>>>>>>>> The RAW architecture [RAW-ARCH] extends the definition of Track as >>>>>>>>>>> being composed of forward directional segments and North-South >>>>>>>>>>> bidirectional segments to enable additional path diversity using >>>>>>>>>>> PREOF functions over the available paths. This provides a dynamic >>>>>>>>>>> balance between the reliability and availability requirements of >>>>>>>>>>> the flows and the need to conserve energy and spectrum. >>>>>>>>>>> " >>>>>>>>>>> 25) <!-- [rfced] Should the title of this section include >>>>>>>>>>> "Amending" as the >>>>>>>>>>> section discusses how this document both "Extends" and "Amends"? Or >>>>>>>>>>> is >>>>>>>>>>> the current okay? >>>>>>>>>>> Current >>>>>>>>>>> 4. Extending Existing RFCs >>>>>>>>>>> Perhaps: >>>>>>>>>>> 4. Extending and Amending Existing RFCs >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 26) <!--[rfced] Is "participate" the intended word or would >>>>>>>>>>> "function" be >>>>>>>>>>> clearer/correct? >>>>>>>>>>> Original: >>>>>>>>>>> Those 6LRs will be unable to participate in the new mechanisms, >>>>>>>>>>> but may also cause projected DAOs to be impossible to install. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Those 6LRs will be unable to function in the new mechanisms >>>>>>>>>>> and may also make the P-DAOs impossible to install. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 27) <!--[rfced] The titles of Sections 4.1, 4.2, and 4.3 do not >>>>>>>>>>> parse. How >>>>>>>>>>> may we update this for clarity? Is "RPL" necessary to include? >>>>>>>>>>> Original: >>>>>>>>>>> 4.1. Extending RPL RFC 6550 >>>>>>>>>>> 4.2 Extending RPL RFC 6553 >>>>>>>>>>> 4.3 Extending RPL RFC 8138 >>>>>>>>>>> Perhaps: >>>>>>>>>>> 4.1. Extending RFC 6550 >>>>>>>>>>> 4.2 Extending RFC 6553 >>>>>>>>>>> 4.3 Extending RFC 8138 >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 28) <!--[rfced] Does "it" refer to the DAO? If so, may we rephrase >>>>>>>>>>> the >>>>>>>>>>> text as shown below for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> The P-DAO message generalizes the DAO to signal to the Track >>>>>>>>>>> Ingress that a Track for which it is the Root can be used to >>>>>>>>>>> reach children and siblings of the Track Egress. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The P-DAO message generalizes the DAO to signal the Track Ingress >>>>>>>>>>> that a track, for which the DAO is the root, can be used to reach >>>>>>>>>>> children and siblings of the Track Egress. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use: >>>>>>>>>>> " >>>>>>>>>>> The P-DAO message generalizes the DAO to signal the Track Ingress >>>>>>>>>>> that a track, for which the sender is the root, can be used to reach >>>>>>>>>>> children and siblings of the Track Egress. >>>>>>>>>>> " >>>>>>>>>>> 29) <!--[rfced] We note the following variation - "MUST" occurs >>>>>>>>>>> once in >>>>>>>>>>> the first sentence and twice in the second. May we update the >>>>>>>>>>> latter sentences to reflect two instances of "MUST" for >>>>>>>>>>> consistency and clarity (i.e., update to "MUST be set to 0 by the >>>>>>>>>>> sender and MUST be ignored by the receiver")? >>>>>>>>>>> Original: >>>>>>>>>>> (6 instances) >>>>>>>>>>> ... MUST be set to 0 by the sender and MUST be ignored by the >>>>>>>>>>> receiver ... >>>>>>>>>>> (4 instances) >>>>>>>>>>> ... MUST be set to 0 by the sender and ignored by the receiver ... >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 30) <!--[rfced] FYI: We updated this sentence for clarity. Please >>>>>>>>>>> let us >>>>>>>>>>> know of any objection. >>>>>>>>>>> Original: >>>>>>>>>>> The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it is >>>>>>>>>>> ready >>>>>>>>>>> to be placed as is in the packet encapsulation by the Track Ingress. >>>>>>>>>>> Perhaps: >>>>>>>>>>> When the SRH-6LoRH is signaled in the NSM-VIO, it is ready to be >>>>>>>>>>> placed as is in the packet encapsulation by the Track Ingress. >>>>>>>>>>> --> >>>>>>>>>>> Pascal: When is already present at the beginning of the paragraph . >>>>>>>>>>> Please use >>>>>>>>>>> " >>>>>>>>>>> In that case, the SRH-6LoRH is signaled in the NSM-VIO, and it is >>>>>>>>>>> expressed in a fashion that can be placed as is in the packet >>>>>>>>>>> encapsulation by the Track Ingress. >>>>>>>>>>> " >>>>>>>>>>> 31) <!--[rfced] FYI: We updated "Type" to "6LoRH Type" in Section >>>>>>>>>>> 4.3 to match the >>>>>>>>>>> name of the field in Figure 12. Please let us know if that is >>>>>>>>>>> incorrect. >>>>>>>>>>> Original: >>>>>>>>>>> Type: IANA is requested to define the same value of the type for >>>>>>>>>>> both Elective and Critical forms. A type of 8 is suggested. >>>>>>>>>>> Current: >>>>>>>>>>> 6LoRH Type: IANA has defined the value 8 >>>>>>>>>>> for both the Elective and Critical forms. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 32) <!--[rfced] Please clarify "sets up the new information" in >>>>>>>>>>> this sentence. >>>>>>>>>>> Original: >>>>>>>>>>> The segment information indicated in the VIO deprecates any state >>>>>>>>>>> for the segment indicated by the P-RouteID within the indicated >>>>>>>>>>> Track and sets up the new information. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please replace >>>>>>>>>>> OLD >>>>>>>>>>> ' sets up the new information ' >>>>>>>>>>> with >>>>>>>>>>> NEW >>>>>>>>>>> ' provides the new information about the segment ' >>>>>>>>>>> 33) <!--[rfced] Is "so the routing can consider" the intending >>>>>>>>>>> wording >>>>>>>>>>> or would one of the following suggestions be more clear? >>>>>>>>>>> Original: >>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance can >>>>>>>>>>> be >>>>>>>>>>> expected in both directions, so the routing can consider that the >>>>>>>>>>> information provided for one direction is valid for both. >>>>>>>>>>> Perhaps A: >>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance can >>>>>>>>>>> be expected in both directions, so the routing can identify that >>>>>>>>>>> the information provided for one direction is valid for both. >>>>>>>>>>> or >>>>>>>>>>> Perhaps B: >>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance can >>>>>>>>>>> be expected in both directions; this flag indicates to the routing >>>>>>>>>>> that >>>>>>>>>>> the information provided for one direction is valid for both. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>> 34) <!--[rfced] We note "Type" in Figure 17 but "Option Type" in the >>>>>>>>>>> corresponding description in the running text. Should Figure 17 >>>>>>>>>>> be updated to reflect "Option Type" for consistency with the >>>>>>>>>>> running text? >>>>>>>>>>> Current: >>>>>>>>>>> 0 1 2 3 >>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> | Type | Option Length |S|B|Flags|Comp.| Opaque | >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> Option Type: 0x11 for SIO (see Table 26). >>>>>>>>>>> Perhaps: >>>>>>>>>>> 0 1 2 3 >>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> | Option Type | Option Length |S|B|Flags|Comp.| Opaque | >>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>> Option Type: 0x11 for SIO (see Table 26). >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 35) <!--[rfced] Should "MUST" be added to the latter part of this >>>>>>>>>>> sentence >>>>>>>>>>> (e.g., a P-DAO "MUST signal the full list of hops")? This would >>>>>>>>>>> make it parallel with the first part of the sentence. >>>>>>>>>>> Original: >>>>>>>>>>> A P-DAO that creates a new Track segment MUST be sent to a GUA or a >>>>>>>>>>> ULA of the segment Egress and MUST signal the full list of hops in >>>>>>>>>>> segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>> and >>>>>>>>>>> signal the full list of hops in the section starting at the node >>>>>>>>>>> that >>>>>>>>>>> immediately precedes the modified section. >>>>>>>>>>> Perhaps: >>>>>>>>>>> A P-DAO that creates a new Track segment MUST be sent to a GUA or a >>>>>>>>>>> ULA of the segment Egress and MUST signal the full list of hops in >>>>>>>>>>> a segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>> and >>>>>>>>>>> MUST signal the full list of hops in the section starting at the >>>>>>>>>>> node >>>>>>>>>>> that immediately precedes the modified section. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > earlier you eliminated the second MUST making it a common >>>>>>>>>>> factor. Following that logic you could do: >>>>>>>>>>> " A P-DAO that creates a new Track segment MUST be sent to a GUA >>>>>>>>>>> or a >>>>>>>>>>> ULA of the segment Egress and signal the full list of hops in >>>>>>>>>>> segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>> and >>>>>>>>>>> signal the full list of hops in the section starting at the node >>>>>>>>>>> that >>>>>>>>>>> immediately precedes the modified section >>>>>>>>>>> " >>>>>>>>>>> Either that or 'Perhaps' work for me. >>>>>>>>>>> 36) <!-- [rfced] Figure 19 contains the non-ASCII character "°". Is >>>>>>>>>>> this >>>>>>>>>>> intentional/significant? Or should it be updated to "o", which is >>>>>>>>>>> used in >>>>>>>>>>> the rest of the figure? >>>>>>>>>>> --> >>>>>>>>>>> Pascal > it is not significant. It is just for visualization to >>>>>>>>>>> show different devices. Your call on this. >>>>>>>>>>> 37) <!--[rfced] Is "and results in" the intended wording here, or >>>>>>>>>>> may we >>>>>>>>>>> revise the sentence as shown below and use "Its function" instead >>>>>>>>>>> for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and >>>>>>>>>>> results in >>>>>>>>>>> cleaning up existing state as opposed to refreshing an existing one >>>>>>>>>>> or >>>>>>>>>>> installing a new one. >>>>>>>>>>> Perhaps: >>>>>>>>>>> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its >>>>>>>>>>> function is to clean up an existing state as opposed to refreshing >>>>>>>>>>> it >>>>>>>>>>> or installing a new one. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 38) <!--[rfced] In Section 6.7, we rephrased the second bullet >>>>>>>>>>> point in >>>>>>>>>>> order to connect it more clearly to the lead-in sentence. Please >>>>>>>>>>> let us know if the update is agreeable or if you prefer otherwise. >>>>>>>>>>> Original: >>>>>>>>>>> * The preferred alternative in a network where 6LoWPAN Header >>>>>>>>>>> Compression [RFC6282] is used is to leverage "IPv6 over Low-Power >>>>>>>>>>> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >>>>>>>>>>> [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. >>>>>>>>>>> Current: >>>>>>>>>>> * To compress RPL artifacts in data packets as indicated in >>>>>>>>>>> [RFC8138], the preferred alternative in a network where 6LoWPAN >>>>>>>>>>> header compression [RFC6282] is used is to implement the method >>>>>>>>>>> described in "IPv6 over Low-Power Wireless Personal Area Network >>>>>>>>>>> (6LoWPAN) Paging Dispatch" [RFC8025]. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > Please retain the original. Or a mix like >>>>>>>>>>> " >>>>>>>>>>> * In a network where 6LoWPAN Header Compression [RFC6282] is in use, >>>>>>>>>>> it is preferred to implement "IPv6 over Low-Power >>>>>>>>>>> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >>>>>>>>>>> [RFC8025] and compress the RPL artifacts as indicated in [RFC8138]. >>>>>>>>>>> " >>>>>>>>>>> 39) <!--[rfced] May we update this sentence as shown below for >>>>>>>>>>> clarity and >>>>>>>>>>> easier readability? >>>>>>>>>>> Original: >>>>>>>>>>> The packet processing uses a precedence that favors self delivery >>>>>>>>>>> or routing header handling when one is present, then delivery to >>>>>>>>>>> direct neighbors, then to indirect neighbors, then routing along a >>>>>>>>>>> segment along the Track, and finally as a last resort injecting the >>>>>>>>>>> packet in another Track. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Packet processing uses the following precedence: 1) self-delivery >>>>>>>>>>> or routing header handling when one is present, 2) delivery to >>>>>>>>>>> direct neighbors, 3) delivery to indirect neighbors, 4) routing >>>>>>>>>>> along a segment along the Track, and 5) injecting the packet in >>>>>>>>>>> another Track, as a last resort. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 40) <!-- [rfced] Will "either of the reasons above" be clear to >>>>>>>>>>> readers? Does this >>>>>>>>>>> mean "in any of the steps above"? >>>>>>>>>>> Original: >>>>>>>>>>> The node that drops a packet for either of the reasons above MUST >>>>>>>>>>> send an ICMPv6 Error message [RFC4443] to the Root, with a new Code >>>>>>>>>>> "Error in P-Route" (See Section 11.15). >>>>>>>>>>> Perhaps: >>>>>>>>>>> The node that drops a packet in any of the steps above MUST >>>>>>>>>>> send an ICMPv6 Error message [RFC4443] to the Root, with a new Code >>>>>>>>>>> "Error in P-Route" (See Section 11.15). >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 41) <!--[rfced] May we revise this text into two sentences for >>>>>>>>>>> easier >>>>>>>>>>> readability and update "remove the leftover" to "the Root can >>>>>>>>>>> remove the leftover" for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>> Tracks, and in the case of a broken segment, remove the leftover >>>>>>>>>>> sections of the segment using SM-VIOs with a lifetime of 0 >>>>>>>>>>> indicating the section to one or more nodes being removed (See >>>>>>>>>>> Section 6.6). >>>>>>>>>>> Perhaps: >>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>> Tracks. In the case of a broken segment, the Root can remove the >>>>>>>>>>> leftover sections of the segment using SM-VIOs with a lifetime of >>>>>>>>>>> 0, indicating the section where one or more nodes are being removed >>>>>>>>>>> (see Section 6.6). >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use >>>>>>>>>>> " >>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>> Tracks. In the case of a broken segment, the Root removes the >>>>>>>>>>> leftover sections of the segment using SM-VIOs with a lifetime of >>>>>>>>>>> 0, indicating the section where one or more nodes are being removed >>>>>>>>>>> (see Section 6.6). >>>>>>>>>>> " >>>>>>>>>>> 42) <!--[rfced] We find "using [RFC8138] in the main DODAG" unclear. >>>>>>>>>>> Please clarify what is being applied from RFC 8138 in the main >>>>>>>>>>> DODAG. >>>>>>>>>>> Original: >>>>>>>>>>> When using [RFC8138] in the main DODAG operated in Non-Storing Mode >>>>>>>>>>> in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG >>>>>>>>>>> is formatted as shown in Figure 20, representing the case where an >>>>>>>>>>> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use >>>>>>>>>>> " >>>>>>>>>>> When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing >>>>>>>>>>> Mode and the >>>>>>>>>>> data packets are compressed using [RFC8138, a typical packet that >>>>>>>>>>> circulates in the main DODAG >>>>>>>>>>> is formatted as shown in Figure 20, representing the case where an >>>>>>>>>>> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >>>>>>>>>>> " >>>>>>>>>>> 43) <!--[rfced] This sentence is hard to parse. Please let us know >>>>>>>>>>> if the >>>>>>>>>>> suggested update captures the intended meaning or if you prefer >>>>>>>>>>> otherwise. >>>>>>>>>>> Original: >>>>>>>>>>> At the head of the resulting sequence of bytes, the track Ingress >>>>>>>>>>> then adds the RPI that carries the TrackID as RPLinstanceID as a P- >>>>>>>>>>> RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as >>>>>>>>>>> RPLInstanceID. >>>>>>>>>>> Perhaps: >>>>>>>>>>> At the head of the resulting sequence of bytes, the Track Ingress >>>>>>>>>>> then adds the RPI that carries the P-RPI-6LoRH Header (as >>>>>>>>>>> illustrated in Figure 12) and uses the TrackID as the RPLInstanceID. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use >>>>>>>>>>> " >>>>>>>>>>> At the head of the resulting sequence of bytes, the track Ingress >>>>>>>>>>> then adds a P-RPI-6LoRH Header to transport the RPI in its >>>>>>>>>>> compressed form as illustrated in Figure 12. The RPI carries the >>>>>>>>>>> TrackID as RPLinstanceID. >>>>>>>>>>> " >>>>>>>>>>> 44) <!--[rfced] Please clarify "at the expense of". Does this mean >>>>>>>>>>> that >>>>>>>>>>> route stretch is used rather than the shortest path routes? >>>>>>>>>>> Original: >>>>>>>>>>> RPL requires less resources than alternative IGPs like OSPF, ISIS, >>>>>>>>>>> EIGRP, BABEL or RIP at the expense of a route stretch vs. the >>>>>>>>>>> shortest path routes to a destination that those protocols compute. >>>>>>>>>>> Perhaps: >>>>>>>>>>> RPL requires fewer resources than alternative IGPs such as OSPF, >>>>>>>>>>> IS-IS, >>>>>>>>>>> the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or >>>>>>>>>>> RIP >>>>>>>>>>> when using route stretch rather than the shortest path routes to a >>>>>>>>>>> destination that those protocols compute. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 45) <!--[rfced] Is "ANIMA" needed in this sentence or can it be >>>>>>>>>>> removed or >>>>>>>>>>> replaced with the title of RFC 8994? We note that the title of >>>>>>>>>>> RFC 8994 is "An Autonomic Control Plane (ACP)", so we are not >>>>>>>>>>> sure how "ANIMA" relates as it is not mentioned in Appendix >>>>>>>>>>> A.9.4. >>>>>>>>>>> Current: >>>>>>>>>>> P-Routes add the capability to install shortest and/or constrained >>>>>>>>>>> routes to special destinations such as discussed in Appendix A.9.4 >>>>>>>>>>> of the ANIMA ACP [RFC8994]. >>>>>>>>>>> Perhaps A: >>>>>>>>>>> P-Routes add the capability to install the shortest and/or >>>>>>>>>>> constrained >>>>>>>>>>> routes to special destinations as discussed in Appendix A.9.4 >>>>>>>>>>> of [RFC8994]. >>>>>>>>>>> or >>>>>>>>>>> Perhaps B: >>>>>>>>>>> P-Routes add the capability to install the shortest and/or >>>>>>>>>>> constrained >>>>>>>>>>> routes to special destinations as discussed in Appendix A.9.4 of >>>>>>>>>>> "An Autonomic Control Plane (ACP)" [RFC8994]. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>> 46) <!--[rfced] Does "is that of" mean "a part of"? And does the >>>>>>>>>>> Ingress >>>>>>>>>>> node encapsulate the RPL Instance or the main DODAG? >>>>>>>>>>> Original: >>>>>>>>>>> The RPL Instance is that of the main DODAG, and the Ingress >>>>>>>>>>> node that encapsulates is not the Root. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The RPL Instance is a part of the main DODAG, and the Ingress >>>>>>>>>>> node that encapsulates the RPL Instance is not the Root. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use >>>>>>>>>>> ' >>>>>>>>>>> The RPL Instance is the one that runs the main DODAG, and the >>>>>>>>>>> Ingress >>>>>>>>>>> node that encapsulates the RPL Instance is not the Root. >>>>>>>>>>> ' >>>>>>>>>>> 47) <!--[rfced] How may we clarify "an order other than that of"? >>>>>>>>>>> Is the >>>>>>>>>>> intended meaning that the PLR's metrics are in a different order >>>>>>>>>>> than the PCE's metrics? >>>>>>>>>>> Original: >>>>>>>>>>> The expectation is that the metrics that the PLR uses are of an >>>>>>>>>>> order other than that of the PCE, because of the difference of >>>>>>>>>>> time scale between routing and forwarding, more in [RAW-ARCHI]. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The expectation is that the PLR's metrics will be in a different >>>>>>>>>>> order >>>>>>>>>>> than the PCE's metrics because of the difference in the timescale >>>>>>>>>>> between routing and forwarding; see more in [RAW-ARCH]. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 48) <!--[rfced] Is "Target/Transit information tuples" correct, or >>>>>>>>>>> should >>>>>>>>>>> it be "Target/TIO tuples" for consistency? >>>>>>>>>>> Original: >>>>>>>>>>> Note that the Path Sequence and Lifetime in the TIO are selected by >>>>>>>>>>> the Root and that the Target/Transit information tuples in the >>>>>>>>>>> P-DAO are not those received by the Root in the DAO messages about >>>>>>>>>>> the said Targets. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Note that the Path Sequence and Lifetime in the TIO are selected by >>>>>>>>>>> the Root and that the Target/TIO tuples in the P-DAO are not those >>>>>>>>>>> received by the Root in the DAO messages about the said Targets. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please retain the original >>>>>>>>>>> 49) <!--[rfced] Can these sentences be combined to reduce >>>>>>>>>>> redundancy? >>>>>>>>>>> Original: >>>>>>>>>>> This section describes profiles that can be implemented separately >>>>>>>>>>> and can be used to discriminate what an implementation can and >>>>>>>>>>> cannot >>>>>>>>>>> do. This section describes profiles that enable implementing only a >>>>>>>>>>> portion of this specification to meet a particular use case. >>>>>>>>>>> Perhaps: >>>>>>>>>>> This section describes profiles that can be implemented separately, >>>>>>>>>>> e.g., using only a portion of this specification to meet a >>>>>>>>>>> particular use >>>>>>>>>>> case, and can be used to discriminate what an implementation can >>>>>>>>>>> and cannot do. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 50) <!--[rfced] Please clarify what "its" is referring to in the >>>>>>>>>>> following. >>>>>>>>>>> Original: >>>>>>>>>>> Profile 3 and above leverage Local RPL Instances to build arbitrary >>>>>>>>>>> Tracks Rooted at the Track Ingress and using its namespace for >>>>>>>>>>> TrackID >>>>>>>>>>> Perhaps: >>>>>>>>>>> Profile 3 and above leverage Local RPL Instances to build arbitrary >>>>>>>>>>> Tracks rooted at the Track Ingress, using the namespace of the >>>>>>>>>>> Track Ingress for the TrackID. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 51) <!-- [rfced] FYI - We updated the "/" here to "or". Let us know >>>>>>>>>>> if another >>>>>>>>>>> meaning is intended. >>>>>>>>>>> Original: >>>>>>>>>>> Profile 2 is >>>>>>>>>>> RECOMMENDED in a high speed / wired environment to enable Traffic >>>>>>>>>>> Engineering and network automation. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Profile 2 is >>>>>>>>>>> RECOMMENDED in a high-speed or wired environment to enable Traffic >>>>>>>>>>> Engineering and network automation. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use >>>>>>>>>>> " >>>>>>>>>>> Profile 2 is >>>>>>>>>>> RECOMMENDED in a high speed (e.g., wired) environment to enable >>>>>>>>>>> Traffic >>>>>>>>>>> Engineering and network automation. >>>>>>>>>>> " >>>>>>>>>>> 52) <!--[rfced] Please clarify "on top". Is it necessary to include >>>>>>>>>>> in >>>>>>>>>>> this sentence? >>>>>>>>>>> Original: >>>>>>>>>>> The other Profiles extend Profile 0 with selected capabilities >>>>>>>>>>> that this specification introduces on top. >>>>>>>>>>> Perhaps: >>>>>>>>>>> The other profiles extend Profile 0 with selected capabilities >>>>>>>>>>> that this specification introduces. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 53) <!--[rfced] Is "source routing" correct in these sentences, or >>>>>>>>>>> should >>>>>>>>>>> it be "source-routed" per Table 26? >>>>>>>>>>> Current: >>>>>>>>>>> Profile 2 extends Profile 0 with strict source routing Non-Storing >>>>>>>>>>> Mode P-Routes along the main DODAG, which is the same as Profile 1 >>>>>>>>>>> but using NSM-VIOs as opposed to SM-VIOs. >>>>>>>>>>> Profile 4 extends Profile 2 with strict source routing Non-Storing >>>>>>>>>>> Mode P-Routes to form forward Tracks that are inside the main >>>>>>>>>>> DODAG but do not necessarily follow it. >>>>>>>>>>> Perhaps: >>>>>>>>>>> Profile 2 extends Profile 0 with strict source-routed Non-Storing >>>>>>>>>>> Mode P-Routes along the main DODAG, which is the same as Profile 1 >>>>>>>>>>> but using NSM-VIOs as opposed to SM-VIOs. >>>>>>>>>>> Profile 4 extends Profile 2 with strict source-routed Non-Storing >>>>>>>>>>> Mode P-Routes to form forward Tracks that are inside the main >>>>>>>>>>> DODAG but do not necessarily follow it. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> 54) <!--[rfced] FYI: We updated "In that case" to "With Profile 2" >>>>>>>>>>> for >>>>>>>>>>> clarity. Please let us know if that is not correct. >>>>>>>>>>> Original: >>>>>>>>>>> In that case, the Tracks MUST be installed as subTracks of the main >>>>>>>>>>> DODAG, the main Instance MUST be used as TrackID. >>>>>>>>>>> Current: >>>>>>>>>>> With Profile 2, the Tracks MUST be installed as subTracks of the >>>>>>>>>>> main >>>>>>>>>>> DODAG, and the main Instance MUST be used as the TrackID. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > OK >>>>>>>>>>> 55) <!--[rfced] We are having trouble parsing this sentence; it >>>>>>>>>>> reads as >>>>>>>>>>> if 6TiSCH defined RFC 9031. Is the intended meaning that 6TiSCH >>>>>>>>>>> is defined in RFC 9031? Please let us know how we may clarify the >>>>>>>>>>> text. >>>>>>>>>>> Original: >>>>>>>>>>> 6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > the 6TiSCH WG defined ... Let's reword, e.g.,: >>>>>>>>>>> " >>>>>>>>>>> The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the >>>>>>>>>>> RPL Root as 6LBR. >>>>>>>>>>> " >>>>>>>>>>> 56) <!--[rfced] We are having trouble parsing the latter part of >>>>>>>>>>> this >>>>>>>>>>> sentence (i.e., "by avoiding that a node appears twice"). How may >>>>>>>>>>> we update this for clarity? >>>>>>>>>>> Original: >>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>> basic loops by avoiding that a node appears twice. >>>>>>>>>>> Perhaps A: >>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>> basic loops when a node appears twice. >>>>>>>>>>> or >>>>>>>>>>> Perhaps B: >>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>> basic loops, i.e., by avoiding a node that appears twice. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>> 57) <!-- [rfced] We have included some specific questions about the >>>>>>>>>>> IANA >>>>>>>>>>> text below. In addition to responding to those questions, please >>>>>>>>>>> review all of the IANA-related updates carefully and let us know >>>>>>>>>>> if any further updates are needed. >>>>>>>>>>> a) Text relating to the "Mode of Operation" registry appears in >>>>>>>>>>> Section 11.1 >>>>>>>>>>> after the information for the "DODAG Configuration Option Flags for >>>>>>>>>>> MOP 0..6" >>>>>>>>>>> registry. May we create a new subsection for this text, perhaps >>>>>>>>>>> titled "Mode of >>>>>>>>>>> Operation"? >>>>>>>>>>> Current: >>>>>>>>>>> IANA has added this RFC as an additional reference for MOP 7 in the >>>>>>>>>>> "Mode of Operation" registry under the "Routing Protocol for Low >>>>>>>>>>> Power and Lossy Networks (RPL)" registry group [IANA-RPL]. >>>>>>>>>>> Pascal > please leave as is >>>>>>>>>>> b) In Table 26, may we include the expansions of "SM-VIO" and >>>>>>>>>>> "NSM-VIO" for >>>>>>>>>>> clarity and consistency with the running text? Note that we will >>>>>>>>>>> communicate >>>>>>>>>>> any updates to IANA. >>>>>>>>>>> Current: >>>>>>>>>>> 0x0F Stateful VIO (SM-VIO) >>>>>>>>>>> 0x10 Source-Routed VIO (NSM-VIO) >>>>>>>>>>> Perhaps: >>>>>>>>>>> 0x0F Stateful Storing Mode VIO (SM-VIO) >>>>>>>>>>> 0x10 Source-Routed Non-Storing Mode VIO (NSM-VIO) >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> c) In Section 5.3, should "stateful" and "source-routed" be included >>>>>>>>>>> in the description for "Option Type" per Table 26? >>>>>>>>>>> Original: >>>>>>>>>>> Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26). >>>>>>>>>>> Perhaps: >>>>>>>>>>> Option Type: 0x0F for stateful SM-VIO and 0x10 for source-routed >>>>>>>>>>> NSM-VIO (see Table 26). >>>>>>>>>>> Please leave as is. stateful is not part of the name, it is a >>>>>>>>>>> characteristic. >>>>>>>>>>> d) In both the "PDR-ACK Acceptance Status Values" and "PDR-ACK >>>>>>>>>>> Rejection >>>>>>>>>>> Status Values" registries <https://www.iana.org/assignments/rpl/>, >>>>>>>>>>> the first >>>>>>>>>>> column is titled "Bit Number"; however, in Tables 28 and 29 of this >>>>>>>>>>> document, >>>>>>>>>>> the first column is titled "Value". Please let us know which term >>>>>>>>>>> you prefer >>>>>>>>>>> ("Bit Number" or "Value") and we will make the document and >>>>>>>>>>> registries >>>>>>>>>>> consistent. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > great catch. This is a bug in the IANA registry, probably >>>>>>>>>>> a cc of the previous entry. Please use 'value' >>>>>>>>>>> 58) <!-- [rfced] Would you like the references to be alphabetized >>>>>>>>>>> or left in their current order? >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please leave as is >>>>>>>>>>> 59) <!--[rfced] FYI: "draft-kuehlewind-update-tag" has been >>>>>>>>>>> replaced by >>>>>>>>>>> "draft-kuehlewind-rswg-updates-tag", so we have updated this >>>>>>>>>>> reference entry accordingly. Please let us know of any objection. >>>>>>>>>>> Original: >>>>>>>>>>> [I-D.kuehlewind-update-tag] >>>>>>>>>>> Kühlewind, M. and S. Krishnan, "Definition of new tags for >>>>>>>>>>> relations between RFCs", Work in Progress, Internet-Draft, >>>>>>>>>>> draft-kuehlewind-update-tag-04, 12 July 2021, >>>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >>>>>>>>>>> update-tag-04>. >>>>>>>>>>> Current: >>>>>>>>>>> [NEW-TAGS] >>>>>>>>>>> Kühlewind, M. and S. Krishnan, "Definition of new tags for >>>>>>>>>>> relations between RFCs", Work in Progress, Internet-Draft, >>>>>>>>>>> draft-kuehlewind-rswg-updates-tag-02, 8 July 2024, >>>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >>>>>>>>>>> rswg-updates-tag-02>. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > thanks >>>>>>>>>>> 60) <!-- [rfced] FYI: We have updated this reference's URL to use >>>>>>>>>>> the >>>>>>>>>>> following URL, which points to the "IPv6 Low Power Personal Area >>>>>>>>>>> Network Parameters" registry: >>>>>>>>>>> <https://www.iana.org/assignments/_6lowpan-parameters>. Please >>>>>>>>>>> let us know if this is incorrect. >>>>>>>>>>> Original: >>>>>>>>>>> [IANA-6LO] IETF, "IPv6 Low Power Personal Area Network Parameters >>>>>>>>>>> registry", >>>>>>>>>>> <https://www.iana.org/assignments/icmpv6-parameters/>. >>>>>>>>>>> Current: >>>>>>>>>>> [IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters", >>>>>>>>>>> <https://www.iana.org/assignments/_6lowpan-parameters>. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > thanks >>>>>>>>>>> 61) <!-- [rfced] Some author comments are present in the XML. >>>>>>>>>>> Please confirm that >>>>>>>>>>> no updates related to these comments are outstanding. Note that the >>>>>>>>>>> comments will be deleted prior to publication. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > confirmed >>>>>>>>>>> 62) <!-- [rfced] Terminology >>>>>>>>>>> a) Throughout the text, the following terminology appears to be used >>>>>>>>>>> inconsistently. Please review these occurrences and let us know >>>>>>>>>>> if/how they >>>>>>>>>>> may be made consistent. >>>>>>>>>>> Complex Track vs. complex Track >>>>>>>>>>> Pascal > please use Complex Track as per RFC 9030 >>>>>>>>>>> Objective Function vs. objective function >>>>>>>>>>> Pascal > please use "Objective Function" as per RFC 6550 >>>>>>>>>>> Instance vs. instance >>>>>>>>>>> [Note: is "topologies called instances" correct or should it be >>>>>>>>>>> "Instances"? Should any other lowercase occurrences be uppercase?] >>>>>>>>>>> Global Instance vs. global instance >>>>>>>>>>> [Note: "Global RPL Instance" and "Global instance" used in RFC 6550 >>>>>>>>>>> and "Global Instance 0" used in RFC 8138] >>>>>>>>>>> Local Instance >>>>>>>>>>> main Instance vs. main instance >>>>>>>>>>> RPL Instance vs. RPL instance >>>>>>>>>>> [Note: "RPL Instance" used in RFCs 6550, 6553, and 8138 and >>>>>>>>>>> companion document draft-ietf-raw-technologies-17] >>>>>>>>>>> Track Instance vs. Track instance >>>>>>>>>>> Pascal > please use " Instance " as per RFC 6550 in all cases >>>>>>>>>>> Rejection Status vs. rejection status >>>>>>>>>>> [Note: "rejection status" used in RFC 6550) >>>>>>>>>>> Pascal > please use "rejection status" as per RFC 6550 >>>>>>>>>>> Root vs. root >>>>>>>>>>> [Note: There are 7 lowercase instances, plus one within quoted text. >>>>>>>>>>> Aside from the quoted text, should any of these be made uppercase >>>>>>>>>>> for consistency?] >>>>>>>>>>> Pascal > please use " Root " as per RFC 6550 in all cases >>>>>>>>>>> Routing Header vs. routing header >>>>>>>>>>> [Note: "Routing Header" used in RFC 8138. Also, after the first >>>>>>>>>>> expansion, may we replace this term with "RH"?] >>>>>>>>>>> Pascal > please use " Routing Header " as per RFC 8138 >>>>>>>>>>> in all cases >>>>>>>>>>> Segment ID (4) vs. SegmentID (6) >>>>>>>>>>> Pascal > please use " SegmentID " in all cases >>>>>>>>>>> Track ID (3) vs. TrackID (90) >>>>>>>>>>> Pascal > please use " TrackID " in all cases >>>>>>>>>>> Target (77) vs. target (11) >>>>>>>>>>> Pascal > please leave the text as is >>>>>>>>>>> Type of 4 vs. type 4 (also, type 3 and type 5) >>>>>>>>>>> Pascal > please use "type 4" >>>>>>>>>>> b) FYI: We updated the following terms to reflect the forms on the >>>>>>>>>>> right for consistency. Please let us know of any objection. >>>>>>>>>>> 6LoWPAN Header Compression -> 6LoWPAN header compression (per RFC >>>>>>>>>>> 8138) >>>>>>>>>>> 6LoWPAN Network -> 6LoWPAN network >>>>>>>>>>> 6TiSCH Architecture -> 6TiSCH architecture >>>>>>>>>>> Backbone -> backbone (per RFC 6550) >>>>>>>>>>> base Object and base object -> Base Object >>>>>>>>>>> Border Router and Border router -> border router (per RFC 6550) >>>>>>>>>>> Code -> code (per RFC 6550) >>>>>>>>>>> dataplane -> data plane (per companion document >>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>> Destination Address -> destination address >>>>>>>>>>> DODAG Configuration Option -> DODAG Configuration option (per RFC >>>>>>>>>>> 6550) >>>>>>>>>>> DODAG ID -> DODAGID >>>>>>>>>>> Extension Header and extension Header -> extension header >>>>>>>>>>> external Controller -> external controller >>>>>>>>>>> global RPLInstanceID -> Global RPLInstanceID >>>>>>>>>>> IPv6 Address -> IPv6 address >>>>>>>>>>> IPv6 Header -> IPv6 header (per RFC 8138) >>>>>>>>>>> Legacy -> legacy (per companion document >>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>> Link-Layer security -> link-layer security (per RFC 9010) >>>>>>>>>>> local RPL Instance -> Local RPL Instance (per RFC 6550 and >>>>>>>>>>> companion >>>>>>>>>>> document draft-ietf-raw-technologies-17) >>>>>>>>>>> local RPLInstanceID -> Local RPLInstanceID (per companion document >>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>> loose Source Routing -> loose source routing >>>>>>>>>>> multihop -> multi-hop (per RFC 8930 and companion documents) >>>>>>>>>>> Non-Storing mode and non-storing mode -> Non-Storing Mode >>>>>>>>>>> Non-Storing P-DAO -> Non-Storing Mode P-DAO >>>>>>>>>>> P-route -> P-Route >>>>>>>>>>> Protection Path -> protection path (to match companion documents) >>>>>>>>>>> Protection service -> protection service >>>>>>>>>>> RAW Architecture -> RAW architecture (to match companion documents) >>>>>>>>>>> Recovery Graph -> recovery graph (per companion document >>>>>>>>>>> draft-ietf-raw-architecture-30) >>>>>>>>>>> Routing Stretch -> routing stretch >>>>>>>>>>> RPL InstanceID and RPLinstanceID -> RPLInstanceID >>>>>>>>>>> RPL Network -> RPL network >>>>>>>>>>> segment Lifetime of zero -> Segment Lifetime of 0 >>>>>>>>>>> Sibling Information option -> Sibling Information Option >>>>>>>>>>> Source Address -> source address (per RFC 6550) >>>>>>>>>>> Source Route path -> source route path (per RFCs 6550 and 8138) >>>>>>>>>>> Stand-Alone -> stand-alone >>>>>>>>>>> Storing mode and storing mode -> Storing Mode >>>>>>>>>>> Strict -> strict >>>>>>>>>>> time scale -> timescale (per companion document >>>>>>>>>>> draft-ietf-raw-architecture-30) >>>>>>>>>>> track -> Track (5 instances) >>>>>>>>>>> traffic Engineering -> Traffic Engineering (per companion documents) >>>>>>>>>>> VIA Address -> Via address >>>>>>>>>>> Via Information option -> Via Information Option >>>>>>>>>>> Pascal > Absolutely great. please note that the companion drafts >>>>>>>>>>> are RFC 9912 and RFC 9913 so this text will change >>>>>>>>>>> c) Please review the following capitalization inconsistencies in >>>>>>>>>>> the names of >>>>>>>>>>> nodes and let us know how to update for consistency. Note that the >>>>>>>>>>> first three >>>>>>>>>>> terms below appeared in the companion document >>>>>>>>>>> draft-ietf-raw-architecture-30, >>>>>>>>>>> and the author chose to use "egress node", "ingress node", and >>>>>>>>>>> "relay node" >>>>>>>>>>> (all lowercase). If you would like to follow this pattern in this >>>>>>>>>>> document, >>>>>>>>>>> please also review instances of "Egress" and "Ingress" when not in >>>>>>>>>>> the >>>>>>>>>>> context of "Egress Node" and "Ingress Node" (e.g., "the Track >>>>>>>>>>> Egress", "from >>>>>>>>>>> Ingress to Egress") and let us know they should be lowercased as >>>>>>>>>>> well. >>>>>>>>>>> Pascal > the "Track Egress" is really the Track egress node so your >>>>>>>>>>> proposal works there too. >>>>>>>>>>> Note that "Root Node" and "Forwarding Node" did not appear in the >>>>>>>>>>> companion >>>>>>>>>>> documents. >>>>>>>>>>> Egress Node vs. Egress node >>>>>>>>>>> Ingress Node vs. Ingress node >>>>>>>>>>> Relay Node vs. Relay node >>>>>>>>>>> [Note: "relay node" used in RFC 8655] >>>>>>>>>>> Pascal > Please use lowercase for "forwarding", "node", "ingress", >>>>>>>>>>> and "egress" in all cases. Root is inherited from RFC 6550 so >>>>>>>>>>> please leave it uppercase. >>>>>>>>>>> Root Node >>>>>>>>>>> Forwarding Node vs. forwarding Node >>>>>>>>>>> d) Please let us know if/how we may make these terms consistent. >>>>>>>>>>> Projected DAO-ACK vs. P-DAO-ACK >>>>>>>>>>> [Note: Is "P-DAO-ACK" short for "Projected DAO-ACK" >>>>>>>>>>> Pascal > yes >>>>>>>>>>> or are these different terms? In Section 4.1.1, should the first >>>>>>>>>>> mention of "P-DAO-ACK" be updated as "Projected DAO-ACK >>>>>>>>>>> (P-DAO-ACK)"?] >>>>>>>>>>> Pascal > Please use "Projected " on first use then P. >>>>>>>>>>> routing stretch vs. route stretch >>>>>>>>>>> Pascal > Please "routing stretch " >>>>>>>>>>> RPL DODAG Configuration option vs. RPL configuration option vs. >>>>>>>>>>> DODAG Configuration option >>>>>>>>>>> Pascal > please use 'Configuration option' as per RFC 6550 in all >>>>>>>>>>> cases >>>>>>>>>>> RPL Storing Mode vs. Storing Mode >>>>>>>>>>> Pascal > please use ' RPL Storing Mode " >>>>>>>>>>> e.1) Please let us know if/how we may make the case for these terms >>>>>>>>>>> consistent. >>>>>>>>>>> Source Routing Header vs. >>>>>>>>>>> source routing header >>>>>>>>>>> [Note: Suggest uppercase to match RFCs 6554 and 8138.] >>>>>>>>>>> Pascal > yes, please use uppercase >>>>>>>>>>> Source Route Header vs. >>>>>>>>>>> source route header vs. >>>>>>>>>>> source-routed header >>>>>>>>>>> [Note: Suggest uppercase. >>>>>>>>>>> Pascal > yes, please use uppercase >>>>>>>>>>> - Should "RPL" precede these instances to match use in >>>>>>>>>>> RFC 6554 (e.g., "RPL Source Route Header"), or should any >>>>>>>>>>> of these instances be "Source Routing Header" or "SRH"?] >>>>>>>>>>> Pascal > yes, please add RPL to ensure clarity (vs. SRH in segment >>>>>>>>>>> routing specs) >>>>>>>>>>> e.2) Is the use of "(RPL) SRH" correct in the sentences below, or >>>>>>>>>>> should it be "RPL Source Route Header" per RFC 6554? >>>>>>>>>>> Original: >>>>>>>>>>> In a Non-Storing mode RPL domain, the IPv6 RH used for source >>>>>>>>>>> routing >>>>>>>>>>> is the (RPL) SRH as defined in [RFC6554]. >>>>>>>>>>> Perhaps: >>>>>>>>>>> In a Non-Storing Mode RPL domain, the IPv6 RH used for source >>>>>>>>>>> routing >>>>>>>>>>> is the RPL Source Route Header as defined in [RFC6554]. >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> ... >>>>>>>>>>> Original: >>>>>>>>>>> As such, forwarding along segments as specified hereafter can be >>>>>>>>>>> seen >>>>>>>>>>> as a form of Segment Routing [RFC8402], but leveraging the (RPL) SRH >>>>>>>>>>> for its operation. >>>>>>>>>>> Perhaps: >>>>>>>>>>> As such, forwarding along segments as specified hereafter can be >>>>>>>>>>> seen >>>>>>>>>>> as a form of Segment Routing [RFC8402] that leverages the RPL Source >>>>>>>>>>> Route Header for its operation. >>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>> f) Regarding "Non-Storing Mode" vs. "Non-Storing Mode of Operation >>>>>>>>>>> (MOP)" and "Non-Storing MOP", should any of the instances below be >>>>>>>>>>> "Non-Storing Mode" or are they correct as is? >>>>>>>>>>> Pascal > they refer to the same thing. When we speak we say "mode", >>>>>>>>>>> and we mean RPL MOP. Please lowercase "mode" or leave the full MOP >>>>>>>>>>> expanded or not. >>>>>>>>>>> We note that RFC 6550 uses "Non-Storing mode" and "Non-Storing >>>>>>>>>>> Mode of Operation". Please let us know if any further changes are >>>>>>>>>>> needed to the case of "Mode" throughout the document. >>>>>>>>>>> Current: >>>>>>>>>>> Section 1: ... operated in RPL Non-Storing Mode of Operation (MOP) >>>>>>>>>>> Section 3.2: ... RPL Storing Mode or Non-Storing Mode of Operation >>>>>>>>>>> (MOP) >>>>>>>>>>> ... compared to Non-Storing MOP >>>>>>>>>>> Pascal > Good. For the latter you could say RPL Storing or >>>>>>>>>>> Non-Storing Mode of Operation (MOP) >>>>>>>>>>> g) May we make "Header" lowercase (form on the right) for the >>>>>>>>>>> following >>>>>>>>>>> terms to match use in RFC 8138? >>>>>>>>>>> IP-in-IP 6LoRH Header -> IP-in-IP 6LoRH header >>>>>>>>>>> P-RPI-6LoRH Header -> P-RPI-6LoRH header >>>>>>>>>>> RPI-6LoRH Header -> RPI-6LoRH header >>>>>>>>>>> Pascal > yes, please >>>>>>>>>>> h) We note the inconsistent use of quote marks around flag names. >>>>>>>>>>> Please review and let us know if you prefer single quotes or no >>>>>>>>>>> quotes for consistency. >>>>>>>>>>> Some examples: >>>>>>>>>>> 'D' flag vs. D flag >>>>>>>>>>> 'P' flag vs. P flag >>>>>>>>>>> 'O', 'R', and 'F' flags vs. O, R, and F flags >>>>>>>>>>> --> >>>>>>>>>>> Pascal > this reflects inconsistencies in the references as well. I >>>>>>>>>>> prefer with the quote if that's OK. >>>>>>>>>>> 63) <!-- [rfced] Abbreviations >>>>>>>>>>> a) FYI - We have added expansions for the following abbreviations >>>>>>>>>>> per >>>>>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and >>>>>>>>>>> each expansion in the document carefully to ensure correctness. >>>>>>>>>>> Deterministic Networking (DetNet) >>>>>>>>>>> Enhanced Interior Gateway Routing Protocol (EIGRP) >>>>>>>>>>> Operations, Administration, and Maintenance (OAM) >>>>>>>>>>> Pascal > Thanks >>>>>>>>>>> b) How may we expand the first mention of "P2P" below (in Section >>>>>>>>>>> 1)? >>>>>>>>>>> We note "P2P (Point-to-Point)" in Section 2.4.4 and "P2P (Peer-to- >>>>>>>>>>> Peer)" in Section 3.3.2. Do all instances of "P2P" refer to >>>>>>>>>>> "Point-to-Point" except for Section 3.3.2, or should "P2P" in >>>>>>>>>>> Section >>>>>>>>>>> 3.3.2 (and/or elsewhere) be made consistent? Please clarify. >>>>>>>>>>> Pascal > Please use P2P for point to point, and leave peer-to-peer >>>>>>>>>>> expanded with no initialism. >>>>>>>>>>> Current: >>>>>>>>>>> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >>>>>>>>>>> is a Distance Vector protocol, which is well-suited for application >>>>>>>>>>> in a variety of low energy Internet of Things (IoT) networks where >>>>>>>>>>> constrained nodes cannot maintain the full view of the topology, >>>>>>>>>>> and stretched P2P paths are acceptable versus the signaling and >>>>>>>>>>> state overhead involved in maintaining the shortest paths across. >>>>>>>>>>> Pascal > please remove "P2P" in that sentence. >>>>>>>>>>> c) How may we expand one instance of "TID"? Perhaps "Transaction >>>>>>>>>>> ID", >>>>>>>>>>> "Track ID", or "TrackID"? >>>>>>>>>>> Current: >>>>>>>>>>> If the DAO-ACK is not received, the Root may retry the DAO with the >>>>>>>>>>> same TID or tear down the route. >>>>>>>>>>> Pascal > "TrackID" it is >>>>>>>>>>> d) FYI: We updated the following expansions to the forms on the >>>>>>>>>>> right for consistency. Please let us know of any objection. >>>>>>>>>>> PCE Protocol (PCEP) -> PCE Communication Protocol (PCEP) (per RFC >>>>>>>>>>> 5440) >>>>>>>>>>> Segment Routing (SRv6) -> Segment Routing over IPv6 (SRv6) (per RFC >>>>>>>>>>> 8754) >>>>>>>>>>> Pascal > Thanks >>>>>>>>>>> e) We note the following inconsistencies with the companion >>>>>>>>>>> document. Please review and let us know if any changes to this >>>>>>>>>>> document are necessary or if these variations are okay. >>>>>>>>>>> "packet delivery ratio (PDR)" (in draft-ietf-raw-architecture-30) >>>>>>>>>>> vs. >>>>>>>>>>> "P-DAO Request (PDR)" (in this document) >>>>>>>>>>> Pascal > I suggest we use PDAOReq and PDAOAck in this spec >>>>>>>>>>> "Radio Access Network (RAN)" (in draft-ietf-raw-architecture-30) vs. >>>>>>>>>>> "RPL-Aware Node (RAN)" (in this document) >>>>>>>>>>> Pascal > please leave as is. This doc is in the RPL family and does >>>>>>>>>>> not apply to 3GPP >>>>>>>>>>> --> >>>>>>>>>>> 64) <!-- [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. >>>>>>>>>>> For example, please consider whether the following should be >>>>>>>>>>> updated: >>>>>>>>>>> - native >>>>>>>>>>> In addition, please consider whether "traditional" (2 instances) >>>>>>>>>>> should be updated for clarity. While the NIST website >>>>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/ >>>>>>>>>>> nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>>>>>>>>> indicates that this term is potentially biased, it is also >>>>>>>>>>> ambiguous. >>>>>>>>>>> "Tradition" is a subjective term, as it is not the same for >>>>>>>>>>> everyone. >>>>>>>>>>> --> >>>>>>>>>>> Pascal > please leave as is. >>>>>>>>>>> Many thanks for this tremendous work! >>>>>>>>>>> Pascal >>>>>>>>>>> Thank you. >>>>>>>>>>> Karen Moore and Rebecca VanRheenen >>>>>>>>>>> RFC Production Center >>>>>>>>>>> On Feb 27, 2026, at 1:55 PM, [email protected] wrote: >>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>> Updated 2026/02/27 >>>>>>>>>>> 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/rfc9914.xml >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>>>>>>>>> Diff file of the text: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by >>>>>>>>>>> side) >>>>>>>>>>> For your convenience, we have also created an alt-diff file that >>>>>>>>>>> will >>>>>>>>>>> allow you to more easily view changes where text has been deleted or >>>>>>>>>>> moved: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-alt-diff.html >>>>>>>>>>> Diff of the XML: >>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-xmldiff1.html >>>>>>>>>>> Tracking progress >>>>>>>>>>> ----------------- >>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9914 >>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>> RFC Editor >>>>>>>>>>> -------------------------------------- >>>>>>>>>>> RFC9914 (draft-ietf-roll-dao-projection-40) >>>>>>>>>>> Title : Root-initiated Routing State in RPL >>>>>>>>>>> Author(s) : P. Thubert, Ed., R. Arvind Jadhav, M. Richardson >>>>>>>>>>> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de >>>>>>>>>>> Velde >>>>>>>>>>> -- >>>>>>>>>>> Pascal >>>>>>>>>>> -- >>>>>>>>>>> auth48archive mailing list -- [email protected] >>>>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> >>>>>> >>>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
