Draft: draft-ietf-quic-transport

Commentary: I took a careful look at the text here and found a few things : was n't much redundancy , but there was a little . Mostly the problem was scattering of content between two locations in the document . 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 . 
 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 ,  !
Paragraph (version B):
After sending a CONNECTION_CLOSE frame, an endpoint immediately
enters the closing state; see closing.  After receiving a
CONNECTION_CLOSE frame, endpoints enter the draining state; see
draining.
Paragraph (version B):
An immediate close can be used after an application protocol has
arranged to close a connection.  This might be after the application
protocol negotiates a graceful shutdown.  The application protocol
can exchange messages that are needed for both application endpoints
to agree that the connection can be closed, after which the
application requests that QUIC close the connection.  When QUIC
consequently closes the connection, a CONNECTION_CLOSE frame with an
application-supplied error code will be used to signal closure to the
peer.
Paragraph (version B):
Once its closing or draining state ends, an endpoint SHOULD discard
all connection state.  The endpoint MAY send a stateless reset in
response to any further incoming packets belonging to this
connection.
Paragraph (version B):
An endpoint enters the closing state after initiating an immediate
close.
Paragraph (version B):
In the closing state, an endpoint retains only enough information to
generate a packet containing a CONNECTION_CLOSE frame and to identify
packets as belonging to the connection.  An endpoint in the closing
state sends a packet containing a CONNECTION_CLOSE frame in response
to any incoming packet that it attributes to the connection.
Paragraph (version B):
An endpoint SHOULD limit the rate at which it generates packets in
the closing state.  For instance, an endpoint could wait for a
progressively increasing number of received packets or amount of time
before responding to received packets.
Paragraph (version B):
An endpoint's selected connection ID and the QUIC version are
sufficient information to identify packets for a closing connection;
the endpoint MAY discard all other connection state.  An endpoint
that is closing is not required to process any received frame.  An
endpoint MAY retain packet protection keys for incoming packets to
allow it to read and process a CONNECTION_CLOSE frame.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version A):
The draining state is entered once an endpoint receives a signal 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.
Paragraph (version A):
Once the closing or draining period has ended, an endpoint SHOULD
discard all connection state.  This results in new packets on the
connection being handled generically.  For instance, an endpoint MAY
send a stateless reset in response to any further incoming packets.
Paragraph (version A):
The draining and closing periods do not apply when a stateless reset
(stateless-reset) is sent.
Paragraph (version A):
An endpoint is not expected to handle key updates when it is closing
or draining.  A key update might prevent the endpoint from moving
from the closing state to draining, but it otherwise has no impact.