Draft: draft-ietf-mops-streaming-opcons

Commentary: and - I ca n't remember how many review comments we got that were some version of " is THIS . Since review was one of these , and it was the last one I was working on , I piled all the definitions and clarifications into this PR , so the changes for this PR are much bigger than you would have expected , if you were just looking at ... Just so you 're not stunned when you see the slides at IETF 114 ... : innocent : 
 But , seriously , it 's fine . 
 I ca n't tell you how happy I am that I finished my edits before I clicked on the Youtube link ... : upsidedownface : 
 Gee , you can JUST SEE THE TYPO HAPPEN , as I missed " CTRL " in front of the " f " ... : facewithspiral_eyes : 
 From 
 thank you for the review . On a quick read ( the authors have a conference call this afternoon my time ) , most of these are immediately actionable , and the ones that need a bit more discussion seem helpful and worth discussing . More news to follow , of course . 
 and - review has popped up some higher - level questions for me , that could be addressed in this issue , or in separate issues . I 'm keeping this list here , until our call in about 26 minutes . This document uses the word " media " about 200 times , and the word " video " about 70 times . I know I have n't been careful to use the best word in text I 've written . It 's probably worth doing a pass in the document to make sure that we say what we mean . Actually , are we mostly talking about " media " in general , and only mentioning " video " in specifics ? We only use the qualifier " high - bitrate " three times ( and two of these are in the abstract and introduction ) . That seems like an important qualifier . I think this document does include Video On Demand . Does anyone disagree ? We 've been saying that media delivery over RTP is " out of scope " , but the word " RTP " appears 12 times in the document . I think we 're including " interactive " , " live " , and " VoD " streaming media , and we probably need to say that clearly , early in the document . is there any difference , from the media provider 's perspective , if ( presumably high - bitrate ) media is streamed to be consumed by a machine ? Zahed has an excellent question - can we explain what 's different about ads , in about 1/4 the space ? sometimes we say " content provider " , and other times we say " media provider " . Is there a meaningful difference , or can we use the same term ? I 'm surprised that we only use the term " operator " three times , and even more surprised that these are n't all talking about the same thing , so that needs to be fixed ... 
 and - I 'm working through the high - level questions in my previous comment , and I have a few new ones . We never defined " high - bitrate " , although we ( now ) use the term in the abstract and in the Introduction . I 'm thinking about adding a pointer to the table of typical bitrates for various bitrates and resolutions in the " Video Bitrates " section , and saying " like , these bitrates " . 
 and - reasonably asked about a citation for this assertion in the draft : After poking around for a while , I 'm not seeing an obvious citation in open literature ( indexed by Google ) , specific to 5G. We do need to decide what to do with this one comment , before merging . 
 I probably wrote that text , and the reason I believed it was that it was discussed in I think a tsvwg or iccrg session talking about using chirping experimentally in conjunction with TCP Prague to find the link capacity , I think either by Ingemar or  . I now wish I could recall which meeting , or even which year I saw this . I do n't have a straight capacity metric , but I saw some stuff about attenuation and effects like shadow fading and path loss that I think are the physics reasons behind the 2nd - hand reported observation : Maybe we should strike the claim if we ca n't find a good source for it -- these 5 g docs talking about the relevant effects tend to speak in decibels rather than mbps , and it 's not clear to me exactly how they translate . 
 - I 'd be astounded if no one at the IETF could speak to this , but in the references I could find , ISTM that there are all kinds of things that can affect pretty much any path traversing at least one wireless link . I removed the specific 5 G and  likewise can easily see rate variation by a factor of 2 or more over a span of seconds as users move around . , which I do n't think we can back up precisely , so now all the wireless - link paths are covered by an overarching In most real - world operating environments , wireless links can often experience sudden changes in capacity as the end user device moves from place to place or encounters new sources of interference . If that works for you , should be ready to review and ( if it 's OK ) merge . 
 on this comment , ( as an aside , I should mention that I do n't have any memory of active measurements being discussed in the working group for this document , but let 's ignore that , for now , and try to do the right thing ) I could n't think of a way to describe advantages of active testing that would work better than the measurement collection section for streaming media operators . Sure , active measurements can be the right thing to do , for operators providing access networks , etc . 
 lgtm now , after the fix for " somFblisse "
Paragraph (version A):
This document provides an overview of operational networking issues
that pertain to the quality of experience when streaming video and
other high-bitrate media over the Internet.
Paragraph (version A):
This document examines networking and transport protocol issues as
they relate to the quality of experience (QoE) in Internet media
delivery, especially focusing on capturing characteristics of
streaming video delivery that have surprised network designers or
transport experts who lack specific video expertise, since streaming
media highlights key differences between common assumptions in
existing networking practices and observations of video delivery
issues encountered when streaming media over those existing networks.
Paragraph (version A):
Streaming is the continuous transmission of media from a server to
a client and its simultaneous consumption by the client.
Paragraph (version A):
Here, "media" refers to any type of media and associated streams
such as video, audio, metadata, etc.  In this definition, the
critical term is "simultaneous," as it is not considered streaming
if one downloads a media file and plays it after the download is
completed, which would be called download-and-play.
Paragraph (version A):
This has two implications.
Paragraph (version A):
First, the server's transmission rate must (loosely or tightly)
match the client's consumption rate to provide uninterrupted
playback.  That is, the client must not run out of data (buffer
underrun) or accept more data than it can buffer before playback
(buffer overrun), as any excess media that cannot be buffered is
simply discarded.
Paragraph (version A):
Second, the client's consumption rate is limited by not only
bandwidth availability but also media availability.  The client
cannot fetch media that is not available from a server yet.
Paragraph (version B):
This document provides an overview of operational networking and
transport protocol issues that pertain to the quality of experience
when streaming video and other high-bitrate media over the Internet.
Paragraph (version B):
This document provides an overview of operational networking and
transport protocol issues that pertain to the quality of experience
(QoE) when streaming video and other high-bitrate media over the
Internet.
Paragraph (version B):
"High-bitrate" is a context-sensitive term broadly intended to
capture rates that can be sustained over some but not all of the
target audience's network connections.  A snapshot of values
commonly qualifying as high-bitrate on today's internet is given
by the higher-value entries in bvr.
Paragraph (version B):
"Streaming" means the continuous transmission of media segments
from a server to a client and its simultaneous consumption by the
client.
Paragraph (version B):
The term "simultaneous" is critical, as media segment
transmission is not considered "streaming" if one downloads a
media file and plays it after the download is completed.
Instead, this would be called "download and play".
Paragraph (version B):
This has two implications.  First, the sending rate for media
segments must match the client's consumption rate (whether
loosely or tightly) to provide uninterrupted playback.  That
is, the client must not run out of media segments (buffer
underrun), and must not accept more media segments than it can
buffer before playback (buffer overrun).
Paragraph (version B):
Second, the client's media segment consumption rate is limited
not only by the path's available bandwidth, but also by media
segment availability.  The client cannot fetch media segments
that a media server cannot provide (yet).
Paragraph (version B):
"Media" refers to any type of media and associated streams such as
video, audio, metadata, etc.
Paragraph (version B):
A full review of all streaming media considerations for all types of
media over all types of network paths is too broad a topic to cover
comprehensively in a single document.
Paragraph (version B):
This document focuses chiefly on large-scale delivery of streaming
high-bitrate media to end users.  It is primarily intended for those
controlling endpoints involved in delivering streaming media traffic.
This can include origin servers publishing content, intermediaries
like content delivery networks (CDNs), and providers for client
devices and media players.
Paragraph (version B):
Most of the considerations covered in this document apply both to
"live media" (created and streamed as an event is in progress) and
"media on demand" (previously recorded media that is streamed from
storage), except where noted.
Paragraph (version B):
Most of the considerations covered in this document apply both to
media that is consumed by a media player, for viewing by a human, and
media that is consumed by a machine, such as a media recorder that is
executing an ABR algorithm, except where noted.
Paragraph (version A):
A description of existing transport protocols used for video
streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
that we expect to be used for streaming media (sec-trans),
Paragraph (version B):
A description of existing transport protocols used for video
streaming and the issues encountered when using those protocols,
along with a description of the QUIC transport protocol RFC9000
more recently used for streaming media (sec-trans),
Paragraph (version A):
A full review of all streaming media considerations is too broad a
topic to cover comprehensively in a single document.
Paragraph (version A):
This document focuses chiefly on large-scale delivery of streaming
media to end users and related issues.  It is primarily intended for
those controlling endpoints involved in delivering streaming media
traffic.  This can include origin servers publishing content,
intermediaries like content delivery networks (CDNs), and providers
for client devices and media players.
Paragraph (version A):
in-depth examination of real-time interactive media, such as video
conferencing; although we touch lightly on topics in this space,
the intent is to let readers know that for more in-depth coverage
they'll need to look to other documents, since the techniques and
issues for interactive real-time media differ so dramatically from
those in large-scale one-way delivery of streaming media.
Paragraph (version B):
in-depth examination of real-time two-way interactive media, such
as video conferencing; although this document touches lightly on
topics related to this space, the intent is to let readers know
that for more in-depth coverage they should look to other
documents, since the techniques and issues for interactive real-
time two-way media differ so dramatically from those in large-
scale one-way delivery of streaming media.
Paragraph (version A):
It is worth pointing out explicitly, because questions about "Web
Real-Time Communication", or "WebRTC", come up often, that some
WebRTC protocols (RFC8834, RFC8835) are mentioned in this document,
including RTP, WebRTC's principal media transport protocol.  However,
(as noted in sd) it is difficult to give general guidance for
unreliable media transport protocols, even in the specific case of
WebRTC.
Paragraph (version B):
transparent tunnels; while tunnels can have an impact on streaming
media via issues like the round trip time and the maximum
transmission unit (MTU) of packets carried over tunnels, for the
purposes of this document these issues are considered as part of
the set of network path properties.
Paragraph (version B):
It is worth pointing out explicitly, because questions about "Web
Real-Time Communication" or "WebRTC" have come up often, that some
WebRTC protocols (RFC8834, RFC8835) are mentioned in this document,
including RTP, WebRTC's principal media transport protocol.  However,
(as noted in sd) it is difficult to give general guidance for
unreliable media transport protocols used to carry interactive real-
time media.
Paragraph (version B):
Note that these codecs do not take the actual "available
bandwidth" between streaming video servers and streaming video
receivers into account when encoding, because the codec does not
have any idea what network paths and network path conditions will
carry the encoded video, at some point in the future.
Paragraph (version B):
Note that video receivers attempting to receive encoded video
across a network path with insufficient available path bandwidth
might request the video server to provide video encoded for lower
bitrates, as described in adapt-deliver.
Paragraph (version B):
In order to provide multiple encodings for video resources, the
codec must produce multiple versions of the video resource encoded
at various bitrates, as described in adapt-encode.
Paragraph (version A):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom" or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  Yet, due to smart delivery methods such as viewport-based or
tile-based streaming, we do not need to send the whole scene to the
user.  Instead, the user needs only the portion corresponding to its
viewpoint at any given time (Survey360o).
Paragraph (version B):
Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom" or
3DoF) require substantially larger bitrates when they are captured
and encoded as such videos require multiple fields of view of the
scene.  Yet, due to smart delivery methods such as viewport-based or
tile-based streaming, there is no need to send the whole scene to the
user.  Instead, the user needs only the portion corresponding to its
viewpoint at any given time (Survey360o).
Paragraph (version A):
Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path
by adjusting the amount of media that the media server will send
to the media player in a given timeframe.  This is described in
greater detail in sec-abr.
Paragraph (version A):
Media servers also typically rely on transport protocols with
capacity-seeking congestion controllers that probe for bandwidth
and adjust the sending rate based on transport mechanisms.  This
is described in greater detail in sec-trans.
Paragraph (version B):
Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path
by adjusting the number of media segments that the media server
will send to the media player in a given timeframe.  This is
described in greater detail in sec-abr.
Paragraph (version B):
Media servers also typically rely on transport protocols with
capacity-seeking congestion controllers that probe for available
path bandwidth and adjust the media segment sending rate based on
transport mechanisms.  This is described in greater detail in sec-
trans.
Paragraph (version A):
One might wonder why media servers and transport protocols are each
blissfully ignorant of what the other is doing, and there are
multiple reasons for that.  However, one reason is that media servers
may be implemented to run under a general-purpose operating system
that typically has its transport protocols implemented in the
operating system kernel, making decisions that the media server never
knows about.
Paragraph (version B):
One might wonder why media servers and transport protocols are each
unaware of what the other is doing, and there are multiple reasons
for that.  One reason is that media servers are often implemented as
applications executing in user space, relying on a general-purpose
operating system that typically has its transport protocols
implemented in the operating system kernel, making decisions that the
media server never knows about.
Paragraph (version A):
the transport protocol cannot probe for available path bandwidth
by sending at a higher rate.
Paragraph (version A):
To avoid these types of situations, which can potentially affect all
the users whose streaming media traverses a bottleneck, there are
several possible mitigations that streaming operators can use.
However, the first step toward mitigating a problem is knowing when
that problem occurs.
Paragraph (version B):
the transport protocol cannot probe for available path bandwidth
by sending at a higher rate, until the media receiver signals the
media server that the media server can increase its media segment
sending rate.
Paragraph (version B):
To avoid these types of situations, which can potentially affect all
the users whose streaming media segments traverse a bottleneck, there
are several possible mitigations that streaming operators can use.
However, the first step toward mitigating a problem is knowing that a
problem is occurring.
Paragraph (version A):
Wireless links (Wi-Fi, 5G, LTE, etc.) often see rapid changes to
capacity from changes in radio interference and signal strength as
endpoints move.
Paragraph (version A):
To recognize that a path carrying streaming media has experienced a
change, maintaining a baseline that captures its prior properties is
fundamental.  Analytics that aid in that recognition can be more or
less sophisticated and can usefully operate on several different time
scales, from milliseconds to hours or days.
Paragraph (version B):
Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to
capacity from changes in radio interference and signal strength as
endpoints move.
Paragraph (version B):
To recognize that a path carrying streaming media segments has
experienced a change, maintaining a baseline that captures its prior
properties is fundamental.  Analytics that aid in that recognition
can be more or less sophisticated and can usefully operate on several
different time scales, from milliseconds to hours or days.
Paragraph (version A):
All of this depends, of course, on the ability of a content provider
to predict usage and provision bandwidth, caching, and other
mechanisms to meet the needs of users.  In some cases (sec-predict),
this is relatively routine, but in other cases, it is more difficult
(sec-unpredict).
Paragraph (version B):
All of this depends, of course, on the ability of a media provider to
predict usage and provision bandwidth, caching, and other mechanisms
to meet the needs of users.  In some cases (sec-predict), this is
relatively routine, but in other cases, it is more difficult (sec-
unpredict).
Paragraph (version A):
A variety of business models exist for producers of streaming media.
Some content providers derive the majority of the revenue associated
with streaming media directly from consumer subscriptions or one-time
purchases.  Others derive the majority of their streaming media
associated revenue from advertising.  Many content providers derive
income from a mix of these and other sources of funding.  The
inclusion of advertising alongside or interspersed with streaming
media content is therefore common in today's media landscape.
Paragraph (version A):
Some commonly used forms of advertising can introduce potential user
experience issues for a media stream.  This section provides a very
brief overview of a complex and evolving space, but a complete
coverage of the potential issues is out of scope for this document.
Paragraph (version A):
The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can
also be used to enable the dynamic insertion of advertisements
(hereafter referred to as "ads").
Paragraph (version A):
Ads may be inserted either with Client-side Ad Insertion (CSAI) or
Server-side Ad Insertion (SSAI).  In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same
during advertisements, but will include media segments that contain
the advertising.  In SSAI, the media segments may or may not be
sourced from an external ad server like with CSAI.
Paragraph (version A):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) can be
accessed quickly.  The less targeted, the more likely the ad requests
can be consolidated and can leverage the same caching techniques as
the video content.
Paragraph (version B):
The inclusion of advertising alongside or interspersed with streaming
media content is common in today's media landscape.
Paragraph (version B):
Some commonly used forms of advertising can introduce potential user
experience issues for a media stream.  This section provides a very
brief overview of a complex and rapidly evolving space.
Paragraph (version B):
The same techniques used to allow a media player to switch between
renditions of different bitrates at segment or chunk boundaries can
also be used to enable the dynamic insertion of advertisements
(hereafter referred to as "ads"), but this does not mean that the
insertion of ads has no effect on the user's quality of experience.
Paragraph (version B):
Ads may be inserted either with Client-side Ad Insertion (CSAI) or
Server-side Ad Insertion (SSAI).  - In CSAI, the ABR manifest will
generally include links to an external ad server for some segments of
the media stream, while in SSAI the server will remain the same
during advertisements, but will include media segments that contain
the advertising.  - In SSAI, the media segments may or may not be
sourced from an external ad server like with CSAI.
Paragraph (version B):
In general, the more targeted the ad request is, the more requests
the ad service needs to be able to handle concurrently.  If
connectivity is poor to the ad service, this can cause rebuffering
even if the underlying video assets (both content and ads) can be
accessed quickly.  The less targeted the ad request is, the more
likely that ad requests can be consolidated, and that ads can be
cached similarly to the video content.
Paragraph (version A):
This ecosystem balances several competing objectives, and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, either of which can
sometimes result in video stalls.  For another example, since the
inserted ads are often produced independently, they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Paragraph (version B):
This ecosystem balances several competing objectives, and integrating
with it naively can produce surprising user experience results.  For
example, ad server provisioning and/or the bitrate of the ad segments
might be different from that of the main video, and either of these
differences can result in video stalls.  For another example, since
the inserted ads are often produced independently, they might have a
different base volume level than the main video, which can make for a
jarring user experience.
Paragraph (version A):
On top of these competing objectives, this market historically has
had incidents of ad fraud (misreporting of ad delivery to end users
for financial gain) ADFRAUD.  As a mitigation for concerns driven by
those incidents, some SSPs have required the use of specific media
players that include features like reporting of ad delivery, or
providing additional user information that can be used for tracking.
Paragraph (version B):
On top of these competing objectives, this market historically has
had incidents of misreporting of ad delivery to end users for
financial gain ADFRAUD.  As a mitigation for concerns driven by those
incidents, some SSPs have required the use of specific media players
that include features like reporting of ad delivery, or providing
additional user information that can be used for tracking.
Paragraph (version A):
In most real-world operating environments, wireless links can often
experience sudden changes in capacity as the end user device moves
from place to place or encounters new sources of interference.
Microwave ovens, for example, can cause a throughput degradation in
Wi-Fi of more than a factor of 2 while active Micro.  5G and LTE
likewise can easily see rate variation by a factor of 2 or more over
a span of seconds as users move around.
Paragraph (version B):
In most real-world operating environments, wireless links can often
experience sudden changes in capacity as the end user device moves
from place to place or encounters new sources of interference.
Microwave ovens, for example, can cause a throughput degradation in
Wi-Fi of more than a factor of 2 while active Micro.
Paragraph (version A):
"Media" would be something like the output of a codec, or other
media source such as closed-captioning,
Paragraph (version A):
Not all possible streaming media applications follow this model, but
for the ones that do, it seems useful to distinguish between the
protocol layer that is aware it is transporting media, and underlying
protocol layers that are not aware.
Paragraph (version B):
"Media Segments" would be something like the output of a codec, or
some other source of media segments, such as closed-captioning,
Paragraph (version B):
Not all possible streaming media applications follow this model, but
for the ones that do, it seems useful to distinguish between the
protocol layer that is aware it is transporting media segments, and
underlying protocol layers that are not aware.
Paragraph (version A):
Because newly standardized transport protocols such as QUIC RFC9000
can evolve their transport behavior more rapidly than currently-used
transport protocols, we have included a description of how the path
characteristics that streaming media providers may see are likely to
evolve in quic-behavior.
Paragraph (version B):
Because newly standardized transport protocols such as QUIC RFC9000
that are typically implemented in userspace can evolve their
transport behavior more rapidly than currently-used transport
protocols that are typically implemented in operating system kernel
space, this document includes a description of how the path
characteristics that streaming media providers may see are likely to
evolve in quic-behavior.
Paragraph (version A):
The notion of "Circuit Breakers" has also been applied to other UDP
applications in RFC8084, such as tunneling packets over UDP that are
potentially not congestion-controlled (for example, "Encapsulating
MPLS in UDP," as described in RFC7510).  If streaming media is
carried in tunnels encapsulated in UDP, these media streams may
encounter "tripped circuit breakers," with resulting user-visible
impacts.
Paragraph (version B):
The notion of "Circuit Breakers" has also been applied to other UDP
applications in RFC8084, such as tunneling packets over UDP that are
potentially not congestion-controlled (for example, "Encapsulating
MPLS in UDP," as described in RFC7510).  If streaming media segments
are carried in tunnels encapsulated in UDP, these media streams may
encounter "tripped circuit breakers," with resulting user-visible
impacts.
Paragraph (version A):
In this document, we will focus on media encrypted at the transport
layer, whether encrypted hop-by-hop or end-to-end.  Because media
encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport-
layer implications.  Of course, both hop-by-hop and end-to-end
encrypted transport may carry media that is, in addition, encrypted
at the application layer.
Paragraph (version B):
This document focuses on media encrypted at the transport layer,
whether encryption is performed hop-by-hop or end-to-end.  Because
media encrypted at the application layer will only be processed by
application-level entities, this encryption does not have transport-
layer implications.  Of course, both hop-by-hop and end-to-end
encrypted transport may carry media that is, in addition, encrypted
at the application layer.
Paragraph (version A):
From a content provider's perspective, a number of considerations are
in play.  The first question is likely whether the content provider
intends that intermediaries are explicitly addressed from endpoints,
or whether the content provider is willing to allow intermediaries to
"intercept" streaming content transparently, with no awareness or
permission from either endpoint.
Paragraph (version A):
If a content provider does not actively work to avoid interception by
intermediaries, the effect will be indistinguishable from
"impersonation attacks," and endpoints cannot be assumed of any level
of privacy.
Paragraph (version B):
From a media provider's perspective, a number of considerations are
in play.  The first question is likely whether the media provider
intends that intermediaries are explicitly addressed from endpoints,
or whether the media provider is willing to allow intermediaries to
"intercept" streaming content transparently, with no awareness or
permission from either endpoint.
Paragraph (version B):
If a media provider does not actively work to avoid interception by
intermediaries, the effect will be indistinguishable from
"impersonation attacks," and endpoints cannot be assumed of any level
of privacy.
Paragraph (version A):
The choice of whether to involve intermediaries sometimes requires
careful consideration.  As an example, when ABR manifests were
commonly sent unencrypted, some networks would modify manifests
during peak hours by removing high-bitrate renditions to prevent
players from choosing those renditions, thus reducing the overall
bandwidth consumed for delivering these media streams and thereby
improving the network load and the user experience for their
customers.  Now that ubiquitous encryption typically prevents this
kind of modification to maintain the same level of network health and
user experience across networks whose users would have benefited from
this intervention a media streaming operator sometimes needs to
choose between adding intermediaries who are authorized to change the
manifests or adding significant extra complexity to their service.
Paragraph (version B):
The choice of whether to involve intermediaries sometimes requires
careful consideration.  As an example, when ABR manifests were
commonly sent unencrypted, some networks would modify manifests
during peak hours by removing high-bitrate renditions to prevent
players from choosing those renditions, thus reducing the overall
bandwidth consumed for delivering these media streams and thereby
improving the network load and the user experience for their
customers.  Now that ubiquitous encryption typically prevents this
kind of modification, a streaming media provider who used
intermediaries in the past, and who now wishes to maintain the same
level of network health and user experience, must choose between
adding intermediaries who are authorized to change the manifests or
adding some other form of complexity to their service.
Paragraph (version A):
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 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):
However, 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 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 explicitly authorized by the streaming media
provider who is to examine packet payloads, rather than intercepting
packets and examining them without authorization, can continue these
practices.
Paragraph (version A):
Security is an important matter for streaming media applications and
it was briefly touched on in gen-encrypt.  This document itself
introduces no new security issues.
Paragraph (version B):
Security is an important matter for streaming media applications and
the topic of media encryption was explained in stream-encrypt-media.
This document itself introduces no new security issues.