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 <[email protected]>
> 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 <[email protected]> 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.
