Many thanks Karen A bientôt;
Pascal > Le 17 mars 2026 à 22:32, Karen Moore <[email protected]> a écrit : > > 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]
