Re: [TLS] IANA Registry for TLS-Flags

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.ietf@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.ietf@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
>