Hi Lorenzo, Xiao, and David, This is a friendly reminder that that we await your approvals prior to moving this document forward in the publication process.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9762.txt https://www.rfc-editor.org/authors/rfc9762.pdf https://www.rfc-editor.org/authors/rfc9762.html https://www.rfc-editor.org/authors/rfc9762.xml The relevant diff files are posted here: https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all AUTH48 changes) https://www.rfc-editor.org/authors/rfc9762-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9762-lastrfcdiff.html (rfcdiff between last version and this) Please see the AUTH48 status page for this document here: https://www.rfc-editor.org/auth48/rfc9762 Thank you, RFC Editor/ap > On May 28, 2025, at 8:41 AM, Bob Hinden <bob.hin...@gmail.com> wrote: > > Lorenzo, Xiao, David, > > I see it now waiting for your approval to be published. Please respond. > > Bob > > >> On May 28, 2025, at 8:34 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >> wrote: >> >> Hi Erik, >> >> Thank you for your approval. We’ve noted it on the AUTH48 status page: >> https://www.rfc-editor.org/auth48/rfc9762 >> >> Best regards, >> RFC Editor/ap >> >>> On May 27, 2025, at 8:54 PM, Erik Kline <ek.i...@gmail.com> wrote: >>> >>> LGTM! >>> >>> On Tue, May 27, 2025 at 2:53 PM Alanna Paloma >>> <apal...@staff.rfc-editor.org> wrote: >>> Hi Authors and Erik (AD)*, >>> >>> *Erik (AD) - This is a friendly reminder that we await your review and >>> approval of the reorder list items under “NEW TEXT” in Section 9.2. >>> >>> See this diff file: >>> https://www.rfc-editor.org/authors/rfc9762-ad-diff.html >>> >>> For context, here is Lorenzo’s rationale for this update: >>>> The issue is: according to this text, in step a), if the prefix is the >>>> link-local prefix, then the host should use PD. But elsewhere in this >>>> document (which will become RFC 9762) we say that the P flag is >>>> meaningless for link-local prefixes, and should be ignored. Specifically, >>>> it says "The P flag is meaningless for link-local prefixes, and any PIO >>>> containing the link-local prefix MUST be ignored as specified in Section >>>> 5.5.3 of [RFC4862]." which causes a reference cycle. >>>> >>>> We could reorder the bullet points, like so, resulting in the following: >>> … >>>> Thoughts?I think we should fix this, but if this is difficult to fix in >>>> AUTH48, I think it's OK not to change it because step a) says "as >>>> described in RFC 9762" and RFC 9762 says that because the prefix is >>>> link-local it should be ignored anyway. And implementers can probably just >>>> ignore the reference cycle because from the text it's sort of clear what >>>> to do anyway. >>>> >>>> +Erik Kline any thoughts on whether we can fix this in AUTH48? >>> >>> Original: >>> For each Prefix-Information option in the Router Advertisement: >>> >>> a) If the P flag is set, and the node implements draft-ietf-6man-pio- >>> pflag, it SHOULD treat the Autonomous flag as if it was unset, and >>> use prefix delegation to obtain addresses as described in draft-ietf- >>> 6man-pio-pflag. >>> >>> b) If the Autonomous flag is not set, silently ignore the Prefix >>> Information option. >>> >>> c) If the prefix is the link-local prefix, silently ignore the Prefix >>> Information option. >>> >>> Current: >>> For each Prefix Information Option in the Router Advertisement: >>> >>> a) If the prefix is the link-local prefix, silently ignore the >>> Prefix Information Option. >>> >>> b) If the P flag is set and the node implements RFC 9762, it >>> SHOULD treat the Autonomous flag as if it was unset and use >>> prefix delegation to obtain addresses as described in RFC >>> 9762. >>> >>> c) If the Autonomous flag is not set, silently ignore the Prefix >>> Information Option. >>> >>> >>> Authors - Please review the document carefully and contact us with any >>> further updates you may have. We will await approvals from Lorenzo, Xiao, >>> David, and *Erik prior to moving forward in the publication process. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9762.txt >>> https://www.rfc-editor.org/authors/rfc9762.pdf >>> https://www.rfc-editor.org/authors/rfc9762.html >>> https://www.rfc-editor.org/authors/rfc9762.xml >>> >>> The relevant diff files are posted here: >>> https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all AUTH48 >>> changes) >>> https://www.rfc-editor.org/authors/rfc9762-lastdiff.html (htmlwdiff diff >>> between last version and this) >>> https://www.rfc-editor.org/authors/rfc9762-lastrfcdiff.html (rfcdiff >>> between last version and this) >>> >>> Please see the AUTH48 status page for this document here: >>> https://www.rfc-editor.org/auth48/rfc9762 >>> >>> Thank you, >>> RFC Editor/ap >>> >>>> On May 20, 2025, at 2:16 PM, Alanna Paloma <apal...@staff.rfc-editor.org> >>>> wrote: >>>> >>>> Hi Erik (AD)*, Lorenzo, and other authors, >>>> >>>> *Erik - As the AD, please review and approve of the reordered list items >>>> under “NEW TEXT” in Section 9.2. >>>> >>>> See this diff file: >>>> https://www.rfc-editor.org/authors/rfc9762-ad-diff.html >>>> >>>> For context, here is Lorenzo’s rationale for this update: >>>>> The issue is: according to this text, in step a), if the prefix is the >>>>> link-local prefix, then the host should use PD. But elsewhere in this >>>>> document (which will become RFC 9762) we say that the P flag is >>>>> meaningless for link-local prefixes, and should be ignored. Specifically, >>>>> it says "The P flag is meaningless for link-local prefixes, and any PIO >>>>> containing the link-local prefix MUST be ignored as specified in Section >>>>> 5.5.3 of [RFC4862]." which causes a reference cycle. >>>>> >>>>> We could reorder the bullet points, like so, resulting in the following: >>>> … >>>>> Thoughts?I think we should fix this, but if this is difficult to fix in >>>>> AUTH48, I think it's OK not to change it because step a) says "as >>>>> described in RFC 9762" and RFC 9762 says that because the prefix is >>>>> link-local it should be ignored anyway. And implementers can probably >>>>> just ignore the reference cycle because from the text it's sort of clear >>>>> what to do anyway. >>>>> >>>>> +Erik Kline any thoughts on whether we can fix this in AUTH48? >>>> >>>> >>>> Original: >>>> For each Prefix-Information option in the Router Advertisement: >>>> >>>> a) If the P flag is set, and the node implements draft-ietf-6man-pio- >>>> pflag, it SHOULD treat the Autonomous flag as if it was unset, and >>>> use prefix delegation to obtain addresses as described in draft-ietf- >>>> 6man-pio-pflag. >>>> >>>> b) If the Autonomous flag is not set, silently ignore the Prefix >>>> Information option. >>>> >>>> c) If the prefix is the link-local prefix, silently ignore the Prefix >>>> Information option. >>>> >>>> Current: >>>> For each Prefix Information Option in the Router Advertisement: >>>> >>>> a) If the prefix is the link-local prefix, silently ignore the >>>> Prefix Information Option. >>>> >>>> b) If the P flag is set and the node implements RFC 9762, it >>>> SHOULD treat the Autonomous flag as if it was unset and use >>>> prefix delegation to obtain addresses as described in RFC >>>> 9762. >>>> >>>> c) If the Autonomous flag is not set, silently ignore the Prefix >>>> Information Option. >>>> >>>> >>>> Authors - We have updated the files per the additional changes sent by >>>> Lorenzo. We will await any further changes you may have and approvals from >>>> Lorenzo, Xiao, David, >>>> and *Erik prior to moving forward in the publication process. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9762.txt >>>> https://www.rfc-editor.org/authors/rfc9762.pdf >>>> https://www.rfc-editor.org/authors/rfc9762.html >>>> https://www.rfc-editor.org/authors/rfc9762.xml >>>> >>>> The relevant diff files are posted here: >>>> https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive diff) >>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all AUTH48 >>>> changes) >>>> https://www.rfc-editor.org/authors/rfc9762-lastdiff.html (htmlwdiff diff >>>> between last version and this) >>>> https://www.rfc-editor.org/authors/rfc9762-lastrfcdiff.html (rfcdiff >>>> between last version and this) >>>> >>>> Please see the AUTH48 status page for this document here: >>>> https://www.rfc-editor.org/auth48/rfc9762 >>>> >>>> Thank you, >>>> RFC Editor/ap >>>> >>>>> On May 19, 2025, at 5:09 PM, Lorenzo Colitti <lore...@google.com> wrote: >>>>> >>>>> Another potential issue I see is in the formal update text of the RFC >>>>> 4861 update. The issue is here: >>>>> >>>>> ========= >>>>> NEW TEXT: >>>>> >>>>> For each Prefix Information Option in the Router Advertisement: >>>>> >>>>> a) If the P flag is set and the node implements RFC 9762, it SHOULD treat >>>>> the Autonomous flag as if it was unset and use prefix delegation to >>>>> obtain addresses as described in RFC 9762. >>>>> b) If the Autonomous flag is not set, silently ignore the Prefix >>>>> Information Option. >>>>> c) If the prefix is the link-local prefix, silently ignore the Prefix >>>>> Information Option. >>>>> ========= >>>>> >>>>> The issue is: according to this text, in step a), if the prefix is the >>>>> link-local prefix, then the host should use PD. But elsewhere in this >>>>> document (which will become RFC 9762) we say that the P flag is >>>>> meaningless for link-local prefixes, and should be ignored. Specifically, >>>>> it says "The P flag is meaningless for link-local prefixes, and any PIO >>>>> containing the link-local prefix MUST be ignored as specified in Section >>>>> 5.5.3 of [RFC4862]." which causes a reference cycle. >>>>> >>>>> We could reorder the bullet points, like so, resulting in the following: >>>>> >>>>> ========= >>>>> NEW TEXT: >>>>> For each Prefix Information Option in the Router Advertisement: >>>>> >>>>> a) If the prefix is the link-local prefix, silently ignore the Prefix >>>>> Information Option. >>>>> b) If the P flag is set and the node implements RFC 9762, it SHOULD treat >>>>> the Autonomous flag as if it was unset and use prefix delegation to >>>>> obtain addresses as described in RFC 9762. >>>>> c) If the Autonomous flag is not set, silently ignore the Prefix >>>>> Information Option. >>>>> ========= >>>>> >>>>> Thoughts?I think we should fix this, but if this is difficult to fix in >>>>> AUTH48, I think it's OK not to change it because step a) says "as >>>>> described in RFC 9762" and RFC 9762 says that because the prefix is >>>>> link-local it should be ignored anyway. And implementers can probably >>>>> just ignore the reference cycle because from the text it's sort of clear >>>>> what to do anyway. >>>>> >>>>> +Erik Kline any thoughts on whether we can fix this in AUTH48? >>>>> >>>>> Cheers, >>>>> Lorenzo >>>>> >>>>> On Tue, May 20, 2025 at 8:54 AM Lorenzo Colitti <lore...@google.com> >>>>> wrote: >>>>> Hi Alanna, >>>>> >>>>> I would like to suggest the following changes. >>>>> >>>>> Section 7.1: >>>>> OLD: >>>>> any time a prefix is added to or removed from the list, the client MUST >>>>> consider this to be a change in configuration information >>>>> NEW: >>>>> any time one or more prefix(es) are added to or removed from the list, >>>>> the client MUST consider this to be a change in configuration information >>>>> >>>>> Rationale: if the RA has more than one prefix in it, the client should >>>>> only rebind once. >>>>> >>>>> >>>>> Section 7.4: >>>>> OLD: >>>>> When the network delegates unique prefixes to clients, each client will >>>>> consider other client's destination addresses to be off-link >>>>> NEW: >>>>> When the network delegates unique prefixes to clients, each client will >>>>> consider other clients's destination addresses to be off-link >>>>> >>>>> Rationale: "clients" is plural and the apostrophe goes after the s. >>>>> >>>>> >>>>> Section 11: >>>>> OLD: >>>>> Implementing the P flag support on a host and receiving side enables >>>>> DHCPv6 on that host. >>>>> NEW: >>>>> Implementing the P flag support on a host and receiving will enable >>>>> DHCPv6 on that host if the host receives an RA containing a PIO with the >>>>> P bit set. >>>>> >>>>> Rationale: the text doesn't really make sense. Previous versions of the >>>>> draft (I checked -06) had "Implementing the P flag support on a host / >>>>> receiving side" instead of "Implementing the P flag support on a host and >>>>> receiving side". That was slightly better, but I think my new text is >>>>> clearer. >>>>> >>>>> Also, I would like to add Patrick Rohr to the acknowledgements section, >>>>> since he pointed out one of these issues. >>>>> >>>>> Cheers, >>>>> Lorenzo >>>>> >>>>> On Wed, May 14, 2025 at 3:16 AM Alanna Paloma >>>>> <apal...@staff.rfc-editor.org> wrote: >>>>> Hi Jen, >>>>> >>>>> Thank you for confirming. Additionally, we have noted your approval on >>>>> the AUTH48 status page. >>>>> >>>>> We will await approvals from Lorenzo, Xiao, and David prior to moving >>>>> this document forward in the publication process. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9762.txt >>>>> https://www.rfc-editor.org/authors/rfc9762.pdf >>>>> https://www.rfc-editor.org/authors/rfc9762.html >>>>> https://www.rfc-editor.org/authors/rfc9762.xml >>>>> >>>>> The relevant diff files are posted here: >>>>> https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all AUTH48 >>>>> changes) >>>>> >>>>> Please see the AUTH48 status page for this document here: >>>>> https://www.rfc-editor.org/auth48/rfc9762 >>>>> >>>>> Thank you, >>>>> RFC Editor/ap >>>>> >>>>>> On May 13, 2025, at 9:30 AM, Jen Linkova <furr...@gmail.com> wrote: >>>>>> >>>>>> On Wed, May 14, 2025 at 2:17 AM Alanna Paloma >>>>>> <apal...@staff.rfc-editor.org> wrote: >>>>>>> Thank you for your reply. Your approval regarding the BCP 14 key word >>>>>>> update has been noted on the AUTH48 status page: >>>>>>> https://www.rfc-editor.org/auth48/rfc9762 >>>>>>> >>>>>>> Please note that we are still awaiting the outcome of the discussion >>>>>>> proposed by Jen: >>>>>>> >>>>>>>>> 6) <!-- [rfced] *AD and authors - There is an open erratum report >>>>>>>>> against RFC >>>>>>>>> 4861 regarding the text that is being updated in Section 9.1 of this >>>>>>>>> document. Are any updates needed? >>>>>>>>> >>>>>>>>> See https://www.rfc-editor.org/errata/eid8055. >>>>>>>>> --> >>>>>>>> >>>>>>>> There is no conflict in spirit between the filed erratum and this >>>>>>>> document. But if the erratum is approved then the text of this >>>>>>>> document should be updated to reflect the erratum, and say: >>>>>>>> “Note: If none of the M, O, or P (draft-ietf-6man-pio-pflag) flags are >>>>>>>> set, this indicates that no information is available via DHCPv6 from >>>>>>>> the router, or from other nodes that the router has been made aware >>>>>>>> of". >>>>>>>> >>>>>>>> With my 6MAN chair hat on: let the chairs discuss it with the AD. I >>>>>>>> think it would be better if the decision for the erratum is made >>>>>>>> before this draft is published. >>>>>> >>>>>> I believe Erik marked the erratum as 'Held for the document update'. >>>>>> So the text in RFC4861 is not going to change, and we can proceed with >>>>>> this draft. >>>>>> >>>>>>>> On May 12, 2025, at 11:08 PM, Erik Kline <ek.i...@gmail.com> wrote: >>>>>>>> >>>>>>>> LGTM; thank you! >>>>>>>> >>>>>>>> On Tue, May 6, 2025 at 8:25 AM Alanna Paloma >>>>>>>> <apal...@staff.rfc-editor.org> wrote: >>>>>>>> Hi Authors and Erik (AD)*, >>>>>>>> >>>>>>>> *Erik (AD) - This is another friendly reminder that we are awaiting >>>>>>>> your review and approval regarding the BCP 14 key word update from >>>>>>>> “MUST not” to “MUST NOT” in the sentence below: >>>>>>>> >>>>>>>> Original: >>>>>>>> In particular, enabling or disabling the P flag MUST not trigger >>>>>>>> automatic changes in the A flag value set by the router. >>>>>>>> >>>>>>>> Current: >>>>>>>> In particular, enabling or disabling the P flag MUST NOT trigger >>>>>>>> automatic changes in the A flag value set by the router. >>>>>>>> >>>>>>>> See this diff file: >>>>>>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html >>>>>>>> >>>>>>>> Additionally, we are still awaiting word regarding this query: >>>>>>>>>> 6) <!-- [rfced] *AD and authors - There is an open erratum report >>>>>>>>>> against RFC >>>>>>>>>> 4861 regarding the text that is being updated in Section 9.1 of this >>>>>>>>>> document. Are any updates needed? >>>>>>>>>> >>>>>>>>>> See https://www.rfc-editor.org/errata/eid8055. >>>>>>>>>> --> >>>>>>>>> >>>>>>>>> There is no conflict in spirit between the filed erratum and this >>>>>>>>> document. But if the erratum is approved then the text of this >>>>>>>>> document should be updated to reflect the erratum, and say: >>>>>>>>> “Note: If none of the M, O, or P (draft-ietf-6man-pio-pflag) flags are >>>>>>>>> set, this indicates that no information is available via DHCPv6 from >>>>>>>>> the router, or from other nodes that the router has been made aware >>>>>>>>> of". >>>>>>>>> >>>>>>>>> With my 6MAN chair hat on: let the chairs discuss it with the AD. I >>>>>>>>> think it would be better if the decision for the erratum is made >>>>>>>>> before this draft is published. >>>>>>>> >>>>>>>> >>>>>>>> Authors - We will await any further updates you may have as well as >>>>>>>> approvals from each party listed on the AUTH48 status page below prior >>>>>>>> to moving this document forward in the publication process. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9762.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9762.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9762.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9762.xml >>>>>>>> >>>>>>>> The relevant diff files are posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive >>>>>>>> diff) >>>>>>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all AUTH48 >>>>>>>> changes) >>>>>>>> >>>>>>>> Please see the AUTH48 status page for this document here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9762 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/ap >>>>>>>> >>>>>>>>> On Apr 25, 2025, at 9:54 AM, Alanna Paloma >>>>>>>>> <apal...@staff.rfc-editor.org> wrote: >>>>>>>>> >>>>>>>>> Hi Authors and Erik (AD)*, >>>>>>>>> >>>>>>>>> *Erik (AD) - This is a friendly reminder that we are awaiting your >>>>>>>>> review and approval regarding the BCP 14 key word update from “MUST >>>>>>>>> not” to “MUST NOT” in the sentence below: >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> In particular, enabling or disabling the P flag MUST not trigger >>>>>>>>> automatic changes in the A flag value set by the router. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> In particular, enabling or disabling the P flag MUST NOT trigger >>>>>>>>> automatic changes in the A flag value set by the router. >>>>>>>>> >>>>>>>>> See this diff file: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html >>>>>>>>> >>>>>>>>> Additionally, we are still awaiting word regarding this query: >>>>>>>>>>> 6) <!-- [rfced] *AD and authors - There is an open erratum report >>>>>>>>>>> against RFC >>>>>>>>>>> 4861 regarding the text that is being updated in Section 9.1 of this >>>>>>>>>>> document. Are any updates needed? >>>>>>>>>>> >>>>>>>>>>> See https://www.rfc-editor.org/errata/eid8055. >>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> There is no conflict in spirit between the filed erratum and this >>>>>>>>>> document. But if the erratum is approved then the text of this >>>>>>>>>> document should be updated to reflect the erratum, and say: >>>>>>>>>> “Note: If none of the M, O, or P (draft-ietf-6man-pio-pflag) flags >>>>>>>>>> are >>>>>>>>>> set, this indicates that no information is available via DHCPv6 from >>>>>>>>>> the router, or from other nodes that the router has been made aware >>>>>>>>>> of". >>>>>>>>>> >>>>>>>>>> With my 6MAN chair hat on: let the chairs discuss it with the AD. I >>>>>>>>>> think it would be better if the decision for the erratum is made >>>>>>>>>> before this draft is published. >>>>>>>>> >>>>>>>>> >>>>>>>>> Authors - We will await any further changes you may have and >>>>>>>>> approvals from each author and the *AD prior to moving forward in the >>>>>>>>> publication process. >>>>>>>>> >>>>>>>>> The files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762.xml >>>>>>>>> >>>>>>>>> The relevant diff files are posted here: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762-diff.html (comprehensive >>>>>>>>> diff) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9762-auth48diff.html (all >>>>>>>>> AUTH48 changes) >>>>>>>>> >>>>>>>>> Please see the AUTH48 status page for this document here: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9762 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> RFC Editor/ap >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, Jen Linkova >>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
