Change:
lists the QUIC version selected by the client. How to perform version negotiation is left as future work defined by <del> future versions of QUIC.  In particular, that future work will ensure robustness against version downgrade attacks; see version-downgrade. </del> <ins> future standards-track specifications.  In particular, that future work will ensure robustness against version downgrade attacks; see version-downgrade. </ins> 6.2.1.

Discussion:
Remove a sentence (apparently) about handling version negotiation packets from the section that's supposed to be about sending them. Clarify that the handling of version negotiation packets is meant to be specified only by standards-track documents (since it is in some sense a cross-version invariant rather than version-specific behavior). In particular, those documents will not necessarily be specifications for a future version of QUIC. New versions of QUIC specified prior to the existence of a version negotiation mechanism are to respond to Version Negotiation packets in the same manner as v1.
Pushed fixups for both points raised.
NAME said:
Responded via email.
My mistake; I haven't responded to this DISCUSS yet. I will do so shortly.
Martin did so (shortly): see URL
NAME said:
This is a common question, but I'm still reluctant to say anything. The best reference I can offer is either or . The former currently doesn't really do anything to address this problem, and I've only a promise to look into this, not even a real commitment to do something. My personal draft is maybe better as the latest version directly addresses the problem, but that had only a lukewarm reception when I presented it and I don't like downrefs to drafts, especially those that aren't working group items.
I guess might have some bearing here as well.
It might be done by including information from VN packets in transport parameters of the eventually-selected version, so the endpoints can validate that they selected the proper version after the fact. That's the most obvious approach. One could also imagine dedicated frame types, something not specific to QUIC, etc.
I had something along the lines of Mike's thought in mind; "There are multiple mechanisms available by which such authentication could occur, including using transport parameters and the TLS transcript hash to provide mutual agreement on the contents of the version negotiation packet, but no such mechanism is currently defined."
I'm still reluctant to say that.
I'm labelling this as editorial, since the request was to "add some indication", which doesn't sound like normative text. If someone would like to argue for adding such text, please prepare a PR.
I propose close with no action. I'm fine without the MUST even, but I can see the argument that it is useful in requiring authentication.

I don't see the point in talking about what an endpoint might do; we have to define that in a future spec. Similar to , is it worth stating that future standards-track spec will describe how to do this authentication?
Okay. While I'm not opposed to mentioning it, I did look at this text and choose not to propose a change for it as part of .
One suggestion, but this is good. Excision performed in the service of brevity. We have no information, but that indicates more that we have time to work on a solution. I am confident that we have enough of an escape valve that we will be able to define new versions securely. As is the working group (who I am certain will speak up if they disagree). If only we hadn't already discussed this at length. I think that we know the answer in the general sense, just not in the specific sense of being able to define the bits and manage operational concerns and other protocol design constraints. The working group reached that confidence. I don't know how much effort I'm able to devote now to helping you reach that state. Perhaps other participants would like to offer their help now.