Subject: [Geopriv] A modest proposal w.r.t. location URI policy

From: Richard Barnes <[email-masked]>
Date: Sun, 20 Sep 2009 21:06:04 -0400

We've been struggling for a while with how one should manage policies on 
location URIs that one receives via an LCP -- either DHCP or HELD.  As 
Martin's recent post in a DHCP thread pointed out, the trouble is that 
we have
1. Ways to deliver location URIs (HELD/DHCP), and
2. A way to manage a specified policy document (XCAP), but not
3. A way to find the policy URI for a given location URI.

I would like to propose that we resolve the latter problem by 
<drumroll/> providing a policy URI alongside the location URI.  For 
example, in HELD

<locationURI policy="http://foo/bar">http://foo/bar</locationURI>

... or in DHCP ....

LuriType=2 Policy URI ...

I think we could agree that this URI MUST be accessible using XCAP 
(using the pres-rules AUID, I guess), but one would want to observe that 
a client could implement just HTTP GET and PUT to that URI to retrieve 
and replace the entire policy document (this being the simplest version 
of XCAP).  This would provide a pretty light-weight way for clients to 
manage policy on location URIs.

There are a few other subtleties to work out -- how the policy URI is 
controlled, requests parameters and error codes for HELD, how the 
possession model looks in pres-rules -- but I wanted to propose the 
general idea to the list to see if there are any obvious problems with 
it.  If not, I may go write a draft...

Cheers,
--Richard

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 21 Sep 2009 09:13:33 +0300

Makes sense to me. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Richard Barnes
>Sent: 21 September, 2009 04:06
>To: 'GEOPRIV'
>Subject: [Geopriv] A modest proposal w.r.t. location URI policy
>
>We've been struggling for a while with how one should manage 
>policies on location URIs that one receives via an LCP -- 
>either DHCP or HELD.  As Martin's recent post in a DHCP thread 
>pointed out, the trouble is that we have 1. Ways to deliver 
>location URIs (HELD/DHCP), and 2. A way to manage a specified 
>policy document (XCAP), but not 3. A way to find the policy 
>URI for a given location URI.
>
><drumroll/> providing a policy URI alongside the location URI. 
> For example, in HELD
>
>I think we could agree that this URI MUST be accessible using 
>XCAP (using the pres-rules AUID, I guess), but one would want 
>to observe that a client could implement just HTTP GET and PUT 
>to that URI to retrieve and replace the entire policy document 
>(this being the simplest version of XCAP).  This would provide 
>a pretty light-weight way for clients to manage policy on 
>location URIs.
>
>There are a few other subtleties to work out -- how the policy 
>URI is controlled, requests parameters and error codes for 
>HELD, how the possession model looks in pres-rules -- but I 
>wanted to propose the general idea to the list to see if there 
>are any obvious problems with it.  If not, I may go write a draft...
>
>Cheers,
>--Richard
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 21 Sep 2009 01:17:46 -0500

For the HELD example, would the policy be per URI, or per URI set?

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Hannes Tschofenig
> Sent: Monday, 21 September 2009 4:14 PM
> To: 'Richard Barnes'; 'GEOPRIV'
> Subject: Re: [Geopriv] A modest proposal w.r.t. location URI policy
> 
> Makes sense to me.
> 

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 21 Sep 2009 10:27:13 +0300

Hi James, 

Good question. I would say URI set rather than URI. 

Furthermore, I wonder whether the idea of providing a policy URI applies
more to DHCP only. My arguments are below.

In HELD the possession model was chosen as a starting point with the
option to support the access control authorization model later. There
are a few things one still want to do that are not part of the Common
Policy/Geolocation Policy work we did and they are described in this
document (HELD context):
http://tools.ietf.org/id/draft-winterbottom-geopriv-held-context-04.txt
We also tried to enhance the gelocation policy document to support the
functionality described in
draft-winterbottom-geopriv-held-context-04.txt and to change
draft-winterbottom-geopriv-held-context-04.txt to re-use the geolocation
policy format (but these approaches seemed to be rather useless).

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 would also add that I still believe that one would be much better of
with a combined model of possession and access control model where the
Device uploads the received LbyR to a separate server, such as a
presence server, and there full-version of access control policies are
enforced. This would require something like
http://tools.ietf.org/id/draft-garcia-geopriv-indirect-publish-00.txt

