I agree that there should be text explicitly discussing SRTP, and having it as a separate transformation is likely the best option. One reason to keep it as a separate transformation is to be able to describe the relation to the RTP-based Redundancy transformation. That would not be possible if SRTP were to be described as an configuration option to the Media Packetizer, for example. New 2.1.x sub-sections for that transformation and the resulting stream will be needed, as well as an update to the media chain figures. I will work with Magnus, my co-authors and the WG, and come up with a text proposal. I will respond to the other comments in the separate thread, reducing the sendlist somewhat. Cheers, Bo B > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@xxxxxxxxxxxx] > Sent: den 18 maj 2015 11:38 > To: Robert Sparks; General Area Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-avtext-rtp-grouping- > taxonomy@xxxxxxxx > Subject: Re: Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06 > > Robert Sparks skrev den 2015-05-14 21:21: > > > Major issues: > > > > I'm surprised that there is no mention of how SRTP fits into the > > vocabulary this document builds. Would it be a mistake for someone to > > think of SRTP as what this document calls a transformation? Are there > > any consequences of using SRTP on one or more of the streams being > > associated that impact how you would talk about the association? > > (There are certainly consequences about which elements can see into > > the various streams). > > > > Yes, encryption is clearly a transformation. And there are cases where the order of the encryption and other > transformations, like FEC, do matter. Thus, I agree that it is an significant oversight to not include security. > > So SRTP is an Securing / Protection (as it is not only Encryption) transformation that operates on Source RTP Streams or > Redundancy RTP Streams to create Secured Source RTP Streams or Secured Redundancy RTP Stream. > > If one looks on something like ISMAcrypt that operates on a special form of packetized encoded streams, i.e. payload > created, but not RTP headers, we get into further distinctions that we so far haven't needed to have. > > I don't know how well we must ensure that something like ISMAcrypt is clearly defined, because then we do need to > split the RTP packetization transformation into two parts. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx > ----------------------------------------------------------------------