Re: Geopriv WG - meeting 5-6 Jun, other news

At 11:04 AM 5/13/2002 -0400, Allison Mankin wrote:

>With our Area Director's consent, we have just advanced all of
>our milestones (and the charter page is updated). We have also
>confirmed his permission for us to have an interim meeting,
>as well as the Yokohama meeting, to try to catch up.
>
>The interim will be at Qualcomm, in San Diego, Jun 5-6. Qualcomm
>has confirmed hosting. I don't have room and hotel info from
>Randy or John N. yet, but we will get it to you, as well as looking
>into providing a phone bridge.
>
>The basis of our discussions for now should be the requirements draft
>that Jorge Cuellar has recently announced, which represents joined efforts
>from several of the folks who wrote before, and which has had
>several different groups commenting and discussing it off the list
>to date.

Unfortunately I will personally be unable to attend the proposed off site
but I wish to make some comments on the proposed requirements draft, which
IMHO is currently inadequate to the task.

In the first place it is my belief that we are not dealing with a protocol
here but objects and the policy surrounding those objects.

The proposed draft way too long on imposing policy on the objects without
actually defining any requirements for the objects.

It strikes me there are two key requirements here which is 1. a Location
Object which is the semantic expression of location data and other useful
information ( raw or other ) of the Target that can be interpreted by
Location Seeker in order to act upon it and 2. A Location Privacy Object
that presumably under the control Rule Maker ( perhaps the Target ) that
expresses what information can be transferred and under what
conditions. Both of these objects reside in this "Location Server" that
can be queried by some undefined and presumably out of scope application
mechanism keyed on by some identifier ( phone number for instance).

I submit that any discussion of transport of geopriv objects be deemed out
of scope and those discussions are best left to the applications that need
geopriv data ...SIP for instance.

Let be honest here .. though there are several applications where this
architecture might be useful the clear and present need is in Internet
Telephony and SIP in particular.

Where it MIGHT be legitimate to discuss Authentication & Authorization
requirements between geopriv entities it is not appropriate to impose
requirements on other protocols that may already have built in AA
methodologies. It is very easy for me see how these objects could be easily
integrated into the SIP environment using all of the existing tools SIP has
at its disposal without imposing any new protocol requirements on SIP. The
Location Object and its Privacy object could easily be transferred to a
Location Server integrated as part of the SIP proxy during a REGISTER
session for instance ...and a Location Seeker could request the Location
Object in a form of INVITE where the PSAP could clearly and unambiguously
authenticate its identity.

Discussions on identity management is SIP is now well underway.

What I'm hoping will come out of this meeting is some agreement that the
requirements document is not done unless the requirements for the Location
Object and Privacy Object can be sufficiently defined, other wise we will
not be able to progress the work froma short, clear, concise and reasonable
document. I suggest now and will continue to suggest that the scope of the
requirements document reflect this generally minimalist approach to object
design and leave general policy details to the applications that must use
the objects.

Now on to some particulars.

IMHO these data elements look like XML objects and the Privacy Object
should be an extension of the work already done in W3C on P3P. Where as
P3P was designed as a PULL mechanism to define privacy policy for servers
running HTTP ..what we are seeing here is more of a PUSH mechanism in the
opposite direction. The Rule Maker defines what they want people should
see not the Location Seeker defining what their policy is.

So What are the requirements for a Location Object? I might suggest a good
start might be ...

Index key - telephone number ?
TTL
Latitude Longitude
Source
Time of source sample
Confidence Level
Motion & Direction if available etc.

What then are the requirements for the Privacy Object ... I make no claim
to be a expert on the P3P work but I think that would be a good place to start.

Last but not least I have real problems with Identity Protection statements
in REQ 12. I've said this before and I'll say it again ..there are serious
policy issues here with public safety officials if the protocol can permit
the Policy Maker to override legitimate requests for identity information.
This is not the wiretapping issue ... on issues involving public safety
state and federal regulators WILL take a very very firm stand. Therefore
the language should be changed from MUST to MAY be able hide real identity.

I want this list to understand that we are laying the ground work for what
is perhaps a once in a generation advance in the concept of a public
service location protocol that if defined correctly could link not just the
location of an individual in distress but also provide life saving links to
other forms of data ...health records that could save countless
lives. Think about that in the context of privacy requirements.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza Bldg 8 Sterling, VA 20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237
<mailto: rshockey@ix.netcom.com> or
<mailto: rich.shockey@neustar.biz>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Received on Thu May 16 16:25:44 2002