How about we split the difference and go with the first 0-15 flags for standards action? We can keep the initial value of 8 for cross-sni-resumption since that document is going through the process. (We could also make it 7 or lower so we're not wasting an empty octet for this flag, should folks want to go that route.)
Any objections? Best, Chris On Sun, Dec 12, 2021, at 2:22 PM, Eric Rescorla wrote: > I'd probably reserve slightly more for standards action, maybe the > first 24 bits. Otherwise, I agree with MT. > > -Ekr > > > On Sun, Dec 12, 2021 at 12:51 PM Yoav Nir <ynir.i...@gmail.com> wrote: >> 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 >>> >>> Please comment. >>> >>> Yoav >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
