Code change:
NAME - I think this version is ready for submission as -03, when the submission window reopens during IETF 115. Please let me know what you think.
It would help people contribute to this document if there are blank sections in outline form, and we will be less likely to miss critical stuff.
The IETF 115 proposal to the working group is to use the approved charter as the high level outline for the Requirements section.

Related discussion:
text: player falls behind edge or because the viewer wishes to play back from a point in the past. <del> 4.4. Finally, the "On-Demand" use cases described in this section do not have a tight linkage between ingest and streaming, allowing significant transcoding, processing, insertion of video clips in a news article, etc.  The latency constraints for the use cases in this section may be dominated by the time required for whatever actions are required before media are available for streaming. 4.4.1. Where media is ingested and processed for a system to later serve it to clients as on-demand media.  This media provided from a pre- recorded source, or captured from live output, but in either case, this media is not immediately passed to viewers, but is stored for "on-demand" retrieval, and may be transcoded upon ingest. 4.4.2. Where media is received from a non-live, typically pre-recorded source.  This may feature additional outputs, bitrates, codecs, and media types described in the live media streaming use case. 5. Our proposal is that "Media Over QUIC" discussions focus first on the use cases described in lm-media, which are Live Media Ingest (lmingest), Syndication (lmsynd), and Streaming (lmstream).  Our reasoning for this suggestion follows. Each of the above use cases in overallusecases fit into one of three classifications of solutions. 5.1. The first group, Interactive Media, as described in interact, and covering gaming (gaming), screen sharing (remdesk), and general video conferencing (vidconf), are largely covered by RTP, often in conjunction with WebRTC WebRTC, and related protocols today. Whilst there may be benefit in these use cases having a QUIC based protocol it may be more appropriate given the size of existing deployments to extend the RTP protocols and specifications. 5.2. The second group of classifications, in lm-media, covering Live Media Ingest (lmingest), Live Media Syndication (lmsynd), and Live Media Streaming (lmstream) are likely the use cases that will benefit most from this work. Existing ingest and streaming protocols such as HLS RFC8216 and DASH DASH are reaching limits towards how low they can reduce latency in live streaming and for scenarios where low-bitrate audio streams are used, these protocols add a significant amount of overhead compared to the media bitstream itself. </del> <ins> 4. </ins> <del> For this reason, we suggest that work on "Media Over QUIC" protocols target these use cases at this time. </del> <ins> Our goal in this section is to understand the requirements that result from the use cases described in overallusecases. </ins> <del> 5.3. </del> <ins> *Note: the initial high-level organization for this section is taken from Suhas Nandakumar's presentation, "Progressing MOQ" Prog-MOQ, at the October 2022 MOQ virtual interim meeting, which was in turn taken from the MOQ working group charter MOQ-charter.  We think this is a reasonable starting point.  We won't be surprised to see the high- level structure change a bit as things develop, but we didn't want to have this section COMPLETELY blank when we request working group adoption. </ins> <del> The third group, od-media, covering On-Demand Media Ingest (od- ingest) and On-Demand Media streaming (od-stream) is unlikely to benefit from work in this space.  Without the same "Live Media" latency requirements that would motivate deployment of new protocols, existing protocols such as HLS and DASH are probably "good enough" to meet the needs of these use cases. </del> <ins> 4.1. </ins> <del> This does not mean that existing protocols in this space are perfect. Segmented protocols such as HLS and DASH were developed to overcome the deficiencies of TCP, as used in HTTP/1.1 RFC7230 and HTTP/2 RFC7540, and do not make full use of the possible congestion window along the path from sender to receiver.  Other protocols in this space have their own deficiencies.  For example, RTSP RFC7826 does not have easy ways to add support for new media codecs. </del> <ins> 4.2. </ins> <del> Our expectation is that these use cases will not drive work in the "Media Over QUIC" space, but as new protocols come into being, they may very well be taken up for these use cases as well. </del> <ins> 4.3. </ins> <del> 6. </del> <ins> 4.4. </ins> <del> TODO: Quite a lot, really ... </del> <ins> 4.5. </ins> <del> 7. </del> <ins> 5. </ins> This document makes no requests of IANA. <del> 8. </del> <ins> 6. </ins> As this document is intended to guide discussion and consensus, it introduces no security considerations of its own. <del> 9.  References </del> <ins> 7.  References </ins> <del> 9.1.  URIs </del> <ins> 7.1.  URIs </ins> [1] https://github.com/fiestajetsam/draft-gruessing-moq-requirements