Subject: [martini] #17: Desirable to align with existing standards

From: "martini issue tracker" <[email-masked]>
Date: Thu, 18 Mar 2010 22:20:39 -0000

#17: Desirable to align with existing standards
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |       Owner:            
     Type:  enhancement              |      Status:  new       
 Priority:  major                    |   Milestone:  milestone1
Component:  reqs                     |     Version:  1.0       
 Severity:  In WG Last Call          |    Keywords:            
-------------------------------------+--------------------------------------
 DES5 - The mechanism SHOULD be aligned as much as possible with mechanisms
 already standardised in other SDO's like ETSI and 3GPP in order to
 prohibit a fragmentation of the market.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/17>
martini <http://tools.ietf.org/martini/>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Mar 2010 12:01:59 +0100

As individual, I would remark that the market is already fragmented between SIP and IMS-SIP, which makes things difficult.

As editor, I seek guidance from others on this one.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of martini issue tracker
> Sent: 18 March 2010 22:21
> To: [email-masked]
> Cc: [email-masked]
> Subject: [martini] #17: Desirable to align with existing standards
> 
>  Reporter:  ietf.hanserik@...          |       Owner:            
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 12:21:02 +0100

SIP = SIP, regardless whether the service provider uses an IMS architecture
or not.

IMS provides a given SIP profile, in a non-IMS setting things are less clear
which is part of the problem we face today.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 12:01 PM, Elwell, John <
[email-masked]> wrote:

> As individual, I would remark that the market is already fragmented between
> SIP and IMS-SIP, which makes things difficult.
>

---

From: "martini issue tracker" <[email-masked]>
Date: Fri, 19 Mar 2010 11:58:01 -0000

#17: Desirable to align with existing standards
-------------------------------------+--------------------------------------
 Reporter:  ietf.hanserik@…          |        Owner:            
     Type:  enhancement              |       Status:  closed    
 Priority:  major                    |    Milestone:  milestone1
Component:  reqs                     |      Version:  1.0       
 Severity:  In WG Last Call          |   Resolution:  invalid   
 Keywords:                           |  
-------------------------------------+--------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 The requirements document notes the issues with existing practices.  There
 are multiple mechanisms already deployed, and each mechanism has one or
 more issues.

 Since it is not possible to simultaneously adopt existing practices
 verbatim and to address the issues with them, the major question is about
 how MARTINI solutions will deviate from existing practice.

 Saying that the solution SHOULD be aligned with existing practice places
 no useful constraints on the solution.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/17#comment:1>
martini <http://tools.ietf.org/martini/>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 13:14:14 +0100

Understood. Still think that it would be good if the different fora talk to
eachother, for the good of industry. Aligning does not mean "adopt" it might
require some changes on both sides.

In that case: "DES4 - The mechanism SHOULD require relatively modest changes
to a substantial population of existing SSP and SIP-PBX implementations, in
order to encourage a fast market adoption of the standardized mechanism. "

Is equally or even more problematic as " require relatively modest changes
to a substantial population of existing SSP and SIP-PBX implementations"
can't be qualified and is highly problematic.  I can raise a TRAC issue to
remove that?

BR,
/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 12:58 PM, martini issue tracker <[email-masked]
> wrote:

> Ticket URL: <
> http://trac.tools.ietf.org/wg/martini/trac/ticket/17#comment:1>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Mar 2010 05:39:14 -0700

Ideally, requirements should be things that we can evaluate a solution against in a straightforward way. 

Whether a solution would require modest or major changes to a given implementation can vary based on the implementation, so determining whether a given solution meets the "modest change" requirement could be difficult to do in an objective way.

My suggestion is that we reformulate this to be more specific.  One way to do this would be to have further discussion about problems that would be considered "deal breakers" for SSPs.  Issues that have already been brought up are things like compatibility with path, outbound, etc.   These are easier to evaluate (e.g. we can require a solution to demonstrate how it would work with path). 

