Lorenzo, Jen, Do you have some other means to encourage Xiao and David to respond?
Bob > 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 > <mailto: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 >> > <mailto: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 >> >> <mailto: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 >> >>> <mailto:ek.i...@gmail.com>> wrote: >> >>> >> >>> LGTM! >> >>> >> >>> On Tue, May 27, 2025 at 2:53 PM Alanna Paloma >> >>> <apal...@staff.rfc-editor.org <mailto: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 <mailto: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 >> >>>>> <mailto: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 >> >>>>> <mailto: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 <mailto: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 >> >>>>>> <mailto:furr...@gmail.com>> wrote: >> >>>>>> >> >>>>>> On Wed, May 14, 2025 at 2:17 AM Alanna Paloma >> >>>>>> <apal...@staff.rfc-editor.org <mailto: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 >> >>>>>>>> <mailto:ek.i...@gmail.com>> wrote: >> >>>>>>>> >> >>>>>>>> LGTM; thank you! >> >>>>>>>> >> >>>>>>>> On Tue, May 6, 2025 at 8:25 AM Alanna Paloma >> >>>>>>>> <apal...@staff.rfc-editor.org >> >>>>>>>> <mailto: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 >> >>>>>>>>> <mailto: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 >> >>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >>
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
