Re: [martini] Call for Consensus: Support for Public GRUUs

Paul Kyzivat <pkyzivat@cisco.com> Mon, 30 August 2010 13:37 UTC

Return-Path: <pkyzivat@cisco.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 16ACD3A680B for <martini@core3.amsl.com>; Mon, 30 Aug 2010 06:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level:
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 oYHAFN8s-znf for <martini@core3.amsl.com>; Mon, 30 Aug 2010 06:37:11 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 41E863A6811 for <martini@ietf.org>; Mon, 30 Aug 2010 06:37:11 -0700 (PDT)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAFJRe0xAZnwM/2dsb2JhbACDFo9ijU1xn0CJbZEkgSKDInMEigk
X-IronPort-AV: E=Sophos;i="4.56,292,1280707200"; d="scan'208";a="153246426"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 30 Aug 2010 13:37:42 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7UDbfCO022876; Mon, 30 Aug 2010 13:37:41 GMT
Message-ID: <4C7BB425.1010200@cisco.com>
Date: Mon, 30 Aug 2010 09:37:41 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <BDBFB6CE314EDF4CB80404CACAEFF5DE04D861FE@XCH02DFW.rim.net> <4C7ACC34.9060100@nostrum.com>
In-Reply-To: <4C7ACC34.9060100@nostrum.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: bernard_aboba@hotmail.com, martini@ietf.org
Subject: Re: [martini] Call for Consensus: Support for Public GRUUs
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: Mon, 30 Aug 2010 13:37:13 -0000

+1

Adam Roach wrote:
> 
> I agree with Andrew on this point
> 
> The key issue in my mind is deployability. With a single registrar, 
> deployment of GRUUs is a fairly tractable problem: once the registrar 
> supports GRUUs, then clients can start making use of them. When we start 
> having more entities involved in the mix -- like the dual-registrar 
> situation that MARTINI was chartered to address -- then the chances of 
> deployment decrease multiplicatively.
> 
> In other words, unless GRUU is mandated in GIN (or any solution to the 
> MARTINI problem, for that matter), the chances of GRUU deployment are 
> vanishingly small, in a way that doesn't exist in a single-registrar 
> system. Because the MARTINI architecture *caused* this problem, I 
> believe that it is incumbent on us to *fix* this problem.
> 
> As public GRUU is really quite easy to implement, I don't imagine that 
> this requirement should be particularly controversial.
> 
> /a
> 
> On 8/29/10 09:28, Aug 29, Andrew Allen wrote:
>>
>> I certainly agree with the compromise we worked out in Masstricht. As 
>> I stated during the meeting GRUU is basically a bug fix for SIP and 
>> without it originally intended basic SIP capabilities either break, 
>> have negative side effects or have significant limitations on other 
>> capabilities in order to make them work.
>>
>> Public GRUU is not complex to implement and with temporary GRUU the 
>> compromise gives enough wiggle room to allow other alternatives that 
>> provide anonymity to be used provided they don't break the use of 
>> Public GRUUs.
>>
>> The privacy text is not so much about implementing privacy as to 
>> ensure that deployments don't break GRUU capabilities in order to 
>> achieve privacy.
>>
>> Especially in enterprise deployments (which is the major MARTINI use 
>> case) endpoints will likely not have public IP addresses (or will have 
>> SBCs that modify them). So the need for GRUU support here is even more 
>> essential than "generic internet SIP".
>>
>> So I agree that SSPs supporting MARTINI MUST implement support for 
>> providing public GRUUs.
>>
>> Andrew
>>  
>> *From*: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> *Sent*: Saturday, August 28, 2010 03:44 PM
>> *To*: martini@ietf.org <martini@ietf.org>
>> *Subject*: [martini] Call for Consensus: Support for Public GRUUs
>>  
>> At the IETF 78 MARTINI WG meeting, during the discussion of Ticket 57 
>> (relating to temporary GRUUs), a suggestion was made that public GRUUs 
>> be mandatory to implement for SSPs. 
>>
>> We will now attempt to determine whether consensus exists within the 
>> MARTINI WG to make this change to the document.
>>
>> Please respond to this email and post your opinion as to whether you 
>> agree that SSPs supporting MARTINI MUST implement support for public 
>> GRUUs.
>>
>> This consensus call will last until September 12, 2010. 
>> ---------------------------------------------------------------------
>> 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.
>>
>>
>> _______________________________________________
>> martini mailing list
>> martini@ietf.org
>> https://www.ietf.org/mailman/listinfo/martini
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> martini mailing list
> martini@ietf.org
> https://www.ietf.org/mailman/listinfo/martini