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
