Subject: RE: full integrity?

From: Dan Greening <[email-masked]>
Date: Wed, 22 May 2002 08:11:18 -0700

Yes, I see this now.  Thanks for the clarification.

So if bogus (or self-naming) is allowed, then we need to put safeguards
in place, just as are in place today for email (open-relay rejection,
intermediate node signing/tracking and so forth, and signed original
messages).

To me this is less an issue of a person managing his/her own list of
aliases, or selectively sending out bogus information, and more pointing
out the need to localize or control obfuscation in an environment of
distributed identity.

In short, we want a distributed environment for scalability. In a
distributed environment, people can self-inject presence and location.
Geopriv (actually I think this is likely a responsibility of something
like Mobile Location Protocol) should have a requirement that says we
can track and authenticate intermediaries, if they sign messages. This
allows people to say "I won't accept unreliable presence information" or
even blackball sites that accept unsigned presence information, just as
many mail servers blackball open-relay mail servers.

Dan Greening, Ph.D.  CEO, BigTribe Corporation 
              330 Townsend Street, Suite 209, San Francisco, CA
94107-1662 
              [email-masked]  +1(415)995-7151  fax 995-7155

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]] 
Sent: Wednesday, May 22, 2002 7:11 AM
To: Dan Greening; James M. Polk; Randall Gellens; Aleksandar Gogic;
Richard Shockey; [email-masked]
Subject: RE: full integrity? (was: RE: Geopriv WG - meeting 5-6 Jun,
other news)

Dan Greening wrote:

> This stuff about bogus locations sounds like something that won't get
> market usage by many people (like less than 1%), and possibly no
> carriers.  It seems like "requirements" should be serious market
> requirements, otherwise the IETF Geopriv requirements could 
> end up stuck in the "academically interesting" category and ignored.

This depends on how closed the systems are for passing this information.
If we're only talking about carrier systems than I might agree with you.
But if enterprises and individuals will have the means to inject
presence and location information into these tracking networks (and I
believe they will over time) then this is hardly academic.

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 
                sip:[email-masked]

---

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

>  intermediate node signing/tracking and so forth, and signed original

This seems to me to be a totally separate issue from what I mentioned.

I was trying to get an idea of how wg participants felt about 
accuracy adjustments being the primary method of disclosure control, 
as opposed to also allowing multiple locations.

The example I gave was in the context of some protocol where geopriv 
is used, I ask you for something, before you reply you ask me for my 
location.  I don't want you to know where I am.  I can either send 
you a vague location, or I can send you multiple locations, one of 
which is correct.  Earlier in the life of this group, people 
expressed a desire to be able to do the latter, in addition to the 
former.  Very recently someone stated that the later should not be 
permitted.  I'd like to get an idea of how the group feels about this.

---

From: Randy Bush <[email-masked]>
Date: Wed, 22 May 2002 14:00:11 -0700

> which is correct.

or i can tell you to stuff it.  this would be my default mode.
though, for my mobile phone, i am tempted to allow folk to know
in what time zone i am, or, more usefully to them, what time of
day it is where my mobile phone is.

randy

---

From: Richard Shockey <[email-masked]>
Date: Wed, 22 May 2002 17:09:27 -0400

At 01:48 PM 5/22/2002 -0700, Randall Gellens wrote:

>I was trying to get an idea of how wg participants felt about accuracy 
>adjustments being the primary method of disclosure control, as opposed to 
>also allowing multiple locations.
>
>The example I gave was in the context of some protocol where geopriv is 
>used, I ask you for something, before you reply you ask me for my 
>location.  I don't want you to know where I am.  I can either send you a 
>vague location, or I can send you multiple locations, one of which is 
>correct.  Earlier in the life of this group, people expressed a desire to 
>be able to do the latter, in addition to the former.  Very recently 
>someone stated that the later should not be permitted.  I'd like to get an 
>idea of how the group feels about this.

Well my answer to that question is simple ..out of scope.  Now you are 
imposing policy on the objects as well I think the best course of action 
for geopriv is to remain policy neutral to how applications may or may not 
use the objects in question ..you would have really enjoyed the IETF 
debates on wiretapping several years ago :-)

  If the policy can be expressed or defined in such a manner that the 
location server gives multiple locations then who are we as designers to 
say it shouldn't ..however I am going to suggest that there may eventually 
be legislation that demands location servers give accurate information to 
special classes (Fire Police) of requesters if they can be properly 
authenticated.

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: Randall Gellens <[email-masked]>
Date: Thu, 23 May 2002 14:20:00 -0700

