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
>
>