Date: Fri, 19 Mar 2010 13:14:14 +0100
Subject: Re: [martini] #17: Desirable to align with existing standards
From: [email-masked]
To: [email-masked]
CC: [email-masked]; [email-masked]

Understood. Still think that it would be good if the different fora talk to eachother, for the good of industry. Aligning does not mean "adopt" it might require some changes on both sides.

In that case: "DES4 - The mechanism SHOULD require relatively modest changes to a    substantial population of existing SSP and SIP-PBX implementations, in order to encourage a fast market adoption of the standardized mechanism. "

Is equally or even more problematic as " require relatively modest changes to a    substantial population of 
existing SSP and SIP-PBX implementations" can't be qualified and is highly problematic.  I can raise a TRAC issue to remove that?

BR,/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 12:58 PM, martini issue tracker <[email-masked]> wrote:

 Keywords:                           |

  * status:  new => closed

  * resolution:  => invalid

Comment:

 more issues.

--

martini mailing list

[email-masked]

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 19 Mar 2010 13:51:56 +0100

Looks like such reformulation would go more in the direction of actual
requirements. Analogous as the one for GRUU.

/Hans Erik van Elburg

On Fri, Mar 19, 2010 at 1:39 PM, Bernard Aboba <[email-masked]>wrote:

> Whether a solution would require modest or major changes to a given
> implementation can vary based on the implementation, so determining whether
> a given solution meets the "modest change" requirement could be difficult to
> do in an objective way.
>
> My suggestion is that we reformulate this to be more specific.  One way to
> do this would be to have further discussion about problems that would be
> considered "deal breakers" for SSPs.  Issues that have already been brought
> up are things like compatibility with path, outbound, etc.   These are
> easier to evaluate (e.g. we can require a solution to demonstrate how it
> would work with path).
>
> ------------------------------
> In that case: "DES4 - The mechanism SHOULD require relatively modest
> changes to a substantial population of existing SSP and SIP-PBX
> implementations, in order to encourage a fast market adoption of the
> standardized mechanism. "
>

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 21 Mar 2010 15:20:18 +0100

I assume this request is directed at Hans Erik.

John 

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 19 March 2010 14:22
> To: Elwell, John
> Cc: [email-masked]
> Hi,
> could you please provide references to the ETSI and 3GPP 
> specs mentioned
> below?
> 
> Thanks,
> 
> Gonzalo
> 
> On 19/03/2010 1:01 PM, Elwell, John wrote:
> > As individual, I would remark that the market is already 
> fragmented between SIP and IMS-SIP, which makes things difficult.
> >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 21 Mar 2010 09:24:29 -0700

Hi,

well, I do not care who answers as long as the information is sent ;o)

Thanks,

Gonzalo

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 21 Mar 2010 15:41:03 -0500

Hi, Gonzalo,

John had added
   [ETSI TS 182 025]
              "ETSI TS 182 025 "Telecommunications and Internet
              converged Services and Protocols for Advanced Networking
              (TISPAN); Business trunking; Architecture and functional
              description"".as a reference in

http://tools.ietf.org/html/draft-ietf-martini-reqs-02 - I'm not smart about
ETSI, but I had hoped that specification was the appropriate reference :D

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 21 Mar 2010 22:09:35 +0100

Yes, I did reference this, but the nature of that standard (delta to a delta to a delta) is such that it requires a whole lot more digging to identify the specific aspects of the TISPAN/3GPP solution that that are germane to the issues we are talking about. I was hoping that Hans Erik could help us to nail down particular aspects of the solution, with appropriate references, that he believes we need to align with.

John 

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: 21 March 2010 20:41
> To: Gonzalo Camarillo; Elwell, John
> Cc: [email-masked]
> >>>>> Ticket URL: 
> <http://trac.tools.ietf.org/wg/martini/trac/ticket/17>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:12:33 +0100

Hi,

Hi following are the specs related to the subject, where indeed 182 025
contains the protocol solution.

ETSI TS 181 019: "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Business Communication
Requirements".

