Re: [Geopriv] Some thoughts on rule-makers, targets, and rules

["Dawson, Martin" <Martin.Dawson at andrew.com>]

I've decided it's just easier to build my own pizza oven :)

I want to thank Ted for capturing the essence of the debate so well.

I believe all possible configurations of RM and target need to be
supported. And the "legacy device scenario" is only one example of the
use case where they are discrete and independent entities. If we exclude
any particular configuration, then we'll have defined a framework that
only addresses a subset of the location service solution space. This
will lead to the unnecessary proliferation of standards to address the
whole solution space - as well as raise the question of where the
mandate lies to define the solution space that GEOPRIV decides is
out-of-bounds.

A single framework can certainly address the whole solution space;
there's no doubt it's possible to define one. It should not obviate the
ability to implement any given configuration nor should it obviate the
ability to exclude a particular configuration. In order to do this, the
appropriate protocol mechanisms are required along with the appropriate
rules/guidance associated with them.

The identity extensions draft aims to satisfy these requirements.

Cheers,
Martin

-----Original Message-----
From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, 18 August 2008 6:20 PM
To: ext Ted Hardie; geopriv at ietf.org
Subject: Re: [Geopriv] Some thoughts on rule-makers, targets, and rules

... another issue I would like to talk about.

On the mentioned emergency services architecture chosen by the 3GPP &
co. To me it seems that there is a clear focus on emergency services
only. For location based services they have developed other mechanisms,
in particular within the OMA, and hence I was wondering why some of us
interpret their architecture in a way they themselves might not even
have envisioned yet. 

When an emergency call is initiated then context information provided.
In our case this context comes with the Service URN to indicate that
this specific communication is about an emergency call and that certain
policies with respect to the distribution of location information are
applicable. 

I am specifically focusing on the emergency services use case since I
believe this is indeed something that is going to see deployment with
SIP. With all the workshops we did I am trying to understand the pain
points of folks deploying our protocols and I got the impression that
some of them face problems with respect to incremental deployment and
there are also lots of fears regarding security. To mention one example:


 -- With emergency services deployments that are in preparation today
VoIP providers have to provide a story for  "legacy" devices that do not
implement the latest version of phone BCP (to put it mildly). They need
to figure out ways to still get the emergency call to happen. They come
up with their own solutions as we speak and there is very little we can
do about it (since we are not the deployment police). This happens
largely in the fixed environment with a clear focus on emergency
services. Is there help we can provide to them other than just telling
them "buy our latest X [where X stands for a particular box]"?

Another location based "application" we have been working on was the
SIP-based presence architecture. There, the role of the Rule Maker is
more or less clear (with the minor issue I described in my other mail).
Nobody, I hope, really envisions a deployment model where location-based
presence servers are located in every access network. Unfortunately, we
are facing a problem with the usage of SIP presence since the deployment
of the location based extensions depends on the successful deployment of
SIP presence in the first place ...

I am not so excited about speculating about potential location based
services (beyond the emergency services case), such as the famous pizza
delivery example, that the GEOPRIV architecture with SIP Location
Conveyance is going to be the preferred deployment choice. I have never
attempted to approach that "community" to figure out how they anticipate
things to work -- I doubt many others in the group have. 

Ciao
Hannes

