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

From: Richard Shockey ^lt;rshockey@ix.netcom.com>
Date: Thu May 16 2002 - 20:44:46 EDT

At 05:00 PM 5/16/2002 -0500, James M. Polk wrote:
>Richard

First let me thank you for a very thoughtful answer ..this is exactly the
kind of proper technical discussion I've been hoping to see here.

>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).

works for me ... great idea... now what about the Policy Object :-)

>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?

Yes ..I have to admit that I am struggling with how to express the concept
of confidence in the accuracy of the location data source.. if you look at
the problem set in wireless it might help in determine what may or may not
be needed here ..the known legal requirements for location in wireless are
within 100 meters as set by Congress in the US ..I have no accurate data on
what the Europeans are requiring in the GSM environment ..however that said
the two solutions are A. GPS but that does not work well in buildings and
B. Triangulation from the base station but that generally requires at least
2 points which is not possible if you are roaming along a highway where the
base stations are linear. This is a highly subjective data point that
SHOULD be under control of the Rule Maker ..but the question is does that
entity have sufficient smarts to evaluate the criterion necessary for
determining a confidence level in the data presented.

>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.

Perhaps but not all SIP calls require location .. I see it as a separate
session the PSAP might be able to request the data separately ..again this
is a fruitful line of discussion.

>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.

well we do have some fine people on this list who have had discussions with
a variety of entities looking at this I know this is a strong area of
interest with Henning Schultzrinne ... certainly since I live in the DC
area ..as does Allison it would be a simple task to sit down with folks and
get a clearer picture of what is really required here.

I have no doubt after numerous conversations with FCC officials and US
State PUC types that they are going to demand an answer to these questions
or they will impose a solution as we have seen Congress do in the wireless
case.

>*************************************
>"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

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 20:41:55 2002

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