ETSI TS 182 023: "Telecommunications and Internet Converged Services and
Protocols for Advanced Networking (TISPAN); Core and Enterprise NGN
Interaction Scenarios and Architectural Requirements".

ETSI TS 182 025 "Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN); Business trunking; Architecture
and functional description

3GPP I guess it is 24.229. But others are better equipped to answer that
question.

Best Regards,
/Hans Erik van Elburg

On Sun, Mar 21, 2010 at 9:41 PM, Spencer Dawkins
<[email-masked]>wrote:

>>>>>> [mailto:[email-masked]] On Behalf Of martini
>>>>>>
>>>>> issue tracker
>>>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 22 Mar 2010 10:19:24 +0100

I think that a lot of valid issues have been raised with the existing
proposed solution and I have nothing against solving those. I have a problem
with a solution that can only handle E.164 numbers and can't even deliver
the other variants of calls or requires a completely different solution. And
with that my main concern is the method of constructing the new Request URI.
If people want to use that solution they can do so anyway as it is legal
according to RFC3261, you don't need an RFC for that.

BR,
/Hans Erik van Elburg

On Sun, Mar 21, 2010 at 10:09 PM, Elwell, John <
[email-masked]> wrote:

> Yes, I did reference this, but the nature of that standard (delta to a
> delta to a delta) is such that it requires a whole lot more digging to
> identify the specific aspects of the TISPAN/3GPP solution that that are
> germane to the issues we are talking about. I was hoping that Hans Erik
> could help us to nail down particular aspects of the solution, with
> appropriate references, that he believes we need to align with.
>
> John
>

---

From: <[email-masked]>
Date: Mon, 22 Mar 2010 10:55:18 +0100

Yes the method of constructing the new Request URI is the main concern. If the GIN draft is adopted as a basis for the IETF solution and is not modified on that point, a PBX will find different things in the Request URI of inbound requests depending on whether it is connected to an IMS or a GIN-based network. I don't believe that's what the Industry is looking for.

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Hans Erik van Elburg
	Envoyé : lundi 22 mars 2010 10:19
	À : Elwell, John
	Cc : [email-masked]
	Objet : Re: [martini] #17: Desirable to align with existing standards

	I think that a lot of valid issues have been raised with the existing proposed solution and I have nothing against solving those. I have a problem with a solution that can only handle E.164 numbers and can't even deliver the other variants of calls or requires a completely different solution. And with that my main concern is the method of constructing the new Request URI. If people want to use that solution they can do so anyway as it is legal according to RFC3261, you don't need an RFC for that.
	
	BR,
	/Hans Erik van Elburg

	On Sun, Mar 21, 2010 at 10:09 PM, Elwell, John <[email-masked]> wrote:

		John

---

From: Dean Willis <[email-masked]>
Date: Mon, 22 Mar 2010 13:18:28 -0500

[email-masked] wrote:
> Yes the method of constructing the new Request URI is the main concern.
> If the GIN draft is adopted as a basis for the IETF solution and is not
> modified on that point, a PBX will find different things in the Request
> URI of inbound requests depending on whether it is connected to an IMS
> or a GIN-based network. I don't believe that's what the Industry is
> looking for.
> 

If anybody bothered to adopt the IMS model, then a PBX would find
different things in the request URI depending on whether it registered
multiple AORs conventionally using RFC 3261 or used this "implicit bulk
registration" hack.

I don't believe that's what the industry is looking for.

I AM in favor of fixing RFC 3261's rather broken proxy contact-routing
model. MARTINI is not the place to do this; it's a much bigger problem
than we're chartered for (and no, IMS doesn't currently fix this in the
general case either -- it did a special-case bandaid that it a different
special-case than the one raised by SIP Forum).

--
Dean

---

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Mon, 22 Mar 2010 14:28:54 -0400

Disagree Dean. There is an IMS model which is being standardized, and to
that Bruno is correct. Then there is a non-IMS, where we already know
how to do this today.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Monday, March 22, 2010 2:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [martini] #17: Desirable to align with existing standards