I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is Ready.

As the document itself clearly states in the security considerations section, this revision introduces no changes to the security or privacy properties of QUIC.

I have only three additional questions/comments:

- What are the implications of the server not encoding the version in its Retry message and subsequently checking that the client didn't change versions upon retrying?

- Is there any optimization possible if the server keeps the Initial receive keys slightly longer than the first instance of processing a packet using keys generated for the negotiated version? I'm guessing not, but I just wanted to confirm.

- In "Endpoints have no need to generate the keying material that would allow them to decrypt or authenticate these packets", I would s/these/such/.