Change:
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 can'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 don'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 don't want to specify the TLS working group, because something like this could potentially (though not likely) come from UTA or some such.
I don'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 .

Discussion:
Reference, which is a link to the document defining this flag. The policy for this shall be "Specification Required" as described in <del> RFC8126. </del> <ins> 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. </ins> The initial contents of the registry shall be one entry, as follows:

The reference shall the the RFC-to-be I-D.ietf-tls-cross-sni- resumption. <del> 4.1. 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. </del> 5. The extension described in this document provides a more concise way