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
