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 >>>> >>>> >>> >> >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
