Subject: [Simple] SIMPLE meeting at IETF81

From: Ben Campbell <[email-masked]>
Date: Tue, 7 Jun 2011 13:28:37 -0500

(as chair)

Hi Everyone,

Given the new proposals and spirited discussion related to draft-ietf-simple-msrp-sessmatch currently happening on the work group list, the chairs have requested meeting time at the IETF81 meeting in Quebec City. We've asked for an hour slot, and currently expect this to be the only significant agenda item.

However, please do not defer discussion until the meeting. If we resolve the issues prior to the meeting, and end up canceling the meeting as a result, we would count that as a success.

Thanks!

Ben.

---

From: Atle Monrad <[email-masked]>
Date: Fri, 10 Jun 2011 09:14:16 +0200

Ben / all

Christer has actively answered and incorporated comments given to progress draft-ietf-simple-msrp-sessmatch since the draft became a WG-item, and it would be good to get some clear guideance how to progress and complete the work . 

This draft is one of the remaining dependencies in 3GPP rel-8, and a conclusion from IETF would be appreciated in order for 3GPP to conclude and complete the work. 
 
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 Ben Campbell
Sent: 7. juni 2011 20:29
To: Simple WG
Cc: [email-masked] Chairs
Subject: [Simple] SIMPLE meeting at IETF81

(as chair)

Hi Everyone,

Thanks!

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

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 14:07:10 +0200

Hello Atle,

As this draft is not required for MSRP protocol on Internet but addresses strictly the needs of 3GPP rel-8 it should explicitly state this simple fact in its title and description. 

Adrian

---

From: Atle Monrad <[email-masked]>
Date: Fri, 10 Jun 2011 14:55:59 +0200

Adrian

as I am not an expert on the formalities on how the extentions under the responsibility of SIMPLE are handled and documented, this has to be left to others to comment and decide on.

However, a point that I'd like to raise, is that 3GPP would like to get our requirements included into the RFCs as normative requirements that can be expressed as mandatory or optional statements. 

When requirements described in drafts become WG-items it seems natural to me that such options are seen as general options. Why these options have to be phrased explicitly as options strictly for 3GPP isn't actually what I had expected.

WRT the title - if this turns out to be the main blocking point, I'm sure that this can be modified, as long as this doesn't restart and alter the technical discussions already held and concluded.

/atle

Atle Monrad
3GPP CT Chairman

-----Original Message-----
From: Adrian Georgescu [mailto:[email-masked]] 
Sent: 10. juni 2011 14:07
To: Atle Monrad
Cc: Ben Campbell; Simple WG; [email-masked] Chairs
Subject: Re: [Simple] SIMPLE meeting at IETF81

Hello Atle,

Adrian

On Jun 10, 2011, at 9:14 AM, Atle Monrad wrote:

> Group Function Technology and Portfolio Management Ericsson
> 
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 10 Jun 2011 14:57:36 +0200

Hello Adrian,
I'm wondering that we are discussing now about this fact that 3GPP does need this mechanism and should now state this in the title.

Such mechanism could also be used within other networks like an TISPAN NGN should we name that too? (We are using TISPAN NGN and would need such mechanism too)

Nevertheless Christer put the 3GPP use case into the introduction of his document.

1.  Introduction

   The Message Session Relay Protocol (MSRP) [RFC4975] is designed to
   use MSRP relays [RFC4976] as a means for Network Address Translation
   (NAT) traversal and policy enforcement.

 However, many Session Initiation Protocol (SIP) [RFC3261] networks,
   in which MSRP usage is emerging, also contain SIP Application Layer
   Gateways (ALGs), that anchor and controls media, perform tasks such
   as NAT traversal, performance monitoring, lawful intercept, address
   domain bridging, interconnect Service Layer Agreement (SLA) policy
   enforcement, etc.  An example is the Interconnection Border Control
   Function (IBCF) [3GPP.23.228], defined by the 3rd Generation
   Partnership Project (3GPP).  The IBCF controls a media relay that
   handles all types of SIP session media (voice, video, MSRP, etc).

It was asked for guidance on this issue. I would prefer to start the real discussion instead of discussing the name of the draft. As long as it is an agreed work item.

