On Thursday, 24 May 2018 21:54:44 CEST Benjamin Kaduk wrote: > On Thu, May 24, 2018 at 02:46:26PM -0500, Nico Williams wrote: > > On Thu, May 24, 2018 at 09:30:59AM -0700, Adam Langley wrote: > > > On Wed, May 23, 2018 at 8:23 PM Peter Gutmann > > > <[email protected]> > > > > > > wrote: > > > > That's going to cause clashes with implementations that use that value > > > > for > > > > TLS-LTS, it would be better to use a value other than 26 that isn't > > > > > > already in > > > > > > > use. > > > > > > Obviously I'm not adverse to using the occasional, non-IANA code point. > > > But > > > they need to be picked randomly and outside the dense, IANA area. > > > Otherwise, this is certain to happen in short order. > > > > Why can't we make it so IANA does early codepoint assignment? > > They already do, and we've got documents approved by the IESG that make the > registration policy just "specification required" (as opposed to "IETF > review"). > > While Peter did mention the value 26 on the list two years ago, there hasn't > exactly been a lot of visible action with TLS-LTS in the intervening > period...
because the chair(s) position was that it would be detracting from TLS 1.3 work, not because the problem went away -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
