Subject: Re: [quicwg/base-drafts] No IANA version registry (#4280)

From: Lars Eggert <[email-masked]>
Date: Mon, 09 Nov 2020 06:31:51 -0800

I think the wiki at https://github.com/quicwg/base-drafts/wiki/QUIC-Versions should be the basis for a registry here, given that it reserves some ranges.

-- 
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/4280#issuecomment-724049633

---

From: Mike Bishop <[email-masked]>
Date: Mon, 09 Nov 2020 08:28:04 -0800

Do you believe those registrations should be enshrined in the RFC, or simply submitted to IANA to seed 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/4280#issuecomment-724122173

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Nov 2020 09:28:03 -0800

I support using the transport document for to create an IANA based version registry and its ranges. However, I think the proprietary registrations from the WIKI can just as easy be submitted at time of registry creation as the values are FCFS. 
The IETF draft range maybe should be mentioned in the IANA consideration. However, the range is way larger than any single draft document can use. So it can fit multiple draft names. 

-- 
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/4280#issuecomment-724158547

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Nov 2020 18:03:29 -0800

I'll take this and write up a FCFS policy. As for draft versions, I think that we can limit the range we take to the last 10 we used.  0xff00001d needs protection, and maybe some of those preceding it, but no deployments of 0xff000000 exist.

-- 
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/4280#issuecomment-724401244

---

From: David Schinazi <[email-masked]>
Date: Mon, 09 Nov 2020 18:38:11 -0800

It would be nice for the new registry to include the currently deployed Google QUIC versions if possible. In particular Q043, Q046, Q050 and T051 represent significant global traffic today.

-- 
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/4280#issuecomment-724411868

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Nov 2020 20:36:20 -0800

@DavidSchinazi, do you mind if I ask for an updated list when the time comes?  @afrind, that probably goes for you too.

-- 
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/4280#issuecomment-724444656

---

From: David Schinazi <[email-masked]>
Date: Mon, 09 Nov 2020 21:59:47 -0800

That's a good idea 

-- 
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/4280#issuecomment-724475241

---

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

I would keep the 0xff000000 range as is - we can reuse if we do a v2, and we don't know how many revs we will need

-- 
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/4280#issuecomment-724504776

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Nov 2020 00:00:18 -0800

A question, shouldn't this registry actually be in Invariants? Version field is an invariant and not specific to V1. 

-- 
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/4280#issuecomment-724532073

---

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Nov 2020 00:06:08 -0800

That's what I thought, too. (I actually looked there as well when @StewartBryant flagged this in his review of -transport.)

-- 
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/4280#issuecomment-724534760

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 00:37:26 -0800

It is considerably easier to reference the general registry guidance and definitions in this document rather than find a way to reference or port them.

-- 
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/4280#issuecomment-724550454

---

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Nov 2020 00:46:15 -0800

Fair point. Maybe a paragraph in -invariants explaining that a version registry exists and that it is defined in -transport would be good though?

-- 
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/4280#issuecomment-724555000

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Nov 2020 05:33:25 -0800

@larseggert from my perspective, to define it in -transport and just reference it from Invariants clearly can be made to work. The only issue that might arises in the future is for example when QUIC v1 is declared historic. Then the registry rules become historic despite they being current for any other version. So from a RFC life cycle perspective the version registry aligns with invariants. 

-- 
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/4280#issuecomment-724704023

---

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Nov 2020 05:35:45 -0800

Do registries automatically become historic when the RFCs that define them do? I didn't know that.

-- 
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/4280#issuecomment-724705279

---

From: StewartBryant <[email-masked]>
Date: Tue, 10 Nov 2020 11:21:18 -0800

On 10 Nov 2020, at 13:35, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/4280#issuecomment-724705279>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AONQALXUCUXACDUKFOGTQITSPE6SZANCNFSM4TCLVFRQ>.

As part of deprecating or declaring an RFC historic instructions regarding the registry can be issued.

Note that just because an RFC is historic it does not necessarily mean that no one is still using it and it is safe to recover its code points.

- Stewart

-- 
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/4280#issuecomment-724912968

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Nov 2020 05:37:11 -0800

No, the registries do not become historic. The issue, is that if you would declare QUICv1 obsolete in QUICv2, then you can't reference the RFC for draft-ietf-quic-transport as that is obsolete for the registry rules when you register the QUICv2 identifier. Thus, you need to copy them to v2. And assuming that we might have several in force QUIC versions this can jump around. By placing the registration rules in invariants this issues would be avoided. As that RFC will only be updated due to need to change invariants or these specific rules. 

-- 
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/4280#issuecomment-725427079

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Nov 2020 05:56:58 -0800

I don't think QUIC v2 would necessarily obsolete v1, FWIW.

-- 
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/4280#issuecomment-725437158

---

From: StewartBryant <[email-masked]>
Date: Wed, 11 Nov 2020 06:05:55 -0800

On 11 Nov 2020, at 13:56, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/4280#issuecomment-725437158>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AONQALSLTLJ73Z4WTGINSCTSPKJ2JANCNFSM4TCLVFRQ>.

No, but Magnus’ approach sounds the best one.

However I did raise the issue of whether, like IP, the QUIC versions should be an IANA registry.

Stewart

-- 
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/4280#issuecomment-725441681

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Nov 2020 14:29:00 -0800

@larseggert probably not, but maybe QUICv4 will obsolete v1. I do expect that the obsoleting version specifying documents are more likely than invariant becoming obsoleted. Clearly both approaches can be made to work, there are slightly different trade-offs what may need to happen down the line. 

-- 
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/4280#issuecomment-725696719

---

From: mjoras <[email-masked]>
Date: Thu, 19 Nov 2020 15:41:39 -0800

For Facebook, we have never used a draft version for our traffic. Our strategy is that we use different versions that are essentially aliases to draft versions. So far that has consisted of:

0xfaceb000 (variously draft-9 or draft-17)
0xfaceb001 (draft-24)
0xfaceb002 (draft-27)
0xfaceb00e-f (experimental versions)

Since old clients take a while to upgrade, we support the -1 version for a few months before just disabling it and letting clients fallback to TCP. As for why we do this, it's because we want to retain control over mvfst <-> mvfst interactions without potentially messing up public clients. In the future I think we'd plan on keeping with this strategy and moving forward e.g. to 0xfaceb003 next time we want to iterate the version.

-- 
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/4280#issuecomment-730706035

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 24 Nov 2020 15:19:38 -0800

I think this one is reasonably resolved with #4345. Marking this `proposal-ready`.

-- 
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/4280#issuecomment-733288691