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