Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-02

From: Ben Campbell <[email-masked]>
Date: Wed, 14 Sep 2011 16:22:24 -0500

This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02:

http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02

The WGLC will conclude on 29 September 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group mail list.

Thanks!

Ben.

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Sep 2011 20:29:50 +0000

This is ready to go.

-hadriel

On Sep 14, 2011, at 5:22 PM, Ben Campbell wrote:

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

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 20 Sep 2011 20:34:19 +0000

+1
Martin C. Dolly
Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible.
+1.609.903.3360

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Tuesday, September 20, 2011 04:29 PM
To: Ben Campbell <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; Simple WG <[email-masked]>
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02

This is ready to go.

-hadriel

---

From: Nancy Greene <[email-masked]>
Date: Tue, 20 Sep 2011 16:37:36 -0400

This version looks good and ready to go.

Just a few editorial comments:
- section 4.1 2nd paragraph, s/can not/cannot
- section 4.4, 2nd sentence, s/a MSRP/an MSRP/ 
- section 5.5, 2nd paragraph, s/When UAs fallback/When UAs fall back/
- section 6.2, 3rd paragraph, use of subjunctive means it should be also support, not also supports: s/RECOMMENDED that a CEMA-enabled MSRP endpoint also supports one/RECOMMENDED that a CEMA-enabled MSRP endpoint also support one/ 
- section 6.2, in the paragraph before the NOTE at the end of the section, s/depending on local policy chose/depending on local policy choose/
- section 6.2 in the NOTE just before section 6.3: s/the user need to be able/the user needs to be able/
- section 6.2 in the NOTE just before section 6.3: s/try to anyway establish/try anyway to establish/

Nancy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: September-14-11 5:22 PM
To: Simple WG
Cc: [email-masked]
Subject: [Simple] WGLC of draft-ietf-simple-msrp-cema-02

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Sep 2011 07:53:45 +0200

Hi Nancy,

Thanks for your comments! I'll modify the text according to your suggestions.

Regards,

Christer 

> From: Nancy Greene 
> Sent: 20. syyskuuta 2011 23:38
> To: Simple WG; Christer Holmberg
> Cc: [email-masked]; Ben Campbell
> Subject: RE: [Simple] WGLC of draft-ietf-simple-msrp-cema-02
> 
> 
> - section 6.2, 3rd paragraph, use of subjunctive means it 
> should be also support, not also supports: s/RECOMMENDED that 
> a CEMA-enabled MSRP endpoint also supports one/RECOMMENDED 
> that a CEMA-enabled MSRP endpoint also support one/
> - section 6.2, in the paragraph before the NOTE at the end of 
> the section, s/depending on local policy chose/depending on 
> local policy choose/
> - section 6.2 in the NOTE just before section 6.3: s/the user 
> need to be able/the user needs to be able/
> - section 6.2 in the NOTE just before section 6.3: s/try to 
> anyway establish/try anyway to establish/
> 
> Nancy
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Campbell
> The WGLC will conclude on 29 September 2011. Please send your 
> comments, including nits and "this is ready to go" type 
> comments, to the authors and the working group mail list.
> 
> Thanks!
> 
> Ben.
> 
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 21 Sep 2011 09:29:36 +0200

Hi,

> The WGLC will conclude on 29 September 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group mail list.

Section 5.2: s/will is some cases/will in some cases/

This last version looks fine to me. The only concern I have is the fact that the MSRP B2BUA functionality is not strictly mandated. Section 5.2 says that "CEMA-enabled MSRP endpoints will is some cases be unable to interoperate with non-CEMA-enabled endpoints across the Middlebox.". which I find too optimistic. Chances of that connection working are close to none IIRC.

I know that we are making some assumptions in what Middleboxes may or may not do, but can we say that "if a Middlebox needs to anchor MSRP media it MUST implement B2BUA functionality" ?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Sep 2011 10:32:12 +0200

Hi Saul, 

>> The WGLC will conclude on 29 September 2011. Please send 
>> your comments, including nits and "this is ready to go" type 

I'll fix that as suggested.

