GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Intended status: Informational                         September 2, 2009
Expires: March 6, 2010

           Requirements for a Location-by-Reference Mechanism

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 6, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Marshall                  Expires March 6, 2010                 [Page 1]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Marshall                  Expires March 6, 2010                 [Page 2]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009


   This document defines terminology and provides requirements relating
   to Location-by-Reference approach using a location Uniform Resource
   Identifier (URI) to handle location information within signaling and
   other Internet messaging.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Overview of Location-by-Reference  . . . . . . . . . . . . . .  8
     3.1.  Location URI Usage . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Location URI Expiration  . . . . . . . . . . . . . . . . .  9
     3.3.  Location URI Authorization . . . . . . . . . . . . . . . . 10
     3.4.  Location URI Construction  . . . . . . . . . . . . . . . . 10
   4.  High-Level Requirements  . . . . . . . . . . . . . . . . . . . 12
     4.1.  Requirements for a Location Configuration Protocol . . . . 12
     4.2.  Requirements for a Location Dereference Protocol . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24

Marshall                  Expires March 6, 2010                 [Page 3]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

1.  Introduction

   All location-based services rely on ready access to location
   information.  Using location information can be done one of two ways,
   either in a direct, Location-by-Value (LbyV) approach, or using an
   indirect, Location-by-Reference (LbyR) model.

   For LbyV, location information is conveyed directly in the form of a
   Presence Information Data Format-Location Object (PIDF-LO)
   ([RFC4119]).  Using LbyV might either be infeasible or undesirable in
   some circumstances.  There are cases where LbyR is better able to
   address location requirements for a specific architecture or
   application.  This document provides a list of requirements for use
   with the LbyR approach, and leaves the LbyV model explicitly out of

   As justification for a LbyR model, consider the circumstance that in
   some mobile networks it is not efficient for the end host to
   periodically query the Location Information Server (LIS) for up-to-
   date location information.  This is especially the case when ower
   availability is a constraint or when a location update is not
   immediately needed.  Furthermore, the end host might want to delegate
   the task of retrieving and publishing location information to a third
   party, such as to a presence server.  Additionally, in some
   deployments, the network operator may not want to make location
   information widely available.  These kinds of location scenarios form
   the basis of motivation for the LbyR model.

   The concept of an LbyR mechanism is simple.  An LbyR is made up of a
   URI scheme, a domain and a randomized component.  This combination of
   data elements, in the form of a URI, is referred to specifically as a
   "location URI".

   A location URI is thought of as a reference to the current location
   of the Target, yet the location value might remain unchanged over
   specific intervals of time for several reasons.  The type of location
   information returned as part of the dereferencing step may, for
   example, be influenced by the following factors:

   - Limitations in the process used to generate location information
   mean that cached location might be used.

   - Policy constraints that may dictate that the location provided
   remains fixed over time for specified Location Recipients.  Without
   additional information, a Location Recipient cannot assume that the
   location information provided by any location URI is static, and will
   never change.

Marshall                  Expires March 6, 2010                 [Page 4]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   The LbyR mechanism works according to an information lifecycle.
   Within this lifecycle, location URIs are considered temporary
   identifiers, each undergoing the following uses: Creation;
   Distribution; Conveyance; Dereference; and Termination.  The use of a
   location URI according to these various states is generally applied
   in one of the following ways:

   1.  Creation of a location URI, within a location server, based on
   some request for its creation.

   2.  Distribution of a location URI, via a Location Configuration
   Protocol, between a Target and a location server.

   3.  Conveyance, applied to LbyR, for example in SIP (Session
   Inititiation Protocol), is the transporting of the location URI, in
   this case,  between any successive signaling nodes.

   4.  Dereference of a location URI, a request/response between a
   client having a location URI and a location server holding the
   location  information that the location URI references.

   5.  Termination of a location URI, either due to expiration or
   cancellation within a location server, and which is based on a Target
   cancellation  request or some other action, such as timer

   Note that this document makes no differentiation between a Location
   Server (LS), per [RFC3693], and a Location Information Server (LIS),
   as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may refer to either of
   them as a location server interchangeably.

   Location determination, different than location configuration or
   dereferencing, often includes topics related to manual provisioning
   processes, automated location calculations based on a variety of
   measurement techniques, and/or location transformations, (e.g., geo-
   coding), and is beyond the scope of this document.

   Location Conveyance for either LbyR or LbyV, as defined within SIP
   signaling is considered out of scope for this document (see
   [I-D.ietf-sip-location-conveyance] for an explanation of location
   conveyance for either LbyR or LbyV scenarios.)

   Except for location conveyance, the above stages in the LbyR
   lifecycle fall into one of two general categories of protocols,
   either a Location Configuration Protocol or a Location Dereference
   Protocol.  The stages of LbyR Creation, Distribution, and
   Termination, are each found within the set of Location Configuration
   Protocols (LCP).  The Dereference stage belongs solely to the set of

