Original text:
5.1.1. Each Connection ID has an associated sequence number to assist in <del> 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 </del>  parameter is sent, the sequence number of the supplied connection ID is 1. connection (transport-parameters). An application protocol can also operate in a limited fashion during <del> 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. </del>  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 21.7. <del> 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. </del>  Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow

Reviewer comments:
Some of these uses were a little too vague. The PMTUD one I will add to . The others I don'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. this is also in the abstract and I believe clear enough without further qualification
Thanks for the fix!

Revised text:
5.1.1. Each Connection ID has an associated sequence number to assist in  <ins> 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 </ins> parameter is sent, the sequence number of the supplied connection ID is 1. connection (transport-parameters). An application protocol can also operate in a limited fashion during  <ins> 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. </ins> 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 21.7.  <ins> 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. </ins> Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow