Subject: [Simple] Suggestion for sessmatch draft

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 16:24:44 +0200

After long threads about issues with this draft, I'd would like to
propose the following:

- Rewrite the draft from scratch by just keeping the "sessmatch"
mechanism itself (don't match full URI but just the sessmatch
identifier in it).

- Remove from the draft any mention to ALG's (as they shouldn't be
considered in a IETF document, they are an "anomaly" in the IP world).

- The draft would be 4-5 lines long. It would be very easy for all the
implementations to update and support it.

- Make the new RFC to update RFC 4975 and 4976.

- Let OMA/RCS/IMS/3GPP (or any other walled warden in which a
"presence" NOTIFY is charged to the user) specify in an own document
the usage of ALG's and the changes to IETF's MSRP specs their devices
must accomplish in order to work within their closed networks.

- Promote the usage of IPv6 so this kind of aberrations won't take
place anymore.

- Ask the router manufactures not to include SIP and MSRP ALG
"feature" in their boxes.

- Promote the usage of SIP over TLS as router manufactures will still
want a label "SIP+MSRP powered" in their products, and SIP over TLS is
the only way to avoid them.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 16:31:52 +0200

Hi, 

>After long threads about issues with this draft, I'd would like to propose the following:
>
>mechanism itself (don't match full URI but just the sessmatch identifier in it).
>
>- Remove from the draft any mention to ALG's (as they shouldn't be considered in a IETF document, they are an "anomaly" in the IP world).

ALGs are the main justification for sessmatch, so I have been asked to include that.

If I remove it, what would your justification for sessmatch be?

>- The draft would be 4-5 lines long. It would be very easy for all the implementations to update and support it.
>

There was a WG decission to NOT to that.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 16:32:48 +0200

> considered in a IETF document, they are an "anomaly" in the IP world).

If we would do the above then there is no reason for the existence of sessmatch. Sessmatch is needed by ALGs, so they need to be mentioned.

As I said earlier, the only way I think everything will continue to work is by making the fallback to B2BUA capability a MUST. This way ALGs  and users behind them will use sessmatch and whose who are outside may not, but they would still interoperate.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 May 2011 09:35:18 -0500

(as individual)

> implementations to update and support it.

Ironically, that's about where this started.

The reason for the discussions about ALGs in the draft, was to motivate the draft, and to attempt to show that current ALG/SBC behavior would actually be helped by it. We have been hampered by the fact, as you mention elsewhere, that there is no standard for ALGs or SBCs other than defacto behavior.

So, without documentation of assumptions about ALGs/SBCs, how do we answer the following:

1) What problem does this draft attempt to solve?
2) Does this draft actually solve that problem?

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:38:09 +0200

> If I remove it, what would your justification for sessmatch be?

None, actually. We tried to solve the wrong problem for the wrong reasons in the wrong place, an IETF working Group. We failed. So what? Better failing on doing it rather than succeeding and making everything fall apart later.

There is no excuse for breaking things when you know already your are going to break them if you continue doing it.

Now we have active MSRP deployments, when your draft started you thought they were not going to be any MSRP 4975/4976 deployments any time soon. Well, that assumption was wrong too.

The fact that the WG took some decisions in the past, ALGs exists or not, is not an excuse to demolish RFC 4975 and 4976 that work just fine.

Adrian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 16:44:00 +0200

Hi, 

>None, actually. We tried to solve the wrong problem for the wrong reasons in the wrong place, an IETF working Group. We failed. So what? Better failing 
>on doing it rather than succeeding and making everything fall apart later.

We are solving the problem where ALGs have to act as MSRP B2BUAs in order to support anchoring of MSRP media, and I have seen no failure.

>There is no excuse for breaking things when you know already your are going to break them if you continue doing it.

It's not going to break anything that isn't already broken.

>The fact that the WG took some decisions in the past, ALGs exists or not, is not an excuse to demolish RFC 4975 and 4976 that work just fine.

I am not suggesting to demolish anything.

RFC 4975 and 4976 does not work fine with ALGs.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 16:44:28 +0200

> 1) What problem does this draft attempt to solve?

None. If we consider ALGs, then the answer would be the manufacturers inability to implement the right solution, that is, a B2BUA for MSRP.

> 2) Does this draft actually solve that problem?

If we consider there is a problem in point 1), partially, since it adds new problems.

3) Does this draft introduce any new problems?

Yes. I breaks interoperability with RFC 4975/4976 endpoints.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 25 May 2011 16:44:36 +0200

