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?
...
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.
…
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 ...
> 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.
…
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.)
Would this update be correct: "In a Non-Storing mode RPL domain” -> "In a RPL
Non-Storing mode domain”
> 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”
- "P-DAO Request Acknowledgement (PDR-ACK)” to
"P-DAO Request Acknowledgement (PDAOAck)”
- all instances of "PDR-ACK" to “PDAOAck”
b) Should these field names be updated as well? Any others we may have missed?
PDRSequence -> PDAOReqSequence
PDR-ACK Status -> PDAOAck Status
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
> 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]
