Subject: [quicwg/base-drafts] IANA review of -transport; question 4 (#4379)

From: Lars Eggert <[email-masked]>
Date: Mon, 16 Nov 2020 22:09:19 -0800

Please see the [review email](https://mailarchive.ietf.org/arch/msg/quic/xlL0IKet4F_QwoiesvANZ32YsKQ) 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."
>
>What if it's the first unallocated codepoint in a range, but not in the registry?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4379

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Nov 2020 06:28:50 -0800

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? 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4379#issuecomment-728964260

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Nov 2020 06:44:43 -0800

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4379#issuecomment-728974382

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Nov 2020 07:04:27 -0800

So in #4378 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. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4379#issuecomment-728987790