Original text:
1. <del> QUIC QUIC is a new transport protocol currently under development in the IETF quic working group, focusing on support of semantics as needed for HTTP/2 QUIC-HTTP such as stream-multiplexing to avoid head-of-line blocking.  Based on current deployment practices, QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information. </del>  This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This <del> includes general guidance for application use of HTTP/2 over QUIC as well as the use of other application layer protocols over QUIC.  For specific guidance on how to integrate HTTP/2 with QUIC, see QUIC- HTTP. </del>  In the following sections we discuss specific caveats to QUIC's applicability, and issues that application developers must consider fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the <del> application layer if needed.  Further, TCP without the TCP Fast Open extension does not support 0-RTT session resumption.  TCP Fast Open can be requested by the connection initiator but might no be supported by the far end or could be blocked on the network path. </del>  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is <del> recognized as such by the receiverApplications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, whether PFS is a hard requirement for the application, and/or whether rejected 0-RTT dgitata should be retransmitted or withdrawn. </del>  3.3. binding or other state entry will be expired after just thirty seconds of inactivity.  A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of <del> interactions with no or very short idle periods. </del>  Ensure there are no long idle periods. transmitted over one stream is mapped into frames or how those frames are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize <del> bandwidth consumption and computational costs (see section 8 of </del>  QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or

Reviewer comments:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.

Revised text:
1.  <ins> QUIC QUIC is a new transport protocol providing a number of advanced features.  While initially designed for the HTTP use case, like most transports it is intended for use with a much wider variety of applications.  QUIC is encapsulated in UDP.  The version of QUIC that is currently under development will integrate TLS 1.3 TLS13 to encrypt all payload data and most control information.  HTTP operating over QUIC is known as HTTP/3. </ins> This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This  <ins> includes general guidance for applications operating over HTTP/3 or directly over QUIC.  For specific guidance on how to integrate HTTP/3 with QUIC, see QUIC-HTTP. </ins> In the following sections we discuss specific caveats to QUIC's applicability, and issues that application developers must consider fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the  <ins> application layer if needed. Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption. Even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </ins> Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). established with 0-RTT MUST be idempotent (as specified in section 2.1 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is  <ins> recognized as such by the receiver.  Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For these reason the QUIC transport SHOULD provide some or all of the following interfaces to applications: indicate if 0-RTT support is in general desired, which implies that lack of PFS is acceptable for some data; an indication when 0RTT data for both egress and ingress, so that both sender and receiver understand the properties of the communication channel when the data is sent; and/or whether rejected 0-RTT data should be retransmitted or withdrawn. Some TLS implementations may offer replay protection, which may mitigate some of these issues. </ins> 3.3. binding or other state entry will be expired after just thirty seconds of inactivity. <ins> By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections may not be robust to rebinding because the routing infrastructure (in particular, load balancers) uses the address/port four-tuple to direct traffic.  Furthermore, middleboxes with functions other than address translation may still affect the path.  In particular, firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. </ins> A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of  <ins> interactions with no or very short idle periods, or the protocol's resistance to NAT rebinding is sufficient. </ins> Ensure there are no long idle periods. transmitted over one stream is mapped into frames or how those frames are bundled into packets.  By default, QUIC will try to maximally pack packets with one or more stream data frames to minimize  <ins> bandwidth consumption and computational costs (see section 13 of </ins> QUIC).  If there is not enough data available to fill a packet, QUIC may even wait for a short time, to optimize bandwidth efficiency instead of latency.  This delay can either be pre-configured or