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

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 02 September 2010 17:03 UTC

Return-Path: <john.elwell@siemens-enterprise.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 E8D8D3A6958 for <martini@core3.amsl.com>; Thu, 2 Sep 2010 10:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.698
X-Spam-Level:
X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 zDvrKF8k3oyr for <martini@core3.amsl.com>; Thu, 2 Sep 2010 10:03:04 -0700 (PDT)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id ADD293A682A for <martini@ietf.org>; Thu, 2 Sep 2010 10:03:03 -0700 (PDT)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1375077 for martini@ietf.org; Thu, 2 Sep 2010 19:03:32 +0200
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 4566D1EB82AB for <martini@ietf.org>; Thu, 2 Sep 2010 19:03:32 +0200 (CEST)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 2 Sep 2010 19:03:32 +0200
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "martini@ietf.org" <martini@ietf.org>
Date: Thu, 02 Sep 2010 19:03:30 +0200
Thread-Topic: [martini] Consensus call: Resolution of Ticket #57
Thread-Index: ActGKlJngWbYSdI3SPmaz/craiFnNwElTtTg
Message-ID: <A444A0F8084434499206E78C106220CA01C48DB925@MCHP058A.global-ad.net>
References: <BLU137-W878D9ABB4B6A396E0682493860@phx.gbl>
Keywords: MARTINI
In-Reply-To: <BLU137-W878D9ABB4B6A396E0682493860@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 02 Sep 2010 17:03:05 -0000

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.  
> 
>