Subject: [quicwg/base-drafts] Add Versions registry (#4345)

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

(Not sure to what extent this is editorial.)

Closes #4280.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4345

-- Commit Summary --

  * Add Versions registry

-- File Changes --

    M draft-ietf-quic-transport.md (30)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4345.patch
https://github.com/quicwg/base-drafts/pull/4345.diff

-- 
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/pull/4345

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 09 Nov 2020 23:52:15 -0800

@gloinul commented on this pull request.

> @@ -7334,6 +7334,36 @@ change controller of the IETF and a contact of the QUIC working group
 ([email-masked]).

+## QUIC Versions Registry {#iana-version}
+
+IANA \[SHALL add/has added] a registry for "QUIC Versions" under a "QUIC"
+heading.
+
+The "QUIC Versions" registry governs a 32-bit space; see {{versions}}. This
+registry follows the registration policy from {{iana-policy}}. Permanent
+registrations in this registry are assigned using the Specification Required
+policy ({{!RFC8126}}).

So wasn't this supposed to have two ranges: Wiki page says "The (WIP) QUIC specification reserves 0x00000001 to 0x0000ffff for standardized versions of the protocol." I think this is a minimal Specification Required policy. Then you have the FCFS range 0x0001000 to 0xFFFFFFFF. 

> +IANA \[SHALL add/has added] a registry for "QUIC Versions" under a "QUIC"
+heading.
+
+The "QUIC Versions" registry governs a 32-bit space; see {{versions}}. This
+registry follows the registration policy from {{iana-policy}}. Permanent
+registrations in this registry are assigned using the Specification Required
+policy ({{!RFC8126}}).
+
+All fields in {{iana-provisional}} MUST be included in all registrations for
+this registry.
+
+The codepoint of 0x00000001 to the protocol is assigned with permanent status
+to the protocol defined in this document. The codepoint of 0x00000000 is
+permanently reserved; the note for this codepoint \[shall] indicate\[s] that
+this version is reserved for Version Negotiation. All codepoints that follow
+the pattern 0x?a?a?a?a are permanently reserved.

I think one should be explicit about the 

0xff[000000-ffffff] | IETF | draft-ietf-quic-transport-xx
-- | -- | --
in the FCFS as being reserved for IETF draft versions. I think in the registry one could include the more specific information which draft-ietf-quic-transport actually used. 

-- 
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/pull/4345#pullrequestreview-526932529

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Nov 2020 23:56:38 -0800

@martinthomson commented on this pull request.

 ([email-masked]).

Based on the way things are for other registries, I figured that it was easier to have the whole space left as specification required.  There is no functional difference other than the involvement of an expert and it simplifies things.  I would rather have someone camp on version 2 than have different rules for parts of an otherwise undifferentiated space.

-- 
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/pull/4345#discussion_r520356746

---

From: Martin Thomson <[email-masked]>
Date: Mon, 09 Nov 2020 23:57:27 -0800

+heading.
+

As above, I don't see any value in propagating that policy.  We don't need the space and can squat on a random piece of the space in future.

-- 
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/pull/4345#discussion_r520357157

---

From: mirjak <[email-masked]>
Date: Tue, 10 Nov 2020 02:42:07 -0800

@mirjak commented on this pull request.

+The codepoint of 0x00000001 to the protocol is assigned with permanent status
+to the protocol defined in this document. The codepoint of 0x00000000 is
+permanently reserved; the note for this codepoint \[shall] indicate\[s] that
+this version is reserved for Version Negotiation. All codepoints that follow
+the pattern 0x?a?a?a?a are permanently reserved.
+
+\[\[RFC editor: please remove the following note before publication.]]
+
+IANA note:
+
+: Several pre-standardization versions will likely be in use at the time of
+  publication. There is no need to document these in an RFC, but recording
+  information about these version will ensure that the information in the
+  registry is accurate.  The document editors or working group chairs can
+  facilitate getting the necessary information.

Given this note will be removed, you could easy note these versions here. This would be others (than the editor) the chance to review and make sure all version that are currently deployed are covered.

-- 
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/pull/4345#pullrequestreview-527072334

---

From: mirjak <[email-masked]>
Date: Tue, 10 Nov 2020 02:43:51 -0800

([email-masked]).

I actually don't see a reason for not separating the space. The are enough codepoints and given we already decided which part of the space we want to use for new versions that are specified in the IETF we should indicate this in the registry, so people know that when they choose a value for testing internal versions.

-- 
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/pull/4345#discussion_r520463574

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 02:54:06 -0800

([email-masked]).

I'm looking for a reason to segregate it.  Protecting IETF rights to little numbers seems like a pretty weak reason when we can use the same rules as everyone else.

-- 
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/pull/4345#discussion_r520470096

---

From: mirjak <[email-masked]>
Date: Tue, 10 Nov 2020 03:13:02 -0800

([email-masked]).

It's not about protecting, it about letting others know what our plans are. Given there is no shortage on numbers, I only see that as a benefit.

-- 
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/pull/4345#discussion_r520482094

---

From: Mike Bishop <[email-masked]>
Date: Tue, 10 Nov 2020 05:56:29 -0800

@MikeBishop approved this pull request.

I feel like there's a little bit of value in having a separate IETF Consensus or Standard Required space, simply to highlight when a spec has that level of broad adoption.  However, like you, I feel like that's fairly mild, so I'm also okay if we don't do that.

+heading.
+

Should this use the formulation from the other greasing sections, that IANA SHALL NOT assign them, rather than actually having them reserved in the list?  I don't want to see 16K registrations for "Reserved" on IANA's list, after all.

Or simply link the wiki.

-- 
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/pull/4345#pullrequestreview-527221988

---

From: David Schinazi <[email-masked]>
Date: Tue, 10 Nov 2020 11:36:05 -0800

@DavidSchinazi commented on this pull request.

 ([email-masked]).

I don't think we should use Specification Required here. Google uses some of these codepoints in production, and we don't have `a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible`. Expert Review would be a better fit.

-- 
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/pull/4345#pullrequestreview-527543542

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 14:40:18 -0800

([email-masked]).

A provisional registration should do for the versions you have.  Any reason why it wouldn't?

-- 
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/pull/4345#discussion_r520919865

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 14:44:12 -0800

@martinthomson pushed 1 commit.

edf575dc774786aa34c36e190404e991cde62a74  MUST NOT be assigned, for consistency

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4345/files/0b461cf2bdf207c27234562a66cddc99f259aa35..edf575dc774786aa34c36e190404e991cde62a74

---

From: David Schinazi <[email-masked]>
Date: Tue, 10 Nov 2020 14:44:45 -0800

([email-masked]).

Given that these code points were deployed for huge amounts of traffic, and there will still be old devices speaking them out there for years, provisional sounds odd to me - no one will be able to reclaim these safely. But if in this context we use "provisional" to mean "doesn't have a public spec" (as opposed to the original meaning of the word) then it works?

-- 
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/pull/4345#discussion_r520921768

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 15:11:55 -0800

@janaiyengar commented on this pull request.

 ([email-masked]).

I think of provisional as something that's not permanent. In this case, while this will take a while to go away, it is getting "drained" off the Internet. In that sense, I would call this provisional.

-- 
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/pull/4345#discussion_r520933115

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 15:23:26 -0800

([email-masked]).

Are we agreed on our future plans though? I am interested in using a completely arbitrary number for version 2.

I agree with keeping this flat; we don't need to make our plans known. I would argue instead that, in the interest of greasing, we _shouldn't_ use 0x2 for v2.

-- 
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/pull/4345#discussion_r520937571

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2020 16:02:54 -0800

([email-masked]).

I'm not sure that 0x1 for v1 was such a great idea either, but we *did* promise.

-- 
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/pull/4345#discussion_r520951815

---

From: David Schinazi <[email-masked]>
Date: Tue, 10 Nov 2020 16:17:11 -0800

([email-masked]).

@janaiyengar that's also true of draft-29, and will be true of QUICv1 once we ship QUICv2. Why does the presence of a specification impact provisional vs permanent?

-- 
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/pull/4345#discussion_r520956573

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 22:11:05 -0800

+this registry.

I'm not sure how to square away this MUST with the MAY exception in {{iana-provisional}}: "Provisional registrations MAY omit the Specification and Notes fields, plus any additional fields that might be required for a permanent registration." Presumably the MAY is still allowed ... why is this MUST necessary here?

-- 
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/pull/4345#pullrequestreview-527886465

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 22:11:19 -0800

([email-masked]).

@DavidSchinazi : It's not the presence of a spec, but that a provisional registration allows for the _absence_ of a spec. See https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-22.

-- 
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/pull/4345#discussion_r521133542

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 10 Nov 2020 22:12:49 -0800

Since this document will have a date, it might make more sense to include the list here.

-- 
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/pull/4345#discussion_r521134040

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Nov 2020 00:12:51 -0800

I would prefer to leave the dynamic information to the registry.  Documenting the mess of proprietary versions we currently know about isn't really something that is worth creating a permanent record of.

-- 
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/pull/4345#discussion_r521185168

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Nov 2020 16:29:18 -0800

+this registry.
+

```suggestion
```

-- 
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/pull/4345#pullrequestreview-528650876

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Nov 2020 19:32:27 -0800

Yeah, that's a fair point.

-- 
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/pull/4345#discussion_r521802504

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Nov 2020 19:36:20 -0800

1f4fc9c2f3eef3edc4807c58a372baa80045d175  No point in repeating, especially when it also contradicts

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4345/files/edf575dc774786aa34c36e190404e991cde62a74..1f4fc9c2f3eef3edc4807c58a372baa80045d175