Hello Alice Many thanks for your hard work and deep consideration
Please see below > Le 28 janv. 2026 à 02:16, Alice Russo <[email protected]> a écrit : > > 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 Yes please apply your proposal > - 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. Good > > - 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? For the use of updates I’ll defer to our AD Eric Vyncke. Would you mind setting the issue with him? >> 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? > The idée is to retain exactly the behavior in your quote from RFC 9685. I believe that the text there is the result of a clarification (by RFC editor?). Maybe we could just use the exact same text? > - 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. Good > > > 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 Many thanks Alice! Pascal > >> 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]
