Re: I-D ACTION:draft-morris-geopriv-core-00.txt

I wanted to ask for feedback and discussion on the referenced I-D
(which is, as these things go, fairly short). In my personal view,
the I-D frames one of the most important questions that we need to
resolve either before or in Atlanta. I think it would be very
helpful if we could start a conversation about the questions before
we get to Atlanta.

The real question is whether the Location Object will be able to
contain some limited set of privacy rules. I've cut and pasted the
"overview" section from the I-D into the end of this e-mail, just to
give you a quick look at possible approaches to the issues.
Obviously, the full draft goes into more detail.

Any comments and questions would be welcome.

John

At 4:21 PM -0500 10/30/02, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
> Title : Core Privacy Protections for Geopriv Location Object
> Author(s) : J. Morris et al.
> Filename : draft-morris-geopriv-core-00.txt
> Pages : 10
> Date : 2002-10-30
>
>In designing the requirements for the Geopriv Location Object (LO), a
>key question for the working group is whether to include privacy-
>protecting rules inside the LO itself, and if so, how many and what
>rules should be contained in the LO. The Internet-Draft first
>suggests that the LO should contain at least a limited set of privacy
>rule fields, and second proposes a set of rules for inclusion in the
>Location Object.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-morris-geopriv-core-00.txt
>
<snip>

Excerpt from the I-D:

1. Overview and Introduction

A critical issue facing the Geopriv working group is whether the
Location Object (LO) to be designed should include fields for
particular privacy-protecting rules, or instead should simply refer
to an external set of privacy rules.

There are at least four plausible answers to this question, labeled
somewhat arbitrarily as follows:

* "Entirely External" -- the LO should only contain a URI reference
to an external set of privacy rules that must be followed by any
recipient of the LO

* "Bare Bones Internal" -- the LO should contain one rule that
specifies that the Location Information (LI) shall not be retained
longer past xyz date (or longer than xyz duration), along with a URI
reference to an external set of privacy rules that must be followed
by any recipient of the LO

* "Limited Internal" -- the LO should contain a very limited set of
rules that cover the great bulk of likely privacy rules (as well as
the ability to include a URI reference to an external set of privacy
rules if more robust rules are needed)

* "Full Internal" -- the LO should be defined to be able to contain a
full, robust, and potentially complex set of privacy rules

To our knowledge no one in the working group has advocated for the
"Full Internal" option. That option would be the most complex to
define, the most complex to implement, and would not be consistent
with the goal of enabling the use of the Geopriv LO on constrained
devices or with constrained bandwidth.

Some WG participants have expressed their view that the "Entirely
External" approach would be the quickest for the working group to
accomplish, and that if fully implemented in the marketplace the
approach could give end users a great deal of control and flexibility
in the protection of Location Information.

Other WG participants (including at least some of the authors here)
have argued that most effective way to ensure that users have some
privacy control is for the LO to be defined to carry a limited number
of privacy rules.

It is not the purpose of this Internet-Draft to attempt to reach a
definitive answer to this critical question. Instead, this I-D
articulates one approach to the "Limited Internal" set of privacy
rules. By specifying one view of exactly how the Limited Internal
set of rules might be expressed, the Internet-Draft hopes to aid the
WG's decisions on this key issue.

Five separate things follow below. First, there is a brief and broad
brush statement of the core privacy elements that we think should be
contained in a "Limited Internal" design of the Location Object.
Second, there is a more precise proposal on exactly how to articulate
and express these elements; significantly, this proposal combines
three of the elements into one "permissions table." Third, there is
an alternate proposal that adds a few additional elements to the
proposed permissions table, and thereby significantly enhances the
power of the LO privacy protections. Fourth, there are a few
additional comments about the proposals. Fifth and last is language
in the form of a Requirement that could be inserted into a
requirements document if the WG chooses the "Limited Internal"
approach.
Received on Thu Oct 31 11:59:37 2002