Subject: [Simple] Consensus Call on sessmatch-13

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Jun 2011 13:45:15 -0500

(as chair)

Hi,

The latest version of the sessmatch draft ( draft-ietf-simple-msrp-sessmatch-13) is a significant change of direction from older version. The essential difference is that the new version involves compliant endpoints using the SDP m and c lines to establish TCP connections, rather than the previous approach of making clients more resilient to a middlebox changing an MSRP URI in the a=path attribute. The draft refers to this new approach as CEMA.

Do people thinks this is the right direction to take this work? I'm not asking if the draft is perfect and ready to go--we certainly expect discussion and potential changes in the details. The point is to decide if we should move forward with the CEMA approach instead of the previous sessmatch approach.

(In a perfect world, we probably would put CEMA in a separate draft so the two could be compared. But unless people strongly object, I think we can still compare the approaches with the current draft structure.)

Please send opinions and comments to the SIMPLE list no later than 11 July 2011. Sooner is better. (This is probably longer than we need, but I know we're into prime vacation time for a number of people, including myself. I've allotted extra time in hopes of getting more comments)

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Jun 2011 13:53:35 -0500

(as individual)

IMO, the CEMA approach is better than the previous sessmatch approach that encouraged middleboxes to change URLs in the SDP offer and answer.

However, I would like to better understand which scenarios allow for CEMA to work, vs which scenarios require fallback to 4975 behavior, with middleboxes acting as MSRP b2buas, along with how common each class of scenario really is.

I wonder whether CEMA solves enough cases where we would not be better off to simply advise (perhaps in an informational rfc) middlebox makers that, if they want to carry MSRP, they have to act either as an MSRP b2bua or an RFC4976 MSRP Relay.

Thanks!

Ben.

On Jun 24, 2011, at 1:45 PM, Ben Campbell wrote:

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 25 Jun 2011 00:45:19 +0200

> However, I would like to better understand which scenarios allow for CEMA to work, vs which scenarios require fallback to 4975 behavior, with middleboxes acting as MSRP b2buas, along with how commo…

I think the same. I'd would like all the scenarios (working and non
working) to be fully detailed and explained in the draft (and not just
in a mail thread in this maillist).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: <[email-masked]>
Date: Mon, 27 Jun 2011 11:26:57 +0200

Hi,
Yes I think that is the right direction to go.

Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Ben Campbell
> Gesendet: Freitag, 24. Juni 2011 20:45
> An: Simple WG
> Betreff: [Simple] Consensus Call on sessmatch-13
>
> (as chair)
>
> Hi,
>
> The latest version of the sessmatch draft (
> draft-ietf-simple-msrp-sessmatch-13) is a significant change
> of direction from older version. The essential difference is
> that the new version involves compliant endpoints using the
> SDP m and c lines to establish TCP connections, rather than
> the previous approach of making clients more resilient to a
> middlebox changing an MSRP URI in the a=path attribute. The
> draft refers to this new approach as CEMA.
>
> Do people thinks this is the right direction to take this
> work? I'm not asking if the draft is perfect and ready to
> go--we certainly expect discussion and potential changes in
> the details. The point is to decide if we should move forward
> with the CEMA approach instead of the previous sessmatch approach.
>
> (In a perfect world, we probably would put CEMA in a separate
> draft so the two could be compared. But unless people
> strongly object, I think we can still compare the approaches
> with the current draft structure.)
>
> Please send opinions and comments to the SIMPLE list no later
> than 11 July 2011. Sooner is better. (This is probably longer
> than we need, but I know we're into prime vacation time for a
> number of people, including myself. I've allotted extra time
> in hopes of getting more comments)
>
> Thanks!
>
> Ben.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 27 Jun 2011 12:27:09 -0400

+1

---

From: Nancy Greene <[email-masked]>
Date: Mon, 27 Jun 2011 12:32:14 -0400

I also support sessmatch-13

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: June-27-11 12:27 PM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