Marshall                  Expires March 6, 2010                 [Page 5]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   Location Dereference Protocols.

   The issues around location configuration protocols have been
   documented in a location configuration protocol problem statement and
   requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
   currently several examples of documented location configuration
   protocols, namely DHCP DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option],
   [I-D.ietf-geopriv-http-location-delivery] protocols.

   For dereferencing of a location URI, depending on the type of
   reference used, such as a 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 [I-D.ietf-geopriv-loc-filters].

   The structure of this document includes terminology, Section 2,
   followed by a discussion of the basic elements that surround how a
   location URI is used.  These elements, or actors, are discussed in an
   overview section, Section 3, accompanied by a graph, associated
   processing steps, and a brief discussion around the use, expiration,
   authorization, and construction of location URIs.

   Requirements are outlined accordingly, separated as location
   configuration requirements, Section 4.1, and location dereference
   requirements, Section 4.2.

Marshall                  Expires March 6, 2010                 [Page 6]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119],
   with the important qualification that, unless otherwise stated, these
   terms apply to the design of the Location Configuration Protocol and
   the Location Dereferencing Protocol, not its implementation or

   This document reuses the terminology of [RFC3693], such as Location
   Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
   Location Object (LO).  Furthermore, the following terms are defined
   in this document:

   Location-by-Value (LbyV):  Using location information in the form of
      a location object (LO), such as a PIDF-LO.

   Location-by-Reference (LbyR):  Representing location information
      indirectly using a location URI.

   Location Configuration Protocol:  A protocol that is used by a Target
      to acquire either location or a location URI from a location
      configuration server, based on information unique to the Target.

   Location Dereference Protocol:  A protocol that is used by a client
      to query a location server, based on the location URI input and
      which returns location information.

   Location URI:  As defined within this document, an identifier that
      serves as a reference to location information.  A location URI is
      provided by a location server, and is later used as input by a
      dereference protocol to retrieve location information.

Marshall                  Expires March 6, 2010                 [Page 7]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

3.  Overview of Location-by-Reference

   This section describes the entities and interactions involved in the
   LbyR model.

            +---------+---------+   Location    +-----------+
            |         |         |  Dereference  | Location  |
            |   LIS   -    LS   +---------------+ Recipient |
            |         |         |   Protocol    |           |
            +----+----+----+----+      (3)      +-----+-----+
                 |           *                        |
                 |      Policy *                      |
        Location |      Exchange *                    |
   Configuration |        (*)      *                  | Location
        Protocol |              +----+----+           | Conveyance
           (1)   |              |  Rule   |           | Protocol
                 |              |  Maker  |           |    (2)
            +----+----+         +---------+           |
            |         |                               |
            | Target  +-------------------------------+
            |         |

          Figure 1: Location Reference Entities and Interactions

   Figure 1 shows the assumed communication model for both a layer 7
   location configuration protocol and a location dereference protocol.

   1.  The Target (an end device) uses a Location Configuration Protocol
   to acquire a location reference from a LIS, which acts as (or is able
   to access) an LS.

   In the case where the Target is also a Rule Maker, the location
   configuration protocol can be used to convey policy information.  In
   the case where possession of a location URI is the only required form
   of authorization, see Section 3.3, a policy is implied whereby any
   requester is granted access to location information.  This does not
   preclude other means of providing authorization policies.

   A Target could also acquire a location URI from the LS directly using
   alternative means, for example, the acquisition of a presence AoR to
   be used for location information, in which case, it could be regarded
   as a location URI.

