Subject: [Simple] Draft new version: ACE - the extension previously known as sessmatch

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Jun 2011 17:31:29 +0200

Hi,

In order for people to easier understand, and get a full picture of the new alternative sessmatch mechanism, now known as ACE, we have submitted a new version (-12) of the draft-ietf-simple-msrp-sessmatch (for administrative reasons the draft name still contains sessmatch), which tries to describe it.

Happy reading :)

Regards,

Christer

---

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

2011/6/9 Christer Holmberg <[email-masked]>:
> In order for people to easier understand, and get a full picture of the new
> alternative sessmatch mechanism, now known as ACE, we have submitted a new
> version (-12) of the draft-ietf-simple-msrp-sessmatch (for administrative
> reasons the draft name still contains sessmatch), which tries to describe
> it.

Hi, honestly I don't like the name ACE. It's too "cool". I don't think
this strange specification (involving ALG's and so....) deserves such
a cool and short name. I wouldn't like people confusing ICE with ACE,
neither I'd like people thinking that "ACE" is a cool new feature (as
it's just a specification for making big vendors happy in their wallen
gardens).

Also, the title of the draft "Alternative Connection Establishment
(ACE) for MSRP" says nothing about ALG's.

Don't take me wrong, please, but I strongly would prefer some draft name like:

  "ALG Aware Connection Mechanism for MSRP"

This is:
- Don't create a new cool abbreviation (as this is not a cool protocol
or feature for Internet).
- Include the word "ALG" in the title.

Regards.

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

---

From: Adrian Georgescu <[email-masked]>
Date: Thu, 9 Jun 2011 18:35:37 +0200

After having already MSRP Alternative Connection Model, having yet another MSRP Alternative Connection Establishment is a very confusing set of terms.

An outsider will look at MSRP protocol and two of its alternative mechanisms, what will he understand of this!? Which alternative of the alternative shall one use to build an MSRP client? An alternative to what?  

Is a ridicule name.

On Jun 9, 2011, at 5:31 PM, Christer Holmberg wrote:

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

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Fri, 10 Jun 2011 07:28:42 -0400

AT&T supports name "ACE", and feels this work needs to move forward, now.

Thank you,

Martin Dolly
Lead Member Technical Staff
Core & Government/Regulatory Standards
AT&T Services, Inc.
[email-masked]
+1-609-903-3360

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Thursday, June 09, 2011 12:05 PM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch

This is:

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 13:37:51 +0200

> AT&T supports name "ACE", and feels this work needs to move forward, now.

Dolly, could you please reply to the arguments Adrian and me have
exposed against "ACE" name? just ignoring them doesn't seem very
polite.

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

---

From: "DOLLY, MARTIN C (ATTSI)" <[email-masked]>
Date: Fri, 10 Jun 2011 07:42:05 -0400

It is a name, please get over it.

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: Friday, June 10, 2011 7:38 AM
To: DOLLY, MARTIN C (ATTSI)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [Simple] Draft new version: ACE - the extension previously known as sessmatch

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

---

From: Adrian Georgescu <[email-masked]>
Date: Fri, 10 Jun 2011 13:57:48 +0200

This name creates the ultimate confusion of having 3 ways to using MSRP protocol with the last one incompatible with the previous ones.

This draft is addressing OMA/ALG style deployments only where only pieces of MSRP protocol are being used and not the usage of MSRP protocol over the open Internet.

The title of this draft should reflect this simple fact.

Adrian

---

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

> It is a name, please get over it.

So you want promote the existence of two specifications with these names:

  1) MSRP Alternative Connection Model
  2) MSRP Alternative Connection Establishment

I think they are confusing enough, do you?

PS: This is not Twitter, you are able to write mails longer than 1-2
lines. Take your time please, as the rest of people here.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 10 Jun 2011 14:18:23 +0200

Hi,

