Change:
These are all small, but neat improvements inspired by the feedback in .
Here are some minor editorial issues: Section 2.1: "TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged." I think "observed" as used here is the wrong word. Because the encrypted form of the clear-text message will be possible to observe. Please reformulate to give actual security properties. Section 2.1: "A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so it MUST NOT carry a self-contained trigger for any non-idempotent action." Please do not use RFC2119 words "MUST NOT" in overview. I understand the need for emphasis on this. However, I assume this is actually specified normatively elsewhere. So simply using other words to provide the emphasis and possibly a reference to the section defining this normatively. Section 5.2: "Note: The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero-length Source Connection ID field." To my understanding the DCID is not arbitrary length, it is of any octet length between 0 and 160 bits. Does the Initial processing function need to deal with non QUIC version-1 long header packets?
Based on , labeling this as "editorial"
I think the PR resolves my issues nicely.
I liked that we dropped the MUST NOT, it's already somewhere else. I also like that we point back to quic-trans for the dcid URL

Discussion:
2.1. TLS provides two endpoints with a way to establish a means of <del> communication over an untrusted medium (that is, the Internet) that ensures that messages they exchange cannot be observed, modified, or forged. </del> <ins> communication over an untrusted medium (that is, the Internet).  TLS enables authentication of peers and provides confidentiality and integrity protection for messages that endpoints exchange. </ins> Internally, TLS is a layered protocol, with the structure shown in tls-layers.

A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately.  This Application Data can be replayed by an attacker <del> so it MUST NOT carry a self-contained trigger for any non- idempotent action. </del> <ins> so 0-RTT is not suitable for carrying instructions that might initiate any non-idempotent action. </ins> A simplified TLS handshake with 0-RTT application data is shown in tls-full.

Destination Connection ID it uses in response to an Initial packet from the server. <del> The Destination Connection ID is of arbitrary length, and it could be zero length if the server sends a Retry packet with a zero- length Source Connection ID field.  In this case, the Initial keys provide no assurance to the client that the server received its packet; the client has to rely on the exchange that included the Retry packet for that property. </del> <ins> The Destination Connection ID field could be any length up to 20 bytes, including zero length if the server sends a Retry packet with a zero-length Source Connection ID field.  After a Retry, the Initial keys provide the client no assurance that the server received its packet, so the client has to rely on the exchange that included the Retry packet to validate the server address; see Section 8.1 of QUIC-TRANSPORT. </ins> test-vectors contains sample Initial packets.