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

From: Allison Mankin <[email-masked]>
Date: Mon, 13 May 2002 11:04:14 -0400

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.

Allison

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 May 2002 11:22:33 -0500

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

>Randy or John N. yet, 

Less than the *mandatory* 30 notice with no prior communications on the
list about tentative dates or a hint that this might actually happen -- and
no hotel info.... 

hmmmm......

Does the meeting start at 8am on the 5th, or noon allowing some of us to
fly in that morning? Does the meeting stop (targeted) at noon or 5pm on the
6th?

Answers to both will greatly impact individuals attempting to get there to
properly plan a viable trip without wasting too much time (on either side),
or missing some of this meeting

>Allison

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

---

From: Allison Mankin <[email-masked]>
Date: Mon, 13 May 2002 12:33:22 -0400

James,

I support your proposal that we start the meeting at 
noon on Jun 5, as there are probably quite a few folks
who benefit from that.

What is the reason you would like to target an early stop
on the 6th?  

Hotel info today, I hope.  We also have to get the announcement
out on ietf-announce today, and that needs the travel info.

Allison

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 May 2002 12:20:27 -0500

Allison,
  We are interested in participating if it can be audio conferenced?

Regards,

-- 
Behcet

---

From: Allison Mankin <[email-masked]>
Date: Mon, 13 May 2002 13:23:06 -0400

Behcet,

We will try to arrange audio conferencing.

Allison

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 13 May 2002 12:30:32 -0500

>What is the reason you would like to target an early stop

I didn't know how much time you 4 (Chairs and ADs) had tentatively planned
this meeting requiring

- and -

I just wanted to know for those of us *not* living on the West Coast to be
able to catch a flight that afternoon (if it ended early) or leave the next
day (if ending at or after 5pm).

I'm like most I believe in trying to get as much done as possible -- and
therefore wish to know at least tentative specifics for planning purposes.

>
>Hotel info today, I hope.  

Will there be Internet access via some LAN => BIG "I" during the meeting? 

>We also have to get the announcement

James M. Polk

Cisco Systems

---

From: Dominic Pinto <[email-masked]>
Date: Mon, 13 May 2002 18:51:00 +0100

> several different groups commenting and discussing it off the list

Can't get there anyway due to previous commitments, and will be
Stateside for other reasons later in June.

Any facilities possible for listening in, that won't cost a small
fortune, and commenting in? If delayed because of time zones?

Dominic
-- 
Dominic Pinto
-------------
					| Barn Cottage, Hill House
Senior Associate Telesphere Limited	| Somerton Road, 
					| between Souldern & Somerton
http://www.telespherelimited.com	| Bicester, Oxon, OX25 6LS, UK	
----------------------------------------------------------------------
Ph/Fax: +44 1869 346375 Cellphone/GSM Mobile: +44 780 302 8268
----------------------------------------------------------------------
Friend or Former Student at University of Newcastle upon Tyne? Join us
over the ALumni Weekend June 8th 2002: See
http://www.ncl.ac.uk/alumni/reunion/programme.html
----------------------------------------------------------------------
Check out FITCE Congress 2002 Genoa at http://www.fitce.org
----------------------------------------------------------------------
The Internet should be for Everyone - help make it so by joining the 
Internet Society - Subscribe to ISOC-E's Monthly newsletter, by
sending an e-mail to <[email-masked]> with the following
command in the body of your email message:
subscribe isoc-e-newsletter
----------------------------------------------------------------------
"This e-mail, and the information it contains or is attached to it, is
private and confidential and is intended for the addressee only.  The
unauthorised use, modification, disclosure, copying or distribution of
this e-mail or any of the information it contains or is attached to it
is prohibited and may be unlawful. If you are not the intended
recipient, please notify the sender immediately."

/"\                      
                   \ /                      
                    X  ASCII Ribbon Campaign
                   / \ Against HTML Mail

---

From: Kenji Takahashi <[email-masked]>
Date: Tue, 14 May 2002 11:55:23 +0900

Allison,

Thank you for making this happen.  I can not attend but will send one of my
coleagues, Yoshitsugu Tsuchiya.  Please count him in.

BR,

Kenji

Kenjij Takahashi
NTT Labs.
Tokyo, Japan

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 May 2002 14:59:47 -0500

>out on ietf-announce today, and that needs the travel info.

Haven't seen anything yet. 

I'm not as worried about the Hotel Location within San Diego as I am the
timing on the 6th. Is this interim meeting expected to go until EOB on that
Thursday? Most flights out *off* the West Coast leave around 6pm -- I just
want to know if some of us are going to have to plan on staying Thursday
night and fly out Friday morning (which I hope is not the case).

James M. Polk

Cisco Systems

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 May 2002 16:28:25 -0400

>several different groups commenting and discussing it off the list

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: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 May 2002 17:00:10 -0500

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.

James M. Polk

Cisco Systems

---

From: Richard Shockey <[email-masked]>
Date: Thu, 16 May 2002 20:44:46 -0400

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

