Change:
Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration.  IANA MUST allocate the <del> selected codepoint unless that codepoint is already assigned or the codepoint is the first unallocated codepoint in the registry. </del> <ins> selected codepoint if the codepoint is unassigned and the requirements of the registration policy are met. </ins> 22.1.3.

Discussion:
And cite RFC 7120 for how that can be assigned.
Oops, I realized that this was marked "design". I'll reopen the issue so that we don't lose it.
Please see the for full context. This issue is tracking the following IANA question: >IANA Question --> Section 22.1.2 says, "Applications to register codepoints in QUIC registries MAY include a codepoint as part of the registration. IANA MUST allocate the selected codepoint unless that codepoint is already assigned or the codepoint is the first unallocated codepoint in the registry."
I think it is a good question that has two aspects. If a registrant is requesting additional consecutive values beyond an earlier registration is that okay? But other registrants they need to draw a new random value to not block the next value? Or any future allocation should have to select a new random value? Also, is it IANA or the designated expert that is making the determination if this request is allowed or not?
I think what this is intended to convey is: Permanent registrations for the first unallocated codepoint are intended for use in Standards-track documents The "negotiation" involved in a provisional registration is essentially to confirm that the requestor is doing so for use in a document which is likely to become a Standards-track RFC. It's the "likely to" that becomes squishy. Do we actually need this?
So in I have a comment that indicates a potential solution or direction for how to work with this using either of two process that will be clearer. Either provisional for test and development value and then assign a final value when approving the specification, or early allocation per RFC 7120. I also like to point out that there is very large hole in this algorithm. If a registry has assigned 0-N then asking for N+1 is rejected, but asking for N+2 is the approved without question per these rules unless you are in a registry with the special rules for 0-63 values.
Could we make some progress here?
I think fixes this too. NAME ?
This was fixed by
Please see the for full context. This issue is tracking the following IANA question: intended for use by specifications that are developed through the standards process [STD] and its allocation MUST be negotiated with IANA before use."

When talking to IANA today, they did ask about how early allocation (RFC7120) interacts with this question. So I understand why IANA react to the "negotiate" language as that is requiring them to apply value judgment rather than follow basic rules to allocate or not. So I think there are a couple of different way here. Require standards action for allocation with the first unallocated value. During the development phase of that option the document recommends either of these two options. A. Use a randomly selected value Provisional assignment. When going for approval specify that a new code point is allocated that has that specific property desired (short encoding?). B. Request early allocation (RFC7120) for that standards action code point. I think what one uses has a lot to do with the perceived maturity of what the code point represent. I think A has significant advantages as if one need to do format changes one can simply request a new provisional code point, that is not possible with B. I think there may exist a point of making it clear also for IETF / Standards Process work that there is a point of doing provisional registrations as soon as one need a code point for testing.
I think that this is a good plan. I've created for that. This says that the first available codepoint is reserved for Standards Action. I've also pointed to 7120, which was always the intended process (I was just lazy about finding and citing it).
NAME why did you reopen this?
The change in was marked as design; I figured that you (as chairs) would want to discuss and resolve.
Ah, I missed that - thanks.
NAME Do we just want to point IANA to the new text here?
I have done so via email.
NAME did IANA respond to your email? do they still have questions or is this resolved?
We got what we needed and I just merged the change.
Closing this now that the IESG have approved the document(s).