Hey, Still speaking as an invidiual:
On Mon, 31 Jan 2022, 20:24 Bill Gage, <[email protected]> wrote: > 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 ... > I appreciate the point but I think it risks putting a large burden on both the process of standards and the endpoints that want to use QUIC. All in the name of trying to convince people not to do the lazy thing. But lazy is as lazy does. If the whole thing could be automated, it wouldn't be so bad. But that is unfeasible and we require too many humans in the loop, which doesn't scale well. Personally I'd rather invest my engineering time in the things that benefit end users more directly. Ossification is a risk to end users but there are other forms mitigations that require less human hours. Cheers Lucas > > > 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 > >