At least I don't care about the name but it must be a cool one, or is this really restricted only for internet ;-).

I fully support his work.

Best Regards
Roland

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]
> Im Auftrag von Adrian Georgescu
> Gesendet: Freitag, 10. Juni 2011 14:07
> An: Atle Monrad
> Cc: [email-masked] Chairs; Simple WG
> Betreff: Re: [Simple] SIMPLE meeting at IETF81
>
> Hello Atle,
>
> As this draft is not required for MSRP protocol on Internet
> but addresses strictly the needs of 3GPP rel-8 it should
> explicitly state this simple fact in its title and description.
>
> Adrian
>
> > Christer has actively answered and incorporated comments
> given to progress draft-ietf-simple-msrp-sessmatch since the
> draft became a WG-item, and it would be good to get some
> clear guideance how to progress and complete the work .
> >
> > This draft is one of the remaining dependencies in 3GPP
> rel-8, and a conclusion from IETF would be appreciated in
> order for 3GPP to conclude and complete the work.
> >
> > thanks
> > /atle
> >
> > From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ben Campbell
> > Sent: 7. juni 2011 20:29
> > To: Simple WG
> > Given the new proposals and spirited discussion related to
> draft-ietf-simple-msrp-sessmatch currently happening on the
> work group list, the chairs have requested meeting time at
> the IETF81 meeting in Quebec City. We've asked for an hour
> slot, and currently expect this to be the only significant
> agenda item.
> >
> > However, please do not defer discussion until the meeting.
> If we resolve the issues prior to the meeting, and end up
> canceling the meeting as a result, we would count that as a success.
> >
> > Thanks!
> >
> > Ben.

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 15:04:54 +0200

OK 3GPP, Tispan NGN are all closed networks with explicit gateways to the Internet. So:

"MSRP media anchoring for closed IP networks"

Would this be capturing all non-Internet style deployments?

Adrian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Jun 2011 09:19:34 -0400

Atle,

> When requirements described in drafts become WG-items it seems natural to me that such options are seen as general options. Why these options have to be phrased explicitly as options strictly for 3…

There are two cases here:

1) requirements identified by 3gpp that are also applicable in the 
internet at large.

2) requirements that are only applicable when operating in a 3gpp 
environment.

Both kinds can be considered as work items. But it is important for all 
the people working on these things to understand which is which. 
Understanding those that are specific to 3gpp typically require a level 
of understanding of 3gpp that few non-3gpp-affiliated ietf participants 
have. And when the work eventually leads to an RFC, future readers of 
that RFC should have that context to help in understanding if the RFC 
applies to them.

	Thanks,
	Paul

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 15:30:25 +0200

Hi Atle,

It is critical that implementors can chose what standard to implement for their customers.

In this case is a clear delimitation of scope. An implementor should not consider this draft when deploying for the Internet. An implementor for 3GPP must because it is a clear requirement.

In its current form, this draft may well be adopted for dubious reasons. For example cheap residential router manufacturers will want it so that 'they are MSRP compliant'. They will like the idea to have the same feature of an Ericsson router, which is well implemented but they will not do it good enough and things will break.  With current  MSRP design you cannot break it, by opening this gate of new possibilities of anchoring media things will break guaranteed. There are so many ifs in the specification that if you hire 100 people you will end up with 100 different solutions working in as many different ways.

This draft must clearly be applied to its scope and no more, to avoid breaking the rest of the MSRP traffic over the Internet.

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 15:33:20 +0200

Hi,

Eventhough there is a requirement in 3GPP (and OMA) for this, it is not only applicable to 3GPP/OMA.

It is applicable to ANY network where ALGs might anchor media - functionaltiy that you will find in many other networks than the ones defined by 3GPP/OMA. 3GPP/OMA didn't invent the ALG :)

But, as Roland also indicated, the draft provides some background text regarding the usage of ALGs in IMS. There is also an RFC giving some general ALG description.

It is also useful for MSRP endpoints located in non-ALG networks, when they communicate with MSRP endpoints in networks with ALGs.

Regards,

