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