Hello Alice Yes please update the reference.
Many thanks! Pascal Le mer. 11 févr. 2026 à 03:49, Sandy Ginoza <[email protected]> a écrit : > Hi Pascal, > > While preparing this document for publication, we noted that RFC 8415 has > been obsoleted by RFC 9915 (STD 102). May we update the reference to refer > to RFC 9915? > > Thank you, > Sandy Ginoza > RFC Production Center > > > > > On Jan 31, 2026, at 1:01 AM, Pascal Thubert <[email protected]> > wrote: > > > > 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]
