%
% > 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
-- --billReceived on Mon Sep 10 18:35:13 2001
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST