Change:
IANA is also requested to create a new registry under the TLS namespace with name "TLS Flags" and the following fields: <del> Value, which is a number between 0 and 63.  All potential values </del> <ins> Value, which is a number between 0 and 2039.  All potential values </ins> are available for assignment. Flag Name, which is a string

Discussion:
See Issue draft-01 had three different versions of how many flags are possible to encode with this extension. This PR makes them all the same: up to 2048 flags.
The drafts says that values from 0 to 63 (inclusive) can be registered. But the syntax says , which implies 0 to 247. Which is it?
Reading it over, it seems worse than that. The draft contains three versions: Section 2 says "...allowing for the encoding of an unbounded number of features." The structure in section 2 has which implies 256 possible flags The IANA text has up to 64 flags Regardless, I think that the type for the flags field should be opaque: bistrings are not integers. And it's not going to be literally unbounded. Eight times the maximum length can be huge, but not quite unbounded. I think 64 will likely be enough, but I see no reason to artificially limit this. We can do and support up to 2048 flags without "wasting" even 1 byte. Of course, we can increase the length field to two bytes and allow up to 524,288 flags, but that seems over the top. So I'll make a pull request to align all three mentions to 255 bytes / 2048 flags.
Thanks, that seems like a fine idea. I agree that a two-byte length would make the overheads for the first few uses of this worse. And 2040 is an insanely large number of flags. Right now, signaling two flags this way costs 6 bytes as opposed to 8 with empty extensions. What seems more likely here is that we might need to split this into multiple extensions because the cost of flag 670 is too high if you aren't using smaller-valued flags. Note that this is 2040 (you can't include 256 bytes, the limit is 255).
I agree that anything beyond 128-bits seems to require many more bytes than the actual extension encoding. I'd prefer if this is capped to 64 or 128-bits.
I agree that anything beyond 128 is weird and would be an indication of mismanagement by TLS chairs and the IANA experts. Still, the format supports 2040 flags, and any other limit is arbitrary and can lead to buggy implementations enforcing or not enforcing such a limit.

I prefer to leave it to chairs and IANA experts to be responsible gatekeepers, rather than tying their hands with artificial limits in rhe draft.
Future chairs and IANA experts would not have the insights you have at this point, so what you call mismanagement, it may not seem so in the future. I think some guidance in the IANA section indicating what you wrote above (that this extension is efficient and has most value when the extensions defined are using less than 128-bits), would give the proper guidance to them, to decide whether they continue using the extension or define another one. Otherwise if no guidance is provided and given that only "specification required" is necessary for a new flag to be defined, I find it likely that not all specifications using this flag will understand the repercussions of going more than 128-bits.
I agree. Did you see my message to the list? It went something like First octet is for standards-track documents coming out of TLS where the draft specifically requests such assignment. Like if we ever need a renegotiation_info again.Octets 2-4 are for other standards-track documents. Octets 5-7 are for experimental drafts. They don’t get re-assigned if they later become standards track Octets 8 are reserved-private Octets beyond that are in case we need more. And I think we can modify the last one to be just the low-quality flags, like vendor extensions or national extensions. Hopefully, implementations can work OK while ignoring those.
NAME NAME is this now resolved with having been merged?
NAME I think so. I will create the PR about IANA considerations guidance soonish.