Change:
adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection. <del> Many server-player systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </del> <ins> Many systems will do an initial probe or a very simple throughput speed test at the start of a video playback.  This is done to get a rough sense of the highest video bitrate in the ABR ladder that the network between the server and player will likely be able to provide under initial network conditions.  After the initial testing, clients tend to rely upon passive network observations and will make use of player side statistics such as buffer fill rates to monitor and respond to changing network conditions. </ins> <del> The choice of bitrate occurs within the context of optimizing for some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </del> <ins> The choice of bitrate occurs within the context of optimizing for one or more metrics monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering event (playback stall). </ins> 5.4.

Discussion:
From NAME Same comment as for section 1, "networking issues" actually means something broader than the plain layer-3. Suggest introducing the shortcut in the terminology part of section 1, e.g., "this document uses the wording networking issues to represent the conjunction of IP and transport layers" ?
Hi, NAME I thought this might be a quick addition of an umbrella definition of "networking" to include transport protocols, but a significant chunk of the text was distinguishing between network and transport protocols, so I added "and transport protocols" to the few occurrences of "networking" that were intended to include both.
Thank you, NAME , this is more work for the authors but less ambiguous for the readers.
From NAME Unsure whether "server-player systems" is well understood by the readers. Nit: "some metric monitored by the client" should the plural form be used ?
I dont think we made the exercise of going thru all the mixed-up terms like clients vs. players in the text. One simple solution is to do the following: (streaming) client: the part of the (media) player that deals with the transmission/reception and buffer related matters. (media) player: on top of the streaming client, this includes the media decoders, UI, user controls, DRM, authentication modules, etc.
"many systems" -
From NAME " Know Your Network Traffic" what is "your" in this section ? My network used by other parties (server and consumer) to transfer streaming video ? My network as the servers, layer-3, and consumers are all in my administrative domain? Suggest removing the 'your'
Knowing expected traffic and traffic growth baselines before something goes wrong.
From NAME While I am not an expert, I am surprised by the acceptable latency numbers, I would have written 100 msec for videoconference and "couple of seconds" for streaming live events. Video streaming (netflix like) is indeed several seconds. But, I am trusting the authors on their statement. Section 4.2 explains a little more those numbers so a forward reference to section 4 would be beneficial.

On-list discussion so far concluded that we are best off leaving it alone, with no dissent yet: URL
I've raised this issue a few times, but suspect that the right answer is to Don't change any of the numbers in this document, Recognize that latency goals are falling year by year, and Wait until we better understand the thinking in MOQ discussions about the latency requirements for live media streaming and other forms of media handling to revisit this The likely improvements from continued discussions about latency categories aren't worth holding up this document.
Up to the authors, really, but suggest to add some text about those numbers are in flux ?
Yeah, that sounds like a good idea. Some clarifying context in the section 4 header where these numbers appear might help avoid some confusion.
NAME - that sounds like a win to me. My goal was to NOT say something like "these numbers are old and inaccurate, so good luck!"
We agree with the suggestion for forward reference to Section 4.
LGTM Hi, Jake, Holland, Jake wrote: specifically about the 1 second for videoconferencing, which is clearly wrong, because we've known that people accidentally talk over other people when latencies are more than 200 ms for decades, but it's probably not wrong enough to be worth talking about changing it. Honestly, if this document is about Operational Considerations for Streaming Media, anyone reading it for guidance about videoconferencing probably has bigger problems than the latency categories. I think we're through discussing that part, at least for now. Best, Spencer