Alice and authors, Thanks for your patience. The use of MUST is approved (and indeed the text is better with a MUST)
Regards -éric From: Alice Russo <[email protected]> Date: Friday, 6 February 2026 at 18:02 To: Eric Vyncke (evyncke) <[email protected]> Cc: Pascal Thubert <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Shwetha <[email protected]>, auth48archive <[email protected]>, RFC Editor <[email protected]> Subject: Re: [AD] AUTH48: RFC-to-be 9926 <draft-ietf-6lo-prefix-registration-18> for your review Éric, The word 'MUST' was added based on Pascal's reply (pasted below). Please review and approve this change (which is also shown in the various files). Original (Section 6): 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. Current: The RPL router that merges multiple advertisements for the same prefix MUST use and advertise the longest remaining lifetime across all the origins of the advertisements for that prefix. Thank you. Alice Russo RFC Production Center > On Jan 30, 2026, at 5:41 PM, Alice Russo <[email protected]> wrote: > > Éric, > > [Please see additional item below for AD approval re: Section 6.] > > Re: Sections 4 and 5 - Yes, "extends" and "extended by" are fine from the RPC > perspective. We have updated the document accordingly. 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) > > > [AD] Re: Section 6 - The word 'MUST' was added based on Pascal's reply > (pasted below). Please review and approve this change (also shown in the diff > files). > > Original: > 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. > > Current: > The RPL router that merges multiple advertisements for the same > prefix MUST use and advertise the longest remaining lifetime across > all the origins of the advertisements for that prefix. > > We'll wait to hear from you again before marking your approval. > > Thank you. > > Alice Russo > RFC Production Center > >> 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 > > >> On Jan 30, 2026, at 2:23 AM, Eric Vyncke (evyncke) <[email protected]> wrote: >> >> Hi Alice, >> >> You are correct: "updates" has a very specific meaning in RFC (especially in >> the meta-data/header). >> >> Rather than "alter" what about "extend" ? >> >> -éric >> >> From: Alice Russo <[email protected]> >> Date: Wednesday, 28 January 2026 at 20:58 >> To: Eric Vyncke (evyncke) <[email protected]> >> Cc: Pascal Thubert <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]>, Shwetha >> <[email protected]>, auth48archive <[email protected]>, >> RFC Editor <[email protected]> >> Subject: [AD] Re: AUTH48: RFC-to-be 9926 >> <draft-ietf-6lo-prefix-registration-18> for your review >> >> Hi Éric, >> >> Re: https://www.rfc-editor.org/authors/rfc9926.html >> >> From discussion with Pascal, we're seeking your guidance on this topic: As >> you know, in the RFC series, the words "updates" and "updated by" are used >> for specific relationships between RFCs (even though the labels have been >> applied with various criteria over the years). So these two statements seem >> inaccurate. Would "alters" and "altered by" or other options be possible? >> >> Original: >> Section 5.5 of [RFC8505] updates [RFC4861] to signal the Registered >> Address in the Target Address field. >> >> [...] >> >> [RFC7400] was already updated by [RFC8505] for use in IPv6 ND >> messages. >> >> [Of note: RFC 8505 updates RFC 6775, not RFC 4861 or RFC 7400.] >> >> >> Perhaps: >> Section 5.5 of [RFC8505] alters [RFC4861] to signal the Registered >> Address in the Target Address field. >> >> [...] >> >> [RFC7400] was already altered by [RFC8505] for use in IPv6 ND >> messages. >> >> Thank you. >> >> Alice Russo >> RFC Production Center >> >> On Jan 27, 2026, I wrote: >> >>> - 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? >>> >>>> 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. >>> >> >> >> On Jan 26, 2026, [email protected] wrote: >> >>> 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. >>> --> > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
