Hi Pascal, Our files now reflect “PDRSequence” (instead of "PDAOReqSequence”).
—Files (please refresh)— 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) Best regards, Karen Moore RFC Production Center > On Mar 17, 2026, at 2:04 PM, Pascal Thubert <[email protected]> wrote: > > Hello Karen > > Since we rolled back to PDR-ACK I believe we should roll back to PDRSequence > as well. For consistency. > > Does that work for you ? > > Pascal > >> Le 17 mars 2026 à 19:50, Karen Moore <[email protected]> a écrit : >> >> Dear Rahul and *Ketan (AD), >> >> Thank you for your reply. We have noted Rahul’s approval on the AUTH48 >> status page (https://www.rfc-editor.org/auth48/rfc9914). Note that >> "coma-separated Targets” was already updated to "comma-separated Targets” >> (Section 3.5, 5th paragraph). This is reflected in the diff file at >> <https://www.rfc-editor.org/authors/rfc9914-diff.html>. If there is a >> different instance we missed, please let us know. >> >> *Ketan, please review the changes in the following sections and let us know >> if you approve. >> >> Section 2.4.5 >> Section 3.2 >> Section 3.6 >> Section 3.7.2.3 >> Section 3.7.2.4 >> Section 4.2 (added “MUST”) >> Section 5.2 (added “MUST”) >> Section 5.3 (added “MUST”) >> Section 6.4.1 (added “MUST”) >> Section 6.8 >> Section 10 >> >> Note that the following terms were updated throughout the text: >> DAO-ACK —> P-DAO-ACK >> PDR —> P-DAO-REQ >> PDRSequence —> PDAOReqSequence >> PAREO -> PREOF >> >> >> —Files (please refresh)— >> >> 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) >> >> Best regards, >> >> Karen Moore >> RFC Production Center >> >> >>> On Mar 17, 2026, at 12:30 AM, Rahul Jadhav <[email protected]> wrote: >>> >>> Hey Team, >>> >>> The document is approved from my side. >>> >>> Just a small nit "coma-separated Targets" --> "comma-separated Targets". >>> >>> Thanks, >>> Rahul >>> >>> On Tue, 17 Mar 2026 at 08:23, Rahul Jadhav <[email protected]> wrote: >>> Hey Karen, Pascal, Team, >>> >>> The document has come a long way. Will review the document today and send >>> my response. >>> >>> Thanks, >>> Rahul >>> >>> On Tue, 17 Mar 2026 at 03:57, Karen Moore <[email protected]> >>> wrote: >>> Hello Pascal, >>> >>> We have updated our files to reflect your requested changes. Please review >>> and let us know if you have any further updates. >>> >>> We have noted your approval of the document on the AUTH48 status page >>> (https://www.rfc-editor.org/auth48/rfc9914). Currently, we await approvals >>> from Rahul and Michael. >>> >>> One additional question. >>> >>> 1) We replaced “Transient Failure” with “Reserved” in Table 29. Is an >>> update needed to Section 5.1, which contains this text: >>> >>> Current: >>> A status of "Transient Failure" (see Section 11.10) is an >>> indication that the P-DAO-REQ may be retried >>> after a reasonable time that depends on the deployment. >>> >>> >>> 2) FYI: In Section 2.4.5, after the first mention/expansion of “PREOF", we >>> removed “operations” per the context. >>> >>> Old: >>> It may contain multiple paths that may fork and rejoin and that may >>> enable RAW Packet ARQ, Replication, Elimination, and Overhearing >>> (PAREO) operations. >>> >>> New: >>> It may contain multiple paths that may fork and rejoin and that may >>> enable RAW Packet Replication, Elimination, and Ordering Functions (PREOF). >>> >>> —Files (please refresh)— >>> >>> 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) >>> >>> Best regards, >>> >>> Karen Moore >>> RFC Production Center >>> >>> >>>>> On Mar 14, 2026, at 6:36 AM, Pascal Thubert <[email protected]> >>>>> wrote: >>>> >>>> Hello Karen >>>> >>>> Please find my final review of the overall document >>>> >>>> 1) there still text mentioning PAREO. That term was removed from RAW and >>>> merged into PREOF. Please replace PAREO with PREOF throughout. >>>> >>>> >>>> 2) old >>>> >>>> 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 Packet Replication, >>>> Elimination, and Ordering Functions (PREOF) over the available paths >>>> >>>> >>>> New >>>> >>>> >>>> A recovery graph as in the RAW architecture [RAW-ARCH] can be composed of >>>> forward East-West directional segments and North-South bidirectional >>>> segments to enable additional path diversity using Packet Replication, >>>> Elimination, and Ordering Functions (PREOF) to select the protection paths >>>> to be used for a given datagram. >>>> >>>> >>>> 3) in section 11.10 table 28, bit of value 1 is reserved in section 5.2 >>>> so please replace "Transient Failure" with "Reserved". >>>> >>>> >>>> 4) In section 11.12 the 'B" flag defined in section 5.4 is missing from >>>> table 30. Bit Nb is 1. >>>> The text for the capability description would be: >>>> "'B" flag: Connectivity to the sibling is roughly symmetrical". >>>> >>>> >>>> When this is fixed I approve this document for publication. >>>> >>>> Enjoy the meeting! >>>> >>>> Pascal >>>> >>>>> Le jeu. 12 mars 2026 à 23:54, Karen Moore <[email protected]> a >>>>> écrit : >>>> Hello again Pascal, >>>> >>>> The changes to Sections 2.4.5 and 3.4.1 have been made. Please review the >>>> updated files and let us know if any further changes are needed. >>>> >>>> Currently, we await approval of the document from each author. >>>> >>>> —Files (please refresh)— >>>> >>>> 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 >>>> >>>> Best regards, >>>> >>>> Karen Moore >>>> RFC Production Center >>>> >>>>> On Mar 12, 2026, at 2:12 PM, Pascal Thubert <[email protected]> >>>>> wrote: >>>>> >>>>> Hello again Karen >>>>> >>>>> Please add "protection" before "path" in >>>>> >>>>> The concept of a Track was introduced in the 6TiSCH architecture >>>>> [RFC9030] as a collection of potential paths that leverage redundant >>>>> forwarding solutions along the way. >>>>> >>>>> All the best >>>>> >>>>> Pascal >>>>> >>>>> Le jeu. 12 mars 2026 à 22:04, Pascal Thubert <[email protected]> a >>>>> écrit : >>>>> Hello Karen >>>>> >>>>> There's an oups about references to detnet "protection path". Not yours, >>>>> ours. >>>>> A Track equates a RAW "recovery graph" not a protection path, see section >>>>> 3 of rfc to be 9912. >>>>> >>>>> Please fix section 2.4.5 >>>>> Old >>>>> The concept of Track is inherited from the 6TiSCH architecture [RFC9030] >>>>> and matches that of a protection path in the RAW architecture [RAW-ARCH]. >>>>> New >>>>> The concept of Track is inherited from the 6TiSCH architecture [RFC9030] >>>>> and equals that of a recovery graph in the RAW architecture [RAW-ARCH]. >>>>> >>>>> Thanks a bunch! >>>>> >>>>> >>>>> Pascal >>>>> >>>>> Le jeu. 12 mars 2026 à 21:38, Pascal Thubert <[email protected]> a >>>>> écrit : >>>>> Excellent! >>>>> >>>>> A bientôt; >>>>> >>>>> Pascal >>>>> >>>>>> Le 12 mars 2026 à 20:34, Karen Moore <[email protected]> a >>>>>> écrit : >>>>>> >>>>>> Thank you! Please note that I also expanded “PREOF” in Section 3.7.2.4. >>>>>> >>>>>> Current: >>>>>> 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 >>>>>> Packet Replication, Elimination, and Ordering Functions (PREOF) over >>>>>> the available paths. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Karen Moore >>>>>> RFC Production Center >>>>>> >>>>>>> On Mar 12, 2026, at 12:20 PM, Pascal Thubert <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> On it Karen, many thanks! >>>>>>> >>>>>>> A bientôt; >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>>> Le 12 mars 2026 à 19:33, Karen Moore <[email protected]> a >>>>>>>>> écrit : >>>>>>>> >>>>>>>> Hello Pascal, >>>>>>>> >>>>>>>> We have added “PDR-ACK” to the glossary and have expanded it in the >>>>>>>> title of Section 11.8. Please review and let us know if any further >>>>>>>> edits are needed. >>>>>>>> >>>>>>>> We will await approval of the document from each author prior to >>>>>>>> moving forward with the publication process. >>>>>>>> >>>>>>>> —Files (please refresh)— >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Karen Moore >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> >>>>>>>>> On Mar 11, 2026, at 1:46 PM, Pascal Thubert >>>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Many thanks Karen! >>>>>>>>> >>>>>>>>> Now is a good time for the authors to read through and approve. I’ll >>>>>>>>> do so asap! >>>>>>>>> >>>>>>>>> One small thing Karen: could you please add PDR-ACK to the glossary? >>>>>>>>> >>>>>>>>> Maybe also expand PDR-ACK in the title of section 11? >>>>>>>>> >>>>>>>>> A bientôt; >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> >>>>>>>>>>> Le 11 mars 2026 à 21:01, Karen Moore <[email protected]> >>>>>>>>>>> a écrit : >>>>>>>>>> >>>>>>>>>> Pascal, >>>>>>>>>> >>>>>>>>>> We have made these changes (the text now reflects “Projected DAO >>>>>>>>>> Request Acknowledgment (PDR-ACK)” and “Projected DAO Acknowledgment >>>>>>>>>> (P)”). Please review the updated files and let us know if any >>>>>>>>>> further changes are needed. Note that we will await approval of the >>>>>>>>>> document from each author prior to moving forward with the IANA >>>>>>>>>> updates and publication process. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> —Files (please refresh)— >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Karen Moore >>>>>>>>>> RFC Production Center >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Mar 11, 2026, at 12:35 PM, Pascal Thubert >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>> >>> >> -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
