Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Versions registry #4345

Merged
merged 4 commits into from
Dec 10, 2020
Merged

Add Versions registry #4345

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0b461cf
Add Versions registry
martinthomson Nov 10, 2020
edf575d
MUST NOT be assigned, for consistency
martinthomson Nov 10, 2020
1f4fc9c
No point in repeating, especially when it also contradicts
martinthomson Nov 12, 2020
51cb83d
don't list grease
martinthomson Dec 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7334,6 +7334,35 @@ change controller of the IETF and a contact of the QUIC working group
(quic@ietf.org).


## 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

policy ({{!RFC8126}}).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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 reserved and MUST NOT be
assigned by IANA and MUST NOT appear in the listing of assigned values.

\[\[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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or simply link the wiki.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a fair point.



## QUIC Transport Parameter Registry {#iana-transport-parameters}

IANA \[SHALL add/has added] a registry for "QUIC Transport Parameters" under a
Expand Down