Subject: Early Allocation

From: Martin Duke <[email-masked]>
Date: Tue, 4 Jan 2022 15:35:43 -0800

Hi Chairs,

I hereby request early allocation of 0x70 9a 50 c4 in the QUIC versions
registry for draft-ietf-quic-v2. I got this number with a random number
generator.

Specification: draft-ietf-quic-v2
Change Control: IETF
Contact: QUIC WG

Please follow the procedures in accordance with RFC 7120.

ccing the WG, in case anyone has a problem with a randomly generated
version number.

Martin

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 05 Jan 2022 11:17:29 +1100

Seriously though, I'm happy to support the request.  Though I'm not sure that I believe the claim that the number is random; it seems like a claim that requires proof [1].

I would point out that another allocation would be necessary if we had to change something significant in the draft.  That makes me think that a provisional registration is most appropriate for this.

Changes seem possible given that the draft is currently a little light on detail with respect to some of the compatible version upgrade cases.  Retry handling springs to mind.

FWIW, I've implemented the v2 draft (and the VN draft) with the current codepoint (0xff020000). I've demonstrated successful interop with picoquic in a limited set of cases.  A fresh codepoint allocation seems like a good way to get experience with it in live deployment.

[1] ... :)

---

From: David Schinazi <[email-masked]>
Date: Mon, 10 Jan 2022 15:36:21 -0800

I think it's too early to be using permanent codepoint allocations.
I'd strongly prefer to see a provisional codepoint (i.e. a draft version of
v2)
in production with compatible version negotiation in use (after all that's
the
main reason for the existence of v2) before we move from provisional to
permanent.

Since the specification can change before publication, the IANA registry
needs to
link to a specific version of the draft. I'd suggest submitting
draft-ietf-quic-v2-01
with the random version in it then requesting a provisional allocation from
IANA
with that specific draft number as reference. If we end up publishing
something
that doesn't contain wire-format changes, we can always make the provisional
registration permanent without changing the number upon publication.

David

On Tue, Jan 4, 2022 at 4:18 PM Martin Thomson <[email-masked]> wrote:

> Seriously though, I'm happy to support the request.  Though I'm not sure
> that I believe the claim that the number is random; it seems like a claim
> that requires proof [1].
>
> I would point out that another allocation would be necessary if we had to
> change something significant in the draft.  That makes me think that a
> provisional registration is most appropriate for this.
>
> Changes seem possible given that the draft is currently a little light on
> detail with respect to some of the compatible version upgrade cases.  Retry
> handling springs to mind.
>
> FWIW, I've implemented the v2 draft (and the VN draft) with the current
> codepoint (0xff020000). I've demonstrated successful interop with picoquic
> in a limited set of cases.  A fresh codepoint allocation seems like a good
> way to get experience with it in live deployment.
>
> [1] ... :)
>
On Tue, Jan 4, 2022 at 4:18 PM Martin Thomson <[email-masked]> wrote:

> Seriously though, I'm happy to support the request.  Though I'm not sure
> that I believe the claim that the number is random; it seems like a claim
> that requires proof [1].
>
> I would point out that another allocation would be necessary if we had to
> change something significant in the draft.  That makes me think that a
> provisional registration is most appropriate for this.
>
> Changes seem possible given that the draft is currently a little light on
> detail with respect to some of the compatible version upgrade cases.  Retry
> handling springs to mind.
>
> FWIW, I've implemented the v2 draft (and the VN draft) with the current
> codepoint (0xff020000). I've demonstrated successful interop with picoquic
> in a limited set of cases.  A fresh codepoint allocation seems like a good
> way to get experience with it in live deployment.
>
> [1] ... :)
>