Code change:
2.2. <del> This document describes considerations for work on extensions to existing "Media Transport Protocols" or creation of new "Media Transport Protocols". Within this document, we use the term "Media Transport Protocol" to describe the protocol of interest.  This is easier to understand if the reader assumes that we are talking about a protocol stack that looks something like this: where "Media Format" would be something like RTP payload formats or ISOBMFF ISOBMFF, and "Media Transport Protocol" would be something like RTP or HTTP.  Not all possible proposals for "Media Over QUIC" follow this model, but for the ones that do, it seems useful to have names for "the protocol layers beteern Media and QUIC". It is worth noting explicitly that the "Media Transport Protocol" layer might include more than one protocol.  For example, a new Media Transport Protocol might be defined to run over HTTP, or even over WebTransport and HTTP. 2.3. Within this document, we extend the latency requirement categories for streaming media described in I-D.draft-ietf-mops-streaming- opcons: </del> <ins> }The "Operational Considerations for Streaming Media" document (I- D.draft-ietf-mops-streaming-opcons) described a range of latencies of interest to streaming media providers, as </ins> ultra low-latency (less than 1 second) low-latency live (less than 10 seconds) non-low-latency live (10 seconds to a few minutes) on-demand (hours or more) <del> These latency bands were appropriate for streaming media, which was the target for I-D.draft-ietf-mops-streaming-opcons, but some interactive media may have requirements that are significantly less than "ultra-low latency".  Within this document, we are also using </del> <ins> Because the IETF Media Over QUIC community now expresses interest in interactive media interact and live media lm-media} use cases will have requirements that are significantly less than the "streaming media"-defined "ultra-low latency". Within this document, we are using </ins> near real-time (less than 50 ms) Ull-200 (less than 200 ms) Perhaps obviously, these last two latency bands are the shortened form of "ultra-low latency - 50 ms" and "ultra-low-latency - 200 ms". Perhaps less obviously, bikeshedding on better names and more useful values is welcomed.

Related discussion:
text: Move "considerations" to a separate draft, and do various related cleanup work (for example, removing unneeded references that supported text that has been deleted.
(but document focus is on all media categories, not just live media) (moving the considerations section to its own draft) (moving this diagram to the considerations draft)
Our diagram shows "media transport protocol" as one layer, which can be true, but the text points out that anything running over HTTP/3, or even WebTransport over HTTP/3, will have multiple media transport protocols. It would be helpful for readers if we showed this.
Sports fans of this draft may remember that this section was called Requirements, and true sports fans may remember that the contents had changed very little from when James and I thought this draft would be focused on Interactive use cases - and now it's focused on live media use cases. Rather than go into the BOF with a "Requirements" section that was a natural attraction for protocol designers, and almost completely mistargeted, I provided text for some of the considerations that I could type off the top of my head, before the I-D deadline. The existing list of considerations is not a complete list, and some of the considerations that are described in this section are "To Do", where the first thing To Do is to decide whether that consideration is a consideration for Live Media. To mention one significant example, the discussion about WebTransport doesn't mention one of the biggest advantages - the use of existing CDN infrastructure for live media streaming. But there are other examples - and I may think about this issue, and let other people also provide thoughts here, before I try to resolve the issue with PRs. (tagging the group, so you can be thinking about this as well) NAME NAME NAME NAME NAME
NAME and NAME - It is occurring to me that all the use cases we're recommending in this draft, and all the use cases that are named in , are pointing towards LIVE media. This document is even explaining why we think that's what matters first.