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

Richard Barnes <rbarnes@bbn.com> Mon, 21 September 2009 21:07 UTC

Return-Path: <rbarnes@bbn.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 431693A6AAC for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 14:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HsINMXim5UQa for <geopriv@core3.amsl.com>; Mon, 21 Sep 2009 14:07:07 -0700 (PDT)
Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 447913A6AF7 for <geopriv@ietf.org>; Mon, 21 Sep 2009 14:07:07 -0700 (PDT)
Received: from [192.1.255.181] (helo=col-dhcp-192-1-255-181.bbn.com) by mx3.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <rbarnes@bbn.com>) id 1Mpq7C-0002P1-Ag; Mon, 21 Sep 2009 17:08:06 -0400
Message-ID: <4AB7EB35.7020200@bbn.com>
Date: Mon, 21 Sep 2009 17:08:05 -0400
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: "Winterbottom, James" <James.Winterbottom@andrew.com>
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> <4AB7E537.9060201@bbn.com> <E51D5B15BFDEFD448F90BDD17D41CFF1062C3A8B@AHQEX1.andrew.com>
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF1062C3A8B@AHQEX1.andrew.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: GEOPRIV <geopriv@ietf.org>, "James M. Polk" <jmpolk@cisco.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
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 21:07:08 -0000

Hm, no, that's not the answer I was looking for.  Here's what I'm 
thinking: Context has basically two parts,
1. Protocol mechanics for creating/updating/deleting contexts
2. Attributes of contexts that can be set with those mechanics

I was thinking that (1) could move toward being XCAP, and (2) could move 
toward extensions of the policy language.

In particular, w.r.t. (2), there are only three things that can be set:
-- "Authorization policy" is already common-policy
-- "Context lifetime" may require some extension, but is largely the 
same as the <validity> element of common-policy
-- "Snapshot context" is the most novel, but you could probably still 
implement it with an extension to the <provide-location> element from 
geopriv-policy.

The protocol mechanics (1) don't do anything really magical; I think you 
could map semantics pretty cleanly to a combination of HELD and XCAP.

--Richard



Winterbottom, James wrote:
> Hi Richard,
> 
> I see Context as a being a container, one of the things of which it can contain is a common policy document.
> 
> Does that help?
> 
> Cheers
> James
> 
> 
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Mon 9/21/2009 3:42 PM
> To: James M. Polk
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes Tschofenig; GEOPRIV
> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>  
> James: Don't worry.  Nothing in held-context is getting rid of or 
> duplicating Common Policy.  The difference is that held-context does 
> some things that are not possible today with common-policy or 
> geopriv-policy framework.
> 
> Hannes/James: Thinking back to the discussions at the Dallas interim 
> some time ago, I thought that there was a motion to move the 
> held-context toward being more of an extension to common-policy, rather 
> than an alternative policy transport.  Am I recalling correctly?
> 
> --Richard
> 
> 
> 
> 
> James M. Polk wrote:
>> 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
>>
> 
> 
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
> 
>