Change:
5.5. This kind of bandwidth-measurement system can experience trouble in <del> several ways that are affected by networking issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </del> <ins> several ways that are affected by networking and transport protocol issues.  Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-level protocol behaviors that can produce surprising measurement values when the application-level feedback loop is interacting with a transport-level feedback loop. </ins> A few specific examples of surprising phenomena that affect bitrate detection measurements are described in the following subsections.

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