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]
