Re: general question

From: Bill Manning ^lt;bmanning@ISI.EDU>
Date: Mon Sep 10 2001 - 17:19:34 EDT

%
% 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
Received on Mon Sep 10 17:18:48 2001

This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:22 EST