Draft: draft-ietf-quic-transport

Commentary: 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 can not have the same PN twice , but that does not apply to Retry .
Paragraph (version A):
Packet loss, in particular loss of a Handshake packet from the
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,
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.
Paragraph (version B):
Packet loss, in particular loss of a Handshake packet from the
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,
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.
Paragraph (version A):
The server uses the NEW_TOKEN frame frame-new-token to provide the
client with an address validation token that can be used to validate
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
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.
Paragraph (version B):
The server uses the NEW_TOKEN frame frame-new-token to provide the
client with an address validation token that can be used to validate
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
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
The rationale for treating the client as unvalidated rather than
discarding the packet is that the client might have received the
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
discarded.  A server MAY encode tokens provided with NEW_TOKEN
frames and Retry packets differently, and validate the latter more
strictly.
Paragraph (version B):
The rationale for treating the client as unvalidated rather than
discarding the packet is that the client might have received the
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
discarded.  A server SHOULD encode tokens provided with NEW_TOKEN
frames and Retry packets differently, and validate the latter more
strictly.