Original text:
Abstract <del> This document describes the uses cases, requirements, and considerations that should guide the design of the encapsulation of a real-time media transport protocol as a payload in the QUIC protocol, that will be used for live media contribution, syndication, and streaming. </del>  Note to Readers

Reviewer comments:
Media over QUIC is just the name of a mailing list and a general area of discussion. In some places, the draft refers to it ambiguously where a read may interpret it as the name of a protocol or working group. Maybe can call out that it is not those things and disambiguate references with "Media over QUIC mailing list" or "Media over QUIC problem space"?
I think the issue (or at least the resolution) is also tied to - the objectionable (or at least the obsolete) text in needs to change, and making the changed text also define all the ways we've used the label "MOQ" seems helpful. Expect a PR that attempts to resolve both.
Streams are equally capable of moving media, though the number of different ways to design a protocol have expanded with the addition of datagrams.
Absolutely. It might be worth mentioning that QUIC datagrams in their current state have caveats. They are congestion controlled, elicit acknowledgements, and these acknowledgements . QUIC datagrams certainly have their benefits, but protocols need to be designed to use them properly. Otherwise SRTP and DTLS might be better options.
This term may imply latency constraints that may not exist in all use cases. Further, I wonder if the framing as 'encapsulation of a media transport protocol as a payload' jives with what Victor mentioned during our call -- that part of what's interesting is using QUIC as a transport protocol.
NAME - two things (one each, for your two excellent points): this draft started out as a survey of what was being described as "Media Over QUIC" last summer (after the IETF 111 side meeting), then lurched downhill to being focused on RTP over QUIC, and then lurched BACK uphill, but not all the way uphill, to focusing on a subset of what's been proposed under the banner of "MOQ". Thanks for helping us spot places in the draft that haven't completed the trek! Agreed about reframing the framing, and if we suck any of the other use cases in - there was a lot of discussion around needing help with gaming for sub-100 ms latencies at the IETF 112 side meeting, so that might happen - the current framing might be even less helpful. Definitely worth fixing. Expect a PR soon.
I've been using the phrase "live media", defining it as "media that is actively being produced and consumed". It's not perfect but neither is drawing a numeric latency number in the sand.
NAME - just so that I understand (better) - are you saying that the media is being consumed at (roughly) the rate it's being produced? Any answer is fine, I just want to make sure I know what we're talking about here.
We have been talking about "Media Over QUIC" as a broad term that would include any media transport protocol running over QUIC, which (apparently) would include RTP over QUIC SRP over QUIC RUSH, which runs over QUIC If we are doing "Media over QUIC", all of these (and potentially others) would be in scope. If the scope of this document is "Media over RTP over QUIC", that would be fine, but we should say that. Thoughts?
I think we've fixed this one - I'll close it for now.

Revised text:
Abstract  <ins> This document describes the use cases that have been discussed in the IETF community under the banner of "Media Over QUIC", and recommends use cases on live media contribution, syndication, and streaming as the basis for discussions that should guide the design of protocols to satisfy these use cases. </ins> Note to Readers