It is indeed 8446bis.... If you want to lean on him, do it. Sean may know better where that draft sits (who is holding the pen).
I would think that a small change, like you propose would be fine (and I'm sort of surprised it wasn't flagged earlier). Deb On Tue, Jun 23, 2026 at 3:32 AM Hannes Tschofenig <[email protected]> wrote: > I do not think it is me holding this up. I have given my approval a while > ago already. I believe the publication is blocked by the completion of > draft-ietf-tls-rfc8446bis. > > > Am 23.06.2026 um 07:36 schrieb Martin Thomson: > > Hi everyone, > > This has taken far, far too long. What is the hold up? > > If the answer is Ekr, as I suspect it is, I might be able to help with that. > Five months is totally unacceptable. > > Cheers, > Martin > > p.s., I have a small patch to this that I would like to request. As the > patient is open... > (In short, one of the lines of hex has one character too many on one line. > Moving that to the next line makes it neater.) > > ~~~ > diff --git a/draft-ietf-tls-keylogfile.md b/draft-ietf-tls-keylogfile.md > index 922388c..836f4fe 100644 > --- a/draft-ietf-tls-keylogfile.md > +++ b/draft-ietf-tls-keylogfile.md > @@ -467,22 +467,22 @@ CLIENT_RANDOM \ > > The following shows a log entry for a TLS 1.3 connection that successfully > negotiated ECH. > > ~~~ application/sslkeylogfile > ECH_SECRET \ > 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ > e8828ec09909cc9363179dc13b62498550c8637129345263011a1678370ca52a > ECH_CONFIG \ > 0ba587ee6b65ce21a726630efb881206a7cd995611095b5f4c244bb2b23f1ee1 \ > - fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d594\ > - e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 > + fe0d003c5500200020d5260ae4cdda08bcbdc37bd0dc53c29aea5f0fdd2b2d59 \ > + 4e4235e99b134ac904000400010001000d636f7665722e6465666f2e69650000 > CLIENT_HANDSHAKE_TRAFFIC_SECRET \ > 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ > a195b63ec4270609692a204c08e63e74d9ae58e377d11a383bfe641a63c01140 > SERVER_HANDSHAKE_TRAFFIC_SECRET \ > 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ > 022d1cb827a90f27dadde0c99110c2b7d0f362fdfe420a04818aa223e5f2c14c > CLIENT_TRAFFIC_SECRET_0 \ > 8726180bb24718089a4c5c8c93e0ea1c6d6649d7dd3c978fc1413854a20e9647 \ > c2310f7db71109de88bab6f2f433fdc1704aecc0d57349cbf9113e5033178172 > SERVER_TRAFFIC_SECRET_0 \ > ~~~ > > > On Tue, Jan 6, 2026, at 11:28, Alanna Paloma wrote: > > All, > > IANA has finished updating its registry accordingly and we now consider > AUTH48 complete:https://www.rfc-editor.org/auth48/rfc9850 > > As this document is part of Cluster C430, you may track the progress of > all documents in this cluster through AUTH48 > at:https://www.rfc-editor.org/auth48/C430 > > We will move this document forward in the publication process once the > other necessary documents in the cluster complete AUTH48 as well. > > Please let us know if you have any questions. > > Thank you, > Alanna Paloma > RFC Production Center > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
