Well, that’s two voices for Martin’s PR and just me liking the convoluted text that I wrote.
Chairs, care to call consensus? Yoav > On 7 Dec 2021, at 23:21, Yoav Nir <ynir.i...@gmail.com> wrote: > > Hi. > > We have one outstanding issue about the TLS-Flags draft. It’s about the IANA > registry. The way the extension is defined, low identifiers for flags result > in shorter extension encoding. For this reason, we want the most popular > flags to have low numbers. This is especially true for flags that everyone > will use (think RI) > > So the current text says this: > > 4.1. Guidance for IANA Experts > > This extension allows up to 2040 flags. However, they are not all > the same, because the length of the extension is determined by the > highest set bit. > > We would like to allocate the flags in such a way that the typical > extension is as short as possible. The scenario we want to guard > against is that in a few years some extension is defined that all > implementations need to support and that is assigned a high number > because all of the lower numbers have already been allocated. An > example of such an extension is the Renegotiation Indication > Extension defined in [RFC5746]. > > For this reason, the IANA experts should allocate the flags as > follows: > > * Flags 0-7 are reserved for documents coming out of the TLS working > group with a specific request to assign a low number. > > * Flags 8-31 are for standards-track documents that the experts > believe will see wide adoption among either all users of TLS or a > significant group of TLS users. For example, an extension that > will be used by all web clients or all smart objects. The only > entry in the initial registry is from this range. > > * Flags 32-63 are for other documents, including experimental, that > are likely to see significant adoption. > > * Flags 64-79 are not to be allocated. They are for reserved for > private use. > > * Flags 80-2039 can be used for temporary allocation in experiments, > for flags that are likely to see use only in very specific > environments, for national and corporate extensions, and as > overflow, in case one of the previous categories has been > exhausted. > > > Quite verbose. Martin Thomson suggests a shorter version that only reserves > flags 0-7 for standards action and leaves everything else for “specification > required”. No reservation for special request. No private use reserve. No > experimental or judgment based on the likelihood of wide adoption: > > https://github.com/tlswg/tls-flags/pull/14/files > <https://github.com/tlswg/tls-flags/pull/14/files> > > Please comment. > > Yoav >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
