Hello Karen Great! Let’s see:
> Le 9 mars 2026 à 21:40, Karen Moore <[email protected]> a écrit : > > Hi Pascal, > > For this requested change, would this update be agreeable? > > Current (Section 2.4.5): > A Track is a networking graph that can be > followed to transport packets with equivalent treatment; as opposed > to the definition of a path above, a Track is not necessarily linear. > > Perhaps: > A Track is a networking graph that can be > followed to transport packets with equivalent treatment; as opposed > to other definitions of a path (see [INT-ARCH] and Section 3.1.1 of > [RAW-ARCH]), > a Track is not necessarily linear. Please use “perhaps “ Many thanks! Pascal > > Best regards, > Karen Moore > RFC Production Center > >> On Mar 6, 2026, at 11:43 PM, Pascal Thubert <[email protected]> wrote: >> >> Hello again Karen >> >> It might be that the text in 2.4.5 >> “ >> as opposed to the definition of a path above >> >> “ >> Becomes unreadable when the quotes on 2.4.3 are removed which is not yet >> visible in the posted html version. >> >> If so maybe we could replace it with : >> “ >> As opposed to other definitions found in the art >> “ >> or something similar and again quote the section. On path in the RAW >> architecture ? >> >> All the best, >> >> Pascal >> >>>> Le 7 mars 2026 à 08:19, Pascal Thubert <[email protected]> a écrit : >>> >>> 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]
