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

Andrew,

That is for SSPs and their vendors to say. As a SIP-PBX vendor, I don't want to find that SSPs don't implement gin (and hence don't implement SIPconnect 1.1 registration mode) because we have made it unnecessarily complicated. I agree it is a lot easier to implement public GRUU than temporary GRUU. If SSPs and their vendors are happy, that's fine, but I don't think we have heard from sufficient.

John

> -----Original Message-----
> From: Andrew Allen [mailto:aallen@rim.com] 
> Sent: 03 September 2010 08:14
> To: Elwell, John; martini@ietf.org
> Subject: Re: [martini] Consensus call: Resolution of Ticket #57
> 
> 
> 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.
> 