Add Versions registry #4345
Add Versions registry #4345
Conversation
Closes #4280.
| 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}}). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'm not sure that 0x1 for v1 was such a great idea either, but we did promise.
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Or simply link the wiki.
There was a problem hiding this comment.
Since this document will have a date, it might make more sense to include the list here.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Yeah, that's a fair point.
There was a problem hiding this comment.
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.
draft-ietf-quic-transport.md
Outdated
| 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. |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
Or simply link the wiki.
|
|
||
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
A provisional registration should do for the versions you have. Any reason why it wouldn't?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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?
There was a problem hiding this comment.
@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.
draft-ietf-quic-transport.md
Outdated
| All fields in {{iana-provisional}} MUST be included in all registrations for | ||
| this registry. |
There was a problem hiding this comment.
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?
martinthomson
added
the
design
Co-authored-by: Jana Iyengar <jri.ietf@gmail.com>
(Not sure to what extent this is editorial.)
Closes #4280.