Original text:
flow control limits set by its peer, and continues to accept and process MAX_STREAM_DATA frames.  An endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is blocked from sending by <del> stream or connection flow control limits data-flow-control. </del>  After the application indicates that all stream data has been sent and a STREAM frame containing the FIN bit is sent, the sending part routed.  This can be used to direct connections to a different server instance. <del> If a server receives a client Initial that can be unprotected but contains an invalid Retry token, it knows the client will not accept </del>  another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  Instead, the lost or when the limit is updated, with care taken to prevent the frame from being sent too often.  An endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receiving part of the stream <del> enters a "Size Known" state. </del>  The limit on streams of a given type is sent in MAX_STREAMS frames.  Like MAX_DATA, an updated value is sent when a packet Examples and a sample decoding algorithm are shown in sample-varint. <del> Versions (versions) and packet numbers sent in the header (packet- encoding) are described using integers, but do not use this encoding. </del>  17. message.  The first CRYPTO frame sent always begins at an offset of 0; see handshake. <del> Note that if the server sends a HelloRetryRequest, the client will send another series of Initial packets.  These Initial packets will continue the cryptographic handshake and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO frames sent in the first flight of Initial packets. </del>  17.2.2.1. restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it included in this packet.  A server MAY treat a packet that contains a different cryptographic handshake <del> message as a connection error or discard it. </del>  A client MAY attempt 0-RTT after receiving a Retry packet by sending <del> 0-RTT packets to the connection ID provided by the server.  A client MUST NOT change the cryptographic handshake message it sends in response to receiving a Retry. </del>  A client MUST NOT reset the packet number for any packet number space after processing a Retry packet.  In particular, 0-RTT packets

Reviewer comments:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.

Revised text:
flow control limits set by its peer, and continues to accept and process MAX_STREAM_DATA frames.  An endpoint in the "Send" state generates STREAM_DATA_BLOCKED frames if it is blocked from sending by  <ins> stream flow control limits data-flow-control. </ins> After the application indicates that all stream data has been sent and a STREAM frame containing the FIN bit is sent, the sending part routed.  This can be used to direct connections to a different server instance.  <ins> If a server receives a client Initial that contains an invalid Retry token but is otherwise valid, it knows the client will not accept </ins> another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  Instead, the lost or when the limit is updated, with care taken to prevent the frame from being sent too often.  An endpoint SHOULD stop sending MAX_STREAM_DATA frames when the receiving part of the stream  <ins> enters a "Size Known" or "Reset Recvd" state. </ins> The limit on streams of a given type is sent in MAX_STREAMS frames.  Like MAX_DATA, an updated value is sent when a packet Examples and a sample decoding algorithm are shown in sample-varint.  <ins> Versions (versions), packet numbers sent in the header (packet- encoding), and the length of connection IDs in long header packets (long-header) are described using integers, but do not use this encoding. </ins> 17. message.  The first CRYPTO frame sent always begins at an offset of 0; see handshake.  <ins> Note that if the server sends a TLS HelloRetryRequest (see Section 4.7 of QUIC-TLS), the client will send another series of Initial packets.  These Initial packets will continue the cryptographic handshake and will contain CRYPTO frames starting at an offset matching the size of the CRYPTO frames sent in the first flight of Initial packets. </ins> 17.2.2.1. restrictions as the first Initial packet.  A client MUST use the same cryptographic handshake message it included in this packet.  A server MAY treat a packet that contains a different cryptographic handshake  <ins> message as a connection error or discard it.  Note that including a Token field reduces the available space for the cryptographic handshake message, which might result in the client needing to send multiple Initial packets. </ins> A client MAY attempt 0-RTT after receiving a Retry packet by sending  <ins> 0-RTT packets to the connection ID provided by the server. </ins> A client MUST NOT reset the packet number for any packet number space after processing a Retry packet.  In particular, 0-RTT packets