RE: Notes from Non-meeting

It would probably be very helpful to start talking about
"attributes sufficient for policy to be applied" and
"some very broad way the purpose of the request"

I understand in a human communication sense what this
means. I don't know what it means in the protocol
design sense.

Perhaps some examples would be useful.

What I don't understand is how to design a language
for expressing this that has sufficient scope for
all use cases, and yet is implementable anytime soon.
All my experience in such language design is that
it's an np hard problem.

I can have a field with a value, one of whose values
is "emergency call" which would give you in some very broad
way the purpose of the request" but, in general, I
don't think you can do that.

Similarly, it seems hard to me to describe the form,
let alone the range of values for "attributes sufficient
for policy to be applied". When I think of all the
uses we have, trying to define a useful set of
attributes makes my head hurt. I can try to do something
like "choose one: wife, boss, co-worker, acquaintance,
stranger, INS agent". I certainly could define a protocol
element to encode it, an IANA registry to create new
classes, ... but I really don't know how to build a system
to get the right value (ie classify the requestor).

Has anyone built such a protocol with anything like this
kind of problem space?

Where is the basis for thinking we can do this hear and now?

Brian

> -----Original Message-----
> From: Randall Gellens [mailto:rg+ietf@qualcomm.com]
> Sent: Thursday, March 21, 2002 11:10 AM
> To: John Morris; Rosen, Brian; geopriv@mail.apps.ietf.org
> Subject: Re: Notes from Non-meeting
>
>
> At 12:04 PM -0500 3/20/02, John Morris wrote:
>
> > The two threshold outputs would be:
> >
> > 1) The structure and elements of a "geopriv object" -- which is
> > different than the mere "format of location information." The
> > object would at a minimum contain a bare bones privacy
> > instruction/rule, and might also contain location information
> > (although we will need to address situations in which the privacy
> > rule and the location information originate in separate places).
>
> I admit to not being an expert in this area, but I was thinking that
> the geopriv object would contain on request a set of attributes
> sufficient for policy to be applied, and on response the location
> itself, with attributes describing its state, but not any description
> of the policy itself. For example, a location requester could fill
> in an object with some attributes saying who it is and how much
> accuracy it requires, and perhaps in some very broad way the purpose
> of the request. An entity which was aware of the location and the
> policy could then apply it, deciding to disclose the location or not,
> and if so to what accuracy, etc.
>
> > 2) A statement of rules that MUST be followed in any
> > implementation that uses the geopriv object
>
> This security requirements document can be used for enforcement, to
> argue that protocol x's use of geopriv does or does not comply, and
> therefore should or should not be standardized within the IETF.
>
Received on Thu Mar 21 15:55:44 2002