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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
