RE: general question

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:bmanning@ISI.EDU]
> Sent: Monday, September 10, 2001 11:39 AM
> To: Brian.Rosen@marconi.com
> Cc: ritadefla@libero.it; geopriv@mail.apps.ietf.org
> 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
>
Received on Mon Sep 10 16:55:58 2001