Re: Notes from Non-meeting

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
Received on Wed Mar 20 12:08:22 2002