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
