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:[email protected]] > Sent: den 18 maj 2015 11:38 > To: Robert Sparks; General Area Review Team; [email protected]; [email protected]; > draft-ietf-avtext-rtp-grouping- > [email protected] > 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: [email protected] > ---------------------------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
