Draft: draft-ietf-quic-transport

Commentary: 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 do n'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 . ? 
 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 . 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 ? ) .   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 ) . 
 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 . 
 Do we just want to point IANA to the new text here ? 
 I have done so via email . 
 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 ) .
Paragraph (version A):
New uses of codepoints from QUIC registries SHOULD use a randomly
selected codepoint that excludes both existing allocations and the
first unallocated codepoint in the selected space.  Requests for
multiple codepoints MAY use a contiguous range.  This minimizes the
risk that differing semantics are attributed to the same codepoint by
different implementations.  Use of the first codepoint in a range is
intended for use by specifications that are developed through the
standards process STD and its allocation MUST be negotiated with IANA
before use.
Paragraph (version B):
New uses of codepoints from QUIC registries SHOULD use a randomly
selected codepoint that excludes both existing allocations and the
first unallocated codepoint in the selected space.  Requests for
multiple codepoints MAY use a contiguous range.  This minimizes the
risk that differing semantics are attributed to the same codepoint by
different implementations.
Paragraph (version B):
Use of the first available codepoint in a range is reserved for
allocation using the Standards Action policy; see Section 4.9 of
RFC8126.  The early codepoint assignment process EARLY-ASSIGN can be
used for these values.
Paragraph (version A):
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.
Paragraph (version B):
Applications to register codepoints in QUIC registries MAY include a
codepoint as part of the registration.  IANA MUST allocate the
selected codepoint if the codepoint is unassigned and the
requirements of the registration policy are met.