Original text:
bytes. An opaque blob that the client can use with a future Initial <del> packet.  The token MUST NOT be empty.  An endpoint MUST treat receipt of a NEW_TOKEN frame with an empty Token field as a connection error of type FRAME_ENCODING_ERROR. </del>  <del> An endpoint might receive multiple NEW_TOKEN frames that contain the </del>  same token value if packets containing the frame are incorrectly <del> determined to be lost.  Endpoints are responsible for discarding </del>  duplicate values, which might be used to link connection attempts; see validate-future. <del> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt </del>  of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION.

Reviewer comments:
Since only servers can send NEW_TOKEN, using "client" is clearer. "Servers MUST treat" is used only here, so it is changed into "A server MUST treat".
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
Thanks, NAME !

Revised text:
bytes. An opaque blob that the client can use with a future Initial  <ins> packet.  The token MUST NOT be empty.  A client MUST treat receipt of a NEW_TOKEN frame with </ins>  <ins> A client might receive multiple NEW_TOKEN frames that contain the </ins> same token value if packets containing the frame are incorrectly  <ins> determined to be lost.  Clients are responsible for discarding </ins> duplicate values, which might be used to link connection attempts; see validate-future.  <ins> Clients MUST NOT send NEW_TOKEN frames.  A server MUST treat receipt </ins> of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION.