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 <[email protected]> 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 <[email protected]> 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) <[email protected]> > 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 <[email protected]> > >> Date: Thursday, 7 November 2024 at 14:10 > >> To: Eric Vyncke (evyncke) <[email protected]>, Lorenzo Colitti > <[email protected]>, Warren Kumari <[email protected]>, > Suresh Krishnan <[email protected]>, rajiv.asati < > [email protected]>, Jen Linkova <[email protected]>, Sheng JIANG < > [email protected]> > >> Cc: RFC Editor <[email protected]>, dhc-ads <[email protected]>, > dhc-chairs <[email protected]>, Timothy Winters <[email protected]>, > auth48archive <[email protected]> > >> 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= > [email protected]> wrote: > >>> > >>> On Thu, Nov 7, 2024 at 4:17 PM Suresh Krishnan < > [email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
