I was going to make a similar comment, but chased it down to my satisfaction. QUIC extensions aren't necessarily compatible between versions, since version number implies everything beyond what's in RFC 8999. This is explicitly an extension to QUICv1, and we can't make a statement about unknown future versions of QUIC because they might be totally different. It's up to those specs to state how they interact with extensions to existing QUIC versions, if at all.
However, RFC 9369 explicitly does that: "Unless otherwise stated, all QUIC extensions defined to work with version 1 also work with version 2." It wouldn't be a problem to make a reference and point that out, but it's correct either way. ________________________________ From: Mirja Kuehlewind <[email protected]> Sent: Thursday, February 5, 2026 6:37 AM To: Erik Kline <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Erik Kline's Ballot for draft-ietf-quic-multipath Hi Erik, your ballot wasn't sent out but I saw your comments in the datatracker. Some quick replies here: > * In addition to working with QUIC v1, I assume it will work with other > v1-compatible version, e.g. "v2"/RFC 9369? Yes. This is actually a good point. I think in other extension documents we actually just say that it's an extension to QUIC, rather than naming a specific version. Maybe we should do this here as well? QUIC chairs any general thoughts on this? > * "There are currently no IETF specifications ..." > Is this really true? Does RFC 6356 count as one such specification? RFC 6356 only specifies congestion control but also no scheduling. Thanks for your review! Mirja
