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

Adam Roach <adam@nostrum.com> Sun, 29 August 2010 21:07 UTC

Return-Path: <adam@nostrum.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 7E3923A68C4 for <martini@core3.amsl.com>; Sun, 29 Aug 2010 14:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 gvZSgY2jEmsS for <martini@core3.amsl.com>; Sun, 29 Aug 2010 14:07:36 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A0E263A6897 for <martini@ietf.org>; Sun, 29 Aug 2010 14:07:35 -0700 (PDT)
Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o7TL842A050820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2010 16:08:04 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4C7ACC34.9060100@nostrum.com>
Date: Sun, 29 Aug 2010 16:08:04 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Andrew Allen <aallen@rim.com>
References: <BDBFB6CE314EDF4CB80404CACAEFF5DE04D861FE@XCH02DFW.rim.net>
In-Reply-To: <BDBFB6CE314EDF4CB80404CACAEFF5DE04D861FE@XCH02DFW.rim.net>
Content-Type: multipart/alternative; boundary="------------000107020205010606020306"
Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism)
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: Sun, 29 Aug 2010 21:07:37 -0000

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