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

I don't think that the support of GRUU will be a key criteria for SSPs to decide whether to implement gin or not. The fact that the gin solution is not compatible with the IMS solution will certainly have more weigth in their decisions, at least for those having rolled out an IMS-based network.
Bruno

> -----Message d'origine-----
> De : martini-bounces@ietf.org 
> [mailto:martini-bounces@ietf.org] De la part de Elwell, John
> Envoyé : vendredi 3 septembre 2010 09:20
> À : Andrew Allen; martini@ietf.org
> Objet : 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.
> > 
> _______________________________________________
> martini mailing list
> martini@ietf.org
> https://www.ietf.org/mailman/listinfo/martini
> 