Hello Lucas and Spencer -
Just to clarify, when I said "there could be a new rolling release of the QUIC
spec at least once a year on March 21 that, as a minimum, greases the
codepoints and salts", I didn't mean to imply a change to the existing WG mode
of operation - RFCs would continue to be issued as soon as the WG completes its
various work items.
What I meant was, to ensure an ossification-resistant protocol, there could be
a new QUIC RFC issued periodically that greases the codepoints and salts *if
there had been no other relevant updates* to the base QUIC spec in the
intervening period.
The new RFC would use a release label similar to "v01-2022r01" that would be an
indicator of the base version of the protocol ("v01", currently RFC 9000) and
the greased codepoints/salts ("2022r01"). If the version identifier isn't
changed, then it is an indication that the RFC refers only to greased
codepoints/salts, Hopefully this would avoid the confusion of using a linear
sequence of version identifiers for updates that only refer to greased
codepoints/salts.
Clearly, the actual on-wire version number would always be changed.
Cheers ...
> From: Spencer Dawkins at IETF
> Sent: Monday, January 31, 2022 2:41 PM
>
> On Mon, Jan 31, 2022 at 12:32 PM Lucas Pardue <[email protected]>
> wrote:
>> Hey,
>>
>> Responding to the theme of this thread, as an individual.
>>
>> I think it's a laudable goal to have scheduled releases and up-front support
>> cycles.
>> However, I fear what that requires is switching the group from a QUIC
>> standards
>> development and maintenance transport WG into a software and hardware
>> delivery
>> and operations group. Yes, if there are problems found in QUIC protocol
>> versions
>> or extensions, we should seek to fix them. However, I think it is a major
>> challenge to attempt coordination across the diverse set of implementations
>> and
>> platforms where QUIC already runs. It also seems the antithesis of our goal
>> in
>> building an ossification-resistant protocol that encourages evolution and
>> experimentation.
>>
>> 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.
>
> I'm sympathetic to this point of view (and this is one of the reasons I was
> thinking
> that this might not be possible in an all-volunteer organization in my
> previous
> comment), but I thought it was useful to ask, because if anything like an
> expiration date was possible to establish, I'm sure that talking about that
> sooner rather than later would make establishing an expiration date much
> easier.
>
> I didn't say this out loud, but I think my suggestion makes much more sense
> if
> something like Bill's suggestion about telling people to expect a new release
> each year, on some date, even if it's just bumping the version number and
> salts,
> was also happening. If the notice of a new QUIC version number included
> something like "you can expect to use this protocol version for the next
> three
> years without worrying about obsolescence", or whatever the right thing to
> say
> is.
>
> Do The Right Thing, of course!
>
> Best,
>
> Spencer
