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

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Thu May 16 2002 - 18:00:10 EDT

Richard

I share many of your views written here. I would add a few requirements
such as altitude, velocity and vector (better than direction). TTL should
be coupled with the Time of source sample because the LO of a Target might
be for a stationary object (infinite TTL) vs. a Rocket (changing quite
rapidly).

I question how you determine "confidence" within the LO Requirements. Is
the policy Rule Maker going to tell me that I should only have a 50%
confidence factor of the answer I just got from some location server when
trying to determine your location, or should that be in the background?
Shouldn't the Rule Maker (Target's Policy) determine how granular the
information is going to be based on who's asking for it?

I don't know if I agree with your PUSH preference at this time, except in
times of emergency -- in which case I believe the LO should be part of the
original INVITE packet in SIP.

Has anyone talked to the FCC and NENA (in the US, and counterparts in other
countries) about their requirements regarding disclosure of information?
One good lawsuit might very well change (or obsolete) this protocol if its
written with the constraints of these requirements and past views.

At 04:28 PM 5/16/2002 -0400, Richard Shockey wrote:
>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>
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Senior Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX 75082 USA
w) 972.813.5208
f) 972.813.5280
www.cisco.com
Received on Thu May 16 18:01:51 2002

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST