Code change:
This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.

Related discussion:
text: source.  This may feature additional outputs, bitrates, codecs, and media types described in the live media streaming use case. <del> 4.9. The use cases that are most applicable today given the existing and known future capabilities of QUIC are included in this section. *Editor Note:* this section is a work in progress, and is based on the opinions of the draft authors.  We are happy to be guided by discussion about other use cases. 4.9.1. Unidirectional live stream contribution.  Two immediate scenarios that best describe this is firstly users on a streaming platform in a remote scenario from their phone live streaming an event or going on to an audience in real time in relatively low bitrates (~1-5Mbit). The second scenario is larger bitrate contribution feeds in broadcast.  This can be an OB feed "back to base" into playout gallery, or from playout facilities to online distribution platforms. 4.9.2. While a media is being contributed in real time via an ingest point to a streaming platform, there may be a need to distribute the media between several servers and/or perform a load balancing of the incoming traffic.  The platform may peform transcoding at one or several points, or distribute (route) the media as is to one or many egress points.  Such a distribution and load balancing may happen with or without the access to the encrypted payload. </del> <ins> 5. </ins> <del> 4.9.3. </del> <ins> This section is a work in progress, and is based on the opinions of the draft authors.  We are happy to be guided by discussion about other use cases. Each of the above use cases fit into three classifications of solutions, with the first three covering gaming, screen sharing, and general video conferencing largely covered by 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 WebRTC protocol and specifications.  Such work could start in a QUIC specific forum, but would likely need to take place in rtcweb and the W3C. The second group of classifications covering Live Media Contribution, Syndication, and Streaming are likely the use cases likely to benefit most from this work.  Existing protocols used 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 add a significant amount of overheads compared to the media bitstream. </ins> <del> Distribution from platform to audience.  Whilst use of WebRTC or RTSP today for On-Demand media streaming is not typical with adaptive streaming like HLS and DASH being predominantly used as WebRTC is more applicable in latency sensitive contexts such as live sporting events.  Instead use cases where there is live streaming of TV linear output, or live streaming such as Twitch or Facebook, or non-UGC services like OTT offerings made by broadcasters. </del> <ins> On-Demand media streaming is unlikely to benefit from work in this space, without notable latency requirements and protocols such as HLS and DASH meeting the needs of this use case.  However larger deployments may benefit from the use of HTTP/3 I-D.draft-ietf-quic- http. </ins> <del> 5. </del> <ins> 6. </ins> Even a cursory examination of the existing proposals listed in priorart shows that there are fundamental differences in the <del> approaches being used - for instance, whether a proposal uses RTP as its Media Transport Protocol. In this section, we attempt to focus on high-level requirements for real time media streaming over a QUIC connection, recognizing that additional analysis will be required, and we are starting with requirements that are apparent for RTP-based proposals </del> <ins> approaches being used. </ins> <del> 5.1. </del> <ins> 6.1. </ins> When initiating a media session, both the sender and receiver should <del> be able to negotiate the codecs, bitrates and other media details based on capabilities and preferences.  It may be prefered to use </del> <ins> be able to negotiate the codecs, bitrates, resolution, and other media details based on capabilities and preferences.  This must be negotiable both before commencing playback but also during as a result of changes to device output or network conditions (such as reduction in available network bandwidth).  It may be prefered to use </ins> existing ecosystem for such purposes, e.g.  SDP RFC4566. <del> 5.2. TODO: confirm requirements for latency </del> <ins> 6.2. </ins> I-D.draft-ietf-mops-streaming-opcons describes these latency <del> requirements for streaming media. </del> <ins> requirements for streaming media: </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> 5.3. </del> <ins> Support for a nominal latency in the low to ultra-low latency should be achieved, with consideration for minimum buffer a receiver playing content may need to handle congestion, packet loss, and other degradation in network quality. 6.3. Handling of migration of a session between hosts, either of sender or receiver should be supported.  This may either happen because the sender is undergoing maintenence or a rebalancing of resource, because the either is experiencing a change in network connectivity (such as a device moving from WiFi to cellular connectivity) or other reasons. This may depend on QUIC capabilities such as I-D.draft-ietf-quic- multipath but is by no means a hard requirement. 6.4. </ins> TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement. <del> 5.4. </del> <ins> 6.5. </ins> TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport. <del> 5.5. </del> <ins> 6.6. </ins> Media should be able to flow in either direction from client to <del> server or vice-versa, either individually or concurrently. </del> <ins> server or vice-versa, either individually or concurrently but should only be negotiated at the start of the session. </ins> <del> 5.6. </del> <ins> 6.7. </ins> TODO: Unsure if this should be a requirement.  If it is, we have to consider two things: WebTransport supports HTTP/2, are we going to