Re: Terminology

From: John W Noerenberg II ^lt;jwn2@qualcomm.com>
Date: Wed Dec 12 2001 - 16:17:31 EST

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
   ----------------------------------------------------------------------
Received on Wed Dec 12 16:18:50 2001

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