+1

On Jun 27, 2011, at 5:26 AM, <[email-masked]> <[email-masked]> wrote:

>> Von: [email-masked] [mailto:[email-masked]] Im 
>> Auftrag von Ben Campbell
>> draft-ietf-simple-msrp-sessmatch-13) is a significant change of 
>> direction from older version. The essential difference is that the 
>> new version involves compliant endpoints using the SDP m and c lines 
>> to establish TCP connections, rather than the previous approach of 
>> making clients more resilient to a middlebox changing an MSRP URI in 
>> the a=path attribute. The draft refers to this new approach as CEMA.
>> 
>> Do people thinks this is the right direction to take this work? I'm 
>> not asking if the draft is perfect and ready to go--we certainly 
>> expect discussion and potential changes in the details. The point is 
>> to decide if we should move forward with the CEMA approach instead of 
>> the previous sessmatch approach.
>> 
>> (In a perfect world, we probably would put CEMA in a separate draft 
>> so the two could be compared. But unless people strongly object, I 
>> think we can still compare the approaches with the current draft 
>> structure.)
>> 
>> Please send opinions and comments to the SIMPLE list no later than 11 
>> July 2011. Sooner is better. (This is probably longer than we need, 
>> but I know we're into prime vacation time for a number of people, 
>> including myself. I've allotted extra time in hopes of getting more 
>> comments)
>> 
>> Thanks!
>> 
>> Ben.

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Mon, 27 Jun 2011 12:32:52 -0400

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nancy Greene
Sent: Monday, June 27, 2011 12:32 PM
To: [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: June-27-11 12:27 PM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

+1

---

From: Atle Monrad <[email-masked]>
Date: Tue, 28 Jun 2011 13:00:57 +0200

+1 from me aswell

Thanks to Ben for a constructive proposal !

/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C (ATTSI)
Sent: 28. juni 2011 00:33
To: Nancy Greene; [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nancy Greene
Sent: Monday, June 27, 2011 12:32 PM
To: [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

Nancy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: June-27-11 12:27 PM
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Simple] Consensus Call on sessmatch-13

+1

---

From: Laura Liess <[email-masked]>
Date: Tue, 28 Jun 2011 15:52:32 +0200

I support this draft.

Laura

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 28 Jun 2011 18:26:22 +0200

+1

-- 
Victor Pascual Ávila

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 29 Jun 2011 09:48:44 +0200

Hi,

I do like and support the CEMA approach.

Small question/comment for Christer: in section 4.3: is it necessary to mention point 3? Since that is not alloweb as per RFC6135, the offer should be rejected, right? I'd remove point 3 and extend the note to mention that "if the SDP offer contains a a=setup:passive attribute the request MUST be rejected".

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Jun 2011 11:59:46 -0400

> Small question/comment for Christer: in section 4.3: is it necessary to mention point 3? Since that is not alloweb as per RFC6135, the offer should be rejected, right? I'd remove point 3 and extend…

I don't think so... because the middlebox will likely set it to be that in the offer/answer before it sends it to the UA behind a NAT (to force the UA to open the TCP connection to the middlebox).

-hadriel

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 30 Jun 2011 08:55:45 +0200

> I don't think so... because the middlebox will likely set it to be that in the offer/answer before it sends it to the UA behind a NAT (to force the UA to open the TCP connection to the middlebox).

That is plain wrong. The middlebox can't do that. RFC6135 forbids it and the current draft version (13) does not allow it either, I just suggested a clarification. See the changelog from draft 12.

I've seen middleboxes doing such things to force the recipient to also become active and then do 'TCP stitching' to bridge both ends. The correct way of doing it would be putting 'actpass', and leave the responsibility of deciding if it want to be active or passive to the recipient.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jun 2011 12:03:50 +0200

> I've seen middleboxes doing such things to force the recipient to also become active and then do 'TCP stitching' to bridge both ends. The correct way of doing it would be putting 'actpass', and lea…

Fully agree. Any other approach (so what Hadriel says) breaks the protocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jun 2011 09:04:04 -0400

> I've seen middleboxes doing such things to force the recipient to also become active and then do 'TCP stitching' to bridge both ends. The correct way of doing it would be putting 'actpass', and lea…

Yup, that's exactly why we do it - to force a UA behind a NAT to become active, and stitch if necessary.  It's worked so far, afaik.

-hadriel

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 30 Jun 2011 15:16:30 +0200

Hi,

> Yup, that's exactly why we do it - to force a UA behind a NAT to become active, and stitch if necessary.  It's worked so far, afaik.

Well, that's not the right thing to do, for the reasons I stated in my previous email. Earlier you said you supported this draft, but the way you use it breaks it. There seems to be an inconsistency here.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jun 2011 16:25:31 +0200

> Yup, that's exactly why we do it - to force a UA behind a NAT to become active, and stitch if necessary.  It's worked so far, afaik.

It works if you try it in your own environment (wallen warden) with
MSRP clients behaving as you desire. But the mechanism you use breaks
the standard, do you agree? (you should). That is a "WorksForMe" or
"WorksInMyWallenGarden" argument, but it breaks MSRP protocol, so this
draft should not cover such case (even if it works for you).

Please, respect the MSRP standard ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jun 2011 11:09:45 -0400

I don't see how it breaks MSRP.  It's not compliant to the must, but the acm rfc does not tell the UAS to reject it nor should it.  
-Hadriel

Sent from my iPhone

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 30 Jun 2011 17:18:48 +0200

> I don't see how it breaks MSRP.  It's not compliant to the must, but the acm rfc does not tell the UAS to reject it nor should it.  

From RFC6135:

"The UA MUST NOT use the a=setup "passive" attribute value in an SDP
   offer."

As a UA what am I supposed to do if I get such a request? RFC says it MUST never happen, so rejecting it is the best an endpoint can do.

It breaks MSRP in the sense that implementations compliant with RFC6135 will most likely reject such requests as they don't comply to the standard.

What really puzzles me is the fact that you support this draft but at the same time "It's not compliant to the must". If everyone would do that there is no point in putting MAY, MUST, SHOUD or whatever on an RFC.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jun 2011 17:24:39 +0200

2011/6/30 Hadriel Kaplan <[email-masked]>:
> I don't see how it breaks MSRP.  It's not compliant to the must

So which is your exact understanding for "MUST" keyword in a RFC??

You cannot say that you support this draft and at the same time break
the MSRP protocol with your non compliant impelmentation.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 30 Jun 2011 12:02:40 -0400

First, it is not the role of a UA to police the RFC.  In fact, the IETF generally expects devices to be strict on send but liberal on receipt.  Second, the Acm rfc says devices must support passive (though it doesn't say when).  There's no real reason to reject such an offer is there?  Answer it with active, as per the rfc for setup attribute.

How about we put a line saying a UAS should accept a passive offer with active?

-Hadriel

Sent from my iPhone

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 30 Jun 2011 18:17:45 +0200

Hi,

> First, it is not the role of a UA to police the RFC.  In fact, the IETF generally expects devices to be strict on send but liberal on receipt.  Second, the Acm rfc says devices must support passive…

It's mentioned as a MUST I'm not sure about how 'flexible' an implementation should be in that matter.

> How about we put a line saying a UAS should accept a passive offer with active?

I see no need for changing what RFC6135 says. What about something like: "MSRP endpoints supporting this specification MUST become active upon receiving an offer with 'actpass' " Would that be reasonable for you?

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jun 2011 18:18:37 +0200

> I see no need for changing what RFC6135 says. What about something like: "MSRP endpoints supporting this specification MUST become active upon receiving an offer with 'actpass' " Would that be reas…

This should be the way to go.

-- 
Iñaki Baz Castillo
<[email-masked]>