Marshall                  Expires March 6, 2010                 [Page 8]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   2.  The Target conveys the location URI to the Location Recipient
   (interface out of scope).

   3.  The Location Recipient dereferences the location URI to acquire
   location information from the LS.

   The LS controls access to location information based on the policy
   provided by the Rule Maker.

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

   Note B. Figure 1 includes the interaction between the owner of the
   Target and the LIS to obtain Rule Maker policies.  This interaction
   needs to happen before the LIS will authorize anything other than
   what is allowed based on default policies in order to dereference a
   location request of the Target.  This communication path is out of
   scope for this document.

   Note C. The Target might take on the role of the Location Recipient,
   in which case it could attempt to dereference the location URI
   itself, in order to obtain its own location information.

3.1.  Location URI Usage

   An example scenario of how the above location configuration and
   location dereference steps might work using SIP, is where a Target
   obtains a location URI in the form of a subscription URI (e.g., a SIP
   URI) via a location configuration protocol.  In this case, the Target
   is the same as the Recipient, therefore the Target can subscribe to
   the URI in order to be notified of its current location based on
   subscription parameters.  In the example, parameters are set up for a
   specific Target/Recipient along with an expressed geospatial
   boundary, so that the Target/Recipient receives an updated location
   notification once the boundary is crossed (see

3.2.  Location URI Expiration

   Location URIs may have an expiry associated with them, primarily for
   security considerations, and generally so that the LIS is able to
   keep track of the location URIs that have been handed out, to know
   whether a location URI is still valid once the LIS receives it in a
   request, and in order for a recipient of such a URI from being able
   to (in some cases) permanently track a host.  Expiration of a
   location URI limits the time that accidental leaking of a location
   URI introduces.  Other justifications for expiration of location URIs
   include the ability for a LIS to do garbage collection.

Marshall                  Expires March 6, 2010                 [Page 9]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

3.3.  Location URI Authorization

   How a location URI will ultimately be used within the dereference
   step is an important consideration at the time the location URI is
   requested via a location configuration protocol.  The process of
   dereferencing location URIs will be influenced by the specific
   authorization model applied by the Location Information Server and
   the URI scheme that indicates the protocol to be used to resolve the
   reference to a location object.

   Location URIs manifest themselves in a few different forms.  The
   different ways that a location URI can be represented is based on
   local policy, and are depicted in the following four scenarios.

   1. No specific information at all:  As is typical, a location URI is
      used to get location information.  However, in this case, the URI
      representation itself does not need to reveal any specific
      information at all.  Location information is acquired by the
      dereferencing operation a location URI.

   2. No Target specific information:  By default, a location URI MUST
      NOT reveal any information about the Target other than location
      information.  This is true for the URI itself, (or in the document
      acquired by dereferencing), unless policy explicitly permits

   3. Access control authorization model:  If the "access control
      authorization model" is used, the location URI MUST NOT include
      any location information in its representation.  Location URIs
      operating under this model could be widely published to recipients
      that are not authorized to receive this information.

   4. Possession authorization model (the URI itself is a secret):  If
      the "possession authorization" model is used, the location URI is
      confidential information shared between the LIS/LS, the Target and
      all authorized Location Recipients.  In this case, possession
      implies authorization.  Because knowledge of the location URI is
      used to authenticate and authorize access to location information,
      the URI needs to include sufficient randomness to make guessing
      its value difficult.  A possession model URI can include location
      information in its representation.

3.4.  Location URI Construction

   Depending on local policy, a location URI may be constructed in such
   a way as to make it difficult to guess.  Accordingly, the form of the
   URI is then constrained by the degree of randomness and uniqueness
   applied to it.  In this case, it may be important to protect the

Marshall                  Expires March 6, 2010                [Page 10]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   actual location information from inspection by an intermediate node.
   Construction of a location URI in such a way as to not reveal any
   Target specific, (e.g., user or device), information, with the goal
   of making the location URI appear bland, uninteresting, and generic,
   may be helpful to some degree in order to keep location information
   more difficult to detect.  Thus, obfuscating the location URI in this
   way may provide some level of safeguard against the undetected
   stripping off of what would otherwise be evident location
   information, since it forces a dereference operation at the location
   dereference server, an important step for the purpose of providing
   statistics, audit trails, and general logging for many different
   kinds of location based services.

Marshall                  Expires March 6, 2010                [Page 11]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

4.  High-Level Requirements

   This document outlines the requirements for an Location by Reference
   mechanism which can be used by a number of underlying protocols.
   Requirements here address two general types of such protocols, a
   general location configuration protocol, and a general location
   dereferencing protocol.

   The requirements are broken into two sections.

4.1.  Requirements for a Location Configuration Protocol

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism as used within the location
   configuration protocol.

   C1. Location URI support:  The location configuration protocol MUST
      support a location reference in URI form.

      Motivation: A standardized location reference mechanism increases

   C2. Location URI expiration:  When a location URI has a limited
      validity interval, its lifetime MUST be indicated.

      Motivation: A location URI may not intend 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.

   C3. Location URI cancellation:  The location configuration protocol
      MUST support the ability to request a cancellation of a specific
      location URI.

      Motivation: If the Target determines that in its best interest to
      destroy the ability for a location URI to effectively be used to
      dereference a location, then there should be a way to nullify the
      location URI.

   C4. Location Information Masking:  The location URI MUST, through
      randomization and uniqueness, ensure that the location URI does
      not contain location information specific components.

      Motivation: It is important to keep any location information
      masked from a casual observing node.

Marshall                  Expires March 6, 2010                [Page 12]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   C5. Target Identity Protection:  The location URI MUST NOT contain
      information that identifies the Target (e.g., user or device).
      Examples include phone extensions, badge numbers, first or last

      Motivation: It is important to protect caller identity or contact
      address from being included in the form of the location URI itself
      when it is generated.

   C6. Reuse indicator:  There SHOULD be a way to allow a Target to
      control whether a location URI can be resolved once only, or
      multiple times.

      Motivation: The Target requesting a location URI may request a
      location URI which has a 'one-time-use' only characteristic, as
      opposed to a location URI having multiple reuse capability.  This
      would allow the server to return an error with or without location
      during the subsequent dereference operation.

   C7. Selective disclosure:  The location configuration protocol MUST
      provide a mechanism to control what information is being disclosed
      about the Target.

      Motivation: The Rule Maker has to be in control of how much
      information is revealed during the dereferencing step as part of
      the privacy features.

   C8. Location URI Not guessable:  As a default, the location
      configuration protocol MUST return location URIs that are random
      and unique throughout the indicated lifetime.  A location URI with
      128-bits of randomness is RECOMMENDED.

      Motivation: Location URIs should be constructed in such a way that
      an adversary cannot guess them and dereference them without having
      ever obtained them from the Target.

   C9. Location URI Options:  In the case of user-provided authorization
      policies, where anonymous or non-guessable location URIs are not
      warranted, the location configuration protocol MAY support a
      variety of optional location URI conventions, as requested by a
      Target to a location configuration server, (e.g., embedded
      location information within the location URI).

      Motivation: Users don't always have such strict privacy
      requirements, but may opt to specify their own location URI, or
      components to be included within a location URI.

Marshall                  Expires March 6, 2010                [Page 13]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

4.2.  Requirements for a Location Dereference Protocol

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism as used within the location
   dereference protocol.

   D1. Location URI support:  The location dereference protocol MUST
      support a location reference in URI form.

      Motivation: It is required that there be consistency of use
      between location URI formats used in an configuration protocol and
      those used by a dereference protocol.

   D2. Authentication:  The location dereference protocol MUST include
      mechanisms to authenticate both the client and the server.

      Motivation: Although the implementations must support
      authentication of both parties, any given transaction has the
      option not to authenticate one or both parties.

   D3.  Dereferenced Location Form:  The value returned by the
      dereference protocol MUST contain a well-formed PIDF-LO document.

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

   D4. Location URI Repeated Use:  The location dereference protocol
      MUST support the ability for the same location URI to be resolved
      more than once, based on dereference server configuration.

      Motivation: Through dereference server configuration, for example,
      it may be useful to not only allow more than one dereference
      request, but, in some cases, to also limit the number of
      dereferencing attempts by a client.

   D5. Location Confidentiality:  The location dereference protocol MUST
      support confidentiality protection of messages sent between the
      Location Recipient and the location server.

      Motivation: The location URI indicates what type of security
      protocol has to be provided.  An example is a location URI using a
      HTTPS URI scheme.

Marshall                  Expires March 6, 2010                [Page 14]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

5.  Security Considerations

   The method of constructing the location URI to include randomized
   components helps to prevent adversaries from obtaining location
   information without ever retrieving a location URI.  In the
   possession model, a location URI, regardless of its construction, if
   made publically available, implies no safeguard against anyone being
   able to dereference and get the location.  Care has to be paid when
   distribution such a location URI to the trusted location recipients.
   When this aspect is of concern then the authorization model has to be
   chosen.  Even in this model care has to be taken on how to construct
   the authorization policies to ensure that only those parties have
   access to location information that are considered trustworthy enough
   to enforce the basic rule set that is attached to location
   information in a PIDF-LO document.

   Any location URI, by necessity, indicates the server (name) that
   hosts the location information.  Knowledge of the server in some
   specific domain could therefore reveal something about the location
   of the Target.  This kind of threat may be mitigated somewhat by
   introducing another layer of indirection: namely the use of a
   (remote) presence server.

   A covert channel for protocol message exchange is an important
   consideration, given an example scenario where user A subscribes to
   location information for user B, then every time A gets a location
   update an (external) observer of the subscription notification may
   know that B has moved.  One mitigation to this is to have periodic
   notification, so that user B may appear to have moved, even when

Marshall                  Expires March 6, 2010                [Page 15]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

6.  IANA Considerations

   This document does not require actions by the IANA.

Marshall                  Expires March 6, 2010                [Page 16]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

7.  Acknowledgements

   I would like to thank the present IETF GEOPRIV working group chairs,
   Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy
   Newton, Allison Mankin and Randall Gellens, who established a design
   team that initiated this requirements work.  I'd also like to thank
   those original design team participants for their inputs, comments,
   and insightful reviews.  The design team included the following
   folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens;
   Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison
   Mankinl; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
   John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
   Tschofenig; Martin Thomson; and James Winterbottom.

Marshall                  Expires March 6, 2010                [Page 17]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

8.  References

8.1.  Normative References

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

8.2.  Informative References

              Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
              and IPv6 Option for a  Location Uniform Resource
              Identifier (URI)",
              draft-ietf-geopriv-dhcp-lbyr-uri-option-05 (work in
              progress), July 2009.

              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-16 (work in
              progress), August 2009.

              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in
              progress), July 2009.

              Mahy, R., Rosen, B., and H. Tschofenig, "A Document Format
              for Filtering and Reporting Location Notications in the
              Presence Information Document Format Location Object
              (PIDF-LO)", draft-ietf-geopriv-loc-filters-05 (work in
              progress), July 2009.

              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-13 (work in progress),
              March 2009.

              TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
              Endpoint Discovery".

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

