Change:
I did add a few paragraphs of text, but don't expect it to be too controversial. Any thoughts?
Needs to be edited and possibly some text migrated.

Discussion:
network operators may be using to troubleshoot HTTP streaming media performance issues, perform analytics, or even intercept exchanges in current applications will not work for QUIC-based applications <del> without making changes to their networks. </del> <ins> without making changes to their networks. stream-encrypt-media describes the implications of media encryption in more detail. </ins> While QUIC is designed as a general-purpose transport protocol, and can carry different application-layer protocols, the current

and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol <del> RFC9000 as its transport layer.  QUIC relies only on the TLS 1.3 initial handshake for key exchange RFC9001, and encrypts almost all transport parameters, with the exception of a few invariant fields. In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the destination connection ID RFC8999.  For </del> <ins> RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself, with the exception of a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination Connection ID, and Source Connection ID.  For </ins> these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

request and response headers and identify the media content being streamed. <del> "End-to-end" media encryption became much more widespread in the years since RFC7258 was issued, which identified pervasive monitoring </del> <ins> "End-to-end" media encryption has become much more widespread in the years since the IETF issued "Pervasive Monitoring Is an Attack" RFC7258 as a Best Current Practice, describing pervasive monitoring </ins> as a much greater threat than previously appreciated.  After the Snowden disclosures, many content providers made the decision to use HTTPS protection - HTTP over TLS - for most or all content being delivered as a routine practice, rather than in exceptional cases for content that was considered "sensitive". <ins> Unfortunately, as noted in RFC7258, there is no way to prevent pervasive monitoring by an "attacker", while allowing monitoring by a more benign entity who "only" wants to use DPI to examine HTTP requests and responses in order to provide a better user experience. If a modern encrypted transport protocol is used for end-to-end media encryption, intermediary streaming operators are unable to examine transport and application protocol behavior.  As described in hop-by- hop-encrypt, only an intermediary streaming operator who is explicitly authorized to examine packet payloads, rather than intercepting packets and examining them without authorization, can continue these practices. RFC7258 said that "The IETF will strive to produce specifications that mitigate pervasive monitoring attacks", so streaming operators should expect the IETF's direction toward preventing unauthorized monitoring of IETF protocols to continue for the forseeable future. </ins> 7. This document requires no actions from IANA.