[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-geopriv-lbyr-requirements

GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Intended status: Informational                              July 9, 2007
Expires: January 10, 2008


  Requirements for a Location-by-Reference  Mechanism used in Location
                      Configuration and Conveyance
              draft-marshall-geopriv-lbyr-requirements-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Marshall                Expires January 10, 2008                [Page 1]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


Abstract

   This document defines terminology and enumerates requirements for a
   Location-by-Reference approach to the configuration, dereferencing,
   and conveyance of location for SIP signaling, and other Internet
   messaging, including for emergency call routing for voice-over-IP
   (VoIP) and general Internet multimedia systems, where Internet
   protocols are used end-to-end.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Terminology . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Terms  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Routing Models . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  LbyR Basic Actors  . . . . . . . . . . . . . . . . . . . . . . 10
   6.  LbyR Actions . . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  LbyR via L7LCP . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  LbyR via DHCP  . . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  LbyR via LLDP-MED  . . . . . . . . . . . . . . . . . . . . . . 17
   10. LbyR via SUPL  . . . . . . . . . . . . . . . . . . . . . . . . 18
   11. High-Level Requirements  . . . . . . . . . . . . . . . . . . . 19
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     16.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29


















Marshall                Expires January 10, 2008                [Page 2]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


1.  Introduction

   Any location-based service which utilizes SIP signaling, needs to
   have some form of location information available, to serve as the
   basis of performing a location-based mapping operation in order to
   know where to route.  To enable any location-based service, whether
   for an end device or middlebox, (e.g., SIP Proxy), location must be
   acquired, either directly or indirectly, location information, either
   in the form of a PIDF-LO or a Location Reference Identifier.

   This document defines the requirements for a Location-by-Reference
   mechanism, its use, and its alternatives.  It contrasts the Location-
   by-Reference routing model to the Location-by-Value model, and
   describes the ways in which a Location-by-Reference mechanism is
   used, such as for requesting a reference, resolving a reference, and
   conveying a reference.

   The document also talks about the two primary network models which
   may use Location-by-Reference, "Edge" routed and "Proxy" routed
   scenarios.

   When describing the use of location within messaging, it is essential
   to discuss the scope of how location is handled within this document.
   We talk about how location is 'acquired', or 'configured' within a
   host, but we do not address the mechanisms involved in
   'determinining' (i.e., the methods or process of coming up with the
   location information).

   The action of passing location from one entity to another entity
   along a SIP signaling path is referred to as "conveyance", and is
   discussed separately from that of configuration.  The commonly used
   example of a SIP-based emergency call may include both elements of
   configuration and conveyance, in order to be able to appropriately
   route and deliver location to an IP-enabled PSAP.

   Location determination, which may include the processes of manual
   provisioning, automated measurements, or derivation steps (e.g., geo-
   coding/reverse geo-coding), is out of scope for this document.

   A detailed description and usage guidelines for Location-by-Value are
   out of scope in this document.

   This document identifies the individual requirements underlying how a
   Location-by-Reference (LbyR) mechanism is to be used over the
   Internet, applied to either a Dereference protocol, Conveyance
   protocol, or a Configuration protocol.

   For an application of LbyR, we often cite the use case of a SIP-based



Marshall                Expires January 10, 2008                [Page 3]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


   signaling to emergency services, though we also talk about LbyR in a
   more general sense.  In this case, a SIP user agent, or SIP proxy
   server acting on behalf of a user agent, to another user agent via
   the SIP protocol [RFC3261].  In place of the actual value for a
   "Location", a Location Reference URI is used to indirectly represent
   the location via a dereference step.  Stored in some Internet-
   connected host, which we call a Location Configuration Server (LCS).

   In the LbyR context, the Configuration protocol mechanism is used to
   fetch a location reference, and in this case, the protocols which
   have been identified for this use, includes DHCP, LLDP-MED, HELD, and
   potentially, SUPL.  Regardless of protocol choices, the underlying
   approach to how LbyR is used for configuration is not specific to any
   particular protocol choice.

   A Location which is referenced can be either Coordinate location [RFC
   3693] (e.g., lat/lon), or a Civic location (e.g., street address).

   We reintroduce a few of the building blocks to location [RFC3693]
   into the LbyR discussion.  Included in this list is the "target", the
   entity whose location is transmitted, (e.g., UA location).  A "using
   protocol", defined as how a "target" (in this model) transmits a
   "location reference identifier" to a "location recipient".  Privacy
   of a target's location, with repect to user identity is important to
   protect.  Therefore, any examples shown will assume that any user
   identity associated with the target is not included with location.

   Location can be pushed from one host to another, via a conveyance
   protocol, as part of a signaling protocol, in order to be used for
   location-based routing (or other purposes, outside the scope here),
   or it can alternatively be queried via a client request to a server
   which provides location [ref. draft-sip-conveyance- XXX].  In the
   case of LbyR Conveyance, the actual location (i.e., location object)
   never gets pushed along, but is replaced by a Location Reference
   Identifier.  In the case of a client which queries a server for
   location, the query is either to obtain a Location Reference
   Identifier, or to obtain an actual Location (e.g., location object)
   based the input of an LRI in the query.

   The draft-sip-conveyance- document [draft-sip-conveyance] details how
   SIP proxies treat LbyR (and LbyV) scenarios for conveying location
   via the SIP protocol.

   Whereas location objects are readily consumable by the hosts that
   using protocols deliver to, a Location Reference ID must first go
   through a dereference step in order to be useful.

   In our SIP example, for LbyR, instead of having a content identifier



Marshall                Expires January 10, 2008                [Page 4]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


   (cid:) pointing to a location object within a SIP body, the LRI is
   carried in the Geolocation header of a SIP message which is used to
   get a location via a dereference step.

   The structure of this document first defines terminology in
   Section 3.  Then a short discussion on actors, Section 5.  Routing
   models, considering both "Edge" and "Proxy" routed models are shown
   by example, Figure 1 and Figure 2, respectively, followed by a more
   specific model which shows a Layer 7 LCP context model.
   [Placeholders for...]  More models are included for comparison,
   including those for LbyR by DHCP, LLDP-MED, and by SUPL.  A high-
   level list of baseline requirements are outlined for the LbyR
   mechanism, (Section 11), and generally apply to configuration,
   dereferencing, and conveyance of location by means of a Location
   Reference Identifier in lieu of the an actual location, as would
   otherwise be included within a PIDF-LO structure.

   Any detailed discussion of Identification information about the
   caller, subscriber, or device, as associated information to location
   or a location reference, for either Conveyance, Dereference, or
   Configuration, is out of scope in this document.






























Marshall                Expires January 10, 2008                [Page 5]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


2.  Requirements Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" in this document are to be interpreted as described in
   RFC 2119 [RFC2119].













































Marshall                Expires January 10, 2008                [Page 6]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


3.  Terminology

3.1.  Terms

   Several of the terms presented below are based on RFC3693, and in
   some cases, extended to include additional language to support the
   Location-by-Reference model.

   Dereference Protocol:  A protocol which is used to query a Location
      Configuration Server based on an LRI as input, and which returns a
      location value (.e.g, PIDF-LO).

   Location Reference Identifier (LRI):  An identifier which serves as a
      pointer to a target's location record on a remote host (e.g.,
      location configuration server), and is used by a dereferencing
      protocol for retrieval of the associated specific location.

   LoST Server:  A network entity which provides a URI response based on
      input of a location and service identifier [ref.
      draft-ecrit-lost-].

   Using Protocol:  A protocol (e.g., SIP) which carries a Location
      Object or an Location Reference Identifier.

   Target:  A person, end device, or other entity whose location is
      communicated by a Geopriv Location Object.

   Location Recipient (LR):  The entity that receives location
      information.  It may have asked for this location explicitly (by
      sending a query containing an LRI to a location configuration
      server), or it may receive this location asynchronously.

   Location Server (LS):  The entity to which a LG publishes location
      objects, is the recipient of queries from location recipients, and
      is the entity that applies rules designed by the Rule Maker (RM)
      [ref.  RFC4119].  Also may be referred to as a Presence Server
      (PS).

   Location Configuration Server (LCS):  The entity which receives a
      client request for either location or a location reference.  In
      the latter case, also performs the dereference function for a
      Location Refernce Identifier, in the context of the Location-by-
      Reference model.  May also be referred to as a Location
      Information Server (LIS).







