That's fine by me.
On Mon, Dec 13, 2021 at 6:31 AM Christopher Wood <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
