Original text:
4.3.  TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport. <del> 4.4. </del>  Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently. <del> 4.5. </del>  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

Reviewer comments:
Hi, NAME I think this looks mostly fine (it looks like the abstract is a tiny bit garbled, but we can fix stuff like that in an editorial pass). Based on the changed title, I'm assuming that we aren't worrying about SRT and RUSH in this draft - that's probably a good call, because I don't think their requirements are going to look much like RTP over QUIC requirements. There will be some places that I will need to tighten up what I wrote, because they were still in scope when I was typing. I'll merge this, and see where I end up in an hour or two of typing.
I needed a bit more context for this: I'm probably confused by "The protocol". URL says it provides this authentication using TLS 1.3 handshake. Are you thinking of something in addition to the QUIC cryptographic handshake? (Assuming the definition of "Media Transport Protocol" in ), something provided by the Media Transport Protocol level? Or something else?
Something in addition to the QUIC cryptographic handshake (in which I am talking about TLS mutual authentication here, where client presents a valid certificate to server, and verifies the server certificate). Consider: Existing protocols in this space usually offer some "shared secret" of some variety as part of either/or an authentication handshake, and encryption of media: which are just secret values set in the field during connection handshake (see § 6.4) - but note they also support a cert-based approach which more closely matches TLS mutual auth where the Stream ID and user define the authorisation Before RIST Main profile there hasn't been a need for a lot of certificate-based authentication and so existing folk in field would use these types of shared secret patterns, and that having to keep PKI for devices may be problematic. Consider things like encoding hardware deployed in remote locations. Other options could be considered, like using a more SIP-like approach, but we would have to be careful not to bring the rest of the SIP kitchen sink with its round peg that might not fit in the square QUIC slot. I get this requirement presently is a bit flaky in part because the requirements are a bit unclear. Perhaps I put a little more description on the requirement, or remove it from the draft now, and leave it for a "ask later". Thoughts?
NAME I think (1) adding the explanation that this is beyond the authentication mechanism provided by QUIC, and (2) leaving it in the draft, with a note that more detail is needed, and will be added as discussion proceeds, is all that's needed for now.
Closing this as I think it has been addressed, please by all means speak up if we still should do work here.
I THINK what we are doing, is roughly Start with current "Media - Media Transport Protocol", where "Media Transport Protocol" might be RTP Encapsulate in QUIC, to give "Media - Media Transport Protocol - QUIC" If that's right, we should be using "Media Transport Protocol" to describe the first layer under "Media", and what we're doing might better be described as something like "Media Transport Protocol Encapsulation" ("in QUIC"). Whatever we choose, we should be consistent - the Abstract says which would make me believe that we're designing a replacement for existing media transport protocols, but then under "Non-requirements, we have I think that the second quote is correct, so we just need to be clearer in the first quote.
I agree with this, and it should be fixed. Would you like me to clean it up or do you want to roll it in with other changes?
Hi, NAME would it be OK if you did this cleanup? I think adding the picture of the two protocol stacks, in some form, will be super helpful for readers.
I think we can close this as our nomenclature for the document is kind of done now the -00 is out.
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:
4.3. <ins> TODO: Confirm these requirements, consider looking at how RFC 8836 applies to this requirement. 4.4. </ins> TODO: confirm scope of this draft to describe lossless media transport, lossy media transport, or both lossless and lossy transport.  <ins> 4.5. </ins> Media should be able to flow in either direction from client to server or vice-versa, either individually or concurrently.  <ins> 4.6. </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