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.
