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

-1 

This statement disturbs me 

"unless GRUU is mandated in GIN (or any solution to the MARTINI problem, for
that matter), the chances of GRUU deployment are vanishingly small"

I don't understand this argument .. so GRUU's have not deployed for well
known reasons so we want to shove them down the throats of implementers and
use MARTINI as the mechanism? 

What in the MARTINI architecture has created this dilema...only the privacy
issue? 

-----Original Message-----
From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf
Of Paul Kyzivat
Sent: Monday, August 30, 2010 9:38 AM
To: Adam Roach
Cc: bernard_aboba@hotmail.com; martini@ietf.org
Subject: Re: [martini] Call for Consensus: Support for Public GRUUs

+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
_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini