Dear Alice I reviewed the final text and the diffs and I approve the current text for publication. Many thanks for your hard work!
A bientôt; Pascal > Le 31 janv. 2026 à 02:42, Alice Russo <[email protected]> a écrit : > > Pascal, > > Based on your reply, we added 'MUST' in Section 6 and have requested AD > approval in a separate mail. > > Remaining items: > > - Re: #22, 23, and 24 (pasted below), we updated the text per your reply 27 > January; my mistake for missing those earlier. > > - Re: #26, you wrote: >> 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. > > > Question: Would you like to update the IEEE references in the following > manner? Based on your reply and guidance from Ted Harrison (the Citation > Specialist here at the RPC), this attempts to provide a "version-less" > reference -- without a date or URL. > > 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, > <https://ieeexplore.ieee.org/document/1700009>. > > Perhaps: > [IEEE802154] IEEE, "IEEE Standard for Low-Rate Wireless Networks", > IEEE Std 802.15.4. > > > 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 > > 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) > > This diff file shows only the changes since the last posted version: > https://www.rfc-editor.org/authors/rfc9926-lastrfcdiff.html (side by side) > > 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: >> 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. > > >> On Jan 28, 2026, at 7:15 PM, Pascal Thubert <[email protected]> wrote: >> >> Hello Alice >> >> Good catch. I believe it’s better to fully align and use MUST as well. The >> intent is to have the same behavior but for prefixes and the MUST clarifies >> that there is no choice. >> >> All the best, >> >> Pascal >> >>>> Le 29 janv. 2026 à 02:44, Alice Russo <[email protected]> a >>>> écrit : >>> >>> Pascal, >>> >>> Thank you for your replies. >>> >>> Re: #16 (Section 6) >>>> Maybe we could just use the exact same text? >>> >>> OK; have updated to match RFC 9685. (Side note: In this paragraph, one >>> remaining difference from 9685 -- besides of course "addresses" vs. >>> "prefix" -- is that this document does not use "MUST" in the first >>> sentence. We assume that is intentional unless you let us know otherwise.) >>> >>> Current: >>> The RPL router that merges multiple advertisements for the same >>> prefix uses and advertises the longest remaining lifetime across all >>> the origins of the advertisements for that prefix. 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. >>> >>> vs. RFC 9685: >>> The RPL router that merges multiple advertisements for the same >>> anycast or multicast addresses MUST use and advertise the longest >>> remaining lifetime across all the origins of the advertisements for >>> that address. 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. >>> >>> >>> 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 >>> >>> 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) >>> >>> This diff file shows only the changes since the last posted version: >>> https://www.rfc-editor.org/authors/rfc9926-lastrfcdiff.html (side by side) >>> >>> Re: >>>>> For the use of updates I’ll defer to our AD Eric Vyncke. Would you mind >>>>> setting the issue with him? >>> >>> Sent it along earlier today. We will wait to hear from you again >>> and from Éric 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 28, 2026, at 5:10 AM, Pascal Thubert <[email protected]> >>>> wrote: >>>> >>>> Hello Alice >>>> >>>> I’m reviewing the full draft now. >>>> >>>> 1) I found that the title for RFC 4861 got screwed up in section 2.2. It’s >>>> “ Neighbor Discovery for IP version 6 (IPv6)” not some TLS extension >>>> >>>> 2) “Merge” is defined in RFC 9685. Please remove its leftover extraneous >>>> redefinition in section 2.4 >>>> >>>> 3) section 3 provides an example SND based on RPL but the concept of SND >>>> is agnostic to the routing protocol >>>> >>>> Before >>>> >>>> An SND deployment consists of: >>>> >>>> After >>>> >>>> The IPv6 ND operation is agnostic to the routing protocol used in the SND. >>>> Route-over LLNs typically leverage RPL. A RPL-based SND deployment >>>> consists of: >>>> >>>> I’m still on it maybe I ll find more. >>>> >>>> A bientôt; >>>> >>>> Pascal >>>> >>>>>> Le 28 janv. 2026 à 08:21, Pascal Thubert <[email protected]> a >>>>>> écrit : >>>>> >>>>> 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 >>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