Christer

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 10. kesäkuuta 2011 16:20
> To: [email-masked]
> > as I am not an expert on the formalities on how the 
> extentions under the responsibility of SIMPLE are handled and 
> documented, this has to be left to others to comment and decide on.
> >
> > However, a point that I'd like to raise, is that 3GPP would 
> like to get our requirements included into the RFCs as 
> normative requirements that can be expressed as mandatory or 
> optional statements.
> >
> > When requirements described in drafts become WG-items it 
> seems natural to me that such options are seen as general 
> options. Why these options have to be phrased explicitly as 
> options strictly for 3GPP isn't actually what I had expected.
> 
> 1) requirements identified by 3gpp that are also applicable 
> in the internet at large.
> 
> 2) requirements that are only applicable when operating in a 
> 3gpp environment.
> 
> Both kinds can be considered as work items. But it is 
> important for all the people working on these things to 
> understand which is which. 
> Understanding those that are specific to 3gpp typically 
> require a level of understanding of 3gpp that few 
> non-3gpp-affiliated ietf participants have. And when the work 
> eventually leads to an RFC, future readers of that RFC should 
> have that context to help in understanding if the RFC applies to them.
> 
> 	Thanks,
> 	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 15:35:47 +0200

Hi, 

>In this case is a clear delimitation of scope. An implementor 
>should not consider this draft when deploying for the 
>Internet. An implementor for 3GPP must because it is a clear 
>requirement.
> 
>In its current form, this draft may well be adopted for 
>dubious reasons. For example cheap residential router 
>manufacturers will want it so that 'they are MSRP compliant'. 
>They will like the idea to have the same feature of an 
>Ericsson router, which is well implemented but they will not 
>do it good enough and things will break.  With current  MSRP 
>design you cannot break it, by opening this gate of new 
>possibilities of anchoring media things will break 
>guaranteed. There are so many ifs in the specification that 
>if you hire 100 people you will end up with 100 different 
>solutions working in as many different ways.
> 
>This draft must clearly be applied to its scope and no more, 
>to avoid breaking the rest of the MSRP traffic over the Internet.

If you deploy an MSRP endpoint compliant to the draft on the Internet, it is not going to break anything. There will be a fallback to 4975 behavior, and everything will work fine.

Regards,

Christer

> > WRT the title - if this turns out to be the main blocking 
> point, I'm sure that this can be modified, as long as this 
> doesn't restart and alter the technical discussions already 
> held and concluded.
> > 
> > /atle
> > 
> >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 15:42:59 +0200

> It is also useful for MSRP endpoints located in non-ALG networks, when they communicate with MSRP endpoints in networks with ALGs.

Hi Christer, please let's be clear: do you still prefer "ACE" name
over the suggestions made here?
Do you prefer "ACE" over "MSRP media anchoring mechanism for ALGs"?

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

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 15:44:19 +0200

> Eventhough there is a requirement in 3GPP (and OMA) for this, it is not only applicable to 3GPP/OMA.

Then again starting from a 3GPP requirement, you encourage and promote the breaking of the public Internet by legitimate the usage of ALG into the public internet and explain how to do such thing in detail in an IETF specification.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 17:19:40 +0200

Hi,

>Then again starting from a 3GPP requirement, you encourage and promote the breaking of the public Internet 
>by legitimate the usage of ALG into the public internet and explain how to do such thing in detail in an IETF 
>specification.

I encourage people to implement the draft, so that MSRP can be used in networks where ALGs have been deployed.

Because, people are not going to remove the ALGs just in order to be able to run MSRP. That is not based on my decission or "encouragement" - that's a fact based on feedback from customers etc.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 17:23:08 +0200

Hi,

>> But, as Roland also indicated, the draft provides some background text regarding the usage of ALGs in 
>>IMS. There is also an RFC giving some general ALG description.
>>
>>It is also useful for MSRP endpoints located in non-ALG networks, when they communicate with MSRP >>endpoints in networks with ALGs.
>

I will have to go through the suggestions. I also have some suggestions myself.

But, as I said, I am not religious about the name, so I am sure we will find something that we can agree upon :)

Regards,

Christer

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