Draft: draft-ietf-mops-streaming-opcons

Commentary: and - note that  's last comment has n't been addressed in this PR yet . 
 Added a single comment for the subsequent sentence where you made a change . 
 and - Most of  '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
Paragraph (version A):
Streaming is the transmission of continuous media from a server to
a client and its simultaneous consumption by the client.
Paragraph (version A):
Here, "continuous media" refers to media and associated streams
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
completed, which would be called download-and-play.
Paragraph (version B):
Streaming is the continuous transmission of media from a server to
a client and its simultaneous consumption by the client.
Paragraph (version B):
Here, "media" refers to any type of media and associated streams
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
completed, which would be called download-and-play.
Paragraph (version A):
Each of these encryption strategies is intended to achieve a
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
may be used to prevent media steam manipulation or to protect
manifests.
Paragraph (version B):
Each of these encryption strategies is intended to achieve a
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
may be used to prevent media stream manipulation or to protect
manifests.