> In order for people to easier understand, and get a full picture of the new alternative sessmatch mechanism, now known as ACE, we have submitted a new version (-12) of the draft-ietf-simple-msrp-se…

I didn't have the time to go through all of it, but since the title doesn't seem to be appropriate for everyone I'll throw my 2 cents.

ACE feels too generic, like ACM, which could be confusing. Also, ACE requires ACM so an alternative needs an alternative, which sounds a bit weird.

I'd suggest something along these lines: "MSRP media anchoring mechanism for ALGs".

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 14:27:36 +0200

2011/6/10 Saúl Ibarra Corretgé <[email-masked]>:
> "MSRP media anchoring mechanism for ALGs"

Great name: descriptive and focused to its real scenario.

Please Christer, consider it ;)

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 14:34:18 +0200

Hi, 

>I didn't have the time to go through all of it, but since the 
>title doesn't seem to be appropriate for everyone I'll throw 
>my 2 cents.
> 
>ACE feels too generic, like ACM, which could be confusing. 
>Also, ACE requires ACM so an alternative needs an 
>alternative, which sounds a bit weird.

Actually, ACE as such does not require ACM. However, as is described in the draft, ACM further adds cases where it will be possible to use ACE, without the ALG having to enable MSRP B2BUA functionlaity.

Personally I don't see why it would be strange for one extension to require support of another (there are many other examples of that). 

But, if people have problems to mandate support of ACM, I have no problem to change it to "SHOULD" or "STRONGLY RECOMMENDED".

But, considering the advantages that ACM brings, I would like to get some justification for such change.

>I'd suggest something along these lines: "MSRP media anchoring mechanism for ALGs".

I am not religious regarding the name. 

I just think it's weird to base arguments on a "coolness" comparison between a draft name and a draft content...

Regards,

Christer

---

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

Hi, 

>Please Christer, consider it ;)

I am considering any proposal which helps bringing the work forward :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 14:37:39 +0200

> I just think it's weird to base arguments on a "coolness" comparison between a draft name and a draft content...

The draft title must represent the draft content. If the content
clearly talks about scenarios with ALG's, and such devices are out of
the scope of "pure" internet, I strongly think that the draft title
should notice it.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 10 Jun 2011 14:38:40 +0200

Hi,

> Personally I don't see why it would be strange for one extension to require support of another (there are many other examples of that). 

The reason I said that is because both begin with "Alternate Connection" not because of the fact that both are extensions. I actually think that this new spec should mandate ACM.

> I just think it's weird to base arguments on a "coolness" comparison between a draft name and a draft content...

My argument base if not coolness, is the fact that it could be confusing for newcomer implementors.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 10 Jun 2011 14:42:09 +0200

To be honest, I do not really care about the name of this specification.
If you want to call it ACM, you can and should explain the relationship, e.g. to the MSRP Alternative Connection Model in the abstract of the specification.

What seems to be more important is the following question:

Lets assume the following model:
MSRP endpoint A -> combination of NATs, MSRP-Proxies, ALGs -> MSRP endpoint B.

Is there any combination of NATs, MSRP-Proxies and ALGs where 
- a MSRP connection is successful (with both MRSP endpoints acting according RFC4975)
- a MSRP connection is not successful due to the fact, that one or both MRSP endpoints acts according this ACE specification?

Regards
Christian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 14:43:16 +0200

Hi, 

>> Actually, ACE as such does not require ACM. However, as is 
>> described in the draft, ACM further adds cases where it will 
>> be possible to use ACE, without the ALG having to enable MSRP 
>> B2BUA functionlaity.
>> 
>> Personally I don't see why it would be strange for one 
>> extension to require support of another (there are many other 
>> examples of that). 
>> 
> 
>The reason I said that is because both begin with "Alternate 
>Connection" not because of the fact that both are extensions. 
>I actually think that this new spec should mandate ACM.

Ok.

