Original text:
2.  Within this document, we use the term "Media Transport Protocol". This is easier to understand if the reader assumes that we are starting with a protocol stack that looks like this:

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:
2. <ins> 2.1. Protocol developers have been considering the implications of the QUIC protocol (RFC9000) for media transport for several years, resulting in a large number of possible meanings of the term "Media Over QUIC", or "MOQ".  As of this writing, "Media Over QUIC" has had at least these meanings: any kind of media carried directly over the QUIC protocol, as a QUIC payload any kind of media carried indirectly over the QUIC protocol, as an RTP payload any kind of media carried indirectly over the QUIC protocol, as an HTTP/3 payload any kind of media carried indirectly over the QUIC protocol, as a WebTransport payload the encapsulation of any Media Transport Protocol (mtp) in a QUIC payload an IETF mailing list (MOQ-ml) "... for discussion of video ingest and distribution protocols that use QUIC as the underlying transport" There may be IETF participants using other meanings as well. As of this writing, the second bullet ("any kind of media carried indirectly over the QUIC protocol, as an RTP payload"), seems to be in scope for the IETF AVTCORE working group, and was discussed at some length at the February 2022 AVTCORE working group meeting AVTCORE-2022-02.  So, perhaps, that possible meaning is out of scope for "Media over QUIC". It will be SUPER HELPFUL if interested parties can come up with a term that unambiguously describes what we're trying to achieve. 2.2. </ins> Within this document, we use the term "Media Transport Protocol". This is easier to understand if the reader assumes that we are starting with a protocol stack that looks like this: