Re: Normative changes to QUICv2

[Martin Duke <[e-mail]>]

Hmm, good point, I hadn't considered that angle. I will remove unless
others object.

On Fri, Oct 28, 2022 at 1:28 PM David Schinazi <[e-mail]>
wrote:

> Hi Martin, overall the changes look fine - except the last one that I
> disagree with:
>
> you added <<Some clients keep track of paths that do not support QUIC by
> recording failures to connect over those paths.  Such clients SHOULD count
> version 2 and version 1 failures separately, as a path might block version
> 2 but allow version 1.>>
>
> This assumes that ossification of the version number is already there and
> that clients SHOULD accept it. I disagree that this is the best strategy. A
> perfectly reasonable strategy is to consider networks that block QUICv2 as
> networks that block QUIC so they realize that they are reducing
> user-visible performance. Fighting ossification is the entire point of this
> document, so it shouldn't say that ossification is OK.
>
> I would remove this new text entirely.
>
> David
>
> On Fri, Oct 28, 2022 at 10:10 AM Martin Duke <[e-mail]>
> wrote:
>
>> Hello QUIC Enthusiasts,
>>
>> IESG review resulted in a few (relatively minor) changes. However, a few
>> of these affect normative requirements so it's appropriate to gather
>> group input. If you have a problem with any of them, *please say so very
>> soon*. If you are fine with all of them, that is also helpful to say.
>>
>> None of these requested changes were attached to a DISCUSS, so there's
>> plenty of scope to push back on anything someone finds problematic
>>
>> Full diff here
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-quic-v2&url2=https://quicwg.github.io/quic-v2/draft-ietf-quic-v2.txt
>>
>> Normative changes.
>>
>> (1)
>> OLD
>> HTTP servers that support multiple versions reduce the probability of
>>    incompatibility and the cost associated with QUIC version negotiation
>>    or TCP fallback.  For example, an origin advertising support for "h3"
>>    in Alt-Svc SHOULD support QUIC version 1 as it was the original QUIC
>>    version used by HTTP/3 and therefore some clients will only support
>>    that version.
>>
>> NEW
>> HTTP servers SHOULD support multiple versions to reduce the probability
>> of incompatibility and the cost associated with QUIC version negotiation or
>> TCP fallback. For example, an origin advertising support for "h3" in
>> Alt-Svc should support QUIC version 1 as it was the original QUIC version
>> used by HTTP/3, and therefore some clients will only support that version.
>>
>> Rationale: move the normative word out of the example.
>>
>> (2)
>> OLD
>> Clients SHOULD NOT use
>>    a session ticket or token from a QUIC version 1 connection to
>>    initiate a QUIC version 2 connection, or vice versa.
>>
>> NEW: SHOULD NOT->MUST NOT.
>>
>> Rationale: Since servers MUST validate, allowing clients to violate the
>> requirement is just setting them up for failure
>>
>> (3)
>> NEW
>> Some clients keep track of paths that do not support QUIC by
>>     recording failures to connect over those paths.  Such clients SHOULD
>>     count version 2 and version 1 failures separately, as a path might
>>     block version 2 but allow version 1.
>>
>> Rationale: Clients really shouldn't interpret QUICv2 connection failure
>> as general QUIC failure.
>>
>