Pascal, Thank you for your reply. Please see the follow-ups below. The revised files are here (please refresh): https://www.rfc-editor.org/authors/rfc9926.html https://www.rfc-editor.org/authors/rfc9926.txt https://www.rfc-editor.org/authors/rfc9926.pdf https://www.rfc-editor.org/authors/rfc9926.xml
- Re: #1, would you like to update the title for readability? Original: IPv6 Neighbor Discovery Prefix Registration Perhaps: Prefix Registration for IPv6 Neighbor Discovery - Re: #10, we have removed usage of <strong>. - Re: #12, you wrote: > -> 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. We have not updated the original sentence in hopes of avoiding a change to the intended meaning. - Re: #13 and 14, in the RFC series, "updates" and "updated by" have a specific meaning when referring to relationships between RFCs, so these two statements are inaccurate. For the second statement, we see that "extended by" was used in version 12 of the draft and it was changed to "updated by". Would "alters" and "altered by" or other options be possible? > Original: > Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered > Address in the Target Address field. > > Original: > [RFC7400] was already updated by [RFC8505] for use in IPv6 ND > messages. - Re: #16, do you want to include "if there is only one" and "if there is more than one" to exactly match the text in RFC 9685? - Re: #15 and 17, updated as requested, and you will be CCed on a separate mail to IANA. - Re: #21, you wrote: > It is a 3-tuple, because a prefix is really a 2-tuple. We have updated "(IPv6 prefix/length, ROVR)" to "(IPv6 prefix, prefix length, ROVR)", but please let us know if that is not what you intended. This diff file shows all changes from the approved I-D: https://www.rfc-editor.org/authors/rfc9926-diff.html https://www.rfc-editor.org/authors/rfc9926-rfcdiff.html (side by side) This diff file shows the changes made during AUTH48 thus far: https://www.rfc-editor.org/authors/rfc9926-auth48diff.html https://www.rfc-editor.org/authors/rfc9926-auth48rfcdiff.html (side by side) We will wait to hear from you again and from your coauthors before continuing the publication process. This page shows the AUTH48 status of your document: https://www.rfc-editor.org/auth48/rfc9926 Thank you. Alice Russo RFC Production Center > On Jan 27, 2026, at 1:51 AM, Pascal Thubert <[email protected]> wrote: > > Dear RFC Editor > 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. > --> > > -> confirmed > 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. > --> > -> Please use your proposal > 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:"? > ... > > --> > -> Please use your proposal > > 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. > --> > -> Not sure it changes anything but OK > 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. > --> > -> I like the perhapps best. All WFM. > 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. > > --> > -> Please use your proposal > 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] > --> > -> > 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 > 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. > --> > -> This is really an affair of presentation and not my field. I'll trust and > follow your opinion on that. > 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). > --> > > -> 3 it is. > 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. > --> > > -> 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. > 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. > --> > -> 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 . > 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. > --> > > Same as above, I'd rather we keep the text as it stands since it passed IESG > reviews. With suffering on that particular issue. > 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 ... > --> > > 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. > > 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. > --> > -> well done :) > 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. > --> > -> Unicast should be everywhere. We do not support registration for multicast > prefixes. Please update the IANA section too. > 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 > --> > -< yes please > 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. > --> > -> 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. > 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. > --> > -> oups, yes. > 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. > --> > It is a 3-tuple, because a prefix is really a 2-tuple. > 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. > --> > -> Please use the "perhaps" > 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: > --> > -> Please use the "or" > 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. > --> > > -> It should be lowercased to match the other instances within this sentence. > 25) > <!-- [rfced] Would you like the references to be alphabetized > or left in their current order? > --> > -> Please do as you most normally do. > 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>. > --> > > 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. > > [#27 was not answered.] 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. > --> > > -> > 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 > 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. > --> > 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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
