Change:
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

Discussion:
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.