jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-mops-streaming-opcons

Commentary: From 
 - thank you for this review . You caught a lot more things than I was hoping were still in there . : grinning : 
 PR should address these issues ( and more ) . 
 Agree with that this fixed lots of stuff . I 'd like to leave it open so we can run this tool again after addressing more issues .
Paragraph (version A):
This level of latency is targeted to have a user experience similar
to traditional broadcast TV delivery.  A frequently cited problem
with failing to achieve this level of latency for live sporting
events is the user experience failure from having crowds within
earshot of one another who react audibly to an important play, or
from users who learn of an event in the match via some other channel,
for example, social media, before it has happened on the screen
showing the sporting event.
Paragraph (version B):
This level of latency is targeted to have a user experience similar
to broadcast TV delivery.  A frequently cited problem with failing to
achieve this level of latency for live sporting events is the user
experience failure from having crowds within earshot of one another
who react audibly to an important play, or from users who learn of an
event in the match via some other channel, for example, social media,
before it has happened on the screen showing the sporting event.
Paragraph (version A):
Non-low-latency live delivery of media is defined here as a live
stream that does not have a latency target shorter than 10 seconds.
Paragraph (version B):
Non-low-latency live delivery of media is defined here as a
livestream that does not have a latency target shorter than 10
seconds.
Draft: draft-ietf-mops-streaming-opcons

Commentary: From - 
 - after thinking about this comment , I think two things need to happen - your observation about bottlenecks at different nodes / hops / layers of the protocol stack belongs at the beginning of this section , because we 're drilling down on ONE layer of the protocol stack in the rest of section 3.2 , and as you say , the reference to " link " is not helpful here . Please let me know if is responsive to this comment .
Paragraph (version B):
Even when the bandwidth requirements for video streams along a path
are well understood, additional analysis is required to understand
the constraints on bandwidth at various points along the path between
media servers and media players.  Video streams can encounter
bottlenecks at many points along a path, whether the bottleneck
happens at a node or at a path segment along the path, and these
bottlenecks may involve a lack of processing power, buffering
capacity, link speed, or any other exhaustible resource.
Paragraph (version A):
the transport protocol detects loss due to congestion and reduces
its sending window size per round trip,
Paragraph (version B):
the transport protocol may detect loss due to congestion and
reduce its sending window size per round trip,
Paragraph (version A):
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 B):
To avoid these types of situations, which can potentially affect all
the users whose streaming media segments traverse a bottleneck path
segment, 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.
Draft: draft-ietf-mops-streaming-opcons

Commentary: Closed with acks as of 2022 - 07 - 20
Paragraph (version A):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,
Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan
Krishna, Roni Even, Sanjay Mishra, Tommy Pauly, and Will Law for very
helpful suggestions, reviews and comments.
Paragraph (version B):
Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran,
Eric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar,
Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Renan
Krishna, Roni Even, Sanjay Mishra, Kiran Makhjani, Chris Lemmons,
Tommy Pauly, Will Law, Michael Scharf, Eric Vyncke, Erik Kline, Roman
Danyliw, Valery Smyslov, Robert Wilton, Lars Eggert, Zahed Sarker,
Warren Kumari, John Scudder, Martin Duke, and Nancy Cam-Winget for
very helpful suggestions, reviews and comments.
Draft: draft-ietf-mops-streaming-opcons

Commentary: lgtm 
 From 
 Done , except that 4960bis has now popped out as RFC9260 . For these next two comments - our responses to reviews from and especially in dropping a lot of the archeology text about TCP , focusing on transport services , and working to make sure we are comparing apples to apples ( 2022 TCP to 2022 QUIC ) , have significantly improved the document throughout Section 6 . The new discussion of " typically implemented in a kernel , although it does n't have to be " and " typically implemented in userspace , although it does n't have to be " is also intended to be more even - handed than the original text . I 'm still following up on a couple of things with and but -11 will be significantly better , thanks to the review teams .
Paragraph (version A):
Various HTTP versions have been used for media delivery.  HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport
behavior is described in reliable-behavior.  HTTP/3 is carried over
QUIC, and QUIC's transport behavior is described in quic-behavior.
Paragraph (version B):
Various HTTP versions have been used for media delivery.  HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP I-D.ietf-tcpm-rfc793bis, and
TCP's transport behavior is described in reliable-behavior.  HTTP/3
is carried over QUIC, and QUIC's transport behavior is described in
quic-behavior.
Draft: draft-ietf-mops-streaming-opcons

