Subject: RE: general question

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Sep 2001 17:51:52 -0400

> I'm leary of a third-party device holding the data (can you say,
> "key-escrow?" or WellKnownPointsofFailure?  - sure you can. 
Well, actually, I'm thinking that I can build a server on a big Linux box
that gives me mucho better security than the puny thing I could do
on a cell phone.  Can you say "PublicKeyCryptoOperationsPerSecond"?
My cell phone tells my server where I am, my server tells whomever I
authorize where I am.  It has a lot more space for rules and a lot more
horsepower for crypto.

> In anycase,
> Ok.  The OOD has what attributes wrt the "geo" component of geopriv?
> 
> 	lat/log/alt
> 	vector/velocity
> 	mass/"size"
Need the other form:
planet/country/state/county/city/street/building/floor/room
Need both in the report, plus a flag that tells if one value
was translated into the other, and another field for who did the
translation.

> 
> And the priv part... :)
> Classes of "who wants to know"
> 
> 	Public data - anyone/thing can get the bits
> 	"Good Guys"
> 	"Bad Guys"
> 	"Gargoles" (instrumentation/measurement)
> 	
> 	(and what subclasses of these "buckets" are useful?"
> 	e.g. multi-juristdictional transit bwtn the requestor and
> 	the OOD)
Starting to get weird on me.  Seems to me that you
have to have your own classes (the spec doesn't define them).
You put a requestor in a class.  This might be done
on the fly, or more likely, beforehand.  I like the
idea of having a way that a third party certifies that
some requestor has some characteristic you want to know,
and you can then use the certification to authorize into
a class.  For example, if there were someone who would
certify GEN-U-INE pizza shops from snake oil salesmen,
that would be nice.  

Anyway, a class gets a rule, and the rule says what the
requestor gets.

You have to decide what ACCURACY each class gets to each
component, where you have a value for - "no information
and let him know that", and another for "make something up 
that looks reasonable, but is pure fantasy and give the
sucker that"
> 
> When does the OOD  release i(or authorize, in the event of third-party
> state-keepers) the data?
> 
> 	Timeliness
> 	Relevence
> 	"granularity"
I'd express this as:
"accuracy, update rate, and minimum-change.  I'm assuming by
granularity you are trying to filter out reports when a component
doesn't change by some defined amount.  I'm not sure I fully
appreciate "Timeliness".  I don't think it is helpfull to me to
give anyone old, but accurate location.

> 
> Please fill in the missing catagories and then some kind soul can 
> construct (small) matrix of useful choices.
> 
> e.g. for granularity:
> 
> 	exact match on "size"+vv
> 	w/in 1m of "size"+vv
> 	w/in 100m of "size"+vv
> 	w/in 10km of "size"+vv
> 
> or something along these lines.
Confusion.  I don't report how near I am to anything.
I can turn location around and subtractl; you tell me
where you are, I know where I am, I subtract, and I
know how far you are from me -- I don't reveal where
I am to you.  Two cannot play that game together!

I do want to support tracking, which implies periodic
reports.  I need to have a decision on how often I will
permit reports to be given (min period).  That is
my decision.  The requester can ask for a longer
period, and he can also ask for a filter on minimum
change before a report is generated.  Note that
min period is important even if I don't explicitly
support tracking - I want to control how often I
will respond to a request for location, as I want to
control implicit tracking.

Brian

---

From: Adam Shostack <[email-masked]>
Date: Mon, 10 Sep 2001 18:07:23 -0400

> was translated into the other, and another field for who did the

I thought that we were supposed to select an existing format, not
create a new one?

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

---

From: Bill Manning <[email-masked]>
Date: Mon, 10 Sep 2001 15:35:56 -0700 (PDT)

% 
% > I'm leary of a third-party device holding the data (can you say,
% > "key-escrow?" or WellKnownPointsofFailure?  - sure you can. 
% Well, actually, I'm thinking that I can build a server on a big Linux box
% that gives me mucho better security than the puny thing I could do
% on a cell phone.  Can you say "PublicKeyCryptoOperationsPerSecond"?
% My cell phone tells my server where I am, my server tells whomever I
% authorize where I am.  It has a lot more space for rules and a lot more
% horsepower for crypto.

	Why crypto? Are we examining the credentials of requestors?
	And what about those requesting info about OOD? Do they need
	enough cycles to generate authenticatable requests?

% > In anycase,
% > Ok.  The OOD has what attributes wrt the "geo" component of geopriv?
% > 
% > 	lat/log/alt
% > 	vector/velocity
% > 	mass/"size"
% Need the other form:
% planet/country/state/county/city/street/building/floor/room
% Need both in the report, plus a flag that tells if one value
% was translated into the other, and another field for who did the
% translation.

	a varient of the first. 

% > And the priv part... :)
% > Classes of "who wants to know"
% > 
% > 	Public data - anyone/thing can get the bits
% > 	"Good Guys"
% > 	"Bad Guys"
% > 	"Gargoles" (instrumentation/measurement)
% > 	
% > 	(and what subclasses of these "buckets" are useful?"
% > 	e.g. multi-juristdictional transit bwtn the requestor and
% > 	the OOD)
% Starting to get weird on me.  Seems to me that you
% have to have your own classes (the spec doesn't define them).
% You put a requestor in a class.  This might be done
% on the fly, or more likely, beforehand.  I like the
% idea of having a way that a third party certifies that
% some requestor has some characteristic you want to know,
% and you can then use the certification to authorize into
% a class.  For example, if there were someone who would
% certify GEN-U-INE pizza shops from snake oil salesmen,
% that would be nice.  
% 
% Anyway, a class gets a rule, and the rule says what the
% requestor gets.

	Humph.. If the request passes through my infrastructure,
	I may want/require information about either/both parties.
	So I, as transit provider, become yet another requestor 
	for information about the OOD.  And if I don't get the
	access I want, I deny transit.

	Couple this with the idea of multiple transit providers
	btwn the "original" requestor and the OOD and things can 
	become complex indeed.

% You have to decide what ACCURACY each class gets to each
% component, where you have a value for - "no information
% and let him know that", and another for "make something up 
% that looks reasonable, but is pure fantasy and give the
% sucker that"
% > 
% > When does the OOD  release i(or authorize, in the event of third-party
% > state-keepers) the data?
% > 
% > 	Timeliness
% > 	Relevence
% > 	"granularity"
% I'd express this as:
% "accuracy, update rate, and minimum-change.  I'm assuming by
% granularity you are trying to filter out reports when a component
% doesn't change by some defined amount.  I'm not sure I fully
% appreciate "Timeliness".  I don't think it is helpfull to me to
% give anyone old, but accurate location.

	I put accuracy in this bucket.
	wrt timeliness, something along the lines of:

	"If ONSTAR(tm) wants to know where I am right now (+/-5sec)
	then the granularity is 10Km. If they want my travel path
	over the last 30min, with a 5 minute delay, then the granularity
	is 1Km"

% Confusion.  I don't report how near I am to anything.
% I can turn location around and subtractl; you tell me
% where you are, I know where I am, I subtract, and I
% know how far you are from me -- I don't reveal where
% I am to you.  Two cannot play that game together!

	size = 3cm square exactly or "bigger than Manhattan".
	v/v  = 58degree heading/43furlongsperfortenight

	You don't report how "near/far" you are to anything,
	you report your size, direction(if any) and speed(ifany)
	in relation to the lat/long/alt nee cubical/floor/building/street/city/county/postalcode etc.

	The granularity of these values depends on whom is asking and
	(potentially) from where they are asking.

% I do want to support tracking, which implies periodic
% reports.  I need to have a decision on how often I will
% permit reports to be given (min period).  That is
% my decision.  The requester can ask for a longer
% period, and he can also ask for a filter on minimum
% change before a report is generated.  Note that
% min period is important even if I don't explicitly
% support tracking - I want to control how often I
% will respond to a request for location, as I want to
% control implicit tracking.

	Tracking is tough. But it is tougher to manage/control.
	One of those "Is it permitted by the requestor & do I
	have the cycles to deal with it" issues.

% Brian

-- 
--bill

---

From: Kenji Takahashi <[email-masked]>
Date: Tue, 11 Sep 2001 09:25:00 +0900

I believe so.  For example, 3GPP is working on 23.032 series and also Mari
wrote an ID,
http://search.ietf.org/internet-drafts/draft-korkea-aho-spatial-dataset-01.t
xt.  They have not been finalized yet but look soon to be.

Kenji
----- Original Message -----
From: "Adam Shostack" <[email-masked]>
To: "Rosen, Brian" <[email-masked]>
Cc: "'Bill Manning'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, September 11, 2001 7:07 AM
Subject: Re: general question

---

From: Andrew Daviel <[email-masked]>
Date: Sat, 29 Sep 2001 19:21:03 -0700 (PDT)

> xt.  They have not been finalized yet but look soon to be.

I have so say I don't like the suggested position format

[N|S]degree.minute.second.f,     N60.08.00.235556
degree range [0-90], decimal fraction f in arbitrary length

It doesn't seem to match anything in common use afaik - nautical,
recreational, or GIS - and incurs processing overhead converting
it for use in calculation.

After a couple of years of arguing this issue in Dublin Core, etc. I much
prefer signed decimal degrees, which is unambiguous (well, apart from axis
ordering), simple to understand and parse, and compatible with GIS data.

(Common nautical use seems to be to give position e.g.
49°04'43"N 140°17'32"E  or 49°04.71N 140°17.53N, but the degree symbol is
not an ASCII character)

-- 
Andrew Daviel
Vancouver Webpages

---

From: Kenji Takahashi <[email-masked]>
Date: Mon, 01 Oct 2001 11:48:41 +0900

Andrew,

I am happy to hear from you again!!  You may be right and I do not have
strong preferences on the format/coding, which is out of scope of this
working group.

I am more interested in privacy issues on the geo-tag/header.
I think that using, for example, HTTP HEAD, people can pass around their
position information.  This scenario is a bit different from the one written
in your draft, which is for search engines....
Do you have any ideas on how the "Negotiation" written in Section 3.1 of the
geo-header draft can be done?  What is the negotiation protocol?  What does
the "trusted site list" look like?  How can users securely store and access
to the list? etc.  I think they are the main topics of this working
group.....

Regards,

Kenji