>This last version looks fine to me. The only concern I have 
>is the fact that the MSRP B2BUA functionality is not strictly 
>mandated. Section 5.2 says that "CEMA-enabled MSRP endpoints 
>will is some cases be unable to interoperate with 
>non-CEMA-enabled endpoints across the Middlebox.". which I 
>find too optimistic. Chances of that connection working are 
>close to none IIRC.
> 
>I know that we are making some assumptions in what 
>Middleboxes may or may not do, but can we say that "if a 
>Middlebox needs to anchor MSRP media it MUST implement B2BUA 
>functionality" ?

I personally would have no problem with that, but we have a decision that we cannot mandate Middlebox behavior - only make "assumptions" - and I would not like to re-open that discussion.

Section 5.2 does say:

	"In order to support interoperability between UAs that support the
   	CEMA extension and UAs that do not support the extension, the
   	Middlebox is MSRP aware.  This means that it implements MSRP B2BUA
   	functionality."

And, whatever MUSTs we would add, at the end of the day the vendor and customer will decide what is implemented and deployed. And, as I've said before, from my experience customers DO require interoperability with non-CEMA clients, and the products I am aware of DO support MSRP B2BUA functionality.

Regards,

Christer

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 22 Sep 2011 10:46:27 +0200

After some minor clarifications and improvements, this ID is ready to go
forward.

Servus
Christian

4.2 MSRP Offer Procedures

   3.  If the MSRP endpoint is using a relay for MSRP communication, it
   MUST include the address information of the relay (the MSRP URI of
   the topmost SDP a=path attribute), rather than the address
   information of itself, in the SDP c/m-line associated with the MSRP
   media description....  

This description is a bit unclear to me. It looks like that only m/c
line
Would be modified. What about the following proposal:

   3.  If the MSRP endpoint is using a relay for MSRP communication, it
   MUST add the address information of the relay to the a=path
attributes 
   (the MSRP URI of the topmost SDP a=path attribute) and use the
address
   Information of the relay (instead of the own address information) 
   in the SDP c/m-line associated with the MSRP media description....

Same proposal for 4.3 MRSP Answerer Procedures

   3.  If the MSRP endpoint is using a relay for MSRP communication, it
   MUST include the address information on the relay (the MSRP URI of
   the topmost SDP a=path attribute), rather than the address
   information of itself, in the SDP c/m-line associated with the MSRP
   media description...

New Version:

   3.  If the MSRP endpoint is using a relay for MSRP communication, it
   MUST add the address information of the relay to the a=path
attributes 
   (the MSRP URI of the topmost SDP a=path attribute) and use the
address
   Information of the relay (instead of the own address information) 
   in the SDP c/m-line associated with the MSRP media description....

General Remark:
Especially Section 4 is a bit difficult to read.
In 4.2 MSRP Offer Procedures the MSRP endpoint is the MSRP offerer and
the remote MSRP endpoint is the MSRP answerer.
In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP answerer and
the remote MSRP endpoint is the MSRP offerer.
That confusing for the reader. Why not replace MSRP endpoint and MSRP
remote endpoint with MSRP offerer and MSRP answerer in all reasonable
cases?

4.2 MSRP Offer Procedures

   NOTE: As described in section 5, in the absence of the SDP a=msrp-
   cema attribute in the new offer, it is assumed that a Middlebox will
   act as an MSRP B2BUA in order to anchor MSRP media.

Does this mean, a Middlebox would have to remove the SDP a=msrp-cema
attribute from an offer, if it provides MSRP B2BUA function?
At lease this description is missing in section 5.

   The MSRP endpoint MAY choose to terminate the session establishment
   if it can detect that a Middlebox acting as a MSRP B2BUA is not the
   desired remote endpoint.

How is this related or relevant for CEMA? 

   The MSRP endpoint can send the new offer within the existing early
   dialog [RFC3261], or it can terminate the early dialog and establish
   a new dialog by sending the new offer in a new initial INVITE
   request.

If this are the possible reactions on the detection of a Middlebox, the
two
Paragraphs should be combined.

1. Introduction

   Since the active MSRP UA establishes
   the MSRP TCP or TLS connection based on the MSRP URI of the SDP
   a=path attribute, this means that the MSRP connection will not,
   unless the middlebox also modifies the MSRP URI of the topmost SDP
   a=path attribute, be routed through the middlebox.

