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]
