Original text:
This document specifically focuses on streaming applications and defines streaming as follows: <del> Streaming is the transmission of continuous media from a server to </del>  a client and its simultaneous consumption by the client. <del> Here, "continuous media" refers to media and associated streams </del>  such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous," as it is not considered streaming if one downloads a media file and plays it after the download is different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption <del> may be used to prevent media steam manipulation or to protect </del>  manifests. This document does not take a position on whether those goals are

Reviewer comments:
NAME and NAME - note that John's last comment hasn't been addressed in this PR yet.
Added a single comment for the subsequent sentence where you made a change.
NAME and NAME - Most of John's comments are nits and easy to resolve, but there are two that need thought. First, this comment So, let's think about this. We're looking at two, related statements, I'm wondering if it is correct to say Streaming is continuous transmission of media from a server to a client and its simultaneous consumption by the client. I'll make that change, and see if anyone objects. Second, this comment (followed by some excellent guesses about recourse) I read this text as saying that your streaming service is less complex if you have an intermediary that is modifying manifests during peak hours, than if you add that functionality to media servers that are already complex, especially if intermediaries are making a few well-understood changes to the manifests that only need to work for media players downstream on a given path, while a media server would have to maintain multiple versions of the manifests that that, in total, cover every possible modification that any intermediary would have done, and then figure out how to send each media player the appropriate version of the manifest for that media player. If that's what other people think, we can say that. If it's not what other people think, we need to talk.
The first one works for me ("Streaming is a continuous transmission of media"). For the second, yes, that was my intent. It is possible to deliver different manifests to different clients. Doing so based on some kind of aggregated estimate of the path load (possibly including peak hours/time of day, etc.) can do roughly the same job of reducing network load that was previously done with on-path edits to unencrypted manifests, but it adds a lot of complexity to the media service, which was previously instead taken on by (some of) the networks with a problem.
lgtm

Revised text:
This document specifically focuses on streaming applications and defines streaming as follows:  <ins> Streaming is the continuous transmission of media from a server to </ins> a client and its simultaneous consumption by the client.  <ins> Here, "media" refers to any type of media and associated streams </ins> such as video, audio, metadata, etc.  In this definition, the critical term is "simultaneous," as it is not considered streaming if one downloads a media file and plays it after the download is different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption  <ins> may be used to prevent media stream manipulation or to protect </ins> manifests. This document does not take a position on whether those goals are