Code change:
6.1. <ins> Within sec-trans, the term "Media Transport Protocol" is used to describe to describe the protocol of interest.  This is easier to understand if the reader assumes a protocol stack that looks something like this: where "Media Format" would be something like an RTP payload format RFC2736 or ISOBMFF ISOBMFF, "Media Transport Protocol" would be something like RTP or HTTP, and "Transport Protocol" would be something like TCP or UDP. Not all possible streaming media applications follow this model, but for the ones that do, it seems useful to have names for the protocol layers between Media Format and Transport Layer It is worth noting explicitly that the Media Transport Protocol and Transport Protocol layers might each include more than one protocol. For example, a Media Transport Protocol might run over HTTP, or over WebTransport, which in turn runs over HTTP. It is worth noting explicitly that more complex network protocol stacks are certainly possible - for instance, packets with this protocol stack may be carried in a tunnel, or in a VPN.  If these environments are present, streaming media operators may need to analyze their effects on applications as well. 6.2. </ins> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application

Related discussion:
text: NAME - several things here. we probably don't need all of the descriptive text - the idea is that we'd say "assume roughly this protocol stack, and here's what's not included" if distinguishing between "transport protocol" and "media transport protocol" makes sense, that probably needs to be reflected elsewhere in the document (like, a lot of elsewheres) If this approach works, it could either be in the transport protocol section, or in the one you're thinking of for
I don't think there will be a lot of places. We need to pay attention to only the places where we are explicitly referring to the media transport protocol. The rest can stay the same IMO.
NAME - I couldn't reply to this inline, but I looked through the document (searching for "transport protocol", and you're right. I found one place in Section 4.1, and changed the description of RTP as a transport protocol to RTP as a media transport protocol. NAME - Section 4.1 is before where my explanation is now - if this PR makes sense to you, the explanation probably DOES belong much earlier in the doc, perhaps in .
I'm merging this, based on Ali's review.
We want a paragraph to say something about scope along the lines of: This document is for endpoints delivering streaming media traffic. This can include intermediaries like CDNs as well as content owners and end users, plus their device and player providers. We think this can help address a few issues from last call/iesg review, including: (more to be linked as we notice them)
Consider adding a subsection in the introduction about things that are out of scope, and (for extra credit), why they are out of scope.
from NAME 's review (URL) Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.)
Not sure if this is really about scope clarification? I think this section is intending to talk about usage as part of a transport protocol, but tunnels are sort of more like a path overlay issue or something (might affect mtu, extra hops with extra things that can go wrong, etc.).