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: If we renamed the document as "Live Media Over QUIC", it would be more accurate, and the BOF proponents could point to this draft and ask people with other use cases if their use cases overlap with the live media use cases, perhaps allowing the BOF to recommend doing the live media use cases in this draft, and inviting people to provide comments on this draft explaining their use cases, so the IESG would know what to do with them. Your thoughts?
I don't object to the name change but I don't feel strongly.
That name works for me too.
We should revisit after the BOF, when we know what the scope of the document will be. :sunglasses:
So, this is slightly more complicated than I had hoped. The use cases in the draft span "Media Over QUIC". The considerations (and, if we get that far, requirements) in the draft only cover "LIVE Media Over QUIC". So, let's leave this one open, until we find out the right thing to do, and then we can Do The Right Thing. :innocent:
I would propose we rename (again) to "Media over QUIC Use Cases and Requirements", for a few reasons: Scope of use cases that the WG will work on isn't yet settled, and it's likely that we may need to cover some (but not all) interactive use cases as well as hybrid interactive/live. I still think we should set the protocol requirements in the document - this frees up the charter to describe scope and milestone, and our draft (if WG adopted) to set the use cases and what we will require of the deliverables. If WG adopted, the details of what is in and out can be made via WG consensus. This follows a similar title format to and other documents like it. NAME thoughts?