>be for a stationary object (infinite TTL) vs. a Rocket (changing quite

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

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

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

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

---

From: Aleksandar Gogic <[email-masked]>
Date: Fri, 17 May 2002 18:59:32 -0700

At 08:44 PM 5/16/2002 -0400, Richard Shockey wrote:
>>such as altitude, velocity and vector (better than direction).

"Vector" may be a slight improvement, but perhaps more appropriate terms 
would be those used in aviation (navigation), such as "Heading" (relative 
to True North).  Along the same lines ... "horizontal velocity" and 
"vertical velocity".

>>TTL should

Granularity of location description (precision) should be independent from 
confidence, it seems to me.  The way I look at this can be illustrated as 
follows.  The location client may be entitled to receive location 
information down to, e.g. 100 meters.  That is granularity, and this is 
what should be the key parameter in privacy rules.  Confidence is the 
degree of certainly to which it can be stated that the object is located 
within the perimeter of the allowed precision.  If the confidence level is 
too low for the purpose of the client, it may make another request that is 
coarser, until it either satisfies the confidence level, or the perimeter 
becomes too coarse.  Confidence is mostly based on measurement, but one can 
get really fancy here.  For example, based on the elapsed time since the 
last available data (e.g. 30 minutes ago), and the assumed mode of 
transportation that the target uses (car), and known traffic conditions in 
the direction of travel since the time of last measurement (North on 
Interstate 405, near Santa Monica Boulevard exit) it may be stated with the 
confidence of 90% that the target has not reached Burbank.  This of course 
is just an illustrative example.  I believe that the confidence should not 
be confused with integrity of the data.  In principle, I believe that the 
location information should always have full integrity, i.e., deceitful 
information should not be used to protect privacy.

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

The two methods described are commonly used for location determination in 
wireless.  They are expected to work well, in fact they do already work on 
many networks, when combined as stated here.  When moving along a lonesome 
highway with only a string of base stations, generally, good visibility to 
satellites exists.  Using time of arrival methods from two base stations 
could even be sufficient for a good measurement, when supplemented by 
topographic information (e.g. it is unlikely that the target has driven off 
into a roadless desert, or even less so into a mountainous forest), 
yielding good confidence in a relatively fine precision perimeter.

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

Aleksandar Gogic
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
Office:  +1 858 651 5386
Mobile: +1 858 213 7368
[email-masked]

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 17 May 2002 22:32:47 -0400

> "Vector" may be a slight improvement, but perhaps more appropriate terms
...

Where did the coordinate system come from? What are the fundamental
properties of discreet events, and discreet points in the coordinate
system? How are these <standard> representations of location and
duration conveyed between hypothetically interoperable implementations?

Terminology I can wait on.

Cheers,
Eric

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 21 May 2002 19:27:40 -0500

>to True North).  Along the same lines ... "horizontal velocity" and 

These 3 terms are quite acceptable to me in this context. 

James M. Polk

Cisco Systems

---

From: Aleksandar Gogic <[email-masked]>
Date: Tue, 21 May 2002 17:54:55 -0700

>These 3 terms are quite acceptable to me in this context.

Taking advantage of this constructive momentum, and perhaps at a risk of 
terminology excess, let me add one more term I have been thinking about for 
the last couple of days.

The term is Azimuth, and can be roughly defined as orientation of the 
object, again relative to True North.  The term is related to Heading, 
albeit a little different.  While Heading is tangential vector of the 
object's trajectory, azimuth can be defined for a stationary object, and 
can be somewhat different than heading for a moving object, e.g. due to 
wind direction affecting flying objects, or due to possibility of moving 
sideways.

I have already heard of some electronic hand-held or vehicle mounted 
product announcements that contain inexpensive magnetic or gyroscopic 
devices, which can be used to determine orientation or azimuth (either term 
is fine with me).  Knowledge of azimuth can be helpful in some geo-location 
applications.

Before we firm up these terms, I am having second thoughts of which of them 
is which.  It's been a while since I worked on navigation projects, but I 
should be able to check this by the time of the June 5-6 meeting.

Alex

