Re: Normative changes to QUICv2

[David Schinazi <[e-mail]>]

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.
>