All, Lorenzo’s approval has been noted on the AUTH48 status page. With this, we have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9686
Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. RFC Editor/ap > On Dec 1, 2024, at 7:47 PM, Lorenzo Colitti <lore...@google.com> wrote: > > Alanna, > > Sorry for replying so late! I approve the revised text for publication. > > Cheers, > Lorenzo > > On Sat, Nov 23, 2024 at 2:12 AM Alanna Paloma <apal...@amsl.com> wrote: > Hi Lorenzo, > > This is a friendly reminder that we await your approval of the updated files. > Once we receive your approval, we will move this document forward in the > publication process. > > Best regards, > RFC Editor/ap > > > On Nov 15, 2024, at 8:06 AM, Alanna Paloma <apal...@amsl.com> wrote: > > > > Hi Éric, > > > > Thank you for your reply. We have noted your approval: > > https://www.rfc-editor.org/auth48/rfc9686 > > > > Best regards, > > RFC Editor/ap > > > >> On Nov 14, 2024, at 12:26 PM, Eric Vyncke (evyncke) <evyn...@cisco.com> > >> wrote: > >> > >> Thanks for your patience, I approve the change as well. > >> Note: like Lorenzo, I think the full text should be removed but it would > >> be too big a of change at this point. > >> -éric > >> From: Alanna Paloma <apal...@amsl.com> > >> Date: Thursday, 7 November 2024 at 14:10 > >> To: Eric Vyncke (evyncke) <evyn...@cisco.com>, Lorenzo Colitti > >> <lorenzo=40google....@dmarc.ietf.org>, Warren Kumari <war...@kumari.net>, > >> Suresh Krishnan <suresh.krish...@gmail.com>, rajiv.asati > >> <rajiv.as...@gmail.com>, Jen Linkova <furr...@gmail.com>, Sheng JIANG > >> <shengji...@bupt.edu.cn> > >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, dhc-ads <dhc-...@ietf.org>, > >> dhc-chairs <dhc-cha...@ietf.org>, Timothy Winters <t...@qacafe.com>, > >> auth48archive <auth48archive@rfc-editor.org> > >> Subject: [AD] Re: AUTH48: RFC-to-be 9686 > >> <draft-ietf-dhc-addr-notification-13> for your review > >> Hi Authors and Éric (AD)*, > >> > >> *Éric - As the AD, please review and approve of the deleted sentence in > >> Section 5. For context, here is Lorenzo’s reasoning for removing the > >> sentence: > >> > >>> I am proposing removing that text because the draft now states that "the > >>> client MUST determine whether the network supports address registration" > >>> before sending this message type. So a network whose servers don't > >>> support these messages can simply state that it is not supported, and the > >>> clients won't send it. I think the reason we still have this text in > >>> section 5 is that the requirement for the client to check for network > >>> support was added fairly late in the draft's cycle. But now the text is > >>> no longer necessary. In fact, I don't think there's even any need to say > >>> that the administrator SHOULD be able to disable these messages, but I > >>> don't think it's appropriate to remove that SHOULD in auth48. > >> > >> > >> See this diff file: > >> https://www.rfc-editor.org/authors/rfc9686-lastdiff.html > >> > >> > >> Authors - Thank you for your replies. We have noted approvals from Warren > >> and Suresh on the AUTH48 status page: > >> https://www.rfc-editor.org/auth48/rfc9686 > >> > >> Additionally, we have updated the files per your requests. > >> > >> The files have been posted here (please refresh): > >> https://www.rfc-editor.org/authors/rfc9686.xml > >> https://www.rfc-editor.org/authors/rfc9686.txt > >> https://www.rfc-editor.org/authors/rfc9686.html > >> https://www.rfc-editor.org/authors/rfc9686.pdf > >> > >> The relevant diff files have been posted here: > >> https://www.rfc-editor.org/authors/rfc9686-diff.html (comprehensive diff) > >> https://www.rfc-editor.org/authors/rfc9686-auth48diff.html (AUTH48 changes) > >> https://www.rfc-editor.org/authors/rfc9686-lastdiff.html (htmlwdiff diff > >> between last version and this) > >> https://www.rfc-editor.org/authors/rfc9686-lastrfcdiff.html (rfcdiff > >> between last version and this) > >> > >> We will await any further changes you may have and approvals from Rajiv, > >> Lorenzo, Jen, Sheng, and *Éric prior to moving forward in the publication > >> process. > >> > >> Thank you, > >> RFC Editor/ap > >> > >>> On Nov 7, 2024, at 9:55 AM, Lorenzo Colitti > >>> <lorenzo=40google....@dmarc.ietf.org> wrote: > >>> > >>> On Thu, Nov 7, 2024 at 4:17 PM Suresh Krishnan > >>> <suresh.krish...@gmail.com> wrote: > >>> Hi Alanna, > >>> Thanks for all your work on this. I approve the publication of this RFC > >>> (upto and including the changes proposed by Lorenzo below) but I do have > >>> an alternate proposal with slightly different text for Section 6 > >>> > >>> OLD: > >>> a malicious or compromised device cannot simply send the ADDR-REG-INFORM > >>> message > >>> > >>> NEW: > >>> a malicious or compromised device can simply choose to not send the > >>> ADDR-REG-INFORM message > >>> > >>> This version works for me as well. > >>> > >>> Also, I thought that text in Section 5 was added as the result of the WG > >>> discussion before adoption as to why turning this off is needed. I have > >>> no issue removing this but it does clarify at least one intended use for > >>> why somebody might turn it off. > >>> > >>> I am proposing removing that text because the draft now states that "the > >>> client MUST determine whether the network supports address registration" > >>> before sending this message type. So a network whose servers don't > >>> support these messages can simply state that it is not supported, and the > >>> clients won't send it. I think the reason we still have this text in > >>> section 5 is that the requirement for the client to check for network > >>> support was added fairly late in the draft's cycle. But now the text is > >>> no longer necessary. In fact, I don't think there's even any need to say > >>> that the administrator SHOULD be able to disable these messages, but I > >>> don't think it's appropriate to remove that SHOULD in auth48. > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
