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
