> On Mar 18, 2026, at 8:18 PM, Ketan Talaulikar <[email protected]> wrote: > > Hi Ines/Aris, > > Can you please take a look and share your perspective? > > Busy at IETF this week and this is non-trivial (for me at least) and so I'll > get back by next week. > > Thanks, > Ketan > > > On Wed, Mar 18, 2026 at 12:20 AM Karen Moore <[email protected]> > wrote: > 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]
