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