The sentence look a bit strange. What about the following proposal:

   An active MSRP UA establishes the MSRP TCP or TLS connection based
   on the MSRP URI of the SDP a=path attribute. This means that the MSRP
   connection will not be routed through the middlebox, unless the
   middlebox also modifies the MSRP URI of the topmost SDP a=path
attribute.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Hadriel Kaplan
Sent: Dienstag, 20. September 2011 22:30
To: Ben Campbell
Cc: <[email-masked]>; Simple WG
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02

This is ready to go.

-hadriel

> The WGLC will conclude on 29 September 2011. Please send your
comments, including nits and "this is ready to go" type comments, to the
authors and the working group mail list.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Sep 2011 14:36:26 +0200

Hi Christian,

Comments inline. 

> This description is a bit unclear to me. It looks like that 
> only m/c line Would be modified. What about the following proposal:
> 
>    MUST add the address information of the relay to the 
>    a=path attributes 
>    (the MSRP URI of the topmost SDP a=path attribute) and use 
>    the address
>    MUST add the address information of the relay to the 
>    a=path attributes 
>    (the MSRP URI of the topmost SDP a=path attribute) and use 
>    the address

Your suggestion looks good.

-------------

> In 4.2 MSRP Offer Procedures the MSRP endpoint is the MSRP 
> offerer and the remote MSRP endpoint is the MSRP answerer.
> In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP 
> answerer and the remote MSRP endpoint is the MSRP offerer.
> That confusing for the reader. Why not replace MSRP endpoint 
> and MSRP remote endpoint with MSRP offerer and MSRP answerer 
> in all reasonable cases?

Unless people object, I can try to do that.

-------------

>    cema attribute in the new offer, it is assumed that a 
>    Middlebox will act as an MSRP B2BUA in order to anchor MSRP media.
> 
> Does this mean, a Middlebox would have to remove the SDP 
> a=msrp-cema attribute from an offer, if it provides MSRP 
> B2BUA function?

I will add some text about that.

-------------

>    "The MSRP endpoint MAY choose to terminate the session establishment
>    desired remote endpoint."
> 

Since the main usage of CEMA is in environments where middleboxes are used, it was
considered good from a security perspective to add this text.

-------------

>    "The MSRP endpoint can send the new offer within the existing early
>    dialog [RFC3261], or it can terminate the early dialog and 
>    establish a new dialog by sending the new offer in a new initial 
>    INVITE request."
> 
> If this are the possible reactions on the detection of a 
> Middlebox, the two Paragraphs should be combined.

It's not really the same thing. One paragraph talks about the procedure when a new offer is sent, and the other paragraph talks about when the user chooses to terminate the session establishment and not send a new offer.

However, I do suggest to switch location of the two paragraphs, as the second one is related to the procedures above in the section.

-------------

>    on the MSRP URI of the SDP a=path attribute. This means 
>    that the MSRP connection will not be routed through the middlebox, 
>    a=path attribute.

Your suggestion looks good.

-------------

Thanks for your comments!

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 22 Sep 2011 17:17:34 +0200

Christer,

> And, whatever MUSTs we would add, at the end of the day the vendor and customer will decide what is implemented and deployed. And, as I've said before, from my experience customers DO require inter…

It was not my intention to re-popen the discussion. I'd be happier to see that, but if it was agreed that we can't do that, it's ok.

+1 from me.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Atle Monrad <[email-masked]>
Date: Mon, 26 Sep 2011 09:54:48 +0200

Hi

Christer has worked long and hard and answered the questions and concerns on this draft.

With the latest additions, I'm happy to bring the draft forwards.
1+ from me aswell.

thanks
/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 Christer Holmberg
Sent: 22. september 2011 14:36
To: Schmidt, Christian 1. (NSN - DE/Munich); Ben Campbell
Cc: [email-masked]; Simple WG
Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 - Christian's comments

Hi Christian,

Comments inline. 

> line Would be modified. What about the following proposal:
> 

-------------

> In 4.3 MSRP Answer Procedures the MSRP endpoint is the MSRP answerer 
> and the remote MSRP endpoint is the MSRP offerer.

-------------

-------------

> How is this related or relevant for CEMA? 

Since the main usage of CEMA is in environments where middleboxes are used, it was considered good from a security perspective to add this text.

-------------

> If this are the possible reactions on the detection of a Middlebox, 
> the two Paragraphs should be combined.

-------------

-------------

Regards,

Christer