Subject: Re: Notes from Non-meeting

From: John Morris <[email-masked]>
Date: Wed, 20 Mar 2002 12:04:05 -0500

I think Brian's overview of the discussions yesterday is very helpful.  I 
have some particular comments that are addressed in-line below, but I'd 
like to give a different big picture overview which reflects my different 
perspective on some of the issues.  My big picture recap does not conflict 
with Brian's, but I think it will highlight a particular issue on which 
Brian noted that our little informal group did not agree yesterday:

>1. The format of location information.  I believe we agreed
>that it won't be hard to agree on this.  There seems to be
>reluctance to actually  do this before we settle harder
>problems.  I personally think this is wrong, and we should
>just go ahead and pick a format (or actually more than one)
>now.

My recap is that there was general agreement that there were at least two 
WG outputs that were key (and from my individual perspective we could defer 
the question of whether some scenarios might require the creation of a new 
protocol).  The two threshold outputs would be:

1)  The structure and elements of a "geopriv object" -- which is different 
than the mere "format of location information."  The object would at a 
minimum contain a bare bones privacy instruction/rule, and might also 
contain location information (although we will need to address situations 
in which the privacy rule and the location information originate in 
separate places).

2)  A statement of rules that MUST be followed in any implementation that 
uses the geopriv object (or perhaps more broadly, any implementation that 
uses location information).  This statement would include things like, for 
example, a requirement that certain entities in a location service scenario 
must be authenticated before location is disclosed, or a requirement that 
the transfer of location information between entities must be encrypted or 
otherwise protected.  I offer these examples not to suggest that there is 
consensus on them, but merely to illustrate the types of rules that would 
be included in a statement of rules.

To loop back to the "do we need a protocol" question, the WG needs to reach 
consensus on the question "if an existing protocol that is already being 
used in a geopriv scenario can by itself comply with all the contents of 
the statement of rules suggested above, is there any need or value in 
forcing the use of some new geopriv specific protocol?"  Certainly many or 
most people at the informal discussion yesterday would answer that question 
with a resounding "no", but it is question that goes straight to the proper 
scope and goal of the WG and it should be clearly answered.

Brian also suggested that he believes that the first output item should be 
the easier "format" question, leaving the harder policy statement for 
later.  I would try to tackle the harder policy statement first, because I 
believe that the content of the statement of rules may possibly have an 
impact on the content of a geopriv object.  It is hard for me to answer 
"what is the bare minimum I must say to someone who has my location 
information" unless I know the presumptive "rules" that the entity with my 
information "must" follow.

Also, until those rules are articulated, it is hard to know for sure that 
any particular existing protocol can in fact follow all of the rules.  And 
thus, the statement of rules will make it easier to answer the "do we need 
a new protocol" question.

There was some concern expressed yesterday that at least some of the 
"rules" in the statement suggested above at 2) would be unenforceable 
through technology, and thus the rules could be viewed as pure policy, 
something that the IETF tries to avoid.  My reaction to that concern is 
that where a technology unavoidably raises potential policy concerns, it is 
a useful effort to state some rules for use of the technology even if the 
rules cannot be technologically enforced. We can debate this issue in a 
later thread.

Some addition comments are in line below.  John

At 06:36 PM 3/19/02 -0500, Rosen, Brian wrote:

SNIP

>One of the things that keeps getting us "wrapped around the
>axle" is that we can't seem to separate four different aspects
>of this work:
>
>1. The format of location information.  I believe we agreed
>that it won't be hard to agree on this.  There seems to be
>reluctance to actually  do this before we settle harder
>problems.  I personally think this is wrong, and we should
>just go ahead and pick a format (or actually more than one)
>now.

As suggested above, this item would be better phased "the format of a 
geopriv object."

SNIP

>One of the things we also agreed on (almost too readily it seems)
>is that the latter [crypto] is NOT going to be specified by geopriv.

I am not ready to say that the WG will not specify a crypto scheme or a 
protocol EVER, but I agree with Brian's core assertion that those can be 
deferred for now.

SNIP

>There was great reluctance to get geopriv into the business of
>devising new ways to express policy and in particular, we did
>not see the WG designing a new policy expression language.

I do not recall that there was general agreement among the participants we 
would not need to devise new ways to express policy.  It would be great if 
we do not need to do so, and probably everyone would agree with that.

SNIP

>It was observed that the output RFC of the work could have
>a 1/2 page statement on policy that would be possible to
>agree on, but it was REALLY hard to figure out how to
>agree on a multipage document in less than infinite time.

We did discuss a possible middle ground between a 1/2 pager and a longer 
policy statement:  a fairly short statement of rules, and discussion of 
illustrative scenarios that aid in the understanding of the rules.

SNIP

Thanks again to Brian for his recap.

John Morris

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Mar 2002 11:42:13 -0600

It would be helpful to identify such policy languages or means of
specification. As I tried to explain in a previous note, this problem is
in general intractable short of writing a programming language. If this
is what the WG wants to do, it should get busy soon. To make things more
complicated, as discussed during the non-meeting, policy for location
information is likely to tied to revealing, e.g., various presence state
information. It makes little technical sense, in my view, to treat one
specific piece of data about an identifier different from another.

One existing, but very limited, approach is CPL. Abstracted from the
concrete parameters, it effectively allows to restrict information based
on querier identity, time of day, and various protocol headers. It does
not allow things that require state such as "only allow if same person
hasn't asked less than ten minutes ago" or "only allow query no more
than ten times a day" or "only allow if the other person has also
allowed viewing this information". I suspect that a similar level of
stateless policy is doable in reasonable time scales, but most likely
needs to be integrated with other policy, e.g., for approving presence
subscriptions.

> minimum contain a bare bones privacy instruction/rule, and might also

Given limits on message size, including a complete policy description
may not be particularly realistic in common scenarios.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Mar 2002 10:09:34 -0600

At 12:04 PM -0500 3/20/02, John Morris wrote:

>  The two threshold outputs would be:
>
>  1)  The structure and elements of a "geopriv object" -- which is 
> different than the mere "format of location information."  The 
> object would at a minimum contain a bare bones privacy 
> instruction/rule, and might also contain location information 
> (although we will need to address situations in which the privacy 
> rule and the location information originate in separate places).

I admit to not being an expert in this area,  but I was thinking that 
the geopriv object would contain on request a set of attributes 
sufficient for policy to be applied, and on response the location 
itself, with attributes describing its state, but not any description 
of the policy itself.  For example, a location requester could fill 
in an object with some attributes saying who it is and how much 
accuracy it requires, and perhaps in some very broad way the purpose 
of the request.  An entity which was aware of the location and the 
policy could then apply it, deciding to disclose the location or not, 
and if so to what accuracy, etc.

>  2)  A statement of rules that MUST be followed in any 
> implementation that uses the geopriv object

This security requirements document can be used for enforcement, to 
argue that protocol x's use of geopriv does or does not comply, and 
therefore should or should not be standardized within the IETF.