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]