At 5:09 PM -0400 5/22/02, Richard Shockey wrote:

>> accuracy adjustments being the primary method of disclosure 
>> control, as opposed to also allowing multiple locations.
>
>  Well my answer to that question is simple ..out of scope.

Maybe it would help if I phrased the question this way: Is it 
necessary for the geopriv object(s) to be able to carry multiple 
locations for the target?

>    Now you are imposing policy on the objects as well

I don't see how my question could be interpreted as imposing policy.

>   I think the best course of action for geopriv is to remain policy 
> neutral to how applications may or may not use the objects in 
> question

I agree that the less we need to do with policy the better off we'll 
be.  We may need to pay some attention to how our objects are used, 
if only to address the privacy and security issues, and to make sure 
that our work is capable of being used.

>   ..you would have really enjoyed the IETF debates on wiretapping 
> several years ago :-)

I recall those debates well; that issue has relevance to our work 
here, but not to the question I have tried to raise.  (The 
wiretapping issue relates to how much attention we pay to regulatory 
and legal constraints.)

>
>   If the policy can be expressed or defined in such a manner that 
> the location server gives multiple locations then who are we as 
> designers to say it shouldn't ..

Can our object carry multiple locations?

>  however I am going to suggest that there may eventually be 
> legislation that demands location servers give accurate information 
> to special classes (Fire Police) of requesters if they can be 
> properly authenticated.

That shouldn't be our concern.  There can be all sorts of constraints 
on policy (legal, contractual, who knows what), but I don't think we 
need to worry too much about it, any more than the IETF worries about 
lawful wiretapping.  We design our protocols to resist eavesdropping 
or other attacks, and let the implementers worry about adherence to 
legal or contractual constraints.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 23 May 2002 14:30:35 -0700

At 2:00 PM -0700 5/22/02, Randy Bush wrote:

>  or i can tell you to stuff it.

Well, of course, you can decline to disclose the information, but 
that really is besides the question I tried to raise.  In my example, 
there is an assumption (and I apologize for not making this more 
painfully clear) that I want the service, and in order to get it I 
need to disclose my location.  If I don't want the service (or if any 
disclosure at all isn't worth it, or if any disclosure within the 
required accuracy isn't worth it), then my question doesn't apply.

If I do want the service, and if I need to provide location within 
some minimum accuracy in order to get it, one possible approach is to 
say "OK, here are x locations as accurate as you wanted.  Give me the 
service for all x."

As others have pointed out, providing this capability naturally adds 
some measure of complexity to our object(s).  As a general principle, 
simpler, less capable, and fewer options are better.  As long as it 
isn't too simple and too incapable to be useful.  So the question 
remains: is this capability required?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 May 2002 17:39:45 -0400

I would imagine that most protocols that carry geopriv information will 
be capable of carrying multiple objects of the same type. Examples: 
822-like headers or MIME bodies. Since you may have different policy 
embedded for each location, you end up replicating the whole thing 
anyway, to be fully general. Thus, this seems like something best left 
to the "transport" mechanism. If the thingie-to-be is XML, having 
multiple top-level tags is just a DTD or schema matter. In general, I 
don't think this is a major constraint. Usually, adding "one more" at 
any level of the hierarchy isn't that hard unless you have to try to 
express complicated relationships between the items.

Randall Gellens wrote:

> 
> If I do want the service, and if I need to provide location within some 
> minimum accuracy in order to get it, one possible approach is to say 
> "OK, here are x locations as accurate as you wanted.  Give me the 
> service for all x."
>

---

From: James Card <[email-masked]>
Date: Thu, 23 May 2002 23:16:13 -0700

>control, as opposed to also allowing multiple locations.

My preference would be to always transmit exactly two spatial 
coordinate sets (minimal case, two lat/lon points; with optional 
altitude and/or direction/velocity vectors). 

The process I currently envision would be something like this:

1. Calculate the current (most recent) geospatial position, 
   returning a single point. Let's make an example with very 
   simple math: 2 degrees north latitude, 2 degrees east 
   longitude. 

2. Calculate the estimated error or degree of precision. In this 
   example we'll say it is +/- 0.2 degree longitude, +/- .1 
   degree latitude.

3. Add and subtract the estimated error to create a bounding 
   box.  Our example location is now defined by two lat/lon 
   points: one at 1.9 degrees north, 1.8 degrees east; and the 
   other at 2.1 degrees north, 2.2 degrees east.

   This represents the best-case calculation of position, and 
   would be transmitted only in response to requests whose 
   authentication/authorization/policy clearance matched the 
   highest level of trust.