Commentary: Check against new main version for duplication on scope . 
 Discussion from editor 's conference call : find a better place to put description of WebRTC ( now that we have a good scope section ) . 
 From 
 - please see what you think of the new location for the mention of WebRTC . 
 Sure , this seems fine .
Paragraph (version A):
A full review of all streaming media considerations is too wide a
topic to cover comprehensively in a single document.
Paragraph (version B):
A full review of all streaming media considerations is too broad a
topic to cover comprehensively in a single document.
Paragraph (version B):
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 A):
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The fill process needs to be at least fast enough to ensure
that the buffer is never empty, however, it also can have significant
complexity when things like personalization or ad workflows are
introduced.
Paragraph (version B):
A simple model of video playback can be described as a video stream
consumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the
content bitrate.  The size of the buffer is also commonly a fixed
size.  The fill process needs to be at least fast enough to ensure
that the buffer is never empty, however, it also can have significant
complexity when things like personalization or advertising insertion
workflows are introduced.
Draft: draft-ietf-mops-streaming-opcons

Commentary: From Section 3.2.1 says , " There are many reasons why path characteristics might change suddenly ... " . It may be good to mention MTU changes as part of the path changes , since changes in the maximum packet sizes supported by paths can be disruptive to traffic ( requiring new PMTUD , etc ) . 
 FWIW , I agree with this . I may try to think of others that we should also add .
Paragraph (version A):
There are many reasons why path characteristics might change
suddenly, for example,
Paragraph (version A):
"cross traffic" that traverses part of the path, especially if
this traffic is "inelastic", and does not, itself, respond to
indications of path congestion.
Paragraph (version A):
routing changes, which can happen in normal operation, especially
if the new path now includes path segments that are more heavily
loaded, offer lower total bandwidth, or simply cover more
distance.
Paragraph (version B):
If the path topology changes.  For example, routing changes, which
can happen in normal operation, may result in traffic being
carried over a new path topology that that is partially or
entirely disjoint from the previous path, especially if the new
path topology includes one or more path segments that are more
heavily loaded, offer lower total bandwidth, change the overall
Path MTU size, or simply cover more distance between the path
endpoints.
Paragraph (version B):
If "cross traffic" that also traverses part or all of the same
path topology increases or decreases, especially if this new
"cross traffic" is "inelastic", and does not, itself, respond to
indications of path congestion.
Draft: draft-ietf-mops-streaming-opcons

Commentary: LGTM - and my comment is the same length as the change itself , so I 'm merging now ...
Paragraph (version A):
At the IXP-level, it was observed that port utilization increased.
This phenomenon could probably be explained by a higher level of
uncacheable traffic such as videoconferencing and VPNs from
residential users as they stopped commuting and switched to work-
at-home.
Paragraph (version B):
At the IXP level, it was observed that physical link utilization
increased.  This phenomenon could probably be explained by a
higher level of uncacheable traffic such as videoconferencing and
VPNs from residential users as they stopped commuting and switched
to work-at-home.
Draft: draft-ietf-mops-streaming-opcons

Commentary: I think this is the right thing to do . Merging now .
Paragraph (version A):
As the Internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  Estimates put the total
share of Internet video traffic at 75% in 2019, expected to grow to
82% by 2022.  This estimate projects the gross volume of video
traffic will more than double during this time, based on a compound
annual growth rate continuing at 34% (from Appendix D of CVNI).
Paragraph (version B):
As the internet has grown, an increasingly large share of the traffic
delivered to end users has become video.  The most recent available
estimates found that 75% of the total traffic to end users was video
in 2019.  At that time, the share of traffic that was video had been
growing for years and was projected to continue growing (Appendix D
of CVNI).
Draft: draft-ietf-mops-streaming-opcons

Commentary: … astructure 
 Looks good to me . I 've been through the doc looking at occurrences of " cach " , " prox " , and " CDN " , and they all looked fine to me .
Paragraph (version A):
HTTP can make use of already-deployed caching infrastructure.
Paragraph (version B):
HTTP can make use of already-deployed caching infrastructure such
as CDNs (Content Delivery Networks), local proxies, and browser
caches.
Draft: draft-ietf-mops-streaming-opcons

Commentary: … seemed more well covered in 8824 than in 8825 . ) 
 IGTM ! 
 From Last paragraph , while I understand why some mobile providers wants " to lower quality " it would be easier for the reader to understand if the text said " in order to reduce the bandwidth on expensive links , some operators want to lower the quality " . 
 Describe how editing manifests lowers the bandwidth requirements .