Marshall                Expires January 10, 2008                [Page 7]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


   Location:  Either a coordinate (geographic) identification assigned
      to a region or feature based on a specific coordinate system, or
      by other identifiable information such as a street number and
      street name within a civic location reference system.

   Civic location:  A described location based on some understood
      location reference system, such a jurisdictions or postal delivery
      grid.  A street address valid within the USPS system is a common
      example.

   Coordinate location:  A reference to a point which is able to be
      located as described by a set of defined coordinates within a
      geographic coordinate system, such as latitude and longitude
      within the WGS-84 datum.  For example, 2-D geographic location is
      defined as an (x,y) coordinate value pair according to the
      distance north or south of the equator and east or west of the
      prime meridian.

   Location-by-Value:  The mechanism of representing location either in
      conveyance protocols or configuration protocols as fully
      specified, (i.e., including the actual location value itself).

   Location-by-Reference:  The mechanism of representing location either
      in conveyance protocols or configuration protocols as an
      identifier which refers to a fully specified location, (i.e.,
      including a pointer to the actual location value itself).

























Marshall                Expires January 10, 2008                [Page 8]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


4.  Routing Models

   This document describes the two primary network models which may use
   Location-by-Reference, these are often referred to as either "Edge"
   routed or "Proxy" routed messaging.

   Since Location-by-Value is an alternative approach which deals with
   acquiring and conveying location information directly, and in the
   general case where LbyV does not include a Location Reference
   Identifier, LbyV is deemed out of scope in this document, except
   where noted, and so the following examples will only deal with LbyR
   scenarios.

   1.  The Edge routed model consists of the end device acquiring a
       location reference identifier, dereferencing the LRI, and
       performing the routing based on the dereferenced location.
       Location information might be generated by the end host itself,
       in which case the end host itself may request a location
       reference identifier, based on its location, from the LCS.

   2.  The Proxy routed approach relies on some kind of middlebox (e.g.,
       Proxy) inserting an LRI into the SIP messaging, and would be
       required for non-location-aware end devices.  In this case,
       location information might be generated by, provisioned into, or
       stored by the LCS, and represented to the end device as a
       location reference identifier, delivered via a location
       configuration protocol (e.g., using DHCP, LLDP-MED, or an L7 LCP.

   The Location Reference Identifier is useful to point to a location
   value or mask the actual location value.  Since possessing the LRI
   alone is insufficient to perform location-based routing, the LRI must
   be de-referenced.  Once the location is de-referenced and returned to
   the location recipient, it can then be used as input to some
   location-based service (e.g., LoST).

















Marshall                Expires January 10, 2008                [Page 9]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


5.  LbyR Basic Actors

      The basic actors shown in an "Edge" routing model.



   +-------------+
   |             |
   |     LCS     +<-----------------+-------------------------+
   |             |                  |                         |
   +--+-------+--+                  |                         |
      ^       ^                     |                         |
      |       |                     |                         |
   Configuration                    |                         |
   Protocol   |                     |                         |
     (a)     (b) Dereference       (b)                       (b)
      |       |   Protocol          |                         |
      |       |                     |                         |
      v       v                     v                         v
   +--+-------+--+ Conveyance +-----+------+            +-----+-----+
   |  Target /   | Protocol   |   Proxy /  |            |   Term./  |
   |  End Host   +----(c)---->+    UAS     +----(c)---->+    UAS    |
   |             |            |            |            |           |
   +-------------+            +------------+            +-----------+

          Figure 1: Shows the basic model shows  Edge routing inter-
       relationship between Configuration, Dereference, and  Conveyance
                                  protocols:

      In the case of Edge routing, the following applies, as shown in
      the above figure, the Target / End Host:

      (a) Acquires an LRI from the LCS

      (b) Dereferences the LRI, receiving the location

      Uses the location to determine routing instructions in the form of
      a destination URI (step not shown)

      (c) Conveys the LRI to the destination URI obtained in the
      previous step

      (b) Additional Dereference steps may be necessary on the way to
      and at the terminating UAS.







Marshall                Expires January 10, 2008               [Page 10]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


      The basic actors shown in an "Proxy" routing model.



   +-------------+
   |             |
   |     LCS     +<-----------------+-------------------------+
   |             |                  |                         |
   +--+-------+--+                  |                         |
      :       ^                     |                         |
      :       |                     |                         |
      :       |                    (b) Dereference           (b)
      :       +--------(a)-------+  |  Protocol               |
     (0)         Configuration   |  |                         |
   Determination     Protocol    |  |                         |
   Mechanism                     |  |                         |
      :                          v  v                         v
   +--+-------+--+            +--+--+------+ Conveyance +-----+-----+
   |  Target /   |            |   Proxy /  | Protocol   |   Term./  |
   |  End Host   +----------->+    UAS     +----(c)---->+    UAS    |
   |             |            |            |            |           |
   +-------------+            +------------+            +-----------+

          Figure 2: Shows the basic model shows  Proxy routed inter-
       relationship between Configuration, Dereference, and  Conveyance
                                  protocols:

      In the case of Proxy routing, this time it's the Proxy, serving
      the Target / End Host, which acts as follows to:

      (a) Acquire an LRI from the LCS

      (b) Dereference the LRI, receiving the location

      Use the location to determine routing instructions in the form of
      a destination URI (step not shown)

      (c) Convey the LRI to the destination URI obtained in the previous
      step












Marshall                Expires January 10, 2008               [Page 11]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


6.  LbyR Actions

   The LbyR mechanism has three distinct actions which describe its use.

   1.  An LRI is 'acquired' via a Configuration protocol request/
       response (which implies its creation and receipt).  This action
       is performed by the entity which needs the location reference to
       resolve it via the dereference step, then send it on to the next
       destination (conveyance).

   2.  An LRI 'resolved', via a Dereferencing protocol request/response.
       This is the action of exchanging the reference for an actual
       location.

   3.  An LRI is 'pushed' via a Conveyance protocol mechanism.  This
       action is accomplished by a using protocol, such as SIP, in which
       case it would be included in a specific SIP header.

   Note: An LRI may also be conveyed alongside a PIDF-LO, (which enables
   the Terminating UAS a convenient mechanism to perform location
   updates).






























Marshall                Expires January 10, 2008               [Page 12]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


7.  LbyR via L7LCP

      Location-by-Reference with Location Subscriptions

      In mobile wireless networks it is not efficient for the end host
      to periodically query the LCS for up-to-date location information.
      Furthermore, the end host might want to delegate the task of
      retrieving and publishing location information to a third party,
      such as a presence server.  Finally, in some deployments the
      network operator might not want to make location information
      available to the end hosts.

      These usage scenarios motivated the introduction of the
      location-by- reference concept.  Depending on the type of
      reference, such as HTTP/ HTTPS or SIP presence URI, different
      operations can be performed.  While an HTTP/HTTPS URI can be
      resolved to location information, a SIP presence URI provides
      further benefits from the SUBSCRIBE/NOTIFY concept that can
      additionally be combined with location filters [13].



              +-----------+ Dereferencing +-----------+
              |           |  Protocol (3) | Location  |
              |    LCS    +---------------+ Recipient |
              |           |               |           |
              +-----+-----+               +----+------+
                    |                        --
                    |                      --
                    | Geopriv-L7         --
                    | Protocol         --
                    | (1)            --
                    |              --      Geopriv
                    |            --        Using Protocol
                    |          --          (e.g., SIP)
              +-----+-----+  --            (2)
              | Target /  |--
              | End Host  +
              |           |
              +-----------+

        Figure 3: Shows the assumed communication model  for a L7 LCP:

      Note that there is no requirement for using the same protocol in
      (1) and (3).






Marshall                Expires January 10, 2008               [Page 13]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


      The following list describes the location subscription idea:

      1.  The end host discovers the LCS.

      2.  The end host sends a request to the LCS asking for a
      location-by- reference, as shown in (1) of Figure 4.

      3.  The LCS responds to the request and includes a location object
      together with a subscription URI.

      4.  The Target puts the subscription URI into a SIP message as
      described in [14] forwards it to a Location Recipient, as shown in
      (2) of Figure 4.  The Location Recipient subscribes to the
      obtained subscription URI (see (3) of Figure 4) and potentially
      uses a location filter (see [13]) to limit the notification rate.

      5.  If the Target moves outside a certain area, indicated by the
      location filter, then the Location Recipient will receive a
      notification.

      Note that the Target may also act in the role of the Location
      Recipient whereby it would subscribe to its own location
      information.  For example, the Target obtains a subscription URI
      from the Geopriv-L7 protocol.  It subscribes to the URI in order
      to obtain its currently location information, which then serves as
      input to a LoST query (see [15]) in order to acquire the service
      boundary (e.g., PSAP boundary).  The service boundary indicates
      the region where the device can move without the need to re-query
      since the returned answer remains unchanged.  The Target uses this
      service boundary to location filters and updates the subscription.
      If the Target moves outside a certain area, indicated by the
      location filter, it will receive a notification and knows that re-
      querying LoST to obtain a new service boundary is necessary.

      For location-by-reference, the LCS needs to maintain a list of
      randomized URIs for each host, timing out these URIs after the
      reference expires.  References need to expire to prevent the
      recipient of such a URL from being able to (in some cases)
      permanently track a host.  Furthermore, this mechanism also offers
      garbage collection capability for the LIS.

      Location references must prevent adversaries from obtaining the
      Target's location.  There are at least two approaches: The
      location reference contains a random component and allows any
      holder of the reference to obtain location information.
      Alternatively, the reference can be public and the LIS performs
      access control via a separate authentication mechanism, such as
      HTTP digest or TLS client side authentication, when resolving the



Marshall                Expires January 10, 2008               [Page 14]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


      reference to a location object.


















































Marshall                Expires January 10, 2008               [Page 15]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


8.  LbyR via DHCP

   [Place text here.]
















































Marshall                Expires January 10, 2008               [Page 16]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


9.  LbyR via LLDP-MED

   [Place text here.]
















































Marshall                Expires January 10, 2008               [Page 17]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


10.  LbyR via SUPL

   [Place text here.]
















































Marshall                Expires January 10, 2008               [Page 18]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


11.  High-Level Requirements

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism.

   Rq1.  Location Reference Identifier as a URI:  The dereferencing
      protocol MUST support an LRI in URI form, and may support other
      non-URI forms.

   Rq2.  Dereference Protocol Confidentiality:  The dereferencing
      protocol MUST support mechanisms for encrypting messages sent
      between client (Location recipient) and server (Location
      Configuration Server).

   Rq3.  Dereference Protocol Transparancy:  The dereferencing protocol
      MUST support the exchange of messages without encryption (i.e., in
      plaintext).

      Motivation: In the case where encrypted message exchange is
      unsuccessful, there must be a way to try to dereference a location
      reference identifier with less restriction (e..g., in the
      emergency service case, where every call always needs answered).

   Rq4.  Location Reference Expiration:  The Location Reference
      mechanism MUST provide a way to limit the validity of that
      reference (and SHOULD also provide a way to extend or shorten the
      validity period).

      Motivation: Location references are not intended to represent a
      location forever, and the identifier eventually may need to be
      recycled, or may be subject to a specific window of validity,
      after which the location reference fails to yield a location, or
      the location is determined to be kept confidential.  An expiry
      timer for a location reference ensures that the location reference
      becomes invalid based on configuration.

   Rq5.  Dereference Protocol Transport:  The dereference protocol MUST
      support TCP/IP and MAY support UDP/IP.

      Motivation: Practical, near-term deployment issues may make TCP/IP
      implementations unachievable.

   Rq6''.  Dereference Protocol Authentication:  The The Location
      dereferencing protocol MUST support both client-side and server-
      side authentication between server and client.






Marshall                Expires January 10, 2008               [Page 19]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


      Motivation: It is reasonable to expect implementations of
      authentication to vary.  Some implementations may choose to
      support both client-side and server-side authentication, might
      support one only, or may support neither.

   Rq7.  Location Privacy:  The Location Reference MUST NOT reveal any
      personal identification information along with a requested
      location object.

   Rq8.  Dereferenced PIDF-LO Result:  The dereferencing of an LRI MUST
      result in a well-formed PIDF-LO.

      Motivation: This is in order to ensure adequate privacy rules can
      be adhered to, since the PIDF-LO format comprises the necessary
      structures to maintain location privacy.

   Rq9.  Time Limitation:  The reference MUST be valid for a limited
      amount of time.

      Motivation:

   Rq10. :  The reference MUST be hard to guess, i.e., it MUST contain a
      cryptographically random component.

      Motivation:

   Rq11. :  The reference MUST NOT contain any information that
      identifies the user, device or address of record.

      Motivation:

   Rq12. :  The Location Recipient MUST be able to resolve the reference
      more than once (i.e., there is no implicit limit on the number of
      dereferencing actions).

      Motivation:

   Rq13. :  Possessing a reference to location information allows a
      Location Recipient to repeately obtain the latest information
      about the Target with the same granularity.

      Motivation:

   Rq14. :  The Target MUST be able to resolve the reference itself.







Marshall                Expires January 10, 2008               [Page 20]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


      Motivation:


















































Marshall                Expires January 10, 2008               [Page 21]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


12.  Security Considerations

   The LbyR mechanism currently addresses security issues as follows.

   1.  A pawn ticket where possession implies permission, and

   2.  Identifiers that are public which are protected by privacy rules
       at the dereference server.

   3.  Additional security issues will be discussed in a separate
       geopriv document (based on a prior version of the l7-lcp-ps
       draft).







































Marshall                Expires January 10, 2008               [Page 22]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


13.  IANA Considerations

   This document does not require actions by the IANA.
















































Marshall                Expires January 10, 2008               [Page 23]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


14.  Contributors

   Andrew Newton; Martin Dawson; Henning Schulzrinne; Marc Linsner;
   Brian Rosen; Ted Hardie; James M. Polk; James Winterbottom; Martin
   Thomson; John Schnizlein; Barbara Stark; Jon Peterson; Allison
   Mankin; Randall Gellens; Cullen Jennings; Richard Barnes; Keith
   Drage; Rohan Mahy; Hannes Tschofenig

   The contributors can be reached at:

   Name          user@example.com








































Marshall                Expires January 10, 2008               [Page 24]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


15.  Acknowledgments

   [TBD]
















































Marshall                Expires January 10, 2008               [Page 25]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

16.2.  Informative References

   [I-D.ietf-ecrit-lost]
              Hardie, T., "LoST: A Location-to-Service Translation
              Protocol", draft-ietf-ecrit-lost-05 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-requirements]
              Schulzrinne, H. and R. Marshall, "Requirements for
              Emergency Context Resolution with Internet Technologies",
              draft-ietf-ecrit-requirements-13 (work in progress),
              March 2007.

   [I-D.ietf-ecrit-security-threats]
              Taylor, T., "Security Threats and Requirements for
              Emergency Call Marking and Mapping",
              draft-ietf-ecrit-security-threats-04 (work in progress),
              April 2007.

   [I-D.ietf-geopriv-dhcp-civil]
              Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic  Addresses
              Configuration Information",
              draft-ietf-geopriv-dhcp-civil-09 (work in progress),
              January 2006.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-02 (work in
              progress), April 2007.

   [I-D.ietf-geopriv-loc-filters]
              Mahy, R., "A Document Format for Filtering and Reporting
              Location Notications in the  Presence Information Document
              Format Location Object (PIDF-LO)",
              draft-ietf-geopriv-loc-filters-01 (work in progress),
              March 2007.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.



Marshall                Expires January 10, 2008               [Page 26]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.










































Marshall                Expires January 10, 2008               [Page 27]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


Author's Address

   Roger Marshall (editor)
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   Phone: +1 206 792 2424
   Email: rmarshall@telecomsys.com
   URI:   http://www.telecomsys.com







































Marshall                Expires January 10, 2008               [Page 28]

Internet-Draft          GEOPRIV LbyR Requirements              July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Marshall                Expires January 10, 2008               [Page 29]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/