Original text:
expected to be relevant for a closed connection.  Retransmitting the final packet requires less state. <del> New packets from unverified addresses could be used to create an amplification attack; see address-validation.  To avoid this, endpoints MUST either limit transmission of CONNECTION_CLOSE frames to validated addresses or drop packets without response if the response would be more than three times larger than the received packet. After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state.  An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a CONNECTION_CLOSE frame and a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets, which could result in a constant exchange of CONNECTION_CLOSE frames until the closing period on either peer ended. </del>  <del> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocols negotiates a graceful shutdown.  The application protocol exchanges whatever messages that are needed to cause both endpoints to agree to close the connection, after which the application requests that the connection be closed.  When the application closes the connection, a CONNECTION_CLOSE frame with an appropriate error code will be used to signal closure. 10.2.1. </del>  When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a

Reviewer comments:
I took a careful look at the text here and found a few things: There wasn't much redundancy, but there was a little. Mostly the problem was scattering of content between two locations in the document. The closing and draining states only apply to immediate close. So I moved things up. I trimmed the top-level immediate close text, and moved text specific to closing or draining to sections corresponding to each. There were a few bits that could be cut, and a few that needed to be better aligned with existing text, but nothing major. Most of this is unmodified text. There are a few bits that I had to tweak. I will add comments for those.
NAME you can add this to your review load.
The section on Immediate Close contains some text that is redundant with the section on the Closing and Draining periods. Factor some of this out.
I think this flows a lot better. Thanks for the time you put into this!Thanks, Martin!

Revised text:
expected to be relevant for a closed connection.  Retransmitting the final packet requires less state.  <ins> While in the closing state, an endpoint could receive packets from a new source address, possibly indicating a connection migration; see migration.  An endpoint in the closing state MUST either discard packets received from an unvalidated address or limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address. </ins>  <ins> An endpoint is not expected to handle key updates when it is closing (Section 6 of QUIC-TLS).  A key update might prevent the endpoint from moving from the closing state to the draining state, as the endpoint will not be able to process subsequently received packets, but it otherwise has no impact. 10.2.2. The draining state is entered once an endpoint receives a CONNECTION_CLOSE frame, which indicates that its peer is closing or draining.  While otherwise identical to the closing state, an endpoint in the draining state MUST NOT send any packets.  Retaining packet protection keys is unnecessary once a connection is in the draining state. An endpoint that receives a CONNECTION_CLOSE frame MAY send a single packet containing a CONNECTION_CLOSE frame before entering the draining state, using a NO_ERROR code if appropriate.  An endpoint MUST NOT send further packets.  Doing so could result in a constant exchange of CONNECTION_CLOSE frames until one of the endpoints exits the closing state. An endpoint MAY enter the draining state from the closing state if it receives a CONNECTION_CLOSE frame, which indicates that the peer is also closing or draining.  In this case, the draining state SHOULD end when the closing state would have ended.  In other words, the endpoint uses the same end time, but ceases transmission of any packets on this connection. 10.2.3. </ins> When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process the frame.  Generally, this means sending the frame in a