>> But, if people have problems to mandate support of ACM, I 
>> have no problem to change it to "SHOULD" or "STRONGLY RECOMMENDED".
>> 
>> But, considering the advantages that ACM brings, I would 
>> like to get some justification for such change.
>> 
>> I just think it's weird to base arguments on a "coolness" 
>> comparison between a draft name and a draft content...
>>  

My comment was not against you. Sorry for the confusion.

Regards,

Christer

---

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

The title of the document must describe its function so people who deploy on the Internet do not need to look at it. This short title can for example explain what it does and why:

"MSRP media anchoring for 3GPP deployments"

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 14:44:52 +0200

Hi Christian,

Before I try to address your question, could you clarify what you mean by MSRP-Proxy. Do you mean MSRP relay? 

Regards,

Christer

> From: Schmidt, Christian 1. (NSN - DE/Munich) 
> [mailto:[email-masked]] 
> Sent: 10. kesäkuuta 2011 15:42
> To: ext Iñaki Baz Castillo; DOLLY, MARTIN C (ATTSI); Christer Holmberg
> Cc: [email-masked]
> Subject: RE: [Simple] Draft new version: ACE - the extension 
> previously known as sessmatch
> 
> If you want to call it ACM, you can and should explain the 
> relationship, e.g. to the MSRP Alternative Connection Model 
> in the abstract of the specification.
> 
> - a MSRP connection is not successful due to the fact, that 
> one or both MRSP endpoints acts according this ACE specification?
> 
> Regards
> Christian
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Iñaki Baz Castillo
> PS: This is not Twitter, you are able to write mails longer 
> than 1-2 lines. Take your time please, as the rest of people here.
> 
> 
> --
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 10 Jun 2011 09:17:25 -0500

(replying to thread in general, not specifically to Iñaki's email)

While the naming conversation is "interesting", I'd like to remind people that there are technical aspects of this draft that need to be considered as well. Or should I assume that if we agree on a name, everyone agrees with the _rest_ of the draft? ;-)

Thanks!

Ben.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 10 Jun 2011 16:46:49 +0200

> - a MSRP connection is not successful due to the fact, that one or both MRSP endpoints acts according this ACE specification?

IMHO the draft should clarify all those scenarios *in detail*.
Honestly I don't have the strength to simulate and analyze them.

Depending on the results we would know whether this draft breaks
something (I mean something already working just with RFC 4975/4976)
or not. Further discussions will happen then.

Personally, if it breaks nothing I'm happy. I will just ignore this
specification and hopefully this specification will ignore me for the
rest of my days. The remaining issue would be, of course, the draft
title. Arguments already exposed in these mail threads. My main points
are:

- This is not a cool/useful spec for Internet, so don't use a "cool"
name/abbreviation. It does not deserve it.
- The draft name should clearly reference walled gardens scenarios, so
implementors in pure internet can discard it without having to read
the draft content.

Best regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2011 18:43:55 +0200

Hi,

>>While the naming conversation is "interesting", I'd like to remind people that there are technical aspects of this draft that need to 
>>be considered as well. Or should I assume that if we agree on a name, everyone agrees with the _rest_ of the draft? ;-)
>

All combinations will work, but there are cases where an ALG still needs to enable MSRP B2BUA functionality.

Those cases are basically where (in the presence of an ALG) an RFC 4975 entity becomes "active", ie cases where a 4975 UA or a 4976 relay establishes the MSRP TCP connection.

There are no impacts regarding NATs.

>or not. Further discussions will happen then.

Everything that works today will continue to work.

Also, there is probably text in the draft that can be further simplified. The main focus of version -12 was to describe the mechanism, so that it is easier for people go get a picture of it.

>name/abbreviation. It does not deserve it.

In order to be really cool it would have to be the name of an alcoholic drink. The only "ACE" drink I could find was an energy drink and a vitamine juice :)

>implementors in pure internet can discard it without having to read

I really hope that implementors don't do implementation decissions purely based on draft titles... :)

Regards,

Christer

---

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

Hi Ben,

