Original text:
A QUIC server starts the process by providing TLS with the client's handshake bytes. <del> At any given time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level.  Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames.  When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. </del>  QUIC takes the unprotected content of TLS handshake records as the content of CRYPTO frames.  TLS record protection is not used by QUIC. QUIC assembles CRYPTO frames into QUIC packets, which are protected using QUIC packet protection.  When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets. <del> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. </del> 4.6. A server accepts 0-RTT by sending an early_data extension in the

Reviewer comments:
This is a point NAME makes in , but it probably pays to make it more clearly. This was possible in earlier iterations of the draft, so it's worth stamping out residual mentions.
Section 4.5 of quic-tls: Early data within the TLS connection MUST NOT be used. As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. As there is no way to express TLS application data (no record headers!) I believe there is no way for the proposed error condition to occur. I propose we strike the paragraph, though we might mention that this condition is impossible for clarity.

Revised text:
A QUIC server starts the process by providing TLS with the client's handshake bytes.  <ins> At any time, the TLS stack at an endpoint will have a current sending encryption level and receiving encryption level.  Each encryption level is associated with a different flow of bytes, which is reliably transmitted to the peer in CRYPTO frames.  When TLS provides handshake bytes to be sent, they are appended to the current flow and any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. </ins> QUIC takes the unprotected content of TLS handshake records as the content of CRYPTO frames.  TLS record protection is not used by QUIC. QUIC assembles CRYPTO frames into QUIC packets, which are protected using QUIC packet protection. <ins> QUIC is only capable of conveying TLS handshake records in CRYPTO frames.  TLS alerts are turned into QUIC CONNECTION_CLOSE error codes; see tls-errors.  TLS application data and other message types cannot be carried by QUIC at any encryption level and is an error if they are received from the TLS stack. </ins> When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets.  4.6. A server accepts 0-RTT by sending an early_data extension in the