Dear RFC Editor
<!-- [rfced] Because this document updates RFCs 4861, 6550,
8505, 8928, and 9010, please review the errata for each
of those RFCs:
https://www.rfc-editor.org/errata/rfc4861
https://www.rfc-editor.org/errata/rfc6550
https://www.rfc-editor.org/errata/rfc8505
https://www.rfc-editor.org/errata/rfc8928
https://www.rfc-editor.org/errata/rfc9010
and let us know if you confirm our opinion that none of them
are relevant to the content of this document.
-->
-> confirmed
<!--[rfced] Please clarify; is this a list of 3 items?
Original:
Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern.
Perhaps:
Other design constraints (such as a limited memory capacity,
duty cycling of the LLN devices, and low-power lossy transmissions)
derive from that primary concern.
-->
-> Please use your proposal
<!--[rfced] Please clarify "This" in "This translates into:".
The preceding text is a list of design points, so perhaps
it may be updated to "These points translate into:"?
...
-->
-> Please use your proposal
<!--[rfced] May this be rephrased for readability so DAD is first?
Original:
It was thus designed
as a reactive protocol that relies on caching and multicast
operations for the Address Resolution (AR, aka Address Discovery or
Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast
addresses.
Perhaps:
Thus, it was designed
as a reactive protocol that relies on caching and multicast
operations for the Duplicate Address Detection (DAD) and Address
Resolution (AR), aka address discovery or address lookup, of IPv6
unicast addresses.
-->
-> Not sure it changes anything but OK
<!--[rfced] May this be rephrased as follows for clarity?
In the original, the repetition of "it" (with different antecedents)
is unclear.
Original:
It can be noted that an energy-conserving node is not necessarily a
router, so even when advertising a prefix, it is a design choice not
to use Router Advertisement (RA) messages that would make the node
appear as a router to peer nodes.
Perhaps:
Please note that an energy-conserving node is not necessarily a
router, so even when a node is advertising a prefix, it is a
design choice not to use Router Advertisement (RA) messages that would
make the node appear as a router to peer nodes.
Or:
Note that an energy-conserving node is not necessarily a
router, so even when a node is advertising a prefix, a design
choice is not using Router Advertisement (RA) messages that
would make the node appear as a router to peer nodes.
-->
-> I like the perhapps best. All WFM.
<!--[rfced] Please clarify this sentence. Is it a list of two items
that are not being leveraged?
Original:
From the design principles above,
it is clearly a design choice not to leverage broadcasts from or to
the node, or complex state machines in the node.
Perhaps:
From the design principles above,
it is clearly a design choice not to leverage (1) broadcasts from or to
the node or (2) complex state machines in the node.
-->
-> Please use your proposal
<!-- [rfced] We have updated the expansion for LoWPAN as follows
to match usage in RFCs. Although the title of the cited document
[IEEE802154] uses the words "Low-Rate Personal Area Network", LoWPAN
has been expanded as follows in RFCs.
Original:
LoWPAN: Low-Rate Personal Area Network [IEEE802154]
Current:
LoWPAN: Low-Power Wireless Personal Area Network [IEEE802154]
-->
->
I suggest using both like
LR-WPAN: Low-Rate Personal Area Network [IEEE802154]
LoWPAN: Low-Power Wireless Personal Area Network
You'll note the removal of the ref to IEEE 802.15.4 in LoWPAN
<!-- [rfced] Regarding usage of <strong> elements in this document.
please review the occurrences and let us know if any updates are
needed for consistency. Details below.
In the HTML and PDF outputs, <strong> yields bold.
In the text output, <strong> yields an asterisk before and after.
(Our suggestions below are due to the asterisks in the text output.)
- S 2.3: used for acronyms upon being defined.
- S 2.4: used for new terms upon being defined.
- S 5: used for flag name; does not match how "F" appears within Figure 1.
we suggest removing this usage.
- S 7.1, 13.1, 13.2: used for left-column values in Tables 1, 2 and 3;
we suggest removing this usage.
- S 7.2, 7.3: used for names of fields; does not match how they appear
within
Figures 2 and 3; we suggest removing this usage.
-->
-> This is really an affair of presentation and not my field. I'll trust
and follow your opinion on that.
<!--[rfced] Please clarify this definition; are there 2 or 3 options?
Original:
*Merge:* The action of receiving multiple anycast or multicast
advertisements, either internally from self, in the form of a
NS(EARO), or as a DAO(TIO, RTO), and generating a single
DAO(TIO, RTO).
Perhaps (if 2):
*Merge:* The process of aggregating multiple advertisements - received
internally as an NS(EARO) or externally as a DAO(TIO, RTO) - into
a single outgoing DAO(TIO, RTO).
Or(if 3):
*Merge:* The action of receiving multiple anycast or multicast
advertisements, either (1) internally from self, (2) in the form
of a
NS(EARO), (3) or as a DAO(TIO, RTO), and generating a single
DAO(TIO, RTO).
-->
-> 3 it is.
<!--[rfced] Is the meaning of "same" (4 instances in this sentence) clear,
or
is the point (in last 2 instances) that there is one given prefix?
i.e., For the last 2 instances, the "same" as what?
Original:
Multiple 6LNs acting as border routers to the same external
network or as access routers to the same subnet may register the same
prefix to the same 6LR or to different 6LRs.
Perhaps:
Multiple 6LNs acting as border routers to the same external
network or as access routers to the same subnet may register
a given prefix to one 6LR or to different 6LRs.
-->
-> If the meaning is still that the same prefix is registered by both, that
they may register to the same set of routers or to different sets of
routers, then we're good with your proposal.
<!-- [rfced] Please review whether this sentence is accurate
and let us know if any changes are needed.
We note that Section 5.5 of [RFC8505] does not mention [RFC4861].
Also, regarding the "Updates" relationship between RFCs,
RFC 8505 updates RFC 6775, not RFC 4861.
Original:
Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered
Address in the Target Address field.
-->
-> you are correct on paper but what we tag as "update" seems to have
evolved in a loop. RFC 4861 does not have a concept of registration. This
is how it is updated by semantic overload. There were long debates during
the IESG cycle about saying that this draft updates RFC 4861. We ended up
with what you see now. I guess the rules for "updates" were a bit different
at the time we published RFC8505 .
<!-- [rfced] How should the second sentence be updated for accuracy?
The original is not accurate because RFC 8505 does not update RFC 7400.
(RFC 8505 updates RFC 6775.)
Original:
This specification updates "6LoWPAN-GHC: Generic Header Compression
for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
[RFC7400] by defining a new capability bit for use in the 6CIO.
[RFC7400] was already updated by [RFC8505] for use in IPv6 ND
messages.
-->
Same as above, I'd rather we keep the text as it stands since it passed
IESG reviews. With suffering on that particular issue.
<!--[rfced] Why is "Supported" capitalized here? If this may be
changed, then we will ask IANA to update the registry
(
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits)
based on your reply.
Original:
The new "Registration for prefixes Supported" (F) flag indicates ...
Perhaps:
The new "Registration for prefixes supported (F bit)" indicates ...
Or (if you prefer title case, which is similar to X flag in that registry):
The new "Registration for Prefixes Supported (F bit)" indicates ...
-->
We do not seem to be consistent either way in IANA "6LoWPAN Capability
Bits" but lowercasing seems to be the norm. Please use the perhaps and
update the IANA section.
<!--[rfced] FYI, we updated this text to clarify the "that is" phrase
and be more similar to RFC 9685 (Section 6).
Please let us know any further updates. Do you want to include
"if there is only one" and "if there is more than one"?
Original:
When the lifetime
expires, the router sends a no-path DAO (i.e., the lifetime is 0)
using the same value for ROVR value as for the previous
advertisements, that is either itself or the single descendant that
advertised the Target.
Current:
When the lifetime
expires, the router sends a no-path DAO (i.e., the lifetime is 0)
using the same value for the ROVR value as for the previous
advertisements. This value refers to either the router itself or the
single descendant that advertised the Target.
For comparison, from RFC 9685 (Section 6):
When the lifetime expires, the router sends a no-path
DAO message (i.e., the lifetime is 0) using the same value for the
ROVR value as for the previous advertisements. This value refers to
either the single descendant that advertised the Target if there is
only one or the router itself if there is more than one.
-->
-> well done :)
<!--[rfced] In Table 1, this meaning has been updated to exactly match
the IANA registry. Please let us know if that is not your intention.
(See
https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values
)
Original: 3 | Registration for a Unicast prefix
Current: 3 | Registration for a Prefix
Due to this, please review whether any other updates updates
are needed. For example, in Section 1, should "unicast" be removed here?
Original:
This specification updates the above registration and subscription
methods to enable a node to register a unicast prefix to the routing
system and get it injected in the routing protocol.
-->
-> Unicast should be everywhere. We do not support registration for
multicast prefixes. Please update the IANA section too.
<!--[rfced] If these phrases have the same meaning, would you like to
make them consistent?
Section 7.2: between 16 and 120 inclusive
Section 7.3: in the inclusive range of 16 to 120
-->
-< yes please
<!--[rfced] How may this be rephrased for clarity? Specifically,
"by the LR" is unclear.
If these are 2 methods of obtaining return reachability services,
then we suggest parallel structure as follows. Adding numbering
is optional.
Original:
* The 6LN may set the R flag in the EARO to obtain return
reachability services by the 6LR, e.g., through ND proxy
operations, or by injecting the route in a route-over subnet.
Perhaps:
* The 6LN may set the R flag in the EARO to obtain return
reachability services (1) by relying on the 6LR, e.g.,
through ND proxy operations, or (2) by injecting the route in
a route-over subnet.
-->
-> not really. It is the 6LR that does either ND proxy or route injection,
iow, original was correct, perhaps is not. you could do:
* The 6LN may set the R flag in the EARO to obtain return
reachability services from the 6LR, e.g., (1)
through ND proxy operations, or (2) by injecting the route to the
Registered Prefix in
a route-over subnet.
<!--[rfced] FYI, we changed "the set" to "set the" here. Please review
that the sentence conveys the intended meaning.
Original:
It MUST set the P-Field in the EARO to 3 for those
prefixes, and the set R flag to receive the traffic associated to
the prefixes.
Current:
It MUST set the P-Field in the EARO to 3 for those
prefixes and set the R flag to receive the traffic associated to
the prefixes.
-->
-> oups, yes.
<!--[rfced] Please clarify this tuple "(IPv6 prefix/length, ROVR)".
Does it mean the first item is a prefix or a prefix length?
The notation "IPv6 prefix/length" has not appeared in any RFCs.
Original:
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix/
length, ROVR) for all registered prefixes.
Perhaps:
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix
or prefix length, ROVR) for all registered prefixes.
Or (if it is a 3-tuple):
* The 6LR MUST maintain a registration state per tuple (IPv6 prefix,
prefix length, ROVR) for all registered prefixes.
-->
It is a 3-tuple, because a prefix is really a 2-tuple.
<!--[rfced] Please clarify this sentence; what does "and this on" mean?
Also, we suggest not repeating "updates".
Original:
This specification updates that proxy operation with the updates in
[RFC9685] and this on the formats and content of the EARO, the EDAR,
and the EDAC messages, to support the P-Field and the signaling of
prefixes.
Perhaps:
This specification updates that proxy operation as specified in
[RFC9685] and defines the formats and content of the
EARO, EDAR, and EDAC messages in order to support the P-Field and the
signaling of prefixes.
-->
-> Please use the "perhaps"
<!--[rfced] May this sentence be rephrased as follows for clarity?
Specifically, "and all of the above" reads oddly.
Original:
A mix of devices that support only [RFC8505], both [RFC8505] and
[RFC9685], and all of the above plus this specification, may coexist.
Different cases may occur:
Perhaps:
A mix of devices (i.e., those that support only [RFC8505], both
[RFC8505] and [RFC9685], or those two plus this specification) may
coexist.
Different cases may occur:
Or:
Devices may coexist while providing different support (i.e., only
[RFC8505], both [RFC8505] and [RFC9685], or those two as well as this
specification). The following cases may occur:
-->
-> Please use the "or"
<!--[rfced] Is "the Prefix" here referring to the Prefix field,
or should it be lowercased to match the other instances within this
sentence?
Original:
With this specification, a router that owns a prefix or provides
reachability
to an external prefix but is not a RPL router can also register those
prefixes with the R flag set, to enable reachability to the Prefix
within the RPL domain.
-->
-> It should be lowercased to match the other instances within this
sentence.
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
-> Please do as you most normally do.
<!-- [rfced] Please review the informative reference [IEEE802154].
The title provided matches a version of this IEEE Standard from 2006.
The most up-to-date version of this reference was published in 2024.
Which version of the IEEE Standard should be referenced in
this document?
Original:
[IEEE802154] IEEE standard for Information Technology, "IEEE Std
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
Area Networks".
Current:
[IEEE802154]
IEEE, "IEEE Standard for Information technology - Local
and metropolitan area networks - Specific requirements -
Part 15.4: Wireless Medium Access Control (MAC) and
Physical Layer (PHY) Specifications for Low Rate Wireless
Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
DOI 10.1109/IEEESTD.2006.232110, 2006,
<https://ieeexplore.ieee.org/document/1700009>.
Most recent version (potential update):
[IEEE802154]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
2024, <https://ieeexplore.ieee.org/document/10794632>.
-->
For IEEE references we take great care not to provide dates to avoid
pointing to a particular year/version when really we cover all unless
specified. Because that would mean we work with only the most recent spec
and that is untrue.
I agree providing even a link is misleading, and that the title of the
standard has changed over time anyway. I guess you may use the most recent
title and link as above but please do not use the <date> tag. Same goes for
the other IEEE links.
<!--[rfced] Terminology: The following terms appear inconsistently
in the original; please let us know if any updates are needed.
a) subnet vs. Subnet
We suggest lowercasing these instances to match usage elsewhere in the
document.
Capitalized instances:
inside the Subnet
a single IPv6 Subnet
b) registration vs. Registration
Capitalized instances:
the Registration for prefixes
the Registration operation
the Registration of overlapping prefixes
c) prefix length vs. Prefix Length
Presumably, this should be capitalized when referring to the field name.
It's not clear if some instances of lowercase are accurate.
For example: Section 7.3, perhaps capitalize it here?
"the remaining byte is dedicated to one reserved bit and the prefix length"
d) FYI, as "Layer 2 (L2)" appears in Section 1, we updated
subsequent instances of "Layer 2" to "L2". Please let us know
if you prefer otherwise.
-->
->
a) agreed
b) please uppercase only when used in a message name line "Prefix
Registration" but use lowercase in a sentence like "for the registration of
a prefix"
c) Yes please capitalize that instance
d) agreed
<!-- [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.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
OK. I'm good with that but I'm not native so please pardon my mistakes.
many thanks!
Please let me know when all this is applied and I'll review the whole text.
all the best,
Pascal
Le mar. 27 janv. 2026 à 05:49, <[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] Would you like to update the title for
> readability?
>
> Original: IPv6 Neighbor Discovery Prefix Registration
> Perhaps: Prefix Registration for IPv6 Neighbor Discovery
> -->
>
>
> 2) <!-- [rfced] Because this document updates RFCs 4861, 6550,
> 8505, 8928, and 9010, please review the errata for each
> of those RFCs:
> https://www.rfc-editor.org/errata/rfc4861
> https://www.rfc-editor.org/errata/rfc6550
> https://www.rfc-editor.org/errata/rfc8505
> https://www.rfc-editor.org/errata/rfc8928
> https://www.rfc-editor.org/errata/rfc9010
>
> and let us know if you confirm our opinion that none of them
> are relevant to the content of this document.
> -->
>
>
> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
>
>
> 4) <!--[rfced] Please clarify; is this a list of 3 items?
>
> Original:
> Other design constraints, such as a limited memory capacity,
> duty cycling of the LLN devices and low-power lossy transmissions,
> derive from that primary concern.
>
> Perhaps:
> Other design constraints (such as a limited memory capacity,
> duty cycling of the LLN devices, and low-power lossy transmissions)
> derive from that primary concern.
> -->
>
>
> 5) <!--[rfced] Please clarify "This" in "This translates into:".
> The preceding text is a list of design points, so perhaps
> it may be updated to "These points translate into:"?
>
> Original:
> The general design points include:
>
> * Placing the protocol complexity [...]
>
> * Using host-triggered operations [...]
>
> This translates into:
>
> * Stateful proactively-built knowledge in the routers that is
> available at any point of time.
>
> * Unicast host to router operations triggered by the host and its
> applications.
>
> * Minimal use of asynchronous L2-broadcast operations that would
> keep the host awake and listening with no application-level need
> to do so.
> -->
>
>
> 6) <!--[rfced] May this be rephrased for readability so DAD is first?
>
> Original:
> It was thus designed
> as a reactive protocol that relies on caching and multicast
> operations for the Address Resolution (AR, aka Address Discovery or
> Address Lookup) and Duplicate Address Detection (DAD) of IPv6 unicast
> addresses.
>
> Perhaps:
> Thus, it was designed
> as a reactive protocol that relies on caching and multicast
> operations for the Duplicate Address Detection (DAD) and Address
> Resolution (AR), aka address discovery or address lookup, of IPv6
> unicast addresses.
> -->
>
>
> 7) <!--[rfced] May this be rephrased as follows for clarity?
> In the original, the repetition of "it" (with different antecedents)
> is unclear.
>
> Original:
> It can be noted that an energy-conserving node is not necessarily a
> router, so even when advertising a prefix, it is a design choice not
> to use Router Advertisement (RA) messages that would make the node
> appear as a router to peer nodes.
>
> Perhaps:
> Please note that an energy-conserving node is not necessarily a
> router, so even when a node is advertising a prefix, it is a
> design choice not to use Router Advertisement (RA) messages that would
> make the node appear as a router to peer nodes.
>
> Or:
> Note that an energy-conserving node is not necessarily a
> router, so even when a node is advertising a prefix, a design
> choice is not using Router Advertisement (RA) messages that
> would make the node appear as a router to peer nodes.
> -->
>
>
> 8) <!--[rfced] Please clarify this sentence. Is it a list of two items
> that are not being leveraged?
>
> Original:
> From the design principles above,
> it is clearly a design choice not to leverage broadcasts from or to
> the node, or complex state machines in the node.
>
> Perhaps:
> From the design principles above,
> it is clearly a design choice not to leverage (1) broadcasts from or to
> the node or (2) complex state machines in the node.
> -->
>
>
> 9) <!-- [rfced] We have updated the expansion for LoWPAN as follows
> to match usage in RFCs. Although the title of the cited document
> [IEEE802154] uses the words "Low-Rate Personal Area Network", LoWPAN
> has been expanded as follows in RFCs.
>
> Original:
> LoWPAN: Low-Rate Personal Area Network [IEEE802154]
>
> Current:
> LoWPAN: Low-Power Wireless Personal Area Network [IEEE802154]
> -->
>
>
> 10) <!-- [rfced] Regarding usage of <strong> elements in this document.
> please review the occurrences and let us know if any updates are
> needed for consistency. Details below.
>
> In the HTML and PDF outputs, <strong> yields bold.
> In the text output, <strong> yields an asterisk before and after.
> (Our suggestions below are due to the asterisks in the text output.)
>
> - S 2.3: used for acronyms upon being defined.
> - S 2.4: used for new terms upon being defined.
> - S 5: used for flag name; does not match how "F" appears within Figure 1.
> we suggest removing this usage.
> - S 7.1, 13.1, 13.2: used for left-column values in Tables 1, 2 and 3;
> we suggest removing this usage.
> - S 7.2, 7.3: used for names of fields; does not match how they appear
> within
> Figures 2 and 3; we suggest removing this usage.
> -->
>
>
> 11) <!--[rfced] Please clarify this definition; are there 2 or 3 options?
>
> Original:
> *Merge:* The action of receiving multiple anycast or multicast
> advertisements, either internally from self, in the form of a
> NS(EARO), or as a DAO(TIO, RTO), and generating a single
> DAO(TIO, RTO).
>
> Perhaps (if 2):
> *Merge:* The process of aggregating multiple advertisements -
> received
> internally as an NS(EARO) or externally as a DAO(TIO, RTO) -
> into
> a single outgoing DAO(TIO, RTO).
>
> Or(if 3):
> *Merge:* The action of receiving multiple anycast or multicast
> advertisements, either (1) internally from self, (2) in the form
> of a
> NS(EARO), (3) or as a DAO(TIO, RTO), and generating a single
> DAO(TIO, RTO).
> -->
>
>
> 12) <!--[rfced] Is the meaning of "same" (4 instances in this sentence)
> clear, or
> is the point (in last 2 instances) that there is one given prefix?
> i.e., For the last 2 instances, the "same" as what?
>
> Original:
> Multiple 6LNs acting as border routers to the same external
> network or as access routers to the same subnet may register the same
> prefix to the same 6LR or to different 6LRs.
>
> Perhaps:
> Multiple 6LNs acting as border routers to the same external
> network or as access routers to the same subnet may register
> a given prefix to one 6LR or to different 6LRs.
> -->
>
>
> 13) <!-- [rfced] Please review whether this sentence is accurate
> and let us know if any changes are needed.
> We note that Section 5.5 of [RFC8505] does not mention [RFC4861].
> Also, regarding the "Updates" relationship between RFCs,
> RFC 8505 updates RFC 6775, not RFC 4861.
>
> Original:
> Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered
> Address in the Target Address field.
> -->
>
>
> 14) <!-- [rfced] How should the second sentence be updated for accuracy?
> The original is not accurate because RFC 8505 does not update RFC 7400.
> (RFC 8505 updates RFC 6775.)
>
> Original:
> This specification updates "6LoWPAN-GHC: Generic Header Compression
> for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
> [RFC7400] by defining a new capability bit for use in the 6CIO.
> [RFC7400] was already updated by [RFC8505] for use in IPv6 ND
> messages.
> -->
>
>
> 15) <!--[rfced] Why is "Supported" capitalized here? If this may be
> changed, then we will ask IANA to update the registry
> (
> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits)
> based on your reply.
>
> Original:
> The new "Registration for prefixes Supported" (F) flag indicates ...
>
> Perhaps:
> The new "Registration for prefixes supported (F bit)" indicates ...
>
> Or (if you prefer title case, which is similar to X flag in that registry):
> The new "Registration for Prefixes Supported (F bit)" indicates ...
> -->
>
>
> 16) <!--[rfced] FYI, we updated this text to clarify the "that is" phrase
> and be more similar to RFC 9685 (Section 6).
> Please let us know any further updates. Do you want to include
> "if there is only one" and "if there is more than one"?
>
> Original:
> When the lifetime
> expires, the router sends a no-path DAO (i.e., the lifetime is 0)
> using the same value for ROVR value as for the previous
> advertisements, that is either itself or the single descendant that
> advertised the Target.
>
> Current:
> When the lifetime
> expires, the router sends a no-path DAO (i.e., the lifetime is 0)
> using the same value for the ROVR value as for the previous
> advertisements. This value refers to either the router itself or the
> single descendant that advertised the Target.
>
> For comparison, from RFC 9685 (Section 6):
> When the lifetime expires, the router sends a no-path
> DAO message (i.e., the lifetime is 0) using the same value for the
> ROVR value as for the previous advertisements. This value refers to
> either the single descendant that advertised the Target if there is
> only one or the router itself if there is more than one.
> -->
>
>
> 17) <!--[rfced] In Table 1, this meaning has been updated to exactly match
> the IANA registry. Please let us know if that is not your intention.
> (See
> https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values
> )
>
> Original: 3 | Registration for a Unicast prefix
> Current: 3 | Registration for a Prefix
>
> Due to this, please review whether any other updates updates
> are needed. For example, in Section 1, should "unicast" be removed here?
>
> Original:
> This specification updates the above registration and subscription
> methods to enable a node to register a unicast prefix to the routing
> system and get it injected in the routing protocol.
> -->
>
>
> 18) <!--[rfced] If these phrases have the same meaning, would you like to
> make them consistent?
>
> Section 7.2: between 16 and 120 inclusive
> Section 7.3: in the inclusive range of 16 to 120
> -->
>
>
> 19) <!--[rfced] How may this be rephrased for clarity? Specifically,
> "by the LR" is unclear.
> If these are 2 methods of obtaining return reachability services,
> then we suggest parallel structure as follows. Adding numbering
> is optional.
>
> Original:
> * The 6LN may set the R flag in the EARO to obtain return
> reachability services by the 6LR, e.g., through ND proxy
> operations, or by injecting the route in a route-over subnet.
>
> Perhaps:
> * The 6LN may set the R flag in the EARO to obtain return
> reachability services (1) by relying on the 6LR, e.g.,
> through ND proxy operations, or (2) by injecting the route in
> a route-over subnet.
> -->
>
>
> 20) <!--[rfced] FYI, we changed "the set" to "set the" here. Please review
> that the sentence conveys the intended meaning.
>
> Original:
> It MUST set the P-Field in the EARO to 3 for those
> prefixes, and the set R flag to receive the traffic associated to
> the prefixes.
>
> Current:
> It MUST set the P-Field in the EARO to 3 for those
> prefixes and set the R flag to receive the traffic associated to
> the prefixes.
> -->
>
>
> 21) <!--[rfced] Please clarify this tuple "(IPv6 prefix/length, ROVR)".
> Does it mean the first item is a prefix or a prefix length?
> The notation "IPv6 prefix/length" has not appeared in any RFCs.
>
> Original:
> * The 6LR MUST maintain a registration state per tuple (IPv6 prefix/
> length, ROVR) for all registered prefixes.
>
> Perhaps:
> * The 6LR MUST maintain a registration state per tuple (IPv6 prefix
> or prefix length, ROVR) for all registered prefixes.
>
> Or (if it is a 3-tuple):
> * The 6LR MUST maintain a registration state per tuple (IPv6 prefix,
> prefix length, ROVR) for all registered prefixes.
> -->
>
>
> 22) <!--[rfced] Please clarify this sentence; what does "and this on" mean?
> Also, we suggest not repeating "updates".
>
> Original:
> This specification updates that proxy operation with the updates in
> [RFC9685] and this on the formats and content of the EARO, the EDAR,
> and the EDAC messages, to support the P-Field and the signaling of
> prefixes.
>
> Perhaps:
> This specification updates that proxy operation as specified in
> [RFC9685] and defines the formats and content of the
> EARO, EDAR, and EDAC messages in order to support the P-Field and the
> signaling of prefixes.
> -->
>
>
> 23) <!--[rfced] May this sentence be rephrased as follows for clarity?
> Specifically, "and all of the above" reads oddly.
>
> Original:
> A mix of devices that support only [RFC8505], both [RFC8505] and
> [RFC9685], and all of the above plus this specification, may coexist.
> Different cases may occur:
>
> Perhaps:
> A mix of devices (i.e., those that support only [RFC8505], both
> [RFC8505] and [RFC9685], or those two plus this specification) may
> coexist.
> Different cases may occur:
>
> Or:
> Devices may coexist while providing different support (i.e., only
> [RFC8505], both [RFC8505] and [RFC9685], or those two as well as this
> specification). The following cases may occur:
> -->
>
>
> 24) <!--[rfced] Is "the Prefix" here referring to the Prefix field,
> or should it be lowercased to match the other instances within this
> sentence?
>
> Original:
> With this specification, a router that owns a prefix or provides
> reachability
> to an external prefix but is not a RPL router can also register those
> prefixes with the R flag set, to enable reachability to the Prefix
> within the RPL domain.
> -->
>
>
> 25) <!-- [rfced] Would you like the references to be alphabetized
> or left in their current order?
> -->
>
>
> 26) <!-- [rfced] Please review the informative reference [IEEE802154].
> The title provided matches a version of this IEEE Standard from 2006.
> The most up-to-date version of this reference was published in 2024.
> Which version of the IEEE Standard should be referenced in
> this document?
>
> Original:
> [IEEE802154] IEEE standard for Information Technology, "IEEE Std
> 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and
> Physical Layer (PHY) Specifications for Low-Rate Wireless Personal
> Area Networks".
>
> Current:
> [IEEE802154]
> IEEE, "IEEE Standard for Information technology - Local
> and metropolitan area networks - Specific requirements -
> Part 15.4: Wireless Medium Access Control (MAC) and
> Physical Layer (PHY) Specifications for Low Rate Wireless
> Personal Area Networks (WPANs)", IEEE Std 802.15.4-2006,
> DOI 10.1109/IEEESTD.2006.232110, 2006,
> <https://ieeexplore.ieee.org/document/1700009>.
>
> Most recent version (potential update):
>
> [IEEE802154]
> IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE
> Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632,
> 2024, <https://ieeexplore.ieee.org/document/10794632>.
> -->
>
>
> 27) <!-- [rfced] Please review the informative reference [IEEE802151].
> We added the following URL to this reference. Note that the title
> is slightly different. Please let us know if you prefer otherwise.
>
> Original:
> [IEEE802151] IEEE standard for Information Technology, "IEEE
> Standard for Information Technology - Telecommunications and
> Information Exchange Between Systems - Local and Metropolitan Area
> Networks - Specific Requirements. - Part 15.1: Wireless Medium Access
> Control (MAC) and Physical Layer (PHY) Specifications for Wireless
> Personal Area Networks (WPANs)".
>
> Current:
> [IEEE802151]
> IEEE, "IEEE Standard for Telecommunications and
> Information Exchange Between Systems - LAN/MAN - Specific
> Requirements - Part 15: Wireless Medium Access Control
> (MAC) and Physical Layer (PHY) Specifications for Wireless
> Personal Area Networks (WPANs)", IEEE Std 802.15.1-2002,
> DOI 10.1109/IEEESTD.2002.93621, 2002,
> <https://ieeexplore.ieee.org/document/1016473>.
> -->
>
>
> 28) <!--[rfced] Terminology: The following terms appear inconsistently
> in the original; please let us know if any updates are needed.
>
> a) subnet vs. Subnet
> We suggest lowercasing these instances to match usage elsewhere in the
> document.
> Capitalized instances:
> inside the Subnet
> a single IPv6 Subnet
>
> b) registration vs. Registration
> Capitalized instances:
> the Registration for prefixes
> the Registration operation
> the Registration of overlapping prefixes
>
> c) prefix length vs. Prefix Length
> Presumably, this should be capitalized when referring to the field name.
> It's not clear if some instances of lowercase are accurate.
> For example: Section 7.3, perhaps capitalize it here?
> "the remaining byte is dedicated to one reserved bit and the prefix length"
>
> d) FYI, as "Layer 2 (L2)" appears in Section 1, we updated
> subsequent instances of "Layer 2" to "L2". Please let us know
> if you prefer otherwise.
> -->
>
>
> 29) <!-- [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.
>
> Note that our script did not flag any words in particular, but this should
> still be reviewed as a best practice.
> -->
>
>
> Thank you.
>
> Alice Russo
> RFC Production Center
>
>
> On Jan 26, 2026, [email protected] wrote:
>
> *****IMPORTANT*****
>
> Updated 2026/01/26
>
> 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/rfc9926.xml
> https://www.rfc-editor.org/authors/rfc9926.html
> https://www.rfc-editor.org/authors/rfc9926.pdf
> https://www.rfc-editor.org/authors/rfc9926.txt
>
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9926-diff.html
> https://www.rfc-editor.org/authors/rfc9926-rfcdiff.html (side by side)
>
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9926-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9926
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9926 (draft-ietf-6lo-prefix-registration-18)
>
> Title : IPv6 Neighbor Discovery Prefix Registration
> Author(s) : P. Thubert, Ed.
> WG Chair(s) : Shwetha Bhandari, Carles Gomez
> Area Director(s) : Erik Kline, Éric Vyncke
>
>
>
>
--
Pascal
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
