Re: [martini] WGLC comments on draft-ietf-martini-gin

Hi,

  My preferance is to keep the text in the draft "as is" for GRUUs in general: describe how the GRUU mechanism works with gin, but don't couple/require that a gin registration implementation must implement the GRUU mechanism.

  Regards
     Brian

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com] 
Sent: Monday, July 19, 2010 2:30 PM
To: Brian Lindsay
Cc: Paul Kyzivat (pkyzivat); martini@ietf.org
Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin

Well - the first question is if we agree that non temp GRUUs are mandatory to implement on the SSP side?  If we don't agree on this we are not going to get far on the temp conversation. 

On Jul 19, 2010, at 10:00 , Brian Lindsay wrote:

> Hi Paul,
> 
>    Perhaps to add to your first point, I think temporary GRUUs aren't even mandatory to implement in RFC 5627?
> 
>    I think the draft currently has the right balance: it defines how GRUUs/Temp-GRUUs work with the "gin" registration mechanism (and defines the necessary extensions for this), but doesn't mandate them. Mandating/coupling argueably goes beyond the scope of the MARTINI requirements. Temp-GRUUs by themselves also aren't necessarily sufficient for full anonymity (e.g. SDP info could be used for correlation) and it hasn't been in the scope of the work to mandate a full solution for anonymity.
> 
>    In the absence of availability a temp-gruu - presumeably the PBX would have to anonymize the request to the extent possible and the network may provide additional privacy capabilities of course (e.g. RFC3323/3325).
> 
> Thanks,
> Brian
> 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Monday, July 19, 2010 10:57 AM
> To: Brian Lindsay
> Cc: Cullen Jennings; martini@ietf.org
> Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin
> 
> IMO the optionality of GRUUs, and of temp gruus, was always a dicy thing.
> 
> The question is what the client is to do if it has functionality that requires GRUU but GRUU isn't supported by the registrar?
> 
> In the current context, I think this might come down to confidentiality features in the PBX. It (or the phones it serves) is likely to be designed to use temp-gruu to implement those features, since for it there aren't a lot of alternatives. So if in a particular deployment the SSP registrar doesn't support temp-gruus, what is the pbx/phone to do about those features? I think about all it can do is disable them - eliminating possibility of anonymous calls.
> 
> Now it may be that the SSP has some alternative mechanism for anonymity.
> But how will the PBX know to use that? Also, such a mechanism wouldn't support anonymity on calls within the PBX.
> 
> Maybe that is as it must be. But I think we must consider this carefully before deciding.
> 
>         Thanks,
>         Paul
> 
> Brian Lindsay wrote:
> > Hi,
> >
> >    I'd disagree with making temp gruu's mandatory to implement in this draft. Some SSP's may have architectures/privacy functions that would not require this to support anonimity (e.g. using B2BUA's). I'd prefer to keep the text as is for temp-gruu's.
> >
> >
> > Thanks,
> > Brian
> >
> > -------------
> > Brian Lindsay
> > Sr. Architect, System Architecture
> > GENBAND
> > Office: +1.613.763.3459      
> > www.genband.com
> >
> > -----Original Message-----
> > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On 
> > Behalf Of Cullen Jennings
> > Sent: Sunday, July 18, 2010 1:02 PM
> > To: martini@ietf.org
> > Subject: [martini] WGLC comments on draft-ietf-martini-gin
> >
> >
> > Looks like a fully formed sausage - I like it. Two issues when I skimmed it.
> >
> > The support for temp gruus seems to be optional. I think it should be mandatory to implement. The exact deployment models where we want to use this are the places where many people believe there is a legal requirement to support anonymous calls and implementing this put us into the situation where there are pretty much no alternatives way to do it.
> >
> > Please change "must" to "MUST" in section 5.1
> >    First, it must contain an option tag of "gin" in
> >    both a "Require" header field and a "Proxy-Require" header field.
> > You might want to consider "must" in the next sentence too.
> >
> > Cullen
> >
> >
> > PS - Thank you to Richard for pointing out this to me - I had missed it because I filter on WGLC on the subject lines.
> >
> >
> > _______________________________________________
> > 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
> >
> 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html