Re: [Gen-art] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06

[Bo Burman <[e-mail]>]

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:[e-mail]]
> Sent: den 18 maj 2015 11:38
> To: Robert Sparks; General Area Review Team; [e-mail]; [e-mail]; draft-ietf-avtext-rtp-grouping-
> [e-mail]
> 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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------