Change:
URL's just a Version field. This is a subtle one, but it follows from the work that others have been doing on greasing versions or providing additions to echconfig for QUIC connection establishment. It basically says that Version is for endpoints, not middleboxes.
I like the idea here, but it seems like the distinction in the text is too subtle. Why not remove this entirely?
By "this", do you mean striking ?
I was actually suggesting removing it from invariants entirely.
I would quibble a bit about whether or not version aliasing really violates the existing text, but I still think this change is a good one. For example, if we fail to prevent ossification then we're going to end up with this being the "fake" version while the real version is buried in the TPs.
The invariants spec currently defines Version thusly: This implies that packets in which this field is present are packets for connections that use the associated version. An overzealous, but not unreasonable interpretation of this might lead to a middlebox looking at Version=N and assuming that the packet conforms to QUIC version N. Actions taken on that basis might be detrimental, especially if we consider options like those proposed in draft-duke-quic-version-aliasing or draft-kazuho-quic-authenticated-handshake. In other words, this commits us to something we already know we might not want to commit to. It would be better to simply state the format of the field and that it is used by endpoints to identify the version. I have done this in .
There seems to be support for this issue and , and the change is editorial.
As an individual, I wonder if it would be worthwhile to add text to the draft that explicitly calls out that it is not safe for anybody other than the endpoints to assume knowledge about what protocol version an observed version number refers to. I think this it the implicit goal, making it explicit is IMO more direct. (This could also be something for the ops-drafts to talk about though.)
NAME relabelled the PR as design a few days ago, so it this potentially a design issue?
Looking at the diff, I don't really see a need for labelling it design. NAME why the design label?
It's a subtle change, but it is a change in the design of the invariants. It's saying that a packet marked version 0x13 isn't necessarily carrying a packet encoded in version 0x13, even if an observer speaks that version. Merely that the bytes 0x00000013 are somehow useful to the recipient in identifying the version. Previously, we made the assertion that the version field indicated what version was used in the packet.
Let's run this through the design issue process to be sure.
So it seems we have a resolution in . Labelling as such.

Discussion:
first byte being set; packets with a short header have that bit cleared. <ins> QUIC packets might be integrity protected, including the header. However, QUIC Version Negotiation packets are not integrity protected; see vn. </ins> Aside from the values described here, the payload of QUIC packets is version-specific and of arbitrary length.

5.4. <del> QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation (see version-negotiation).  All other version numbers are potentially valid. </del> <ins> The Version field contains a 4-byte identifier.  This value can be used by endpoints to identify a QUIC Version.  A Version field with a value of 0x00000000 is reserved for version negotiation; see vn.  All other values are potentially valid. </ins> The properties described in this document apply to all versions of QUIC.  A protocol that does not conform to the properties described