Original text:
1. QUIC QUIC is a new transport protocol providing a number of advanced <del> 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. </del>  This document provides guidance for application developers that want to use the QUIC protocol without implementing it on their own.  This 1.1. <del> The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document.  It's not shouting; when these words are capitalized, they have a special meaning as defined in RFC2119. </del>  2. <del> QUIC uses UDP as a substrate for userspace implementation and port numbers for NAT and middlebox traversal.  While there is no evidence of widespread, systematic disadvantage of UDP traffic compared to TCP in the Internet Edeline16, somewhere between three Trammell16 and five Swett16 percent of networks simply block UDP traffic.  All applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  This fallback SHOULD provide TLS 1.3 or equivalent cryptographic protection, if available, in order to keep fallback from being exploited as a downgrade attack. In the case of HTTP, this fallback is TLS 1.3 over TCP. </del>  These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the 3.1. <del> A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption- v-keepalive. </del>  Applications must be slightly rethought in order to make best use of <del> 0-RTT resumption.  Most importantly, application operations must be divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes idempotence either explicitly or implicitly. </del>  3.2. Retransmission or (malicious) replay of data contained in 0-RTT <del> resumption packets could cause the server side to receive two copies of the same data.  This is further described in HTTP-RETRY.  Data sent during 0-RTT resumption also cannot benefit from perfect forward secrecy (PFS). Data in the first flight sent by the client in a connection established with 0-RTT MUST be idempotent (as specified in Section 5.6 in QUIC-TLS).  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is 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. </del>  3.3. entirely. By using a Connection ID, QUIC is designed to be robust to NAT <del> 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. A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </del>  Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to <del> lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </del>  Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is <del> idempotent. </del>  The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should

Reviewer comments:
These are pretty big. If you would prefer that I create a PR for each individual commit, that can be done. It turns out that there were a lot of things I found needed work. For instance, this completely redoes the 0-RTT advice.
It did kinda snowball, for which I apologize. I was trying to get something under your nose before I got swamped by meetings. I am also on vacation next week. I'm reading through and there is some really good stuff in the doc. I have started to open issues where I don't think the fixes are so simple.
Aside from the keep-alive tweak and the idempotence change, these are all editorial and LGTM, thanks! The keepalive tweak is also good. Having looked at URL, the text here is a good applicability-appropriate view on what's there now. assuming discussion there converges to mostly the same thing, I'd be happy to merge this. (in the future, no need to make tiny PRs, but splitting into "editorial-rollup" and "substantive editorial changes" would be nice to separate discussion, since the former shouldn't need much of it)Changes look all ready good. Thanks! I just have left one minor comment/question to double-check before we merge.

Revised text:
1. QUIC QUIC is a new transport protocol providing a number of advanced  <ins> features.  While initially designed for the HTTP use case, it provides capabilities that can be used with a much wider variety of applications.  QUIC is encapsulated in UDP.  QUIC version 1 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 1.1.  <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.  <ins> QUIC uses UDP as a substrate.  This enables both userspace implementation traversal of middleboxes and NAT without requiring updates. While there is no evidence of widespread, systematic disadvantage of UDP traffic compared to TCP in the Internet Edeline16, somewhere between three Trammell16 and five Swett16 percent of networks simply block UDP traffic.  All applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further downgrades to older TLS versions might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation ALPN only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the 3.1.  <ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view of the application using it.  Relative trade-offs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption-v-keepalive. </ins> Applications must be slightly rethought in order to make best use of  <ins> 0-RTT resumption.  Using 0-RTT requires an understanding of the implication of sending application data that might be replayed by an attacker. Application protocols that use 0-RTT require a profile that describes the types of information that can be safely sent.  For HTTP, this profile is described in HTTP-REPLAY. </ins> 3.2. Retransmission or (malicious) replay of data contained in 0-RTT  <ins> packets could cause the server side to receive two copies of the same data. Application data sent by the client in 0-RTT packets could be processed more than once if it is replayed.  Applications need to be aware of what is safe to send in 0-RTT.  Application protocols that seek to enable the use of 0-RTT need a careful analysis and a description of what can be sent in 0-RTT; see Section 5.6 of QUIC- TLS. In some cases, it might be sufficient to limit application data sent in 0-RTT to that which only causes actions at a server that are known to be free of lasting effect.  Initiating data retrieval or establishing configuration are examples of actions that could be safe.  Idempotent operations - those for which repetition has the same net effect as a single operation - might be safe.  However, it is also possible to combine individually idempotent operations into a non-idempotent sequence of operations. Once a server accepts 0-RTT data there is no means of selectively discarding data that is received.  However, protocols can define ways to reject individual actions that might be unsafe if replayed. Some TLS implementations and deployments might be able to provide partial or even complete replay protection, which could be used to manage replay risk. </ins> 3.3. entirely. By using a Connection ID, QUIC is designed to be robust to NAT  <ins> address rebinding after a timeout.  However, this only helps if one endpoint maintains availability at the address its peer uses, and the peer is the one to send after the timeout occurs. 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 could 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. A QUIC application can adjust idle periods to manage the risk of timeout (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC), but then there are three options: </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to  <ins> lower network and computational load. Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices.  Additionally, time-outs shorter than 30 seconds can make it harder to handle transient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is  <ins> idempotent.  Using resumption in this way also assumes that the protocol does not accumulate any non-persistent state in association with a connection.  State bound to a connection cannot reliably be transferred to a resumed connection. </ins> The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should