Re: draft-30 non-implementable, please

[David Schinazi <[e-mail]>]

If there are no interop-breaking changes, then I would much prefer draft-30
to have text stating that 0xff00001e and h3-20 MUST NOT be sent on the wire.
Deploying a new version would take on the order of two months for us, and
also has a non-negligible impact on the environment due to the large amount
of tests we run on all supported versions.

On Tue, Aug 11, 2020 at 11:54 AM Martin Duke <[e-mail]>
wrote:

> Christian,
>
> I think the issue is that for many of us a one-line change can take weeks
> or months to propagate to the field, so there will be more version
> mismatches in the meantime.
>
> I suppose if all h3-30s also support h3-29, there's no issue, but that's a
> weird thing to mandate.
>
> On Tue, Aug 11, 2020 at 11:25 AM Christian Huitema <[e-mail]>
> wrote:
>
>> If that's true, then supporting draft-30 in picoquic in addition to draft
>> 29 is just a one-line change. Good way to test version aliasing.
>> On 8/11/2020 11:13 AM, Ian Swett wrote:
>>
>> I'm not aware of anything that I expect to cause interop problems, but
>> the other editors may have something in mind.  In particular, there are no
>> wire format changes or new mechanisms that if you don't implement, the
>> connection fails.
>>
>> I was thinking we would roll the changes into the existing -29, rather
>> than shipping -30 as an ALPN and Alt-Svc.
>>
>> On Tue, Aug 11, 2020 at 2:04 PM Martin Duke <[e-mail]>
>> wrote:
>>
>>> I am happy to defer to the editors as to whether their change requires
>>> interoperability changes or not. My quick scan of the diff doesn't
>>> immediately reveal anything that would actually cause an issue, but I might
>>> be wrong.
>>>
>>> On Tue, Aug 11, 2020 at 10:55 AM Lucas Pardue <
>>> [e-mail]> wrote:
>>>
>>>> whoops [1]
>>>>
>>>> [1] -
>>>> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-quic-transport&url2=https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.txt
>>>>
>>>> On Tue, Aug 11, 2020 at 6:54 PM Lucas Pardue <
>>>> [e-mail] <[e-mail]>> wrote:
>>>>
>>>>>
>>>>> On Tue, Aug 11, 2020 at 6:46 PM Ryan Hamilton <[e-mail]>
>>>>> <[e-mail]> wrote:
>>>>>
>>>>>> Completely agree. If -30 is compatible with -29 let's keep the same
>>>>>> "on the wire" versioning so that we can maximize the probability of
>>>>>> successful communication!
>>>>>>
>>>>>
>>>>> Speaking as an individual, the struggle I have is that 29 to 30 is not
>>>>> a no-op. You can look at the current diff for transport [1] and see that
>>>>> we're sarig down the barrel of 10 design issues with proposals. So as an
>>>>> endpoint that implements 30-not-30, if I speak to an endpoint that is
>>>>> barely-29 and I have issues, what is my recourse? I really don't want to
>>>>> get into UA sniffing to build in branching code...
>>>>>
>>>>> Lucas
>>>>>
>>>>>
>>>>>