Re: [martini] Consensus call: Resolution of Ticket #57

"Andrew Allen" <aallen@rim.com> Fri, 03 September 2010 07:13 UTC

Return-Path: <aallen@rim.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF6C3A67FA for <martini@core3.amsl.com>; Fri, 3 Sep 2010 00:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.43
X-Spam-Level:
X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4veBHDCpubaO for <martini@core3.amsl.com>; Fri, 3 Sep 2010 00:13:51 -0700 (PDT)
Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 6DB5D3A67F6 for <martini@ietf.org>; Fri, 3 Sep 2010 00:13:51 -0700 (PDT)
X-AuditID: 0a666446-b7b69ae000002759-82-4c80a04c7f03
Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id DE.4E.10073.C40A08C4; Fri, 3 Sep 2010 03:14:20 -0400 (EDT)
Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Sep 2010 03:14:19 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
Date: Fri, 03 Sep 2010 02:14:16 -0500
Message-ID: <BDBFB6CE314EDF4CB80404CACAEFF5DE04D8624B@XCH02DFW.rim.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA01C48DB925@MCHP058A.global-ad.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [martini] Consensus call: Resolution of Ticket #57
Thread-Index: ActGKlJngWbYSdI3SPmaz/craiFnNwElTtTgAB4EEEs=
From: Andrew Allen <aallen@rim.com>
To: john.elwell@siemens-enterprise.com, martini@ietf.org
X-OriginalArrivalTime: 03 Sep 2010 07:14:19.0193 (UTC) FILETIME=[A0200A90:01CB4B37]
X-Brightmail-Tracker: AAAAAwAAAZEV26rdFdxz8g==
Subject: Re: [martini] Consensus call: Resolution of Ticket #57
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Sep 2010 07:13:53 -0000

John

What is the "too high bar" that supporting public GRUU represents? 

As was discussed during the IETF session public GRUU implementation is straight forward (and everyone seemed to agree that). 

Temporary GRUU is more complex but the proposed wording allows for other mechanisms to be used in place of temporary GRUUs provided they don't break use of public GRUUs.

Can someone outline what the concern with supporting Public GRUU is and why this would prevent SSPs implementing suppirt for GIN?

Andrew

----- Original Message -----
From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
Sent: Thursday, September 02, 2010 01:03 PM
To: martini@ietf.org <martini@ietf.org>
Subject: Re: [martini] Consensus call:  Resolution of Ticket #57

I think what is paramount here is the ability for gin to gain traction in the market place. Although in Maastricht I agreed to this resolution, along with the other people in the room at the time, I had earlier in the meeting expressed a concern about raising the bar too high for SSPs to adopt gin. If SSPs are happy to keep support for public GRUU as a MUST, that is fine with me. But if SSPs say this raises the bar too high and they will not be able to implement gin within a reasonable timescale, I am concerned.

I know GRUU is needed to support attended transfer using REFER/Replaces. It is also required to support transfer using REFER on a new dialog. However, transfer between domains is generally done by 3PCC means (re-INVITE), because of security / charging concerns about acting on a REFER request from another domain. In my opinion public GRUU is not a necessary component of a basic, entry level SIP interface between SIP-PBX and SSP.

John


> -----Original Message-----
> From: martini-bounces@ietf.org 
> [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
> Sent: 27 August 2010 21:56
> To: martini@ietf.org
> Subject: [martini] Consensus call: Resolution of Ticket #57
> 
> In the MARTINI WG second session at IETF 78, the participants 
> in the room came to consensus (12-0) on the following text to 
> resolve Issue 57:
> 
> In order to provide support for privacy, the SSP
> SHOULD implement the temporary GRUU
> mechanism described in this section. Reasons for
> not doing so would include systems with an
> alternative privacy mechanism which maintains
> the integrity of public GRUUs (i.e., if public
> GRUUs are anonymized then the anonymizer
> function would need to be capable of providing as
> the anonymized URI a globally routable URI
> that routes back only to the target identified by
> the original public GRUU).
> 
> We are now bringing this resolution to the mailing list to 
> verify that consensus. 
> 
> If you did not express your opinion during the IETF 78 
> MARTINI WG meeting, and would like to do so now, please 
> respond to this email and post your opinion as to whether you 
> agree with the text above as a resolution to Issue 57. 
> 
> This consensus call will last until September 12, 2010.  
> 
> 
_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.