It's both simplest and safest to change both, I'd suggest doing that. David
On Wed, Nov 30, 2022 at 10:30 PM Martin Thomson <m...@lowentropy.net> wrote: > Right, thanks for reviving this. > > My sense is that the best approach here is to make a clean break and get a > new codepoints for BOTH the version negotiation transport parameter and the > v2 version. > > Though deployments can change, they probably won't change atomically > enough to avoid real negotiation failure. > > On Thu, Dec 1, 2022, at 06:25, Martin Duke wrote: > > I don't want to lose this thread, as this is a quite important thing to > > resolve. I personally would prefer to keep the version number constant, > > but it's not all clear to me that it's acceptable to deployed > > implementations. > > > > On Mon, Nov 21, 2022 at 5:06 AM Nick Banks <niba...@microsoft.com> > wrote: > >> MsQuic has released a version with VN+V2 support, but it’s marked as > “preview” so it can change, as necessary. We weren’t planning to make it an > official feature until the RFCs.____ > >> __ __ > >> Thanks,____ > >> - Nick____ > >> Sent from Outlook <http://aka.ms/weboutlook>____ > >> *From:* QUIC <quic-boun...@ietf.org> *On Behalf Of * Martin Duke > >> *Sent:* Thursday, November 17, 2022 8:45 PM > >> *To:* Christian Huitema <huit...@huitema.net> > >> *Cc:* Martin Thomson <m...@lowentropy.net>; quic@ietf.org > >> *Subject:* Re: Transport parameters for version negotiation and v2____ > >> __ __ > >> In Google's code, the v2 code is exists but is not in production > because we haven't done compatible VN yet. So changing the transport > parameter at this point would have no impact on Chrome or Google production > servers.____ > >> __ __ > >> On Thu, Nov 17, 2022 at 4:28 PM Christian Huitema <huit...@huitema.net> > wrote:____ > >>> > >>> > >>> On 11/17/2022 4:15 PM, Martin Thomson wrote: > >>> > How many people have shipped version negotiation and v2 already? > >>> > > >>> > I assume that implementations are using the codepoints for the > transport parameter in the draft (0xFF73DB), but the drafts says this: > >>> > > >>> >> When this document is approved, it will request permanent > allocation of a codepoint in the 0-63 range to replace the provisional > codepoint described above. > >>> > > >>> > IANA are about to make that new allocation, but that might not do > good things for interoperability. > >>> > > >>> > We're not changing the v2 version number and v2 *requires* the use > of this transport parameter: > https://quicwg.org/quic-v2/draft-ietf-quic-v2.html#section-4-2 < > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fquic-v2%2Fdraft-ietf-quic-v2.html%23section-4-2&data=05%7C01%7Cnibanks%40microsoft.com%7C0b21307c92c24ee5f18c08dac906a08b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043327575620512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wz2tzGwBJsw7zyflxjdsihvHeZ%2FvFJhb1S48%2Bc9x%2BAY%3D&reserved=0 > > > >>> > > >>> > Consequently, an implementation that uses the current transport > parameter codepoint will not interoperate successfully with an > implementation that uses any new transport parameter codepoint. > >>> > > >>> > So, we either allocate a new codepoint for both, or we keep the > existing ones. Which do people prefer? > >>> > > >>> > Or, am I wrong about this? > >>> > >>> > >>> The way I read it, QUIC-V2 makes a reference to QUIC-VN, which is > >>> documented in the reference section as pointing to > >>> draft-ietf-quic-version-negotiation-13. But I fully expect that the > next > >>> QUIC-V2 draft will refer to the updated version of QUIC-VN, and thus > to > >>> the final transport parameter. > >>> > >>> -- Christian Huitema > >>> > >>> ____ > >