>-----Original Message-----
>From: geopriv-bounces at ietf.org 
>[mailto:geopriv-bounces at ietf.org] On Behalf Of ext Ted Hardie
>Sent: 15 August, 2008 21:01
>To: geopriv at ietf.org
>Subject: [Geopriv] Some thoughts on rule-makers, targets, and rules
>
>At the last IETF, there was considerable hallway discussion 
>about a set of drafts that discussed a topic using the shorthand "obo"
>(on behalf of) for a class of uses.  We felt a lot of heat in 
>the warm Irish sun on this, and to keep our meeting room from 
>boiling over, Robert delayed the full-on discussion of it.  
>During the meeting I offered to try to describe the problem in 
>other terms, as I believe the folks discussing the issue were 
>talking past each other in some pretty fundamental ways.  To 
>try to resolve this, I'd like to take us back a bit, to this 
>famous set of boxes and arrows, rendered in the finest 
>fixed-width Courier:
>
>
>                              +----------+
>                              |  Rule    |
>                              | Holder   |
>                              |          |
>                              +----+-----+
>                                   |
>                               rule|interface
>                                   V
>   +----------+               +----------+               +----------+
>   |Location  |  publication  | Location |  notification |Location  |
>   |Generator +-------------->| Server   +-------------->|Recipient |
>   |          |  interface    |          |  interface    |          |
>   +----------+               +----------+               +----------+
>
>
>One of the things missing in this diagram is a labelled 
>"Target", a term that is pretty fundamental in RFC 3963.
>The Location Generator has location for a specific Target, 
>which it publishes through the publication interface to the 
>location server; the Rule Holder uses the rule interface to 
>apply rules to one or more Location Objects about that Target 
>and the Location Recipients receive the Location Objects if 
>permitted by the Rule Holder and with the permissions the Rule 
>Holder applied.
>
>You'll also notice that the boxes and flows refer to a Rule 
>Holder, where the Rule Maker's interaction with the Rule 
>Holder is off-stage.  The Rule Maker is pretty important, 
>though.  To quote from the principles set out 3693's overview:
>
> 2) A critical role is played by user-controlled Privacy Rules, which
>      describe the restrictions imposed or permissions given by the
>      "user" (or, as defined below, the "Rule Maker").  The Privacy
>      Rules specify the necessary conditions that allow a Location
>      Server to forward Location Information to a Location Recipient,
>      and the conditions and purposes for which the Location 
>Information
>      can be used.
>
>Note, though, that the Rule Maker is not *necessarily* the 
>user, nor is the ability to make rules completely unfettered.
>Forgive the long quote, but this is pretty key to the
>discussion:
>
> Rule Maker (RM):
>         The individual or entity that has the authorization to set the
>         applicable Privacy Rules for a potential Geopriv Target.  In
>         many cases this will be the owner of the Device, and in other
>         cases this may be the user who is in possession of the Device.
>         For example, parents may control what happens to the location
>         information derived from a child's cell phone.  A company, in
>         contrast, may own and provide a cell phone to an employee but
>         permit the employee to set the privacy rules.
>
>         There are four scenarios in which some form of constraint or
>         override might be placed on the Privacy Rules of the Rule
>         Maker:
>
>         1. In the case of emergency services (such as E911 within the
>            United States), local or national laws may require that
>            accurate location information be transmitted in certain
>            defined emergency call situations.  The Geopriv Working
>            Group MUST facilitate this situation.
>
>         2. In the case of legal interception, the RM may not be aware
>            of an override directive imposed by a legal authority.  It
>            is not the expectation of the Working Group that a
>            particular accommodation will be made to facilitate this
>            situation.
>
>         3. In the context of an employment relationship or other
>            contractual relationship, the owner of a 
>particular location
>            (such as a corporate campus) may impose constraints on the
>            use of Privacy Rules by a Rule Maker.  It is not the
>            expectation of the Working Group that a particular
>            accommodation will be made to facilitate this situation.
>
>         4. It is conceivable that a governmental authority may seek to
>            impose constraints on the use of Privacy Rules by a Rule
>            Maker in non-emergency situations.  It is not the
>            expectation of the Working Group that a particular
>            accommodation will be made to facilitate this situation.
>
>In some of the discussions in Dublin, the Rule Maker as an 
>entity seems to have collapsed completely into the Target.  As 
>the above makes clear, there are cases where the Rule Maker 
>and Target are distinct. 
>
>There also, however, are pretty specific exceptions made here 
>for emergency services which are not otherwise made.
>In Dublin, some folks seemed to be describing the emergency 
>services model for providing location about a Target as a 
>general model.  The model *may* be general, obviously, but 
>given the exception language above, it is worth examining 
>whether the relationships would continue to fit into the 
>GEOPRIV framework without the emergency services exception.  
>Perhaps I am not totally clear on the discussion (since I was 
>not at the Interim meeting where this all started"), but some 
>folks appear to be interpreting others as saying that the 
>systems put in place for emergency services should be 
>generalized so that location can be provided about a Target 
>without the Target having any ability to act as a Rule Maker 
>(or to limit the Rule Making to a single bit "yes to everything"
>or "no to everything not mandated by law").
>
>To put this another way, this discussion is *really* about who 
>gets to act as a Rule Maker for specific Targets and the level 
>of consent needed to transfer the role of Rule Maker from the 
>Target to some other entity.  In particular, there seems to be 
>one set of folks who believe that the role of Rule Maker 
>defaults to the Target, and another set of folks who believe 
>that the role of Rule Maker defaults to the location generator 
>(or, possibly "location provider") with limited input from the Target.
>
>To be upfront about my own prejudices here, I believe that 
>using the emergency services model as justification for a 
>general model is pretty silly, especially when references are 
>to 3GPP (which clearly uses non-geopriv technology and is also 
>willing to have separate systems for emergency systems in 
>general--witness the ECSCF).  On the other hand, if I am 
>willing to sell the role of Rule Maker to my cellular provider 
>in order to get a lower bill, I believe I should be able to do 
>so; everyone just needs to be very clear that this is what is 
>happening and agree that there be a way for me to choose to be 
>my own Rule Maker instead. 
>What I do not think makes sense is for the Rule Maker's role 
>to default to the location generator; it should default to the 
>Target, with the recognition that it may move from there 
>either when the Target permits this or when the Target is not 
>competent to make rules.  In my personal opinion, "competent 
>to make the rules" is a statement about the Target, not the 
>device, and justifying transferring the Rule Maker's role by 
>reference to a device transition makes no sense.  The Rule 
>Maker/Rule Holder interface is different in one place than 
>another, but the issues remain the same.
>
>These biases may affect my understanding of the situation 
>here, but they are strong enough that I needed to mention them. 
>More generally, though, I believe we will get a lot further in 
>this discussion if go back to talking about the relationships 
>in terms of Rule Makers and Targets.  In too many cases here, 
>the "obo" phrase seems to be eliding the basic case here, 
>where we are talking *about* the Target when the Target is not 
>for some reason taking the role of Rule Maker.
>
>By the way, I originally intended to pass this by Jon, but 
>given his happy tidings, I decided to go out on the limb on my 
>own; any slings and arrows should come my way.
>
>					regards,
>						Ted
>
>
>
>
>
>
>
>
>_______________________________________________
>Geopriv mailing list
>Geopriv at ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

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

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv