Original text:
the set of network path properties. It is worth pointing out explicitly because questions about "Web <del> Real-Time Communication (WebRTC)" has 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. </del>  1.2. 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 <del> carry the encoded video at some point in the future. </del>  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 <del> bitrates, as described in adapt-deliver. </del>  In order to provide multiple encodings for video resources, the codec must produce multiple versions of the video resource encoded transmission, so the transport protocol cannot probe for available path bandwidth <del> 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. </del>  To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck, there

Reviewer comments:
NAME - I went back through -11 and made sure we had at least tried to address each of your comments. Thank you for the careful read.
From NAME
NAME 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.
NAME and NAME - NAME 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 haven'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 aren't all talking about the same thing, so that needs to be fixed ...
NAME and NAME - 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".
NAME and NAME - NAME 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 Bob. I now wish I could recall which meeting, or even which year I saw this. I don'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: URL URL Maybe we should strike the claim if we can't find a good source for it--these 5g 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.
NAME - 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 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., which I don'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.
NAME on this comment, (as an aside, I should mention that I don'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 couldn'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.

Revised text:
the set of network path properties. It is worth pointing out explicitly because questions about "Web  <ins> Real-Time Communication (WebRTC)" has come up often, that RTP, WebRTC's principal media transport protocol (RFC8834, RFC8835), is mentioned in this document.  However, (as noted in sd) it is difficult to give general guidance for unreliable media transport protocols used to carry interactive real-time media. </ins> 1.2. 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  <ins> carry the encoded video at some point in the future.  It is common for codecs to offer a small number of resource variants, differing only in the bandwidth each variant targets. </ins> 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  <ins> bitrates, at the cost of lower video quality, as described in adapt-deliver. </ins> In order to provide multiple encodings for video resources, the codec must produce multiple versions of the video resource encoded transmission, so the transport protocol cannot probe for available path bandwidth  <ins> by sending at a higher rate until the media receiver requests segments that buffer enough data for the transport to perform the probing. </ins> To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck, there