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
