RE: Terminology

I'm going to have to respond properly to this proposal some time when I can
spend
a while extracting the ideas from it. It's pretty dense, and has a lot of
new
terminology.
 
One of the key things I think you should do is to eliminate the word
"mobile".
There should be no reference to anything mobile in this work except for
scenarios. It has to work in a mobile system, but it also has to work as
well
in a fixed system. It has to work in an enterprise, in a hospital and in a
home
as well as in a carrier network.
 
Brian

-----Original Message-----
From: John W Noerenberg II [mailto:jwn2@qualcomm.com]
Sent: Wednesday, December 12, 2001 4:18 PM
To: Rosen, Brian
Cc: geopriv@mail.apps.ietf.org
Subject: Re: Terminology

At 12:43 PM -0500 12/11/01, Brian Rosen wrote:

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.

Below is a model I've been using to think about the threats to the
information integrity of location data. What follows is a part of a
yet-to-be-published I-D which includes my threat analysis. The reason for
publishing the model here is there are significant similarities to what
Brian has outlined. I also define other terms which you may or may not find
useful.

                                                           /-------\
                                                         // \\
                                                        | MPC |
                                                        | |
                     /-------\ \\ //
                   // location\\ /\-------/
                  | proxy | /
                  | | /
                   \\ LocSrv // +----------+ /
    /----\ \---+---/ | Mobile | /
  / App \ | | station | / //-----\\
 | | | | | / |/ \|
 | LocReq |---------------------| LocSrv +-----/-----+ PDE |
  \ / | | |\ /|
    \----/ +----+-----+ \\-----//
                                       |
                                   +---+----+
                                   |Local |
                                   |node |
                                   | |
                                   +--------+

To the left of the Mobile Station and Local node is the public Internet, to
the right is a private network used for position calculation. By "public
Internet" I mean principally the relationship between an application service
provider (App) which is a Location Requestor (LocReq) and the Mobile Station
(MS). The Mobile station is a Location Server (LocSrv). A local processor
(such as a laptop or pda) may be associated with the MS, and may also be a
LocReq. The location proxy is also a LocSrv. With appropriate permission
from the MS, it may provide the MS location to a LocReq.

The private network consists of a Mobile Positioning Center (MPC), a
Position Determination Engine (PDE), and the MS. Resident on the MPC is a
process called a Policy Generator that maintains position attributes
contained in a Policy Vector (PV) for the MS. The MPC is also responsible
for authorizing connections between an arbitrary MS and an arbitrary
Position Determination Engine (PDE). The MS and the PDE cooperate to fix MS
location. The location fix is incorporated into the Policy Vector. The
complete PV is maintained in the MS and may also be maintained in the
location proxy. The complete PV encapsulates rule parameters used to
specify the conditions for releasing location data.

Resident on the MS and the location proxy is a Policy Engine. An App sends
a Location Request Message (LocRM) to a LocSrv. The LocRM includes a PV
to indicate what location information it requires. The Policy Engine
compares the LocRM(PV) to its PV and forms a Location Request Response
(LocRR). The LocRR includes the position data appropriate to the
"intersection" of the LocRM(PV) and PV. The intersection operator is a
comparison function. Its details need not be defined for the model's
analysis.

I see there are other notes in this thread. I hope this proposal is not
orthogonal to the rest of the discussion - I've been trying to finish the
minutes. But having seen Brian's note, I felt it would be worthwhile to
offer my model to the WG.

best,

-- 
john noerenberg
jwn2@qualcomm.com
  ----------------------------------------------------------------------
  While the belief we  have found the Answer can separate us
  and make us forget our humanity, it is the seeking that continues
  to bring us together, the makes and keeps us human.
  -- Daniel J. Boorstin, "The Seekers", 1998
  ----------------------------------------------------------------------