Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy
"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Mon, 21 September 2009 19:17 UTC
Return-Path: <hannes.tschofenig@nsn.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 97F593A69CD for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 12:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.259
X-Spam-Level:
X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599]
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 qT6Px4bYFRUz for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 12:17:26 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 7433B3A690E for <geopriv@ietf.org>; Mon, 21 Sep 2009 12:17:26 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n8LJIEni027631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2009 21:18:14 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n8LJIEoo030740; Mon, 21 Sep 2009 21:18:14 +0200
Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 21:18:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Sep 2009 22:17:40 +0300
Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501B596D2@FIESEXC015.nsn-intra.net>
In-Reply-To: <XFE-SJC-2122m9lHiu300000508@xfe-sjc-212.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: HELD using XCAP wrt Common Policy/Geolocation Policy
Thread-Index: Aco650kPSBGHvUcvQvuidWaBDoUrXgAAMO1Q
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>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: "ext James M. Polk" <jmpolk@cisco.com>, "ext Winterbottom, James" <James.Winterbottom@andrew.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, Richard Barnes <rbarnes@bbn.com>, GEOPRIV <geopriv@ietf.org>
X-OriginalArrivalTime: 21 Sep 2009 19:18:14.0565 (UTC) FILETIME=[44489550:01CA3AF0]
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 19:17:27 -0000
Hi James, Let me provide a longer description of the story. 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. 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. 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. >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 > >
- [Geopriv] A modest proposal w.r.t. location URI p… Richard Barnes
- Re: [Geopriv] A modest proposal w.r.t. location U… Hannes Tschofenig
- Re: [Geopriv] A modest proposal w.r.t. location U… Winterbottom, James
- Re: [Geopriv] A modest proposal w.r.t. location U… Tschofenig, Hannes (NSN - FI/Espoo)
- [Geopriv] HELD using XCAP wrt Common Policy/Geolo… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Richard Barnes
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Winterbottom, James
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Richard Barnes
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Thomson, Martin
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… James M. Polk
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Hannes Tschofenig
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Hannes Tschofenig
- Re: [Geopriv] HELD using XCAP wrt Common Policy/G… Shida Schubert