Original text:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del>  These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

Reviewer comments:
From PR : I'd also like to see something like : /In this section, we discuss those aspects of the QUIC transport protocol that/This section discusses those aspects of the QUIC transport protocol that/ /Here, we are concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, which we define as the information available in the packet/This section is concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, defined as the information available in the packet/ and /least four datagrams we'll call "Client Initial",/least four datagrams, labelled "Client Initial",/ and / 0-RTT data may also be seen in the Client Initial datagram, as shown in /When the client uses 0-RTT connection resumption, the Client Initial datagram can also carry 0-RTT data, as shown in/ and /typically around 10 packets/typically to around 10 packets/ and /of a connection after one of one endpoint/of a connection after an endpoint/ I'd prefer more like: /Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision as to whether or not to filter later packets in the same connection. QUIC applications are encouraged to fail over to TCP if early packets do/ ... and I'll close PR .
“QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or because the information is intended to be used by the network.” Could this benefit form a cross-reference to manageability, where this topic is also discussed from a network perspective?
Three places where the text might avoid confusion when read in future years: 1) “Further downgrades to older TLS versions than used in QUIC, which is 1.3, “ … will it always be 1.3, or should this be “in QUIC [REF] is TLS 1.3” 2) “Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window. “ I'm not so happy with currently here: Is this the best way to say this, might it be better to say this rather than even hinting that future QUIC might only be reliable: “When a QUIC endpoint provides provides fully reliable stream transmission, prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window. “ 3) I’d prefer to see a ref here, since this something that the WG might later decide to work upon: “Currently QUIC only supports failover cases [Quic-Transport].”
That mega paragraph has a bunch of good concepts, but it's all run together into a single blob, which makes it a bit hard to follow.

Revised text:
An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further  <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 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