Subject: [Simple] minor agenda change

From: Robert Sparks <[email-masked]>
Date: Thu, 19 Jul 2007 14:22:09 -0500

I'd like to have Jonathan talk about the SIMPLE protocol annotated  
overview at the beginning of the SIMPLE meeting
(right after the chair status update) instead of later in the  
meeting. Let me know if that gives anyone heartburn.

The adjusted agenda would look like this:

5m - Status/Administrivia

5m - Annotated Overview

10m - Interdomain Scaling Analysis

20m - Chat using MSRP

20m - Remaining direction

RjS

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

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 18:52:20 +0300

Hi,

Now that MSRP has been finally approved as an RFC, it would be nice to
get some actual implementations and even deployments for it. Based on
what I've heard there are several client implementations under
development (for instance to support file/image transfer service). The
problem is that I've got a sense that the interest to support MSRP relay
extension seems to be quite low. I'm not sure if there are MSRP relay
implementations under development. Instead it seems that many people
would rather have MSRP NAT traversal using SBCs (based on comedia) or
ICE/TURN.

Personally I think that the decision in MSRP not to use comedia has been
a mistake. It's not possible to change that anymore in the MSRP base
spec, but I think it would be valuable to define how to negotiate MSRP
with comedia in an extension spec. This would allow MSRP to work in
situations where one of the endpoints can receive incoming TCP
connections, as well as with SBCs supporting comedia.

Also the work started in
http://www.ietf.org/internet-drafts/draft-niemi-simple-msrp-ice-00.txt
should be brought to completion.

I would be interested in hearing comments whether people think that MSRP
relays are going to be sufficient for MSRP NAT traversal (and especially
if there are implementation plans) or if there is interest in defining
how MSRP works with comedia as an alternative mechanism. My goal would
be to do whatever is best to have MSRP deployable.

Regards,
	Markus

---

From: Ben Campbell <[email-masked]>
Date: Tue, 24 Jul 2007 18:32:47 -0500

On Jul 24, 2007, at 10:52 AM, <[email-masked]>  
<[email-masked]> wrote:

> if there are implementation plans)
We have plans to implement relays. I think MSRP relays are sufficient  
for the NAT problem, but I realize that some may be motivated to use  
other existing technologies (i.e. SBCs, stun relay, etc.)

> or if there is interest in defining

I have no objection to work on specifying MSRP with COMEDIA. The only  
reason we took it out of the MSRP base was that at the time we worked  
on that part of the protocol, COMEDIA was not a sufficient solution,  
and we did not want to block on it. COMEDIA has evolved since then,  
but if we went back and adapted to every change in dependencies, we  
would never have finished MSRP.

MSRP has explicit words indicating that the TCP connection direction  
could be changed by future extensions for this exact reason.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 25 Jul 2007 02:42:00 +0300

> could be changed by future extensions for this exact reason.

Unfortunately, that wording is most likely insufficient. We will most likely 
stumble upon the fact that COMEDIA will want to use c= and m= as 
authoritative, rather than the MSRP URL, if there is a COMEDIA-capable SBC. 
We've already seen that was a problem for MSRP+ICE in Prague.

-- 
Rémi Denis-Courmont

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 25 Jul 2007 12:11:33 -0400

I think changing the SDP for MSRP to follow comedia's model is necessary but
not sufficient to get it to go through SBCs, or at least some SBCs.

The problem is the to-path/from-path URIs in MSRP itself.  The SIP protocol
headers have been virtually reproduced in the bearer plane, and along with
that comes all the baggage.  I was hoping we could just treat MSRP as a
media-plane connection, and allow TLS to be end-end (which we do for
comedia-tls), if the operator so wished - but that won't be the case as MSRP
is currently defined, because of the to-path/from-path.  Few operators will
let us leak those URI IP addresses through, and even if they did the
protocol will break when they don't match L3/sdp addresses.  

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2007 11:52 AM
> To: [email-masked]; [email-masked]
> Subject: [Simple] MSRP NAT traversal
> 
> Hi,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jul 2007 14:30:56 -0400

Since when is it the responsibility of protocol designers to design 
their protocols to get through SBCs, rather than visa versa?

	Paul

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 25 Jul 2007 15:23:35 -0400

It isn't, and I didn't say it should.
Markus posed a question.  I tried to answer part of it.

Having said that, I think history has shown designing protocols which don't
consider NATs/FWs/etc. is not the best of ideas.  But that's just my view.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2007 2:31 PM
> To: Hadriel Kaplan
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] MSRP NAT traversal
>

---

From: "Hisham Khartabil" <[email-masked]>
Date: Fri, 27 Jul 2007 14:29:48 +1000

I think we are always in the habbit on being 10 years ahead of
implementation and always trying to design an alternative solution to a
solution that has not been proven broken.

We spent years on designing MSRP and MSRP relay. Now that they are finally
becoming RFCs, we want an alternative solution. One that will cause
interoperability problem in the sense that different implementors will
choose different solutions. This will cause further work in order to
negotiate the NAT traversal solution between endpoints.

- Why is not using comedia a mistake?
- Why is it valuable?
- Why isnt MSRP Relay sufficient?

Config framework work is another example where people are proposing
something else before the config framework has been proven broken.

I don't know why you would want to standardise something that is not any
better than an existing solution.

Hisham

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 30 Jul 2007 12:36:42 +0300

> - Why isnt MSRP Relay sufficient?

Hmm, I cannot honestly say that I am satisfied with the answers that were 
given in this thread:
http://www1.ietf.org/mail-archive/web/simple/current/msg05676.html
and in particular, that one is very worrying:
http://www1.ietf.org/mail-archive/web/simple/current/msg05706.html

I still consider the current design of MSRP relays to be fatally broken, as in 
easily abusable by malign third parties. It's currently basically like TCP 
without window and ACKs... which of course does not work.

On the contrary, using COMEDIA and/or ICE ensures end-to-end congestion and 
error control, with TCP, proven IETF technology.

-- 
Rémi Denis-Courmont