Hi, I approve this version. I've reviewed the diff carefully and I think it's now ready.
Apologies it took so long. As usual, life got in the way. Tomek On 13.01.2026 21:58, Megan Ferguson wrote: > Authors (*Tomek and *Éric), > > Thank you for your replies. We have updated to use Bernie’s first > suggestion. > > *Éric - we have updated your status to “Approved” at the AUTH48 status page > (see below) as we believe this resolves your remaining outstanding issue. > > Once we have approval from *Tomek, we will be ready to move this version > forward in the publication process. > > Please review the files carefully as we do not make changes after > publication. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915.txt > https://www.rfc-editor.org/authors/rfc9915.pdf > https://www.rfc-editor.org/authors/rfc9915.html > https://www.rfc-editor.org/authors/rfc9915.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9915-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9915-rfcdiff.html (comprehensive side > by side) > https://www.rfc-editor.org/authors/rfc9915-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9915-auth48rfcdiff.html (AUTH48 side by > side) > https://www.rfc-editor.org/authors/rfc9915-lastdiff.html (last version to > this) > https://www.rfc-editor.org/authors/rfc9915-lastrfcdiff.html (last to this > side by side) > > Please contact us with any further updates/questions/comments you may have. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9915 > > Thank you. > > Megan Ferguson > RFC Production Center > >> On Jan 8, 2026, at 6:23 AM, Timothy Winters <[email protected]> wrote: >> >> I also like the first version of the text. >> >> ~Tim >> >> On Thu, Jan 8, 2026 at 1:39 AM Eric Vyncke (evyncke) <[email protected]> >> wrote: >> Like Bernie, I prefer the first version of the new text. >> >> -éric >> >> From: Megan Ferguson <[email protected]> >> Date: Thursday, 8 January 2026 at 01:10 >> To: Michael Richardson <[email protected]>, Bernie Volz >> <[email protected]>, Tomek Mrugalski <[email protected]>, Eric >> Vyncke (evyncke) <[email protected]> >> Cc: [email protected] <[email protected]>, Editor RFC >> <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]>, Suresh Krishnan >> (sureshk) <[email protected]>, Shawn Zandi via auth48archive >> <[email protected]> >> Subject: Re: [AD] AUTH48: RFC-to-be 9915 <draft-ietf-dhc-rfc8415bis-12> for >> your review >> >> Hi Tomek (and *Éric), >> >> Any further thoughts/suggestions or preference related to one of these >> options from Bernie? >> >> >>>>>>> 7. Can client send status code? >>>>>>> >>>>>>> The table in Section 21.13 lists UnspecFail status code with this text: >>>>>>> "...this status code is sent by either a client or a server to indicate >>>>>>> a failure...". In which cases client would be sending status code? I >>>>>>> don't remember ever seeing client sending a status code in the wild. Is >>>>>>> this to indicate some weird failure in reconfigure? Do we have a >>>>>>> normative text somewhere that would say "client sends status code if >>>>>>> ..."? I'm not sure what would be the point. What would the server be >>>>>>> supposed to do with such information? >>>>>>> >>>>>> bv> you are correct that a client cannot send a status code, at least in >>>>>> the messages covered by this document. Again 3315 and 8415 have this >>>>>> text. Though I am a bit unsure as to whether we should actually change >>>>>> this text. >>>>> [rfced] Please let us know how to proceed (perhaps *AD input could help?). >>>>> >>>>> AD> Let's avoid ambiguities and update the text to be clear that status >>>>> code is sent by the server only and should be ignored by the server upon >>>>> receiving any status code. Authors, can you propose OLD/NEW text ? >> >> Bernie’s suggestions that were favored by Michael: >>> >>> Bernie Volz <[email protected]> wrote: >>>> UnspecFail 1 Failure, reason unspecified; this status code >>>> is sent by a server to indicate a failure not explicitly specified in >>>> this document. >>> >>> I prefer this one. >>> (Not sure if my middle-of-the-night phone poking worked) >>> >>>> Or, we could use (as the two conditions where this is used in the text >>>> are clear indications that this is sent by server to client): >>> >>>> UnspecFail 1 Failure, reason unspecified; indicates a >>>> failure not explicitly specified in this document. >>> >>> This one also works for me. >>> >>> >>> >> Thank you. >> >> Megan Ferguson >> RFC Production Center > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
