Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt

From: "Elwell, John" <[email-masked]>
Date: Wed, 06 Sep 2006 21:34:52 +0100

Francois,

I am supportive of trying to solve this problem quickly. I was just pointing
out some shortcomings of the proposal and making sure that we have explored
all reasonable alternatives that might close some of these shortcomings. In
the absence of support I will keep quiet.

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 06 September 2006 19:53
> To: Elwell, John; Hadriel Kaplan; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> 
> I'm not sure I agree.
> 
> The sdp-cap proposal was a "usage" of an existing RFC. 
> 
> While it may be "more complex" from a theoretical point of view, the
> process 
> of standardizing yet another SDP extension to do this seems much more
> "complex" 
> from a procedural point of view.
> 
> This group has an appetite for making seamingly simple 
> problems complex.
> I do not
> see why this particular one wouldn't expand to be just as "complex" as
> the sdp-cap
> proposal when we are done with it.
> 
> As I stated in Montreal, what really bothers me about this is the
> unresponsiveness
> of the IETF in providing a mechanism for supporting best-effort
> backward-compatible
> SRTP.
> 
> We are at a point now where the industry is way ahead of the standard.
> Implementors have 
> been working on this particular item for 2-3 years now. Implementors
> don't understand why
> IETF can't make up our mind on such a trivial problem.
> 
> The consequence of this is a proliferation of ways to do best-effort
> SRTP. They mostly
> are variations of either port overloading, multiple ports and
> AVP+crypto/kmgmt.
> Mostly not interoperable obviously.
> 
> We are very close to a point of losing our relevance. 
> 
> <<<<rant off>>>>
> 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Tuesday, September 05, 2006 11:40 PM
> > To: Audet, Francois (SC100:3055); Hadriel Kaplan; [email-masked]
> > Subject: RE: [MMUSIC] FW: I-D 
> > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > 
> > I think it's a lot simpler, addressing this particular 
> > problem of SSRTP versus RTP.
> > 
> > John 
> > 
> > > -----Original Message-----
> > > From: Francois Audet [mailto:[email-masked]]
> > > Sent: 05 September 2006 21:43
> > > To: Elwell, John; Hadriel Kaplan; [email-masked]
> > > Subject: RE: [MMUSIC] FW: I-D
> > > ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt
> > > 
> > > 
> > > > It is a question of whether a new RFC, perhaps defining a new 
> > > > attribute, would be worthwhile in terms of gaining a larger 
> > > > catchment of legacy devices with which we can fall back to RTP.
> > > 
> > > 
> > > How is that any different from the sdp-cap proposal in Montreal? 
> > > 
> > 
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Sep 2006 16:01:44 -0500

Hi John,

You shouldn't keep quiet ;^)

I'm not against the idea. I'm just thinking that it would end-up looking
very similar to sip-cap, since in order to be backward compatible, the
whole SRTP component would have to be "prefixed" with some some of
attribute to make it invisible to a UA that doesn't unserstand SAVP.
But maybe I'm wrong.

I'd even encourage you to write a draft on it. I can even help.

I'd be very happy to see all the various proposal on the table, so we
can
finally pick one. I'm really not attached to any one in particular.

> Sent: Wednesday, September 06, 2006 1:35 PM
> I am supportive of trying to solve this problem quickly. I 
> was just pointing out some shortcomings of the proposal and 
> making sure that we have explored all reasonable alternatives 
> that might close some of these shortcomings. In the absence 
> of support I will keep quiet.
> 
> John 
> 
> > process of standardizing yet another SDP extension to do this seems 
> > much more "complex"
> > This group has an appetite for making seamingly simple problems 
> > complex.
> > I do not
> > the sdp-cap proposal when we are done with it.
> > 
> > unresponsiveness of the IETF in providing a mechanism for 
> supporting 
> > best-effort backward-compatible SRTP.
> > 
> > don't understand why IETF can't make up our mind on such a trivial 
> > problem.
> > 
> > SRTP. They mostly are variations of either port 
> overloading, multiple 
> > ports and
> > AVP+crypto/kmgmt.
> > > I think it's a lot simpler, addressing this particular problem of 
> > > SSRTP versus RTP.
> > > 
> > > John
> > >