Paragraph (version A):
If a content provider chooses not to involve intermediaries, this
choice should be carefully considered.  As an example, if media
manifests are encrypted end-to-end, network providers who had been
able to lower offered quality and reduce on their networks will no
longer be able to do that.  Some resources that might inform this
consideration are in RFC8825 (for WebRTC) and I-D.ietf-quic-
manageability (for HTTP/3 and QUIC).
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 in order 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, in order to maintain the same level of network
health and user experience across networks whose users would have
benefitted 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):
Some resources that might inform other similar considerations are
further discussed in RFC8824 (for WebRTC) and I-D.ietf-quic-
manageability (for HTTP/3 and QUIC).
Draft: draft-ietf-mops-streaming-opcons

Commentary: From Authors may also want to refer to drafts about the same considerations ( i.e. , end - to - end crypto hindering operations ) . 
 Agree , will reference ( was draft - ietf - tsvwg - transport - encrypt ) Considerations around Transport Header Confidentiality , Network Operations , and the Evolution of Internet Transport Protocols
Paragraph (version A):
More broadly, I-D.ietf-quic-manageability discusses manageability of
the QUIC transport protocol, focusing on the implications of QUIC's
design and wire image on network operations involving QUIC traffic.
It discusses what network operators can consider in some detail.
Paragraph (version B):
I-D.ietf-quic-manageability discusses manageability of the QUIC
transport protocol that is used to encapsulate HTTP/3, focusing on
the implications of QUIC's design and wire image on network
operations involving QUIC traffic.  It discusses what network
operators can consider in some detail.
Paragraph (version B):
More broadly, RFC 9065 RFC9065, "Considerations around Transport
Header Confidentiality, Network Operations, and the Evolution of
Internet Transport Protocols" describes the impact of increased
encryption of transport headers in general terms.
Draft: draft-ietf-mops-streaming-opcons

Commentary: From Based on the title it is unclear whether this section also covers " app layer encryption " , I guess no but this should be made clear ( perhaps high in section 7 by stating that this doc does not cover app layer encryption ) . 
 This paragraph appears later in the document - I can move this up under the bullet points and make that clearer . 
 Fixed as in my previous comment . 
 BTW , unsure how the authors want me to mark " I have read the change and I like it " ? Currently , simply using a " thum up " emoticon on the solution comment . Let me know if you prefer another marking . 
 If I ca n't hear you either giggling or screaming all the way to Texas , and I see a " thumbs up " emoticon , that 's clear enough to me ! 
 LGTM
Paragraph (version A):
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):
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 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.
Draft: draft-ietf-mops-streaming-opcons

Commentary: LGTM 
 From The very first sentence is mostly unparseable due to its length ( 7 lines ) . Please consider splitting it . 
 I this , from review : This section and the next one should be a list with 2 bullets rather than 2 sections to make the text more readable .
Paragraph (version A):
In addition to measurements media players use to guide their segment-
by-segment adaptive streaming requests, streaming media providers may
also rely on measurements collected from media players to provide
analytics that can be used for decisions such as whether the adaptive
encoding bitrates in use are the best ones to provide to media
players, or whether current media content caching is providing the
best experience for viewers.  To that effect, the Consumer Technology
Association (CTA) who owns the Web Application Video Ecosystem (WAVE)
project has published two important specifications.
Paragraph (version B):
Media players use measurements to guide their segment-by-segment
adaptive streaming requests, but may also provide measurements to
streaming media providers.
Paragraph (version B):
In turn, providers may base analytics on these measurements, to guide
decisions such as whether adaptive encoding bitrates in use are the
best ones to provide to media players, or whether current media
content caching is providing the best experience for viewers.
Paragraph (version B):
To that effect, the Consumer Technology Association (CTA) who owns
the Web Application Video Ecosystem (WAVE) project has published two
important specifications.
Draft: draft-ietf-mops-streaming-opcons

