Change:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.

Discussion:
4.6. <ins> The 0-RTT feature in QUIC allows a client to send application data before the handshake is complete.  This is made possible by reusing negotiated parameters from a previous connection.  To enable this, 0-RTT depends on the client remembering critical parameters and providing the server with a TLS session ticket that allows the server to recover the same information. This information includes parameters that determine TLS state, as governed by TLS13, QUIC transport parameters, the chosen application protocol, and any information the application protocol might need; see app-0rtt.  This information determines how 0-RTT packets and their contents are formed. To ensure that the same information is available to both endpoints, all information used to establish 0-RTT comes from the same connection.  Endpoints cannot selectively disregard information that might alter the sending or processing of 0-RTT. TLS13 sets a limit of 7 days on the time between the original connection and any attempt to use 0-RTT.  There are other constraints on 0-RTT usage, notably those caused by the potential exposure to replay attack; see replay. 4.6.1. </ins> To communicate their willingness to process 0-RTT data, servers send a NewSessionTicket message that contains the "early_data" extension <del> with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  Servers MUST NOT send the "early_data" extension with a max_early_data_size set to any value other than 0xffffffff.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </del> <ins> with a max_early_data_size of 0xffffffff.  The TLS max_early_data_size parameter is not used in QUIC.  The amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server. Servers MUST NOT send the "early_data" extension with a max_early_data_size set to any value other than 0xffffffff.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </ins> A client that wishes to send 0-RTT packets uses the "early_data" <del> extension in the ClientHello message of a subsequent handshake (see Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets. </del> <ins> extension in the ClientHello message of a subsequent handshake; see Section 4.2.10 of TLS13.  It then sends application data in 0-RTT packets. </ins> <del> 4.7. </del> <ins> A client that attempts 0-RTT might also provide an address validation token if the server has sent a NEW_TOKEN frame; see Section 8.1 of QUIC-TRANSPORT. 4.6.2. </ins> A server accepts 0-RTT by sending an early_data extension in the EncryptedExtensions (see Section 4.2.10 of TLS13).  The server then

configuration.  The client therefore MUST reset the state of all streams, including application state bound to those streams. <del> A client MAY attempt to send 0-RTT again if it receives a Retry or Version Negotiation packet.  These packets do not signify rejection of 0-RTT. </del> <ins> A client MAY reattempt 0-RTT if it receives a Retry or Version Negotiation packet.  These packets do not signify rejection of 0-RTT. </ins> <del> 4.8. </del> <ins> 4.6.3. </ins> When a server receives a ClientHello with the "early_data" extension, it has to decide whether to accept or reject early data from the

different requirements for determining whether to accept or reject early data. <del> 4.9. </del> <ins> 4.7. </ins> In TLS over TCP, the HelloRetryRequest feature (see Section 4.1.4 of TLS13) can be used to correct a client's incorrect KeyShare extension

use the Retry feature (see Section 8.1 of QUIC-TRANSPORT). HelloRetryRequest is still used to request key shares. <del> 4.10. </del> <ins> 4.8. </ins> If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13.

handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. <del> 4.11. </del> <ins> 4.9. </ins> After QUIC moves to a new encryption level, packet protection keys for previous encryption levels can be discarded.  This occurs several

and retransmissions of data in CRYPTO frames are sent at a previous encryption level.  These packets MAY also include PADDING frames. <del> 4.11.1. </del> <ins> 4.9.1. </ins> Packets protected with Initial secrets (initial-secrets) are not authenticated, meaning that an attacker could spoof packets with the

This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets. <del> 4.11.2. </del> <ins> 4.9.2. </ins> An endpoint MUST discard its handshake keys when the TLS handshake is confirmed (handshake-confirmed).  The server MUST send a HANDSHAKE_DONE frame as soon as it completes the handshake. <del> 4.11.3. </del> <ins> 4.9.3. </ins> 0-RTT and 1-RTT packets share the same packet number space, and clients do not send 0-RTT packets after sending a 1-RTT packet