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

["Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig at nsn.com>]

Hi Ted,

as stated in my previous mail I am agree with your description. 

I was just looking at Section 5.2 of 
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-06#section-5.2
and it essentially summarizes what you said in your mail. 

I think it would be useful to capture your description in Section 5.2 of
that document. 

Would this be useful? 

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