Terminology

From: Rosen, Brian ^lt;Brian.Rosen@marconi.com>
Date: Tue Dec 11 2001 - 12:43:12 EST

I'd like to start a discussion of terminology.

I think we all agree on the term "target"; it's the device
that has a location.

We usually use the term "user", in two contexts. One is that
the target is usually described as associated with the user.
We really want the location of the user, but until we get
implanted with GPS receivers and radios, we have targets
that are separate from the user. The other context we
use "user" is that the user is the source of the privacy
concern. Ultimately, it is the user that grants rights to
some other entity to learn the location of the target.

From there, we tend to fall apart on generally accepted
terminology. I'd like to propose that we use the policy
terms like 'Policy Determination Point' and 'Policy
Enforcement Point' which have accepted meanings when we
discuss the application of the users policy on the
location dissemination. Is that acceptable?

Finally, I'd like to take a stab at convincing you that
there are only two other entities (nouns) in this process.
I think many have in mind that there are several other entities,
but in my mind, there are only two.

A Server is an entity that knows the location of a target.
A Client is an entity that wants to find out the location
of a target.

See, wasn't that easy?

Now, let's look at scenarios. Please remember that these
are logical functions, and a physical device can have
multiple functions implemented in it.

First is the simple case of the target actually knowing
its own location (using, say, GPS), and it having enough
horsepower to be a PDP/PEP. Then the target has the Server
and the PDP/PEP collocated in it. A client gets authenticated
by the server. The server consults its PDP to determine
if location should be given to the client, applies the
appropriate policy (PEP) and then sends the result to the
client.

Next, let's assume that the target knows it's own location,
but does not have enough horsepower to do all the policy
application. In such a case, we employ a Proxy Server.
This is a back to back Client and Server. So, the target
has a server that has exactly one client, the client side of
the Proxy Server. The proxy server has the PDP/PEP and other
clients authorized by the user's policy get location information
from the server side of the Proxy Server.

Now lets assume that the target doesn't know its location,
but some other entity does. That entity is just a Server;
it knows the location of a target, and provides it to clients.
That server could have the PDP/PEP, or it could use a Proxy
Server as above.

Now take a translator. It is another instance of a Proxy
Server that transforms the data between the client side
and the server side. It, of course, could have the PDP,
or just the PEP, or it could be, as above, serving only
one client, which is another Proxy Server that has the PEP.

Of course, in single client servers, PDP and PEP are implemented,
they are just very simple. So, in reality, every server
has at least a PEP.

Now we can get arbitrarily complex. Suppose there was a system
where there were a bunch of targets all served by a "carrier"
(we don't really care what the thing that serves all these client
is, it could be an enterprise device), where the server could
provide a reasonable set of policies and enforce them. A user
created a policy for that server that applied to a range of
clients. However, suppose that the server is not all that clever,
and some enterprising dotcom offers a service to the user that
provides a more rich policy mechanism than the "carrier" does.
So, the user authorizes the carrier server to supply location
to the dotcom, which is another proxy server. The user then
authorizes another set of clients to the dotcom server.

Either or both of the "carrier" server and the dotcom server
could provide translation or obfuscation services.

I think that is all we need for nouns.

Brian
Received on Tue Dec 11 12:45:00 2001

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