Re: [TLS] IANA Registry for TLS-Flags

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.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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls