Subject: RE: general question

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Sep 2001 16:56:32 -0400

I agree.  I do think that one of the mechanisms that will help is that
in many cases, you will have delegation to a processor that has more
capacity and storage than the OOD.  It can keep the policies, and do
the authentication on behalf of the OOD.

However, I agree with your central theme, which is that you can't 
realistically have fine-grain control over everything, and yet you 
want to.  I'm all for practical answers to knotty problems.  
And, for sure, not everyone will be happy.  So long as we have a 
middle ground, and not one or the other extreme, I'll live with it.

Once again, I'd really like to get to the actual requirements, in
requirements language, and stop beating around the bush (no pun
intended) with vague concepts.

Brian

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Monday, September 10, 2001 11:39 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: general question
> 
> 
> 
> Figuring out "where" something is (and "recording" that data) 
> is fairly
> straightforward.  The tough part is what friend Bush has been 
> trying to
> hammer home (and its showing up in other places as well.. provreg for
> example) which is:
> 
> Who gets to know (and to what precision) which attributes 
> about "where"
> the object of desire "is"?   For the properly paranoid, that 
> means each
> object of desire (OOD) needs to "know" about everything that 
> might want
> to find out "where" it is, attach a policy to it so it knows what and 
> how much info to release to the querier.  This might be too 
> much state to
> keep.
> 
> While it may be too much to have the protocol make the 
> presumption that 
> any OOD can be located to an arbitrary degree of precision, 
> it is overkill
> (IMHO) to require the OOD to keep an arbitrary number of 
> policies about
> who gets to know what and to to a given degree of precision. 
> 
> Finding that middle ground will be tough.  And when "rough 
> consensus" is
> reached, it will be, at best, an 80% solution; i.e. no one 
> will like it.
> 
> 
> --bill
>

---

From: Bill Manning <[email-masked]>
Date: Mon, 10 Sep 2001 14:19:34 -0700 (PDT)

% 
% I agree.  I do think that one of the mechanisms that will help is that
% in many cases, you will have delegation to a processor that has more
% capacity and storage than the OOD.  It can keep the policies, and do
% the authentication on behalf of the OOD.
% 
% However, I agree with your central theme, which is that you can't 
% realistically have fine-grain control over everything, and yet you 
% want to.  I'm all for practical answers to knotty problems.  
% And, for sure, not everyone will be happy.  So long as we have a 
% middle ground, and not one or the other extreme, I'll live with it.
% 
% Once again, I'd really like to get to the actual requirements, in
% requirements language, and stop beating around the bush (no pun
% intended) with vague concepts.
% 
% Brian

I'm leary of a third-party device holding the data (can you say,
"key-escrow?" or WellKnownPointsofFailure?  - sure you can. In anycase,
Ok.  The OOD has what attributes wrt the "geo" component of geopriv?

	lat/log/alt
	vector/velocity
	mass/"size"

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)

When does the OOD  release i(or authorize, in the event of third-party
state-keepers) the data?

	Timeliness
	Relevence
	"granularity"

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.

--bill

---

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

> intended) with vague concepts.

Actually I feel like we are discussing the same things in the spatial BOF
mailing list again and again.
Without new mechanisms/protocols or major modifications to them, I agree
with what Brian said so far (you can not have a new, fancy privacy control
mechanism by end-users).  And what he said is written in the draft
(draft-rosen-geopriv-requirements-00.txt).  Why do not you use the draft and
comment on it as a start point?  I propose to delete the Sections 6, 7, 8
and 10 (they are related to protocols) and add use scenarios/threat
analysis.

Kenji