Hi Xiao, Your approval has been noted on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9762
Thank you, RFC Editor/ap > On Jun 8, 2025, at 5:03 PM, Xiao Ma <xi...@google.com> wrote: > > Hi Alanna, > > Sorry for the late reply, read the documentation/diff again, looks good to > me! Approve the updated text for publication. > > Thanks, > Xiao > > On Fri, Jun 6, 2025 at 12:51 AM Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > Hi Lorenzo, > > Thank you for your reply. We have noted your approval on the AUTH48 status > page and updated the files accordingly. > > 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 > > Once Xiao and David approve, we will move forward with the publication > process. > > Best regards, > RFC Editor/ap > > > > On Jun 4, 2025, at 6:08 PM, Lorenzo Colitti <lore...@google.com> wrote: > > > > Hi, > > > > Sorry for the delay. I approve the document. If possible the following > > minor changes, but very much optional - LGTM either way. > > > > Section 10: "disrupt hosts connectivity anyway" -> "disrupt hosts' > > connectivity anyway" OR "disrupt hosts's connectivity anyway" > > Section 11: "DHCPv6 for assigning individual addresses" -> "DHCPv6 to > > assign individual addresses" > > > > Thanks, > > Lorenzo > > > > On Thu, Jun 5, 2025 at 5:33 AM Alanna Paloma <apal...@staff.rfc-editor.org> > > wrote: > > 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
