Original text:
server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, <del> clients SHOULD send a packet upon a handshake timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del>  A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all <del> Initial packets it sends after it receives the Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </del>  As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is future connections.  The client includes this token in Initial packets to provide address validation in a future connection.  The client MUST include the token in all Initial packets it sends, unless <del> a Retry replaces the token with a newer token.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </del>  Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed to be easily distinguishable from tokens that are sent in Retry packets as they are carried in the same field. </del>  If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is <del> discarded.  A server MAY encode tokens provided with NEW_TOKEN </del>  frames and Retry packets differently, and validate the latter more strictly.

Reviewer comments:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.

Revised text:
server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock,  <ins> clients SHOULD send a packet upon a crypto retransmission timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all  <ins> Initial packets it sends for that connection after it receives the Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </ins> As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is future connections.  The client includes this token in Initial packets to provide address validation in a future connection.  The client MUST include the token in all Initial packets it sends, unless  <ins> a Retry or NEW_TOKEN frame replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is different connections; validating the port is therefore unlikely to be successful.  <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </ins> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD token in a previous connection using the NEW_TOKEN frame, and if the server has lost state, it might be unable to validate the token at all, leading to connection failure if the packet is  <ins> discarded.  A server SHOULD encode tokens provided with NEW_TOKEN </ins> frames and Retry packets differently, and validate the latter more strictly.