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(_dot_)westerlund(_at_)ericsson(_dot_)com]
Sent: den 18 maj 2015 11:38
To: Robert Sparks; General Area Review Team; avtext(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; draft-ietf-avtext-rtp-grouping-
taxonomy(_at_)ietf(_dot_)org
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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------