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 >>>>>>>>>>>>> they do not attempt to validate the order for nested Tracks, >>>>>>>>>>>>> trusting the PCE implicitly. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > "it" refers to "the DODAG of underlay instances", which >>>>>>>>>>>>> is optionally provided >>>>>>>>>>>>> Proposed: >>>>>>>>>>>>> When the DODAG of underlay instances is not provided, the RPL >>>>>>>>>>>>> nodes consider by default >>>>>>>>>>>>> that all Track instances are children of the main instance, and >>>>>>>>>>>>> they do not attempt to validate the order for nested Tracks, >>>>>>>>>>>>> trusting the PCE implicitly. >>>>>>>>>>>>> 18) <!-- [rfced] Is "coma-" here is correct? Should this be >>>>>>>>>>>>> updated to "comma-" or >>>>>>>>>>>>> something else? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> We use "-to-", such as in C==>D==>E-to-F to represent >>>>>>>>>>>>> coma-separated Targets, e.g., F is a Target for segment C==>D==>E. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use "comma-" >>>>>>>>>>>>> 19) <!--[rfced] We note that several of the tables have the same >>>>>>>>>>>>> title; >>>>>>>>>>>>> will this be confusing for readers? For instance, Tables 3, 6, 9, >>>>>>>>>>>>> 15, 18, 19, and 20 are all titled "Packet Header Settings". >>>>>>>>>>>>> Would you like to make these titles more descriptive like Table >>>>>>>>>>>>> 12, which is titled "Packet Header Settings Between C and E"? If >>>>>>>>>>>>> so, please provide the wording. If not, should the title of Table >>>>>>>>>>>>> 12 >>>>>>>>>>>>> be updated for consistency with the other titles (i.e., update >>>>>>>>>>>>> as "Packet Header Settings")? >>>>>>>>>>>>> Note that Tables 2, 5, 8, 11, 14, and 17 are all titled "RIB >>>>>>>>>>>>> Settings", >>>>>>>>>>>>> and Tables 1, 4, 7, 10, 13, and 16 are all titled "P-DAO >>>>>>>>>>>>> Messages". >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > I'd leave as is. Michael ? >>>>>>>>>>>>> 20) <!--[rfced] Please clarify the meaning of "participates to" >>>>>>>>>>>>> in the >>>>>>>>>>>>> following sentence. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> Two protection paths of the same Track may cross at a common node >>>>>>>>>>>>> that participates to a segment of each protection path or that >>>>>>>>>>>>> may be joined by additional segments. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal> >>>>>>>>>>>>> Proposed: >>>>>>>>>>>>> Two protection paths of the same Track may cross at a common node >>>>>>>>>>>>> that is a member of a segment of each protection path or >>>>>>>>>>>>> may be joined by additional segments. >>>>>>>>>>>>> 21) <!--[rfced] The following text is difficult to read. May we >>>>>>>>>>>>> add >>>>>>>>>>>>> parentheses as shown below for clarity? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Note that while this specification enables building both segments >>>>>>>>>>>>> inside a protection path, for instance segment 2 above which is >>>>>>>>>>>>> within protection path 1, and Inter-protection-path segments >>>>>>>>>>>>> (i.e., >>>>>>>>>>>>> North-South), for instance segment 5 above which joins protection >>>>>>>>>>>>> path 1 and protection path 2, it does not signal to the Ingress >>>>>>>>>>>>> which >>>>>>>>>>>>> Inter-protection-path segments are available, so the use of North- >>>>>>>>>>>>> South segments and associated path redundancy functions is >>>>>>>>>>>>> currently >>>>>>>>>>>>> limited. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Note that while this specification enables building both segments >>>>>>>>>>>>> inside a protection path, for instance, segment 2 above (which is >>>>>>>>>>>>> within protection path 1) and Inter-protection-path segments >>>>>>>>>>>>> (i.e., >>>>>>>>>>>>> North-South) such as segment 5 above (which joins protection paths >>>>>>>>>>>>> 1 and 2), it does not signal which Inter-protection-path segments >>>>>>>>>>>>> are available to the Ingress, so the use of North-South segments >>>>>>>>>>>>> and associated path redundancy functions is currently limited. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > yes please >>>>>>>>>>>>> 22) <!-- [rfced] Please clarify this section title. We are unsure >>>>>>>>>>>>> what >>>>>>>>>>>>> "Positioning" refers to. In addition, not all of the RFCs >>>>>>>>>>>>> mentioned in >>>>>>>>>>>>> the section are Standards Track documents, so another term like >>>>>>>>>>>>> "Specifications" is more accurate. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> 3.7.2. Positioning vs. Related IETF Standards >>>>>>>>>>>>> Perhaps A: >>>>>>>>>>>>> 3.7.2. Related IETF Specifications >>>>>>>>>>>>> or >>>>>>>>>>>>> Perhaps B: >>>>>>>>>>>>> 3.7.2. Relationship to Other IETF Specifications >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'perhaps B' >>>>>>>>>>>>> 23) <!--[rfced] Does "In that case" refer to when the PCE is >>>>>>>>>>>>> collocated >>>>>>>>>>>>> with the Root or when it resides in an external controller? What >>>>>>>>>>>>> does "one possibility" refer to? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The PCE may be collocated with the Root, or may reside in an >>>>>>>>>>>>> external Controller. In that case, the protocol between the Root >>>>>>>>>>>>> and the PCE is out of scope and mapped to RPL inside the DODAG; >>>>>>>>>>>>> one >>>>>>>>>>>>> possibility is for the Root to transmit to the PCEs the >>>>>>>>>>>>> information >>>>>>>>>>>>> it received in RPL DAOs including all the SIOs that detail the >>>>>>>>>>>>> parent/child and sibling information. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > the latter case, external. "One possibility" means "One >>>>>>>>>>>>> possible control protocol between the root and the external PCE" >>>>>>>>>>>>> 24) <!--[rfced] May we revise this text to be two sentences to >>>>>>>>>>>>> improve >>>>>>>>>>>>> readability? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The RAW Architecture [RAW-ARCHI] extends the definition of Track, >>>>>>>>>>>>> as being composed of forward directional segments and North-South >>>>>>>>>>>>> bidirectional segments, to enable additional path diversity, using >>>>>>>>>>>>> Packet ARQ, Replication, Elimination, and Overhearing (PAREO) >>>>>>>>>>>>> functions over the available paths, to provide a dynamic balance >>>>>>>>>>>>> between the reliability and availability requirements of the flows >>>>>>>>>>>>> and the need to conserve energy and spectrum. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> 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 >>>>>>>>>>>>> PAREO functions over the available paths. This provides a dynamic >>>>>>>>>>>>> balance between the reliability and availability requirements of >>>>>>>>>>>>> the flows and the need to conserve energy and spectrum. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > We finally abandoned the term PAREO in RFC 9912. Please >>>>>>>>>>>>> use PREOF instead. and replace references to PAREO The text >>>>>>>>>>>>> above becomes: >>>>>>>>>>>>> " >>>>>>>>>>>>> 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 >>>>>>>>>>>>> PREOF functions over the available paths. This provides a dynamic >>>>>>>>>>>>> balance between the reliability and availability requirements of >>>>>>>>>>>>> the flows and the need to conserve energy and spectrum. >>>>>>>>>>>>> " >>>>>>>>>>>>> 25) <!-- [rfced] Should the title of this section include >>>>>>>>>>>>> "Amending" as the >>>>>>>>>>>>> section discusses how this document both "Extends" and "Amends"? >>>>>>>>>>>>> Or is >>>>>>>>>>>>> the current okay? >>>>>>>>>>>>> Current >>>>>>>>>>>>> 4. Extending Existing RFCs >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> 4. Extending and Amending Existing RFCs >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 26) <!--[rfced] Is "participate" the intended word or would >>>>>>>>>>>>> "function" be >>>>>>>>>>>>> clearer/correct? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Those 6LRs will be unable to participate in the new mechanisms, >>>>>>>>>>>>> but may also cause projected DAOs to be impossible to install. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Those 6LRs will be unable to function in the new mechanisms >>>>>>>>>>>>> and may also make the P-DAOs impossible to install. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 27) <!--[rfced] The titles of Sections 4.1, 4.2, and 4.3 do not >>>>>>>>>>>>> parse. How >>>>>>>>>>>>> may we update this for clarity? Is "RPL" necessary to include? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> 4.1. Extending RPL RFC 6550 >>>>>>>>>>>>> 4.2 Extending RPL RFC 6553 >>>>>>>>>>>>> 4.3 Extending RPL RFC 8138 >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> 4.1. Extending RFC 6550 >>>>>>>>>>>>> 4.2 Extending RFC 6553 >>>>>>>>>>>>> 4.3 Extending RFC 8138 >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 28) <!--[rfced] Does "it" refer to the DAO? If so, may we >>>>>>>>>>>>> rephrase the >>>>>>>>>>>>> text as shown below for clarity? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The P-DAO message generalizes the DAO to signal to the Track >>>>>>>>>>>>> Ingress that a Track for which it is the Root can be used to >>>>>>>>>>>>> reach children and siblings of the Track Egress. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The P-DAO message generalizes the DAO to signal the Track Ingress >>>>>>>>>>>>> that a track, for which the DAO is the root, can be used to reach >>>>>>>>>>>>> children and siblings of the Track Egress. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use: >>>>>>>>>>>>> " >>>>>>>>>>>>> The P-DAO message generalizes the DAO to signal the Track Ingress >>>>>>>>>>>>> that a track, for which the sender is the root, can be used to >>>>>>>>>>>>> reach >>>>>>>>>>>>> children and siblings of the Track Egress. >>>>>>>>>>>>> " >>>>>>>>>>>>> 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' >>>>>>>>>>>>> 30) <!--[rfced] FYI: We updated this sentence for clarity. Please >>>>>>>>>>>>> let us >>>>>>>>>>>>> know of any objection. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it is >>>>>>>>>>>>> ready >>>>>>>>>>>>> to be placed as is in the packet encapsulation by the Track >>>>>>>>>>>>> Ingress. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> When the SRH-6LoRH is signaled in the NSM-VIO, it is ready to be >>>>>>>>>>>>> placed as is in the packet encapsulation by the Track Ingress. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal: When is already present at the beginning of the paragraph >>>>>>>>>>>>> . Please use >>>>>>>>>>>>> " >>>>>>>>>>>>> In that case, the SRH-6LoRH is signaled in the NSM-VIO, and it is >>>>>>>>>>>>> expressed in a fashion that can be placed as is in the packet >>>>>>>>>>>>> encapsulation by the Track Ingress. >>>>>>>>>>>>> " >>>>>>>>>>>>> 31) <!--[rfced] FYI: We updated "Type" to "6LoRH Type" in Section >>>>>>>>>>>>> 4.3 to match the >>>>>>>>>>>>> name of the field in Figure 12. Please let us know if that is >>>>>>>>>>>>> incorrect. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Type: IANA is requested to define the same value of the type for >>>>>>>>>>>>> both Elective and Critical forms. A type of 8 is suggested. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> 6LoRH Type: IANA has defined the value 8 >>>>>>>>>>>>> for both the Elective and Critical forms. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 32) <!--[rfced] Please clarify "sets up the new information" in >>>>>>>>>>>>> this sentence. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The segment information indicated in the VIO deprecates any state >>>>>>>>>>>>> for the segment indicated by the P-RouteID within the indicated >>>>>>>>>>>>> Track and sets up the new information. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please replace >>>>>>>>>>>>> OLD >>>>>>>>>>>>> ' sets up the new information ' >>>>>>>>>>>>> with >>>>>>>>>>>>> NEW >>>>>>>>>>>>> ' provides the new information about the segment ' >>>>>>>>>>>>> 33) <!--[rfced] Is "so the routing can consider" the intending >>>>>>>>>>>>> wording >>>>>>>>>>>>> or would one of the following suggestions be more clear? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance >>>>>>>>>>>>> can be >>>>>>>>>>>>> expected in both directions, so the routing can consider that the >>>>>>>>>>>>> information provided for one direction is valid for both. >>>>>>>>>>>>> Perhaps A: >>>>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance >>>>>>>>>>>>> can >>>>>>>>>>>>> be expected in both directions, so the routing can identify that >>>>>>>>>>>>> the information provided for one direction is valid for both. >>>>>>>>>>>>> or >>>>>>>>>>>>> Perhaps B: >>>>>>>>>>>>> The SIO carries a flag (B) that is set when similar performance >>>>>>>>>>>>> can >>>>>>>>>>>>> be expected in both directions; this flag indicates to the >>>>>>>>>>>>> routing that >>>>>>>>>>>>> the information provided for one direction is valid for both. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>>>> 34) <!--[rfced] We note "Type" in Figure 17 but "Option Type" in >>>>>>>>>>>>> the >>>>>>>>>>>>> corresponding description in the running text. Should Figure 17 >>>>>>>>>>>>> be updated to reflect "Option Type" for consistency with the >>>>>>>>>>>>> running text? >>>>>>>>>>>>> Current: >>>>>>>>>>>>> 0 1 2 3 >>>>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>>>> | Type | Option Length |S|B|Flags|Comp.| Opaque | >>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>>>> Option Type: 0x11 for SIO (see Table 26). >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> 0 1 2 3 >>>>>>>>>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>>>> | Option Type | Option Length |S|B|Flags|Comp.| Opaque | >>>>>>>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>>>>>>>>> Option Type: 0x11 for SIO (see Table 26). >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 35) <!--[rfced] Should "MUST" be added to the latter part of this >>>>>>>>>>>>> sentence >>>>>>>>>>>>> (e.g., a P-DAO "MUST signal the full list of hops")? This would >>>>>>>>>>>>> make it parallel with the first part of the sentence. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> A P-DAO that creates a new Track segment MUST be sent to a GUA or >>>>>>>>>>>>> a >>>>>>>>>>>>> ULA of the segment Egress and MUST signal the full list of hops in >>>>>>>>>>>>> segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>>>> and >>>>>>>>>>>>> signal the full list of hops in the section starting at the node >>>>>>>>>>>>> that >>>>>>>>>>>>> immediately precedes the modified section. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> A P-DAO that creates a new Track segment MUST be sent to a GUA or >>>>>>>>>>>>> a >>>>>>>>>>>>> ULA of the segment Egress and MUST signal the full list of hops in >>>>>>>>>>>>> a segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>>>> and >>>>>>>>>>>>> MUST signal the full list of hops in the section starting at the >>>>>>>>>>>>> node >>>>>>>>>>>>> that immediately precedes the modified section. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > earlier you eliminated the second MUST making it a >>>>>>>>>>>>> common factor. Following that logic you could do: >>>>>>>>>>>>> " A P-DAO that creates a new Track segment MUST be sent to a GUA >>>>>>>>>>>>> or a >>>>>>>>>>>>> ULA of the segment Egress and signal the full list of hops in >>>>>>>>>>>>> segment; a P-DAO that updates (including deletes) a section of a >>>>>>>>>>>>> segment MUST be sent to the first node after the modified segment >>>>>>>>>>>>> and >>>>>>>>>>>>> signal the full list of hops in the section starting at the node >>>>>>>>>>>>> that >>>>>>>>>>>>> immediately precedes the modified section >>>>>>>>>>>>> " >>>>>>>>>>>>> Either that or 'Perhaps' work for me. >>>>>>>>>>>>> 36) <!-- [rfced] Figure 19 contains the non-ASCII character "°". >>>>>>>>>>>>> Is this >>>>>>>>>>>>> intentional/significant? Or should it be updated to "o", which is >>>>>>>>>>>>> used in >>>>>>>>>>>>> the rest of the figure? >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > it is not significant. It is just for visualization to >>>>>>>>>>>>> show different devices. Your call on this. >>>>>>>>>>>>> 37) <!--[rfced] Is "and results in" the intended wording here, or >>>>>>>>>>>>> may we >>>>>>>>>>>>> revise the sentence as shown below and use "Its function" instead >>>>>>>>>>>>> for clarity? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and >>>>>>>>>>>>> results in >>>>>>>>>>>>> cleaning up existing state as opposed to refreshing an existing >>>>>>>>>>>>> one or >>>>>>>>>>>>> installing a new one. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its >>>>>>>>>>>>> function is to clean up an existing state as opposed to >>>>>>>>>>>>> refreshing it >>>>>>>>>>>>> or installing a new one. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 38) <!--[rfced] In Section 6.7, we rephrased the second bullet >>>>>>>>>>>>> point in >>>>>>>>>>>>> order to connect it more clearly to the lead-in sentence. Please >>>>>>>>>>>>> let us know if the update is agreeable or if you prefer otherwise. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> * The preferred alternative in a network where 6LoWPAN Header >>>>>>>>>>>>> Compression [RFC6282] is used is to leverage "IPv6 over Low-Power >>>>>>>>>>>>> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >>>>>>>>>>>>> [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> * To compress RPL artifacts in data packets as indicated in >>>>>>>>>>>>> [RFC8138], the preferred alternative in a network where 6LoWPAN >>>>>>>>>>>>> header compression [RFC6282] is used is to implement the method >>>>>>>>>>>>> described in "IPv6 over Low-Power Wireless Personal Area Network >>>>>>>>>>>>> (6LoWPAN) Paging Dispatch" [RFC8025]. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > Please retain the original. Or a mix like >>>>>>>>>>>>> " >>>>>>>>>>>>> * In a network where 6LoWPAN Header Compression [RFC6282] is in >>>>>>>>>>>>> use, >>>>>>>>>>>>> it is preferred to implement "IPv6 over Low-Power >>>>>>>>>>>>> Wireless Personal Area Network (6LoWPAN) Paging Dispatch" >>>>>>>>>>>>> [RFC8025] and compress the RPL artifacts as indicated in >>>>>>>>>>>>> [RFC8138]. >>>>>>>>>>>>> " >>>>>>>>>>>>> 39) <!--[rfced] May we update this sentence as shown below for >>>>>>>>>>>>> clarity and >>>>>>>>>>>>> easier readability? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The packet processing uses a precedence that favors self delivery >>>>>>>>>>>>> or routing header handling when one is present, then delivery to >>>>>>>>>>>>> direct neighbors, then to indirect neighbors, then routing along a >>>>>>>>>>>>> segment along the Track, and finally as a last resort injecting >>>>>>>>>>>>> the >>>>>>>>>>>>> packet in another Track. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Packet processing uses the following precedence: 1) self-delivery >>>>>>>>>>>>> or routing header handling when one is present, 2) delivery to >>>>>>>>>>>>> direct neighbors, 3) delivery to indirect neighbors, 4) routing >>>>>>>>>>>>> along a segment along the Track, and 5) injecting the packet in >>>>>>>>>>>>> another Track, as a last resort. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 40) <!-- [rfced] Will "either of the reasons above" be clear to >>>>>>>>>>>>> readers? Does this >>>>>>>>>>>>> mean "in any of the steps above"? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The node that drops a packet for either of the reasons above MUST >>>>>>>>>>>>> send an ICMPv6 Error message [RFC4443] to the Root, with a new >>>>>>>>>>>>> Code >>>>>>>>>>>>> "Error in P-Route" (See Section 11.15). >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The node that drops a packet in any of the steps above MUST >>>>>>>>>>>>> send an ICMPv6 Error message [RFC4443] to the Root, with a new >>>>>>>>>>>>> Code >>>>>>>>>>>>> "Error in P-Route" (See Section 11.15). >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 41) <!--[rfced] May we revise this text into two sentences for >>>>>>>>>>>>> easier >>>>>>>>>>>>> readability and update "remove the leftover" to "the Root can >>>>>>>>>>>>> remove the leftover" for clarity? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>>>> Tracks, and in the case of a broken segment, remove the leftover >>>>>>>>>>>>> sections of the segment using SM-VIOs with a lifetime of 0 >>>>>>>>>>>>> indicating the section to one or more nodes being removed (See >>>>>>>>>>>>> Section 6.6). >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>>>> Tracks. In the case of a broken segment, the Root can remove the >>>>>>>>>>>>> leftover sections of the segment using SM-VIOs with a lifetime of >>>>>>>>>>>>> 0, indicating the section where one or more nodes are being >>>>>>>>>>>>> removed >>>>>>>>>>>>> (see Section 6.6). >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use >>>>>>>>>>>>> " >>>>>>>>>>>>> The Root can then repair by updating the broken segment and/or >>>>>>>>>>>>> Tracks. In the case of a broken segment, the Root removes the >>>>>>>>>>>>> leftover sections of the segment using SM-VIOs with a lifetime of >>>>>>>>>>>>> 0, indicating the section where one or more nodes are being >>>>>>>>>>>>> removed >>>>>>>>>>>>> (see Section 6.6). >>>>>>>>>>>>> " >>>>>>>>>>>>> 42) <!--[rfced] We find "using [RFC8138] in the main DODAG" >>>>>>>>>>>>> unclear. >>>>>>>>>>>>> Please clarify what is being applied from RFC 8138 in the main >>>>>>>>>>>>> DODAG. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> When using [RFC8138] in the main DODAG operated in Non-Storing >>>>>>>>>>>>> Mode >>>>>>>>>>>>> in a 6LoWPAN LLN, a typical packet that circulates in the main >>>>>>>>>>>>> DODAG >>>>>>>>>>>>> is formatted as shown in Figure 20, representing the case where an >>>>>>>>>>>>> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use >>>>>>>>>>>>> " >>>>>>>>>>>>> When the main DODAG in a 6LoWPAN LLN is operated in Non-Storing >>>>>>>>>>>>> Mode and the >>>>>>>>>>>>> data packets are compressed using [RFC8138, a typical packet that >>>>>>>>>>>>> circulates in the main DODAG >>>>>>>>>>>>> is formatted as shown in Figure 20, representing the case where an >>>>>>>>>>>>> IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]): >>>>>>>>>>>>> " >>>>>>>>>>>>> 43) <!--[rfced] This sentence is hard to parse. Please let us >>>>>>>>>>>>> know if the >>>>>>>>>>>>> suggested update captures the intended meaning or if you prefer >>>>>>>>>>>>> otherwise. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> At the head of the resulting sequence of bytes, the track Ingress >>>>>>>>>>>>> then adds the RPI that carries the TrackID as RPLinstanceID as a >>>>>>>>>>>>> P- >>>>>>>>>>>>> RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID >>>>>>>>>>>>> as >>>>>>>>>>>>> RPLInstanceID. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> At the head of the resulting sequence of bytes, the Track Ingress >>>>>>>>>>>>> then adds the RPI that carries the P-RPI-6LoRH Header (as >>>>>>>>>>>>> illustrated in Figure 12) and uses the TrackID as the >>>>>>>>>>>>> RPLInstanceID. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use >>>>>>>>>>>>> " >>>>>>>>>>>>> At the head of the resulting sequence of bytes, the track Ingress >>>>>>>>>>>>> then adds a P-RPI-6LoRH Header to transport the RPI in its >>>>>>>>>>>>> compressed form as illustrated in Figure 12. The RPI carries the >>>>>>>>>>>>> TrackID as RPLinstanceID. >>>>>>>>>>>>> " >>>>>>>>>>>>> 44) <!--[rfced] Please clarify "at the expense of". Does this >>>>>>>>>>>>> mean that >>>>>>>>>>>>> route stretch is used rather than the shortest path routes? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> RPL requires less resources than alternative IGPs like OSPF, ISIS, >>>>>>>>>>>>> EIGRP, BABEL or RIP at the expense of a route stretch vs. the >>>>>>>>>>>>> shortest path routes to a destination that those protocols >>>>>>>>>>>>> compute. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> RPL requires fewer resources than alternative IGPs such as OSPF, >>>>>>>>>>>>> IS-IS, >>>>>>>>>>>>> the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or >>>>>>>>>>>>> RIP >>>>>>>>>>>>> when using route stretch rather than the shortest path routes to a >>>>>>>>>>>>> destination that those protocols compute. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 45) <!--[rfced] Is "ANIMA" needed in this sentence or can it be >>>>>>>>>>>>> removed or >>>>>>>>>>>>> replaced with the title of RFC 8994? We note that the title of >>>>>>>>>>>>> RFC 8994 is "An Autonomic Control Plane (ACP)", so we are not >>>>>>>>>>>>> sure how "ANIMA" relates as it is not mentioned in Appendix >>>>>>>>>>>>> A.9.4. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> P-Routes add the capability to install shortest and/or constrained >>>>>>>>>>>>> routes to special destinations such as discussed in Appendix A.9.4 >>>>>>>>>>>>> of the ANIMA ACP [RFC8994]. >>>>>>>>>>>>> Perhaps A: >>>>>>>>>>>>> P-Routes add the capability to install the shortest and/or >>>>>>>>>>>>> constrained >>>>>>>>>>>>> routes to special destinations as discussed in Appendix A.9.4 >>>>>>>>>>>>> of [RFC8994]. >>>>>>>>>>>>> or >>>>>>>>>>>>> Perhaps B: >>>>>>>>>>>>> P-Routes add the capability to install the shortest and/or >>>>>>>>>>>>> constrained >>>>>>>>>>>>> routes to special destinations as discussed in Appendix A.9.4 of >>>>>>>>>>>>> "An Autonomic Control Plane (ACP)" [RFC8994]. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>>>> 46) <!--[rfced] Does "is that of" mean "a part of"? And does the >>>>>>>>>>>>> Ingress >>>>>>>>>>>>> node encapsulate the RPL Instance or the main DODAG? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The RPL Instance is that of the main DODAG, and the Ingress >>>>>>>>>>>>> node that encapsulates is not the Root. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The RPL Instance is a part of the main DODAG, and the Ingress >>>>>>>>>>>>> node that encapsulates the RPL Instance is not the Root. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use >>>>>>>>>>>>> ' >>>>>>>>>>>>> The RPL Instance is the one that runs the main DODAG, and the >>>>>>>>>>>>> Ingress >>>>>>>>>>>>> node that encapsulates the RPL Instance is not the Root. >>>>>>>>>>>>> ' >>>>>>>>>>>>> 47) <!--[rfced] How may we clarify "an order other than that of"? >>>>>>>>>>>>> Is the >>>>>>>>>>>>> intended meaning that the PLR's metrics are in a different order >>>>>>>>>>>>> than the PCE's metrics? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The expectation is that the metrics that the PLR uses are of an >>>>>>>>>>>>> order other than that of the PCE, because of the difference of >>>>>>>>>>>>> time scale between routing and forwarding, more in [RAW-ARCHI]. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The expectation is that the PLR's metrics will be in a different >>>>>>>>>>>>> order >>>>>>>>>>>>> than the PCE's metrics because of the difference in the timescale >>>>>>>>>>>>> between routing and forwarding; see more in [RAW-ARCH]. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 48) <!--[rfced] Is "Target/Transit information tuples" correct, >>>>>>>>>>>>> or should >>>>>>>>>>>>> it be "Target/TIO tuples" for consistency? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Note that the Path Sequence and Lifetime in the TIO are selected >>>>>>>>>>>>> by >>>>>>>>>>>>> the Root and that the Target/Transit information tuples in the >>>>>>>>>>>>> P-DAO are not those received by the Root in the DAO messages about >>>>>>>>>>>>> the said Targets. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Note that the Path Sequence and Lifetime in the TIO are selected >>>>>>>>>>>>> by >>>>>>>>>>>>> the Root and that the Target/TIO tuples in the P-DAO are not those >>>>>>>>>>>>> received by the Root in the DAO messages about the said Targets. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please retain the original >>>>>>>>>>>>> 49) <!--[rfced] Can these sentences be combined to reduce >>>>>>>>>>>>> redundancy? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> This section describes profiles that can be implemented separately >>>>>>>>>>>>> and can be used to discriminate what an implementation can and >>>>>>>>>>>>> cannot >>>>>>>>>>>>> do. This section describes profiles that enable implementing >>>>>>>>>>>>> only a >>>>>>>>>>>>> portion of this specification to meet a particular use case. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> This section describes profiles that can be implemented >>>>>>>>>>>>> separately, >>>>>>>>>>>>> e.g., using only a portion of this specification to meet a >>>>>>>>>>>>> particular use >>>>>>>>>>>>> case, and can be used to discriminate what an implementation can >>>>>>>>>>>>> and cannot do. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 50) <!--[rfced] Please clarify what "its" is referring to in the >>>>>>>>>>>>> following. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Profile 3 and above leverage Local RPL Instances to build >>>>>>>>>>>>> arbitrary >>>>>>>>>>>>> Tracks Rooted at the Track Ingress and using its namespace for >>>>>>>>>>>>> TrackID >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Profile 3 and above leverage Local RPL Instances to build >>>>>>>>>>>>> arbitrary >>>>>>>>>>>>> Tracks rooted at the Track Ingress, using the namespace of the >>>>>>>>>>>>> Track Ingress for the TrackID. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 51) <!-- [rfced] FYI - We updated the "/" here to "or". Let us >>>>>>>>>>>>> know if another >>>>>>>>>>>>> meaning is intended. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Profile 2 is >>>>>>>>>>>>> RECOMMENDED in a high speed / wired environment to enable Traffic >>>>>>>>>>>>> Engineering and network automation. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Profile 2 is >>>>>>>>>>>>> RECOMMENDED in a high-speed or wired environment to enable Traffic >>>>>>>>>>>>> Engineering and network automation. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use >>>>>>>>>>>>> " >>>>>>>>>>>>> Profile 2 is >>>>>>>>>>>>> RECOMMENDED in a high speed (e.g., wired) environment to enable >>>>>>>>>>>>> Traffic >>>>>>>>>>>>> Engineering and network automation. >>>>>>>>>>>>> " >>>>>>>>>>>>> 52) <!--[rfced] Please clarify "on top". Is it necessary to >>>>>>>>>>>>> include in >>>>>>>>>>>>> this sentence? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> The other Profiles extend Profile 0 with selected capabilities >>>>>>>>>>>>> that this specification introduces on top. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> The other profiles extend Profile 0 with selected capabilities >>>>>>>>>>>>> that this specification introduces. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 53) <!--[rfced] Is "source routing" correct in these sentences, >>>>>>>>>>>>> or should >>>>>>>>>>>>> it be "source-routed" per Table 26? >>>>>>>>>>>>> Current: >>>>>>>>>>>>> Profile 2 extends Profile 0 with strict source routing Non-Storing >>>>>>>>>>>>> Mode P-Routes along the main DODAG, which is the same as Profile 1 >>>>>>>>>>>>> but using NSM-VIOs as opposed to SM-VIOs. >>>>>>>>>>>>> Profile 4 extends Profile 2 with strict source routing Non-Storing >>>>>>>>>>>>> Mode P-Routes to form forward Tracks that are inside the main >>>>>>>>>>>>> DODAG but do not necessarily follow it. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Profile 2 extends Profile 0 with strict source-routed Non-Storing >>>>>>>>>>>>> Mode P-Routes along the main DODAG, which is the same as Profile 1 >>>>>>>>>>>>> but using NSM-VIOs as opposed to SM-VIOs. >>>>>>>>>>>>> Profile 4 extends Profile 2 with strict source-routed Non-Storing >>>>>>>>>>>>> Mode P-Routes to form forward Tracks that are inside the main >>>>>>>>>>>>> DODAG but do not necessarily follow it. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 54) <!--[rfced] FYI: We updated "In that case" to "With Profile >>>>>>>>>>>>> 2" for >>>>>>>>>>>>> clarity. Please let us know if that is not correct. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> In that case, the Tracks MUST be installed as subTracks of the >>>>>>>>>>>>> main >>>>>>>>>>>>> DODAG, the main Instance MUST be used as TrackID. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> With Profile 2, the Tracks MUST be installed as subTracks of the >>>>>>>>>>>>> main >>>>>>>>>>>>> DODAG, and the main Instance MUST be used as the TrackID. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > OK >>>>>>>>>>>>> 55) <!--[rfced] We are having trouble parsing this sentence; it >>>>>>>>>>>>> reads as >>>>>>>>>>>>> if 6TiSCH defined RFC 9031. Is the intended meaning that 6TiSCH >>>>>>>>>>>>> is defined in RFC 9031? Please let us know how we may clarify the >>>>>>>>>>>>> text. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> 6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > the 6TiSCH WG defined ... Let's reword, e.g.,: >>>>>>>>>>>>> " >>>>>>>>>>>>> The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the >>>>>>>>>>>>> RPL Root as 6LBR. >>>>>>>>>>>>> " >>>>>>>>>>>>> 56) <!--[rfced] We are having trouble parsing the latter part of >>>>>>>>>>>>> this >>>>>>>>>>>>> sentence (i.e., "by avoiding that a node appears twice"). How may >>>>>>>>>>>>> we update this for clarity? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>>>> basic loops by avoiding that a node appears twice. >>>>>>>>>>>>> Perhaps A: >>>>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>>>> basic loops when a node appears twice. >>>>>>>>>>>>> or >>>>>>>>>>>>> Perhaps B: >>>>>>>>>>>>> This specification suggests some validation of the VIO to prevent >>>>>>>>>>>>> basic loops, i.e., by avoiding a node that appears twice. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please use 'Perhaps B' >>>>>>>>>>>>> 57) <!-- [rfced] We have included some specific questions about >>>>>>>>>>>>> the IANA >>>>>>>>>>>>> text below. In addition to responding to those questions, please >>>>>>>>>>>>> review all of the IANA-related updates carefully and let us know >>>>>>>>>>>>> if any further updates are needed. >>>>>>>>>>>>> a) Text relating to the "Mode of Operation" registry appears in >>>>>>>>>>>>> Section 11.1 >>>>>>>>>>>>> after the information for the "DODAG Configuration Option Flags >>>>>>>>>>>>> for MOP 0..6" >>>>>>>>>>>>> registry. May we create a new subsection for this text, perhaps >>>>>>>>>>>>> titled "Mode of >>>>>>>>>>>>> Operation"? >>>>>>>>>>>>> Current: >>>>>>>>>>>>> IANA has added this RFC as an additional reference for MOP 7 in >>>>>>>>>>>>> the >>>>>>>>>>>>> "Mode of Operation" registry under the "Routing Protocol for Low >>>>>>>>>>>>> Power and Lossy Networks (RPL)" registry group [IANA-RPL]. >>>>>>>>>>>>> Pascal > please leave as is >>>>>>>>>>>>> b) In Table 26, may we include the expansions of "SM-VIO" and >>>>>>>>>>>>> "NSM-VIO" for >>>>>>>>>>>>> clarity and consistency with the running text? Note that we will >>>>>>>>>>>>> communicate >>>>>>>>>>>>> any updates to IANA. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> 0x0F Stateful VIO (SM-VIO) >>>>>>>>>>>>> 0x10 Source-Routed VIO (NSM-VIO) >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> 0x0F Stateful Storing Mode VIO (SM-VIO) >>>>>>>>>>>>> 0x10 Source-Routed Non-Storing Mode VIO (NSM-VIO) >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> c) In Section 5.3, should "stateful" and "source-routed" be >>>>>>>>>>>>> included >>>>>>>>>>>>> in the description for "Option Type" per Table 26? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> Option Type: 0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26). >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Option Type: 0x0F for stateful SM-VIO and 0x10 for source-routed >>>>>>>>>>>>> NSM-VIO (see Table 26). >>>>>>>>>>>>> Please leave as is. stateful is not part of the name, it is a >>>>>>>>>>>>> characteristic. >>>>>>>>>>>>> d) In both the "PDR-ACK Acceptance Status Values" and "PDR-ACK >>>>>>>>>>>>> Rejection >>>>>>>>>>>>> Status Values" registries >>>>>>>>>>>>> <https://www.iana.org/assignments/rpl/>, the first >>>>>>>>>>>>> column is titled "Bit Number"; however, in Tables 28 and 29 of >>>>>>>>>>>>> this document, >>>>>>>>>>>>> the first column is titled "Value". Please let us know which term >>>>>>>>>>>>> you prefer >>>>>>>>>>>>> ("Bit Number" or "Value") and we will make the document and >>>>>>>>>>>>> registries >>>>>>>>>>>>> consistent. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > great catch. This is a bug in the IANA registry, >>>>>>>>>>>>> probably a cc of the previous entry. Please use 'value' >>>>>>>>>>>>> 58) <!-- [rfced] Would you like the references to be alphabetized >>>>>>>>>>>>> or left in their current order? >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please leave as is >>>>>>>>>>>>> 59) <!--[rfced] FYI: "draft-kuehlewind-update-tag" has been >>>>>>>>>>>>> replaced by >>>>>>>>>>>>> "draft-kuehlewind-rswg-updates-tag", so we have updated this >>>>>>>>>>>>> reference entry accordingly. Please let us know of any objection. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [I-D.kuehlewind-update-tag] >>>>>>>>>>>>> Kühlewind, M. and S. Krishnan, "Definition of new tags for >>>>>>>>>>>>> relations between RFCs", Work in Progress, Internet-Draft, >>>>>>>>>>>>> draft-kuehlewind-update-tag-04, 12 July 2021, >>>>>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >>>>>>>>>>>>> update-tag-04>. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> [NEW-TAGS] >>>>>>>>>>>>> Kühlewind, M. and S. Krishnan, "Definition of new tags for >>>>>>>>>>>>> relations between RFCs", Work in Progress, Internet-Draft, >>>>>>>>>>>>> draft-kuehlewind-rswg-updates-tag-02, 8 July 2024, >>>>>>>>>>>>> <https://datatracker.ietf.org/doc/html/draft-kuehlewind- >>>>>>>>>>>>> rswg-updates-tag-02>. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > thanks >>>>>>>>>>>>> 60) <!-- [rfced] FYI: We have updated this reference's URL to use >>>>>>>>>>>>> the >>>>>>>>>>>>> following URL, which points to the "IPv6 Low Power Personal Area >>>>>>>>>>>>> Network Parameters" registry: >>>>>>>>>>>>> <https://www.iana.org/assignments/_6lowpan-parameters>. Please >>>>>>>>>>>>> let us know if this is incorrect. >>>>>>>>>>>>> Original: >>>>>>>>>>>>> [IANA-6LO] IETF, "IPv6 Low Power Personal Area Network Parameters >>>>>>>>>>>>> registry", >>>>>>>>>>>>> <https://www.iana.org/assignments/icmpv6-parameters/>. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> [IANA-6LO] IANA, "IPv6 Low Power Personal Area Network >>>>>>>>>>>>> Parameters", >>>>>>>>>>>>> <https://www.iana.org/assignments/_6lowpan-parameters>. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > thanks >>>>>>>>>>>>> 61) <!-- [rfced] Some author comments are present in the XML. >>>>>>>>>>>>> Please confirm that >>>>>>>>>>>>> no updates related to these comments are outstanding. Note that >>>>>>>>>>>>> the >>>>>>>>>>>>> comments will be deleted prior to publication. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > confirmed >>>>>>>>>>>>> 62) <!-- [rfced] Terminology >>>>>>>>>>>>> a) Throughout the text, the following terminology appears to be >>>>>>>>>>>>> used >>>>>>>>>>>>> inconsistently. Please review these occurrences and let us know >>>>>>>>>>>>> if/how they >>>>>>>>>>>>> may be made consistent. >>>>>>>>>>>>> Complex Track vs. complex Track >>>>>>>>>>>>> Pascal > please use Complex Track as per RFC 9030 >>>>>>>>>>>>> Objective Function vs. objective function >>>>>>>>>>>>> Pascal > please use "Objective Function" as per RFC 6550 >>>>>>>>>>>>> Instance vs. instance >>>>>>>>>>>>> [Note: is "topologies called instances" correct or should it be >>>>>>>>>>>>> "Instances"? Should any other lowercase occurrences be >>>>>>>>>>>>> uppercase?] Global Instance vs. global instance >>>>>>>>>>>>> [Note: "Global RPL Instance" and "Global instance" used in RFC >>>>>>>>>>>>> 6550 >>>>>>>>>>>>> and "Global Instance 0" used in RFC 8138] >>>>>>>>>>>>> Local Instance >>>>>>>>>>>>> main Instance vs. main instance >>>>>>>>>>>>> RPL Instance vs. RPL instance >>>>>>>>>>>>> [Note: "RPL Instance" used in RFCs 6550, 6553, and 8138 and >>>>>>>>>>>>> companion document draft-ietf-raw-technologies-17] >>>>>>>>>>>>> Track Instance vs. Track instance >>>>>>>>>>>>> Pascal > please use " Instance " as per RFC 6550 in all cases >>>>>>>>>>>>> Rejection Status vs. rejection status >>>>>>>>>>>>> [Note: "rejection status" used in RFC 6550) >>>>>>>>>>>>> Pascal > please use "rejection status" as per RFC 6550 >>>>>>>>>>>>> Root vs. root >>>>>>>>>>>>> [Note: There are 7 lowercase instances, plus one within quoted >>>>>>>>>>>>> text. >>>>>>>>>>>>> Aside from the quoted text, should any of these be made uppercase >>>>>>>>>>>>> for consistency?] >>>>>>>>>>>>> Pascal > please use " Root " as per RFC 6550 in all cases >>>>>>>>>>>>> Routing Header vs. routing header >>>>>>>>>>>>> [Note: "Routing Header" used in RFC 8138. Also, after the first >>>>>>>>>>>>> expansion, may we replace this term with "RH"?] >>>>>>>>>>>>> Pascal > please use " Routing Header " as per RFC 8138 >>>>>>>>>>>>> in all cases >>>>>>>>>>>>> Segment ID (4) vs. SegmentID (6) >>>>>>>>>>>>> Pascal > please use " SegmentID " in all cases >>>>>>>>>>>>> Track ID (3) vs. TrackID (90) >>>>>>>>>>>>> Pascal > please use " TrackID " in all cases >>>>>>>>>>>>> Target (77) vs. target (11) >>>>>>>>>>>>> Pascal > please leave the text as is >>>>>>>>>>>>> Type of 4 vs. type 4 (also, type 3 and type 5) >>>>>>>>>>>>> Pascal > please use "type 4" >>>>>>>>>>>>> b) FYI: We updated the following terms to reflect the forms on the >>>>>>>>>>>>> right for consistency. Please let us know of any objection. >>>>>>>>>>>>> 6LoWPAN Header Compression -> 6LoWPAN header compression (per RFC >>>>>>>>>>>>> 8138) >>>>>>>>>>>>> 6LoWPAN Network -> 6LoWPAN network >>>>>>>>>>>>> 6TiSCH Architecture -> 6TiSCH architecture >>>>>>>>>>>>> Backbone -> backbone (per RFC 6550) >>>>>>>>>>>>> base Object and base object -> Base Object >>>>>>>>>>>>> Border Router and Border router -> border router (per RFC 6550) >>>>>>>>>>>>> Code -> code (per RFC 6550) >>>>>>>>>>>>> dataplane -> data plane (per companion document >>>>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>>>> Destination Address -> destination address >>>>>>>>>>>>> DODAG Configuration Option -> DODAG Configuration option (per RFC >>>>>>>>>>>>> 6550) >>>>>>>>>>>>> DODAG ID -> DODAGID >>>>>>>>>>>>> Extension Header and extension Header -> extension header >>>>>>>>>>>>> external Controller -> external controller >>>>>>>>>>>>> global RPLInstanceID -> Global RPLInstanceID >>>>>>>>>>>>> IPv6 Address -> IPv6 address >>>>>>>>>>>>> IPv6 Header -> IPv6 header (per RFC 8138) >>>>>>>>>>>>> Legacy -> legacy (per companion document >>>>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>>>> Link-Layer security -> link-layer security (per RFC 9010) >>>>>>>>>>>>> local RPL Instance -> Local RPL Instance (per RFC 6550 and >>>>>>>>>>>>> companion >>>>>>>>>>>>> document draft-ietf-raw-technologies-17) >>>>>>>>>>>>> local RPLInstanceID -> Local RPLInstanceID (per companion document >>>>>>>>>>>>> draft-ietf-raw-technologies-17) >>>>>>>>>>>>> loose Source Routing -> loose source routing >>>>>>>>>>>>> multihop -> multi-hop (per RFC 8930 and companion documents) >>>>>>>>>>>>> Non-Storing mode and non-storing mode -> Non-Storing Mode >>>>>>>>>>>>> Non-Storing P-DAO -> Non-Storing Mode P-DAO >>>>>>>>>>>>> P-route -> P-Route >>>>>>>>>>>>> Protection Path -> protection path (to match companion documents) >>>>>>>>>>>>> Protection service -> protection service >>>>>>>>>>>>> RAW Architecture -> RAW architecture (to match companion >>>>>>>>>>>>> documents) >>>>>>>>>>>>> Recovery Graph -> recovery graph (per companion document >>>>>>>>>>>>> draft-ietf-raw-architecture-30) >>>>>>>>>>>>> Routing Stretch -> routing stretch >>>>>>>>>>>>> RPL InstanceID and RPLinstanceID -> RPLInstanceID >>>>>>>>>>>>> RPL Network -> RPL network >>>>>>>>>>>>> segment Lifetime of zero -> Segment Lifetime of 0 >>>>>>>>>>>>> Sibling Information option -> Sibling Information Option >>>>>>>>>>>>> Source Address -> source address (per RFC 6550) >>>>>>>>>>>>> Source Route path -> source route path (per RFCs 6550 and 8138) >>>>>>>>>>>>> Stand-Alone -> stand-alone >>>>>>>>>>>>> Storing mode and storing mode -> Storing Mode >>>>>>>>>>>>> Strict -> strict >>>>>>>>>>>>> time scale -> timescale (per companion document >>>>>>>>>>>>> draft-ietf-raw-architecture-30) >>>>>>>>>>>>> track -> Track (5 instances) >>>>>>>>>>>>> traffic Engineering -> Traffic Engineering (per companion >>>>>>>>>>>>> documents) >>>>>>>>>>>>> VIA Address -> Via address >>>>>>>>>>>>> Via Information option -> Via Information Option >>>>>>>>>>>>> Pascal > Absolutely great. please note that the companion drafts >>>>>>>>>>>>> are RFC 9912 and RFC 9913 so this text will change >>>>>>>>>>>>> c) Please review the following capitalization inconsistencies in >>>>>>>>>>>>> the names of >>>>>>>>>>>>> nodes and let us know how to update for consistency. Note that >>>>>>>>>>>>> the first three >>>>>>>>>>>>> terms below appeared in the companion document >>>>>>>>>>>>> draft-ietf-raw-architecture-30, >>>>>>>>>>>>> and the author chose to use "egress node", "ingress node", and >>>>>>>>>>>>> "relay node" >>>>>>>>>>>>> (all lowercase). If you would like to follow this pattern in this >>>>>>>>>>>>> document, >>>>>>>>>>>>> please also review instances of "Egress" and "Ingress" when not >>>>>>>>>>>>> in the >>>>>>>>>>>>> context of "Egress Node" and "Ingress Node" (e.g., "the Track >>>>>>>>>>>>> Egress", "from >>>>>>>>>>>>> Ingress to Egress") and let us know they should be lowercased as >>>>>>>>>>>>> well. >>>>>>>>>>>>> Pascal > the "Track Egress" is really the Track egress node so >>>>>>>>>>>>> your proposal works there too. >>>>>>>>>>>>> Note that "Root Node" and "Forwarding Node" did not appear in the >>>>>>>>>>>>> companion >>>>>>>>>>>>> documents. >>>>>>>>>>>>> Egress Node vs. Egress node >>>>>>>>>>>>> Ingress Node vs. Ingress node >>>>>>>>>>>>> Relay Node vs. Relay node >>>>>>>>>>>>> [Note: "relay node" used in RFC 8655] >>>>>>>>>>>>> Pascal > Please use lowercase for "forwarding", "node", >>>>>>>>>>>>> "ingress", and "egress" in all cases. Root is inherited from RFC >>>>>>>>>>>>> 6550 so please leave it uppercase. >>>>>>>>>>>>> Root Node >>>>>>>>>>>>> Forwarding Node vs. forwarding Node >>>>>>>>>>>>> d) Please let us know if/how we may make these terms consistent. >>>>>>>>>>>>> Projected DAO-ACK vs. P-DAO-ACK >>>>>>>>>>>>> [Note: Is "P-DAO-ACK" short for "Projected DAO-ACK" >>>>>>>>>>>>> Pascal > yes >>>>>>>>>>>>> or are these different terms? In Section 4.1.1, should the first >>>>>>>>>>>>> mention of "P-DAO-ACK" be updated as "Projected DAO-ACK >>>>>>>>>>>>> (P-DAO-ACK)"?] >>>>>>>>>>>>> Pascal > Please use "Projected " on first use then P. >>>>>>>>>>>>> routing stretch vs. route stretch >>>>>>>>>>>>> Pascal > Please "routing stretch " >>>>>>>>>>>>> RPL DODAG Configuration option vs. RPL configuration option vs. >>>>>>>>>>>>> DODAG Configuration option >>>>>>>>>>>>> Pascal > please use 'Configuration option' as per RFC 6550 in >>>>>>>>>>>>> all cases >>>>>>>>>>>>> RPL Storing Mode vs. Storing Mode >>>>>>>>>>>>> Pascal > please use ' RPL Storing Mode " >>>>>>>>>>>>> e.1) Please let us know if/how we may make the case for these >>>>>>>>>>>>> terms >>>>>>>>>>>>> consistent. >>>>>>>>>>>>> Source Routing Header vs. >>>>>>>>>>>>> source routing header >>>>>>>>>>>>> [Note: Suggest uppercase to match RFCs 6554 and 8138.] >>>>>>>>>>>>> Pascal > yes, please use uppercase >>>>>>>>>>>>> Source Route Header vs. >>>>>>>>>>>>> source route header vs. >>>>>>>>>>>>> source-routed header >>>>>>>>>>>>> [Note: Suggest uppercase. >>>>>>>>>>>>> Pascal > yes, please use uppercase >>>>>>>>>>>>> - Should "RPL" precede these instances to match use in >>>>>>>>>>>>> RFC 6554 (e.g., "RPL Source Route Header"), or should any >>>>>>>>>>>>> of these instances be "Source Routing Header" or "SRH"?] >>>>>>>>>>>>> Pascal > yes, please add RPL to ensure clarity (vs. SRH in >>>>>>>>>>>>> segment routing specs) >>>>>>>>>>>>> e.2) Is the use of "(RPL) SRH" correct in the sentences below, or >>>>>>>>>>>>> should it be "RPL Source Route Header" per RFC 6554? >>>>>>>>>>>>> Original: >>>>>>>>>>>>> In a Non-Storing mode RPL domain, the IPv6 RH used for source >>>>>>>>>>>>> routing >>>>>>>>>>>>> is the (RPL) SRH as defined in [RFC6554]. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> In a Non-Storing Mode RPL domain, the IPv6 RH used for source >>>>>>>>>>>>> routing >>>>>>>>>>>>> is the RPL Source Route Header as defined in [RFC6554]. >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> ... >>>>>>>>>>>>> Original: >>>>>>>>>>>>> As such, forwarding along segments as specified hereafter can be >>>>>>>>>>>>> seen >>>>>>>>>>>>> as a form of Segment Routing [RFC8402], but leveraging the (RPL) >>>>>>>>>>>>> SRH >>>>>>>>>>>>> for its operation. >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> As such, forwarding along segments as specified hereafter can be >>>>>>>>>>>>> seen >>>>>>>>>>>>> as a form of Segment Routing [RFC8402] that leverages the RPL >>>>>>>>>>>>> Source >>>>>>>>>>>>> Route Header for its operation. >>>>>>>>>>>>> Pascal > please use 'Perhaps' >>>>>>>>>>>>> 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. >>>>>>>>>>>>> We note that RFC 6550 uses "Non-Storing mode" and "Non-Storing >>>>>>>>>>>>> Mode of Operation". Please let us know if any further changes are >>>>>>>>>>>>> needed to the case of "Mode" throughout the document. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> Section 1: ... operated in RPL Non-Storing Mode of Operation >>>>>>>>>>>>> (MOP) >>>>>>>>>>>>> Section 3.2: ... RPL Storing Mode or Non-Storing Mode of >>>>>>>>>>>>> Operation (MOP) >>>>>>>>>>>>> ... compared to Non-Storing MOP >>>>>>>>>>>>> Pascal > Good. For the latter you could say RPL Storing or >>>>>>>>>>>>> Non-Storing Mode of Operation (MOP) >>>>>>>>>>>>> g) May we make "Header" lowercase (form on the right) for the >>>>>>>>>>>>> following >>>>>>>>>>>>> terms to match use in RFC 8138? >>>>>>>>>>>>> IP-in-IP 6LoRH Header -> IP-in-IP 6LoRH header >>>>>>>>>>>>> P-RPI-6LoRH Header -> P-RPI-6LoRH header >>>>>>>>>>>>> RPI-6LoRH Header -> RPI-6LoRH header >>>>>>>>>>>>> Pascal > yes, please >>>>>>>>>>>>> h) We note the inconsistent use of quote marks around flag names. >>>>>>>>>>>>> Please review and let us know if you prefer single quotes or no >>>>>>>>>>>>> quotes for consistency. >>>>>>>>>>>>> Some examples: >>>>>>>>>>>>> 'D' flag vs. D flag >>>>>>>>>>>>> 'P' flag vs. P flag >>>>>>>>>>>>> 'O', 'R', and 'F' flags vs. O, R, and F flags >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > this reflects inconsistencies in the references as well. >>>>>>>>>>>>> I prefer with the quote if that's OK. >>>>>>>>>>>>> 63) <!-- [rfced] Abbreviations >>>>>>>>>>>>> a) FYI - We have added expansions for the following abbreviations >>>>>>>>>>>>> per >>>>>>>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these >>>>>>>>>>>>> and >>>>>>>>>>>>> each expansion in the document carefully to ensure correctness. >>>>>>>>>>>>> Deterministic Networking (DetNet) >>>>>>>>>>>>> Enhanced Interior Gateway Routing Protocol (EIGRP) >>>>>>>>>>>>> Operations, Administration, and Maintenance (OAM) >>>>>>>>>>>>> Pascal > Thanks >>>>>>>>>>>>> b) How may we expand the first mention of "P2P" below (in Section >>>>>>>>>>>>> 1)? >>>>>>>>>>>>> We note "P2P (Point-to-Point)" in Section 2.4.4 and "P2P (Peer-to- >>>>>>>>>>>>> Peer)" in Section 3.3.2. Do all instances of "P2P" refer to >>>>>>>>>>>>> "Point-to-Point" except for Section 3.3.2, or should "P2P" in >>>>>>>>>>>>> Section >>>>>>>>>>>>> 3.3.2 (and/or elsewhere) be made consistent? Please clarify. >>>>>>>>>>>>> Pascal > Please use P2P for point to point, and leave >>>>>>>>>>>>> peer-to-peer expanded with no initialism. >>>>>>>>>>>>> Current: >>>>>>>>>>>>> The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL] >>>>>>>>>>>>> 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 versus the signaling and >>>>>>>>>>>>> state overhead involved in maintaining the shortest paths across. >>>>>>>>>>>>> Pascal > please remove "P2P" in that sentence. >>>>>>>>>>>>> c) How may we expand one instance of "TID"? Perhaps "Transaction >>>>>>>>>>>>> ID", >>>>>>>>>>>>> "Track ID", or "TrackID"? >>>>>>>>>>>>> Current: >>>>>>>>>>>>> If the DAO-ACK is not received, the Root may retry the DAO with >>>>>>>>>>>>> the >>>>>>>>>>>>> same TID or tear down the route. >>>>>>>>>>>>> Pascal > "TrackID" it is >>>>>>>>>>>>> d) FYI: We updated the following expansions to the forms on the >>>>>>>>>>>>> right for consistency. Please let us know of any objection. >>>>>>>>>>>>> PCE Protocol (PCEP) -> PCE Communication Protocol (PCEP) (per RFC >>>>>>>>>>>>> 5440) >>>>>>>>>>>>> Segment Routing (SRv6) -> Segment Routing over IPv6 (SRv6) (per >>>>>>>>>>>>> RFC 8754) >>>>>>>>>>>>> Pascal > Thanks >>>>>>>>>>>>> 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 >>>>>>>>>>>>> "Radio Access Network (RAN)" (in draft-ietf-raw-architecture-30) >>>>>>>>>>>>> vs. >>>>>>>>>>>>> "RPL-Aware Node (RAN)" (in this document) >>>>>>>>>>>>> Pascal > please leave as is. This doc is in the RPL family and >>>>>>>>>>>>> does not apply to 3GPP >>>>>>>>>>>>> --> >>>>>>>>>>>>> 64) <!-- [rfced] Please review the "Inclusive Language" portion >>>>>>>>>>>>> of the online >>>>>>>>>>>>> Style Guide >>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>>>>>>>> and let us know if any changes are needed. Updates of this >>>>>>>>>>>>> nature typically >>>>>>>>>>>>> result in more precise language, which is helpful for readers. >>>>>>>>>>>>> For example, please consider whether the following should be >>>>>>>>>>>>> updated: >>>>>>>>>>>>> - native >>>>>>>>>>>>> In addition, please consider whether "traditional" (2 instances) >>>>>>>>>>>>> should be updated for clarity. While the NIST website >>>>>>>>>>>>> <https://web.archive.org/web/20250214092458/https://www.nist.gov/ >>>>>>>>>>>>> nist-research-library/nist-technical-series-publications-author-instructions#table1> >>>>>>>>>>>>> indicates that this term is potentially biased, it is also >>>>>>>>>>>>> ambiguous. >>>>>>>>>>>>> "Tradition" is a subjective term, as it is not the same for >>>>>>>>>>>>> everyone. >>>>>>>>>>>>> --> >>>>>>>>>>>>> Pascal > please leave as is. >>>>>>>>>>>>> Many thanks for this tremendous work! >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> Thank you. >>>>>>>>>>>>> Karen Moore and Rebecca VanRheenen >>>>>>>>>>>>> RFC Production Center >>>>>>>>>>>>> On Feb 27, 2026, at 1:55 PM, [email protected] wrote: >>>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>>> Updated 2026/02/27 >>>>>>>>>>>>> RFC Author(s): >>>>>>>>>>>>> -------------- >>>>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed >>>>>>>>>>>>> and >>>>>>>>>>>>> approved by you and all coauthors, it will be published as an >>>>>>>>>>>>> RFC. >>>>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before >>>>>>>>>>>>> providing >>>>>>>>>>>>> your approval. >>>>>>>>>>>>> Planning your review >>>>>>>>>>>>> --------------------- >>>>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>>>> * RFC Editor questions >>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>>>> follows: >>>>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>>>> * Content >>>>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>>>> change once the RFC is published. Please pay particular >>>>>>>>>>>>> attention to: >>>>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>>>> - contact information >>>>>>>>>>>>> - references >>>>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info). >>>>>>>>>>>>> * Semantic markup >>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements >>>>>>>>>>>>> of >>>>>>>>>>>>> content are correctly tagged. For example, ensure that >>>>>>>>>>>>> <sourcecode> >>>>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>>>>>> * Formatted output >>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>>>> Submitting changes >>>>>>>>>>>>> ------------------ >>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ >>>>>>>>>>>>> as all >>>>>>>>>>>>> the parties CCed on this message need to see your changes. The >>>>>>>>>>>>> parties >>>>>>>>>>>>> include: >>>>>>>>>>>>> * your coauthors >>>>>>>>>>>>> * [email protected] (the RPC team) >>>>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>>>> * [email protected], which is a new archival mailing >>>>>>>>>>>>> list >>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>>>>>> list: >>>>>>>>>>>>> * More info: >>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>>>>>>>> * The archive itself: >>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive >>>>>>>>>>>>> matter). >>>>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>>>> [email protected] will be re-added to the CC list and >>>>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>>>> An update to the provided XML file >>>>>>>>>>>>> — OR — >>>>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>>>> OLD: >>>>>>>>>>>>> old text >>>>>>>>>>>>> NEW: >>>>>>>>>>>>> new text >>>>>>>>>>>>> You do not need to reply with both an updated XML file and an >>>>>>>>>>>>> explicit >>>>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>>>> We will ask a stream manager to review and approve any changes >>>>>>>>>>>>> that seem >>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion >>>>>>>>>>>>> of text, >>>>>>>>>>>>> and technical changes. Information about stream managers can be >>>>>>>>>>>>> found in >>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream >>>>>>>>>>>>> manager. >>>>>>>>>>>>> Approving for publication >>>>>>>>>>>>> -------------------------- >>>>>>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>>>>>> stating >>>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY >>>>>>>>>>>>> ALL’, >>>>>>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>>>>>> Files >>>>>>>>>>>>> ----- >>>>>>>>>>>>> The files are available here: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.xml >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.pdf >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914.txt >>>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-diff.html >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-rfcdiff.html (side by >>>>>>>>>>>>> side) >>>>>>>>>>>>> For your convenience, we have also created an alt-diff file that >>>>>>>>>>>>> will >>>>>>>>>>>>> allow you to more easily view changes where text has been deleted >>>>>>>>>>>>> or >>>>>>>>>>>>> moved: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-alt-diff.html >>>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9914-xmldiff1.html >>>>>>>>>>>>> Tracking progress >>>>>>>>>>>>> ----------------- >>>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9914 >>>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>>> RFC Editor >>>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>>> RFC9914 (draft-ietf-roll-dao-projection-40) >>>>>>>>>>>>> Title : Root-initiated Routing State in RPL >>>>>>>>>>>>> Author(s) : P. Thubert, Ed., R. Arvind Jadhav, M. >>>>>>>>>>>>> Richardson >>>>>>>>>>>>> WG Chair(s) : Ines Robles, Remous-Aris Koutsiamanis >>>>>>>>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de >>>>>>>>>>>>> Velde >>>>>>>>>>>>> -- >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> -- >>>>>>>>>>>>> auth48archive mailing list -- [email protected] >>>>>>>>>>>>> To unsubscribe send an email to [email protected] -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