Commentary: From Unsure whether the end part of this section is relevant to the document as it is rather anecdotical . 
 We should explain the impact on the Internet , the IETF , and regulatory agencies from the BitTorrent experience . 
 Working session discussion : yes this is anecdotal , but is a worthwhile example to keep because it adds a concrete example to the abstract notion of unpredictable traffic and its impacts . We think the right response is to add a paragraph to this anecdote explaining the ultimate impact to the internet that this example of unpredictable traffic had as a conclusion to explain how the experiences from unpredictable traffic can cause large and sudden shifts in network operational practice . 
 - I agree . I suspect that the number of people who remember the impact of Comcast attending to " manage " BitTorrent on residential networks is declining every year , but it was horrendous at the time . We should make it clear that you do n't have to have a hurricane to end up with sudden and massive spikes in network traffic that you never planned for . 
 I teach this every year to keep the new generation aware of some of the non - sense stuff their elder brothers ( or sisters ) had to put up with . It was not just  , I can name 5 other names based on my own testing at that time . 
 I like the last paragraph of the PR ;-) Thanks 
 LGTM
Paragraph (version A):
The combination of the large volume of "torrents" and the peer-to-
peer characteristic of swarm transfers meant that end user hosts were
suddenly uploading higher volumes of traffic to more destinations
than was the case before Bittorrent.  This caused at least one large
internet service provider (ISP) to attempt to "throttle" these
transfers in order to to mitigate the load that these hosts placed on
their network.  These efforts were met by increased use of encryption
in Bittorrent, similar to an arms race, and set off discussions about
"Net Neutrality" and calls for regulatory action.
Paragraph (version B):
The combination of the large volume of "torrents" and the peer-to-
peer characteristic of swarm transfers meant that end user hosts were
suddenly uploading higher volumes of traffic to more destinations
than was the case before Bittorrent.  This caused at least one large
internet service provider (ISP) to attempt to "throttle" these
transfers in order to to mitigate the load that these hosts placed on
their network.  These efforts were met by increased use of encryption
in Bittorrent, and complaints to regulators calling for regulatory
action.
Paragraph (version B):
The BitTorrent case study is just one example, but the example is
included here to make it clear that unpredicted and unpredictable
massive traffic spikes may not be the result of natural disasters,
but they can still have significant impacts.
Draft: draft-ietf-mops-streaming-opcons

Commentary: From " reliable media using HTTP over TCP , " should MOQ be cited here ? or HTTP/3 over QUIC ? 
 - Thanks for catching this . The relevant point here is that HTTP is carried over reliable transport protocols . The behavior of specific transport protocols is described in subsections of Section 6 . I 've clarified that in Section 2 .
Paragraph (version B):
Various HTTP versions have been used for media delivery.  HTTP/1.0,
HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport
behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC,
and QUIC's transport behavior is described in quic-behavior.
Draft: draft-ietf-mops-streaming-opcons

Commentary: I do n't remember where this suggestion came from , but it was on the list in the 107 interim slides , so I figured it should be tracked : 
 Maybe refer to Cisco VNI ? 
 Cisco VNI link is already a 404 , so ... Checking with RFC Editor to see whether they can handle SVG yet . 
 The point of this is trying to show internet scale growth of video traffic over time , both by proportion and by gross volume , not really about including pictures . This maybe is already covered by our intro paragraph : " Estimates put the total share of internet video traffic at 75 % in 2019 , expected to grow to 82 % by 2022 . This estimate projects the gross volume of video traffic will more than double during this time , based on a compound annual growth rate continuing at 34 % ( from Appendix D of [ CVNI ] ) . " We should consider just closing this issue . 
 Related point ( perhaps a new issue ? ): this info may stop being available -- prior reports often came from DPI at IXPs or similar to monitor traffic , but since the dawn of ubiquitous encryption this info will stop being available , and we 'll ( probably ? ) only have reports from servers . 
 We 're thinking this is Wo n't Fix - at a minimum , this is n't information we can update in the future . 
 Pulled these out of the text of the draft as part of this issue , from the bottom of section " 2.4 Predictable Usage Profiles " : TBD : insert charts showing historical relative data usage patterns with error bars by time of day in consumer networks ? TBD : Cross - ref vs. video quality by time of day in practice for some case study ? Not sure if there 's a good way to capture a generalized insight here , but it seems worth making the point that demand projections can be used to help with e.g. power consumption with routing architectures that provide for modular scalability .
Paragraph (version A):
TBD: insert charts showing historical relative data usage patterns
with error bars by time of day in consumer networks?
Paragraph (version A):
TBD: Cross-ref vs. video quality by time of day in practice for some
case study?  Not sure if there's a good way to capture a generalized
insight here, but it seems worth making the point that demand
projections can be used to help with e.g. power consumption with
routing architectures that provide for modular scalability.