No person on this mailing list can claim to understand the consequences of the act of legitimating the insertion of a intermediate in the path of an end-to end protocol like MSRP.  

MSRP sess-match does exactly this act.

This act leads to non-deterministic behavior. 

For this reason alone, this aberration must be confined to the environment where vendors and their customers  (3GPP OMA deployments in this very case) can fix the problems and a standardization body like IETF cannot be made responsible for creating such aberration as a standard for how things work on the open Internet.

I assume that what 3GPP and IETF have agreed to do together in terms of standardization is not a blank check for destroying every other work that has been done previously in the IETF for the sake of some vendors selling equipment to closed IP networks. If it is, then of course I will stop complaining uselessly and barking at trees.

Adrian

---

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

Hi,

>No person on this mailing list can claim to understand the consequences of the act of legitimating the insertion >of a intermediate in the path of an end-to end protocol like MSRP.
>
>For this reason alone, this aberration must be confined to the environment where vendors and their 
>customers  (3GPP OMA deployments in this very case) can fix the problems and a standardization body like 
>IETF cannot be made responsible for creating such aberration as a standard for how things work on the open 
>Internet.
>
>I assume that what 3GPP and IETF have agreed to do together in terms of standardization is not a blank 
>check for destroying every other work that has been done previously in the IETF for the sake of some 
>vendors selling equipment to closed IP networks. If it is, then of course I will stop complaining uselessly and 
>barking at trees.

There is no blank check. 

For example, people have indicated that there needs to be a backward compability story - which the draft tries to describe. The very first version of the mechanism (at that time still part of the ACM draft) did NOT provide backward compability, and was rejected by the WG.

Also keep in mind that some of the "closed IP networks" are conneted to the Internet, and/or to other networks with 4975 endpoints, so it is also in their interest to know how to provide backward compability.

Last, the main reason behind the mechanism has been known from the beginning, when the SIMPLE milestone was created. It has never been a "secret".

Regards,

Christer

---

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

Hi,

Another example showing that we're not talking about a "blank check" is the conserns people raised due to the fact that name based authentication didn't work with the previuos version. 

3GPP provides other authentication mechanisms, but people still wanted that the main authentication mechanism of 4975 should still work. There may also be other parts of the security considerations that don't apply to 3GPP.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Friday, June 10, 2011 9:32 PM
To: Adrian Georgescu; Ben Campbell
Cc: Simple WG
Subject: Re: [Simple] Draft new version: ACE - the extension    previously      known as sessmatch

Hi,

There is no blank check.

Regards,

Christer

---

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

