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]