Marshall                  Expires March 6, 2010                [Page 18]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

Marshall                  Expires March 6, 2010                [Page 19]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

Appendix A.  Change log

   Changes to this draft in comparison to the previous version (-08 vs.
   -07), as part of the IESG review process:

   1. changes sent 09/02/2009 based on IESG Security comments from
   Hilarie Orman, 06/08/2009.

   2. changes sent 09/02/2009 based on Operational Directorate comments
   from Hannes Tschofenig, 06/11/2009.

   Changes to this draft in comparison to the previous version (-07 vs.

   1. deleted text and reference to ID.ietf-geopriv-policy (Thomson

   2. replaced text in Introduction referring to SIP (Thomson).

   3. reworded section 3.4 on location URI authorization (Thomson).

   Changes to this draft in comparison to the previous version (-06 vs.

   1. replaced diagram (Thomson).

   2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig).

   3. redefined term, "Location-by-Reference" (Tschofenig).

   4. redefined term, "Location Dereference Protocol" (Tschofenig).

   5. reworded term, "Location URI" (Tschofenig).

   6. modified steps, text, Figure 1 (Tschofenig).

   7. deleted redundant text in paragraph, "Because a location URI..."

   8. modified Authorization model text paragraphs, (Tschofenig).

   9. added qualifying sentence before sentence, "Thus, obfuscating the
   location URI..."  (Marshall based on question from Tschofenig).

   10. replaced diagram with one that contains both "LIS - LS" labeling

   11. added text to Introduction that a location URI is dynamic and may

Marshall                  Expires March 6, 2010                [Page 20]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   change over time (Martin, 2/23/09).

   12. section 3 text changed to make the makeup of a location URI less
   stringent as to being guessable, etc.  (Martin, 2/23/09).

   13. reordered "C" requirements from those remaining: C8-->C7;
   C9-->C8; C10-->C9.

   14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5.

   15. section-ized the overview, (section 3), for pointing to (Martin,

   16. edited section 3.4 to make clear that some default requirements
   may be relaxed ONLY if explicit local policy exists.  (RSM based on
   Martin, 2/23/09).

   17. added an citation for the geopriv-policy draft reference.

   18. reworded first couple of paragraphs of Introduction for

   Changes to this draft in comparison to the previous version (-05 vs.

   1.  Fixed minor spelilng errors.

   Changes to this draft in comparison to the previous version (-04 vs.

   1.  Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08
   list comments).

   1.  Relocated text in section 3 "Overview of Location-by-Reference"
   to section 1 (Intro), (Thomson comments).

   2.  (Sect. 3, con't) Fixed Figure 1.  Label, based on (Thomson

   3.  Fixed minor spelling errors, incl.  Note B., Note C., etc., based
   on (Thomson comments).

   4.  Added some qualifying text (security) around possession model,
   based on (Thomson comments).

   5.  Replaced "use type" labels with "authorization models", "access
   authorization model", and "possession authorization model", (Thomson

Marshall                  Expires March 6, 2010                [Page 21]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   6.  Changed the entity role of applying security from LIS (Server-
   side authentication), to the Rule Maker (owner/Target) providing
   policies to the LIS, (Thomson comments).

   7.  Changed requirement C3 to a MUST, (Thomson comments).

   8.  Added new requirement, C12, "C12.  Location URI Lifetime:" as a
   SHOULD for all, and MUST for possession auth model, (Thomson

   9.  Changed name of requirement C8 to "Location Only", (Thomson

   10.  Reworded C7 and D6 to be less implementation specific, (Thomson

   11.  Changed requirements C11, D11 to SHOULD, (Thomson comments).

   12.  (Section 5:) Removed lead in sentence for readibility, (Thomson

   13.  Remove "pawn ticket" reference - replaced with "possession
   authorization model", (Thomson comments).

   14.  Added new paragraph to the security section (Thomson, 7/09/08

   15.  Corrected other minor spelling and wording errors and
   deficiencies (refer to diff 04/03) (-Editor).

   Changes to this draft in comparison to the previous version (-03 vs.

   1.  Changed wording of section 3 "Overview of Location-by-Reference"
   (Polk, Thomson, Winterbottom ~ 4/1/08 list comments).

   2.  Added new requirement C4.  "Location Information Masking:", based
   on (Thomson ~4/1/08 list comment).

   3.  Added new requirement C11.  "Location URI Use Type:", based on
   (~4/1/08 list comments).

   4.  Added new requirement D11.  "Location URI Use Type:", for deref.
   based on (~4/1/08 list comments).

   5.  Replaced requirement D8.  "Location URI Non-Anonymized" with
   "Location Information Masking:".

Marshall                  Expires March 6, 2010                [Page 22]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

   Changes to this draft in comparison to the previous version (-02 vs.

   1.  Reworded Introduction (Barnes 12/6 list comments).

   2.  Changed name of "Basic Actors" section to "Overview of Location
   by Reference" (Barnes).

   3.  Keeping the LCP term away (for now) since it is used as Link
   Control Protocol elsewhere (IETF).

   4.  Changed formatting of Terminology section (Barnes).

   5.  Requirement C2. changed to indicate that if the URI has a
   lifetime, it has to have an expiry (Barnes)

   6.  C7.  Changed title and wording based on suggested text and dhcp-
   uri-option example (Polk).

   7.  The new C2 req. describing valid-for, was also added into the
   deref section, as D6

   8.  Changed C4 based on much list discussion - replaced by 3 new

   9.  Reworded C5 based on the follow-on C4 thread/discussion on list

   10.  Changed wording of D3 based on suggestion (Barnes).

   11.  Reworded D4 per suggestion (Barnes).

   12.  Changed D5 based on comment (Barnes), and additional title and
   text changes for clarity.

   13.  Added D9 and D10 per Richard Barnes suggestions - something
   needed in addition to his own security doc.

   14.  Deleted reference to individual Barnes-loc-sec draft per wg list
   suggestion (Barnes), but need more text for this draft's security

Marshall                  Expires March 6, 2010                [Page 23]

Internet-Draft          GEOPRIV LbyR Requirements         September 2009

Author's Address

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

   Phone: +1 206 792 2424

Marshall                  Expires March 6, 2010                [Page 24]