Draft: draft-ietf-mops-streaming-opcons

Commentary: I did add a few paragraphs of text , but do n't expect it to be too controversial . Any thoughts ? 
 Needs to be edited and possibly some text migrated .
Paragraph (version A):
Although QUIC provides an alternative to the TCP and UDP transport
protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
this document, the QUIC protocol encrypts almost all of its transport
parameters, and all of its payload, so any intermediaries that
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
without making changes to their networks.
Paragraph (version B):
Although QUIC provides an alternative to the TCP and UDP transport
protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
this document, the QUIC protocol encrypts almost all of its transport
parameters, and all of its payload, so any intermediaries that
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
without making changes to their networks. stream-encrypt-media
describes the implications of media encryption in more detail.
Paragraph (version A):
Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries do have access to
unencrypted TCP-level transport information, such as retransmissions,
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
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
these reasons, HTTP/3 is significantly more "opaque" than HTTPS with
HTTP/1 or HTTP/2.
Paragraph (version B):
Because HTTPS has historically layered HTTP on top of TLS, which is
in turn layered on top of TCP, intermediaries do have access to
unencrypted TCP-level transport information, such as retransmissions,
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
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
these reasons, HTTP/3 is significantly more "opaque" than HTTPS with
HTTP/1 or HTTP/2.
Paragraph (version A):
"End-to-end" media encryption became much more widespread in the
years since RFC7258 was issued, which identified pervasive monitoring
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".
Paragraph (version B):
"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
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".
Paragraph (version B):
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.
Paragraph (version B):
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.