draft-ietf-geopriv-lbyr-requirements-05.txt   draft-ietf-geopriv-lbyr-requirements-06.txt 
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational November 28, 2008 Intended status: Informational February 26, 2009
Expires: June 1, 2009 Expires: August 30, 2009
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-05 draft-ietf-geopriv-lbyr-requirements-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2009. This Internet-Draft will expire on August 30, 2009.
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 (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
Abstract Abstract
This document defines terminology and provides requirements relating This document defines terminology and provides requirements relating
to Location-by-Reference approach using a location URI to handle to Location-by-Reference approach using a location URI to handle
location information within signaling and other Internet messaging. location information within signaling and other Internet messaging.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Location-by-Reference . . . . . . . . . . . . . . 7 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 8
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 9
4.1. Requirements for a Location Configuration Protocol . . . 10 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 9
4.2. Requirements for a Location Dereference Protocol . . . . 12 3.3. Location URI Authorization Models . . . . . . . . . . . . 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 . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
Since all location-based services rely on ready access to location All location-based services rely on ready access to location
information, this can accomplished through some direct means, or information. Within this document, the use of location information
alternatively, through some indirect means as a pointer to location is constrained according to specific policies included in
information. The direct vs. indirect approach we characterize as [I-D.ietf-geopriv-policy]. Using location information according to
either Location-by-Value (LbyV), or Location-by-Reference (LbyR). these policies can be done one of two ways, either in a direct,
Location-by-Value (LbyV) approach, or using an indirect, Location-by-
While it is the case that within SIP, location can be handled in a Reference (LbyR) model. Despite the standard technique of passing
direct manner, (i.e., passing the actual location information around location directly in SIP, in the form of a PIDF-LO, (Presence
in the form of a PIDF-LO*), there are additional location Information Document Format - Location Object, [RFC4119]), there are
requirements which apply to certain applications and/or location some cases where LbyV is not desirable. In cases where additional
architectures that are only satisfied by specifying an indirect location requirements apply to specific applications and/or location
location mechanism. This document puts forth a set of requirements architectures, and when can only be met by an indirect location
for such an indirect location approach, namely, the LbyR location mechanism, there is the Location-by-Reference model. This document
model. provides a list of requirements for use with the LbyR approach, and
leaves the LbyV model as explicitly out of scope.
As justification for a LbyR model, consider the following. In some As justification for a LbyR model, consider the following. In some
mobile networks it is not efficient for the end host to periodically mobile networks it is not efficient for the end host to periodically
query the LIS for up-to-date location information. This is query the LIS for up-to-date location information. This is
especially the case when power is a constraint or when a location especially the case when power is a constraint or when a location
update is not immediately needed. Furthermore, the end host might update is not immediately needed. Furthermore, the end host might
want to delegate the task of retrieving and publishing location want to delegate the task of retrieving and publishing location
information to a third party, such as to a presence server. information to a third party, such as to a presence server.
Additionally, in some deployments, the network operator may not want Additionally, in some deployments, the network operator may not want
to make location information widely available. These kinds of to make location information widely available. These kinds of
skipping to change at page 3, line 42 skipping to change at page 4, line 43
whether a mobile device needs to be located on demand or according to whether a mobile device needs to be located on demand or according to
some pre-determined interval, together form the basis of motivation some pre-determined interval, together form the basis of motivation
for the LbyR concept. for the LbyR concept.
The concept of an LbyR mechanism is simple. It is made up of a The concept of an LbyR mechanism is simple. It is made up of a
pointer which makes reference to the actual location information by pointer which makes reference to the actual location information by
some combination of key value and fully qualified domain name. This some combination of key value and fully qualified domain name. This
combination of data elements, in the form of a URI, is referred to combination of data elements, in the form of a URI, is referred to
specifically as a "location URI". specifically as a "location URI".
The LbyR mechanism itself works according to an information A location URI is thought of as a dynamic reference to the current
lifecycle. Within the LbyR mechanism, location URIs are temporary location of the Target, yet the location value might remain unchanged
over specific intervals of time for several reasons:
- 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.
The LbyR mechanism works according to an information lifecycle.
Within this lifecycle, location URIs are considered temporary
identifiers, each undergoing the following uses: Creation; identifiers, each undergoing the following uses: Creation;
Distribution; Conveyance; Dereference; and Termination. The use of a Distribution; Conveyance; Dereference; and Termination. The use of a
location URI according to these various states is generally applied location URI according to these various states is generally applied
in one of the following ways: in one of the following ways:
1. Creation of a location URI, within a location server, based on 1. Creation of a location URI, within a location server, based on
some request for its creation. some request for its creation.
2. Distribution of a location URI, via a Location Configuration 2. Distribution of a location URI, via a Location Configuration
Protocol, between a target and a location server**. Protocol, between a target and a location server.
3. Conveyance, applied to LbyR, in SIP, is the transporting of the 3. Conveyance, applied to LbyR, in SIP, is the transporting of the
location URI, in this case, between any successive signaling location URI, in this case, between any successive signaling nodes.
nodes***.
4. Dereference of a location URI, a request/response between a 4. Dereference of a location URI, a request/response between a
client having a location URI and a location server holding the client having a location URI and a location server holding the
location information that the location URI references. location information that the location URI references.
5. Termination of a location URI, either due to expiration or 5. Termination of a location URI, either due to expiration or
cancellation within a location server, and which is based on a target cancellation within a location server, and which is based on a target
cancellation request or some other action, such as timer cancellation request or some other action, such as timer
expiration. expiration.
Note that this document makes no differentiation between a LS, per
[RFC3693], and a 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 Location determination, different than location configuration or
dereferencing, often includes topics related to manual provisioning dereferencing, often includes topics related to manual provisioning
processes, automated location calculations based on a variety of processes, automated location calculations based on a variety of
measurement techniques, and/or location transformations, (e.g., geo- measurement techniques, and/or location transformations, (e.g., geo-
coding), and is beyond the scope of this document. coding), and is beyond the scope of this document.
*The standard mechanism for LbyV has been defined around the use of Location Conveyance for either LbyR or LbyV as defined within SIP
the PIDF-LO (Presence Information Document Format - Location Object signaling is considered out of scope for this document (see
[RFC4119]]), and is explicitly out of scope in this document.
**This document make no differentiation between a LS, per RFC3693,
and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to
either of them as a location server interchangeably.
***Location Conveyance for either LbyR or LbyV, within SIP signaling
is considered out of scope for this document (see
[I-D.ietf-sip-location-conveyance] for an explanation of location [I-D.ietf-sip-location-conveyance] for an explanation of location
conveyance for either LbyR or LbyV scenarios.) conveyance for either LbyR or LbyV scenarios.)
Except for location conveyance, the above stages in the LbyR Except for location conveyance, the above stages in the LbyR
lifecycle fall into one of two general categories of protocols, lifecycle fall into one of two general categories of protocols,
either a Location Configuration Protocol or a Location Dereference either a Location Configuration Protocol or a Location Dereference
Protocol. The stages of LbyR Creation, Distribution, and Protocol. The stages of LbyR Creation, Distribution, and
Termination, are each found within the set of Location Configuration Termination, are each found within the set of Location Configuration
Protocols (LCP). The Dereference stage belongs solely to the set of Protocols (LCP). The Dereference stage belongs solely to the set of
Location Dereference Protocols. Location Dereference Protocols.
The issues around location configuration protocols have been The issues around location configuration protocols have been
documented in a location configuration protocol problem statement and documented in a location configuration protocol problem statement and
requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are
currently several examples of a location configuration protocols currently several examples of a location configuration protocols
currently proposed, including, DHCP, LLDP-MED, and HELD currently proposed, including, DHCP
[I-D.ietf-geopriv-http-location-delivery]) protocols. [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD
[I-D.ietf-geopriv-http-location-delivery] protocols.
For dereferencing of a location URI, depending on the type of For dereferencing of a location URI, depending on the type of
reference used, such as a HTTP/HTTPS, or SIP Presence URI, different reference used, such as a HTTP/HTTPS, or SIP Presence URI, different
operations can be performed. While an HTTP/HTTPS URI can be resolved operations can be performed. While an HTTP/HTTPS URI can be resolved
to location information, a SIP Presence URI provides further benefits to location information, a SIP Presence URI provides further benefits
from the SUBSCRIBE/NOTIFY concept that can additionally be combined from the SUBSCRIBE/NOTIFY concept that can additionally be combined
with location filters [I-D.ietf-geopriv-loc-filters]. with location filters [I-D.ietf-geopriv-loc-filters].
The structure of this document includes terminology, Section 2, The structure of this document includes terminology, Section 2,
followed by a discussion of the basic elements that surround how a followed by a discussion of the basic elements that surround how a
location URI is used. These elements, or actors, are discussed in an location URI is used. These elements, or actors, are discussed in an
overview section, Section 3, accompanied by a graph and associated overview section, Section 3, accompanied by a graph, associated
processing steps. processing steps, and a brief discussion around the use, expiration,
authorization, and construction of location URIs.
Requirements are outlined accordingly, separated as location Requirements are outlined accordingly, separated as location
configuration requirements, Section 4.1, and location dereference configuration requirements, Section 4.1, and location dereference
requirements, Section 4.2. requirements, Section 4.2.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology of [RFC3693], such as Location This document reuses the terminology of [RFC3693], such as Location
Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
Location Generator (LG), Location Object (LO), and Using Protocol: Location Generator (LG), Location Object (LO), and Using Protocol:
Location-by-Value (LbyV): The mechanism of representing location Location-by-Value (LbyV): Location information in the format of a
either in configuration or conveyance protocols, (i.e., the actual PIDF-LO (or related encoding).
included location value).
Location-by-Reference (LbyR): The mechanism of representing location Location-by-Reference (LbyR): A location URI pointing to location
by means of a location URI for use in either a location information.
configuration, conveyance, or dereferencing protocol, and which
refers to a fully specified location.
Location Configuration Protocol: A protocol which is used by a Location Configuration Protocol: A protocol which is used by a
client to acquire either location or a location URI from a client to acquire either location or a location URI from a
location configuration server, based on information unique to the location configuration server, based on information unique to the
client. client.
Location Dereference Protocol: A protocol which is used by a client Location Dereference Protocol: A protocol that is used by a client
to query a location dereference server, based on location URI to query a location server, based on the location URI input and
input and which returns location information. which returns location information.
Location URI: An identifier which serves as a pointer to a location Location URI: As defined within this document, an identifier that
record on a remote host (e.g., LIS). Used within an Location-by- serves as a pointer to a location information. A location URI is
Reference mechanism, a location URI is provided by a location provided by a location server, and is later used as input by a
configuration server, and is used as input by a dereference dereference protocol to retrieve location information.
protocol to retrieve location from a dereference server.
3. Overview of Location-by-Reference 3. Overview of Location-by-Reference
This section describes the entities and interactions involved in the This section describes the entities and interactions involved in the
LbyR model. LbyR model.
+-----------+ Geopriv +-----------+ +---------+---------+ Location +-----------+
| | Location | Location | | | | Dereference | Location |
| LIS +---------------+ Recipient | | LIS - LS +---------------+ Recipient |
| | Dereference | | | | | Protocol | |
+-+---+-----+ Protocol (3) +----+------+ +----+----+----+----+ (3) +-----+-----+
* | -- | * |
Rulemaker * | Geopriv -- | Policy * |
Policy * | Location -- Location | Exchange * |
Exchange * | Configuration -- Configuration | (*) * | Location
(1b) * | Protocol -- Protocol | +----+----+ | Conveyance
* | (1a) -- Geopriv (1) | | Rule | | Protocol
* | -- Using Protocol | | Maker | | (2)
+ - - - -*- - - - - -|- - - -+ -- (e.g., SIP) +----+----+ +---------+ |
|+------+----+ +-----+-----+ |-- (2) | | |
| Rulemaker | | Target / |-- | Target +-------------------------------+
|| / owner | | End Host + | | |
| | | | +---------+
|+-----------+ +-----------+ |
| User of Target |
+ - - - - - - - - - - - - - -+
Figure 1: Location Reference Entities and Interactions Figure 1: Location Reference Entities and Interactions
Figure 1 shows the assumed communication model for both a layer 7 Figure 1 shows the assumed communication model for both a layer 7
location configuration protocol and a location dereference protocol. location configuration protocol and a location dereference protocol.
(1a). Target requests reference from server; and receives back, a 1. The Target (a Device) uses a Location Configuration Protocol to
location URI in server response acquire a location reference from a LIS, which acts as (or is able to
access) an LS.
(1b). Rulemaker policy is consulted (interface out of scope) 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.
(2). Target conveys reference to recipient (out of scope) 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.
(3). Recipient dereferences location URI, by a choice of methods, 2. The Target conveys the location URI to the Location Recipient
including a request/response (e.g., HTTP) or publish/subscription (interface out of scope).
(e.g., SIP SUBSCRIBE/NOTIFY)
Note A. There is no requirement for using the same protocol in (1a) 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). and (3).
Note B. Figure 1 includes the interaction between the owner of the Note B. Figure 1 includes the interaction between the owner of the
Target and the LIS to establish Rulemaker policies. This is Target and the LIS to obtain Rule Maker policies. This interaction
communications path (1b). This interaction needs to be done before needs to happen before the LIS will authorize anything other than
the LIS will authorize anything other than default policies to a what is allowed based on default policies in order to dereference a
dereference request for location of the Target. location request of the Target. This is communications path, (*),
out of scope for this document.
Note C. The Target may take on the role of the Location Recipient Note C. The Target might take on the role of the Location Recipient,
whereby it would dereference the location URI to obtain its own in which case it could attempt to dereference the location URI
location information. itself, in order to obtain its own location information.
An example scenario of how this might work, is where the Target 3.1. Location URI Usage
An example scenario of how the above might work, is where the Target
obtains a location URI in the form of a subscription URI (e.g., a SIP 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). URI) via a location configuration protocol. In this case, the Target
In this case, the Target is the same as the Recipient, therefore the is the same as the Recipient, therefore the Target can subscribe to
Target can subscribe to the URI in order to be notified of its the URI in order to be notified of its current location based on
current location based on subscription parameters. In the example, subscription parameters. In the example, parameters are set up for a
parameters are set up for a specific Target/Recipient along with an specific Target/Recipient along with an expressed geospatial
expressed geospatial boundary, so that the Target/Recipient receives boundary, so that the Target/Recipient receives an updated location
an updated location notification once the boundary is crossed (see notification once the boundary is crossed (see
[I-D.ietf-geopriv-loc-filters]). [I-D.ietf-geopriv-loc-filters]).
3.2. Location URI Expiration
Location URIs may have an expiry associated with them, primarily for Location URIs may have an expiry associated with them, primarily for
security considerations, and generally so that the LIS is able to security considerations, and generally so that the LIS is able to
keep track of the location URIs that have been handed out, to know 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 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 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 to (in some cases) permanently track a host. Expiration of a
location URI limits the time that accidental leaking of a location location URI limits the time that accidental leaking of a location
URI introduces. Other justifications for expiration of location URIs URI introduces. Other justifications for expiration of location URIs
include the ability for a LIS to do garbage collection. include the ability for a LIS to do garbage collection.
Because a location URI is a pointer to the Target's location, it is 3.3. Location URI Authorization Models
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 by
direct examination of the location URI itself, (e.g., names,
identifiers, etc.), some determinable pattern or syntax (e.g.,
sequence of numbers), or guessable codes (e.g., weak encryption).
Therefore, each location URI must be constructed with security
safeguards in mind.
How a location URI is will ultimately be used within the dereference How a location URI is will ultimately be used within the dereference
step is an important consideration at the time that the location URI step is an important consideration at the time that the location URI
is requested via a location configuration protocol. Since is requested via a location configuration protocol. Since
dereferencing of location URIs could be done according to one of two dereferencing of location URIs could be done according to one of two
authorization models, either an "access control authorization model" authorization models, either an "access control authorization model"
or a "possession authorization model" (see definitions, below), it is or a "possession authorization model", it is important that location
important that location configuration protocols indicate the type of configuration protocols indicate the type of a location URI that is
a location URI that is being requested, (and also which type is being requested, as well as which type is returned).
returned).
1. Access control authorization model: Access to the location URI is 1. Access Control Authorization.
limited by policy. In this case, the Rule Maker (owner/Target) is
able to provide authorization policies to the LIS during this
stage, or through some other parallel mechanism (e.g., interface
1b., Figure 1.). Policies are attached to a location URI through
an (undisclosed) mechanism.
2. Possession authorization model: The possession authorization Access to the location URI is limited by policy. In this model it
model is described as having no authentication and/or is assumed that the Rule Maker provides authorization policies to
authorization requirement aside from only possessing the location the LIS and these policies are attached to a location URI and
URI itself. In this case, possession implies authorization. control the dereferencing process.
Access to the location URI is limited by distribution only.
Whoever possesses the location URI has the ability to dereference
it. Possession authorization models may be used within specified
domains only, or might be used across wide open public networks.
In either of the above cases, a location URI needs to be constructed 2. Possession Authorization.
is such a way as to make it difficult to guess. The form of the URI
is constrained by the degree of randomness and uniqueness applied to The possession authorization model is described as not having
it. It is important to protect the actual location information from policies associated to the location URI aside from only possessing
an intermediate node (despite the fact that in the possession model the location URI itself. In this case, possession implies
there would be nothing to prevent an interceptor from seeking to authorization. Access to the location URI is limited by
dereference the location URI). Obfuscating the location URI distribution only. Whoever possesses the location URI has the
safeguards against the undetected stripping off of what would ability to dereference it. Possession authorization models may be
otherwise be evident location information, since it forces a used within specified domains only, or might be used across wide
dereference operation by the location dereference server, an open public networks.
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
actual location information from inspection by an intermediate node.
Construction of a location URI in such a way as to not reveal any
domain, user, or device specific 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, important step for the purpose of providing statistics, audit trails,
and general logging for many different kinds of location based and general logging for many different kinds of location based
services. services.
Where local policy explicitly relaxes the limitations around the
information provided within the structure of the location URI itself,
default restrictions may not exist. Under such conditions, it may be
reasonable, for example, to have the location URI be the AoR itself.
4. High-Level Requirements 4. High-Level Requirements
This document outlines the requirements for an Location by Reference This document outlines the requirements for an Location by Reference
mechanism which can be used by a number of underlying protocols. mechanism which can be used by a number of underlying protocols.
Requirements here address two general types of such protocols, a Requirements here address two general types of such protocols, a
general location configuration protocol, and a general location general location configuration protocol, and a general location
dereferencing protocol. Each of these two general protocols has dereferencing protocol.
multiple specific protocol implementations. Location configuration
protocols include, HELD, DHCP, and LLDP-MED, whereas current location
dereferencing protocols include HELD Deref, HTTP 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 any location configuration protocol or location
dereference protocol, for the purposes of using a location URI.
The requirements are broken into two sections. The requirements are broken into two sections.
4.1. Requirements for a Location Configuration Protocol 4.1. Requirements for a Location Configuration Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
configuration protocol. configuration protocol.
C1. Location URI support: The configuration protocol MUST support a C1. Location URI support: The location configuration protocol MUST
location reference in URI form. support a location reference in URI form.
Motivation: It is helpful to have a consistent form of key for the Motivation: A standardized location reference mechanism increases
LbyR mechanism. interoperability.
C2. Location URI expiration: When a location URI has a limited C2. Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated. validity interval, its lifetime MUST be indicated.
Motivation: A location URI may not intend to represent a location Motivation: A location URI may not intend to represent a location
forever, and the identifier eventually may need to be recycled, or forever, and the identifier eventually may need to be recycled, or
may be subject to a specific window of validity, after which the may be subject to a specific window of validity, after which the
location reference fails to yield a location, or the location is location reference fails to yield a location, or the location is
determined to be kept confidential. determined to be kept confidential.
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI. location URI.
Motivation: If the client determines that in its best interest to Motivation: If the client determines that in its best interest to
destroy the ability for a location URI to effectively be used 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 dereference a location, then there should be a way to nullify the
location URI. location URI.
C4. Location Information Masking: The location URI form MUST, C4. Location Information Masking: The location URI MUST, through
through randomization and uniqueness, ensure that any location randomization and uniqueness, ensure that the location URI does
specific information embedded within the location URI itself is not contain location information specific components.
kept obscure during location configuration.
Motivation: It is important to keep any location information Motivation: It is important to keep any location information
masked from a casual observing node. masked from a casual observing node.
C5. User Identity Protection: The location URI MUST NOT contain any C5. User Identity Protection: The location URI MUST NOT contain
user identifying information that identifies the user, device or information that identifies the user or device. Examples include
address of record, (e.g., which includes phone extensions, badge phone extensions, badge numbers, first or last names.
numbers, first or last names, etc.), within the URI form.
Motivation: It is important to protect caller identity or contact Motivation: It is important to protect caller identity or contact
address from being included in the form of the location URI itself address from being included in the form of the location URI itself
when it is generated. when it is generated.
C6. Reuse indicator: There SHOULD be a way to allow a client to C6. Reuse indicator: There SHOULD be a way to allow a client to
control whether a location URI can be resolved once only, or control whether a location URI can be resolved once only, or
multiple times. multiple times.
Motivation: The client requesting a location URI may request a Motivation: The client requesting a location URI may request a
location URI which has a 'one-time-use' only characteristic, as location URI which has a 'one-time-use' only characteristic, as
opposed to a location URI having multiple reuse capability. opposed to a location URI having multiple reuse capability.
C7. Validity Interval Indication: A location configuration protocol C7. Selective disclosure: The location configuration protocol MUST
MUST provide an indication of the location URI validity interval provide a mechanism to control what information is being disclosed
(i.e., expiry time) when present. about the Target.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be
refreshed.
C8. Location only: The location URI MUST NOT point to any Motivation: The Rule Maker has to be in control of how much
information about the Target other than it's location. information is revealed during the dereferencing step as part of
the privacy features.
Motivation: A user should have the option to control how much C8. Location URI Not guessable: As a default, the location
information is revealed about them. This provides that control by configuration protocol MUST return location URIs that are random
not forcing the inclusion of other information with location, and unique throughout the indicated lifetime. A location URI with
(e.g., to not include any identification information in the 128-bits of randomness is RECOMMENDED.
location URI.)
C9. Location URI Not guessable: Where location URIs are used Motivation: Location URIs should be constructed in such a way that
publicly, any location URI MUST be constructed using properties of an adversary cannot guess them and dereference them without having
uniqueness and cryptographically random sequences so that it is ever obtained them from the Target.
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 near term.)
Motivation: Location URIs need to guard against any observing node
or individual stripping off meaningful information about the
Target.
C10. Location URI Optional: In the case of user-provided C9. Location URI Optional: In the case of user-provided
authorization policies, where anonymous or non-guessable location authorization policies, where anonymous or non-guessable location
URIs are not warranted, the location configuration protocol MAY URIs are not warranted, the location configuration protocol MAY
support optional location URI forms. support optional location URI forms, (such as embedded location
information within the location URI).
Motivation: Users don't always have such strict privacy Motivation: Users don't always have such strict privacy
requirements, but may opt to specify their own location URI, or requirements, but may opt to specify their own location URI, or
components thereof. components thereof.
C11. Location URI Authorization Model: The location configuration
protocol SHOULD indicate whether the requested location URI
conforms to the access control authorization model or the
possession authorization 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 authorization model or a
possession authorization model.
C12. Location URI Lifetime: A location URI SHOULD have an
associated expiration lifetime (i.e., validity interval), and MUST
have an validity interval if used with the possession
authorization model.
Motivation: If a location URI is unintentionally leaked, then the
amount of time that the reference can be potentially used by an
unknown attacker (or, casual observer) needs to be limited.
4.2. Requirements for a Location Dereference Protocol 4.2. Requirements for a Location Dereference Protocol
Below, we summarize high-level design requirements needed for a Below, we summarize high-level design requirements needed for a
location-by-reference mechanism as used within the location location-by-reference mechanism as used within the location
dereference protocol. dereference protocol.
D1. Location URI support: The location dereference protocol MUST D1. Location URI support: The location dereference protocol MUST
support a location reference in URI form. support a location reference in URI form.
Motivation: It is required that there be consistency of use Motivation: It is required that there be consistency of use
between location URI formats used in an configuration protocol and between location URI formats used in an configuration protocol and
those used by a dereference protocol. those used by a dereference protocol.
D2. Validity Interval Indication: A location dereference protocol D2. Authentication: The location dereference protocol MUST include
MUST provide an indication of the location URI validity interval
(i.e., expiry time) when present.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and what time it will no
longer be usable.
D3. Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server. mechanisms to authenticate both the client and the server.
Motivation: Although the implementations must support Motivation: Although the implementations must support
authentication of both parties, any given transaction has the authentication of both parties, any given transaction has the
option not to authenticate one or both parties. option not to authenticate one or both parties.
D4. Dereferenced Location Form: The value returned by the D3. Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO document. dereference protocol MUST contain a well-formed PIDF-LO document.
Motivation: This is in order to ensure that adequate privacy rules Motivation: This is in order to ensure that adequate privacy rules
can be adhered to, since the PIDF-LO format comprises the can be adhered to, since the PIDF-LO format comprises the
necessary structures to maintain location privacy. necessary structures to maintain location privacy.
D5. Location URI Repeated Use: The location dereference protocol D4. Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be resolved MUST support the ability for the same location URI to be resolved
more than once, based on dereference server configuration. more than once, based on dereference server configuration.
Motivation: Through dereference server configuration, for example, Motivation: Through dereference server configuration, for example,
it may be useful to not only allow more than one dereference it may be useful to not only allow more than one dereference
request, but, in some cases, to also limit the number of request, but, in some cases, to also limit the number of
dereferencing attempts by a client. dereferencing attempts by a client.
D6. Validity Interval Indication: A dereference protocol MUST D5. Location Confidentiality: The location dereference protocol MUST
provide an indication of the location URI validity interval (i.e., support confidentiality protection of messages sent between the
expiry time) when present. Location Recipient and the location server.
Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be
refreshed.
D7. Location URI anonymized: Any location URI whose dereference will
not be subject to authentication and access control MUST be
anonymized.
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 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 URI dereferencing.
Motivation: It is important to keep any location information
masked from a casual observing node, requiring instead a discrete
dereference operation in order to 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 Authorization Model: The location dereference
protocol SHOULD indicate whether the requested location URI
conforms to the access control authorization model or the
possession authorization model.
Motivation: Downstream dereference clients need to know whether a Motivation: The location URI indicates what type of security
location URI provided by the location configuration protocol protocol has to be provided. An example is a location URI using a
conforms to an access control authorization model or a possession HTTPS URI scheme.
authorization model in order to save time processing dereference
attempts.
5. Security Considerations 5. Security Considerations
A location URI, regardless of its construction, if public, by itself, The method of constructing the location URI to include randomized
implies no safeguard against anyone being able to dereference and get components helps to prevent adversaries from obtaining location
the location. The method of constructing the location URI form to information without ever retrieving a location URI. In the
include randomization along with encryption does help prevent some possession model, a location URI, regardless of its construction, if
potential pattern guessing. In the case of one time use location made publically available, implies no safeguard against anyone being
URIs, (referred to as a pawn ticket), the argument can be made that able to dereference and get the location. Care has to be paid when
possession implies permission, and location URIs that are public are distribution such a location URI to the trusted location recipients.
protected only by privacy rules enforced at the dereference server. 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 Any location URI, by necessity, indicates the server (name) that
hosts the location information. Knowledge of the server in some hosts the location information. Knowledge of the server in some
specific domain could therefore reveal something about the location specific domain could therefore reveal something about the location
of the Target. This kind of threat may be mitigated somewhat by of the Target. This kind of threat may be mitigated somewhat by
introducing another layer of indirection: namely the use of a introducing another layer of indirection: namely the use of a
(remote) presence server. (remote) presence server.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by the IANA. This document does not require actions by the IANA.
7. Acknowledgements 7. Acknowledgements
I would like to thank the present IETF GEOPRIV working group chairs, I would like to thank the present IETF GEOPRIV working group chairs,
Robert Sparks and Richard Barnes for their continued support in Robert Sparks and Richard Barnes, past chairs, Andy Newton, Allison
progressing this document along, as well, I wish to thank past Mankin and Randall Gellens, for establishing the design team which
chairs, Andy Newton, Allison Mankin and Randall Gellens, for creating initiated this requirements work. I'd also like to thank those
the design team which initiated this requirements work. I'd also original design team participants for their inputs, comments, and
like to thank those original design team participants for their insightful reviews. The design team included the following folks:
inputs, comments, and insightful reviews. The design team included Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted
the following folks: Richard Barnes; Martin Dawson; Keith Drage; Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin;
Randall Gellens; Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian
Mahy; Allison Mankin; Roger Marshall; Andrew Newton; Jon Peterson; Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
James M. Polk; Brian Rosen; John Schnizlein; Henning Schulzrinne; Tschofenig; Martin Thomson; and James Winterbottom.
Barbara Stark; Hannes Tschofenig; Martin Thomson; and James
Winterbottom.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP)
Option for a Location Uniform Resource Identifier (URI)",
draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in
progress), November 2008.
[I-D.ietf-geopriv-http-location-delivery] [I-D.ietf-geopriv-http-location-delivery]
Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
"HTTP Enabled Location Delivery (HELD)", "HTTP Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-10 (work in draft-ietf-geopriv-http-location-delivery-12 (work in
progress), October 2008. progress), January 2009.
[I-D.ietf-geopriv-l7-lcp-ps] [I-D.ietf-geopriv-l7-lcp-ps]
Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol; Problem Statement and Location Configuration Protocol; Problem Statement and
Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-09 (work in
progress), June 2008. progress), February 2009.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R. and B. Rosen, "A Document Format for Filtering Mahy, R. and B. Rosen, "A Document Format for Filtering
and Reporting Location Notications in the Presence and Reporting Location Notications in the Presence
Information Document Format Location Object (PIDF-LO)", Information Document Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-03 (work in progress), draft-ietf-geopriv-loc-filters-03 (work in progress),
November 2008. November 2008.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-17 (work in progress), draft-ietf-geopriv-policy-20 (work in progress),
June 2008. February 2009.
[I-D.ietf-sip-location-conveyance] [I-D.ietf-sip-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sip-location-conveyance-12 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
November 2008. November 2008.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
Appendix A. Change log Appendix A. Change log
Changes to this draft in comparison to the previous version (-06 vs.
-05):
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..."
(Tschofenig).
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
(Martin).
11. added text to Introduction that a location URI is dynamic and may
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,
2/23/09)
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
readability.
Changes to this draft in comparison to the previous version (-05 vs. Changes to this draft in comparison to the previous version (-05 vs.
-04): -04):
1. Fixed minor spelilng errors. 1. Fixed minor spelilng errors.
Changes to this draft in comparison to the previous version (-04 vs. Changes to this draft in comparison to the previous version (-04 vs.
-03): -03):
1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08 1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08
list comments). list comments).
skipping to change at page 19, line 35 skipping to change at page 21, line 36
on (Thomson comments). on (Thomson comments).
4. Added some qualifying text (security) around possession model, 4. Added some qualifying text (security) around possession model,
based on (Thomson comments). based on (Thomson comments).
5. Replaced "use type" labels with "authorization models", "access 5. Replaced "use type" labels with "authorization models", "access
authorization model", and "possession authorization model", (Thomson authorization model", and "possession authorization model", (Thomson
comments). comments).
6. Changed the entity role of applying security from LIS (Server- 6. Changed the entity role of applying security from LIS (Server-
side authentication), to the Rule-Maker (owner/Target) providing side authentication), to the Rule Maker (owner/Target) providing
policies to the LIS, (Thomson comments). policies to the LIS, (Thomson comments).
7. Changed requirement C3 to a MUST, (Thomson comments). 7. Changed requirement C3 to a MUST, (Thomson comments).
8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a
SHOULD for all, and MUST for possession auth model, (Thomson SHOULD for all, and MUST for possession auth model, (Thomson
comments). comments).
9. Changed name of requirement C8 to "Location Only", (Thomson 9. Changed name of requirement C8 to "Location Only", (Thomson
comments). comments).
skipping to change at page 23, line 4 skipping to change at line 791
Roger Marshall (editor) Roger Marshall (editor)
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
2401 Elliott Avenue 2401 Elliott Avenue
2nd Floor 2nd Floor
Seattle, WA 98121 Seattle, WA 98121
US US
Phone: +1 206 792 2424 Phone: +1 206 792 2424
Email: rmarshall@telecomsys.com Email: rmarshall@telecomsys.com
URI: http://www.telecomsys.com URI: http://www.telecomsys.com
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
"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.
 End of changes. 61 change blocks. 
304 lines changed or deleted 316 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/