Change:
to send data.  A credit-based scheme is used to limit stream creation and to bound the amount of data that can be sent. <del> The QUIC handshake combines negotiation of cryptographic and transport parameters.  The handshake is structured to permit the exchange of application data as soon as possible.  This includes an option for clients to send data immediately (0-RTT), which might require prior communication to enable. </del> <ins> QUIC provides the necessary feedback to implement reliable delivery and congestion control.  An algorithm for detecting and recovering from loss of data is described in QUIC-RECOVERY.  QUIC depends on congestion control to avoid network congestion.  An exemplary congestion control algorithm is also described in QUIC-RECOVERY. </ins> QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers to allow connections <del> to transfer to a new network path. Frames are used in QUIC to communicate between endpoints.  One or more frames are assembled into a QUIC packet.  QUIC authenticates all packets and encrypts as much as is practical.  QUIC packets are carried in UDP datagrams (UDP) to better facilitate deployment in existing systems and networks. </del> <ins> to transfer to a new network path.  Only clients are able to migrate in this version of QUIC.  This design also allows connections to continue after changes in network topology or address mappings, such as might be caused by NAT rebinding. </ins> Once established, multiple options are provided for connection termination.  Applications can manage a graceful shutdown, endpoints

Discussion:
This takes some of the concepts that NAME added in and massages those into the introduction. The net effect is two-fold: a little more substance in this section and the addition of prominent, early references to the key supporting documents. It removes the bullet feature list and puts that into the abstract as a single sentence. I have also reordered this slightly. There is no perfect ordering here, but this no longer slavishly adheres to the document structure.
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies the cryptographic exchanges and formats associated with the QUIC protocol, which in turn is an ambitious protocol that could over time replace TCP. quic-transport, quic-tls, and quic-recovery represent a triple of I-Ds that are always used together and could be combined into a single spec, though the length of the existing specs is already daunting. In many cases, it is impossible to evaluate them independently. As an interested outsider, I see these protocols as exceptionally well designed and the specs exceptionally well written. I could not find even any nits in a very long spec. It is misleading to regard this as a specification of running QUIC over TLS. It is related to TLS in the same way that DTLS is related to TLS: it imports much of the syntax, but there are many differences and its security must be evaluated largely independently. My initial reaction to this spec was to wonder why it did not simply run QUIC over DTLS . I believe the answer is that careful integration improves the performance and is necessary for some of the address agility/transition design. Given its potential importance, this deserves a thorough review by our best security people. Fortunately, from the acknowledgements list, it appears it has gotten that. There are a few aspects of the design that might raise eyebrows. For example: 1) TLS exchanges start out in cleartext until a key can be negotiated. QUIC data is always encrypted. The initial packets are encrypted with fixed keys whose derivation is specified in the I-D until fresh keys are negotiated.

This isn't a security URL will just surprise people. 2) Applications using TLS can usually be configured to run over TCP in contexts where cryptographic protection is not needed. (e.g., use HTTP instead of HTTPS). Applications using QUIC cannot. That is likely to mean in practice that it will more frequently be the case that applications using QUIC will need to connect to servers without certificates signed by a CA trusted by the client (because that's the substitute when connecting to a server without a certificate). It's not clear what the spec should say about that, but perhaps the problem should be acknowledged. Radia
(2) is the only comment here that raises a possible text change, and it's editorial-only. I'm not certain it's properly a security issue with the protocol, but a note in Security Considerations that people might be more inclined to do self-signed certs with a transport that doesn't let them opt out of TLS wouldn't break anything.
Proposing to do nothing. The only comment that raises concerns (2) is not unique to QUIC, but a pre-existing concern with TLS as well.
I agree with NAME now clearly that TLS is integrated with QUIC.
I agree with NAME too.
The proposed resolution was to close to with action, which was signalled to the appropriate review channel. Hearing no pushback, I'm closing this.
Section 1 provides an ultrafast introduction to the problem, and very little on the fundamentals of how the protocol works. It would be useful if there a process by which the reader is gradually immersed in the detail.
That is, in fact, the intended structure of the document. Section 1 provides an extremely high-level view of the protocol; section 1.1 lays out how these high-level concepts are discussed in greater depth in Sections 2-14, with wire-level details reserved for Sections 15-20. Is the suggestion that there should be a new Section 2 which goes into more detail than Section 1, but less detail than Sections 2-14? Or is the suggestion more detail in Section 1.1 about the concepts before the forward references?
What NAME said above. The draft is already super long, so while we can make additions for clarity, I'd want to keep it as short as possible.
Adding the text in a new section 2 would be a good idea.

Whilst the draft is long, it has to be readable by readers that are not yet experts on the protocol. My overall impression during my review was that it was a draft written by people that understood the protocol for people that understood the protocol, but the target audience for a major new IETF transport protocol is much wider than that. It is also the same with the very abbreviated text on some important design decisions. This is fine whilst the original designers are around, but the work has a lifetime longer than the participation lifetime of the original designers, and a few words now save a lot of discussion and more importantly mistakes and complexity as the design is developed, possibly decades in the future.