Draft: draft-ietf-quic-transport

Commentary: Some of these uses were a little too vague . The PMTUD one I will add to . The others I do n't plan to fix . 
 I reviewed , and it is not always clear what a " message " is supposed to mean . It needs clarification in the text to disambiguate between different meanings , and could also benefit from definitions . Here is a review of the different meanings of " message " I found in the draft : TLS message ( referred to as cryptographic message or cryptographic handshake message ) ICMP message application message , which seems to refer to messages sent by applications with their own internal framing ( not visible to QUIC , since each stream provides a simple bytestream with no framing ) QUIC " message " , which seems to roughly mean " any QUIC control frame " but this is not defined . In any case , there is no " QUIC message " as such in the base protocol . The first three meanings are understandable , but the last one should be clarified or removed altogether . Additionally , any usage of " message " not clearly falling into one of these four categories should be clarified . Here is a breakdown of usages that need clarification : [ 2 . ] An alternative view of QUIC unidirectional streams is a " message " abstraction of practically unlimited length . -this is not exactly the same as an application message . That being said , the quotes make it clear that it is used in an approximate sense . [ 5.1.1 . ] Each Connection ID has an associated sequence number to assist in deduplicating messages -this seems to refer to and frames specifically [ 5.3 . ] 0 - RTT allows application messages to be sent by a client before receiving any messages from the server -the second occurrence is unclear : does it refer to application messages sent by the server application ? Or does it also include TLS messages or other " QUIC messages " ? [ 10.3 . ] The application protocol exchanges whatever messages that are needed to cause both endpoints to agree to close the connection -this is quite clear from the context , but it would be more consistent to use " application messages " [ 14.1 . ] An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery ( ... ) to determine whether the path to a destination will support a desired message size without fragmentation -this should probably be replaced with " QUIC maximum packet size " as defined just above in the text . [ 21.7 . ] QUIC and TLS both contain messages that have legitimate uses in some contexts , but that can be abused ( .. ) -this section contains several other occurrences of " message " . This is well - defined for TLS , but there is no such thing as a " QUIC message " currently . 
 I did not fix the ones in the following : 2 - this is clearly intended in the abstract , as you say . 3 - this is also in the abstract and I believe clear enough without further qualification 
 Thanks for the fix !
Paragraph (version A):
Each Connection ID has an associated sequence number to assist in
deduplicating messages.  The initial connection ID issued by an
endpoint is sent in the Source Connection ID field of the long packet
header (long-header) during the handshake.  The sequence number of
the initial connection ID is 0.  If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1.
Paragraph (version B):
Each Connection ID has an associated sequence number to assist in
detecting when NEW_CONNECTION_ID or RETIRE_CONNECTION_ID frames refer
to the same value.  The initial connection ID issued by an endpoint
is sent in the Source Connection ID field of the long packet header
(long-header) during the handshake.  The sequence number of the
initial connection ID is 0.  If the preferred_address transport
parameter is sent, the sequence number of the supplied connection ID
is 1.
Paragraph (version A):
An application protocol can also operate in a limited fashion during
the handshake phase.  0-RTT allows application messages to be sent by
a client before receiving any messages from the server.  However,
0-RTT lacks certain key security guarantees.  In particular, there is
no protection against replay attacks in 0-RTT; see QUIC-TLS.
Separately, a server can also send application data to a client
before it receives the final cryptographic handshake messages that
allow it to confirm the identity and liveness of the client.  These
capabilities allow an application protocol to offer the option to
trade some security guarantees for reduced latency.
Paragraph (version B):
An application protocol can also operate in a limited fashion during
the handshake phase.  0-RTT allows application data to be sent by a
client before receiving any response from the server.  However, 0-RTT
lacks certain key security guarantees.  In particular, there is no
protection against replay attacks in 0-RTT; see QUIC-TLS.
Separately, a server can also send application data to a client
before it receives the final cryptographic handshake messages that
allow it to confirm the identity and liveness of the client.  These
capabilities allow an application protocol to offer the option to
trade some security guarantees for reduced latency.
Paragraph (version A):
QUIC and TLS both contain messages that have legitimate uses in some
contexts, but that can be abused to cause a peer to expend processing
resources without having any observable impact on the state of the
connection.
Paragraph (version B):
QUIC and TLS both contain frames or messages that have legitimate
uses in some contexts, but that can be abused to cause a peer to
expend processing resources without having any observable impact on
the state of the connection.