Aleksandar Gogic
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121-1714
Office:  +1 858 651 5386
Mobile: +1 858 213 7368
[email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Tue, 21 May 2002 22:00:01 -0400

At 03:17 PM 5/21/2002 -0700, Randall Gellens wrote:
>At 4:28 PM -0400 5/16/02, Richard Shockey wrote:
>
>>  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.
>
>It may be worth keeping in mind some example usages.  For instance, there 
>is an existing draft on requesting and disclosing location information 
>within HTTP.  In that context, a web browser (perhaps on a cell phone) 
>requests a document and is asked for its location. There is a wide range 
>of possibilities in how it answers that request, depending in many ways on 
>what we end up with here in geopriv.

application specific ...

well please do not go down the road of discussing this in the context of 
HTTP it may be an example but that leads to considerations that IMHO are 
not in scope ... been there done that.  I was involved in the Internet 
Print Protocol  work group for many years ... we have a admonition in the 
IETF on the use of HTTP as the substrate for any protocol.  READ IT WILL 
NOT HAPPEN . I continue to advocate that any discussion of transport for 
either the privacy or location object or their interaction is out of scope.

ftp://ftp.isi.edu/in-notes/rfc3205.txt

Perhaps the first order of business for the off site is a discussion of 
recharter.

>For example, the web server could partially fill in some sort of geopriv 
>object, to indicate the required precision and age, its identity, and 
>perhaps some broad category of use.  If the web knows its location but 
>doesn't have the power to process policy, it could perhaps fill in its 
>location but encrypt it, and indicate a location server to which the web 
>server can go to get the data decrypted subject to policy.

so the way I see this is, in the interest of reuse of existing work, would 
someone pray tell me what in LIF object is not applicable to the task at 
hand for the location portion of the problem statement?

>Such example uses raise questions about the information that needs to be 
>in the object(s), if the policy itself is included or not, and if an 
>identifier is included or not.  (In the HTTP example, there is no need for 
>a geopriv target identifier.)

So what is the privacy object?  I'm really looking for answers here ...I do 
not see a syntax of expression for privacy policy discrete from P3P.. is 
this the task a hand?

Oh BTW   as a reminder to to the list ..since there MAY be consensus that 
this is still looking like the interaction of XML objects....

         Title           : Guidelines For The Use of XML in IETF Protocols
         Author(s)       : S. Hollenbeck, M. Rose, L. Masinter
         Filename        : draft-hollenbeck-ietf-xml-guidelines-01.txt
         Pages           : 25
         Date            : 16-Apr-02

The eXtensible Markup Language (XML) is a framework for structuring
data.  While it evolved from SGML -- a markup language primarily
focused on structuring documents -- XML has evolved to be a widely-
used mechanism for representing structured data.
There are a wide variety of Internet protocols; many have need for a
representation for structured data relevant to their application.
There has been much interest in the use of XML as a representation
method.  This document describes basic XML concepts, analyzes various
alternatives in the use of XML, and provides guidelines for the use
of XML within IETF standards-track protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hollenbeck-ietf-xml-guidelines-01.txt

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 22 May 2002 12:43:28 -0400

Morning Richard,

> HTTP

Yup.

Daviel is attempting to associate some attribute (location) to some HTML
page(s) through a meta TAG.

If one comes at this from an end-2-end or pilc-esque PoV, the network
graph (last mile) is the controlling issue, not the point and associated
probability of sampled correctness in a graph-blind coordinate system.

This in turn becomes more complex when the administrative overlays of
carrier-services-for-mobile-devices (cell phones) is added, and there
the controlling issue is a business issue. Roaming didn't appear to have
been solved prior to the W3C-WAP workshop on mobility and privacy in Dec.
2000 (Munich), and for those thinking about extending the semantics of
P3P (DOM tree element policy evaluation) beyond the wireline demark, the
walled gardens pretty much defined the (in)ability of edge-devices to
either reference rule-sets , or access evaluators, in a location-independent
fashion.

What Daviel could offer, could also IMO be provisioned using CNRP. As there
is a working implementation of CNRP, that does more than just co-location
hinting. 

> So what is the privacy object? 

Good question. I'm still waiting to find out what an "embedded protocol"
is.

It isn't every day you see an I-D that only references Scott's "WHEN WE SHOUT"
memo. There are a few things clearly left to the imagination, and unless this
is just a General Area policy romp, our good sense requires that we come up
with ... something implementable.

Cheers,
Eric

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 May 2002 13:41:43 -0700

At 10:00 PM -0400 5/21/02, Richard Shockey wrote:

>>  It may be worth keeping in mind some example usages.  For 
>> instance, there is an existing draft on requesting and disclosing 
>> location information within HTTP.  In that context, a web browser 
>> (perhaps on a cell phone) requests a document and is asked for its 
>> location. There is a wide range of possibilities in how it answers 
>> that request, depending in many ways on what we end up with here 
>> in geopriv.
>
>  application specific ...
>
>  well please do not go down the road of discussing this in the 
> context of HTTP it may be an example but that leads to 
> considerations that IMHO are not in scope ... been there done that. 
> I was involved in the Internet Print Protocol  work group for many 
> years ... we have a admonition in the IETF on the use of HTTP as 
> the substrate for any protocol.  READ IT WILL NOT HAPPEN . I 
> continue to advocate that any discussion of transport for either 
> the privacy or location object or their interaction is out of scope.

I agree that HTTP is a lousy choice for a transport protocol, but 
that has nothing to do with our discussion.  We are not working on a 
transport protocol, and transport issues are out of scope.

My point is that it can be helpful to keep in mind some idea of how 
our work will be used within other protocols, in order to know what 
information we need to have in our object(s).

---

From: Randall Gellens <[email-masked]>
Date: Wed, 22 May 2002 13:53:52 -0700

>  page(s) through a meta TAG.

That's the other draft; I was talking about the one where the server 
requests the client's location.  But the specifics don't matter -- it 
seems to me to be likely that people will want to do something like 
this, and I'm curious what this means for the geopriv object(s).

>  I'm still waiting to find out what an "embedded protocol"
>  is.

Something like SASL comes to mind.