Ciao
Hannes

>[mailto:[email-masked]] On Behalf Of ext Winterbottom, James
>Sent: 21 September, 2009 09:18
>To: Hannes Tschofenig; Richard Barnes; GEOPRIV
>> >We've been struggling for a while with how one should 
>manage policies 
>> >on location URIs that one receives via an LCP -- either 
>DHCP or HELD.  
>> >As Martin's recent post in a DHCP thread pointed out, the 
>trouble is 
>> >that we have 1. Ways to deliver location URIs (HELD/DHCP), and 2. A 
>> >way to manage a specified policy document (XCAP), but not 
>3. A way to 
>> >find the policy URI for a given location URI.
>> >
>> >(using the pres-rules AUID, I guess), but one would want to observe 
>> >that a client could implement just HTTP GET and PUT to that URI to 
>> >retrieve and replace the entire policy document (this being the 
>> >simplest version of XCAP).  This would provide a pretty 
>light-weight 
>> >way for clients to manage policy on location URIs.
>> >
>> >general idea to the list to see if there are any obvious problems 
>> >with it.  If not, I may go write a draft...
>> >
>> >Cheers,
>> >--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 21 Sep 2009 13:13:46 -0500

>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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 21 Sep 2009 22:17:40 +0300

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. 

>>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 
>Is HELD really not needing Common Policy/Geolocation Policy 
>because it has another ID specifying some other mechanism?
>
>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
>
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Sep 2009 16:42:31 -0400

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:
> Is HELD really not needing Common Policy/Geolocation Policy because it 
> has another ID specifying some other mechanism?
> 
> 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
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 21 Sep 2009 23:56:33 +0300

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

You recall it correctly. I tried it and it was super complex without any
additional benefit. I posted something to the list, if I recall it
correctly. 
I  could even try to find it

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 21 Sep 2009 15:53:32 -0500

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:[email-masked]]
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

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Sep 2009 17:08:05 -0400

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 21 Sep 2009 17:54:35 -0500

I think that the answer that you were looking for is this:

Held-context had a few items that I still believe pertain to the minting of the URI, more so than the authorization policy.  Of those three functions you list below:

 -- authorization policy: common-policy is already used by held-context directly
 -- lifetime: managing the lifetime of the created resource is an important problem, and one that goes beyond what is available through policy (even if some of the effects can be mimicked by using policy)
 -- snapshot: I'm yet to see a workable proposal that extends common- or geopriv-policy; I'd love to see one.

Regarding the fundamentals:

The problem I have is the continuing mutation of the HELD locationRequest.  I was perhaps in the minority when it came to deciding that "locationURI" was a location type.  I would have preferred that locationURI was the subject of an entirely separate request (i.e. context creation).  Sure, there are some good reasons for it being as it is, but those are reasons of convenience for the most part.

Thus, on consideration, the largest problem I have with your proposal is that it continues to build on something that is only marginally useful in the first place.  The net result is an increase in complexity, with less to show for it.

However, I see this as constructive input on held-context.  I've been toying with ideas regarding better modularity and use of REST-like principles in its design.  Perhaps there's an opportunity to make some improvements.

--Martin

> Behalf Of Richard Barnes
> Sent: Tuesday, 22 September 2009 7:08 AM
> To: Winterbottom, James
> Cc: GEOPRIV; James M. Polk; Tschofenig,Hannes (NSN - FI/Espoo)
> Subject: Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation
> Policy
> 
> only
> >> I'm trying to figure out what is being said here in Hannes'
> paragraph
> >> above.
> >>
> it
> jump

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 21 Sep 2009 18:21:01 -0500

>Let me provide a longer description of the story.

thanks for taking the time

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

>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

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.

> >paragraph above.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 21 Sep 2009 18:25:27 -0500

At 03:42 PM 9/21/2009, Richard Barnes wrote:
>held-context toward being more of an extension to common-policy, 
>rather than an alternative policy transport.  Am I recalling correctly?

there was something along those lines, but it's been a while now so 
my memory isn't the greatest (I've killed a lot of brain cells since then  ;-)