> 2) Does this draft actually solve that problem?

Yes, you all are 100% right here. My motivations are the following:

- It's true (in fact I've said it before several times) that Sessmatch
is useless if we ignore ALG's. I just proposed to make it a standard
(which supposes 4 lines of code in each MSRP entity) to allow
OMA/RCS/3GPP to make usage of it within their networks and their
specifications.

- ALG's will break RFC 4975 and 4976 (when acting as ALG's) so it
doesn't matter the existence of an IETF spec describing it. Don't let
the vendors say "Yes, I break MSRP but I'm based on a RFC".

Of course I could be wrong and my suggestion be just a stupid proposal, sure :)

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:44:48 +0200

The places where this proposed draft can see deployments is only in walled gardens that do not need an IETF endorsement. Those bodies can make an internal note/document which becomes mandatory for their vendor supply chain. There are many changes already described in SIP, XCAP and other protocols in those walled gardens.

We do not need to pass an IETF document to break exiting well established MSRP protocols proven to be working fine for this.

OMA/3GPP can simply make a change to exiting MSRP protocol to have their walled gardens implemented. If they ever want to get out of their walled garden, their vendor must deploy a gateway to Internet.

This does not break anything.

On May 25, 2011, at 4:35 PM, Ben Campbell wrote:

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

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 16:47:34 +0200

> RFC 4975 and 4976 does not work fine with ALGs.

This is not an excuse to break the RFCs. This should open your eyes that the ALGs must disappear not otherwise.

These things cannot cohabit together. 

This is IETF and the RFCs work just fine.

The ALGs do not belong here, take the problem some places else.

Adrian

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 16:49:38 +0200

> RFC 4975 and 4976 does not work fine with ALGs.

Since the behavior for an ALG is not specified anywhere how can you ensure that? A vendor could very well use a SIP ALG and a MSRP Relay and there would be no issues.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 17:06:02 +0200

>This is not an excuse to break the RFCs. 

I am not breaking the RFCc. I am defining an extension which will not break anything that works today.

>This should open your eyes that the ALGs must disappear not otherwise.

It doesn't matter what my eyes see - ALGs will not disappear.

>The ALGs do not belong here, take the problem some places else.

It belongs in draft-ietf-simple-msrp-sessmatch. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 17:09:00 +0200

Hi, 

>From my experience, I know that most ALGs don't implement MSRP B2BUA functionality.

I also know that customers don't want to deploy MSRP specific relays - at least not if they also provide other types of media.

But, I'm happy to be proven wrong.

Regards,

Christer

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 25 May 2011 17:10:11 +0200

This draft should not exist. It solves no Internet related problem. It solves particular interests of some walled-garden providers not connected to the Internet.

IETF has nothing to do with this.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 17:16:44 +0200

> But, I'm happy to be proven wrong.

Can you ensure this will always be true? No. So the specification needs to take the case I described into account. The breakage this draft introduces is severe enough not to base decisions on what anyone may think about what customers want. They may want something else tomorrow.

--
Saúl Ibarra Corretgé
AG Projects

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 17:34:51 +0200

>IETF has nothing to do with this.

In this case, there is nothing which prevents what we specify to be used outside "walled gardens".

In general, there is also an agreement between 3GPP and IETF that you may want to take a look at.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 May 2011 17:39:54 +0200

>>> Since the behavior for an ALG is not specified anywhere how can you 
>>> ensure that? A vendor could very well use a SIP ALG and a MSRP Relay and there would be no issues.
>> 
>Can you ensure this will always be true? 

Of course not. But, I do know that it is true for now, and will be true for a considerable time to come - at a time when people are requesting the functionality.

And, if people then in future suddenly start to deploy MSRP B2BUAs things whill still work.

>No. So the specification needs to take the case I described into account. The breakage this draft introduces is severe enough not to base decisions on 
>what anyone may think about what customers want. They may want something else tomorrow.

I still doesn't think it breaks anything that isn't broken already.

Regards,

Christer

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Wed, 25 May 2011 17:45:34 +0200

> Of course not. But, I do know that it is true for now, and will be true for a considerable time to come - at a time when people are requesting the functionality.

Then lets make a solution that works for all.

> I still doesn't think it breaks anything that isn't broken already.

I strongly disagree. If a ALG modifies the SDP in whatever way without touching the path line it will just work with 4975/4976, today. The fact that some networks where ALGs are deployed block direct traffic is not relevant, that's a network issue, not related to what the ALG does.

--
Saúl Ibarra Corretgé
AG Projects