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]