> For example, people have indicated that there needs to be a backward compability story - which the draft tries to describe. The very first version of the mechanism (at that time still part of the A…

After +200 emails do you honestly think there is a clear cut here?

> Also keep in mind that some of the "closed IP networks" are conneted to the Internet, and/or to other networks with 4975 endpoints, so it is also in their interest to know how to provide backward c…

There is always a gateway between such environment. A B2BUA for both signaling and media. There is no need for other mechanism to be specified between the two.

> Last, the main reason behind the mechanism has been known from the beginning, when the SIMPLE milestone was created. It has never been a "secret".

Yes, but the nature of this act emerged once people started zooming on it. And it reveals all the signs of poor design decisions that can later break things with no one being accountable anymore. 

So if this solves a problem for a particular  environment where specific assumptions were made is fine but coin as such. Do not call it a generic mechanism for Internet usage. 

Adrian

---

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

Hi,

>There is always a gateway between such environment. A B2BUA for both signaling and media. There is no need for other mechanism to be specified between the two.

First, it is not true that there is always a B2BUA for both signaling and media between the networks. It depends on many things, related to both protocols and trust policies.

Second, the mechanism allows such gateway not to enable MSRP B2BUA functionality in all cases. It consumes as much resources in a gateway as in any other node.

>So if this solves a problem for a particular  environment where specific assumptions were made is fine but coin as such. Do not call it a generic mechanism for Internet usage.

Based on previous discussions, the document describes assumptions on how ALGs behave in environments where the mechanism is used. 

Regards,

Chrsiter

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 14 Jun 2011 09:16:52 +0200

Hi,

> In order for people to easier understand, and get a full picture of the new alternative sessmatch mechanism, now known as ACE, we have submitted a new version (-12) of the draft-ietf-simple-msrp-se…

Some comments after a first read:

Section 1, paragrapth 2: "that anchor and controls" -> "that anchor and control"

Section 1, paragraph 3: Instead of saying that MSRP does not work I think it would be more correct to say that the MSRP media can't be anchored.

Section 1, paragraph 3: "topmost SDP a=path", mentioning that the a=path may come in form of a single line and that in such case the leftmost URI applies would be nice.

Section 1, paragraph 4: "that in certain cases", now it's in most cases, right?

Section 1, paragraph 4: "ALGs that anchor the MSRP connection", what about: "ALGs that want to anchor the MSRP media"

Section 1, paragraph 4: "can use the SDP c/m line" -> "will use the SDP c/m line"

I'm a bit concerned about the use of the a=setup attribute here. If Alice calls Bob (both supporting ACE), will the ALG modify the setup attribute? Also, Section 4.2 says that if a relay is being used, a=setup: passive MUST be used, which is forbidden by RFC6135 (sec 4.2.2). Thus, if a non-ACE endpoint receives such a request it will reject it. AFAIS this was added to avoid using B2BUA mode, but it doesn't really help. The best-effort solution would be to use 'actpass' instead and hope for the other end to become active. Else, I guess a mention about this change to RFC6135 needs to be added somewhere.

Section 5, paragraph 1: "networks where ALGs are present", I'd like to see a mention to the fact that those ALGs want to anchor media.

Those are my 2 cents for now.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Jun 2011 11:09:10 +0200

Hi Saul, 

Comments inline.

---------

>Section 1, paragrapth 2: "that anchor and controls" -> "that 

I'll fix as suggested.

---------

>Section 1, paragraph 3: Instead of saying that MSRP does not 
>work I think it would be more correct to say that the MSRP 
>media can't be anchored.

I'll fix as suggested.

---------

>Section 1, paragraph 3: "topmost SDP a=path", mentioning that 
>the a=path may come in form of a single line and that in such 
>case the leftmost URI applies would be nice.

I am not sure we normally say that, because it's according to the ABNF rules.

---------

>Section 1, paragraph 4: "that in certain cases", now it's in 

Yes. I'll fix that.

---------

>Section 1, paragraph 4: "ALGs that anchor the MSRP 
>connection", what about: "ALGs that want to anchor the MSRP media"

I'll fix as suggested.

---------

>Section 1, paragraph 4: "can use the SDP c/m line" -> "will 

I'll fix as suggested.

---------

>I'm a bit concerned about the use of the a=setup attribute 
>here. If Alice calls Bob (both supporting ACE), will the ALG 
>modify the setup attribute? Also, Section 4.2 says that if a 
>relay is being used, a=setup: passive MUST be used, which is 
>forbidden by RFC6135 (sec 4.2.2). Thus, if a non-ACE endpoint 
>receives such a request it will reject it. AFAIS this was 
>added to avoid using B2BUA mode, but it doesn't really help. 
>The best-effort solution would be to use 'actpass' instead 
>and hope for the other end to become active. Else, I guess a 
>mention about this change to RFC6135 needs to be added somewhere.

Good point.

Eventhough I don't think it really matters, since the draft defines a fallback mechanism, the intention is not to break RFC 6135, so I'll change it to "actpass".

--------- 

>Section 5, paragraph 1: "networks where ALGs are present", 
>I'd like to see a mention to the fact that those ALGs want to 
>anchor media.

I'll fix that. 

---------

Thank You for the comments! :)

Regards,

Christer