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

Cullen Jennings <fluffy@cisco.com> Mon, 19 July 2010 18:30 UTC

Return-Path: <fluffy@cisco.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 9195B3A6949 for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.459
X-Spam-Level:
X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kc0IrC+YzlOT for <martini@core3.amsl.com>; Mon, 19 Jul 2010 11:30:13 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B47063A67A1 for <martini@ietf.org>; Mon, 19 Jul 2010 11:30:11 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="228520434"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2010 18:30:22 +0000
Received: from sjc-vpn2-1198.cisco.com (sjc-vpn2-1198.cisco.com [10.21.116.174]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6JIULfo017787; Mon, 19 Jul 2010 18:30:22 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com>
Date: Mon, 19 Jul 2010 11:30:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E65E5ED-2DFB-4287-9713-E4CB2E71F204@cisco.com>
References: <BLU137-W10550BA232377BE7913FFE93B30@phx.gbl><D7C725AD-CBBD-4DCF-9077-99DC7E218C2E@cisco.com> <F1A0ED6425368141998E077AC43334E4037905@gbplmail01.genband.com> <4C4467BD.5060505@cisco.com> <F1A0ED6425368141998E077AC43334E4037A11@gbplmail01.genband.com>
To: Brian Lindsay <brian.lindsay@genband.com>
X-Mailer: Apple Mail (2.1081)
Cc: martini@ietf.org
Subject: Re: [martini] WGLC comments on draft-ietf-martini-gin
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: Mon, 19 Jul 2010 18:30:15 -0000

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