Re: Early Allocation

[David Schinazi <[e-mail]>]

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 <[e-mail]> 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 Wed, Jan 5, 2022, at 10:35, Martin Duke wrote:
> > 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
>
>
On Tue, Jan 4, 2022 at 4:18 PM Martin Thomson <[e-mail]> 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 Wed, Jan 5, 2022, at 10:35, Martin Duke wrote:
> > 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
>
>