4. All other requests would cause a further calculation to 
   expand the size of the bounding box surrounding the location. 
   The size of the resulting box would vary in inverse 
   proportion to the degree of trust assigned to the request 
   (through the policy/authentication mechanism).

The result might be something like the following diagram, where 
the "o" represents the single point from step 1, the small box 
(with the "*" characters marking the reference points of the 
bounding box) presents the highest-precision estimate of 
position from step 3, and the large outer box might be the 
coordinates provided to less trusted requestors.

   +------------------------------------------------*
   |                                                |
   |   +-------*                                    |
   |   |   o   |                                    |
   |   *-------+                                    |
   |                                                |
   |                                                |
   |                                                |
   |                                                |
   *------------------------------------------------+

The recipient of the data would always understand that the 
actual position is contained within the bounding box, and could 
then determine whether that provides enough "accuracy" for their 
purpose.

I see no need to transmit any additional "confidence level" or 
"degree of precision" information. You always get exactly two 
lat/lon points. Applications that require a single lat/lon point 
may simply calculate the centroid of the bounding box.

I also see no need to transmit more than one set of location 
data in any given transaction. The requestor can always assume 
that they have received the most accurate information available 
(given the authentication/policy status of their request).

This is admittedly a very simplified model -- and that is what I 
like about it -- but I believe that we've slogged through arcane 
detail and abstract discussion long enough; I needed a simple 
way to summarize my thinking about the multiple locations / 
accuracy adjustment question.

To summarize: I favor full integrity, always transmitting the 
the greatest precision that is consistent with the policy 
mechanism under which the request was authenticated.

-- 
James Card  --  http://home.inreach.com/jdcard/
The wise person restrains his words, and the one who keeps 
his cool is a discerning person. -- Proverbs 17:27

---

From: John W Noerenberg II <[email-masked]>
Date: Wed, 29 May 2002 13:50:49 -0700

At 5:39 PM -0400 5/23/02, Henning Schulzrinne wrote:
>I would imagine that most protocols that carry geopriv information 
>will be capable of carrying multiple objects of the same type. 
>Examples: 822-like headers or MIME bodies. Since you may have 
>different policy embedded for each location, you end up replicating 
>the whole thing anyway, to be fully general. Thus, this seems like 
>something best left to the "transport" mechanism. If the 
>thingie-to-be is XML, having multiple top-level tags is just a DTD 
>or schema matter. In general, I don't think this is a major 
>constraint. Usually, adding "one more" at any level of the hierarchy 
>isn't that hard unless you have to try to express complicated 
>relationships between the items.

Eventually there are practical considerations governing the number of 
bits that can be usefully sent.  But sending multiple instances of a 
location object shouldn't be prohibited, I agree.

Similarly, there are practical limits to representing the precision 
of the location.  After all, it takes time to calculate the position 
and update it as needed, and the precision is a function of the time 
needed for the calculation.  But just as with the number of 
locations, the ability to report position with varying precision 
shouldn't be prohibited.

>>some minimum accuracy in order to get it, one possible approach is 
>>to say "OK, here are x locations as accurate as you wanted.  Give 
>>me the service for all x."

The client requesting the location object(s) has the opportunity to 
decide how it will choose to react to this response, just as it would 
if no location objects are returned, or if the response doesn't meet 
precision requirements for the service.

Whether or not Alice lies about the precision of her location or the 
number of locations she has is beside the point of whether or not she 
can respond with variable precision or a variable number of 
locations.  In the same fashion how Bob interprets Alice's location 
information is not the issue.

However, the protocol must include a way for the requester to specify 
constraints on the location report.  Similarly, the protocol must 
include a way for the responder to specify constraints on the 
location request.  For both the requester and the responder, the 
constraints must include the number of location objects and the 
precision of each object.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, that makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 May 2002 19:42:14 -0400

> include a way for the responder to specify constraints on the location 
> request.  For both the requester and the responder, the constraints must 
> include the number of location objects and the precision of each object.

Plus, to play my favorite broken record: remember that there may not be 
a special request "protocol" at all and no requests. The 'responder' may 
simply decide to include a suitably signed/encrypted object as an email 
attachment, SIP header or body, NNTP header or body, SNMP blob, HTTP 
POST request, SOAP payload, BEEP payload or who knows what else. I 
suspect that every single IETF-standardized application or management 
protocol can usefully convey location information in some circumstance. 
Assuming that the recipient can reach out and touch the target to ask 
for that information in all cases is unrealistic and overly constraining.