On 1/31/2022 10:32 AM, Lucas Pardue wrote:
Instead, as an individual, I would rather the WG continue to build robust versioning capabilities that allow the community to drive their own evolution. I trust the WG will, if required, make judgement calls on the right time and circumstances to deprecate IETF versions of QUIC. I would not be optimistic that we can drive deployments to change their supported versions just because we said so.
We have a fairly light weight extension capability, which very much "allows the community to drive their own evolution". There is already quite a bit of experience with that: delayed acks, datagrams, multipath were all tested and deployed using the extension mechanism. Given that mechanism, I wonder what the versioning capability brings. I can think of two approaches:
1) Spring clean-up. When the season comes, the WG looks at the various extensions that have been negotiated, and decides which one should be considered "mainline" in the new version. There is some merit to that, but the same result could probably be achieved by standardizing popular extensions.
2) Define new packet formats, incompatible with the initial version. I think that's the real value of versioning.
For example, we may want to define a version of QUIC that's more secure than the current one, more robust against attacks during the handshake -- something like Martin & David's "protected initials" draft. That requires changing format and handling of initial packets, i.e., defining a new version.
-- Christian Huitema
