Re: Normative changes to QUICv2

[Martin Thomson <[e-mail]>]

Removing that change sounds right to me.

On Fri, Oct 28, 2022, at 21:31, Martin Duke wrote:
> 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.