Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

"James M. Polk" <jmpolk@cisco.com> Mon, 21 September 2009 23:20 UTC

Return-Path: <jmpolk@cisco.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529E23A6B30 for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 16:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.476
X-Spam-Level:
X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 McEavI-YOFTZ for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 16:20:04 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E27C03A6ADE for <geopriv@ietf.org>; Mon, 21 Sep 2009 16:20:03 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlwFAHint0pAZnmf/2dsb2JhbACIKLMPiFABjncFgi6BbQ
X-IronPort-AV: E=Sophos;i="4.44,427,1249257600"; d="scan'208";a="59225849"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Sep 2009 23:21:05 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8LNL5h4013623; Mon, 21 Sep 2009 19:21:05 -0400
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8LNL3iu014090; Mon, 21 Sep 2009 23:21:05 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:21:05 -0700
Received: from jmpolk-wxp01.cisco.com ([10.89.0.47]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 16:21:04 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 21 Sep 2009 18:21:01 -0500
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "ext Winterbottom, James" <James.Winterbottom@andrew.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Richard Barnes <rbarnes@bbn.com>, GEOPRIV <geopriv@ietf.org>
From: "James M. Polk" <jmpolk@cisco.com>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501B596D2@FIESEXC015.nsn-in tra.net>
References: <4AB6D17C.3010109@bbn.com> <024201ca3a82$a6b8f860$b34ba20a@nsnintra.net> <E51D5B15BFDEFD448F90BDD17D41CFF10650E9C3@AHQEX1.andrew.com> <3D3C75174CB95F42AD6BCC56E5555B4501B2E682@FIESEXC015.nsn-intra.net> <XFE-SJC-2122m9lHiu300000508@xfe-sjc-212.amer.cisco.com> <3D3C75174CB95F42AD6BCC56E5555B4501B596D2@FIESEXC015.nsn-intra.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-211EUdKwUkz00000ce3@xfe-sjc-211.amer.cisco.com>
X-OriginalArrivalTime: 21 Sep 2009 23:21:04.0600 (UTC) FILETIME=[30B37D80:01CA3B12]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4715; t=1253575265; x=1254439265; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20RE=3A=20HELD=20using=20XCAP=20wrt=20Common=20Po licy/Geolocation=20Policy |Sender:=20 |To:=20=22Tschofenig,=20Hannes=20(NSN=20-=20FI/Espoo)=22=20 <hannes.tschofenig@nsn.com>,=0A=20=20=20=20=20=20=20=20=22ex t=20Winterbottom,=20James=22=20<James.Winterbottom@andrew.co m>,=0A=20=20=20=20=20=20=20=20=22Hannes=20Tschofenig=22=20<H annes.Tschofenig@gmx.net>,=0A=20=20=20=20=20=20=20=20=22Rich ard=20Barnes=22=20<rbarnes@bbn.com>,=20=22GEOPRIV=22=20<geop riv@ietf.org>; bh=gBEFX7Wwj4xeUDTQZNvmbBG5cltRLGRKq8fUk/RQ8GY=; b=YKQbvnwwSyLDGQXjQwxToUUlBhrivNbHuP8rSPlyb98W8A7b0ggEFNcP2g 3RwEGXEvIQWyXiYb9R5w25bRhdwRBNDYq/b3FH4Eb+8SU0VlWjE1xcq6kskH n3bhYqng8p;
Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Subject: Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 23:20:05 -0000

At 02:17 PM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi James,
>
>Let me provide a longer description of the story.

thanks for taking the time


>With the work on the DHCP LbyR you wanted to go for the access control
>authorization model. I told you about the disadvantages before (but, as
>usual, you did not seem to like my input).
>
>The downside of that decision is that you need to provide a story for
>the access control authorization model. The only possible story in DHCP
>is to use a separate protocol mechanism. At the moment there is only one
>mechanism available for usage with DHCP, namely XCAP & Common Policy
>(and potentially Geolocation Policy).
>
>In HELD the group decided in favor of the possession authorization
>model. HELD runs on top of HTTP and hence you can put a lot of other
>stuff in there, if you want. However, with the possession model you
>don't need to upload authorization policies. If you (later) still want
>to additionally provide support for the access control model then you
>could, as an option, piggyback a Common Policy document (which was in
>one of the earliest HELD drafts --  a feature that got removed because
>it was seen as too complex by the group back then) -- something you
>cannot do with DHCP (obviously because of the size).
>
>So, the default model in HELD is the possession model and the access
>control authorization model is just an add-on. In DHCP you decided that
>the access control authorization model is the only suitable model (for
>whatever reason).
>
>About the HELD context work: Doing the work on HELD we noticed that
>additional functionality would be very useful, i.e. functionality that
>goes beyond Common Policy and the Geolocation Policy (or is even not
>directly related to the two, I would say). This work is documented in
>the HELD context document.
>
>Hope my description helped and was able to clarify the topic. This is
>not a HELD vs. DHCP issue, just as a remark.

ok - I didn't necessarily mean for this thread to be a HELD vs. DHCP 
focus, I was more asking why HELD is being allowed to not do Common 
and Geolocation Policy defined procedures.

What you stated above is good, but it really makes me question why we 
have done all the work in Common or Geolocation Policy because if it 
weren't for DHCP, neither appears to have been useful at all.

Am I wrong in that conclusion?


>Finally, as you know: The geolocation policy document provides only
>location-based authorization and transformations for location
>information. The most important features one needs are for the purpose
>discussed here is, however, authorization based on the **identity** of
>the location recipient.

So, while not disagreeing with you at all, I'm still struggling to 
understand why referencing RFC 4745 isn't enough for the DHCP 
location URI doc? Why does this ID need to go into all the additional 
details since it is merely a delivery system piece of the soltion?

>This functionality is in Common Policy. So, I
>believe that (if this stuff gets used at all) then it will be Common
>Policy rather than Geolocation Policy.
>
>Ciao
>Hannes
>
>PS: Please note that I only review and help with the DHCP LbyR document
>review because I want to be a good GEOPRIV WG citizen and not because my
>employer has any interest in it.

I, on the other hand (& FWIW), believe in being a good <pick your WG> 
citizen regardless of whether my employer has any interested in it. 
Cisco is big enough to be involved in most everything, but that 
doesn't mean I work with those internal groups.



> >At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> >>I could imagine that adding the ability to upload Common
> >>Policy/Geolocation Policy as an add-on to
> >>draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
> >>using XCAP, particularly since I believe that 95% of the cases will
> >>only make usage of a fraction of Common Policy (and nothing from the
> >>geolocation policy document).
> >
> >I'm trying to figure out what is being said here in Hannes'
> >paragraph above.
> >
> >Is HELD really not needing Common Policy/Geolocation Policy
> >because it has another ID specifying some other mechanism?
> >
> >If so, why would this WG allow this?
> >
> >Common Policy is supposed to be "common" to everything, right?
> >
> >Geolocation Policy is supposed to be used by everything
> >Geopriv specific, right?
> >
> >It appears the net result of this - if true - is that DHCP has
> >to jump through hoops that HELD doesn't, even though HELD can.
> >
> >James
> >
> >
> >>Ciao
> >>Hannes
> >
> >