Draft: draft-ietf-tls-tlsflags

Commentary: No other advice is needed . 
 My interpretation of these is that these reduce to something like : 0 - 31 - standards action 32 - 63 - ? ? ? ( something like RFC Required or maybe Specification Required ) 64 - 79 - might as well burn these for all the good they will do 80 + - open season ( FCFS ? ) I can see the rationale for standards action here , but the rest of this should just be expert review ( or specification required ) along with guidance to experts . As this requires judgment , and the proponents of a new flag will lack the necessary perspective to have good judgment , a lot does depend on the nature of the guidance to experts . The document will need to provide experts with support that they can rely on : right now , the text does not do that . It relies too heavily on good judgment . If there is concrete advice that can be given about how to pick a value , then the document should do that . If it ca n't , as I suspect is the case , then it should either give experts the power to pick or just let authors grab for short values . 
 All TLS registries are " expert review " with no FCFS . I do n't think we want this one to be the outlier . So how about making the segmentation in section 4 , something like Then I can reduce the content of section 4.1 and just advise the expert to assign the first 7 bits only with a specific request from the WG . I do n't want to specify the TLS working group , because something like this could potentially ( though not likely ) come from UTA or some such . 
 I do n't think that sequential assignment has worked well for us . I would remove that part and maybe change the assignment rule to be " at the discretion of the expert " across the board , with a reminder that small values are more valuable and so should be reserved for things that are going to be used more often . 
 Fixed by .
The policy for this shall be "Specification Required" as described in
RFC8126.
The policy for this shall be "Specification Required" as described in
RFC8126 with the exception of flags numbered from 0-15, which follow
the "Standards Action" policy (RFC8126).  Designated expert(s) are
advised to follow the advice in RFC8447 when reviewing registration
requests.
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.
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.