If your memory is right, then I would have pushed the held-context 
effort to be way more general - making it an update (i.e., an 
extension to) common policy; something that I don't get the 
impression it ever did.  That said - why hasn't it moved to being 
more general in scope?

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 22 Sep 2009 09:59:20 +0300

Hi Richard, 

Regarding (1): The usage of XCAP for the transport instead of the mechanism
currently described in Context is certain something we could investigate. I
have not followed the recent work in BLISS but aren't some folks trying to
invent a new protocol mechanism to update XCAP?

Regarding (2): I have tried to create such an extension to Common Policy &
the Gelocation Policy (since I thought it was a good idea after the
discussion we had at the interim meeting) but then the outcome convinced me
that it isn't. 

Here is the result I came up with about a year ago:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05907.html

We might want to revisit that very brief discussion and try to the
complexity for implementers. 

Ciao
Hannes

>Sent: 22 September, 2009 00:08
>To: Winterbottom, James
>Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); Hannes 
>Tschofenig; GEOPRIV
>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.
>
>-- "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
>
>
>
>> 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
>> 
>> 
>----------------------------------------------------------------------
>> -------------------------- This message is for the designated 
>> recipient only and may contain privileged, proprietary, or otherwise 
>> private information.
>immediately 
>> and delete the original.  Any unauthorized use of this email is 
>> prohibited.
>>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 22 Sep 2009 10:34:32 +0300

Hi James, 

~snip~
>
>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.
>

Common Policy and Geolocation policy is a good mechanism for usage with a
Location Server but not for a LIS (in my opinion). 

I have the following model in mind (copied from 
http://tools.ietf.org/html/draft-garcia-geopriv-indirect-publish-00 and
modified):

                                  +------------+
                                  | Location   |
                                  | Recipient  |
                                  |            |
                                  |            |
                                  +------------+
                                        ^
                                        |Location
                                        |Request/
                                        |Response
                                        |(3)
                                        |
                                        v
      +-----------+               +------------+
      |           |               | Location   |
      |    LIS    |               | Server     |
      |           |               | (+Policies)|
      |           |               |            |
      +-----------+               +------------+
           ^                          ^
           | Geopriv                //
           | Location             //
           | Configuration      //
           | Protocol         //
           | (1)            //
           |              //   Geopriv Location
           v            //     Conveyance Protocol
      +-----------+   //       (e.g., SIP)
      | Device    | //         (2)
      |           |v
      |           |
      +-----------+

             Figure: Location by Value 

                                   +------------+
                                   | Location   |
                                   | Recipient  |
                                   |            |
                                   |            |
                                   +------------+
                                         ^
                                         |Location
                                         |Request/
                                         |Response
                                         |(4)
                                         |
                                         v
       +-----------+  Geopriv      +------------+
       |           |  Location     | Location   |
       |    LIS    |<------------->| Server     |
       |           |  Dereference  | (+Policies)|
       |           |  Protocol (3) |            |
       +-----------+               +------------+
            ^                          ^
            | Geopriv                //
            | Location             //
            | Configuration      //
            | Protocol         //
            | (1)            //
            |              //   Geopriv Location
            v            //     Conveyance Protocol
       +-----------+   //       (e.g., SIP)
       | Device    | //         (2)
       |           |v
       |           |
       +-----------+
   
               Figure: Location by Reference

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

A reference to RFC 4745 is a first step, certainly. But it leaves the
question open of how the XML documents get to the LIS. 

Ciao
Hannes

---

From: Shida Schubert <[email-masked]>
Date: Mon, 28 Sep 2009 13:49:42 +0900

Hannes;

  At BLISS we are trying to define set of URIs along with
rules on how these URIs are to be used to enable/disable
common features on the proxy (call-forward ON/OFF,
voicemail ON/OFF for particular AoR etc.). Each configuration
is viewed as a resource, represented as a URI following the
REST principle.

  We are not defining a protocol per se, but trying to
provide a simple solution to an interoperability problems
observed in a wild, while maintaining forward compatibility
to XCAP.

  So we are neither updating XCAP nor replacing XCAP.

  Regards
   Shida

On Sep 22, 2009, at 3:59 PM, Hannes Tschofenig wrote:

>>> --------------------------
>>> [mf2]
>>>
>>>
>>
>