GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Intended status: Informational                         February 25,                              July 9, 2008
Expires: August 28, 2008 January 10, 2009

           Requirements for a Location-by-Reference Mechanism

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-

   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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). January 10, 2009.


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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of Location-by-Reference  . . . . . . . . . . . . . .  6
   4.  High-Level Requirements  . . . . . . . . . . . . . . . . . . .  9
     4.1.  Requirements for a  Location Configuration Protocol  . . .  9
     4.2.  Requirements for a  Location Dereference Protocol  . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 20 21

1.  Introduction

   Location-based services rely on ready access to location information,
   which can be through a direct or indirect mechanism.  While there are
   mechanisms for providing location directly, (e.g., as part of the SIP
   signaling protocol), an alternative mechanism has been developed for
   handling location indirectly, via a location reference, a pointer to
   the actual location information.  This reference is called a location
   URI, and is used by the mechanism we generally call the Location-by-
   Reference mechanism, or simply, LbyR.

   The use of a location URI is generally applied in one of the
   following ways:

   1.  Creation/allocation of a location URI, by a location server based
   on some request mechanism.

   2.  As part of a Location Configuration Protocol, between a target
   and location server*.

   3.  The location dereference process, (between a dereference  client
   and dereference server).

   4.  Cancellation/expiration of a location URI, by a location server
   based on either a direct target request or some other action (e.g.,

   *In this document, we make no differentiation between a LS, per
   RFC3693, and a LIS, but may refer to either of them as a location
   server interchangeably.

   These four things fall under two general protocol mechanisms,
   location configuration protocols and location dereference protocols.

   A fifth use of location URI is within the context of what is called
   location conveyance.  Location conveyance is defined as part of the
   SIP protocol, and is out of scope for this document. (see
   [I-D.ietf-sip-location-conveyance] for an explanation of conveyance
   of location using a location URI.

   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 a several examples of a location configuration
   protocol.  These include DHCP, LLDP-MED, and HELD
   [I-D.ietf-geopriv-http-location-delivery]) protocols.

   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 and associated
   processing steps.

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

   In contrast to using a location URI as the mechanism to support a
   Location-by-Reference model, it may be worth mentioning the common
   alternative model, that of Location-by-Value (LbyV), which provides
   location directly.  LbyV uses a location object, (e.g., a PIDF-LO,
   [RFC4119]) within SIP signaling.  Using the LbyV model for location
   configuration 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.

   Location determination, different than location configuration or
   dereferencing, often includes topics related to manual provisioning
   processes, automated measurements, and/or location transformations,
   (e.g., geo-coding), and are beyond the scope of this document.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document reuses the terminology of [RFC3693], such as Location
   Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
   Location Generator (LG), Location Object (LO), and Using Protocol:

   Location-by-Value (LbyV):  The mechanism of representing location
      either in configuration or conveyance protocols, (i.e., the actual
      included location value).

   Location-by-Reference (LbyR):  The mechanism of representing location
      by means of a location URI for use in either a location
      configuration, conveyance, or dereferencing protocol, and which
      refers to a fully specified location.

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

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

   Location URI:  An identifier which serves as a pointer to a location
      record on a remote host (e.g., LIS).  Used within an Location-by-
      Reference mechanism, a location URI is provided by a location
      configuration server, and is used as input by a dereference
      protocol to retrieve location from a dereference server.

3.  Overview of Location-by-Reference

   In mobile wireless networks it is not efficient for the end host to
   periodically query the LIS for up-to-date location information.  This
   is especially the case when power is a constraint or 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.  Finally,
   in some deployments, the network operator may not want to make
   location information widely available.

   Different location scenarios, such as whether a Target is mobile and
   whether a mobile device needs to be located on demand or according to
   some pre-determined interval motivated the introduction of the LbyR
   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

                    +-----------+  Geopriv      +-----------+
                    |           |  Location     | Location  |
                    |    LIS    +---------------+ Recipient |
                    |           |  Dereference  |           |
                    +-+---+-----+  Protocol (3) +----+------+
                     *    |                        --
         Rulemaker  *     | Geopriv              --
         Policy    *      | Location           --
         Exchange *       | Configuration    --
            (1b) *        | Protocol       --
                *         | (1a)         --      Geopriv
               *          |            --        Using Protocol
     + - - - -*- - - - - -|- - - -+  --          (e.g., SIP)
     |+------+----+ +-----+-----+ |--            (2)
      | Rulemaker | | Target /  |--
     ||  / owner  | | End Host  + |
      |           | |           |
     |+-----------+ +-----------+ |

     |       User of Target       |
     + - - - - - - - - - - - - - -+

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

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

   (1a).  Target requests reference from server; and receives back, a
   location URI in server response

   (1b).  Rulemaker policy is consulted (interface out of scope)

   (2).  Target conveys reference to recipient (out of scope)

   (3).  Recipient dereferences location URI, by a choice of methods,
   including a request/response (e.g., HTTP) or publish/subscription

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

   Note B. Figure 1 includes the interaction between the owner of the
   Target and the LIS to establish Rulemaker policies.  This is
   communications path (1b).  This interaction needs to be done before
   the LIS will authorize anything of than default policies to a
   dereference request for location of the Target.

   Note C. that the Target may take on the role of the Location
   Recipient whereby it would dereference the location URI to obtain its
   own location information.

   An example scenario of how this might work, is where the Target
   obtains a location URI in the form of a subscription URI (e.g., a SIP
   URI) via HELD, (a Geopriv layer 7 location configuration protocol).
   Since, in this case the Target equals Recipient, then the Target can
   subscribe to the URI in order to be notified of its current location
   based on subscription parameters (see
   [I-D.ietf-geopriv-loc-filters]).  Additionally, a geospatial boundary
   can be expressed (ref.  [I-D.ietf-geopriv-policy]), so that the
   Target/Recipient will get its updated location notification once it
   crosses the specified boundary.

   Location URIs may have an life expiration expiry associated to them, so that the LIS needs to be
   is able to keep track of the location URIs that have been handed out, in addition,
   to also know about validity information
   for each whether a location URI.  Location URIs need to expire to prevent 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.  Another example  Other
   justifications for expiration of location URIs include the usefulness of an
   expiration mechanism is ability
   for a LIS to offer do garbage collection capabilities collection.

   Because a location URI is a pointer to the LIS.

   It Target's location, it is
   important that it be constructed in such a way that it does not
   unintentionally reveal any usable information about the Target it
   represents.  For example, it is important to prevent adversaries from
   obtaining any information that may be revealed about a Target through by
   direct examination of the location URI itself, (e.g., names,
   identifiers, etc.), some determinable pattern or even a Target's
   location if the owner syntax (e.g.,
   sequence of the Target wants to protect it. numbers), or guessable codes (e.g., weak encryption).
   Therefore, each location URI must be constructed with security
   safeguards in mind.  There are two general cases assumed, both having to do with

   How a location URI is will ultimately be used within the form of dereference
   step is an important consideration at the time that the location URI when
   is requested via a location configuration protocol.  Since
   dereferencing of location URIs could be done according to one of two
   models, an "access control" model or a "possession" model (see
   below), it is created.

   Case important that location configuration protocols
   indicate the type of a location URI that is being requested, (and
   also which type is returned).  Dereference protocols must support
   both types.

   1.  Where access Access control use type:  Access to the location URI is limited by policy:
      policy.  This is the case where where, for location configuration, the
      LIS applies (server side) authentication and access control at the
      location configuration step step, and again at the repeats authentication and
      authorization for each dereference step.  In this case, the URI can be operation of any form chosen
      by the LIS.

   Case that location URI.

   2.  Access limited by distribution: Possession use type:  The LIS does not apply possession use type is described as
      having no authentication and access control at and/or authorization requirement aside
      from only possessing the time that location URI itself (in this case,
      possession implies authorization).  Access to the location URI is dereferenced.
      limited by distribution only.  Whoever possesses the location URI
      has the ability to dereference it.  Possession use types may be
      used within specified domains only, or might be used across wide
      open public networks.

      In this case, either of the above cases, a location URI must needs to be
      constructed is such a way as to make it difficult to guess (so guess.  The
      form of the URI is constrained by the degree of randomness and
      uniqueness applied to it.  It is important to protect the actual
      location information from an intermediate node (despite the fact
      that in the possession can model there would be used nothing to imply
      authorization). prevent an
      interceptor from seeking to dereference the location URI).
      Obfuscating the location URI safeguards against the undetected
      stripping off of what would otherwise be evident location
      information, since it forces a dereference operation by 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.

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.  Given that either  Each of these two general protocols can take the form of different protocols implementations
   for either location has
   multiple specific protocol implementations.  Location configuration vs.
   protocols include, HELD, DHCP, and LLDP-MED, whereas current location dereference, (e.g.,
   dereferencing protocols include HELD Deref, HTTP GET/SIP SUBSCRIBE/NOTIFY, respectively). GET, and SIP
   SUBSCRIBE/NOTIFY.  Because each of these specific protocol
   implementations has its own unique client and server interactions,
   the requirements here are not intended to state what a client or
   server is expected to do, but rather which requirements must be met
   separately by either a any location configuration protocol, protocol or a location
   dereference protocol, for the purposes of using a location URI.

   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 configuration protocol MUST support a
      location reference in URI form.

      Motivation: It is helpful to have a consistent form of key for the
      LbyR mechanism.

   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
      SHOULD support the ability to request a cancellation of a specific
      location URI.

      Motivation: If the client 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. [Deleted, replaced by C8,C9,C10]: Location Information Masking:  The location URI form MUST,
      through randomization and uniqueness, ensure that any location
      specific information embedded within the location URI itself is
      kept obscure during location configuration.

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

   C5. User Identity Protection:  The location URI MUST NOT contain any
      user identifying information that identifies the user, device or
      address of record, (e.g., which includes phone extensions, badge
      numbers, first or last names, etc.), within the URI form.

      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 client to
      control whether a location URI can be resolved once only, or
      multiple times.

      Motivation: The client 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.

   C7. Location URI Valid-for:  A location URI validity interval, if
      used, MUST include the validity time, in seconds, as an indication
      of how long the client can consider a location URI to be valid.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and when it must be

   C8. Location URI Anonymous:  The location URI MUST NOT reveal point to any
      information about the Target other than it's location.

      Motivation: A user should have the option to control how much
      information is revealed about them.  This provides that control by
      not forcing the inclusion of other information with location,
      (e.g., to not include any identification information in the
      location URI.)

   C9. Location URI Not guessable:  Location  Where location URIs that do not require
      authentication and authorization are used
      publicly, any location URI MUST NOT be guessable, based on
      the use constructed using properties of a
      uniqueness and cryptographically random sequence somewhere within
      the URI. sequences so that it is
      not guessable.  (Note that the number of bits depends to some
      extent on the number of active location URIs that might exist at
      the one time; 128-bit is most likely enough for the short near term.)
      Motivation: Location URIs without access control reveal private
      information, and a guessable location URI could be easily
      exploited need to obtain private information. guard against any observing node
      or individual stripping off meaningful information about the

   C10.  Location URI Optional:  In the case of user-provided
      authorization policies, where anonymous or non-guessable location
      URIs are not warranted, the location configuration protocol MAY
      support optional location URI forms.

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

   C11.  Location URI Use Type:  The location configuration protocol
      MUST indicate whether the requested location URI conforms to the
      access control model or the possession model.

      Motivation: Downstream dereference clients and servers need to
      know whether a location URI provided by the location configuration
      protocol conforms to an access control model or a possession

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. Location URI expiration indicator:  The location dereference
      protocol MUST support an indicator showing that, if it is the
      case, that a location URI is no longer valid due to expiration.

      Motivation: Location URIs are expected to expire, based on
      location configuration protocol parameters, and it is therefore
      useful to convey the expired status of the location URI in the
      location dereference protocol.

   D3. 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.

   D4.  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.

   D5. 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.

   D6. Location URI Valid-for:  A location URI validity interval, if
      used, MUST include the validity time, in seconds, as an indication
      of how long the client can consider a location URI to be valid.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful when dereferencing a location

   D7. Location URI anonymized:  Any location URI whose dereference will
      not be subject to authentication and access control MUST be

      Motivation: The dereference protocol must define an anonymized
      format for location URIs.  This format must identify the desired
      location information via a random token with at least 128 bits of
      entropy (rather than some kind of explicit identifier, such as an
      IP address).

   D8. Location URI non-anonymized: Information Masking:  The dereference protocol MAY define
      a more general, non-anonymized location URI form MUST,
      through randomization and uniqueness, ensure that any location
      specific information embedded within the location URI format. itself is
      kept obscure during location URI dereferencing.

      Motivation: Only It is important to keep any location URIs for which information
      masked from a casual observing node, requiring instead a discrete
      dereference is subject operation in order to
      access-control policy by the LIS may use this format. return location information.

   D9. Location Privacy:  The location dereference protocol MUST support
      the application of privacy rules to the dissemination of a
      requested location object.

      Motivation: The dereference server must obey all provisioned
      privacy rules that apply to a requested location object.

   D10.  Location Confidentiality:  The dereference protocol MUST
      support encryption of messages sent between the location
      dereference client and the location dereference server, and MAY
      alternatively provide messaging unencrypted.

      Motivation: Environmental and local configuration policy will
      guide the requirement for encryption for certain transactions.  In
      some cases, encryption may be the rule, in others, it may be
      acceptable to send and receive messages without encryption.

   D11.  Location URI Use Type:  The location dereference protocol MUST
      indicate whether the requested location URI conforms to the access
      control model or the possession model.

      Motivation: Downstream dereference clients need to know whether a
      location URI provided by the location configuration protocol
      conforms to an access control model or a possession model in order
      to save time processing dereference attempts.

5.  Security Considerations

   The LbyR mechanism currently addresses security issues as follows.

      A location URI, regardless of its construction, if public, by
      itself, implies no safeguard against anyone being able to
      dereference and get the location.  The method of constructing a the
      location URI in its naming form to include randomization along with encryption
      does help prevent some potential guessing, according to some
      defined pattern. pattern guessing.  In the instance case of one-time-use
      one time use location URIs,
      which function similarly (referred to as a pawn ticket, ticket), the
      argument can be made that with a pawn ticket, possession implies permission, and
      location URIs which that are public are protected only by privacy rules
      enforced at the dereference server.

6.  IANA Considerations

   This document does not require actions by the IANA.

7.  Acknowledgements

   We would like to thank the IETF GEOPRIV working group chairs, Andy
   Newton, Allison Mankin and Randall Gellens, for creating the design
   team which initiated this requirements work.  We'd also like to thank
   those design team participants for their inputs, comments, and
   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 Mankin; Roger
   Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen;
   John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
   Tschofenig; Martin Thomson; and James Winterbottom.

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

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

              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-06 draft-ietf-geopriv-l7-lcp-ps-08 (work in
              progress), November 2007. June 2008.

              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.

              Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
              and J. Polk, "Geolocation Policy: A Document Format for
              Expressing Privacy Preferences for  Location Information",
              draft-ietf-geopriv-policy-17 (work in progress),
              June 2008.

              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-10 (work in progress),
              November 2007.
              February 2008.

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

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

Appendix A.  Change log

   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:".

   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

Author's Address

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

   Phone: +1 206 792 2424

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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

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

   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


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