draft-ietf-geopriv-lbyr-requirements-02.txt   draft-ietf-geopriv-lbyr-requirements-03.txt 
GeoPriv R. Marshall, Ed. GeoPriv R. Marshall, Ed.
Internet-Draft TCS Internet-Draft TCS
Intended status: Informational February 25, 2008 Intended status: Informational July 9, 2008
Expires: August 28, 2008 Expires: January 10, 2009
Requirements for a Location-by-Reference Mechanism Requirements for a Location-by-Reference Mechanism
draft-ietf-geopriv-lbyr-requirements-02 draft-ietf-geopriv-lbyr-requirements-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 August 28, 2008. This Internet-Draft will expire on January 10, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 26 skipping to change at page 2, line 26
4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9
4.1. Requirements for a Location Configuration Protocol . . . 9 4.1. Requirements for a Location Configuration Protocol . . . 9
4.2. Requirements for a Location Dereference Protocol . . . . 11 4.2. Requirements for a Location Dereference Protocol . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
Location-based services rely on ready access to location information, Location-based services rely on ready access to location information,
which can be through a direct or indirect mechanism. While there are which can be through a direct or indirect mechanism. While there are
mechanisms for providing location directly, (e.g., as part of the SIP mechanisms for providing location directly, (e.g., as part of the SIP
signaling protocol), an alternative mechanism has been developed for signaling protocol), an alternative mechanism has been developed for
handling location indirectly, via a location reference, a pointer to handling location indirectly, via a location reference, a pointer to
the actual location information. This reference is called a location the actual location information. This reference is called a location
URI, and is used by the mechanism we generally call the Location-by- URI, and is used by the mechanism we generally call the Location-by-
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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 HELD, (a Geopriv layer 7 location configuration protocol).
Since, in this case the Target equals Recipient, then the Target can 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 subscribe to the URI in order to be notified of its current location
based on subscription parameters (see based on subscription parameters (see
[I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary [I-D.ietf-geopriv-loc-filters]). Additionally, a geospatial boundary
can be expressed (ref. [I-D.ietf-geopriv-policy]), so that the can be expressed (ref. [I-D.ietf-geopriv-policy]), so that the
Target/Recipient will get its updated location notification once it Target/Recipient will get its updated location notification once it
crosses the specified boundary. crosses the specified boundary.
Location URIs may have an life expiration associated to them, so the Location URIs may have an expiry associated to them, so that the LIS
LIS needs to be able to keep track of the location URIs that have is able to keep track of the location URIs that have been handed out,
been handed out, in addition, to also know about validity information to know whether a location URI is still valid once the LIS receives
for each location URI. Location URIs need to expire to prevent the it in a request, and in order for a recipient of such a URI from
recipient of such a URI from being able to (in some cases) being able to (in some cases) permanently track a host. Other
permanently track a host. Another example of the usefulness of an justifications for expiration of location URIs include the ability
expiration mechanism is to offer garbage collection capabilities to for a LIS to do garbage collection.
the LIS.
It is important to prevent adversaries from obtaining any information Because a location URI is a pointer to the Target's location, it is
about a Target through the location URI itself, or even a Target's important that it be constructed in such a way that it does not
location if the owner of the Target wants to protect it. Therefore, unintentionally reveal any usable information about the Target it
each location URI must be constructed with security safeguards in represents. For example, it is important to prevent adversaries from
mind. There are two general cases assumed, both having to do with obtaining any information that may be revealed about a Target by
the form of the location URI when it is created. 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.
Case 1. Where access to the location URI is limited by policy: This How a location URI is will ultimately be used within the dereference
is the case where the LIS applies authentication and access step is an important consideration at the time that the location URI
control at location configuration step and again at the is requested via a location configuration protocol. Since
dereference step. In this case, the URI can be of any form chosen dereferencing of location URIs could be done according to one of two
by the LIS. models, an "access control" model or a "possession" model (see
below), it is 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.
Case 2. Access limited by distribution: The LIS does not apply 1. Access control use type: Access to the location URI is limited by
authentication and access control at the time that the location policy. This is the case where, for location configuration, the
URI is dereferenced. In this case, the location URI must be LIS applies (server side) authentication and access control at the
difficult to guess (so that possession can be used to imply location configuration step, and repeats authentication and
authorization). authorization for each dereference operation of that location URI.
2. Possession use type: The possession use type is described as
having no authentication and/or authorization requirement aside
from only possessing the location URI itself (in this case,
possession implies authorization). Access to the location URI is
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 either of the above cases, a location URI needs to be
constructed 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 it. It is important to protect the actual
location information from an intermediate node (despite the fact
that in the possession model there would be nothing to 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 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. Given that either of these two general dereferencing protocol. Each of these two general protocols has
protocols can take the form of different protocols implementations multiple specific protocol implementations. Location configuration
for either location configuration vs. location dereference, (e.g., protocols include, HELD, DHCP, and LLDP-MED, whereas current location
HELD/DHCP/LLDP-MED, vs. HTTP GET/SIP SUBSCRIBE/NOTIFY, respectively). dereferencing protocols include HELD Deref, HTTP GET, and SIP
Because each of these specific protocol implementations has its own SUBSCRIBE/NOTIFY. Because each of these specific protocol
unique client and server interactions, the requirements here are not implementations has its own unique client and server interactions,
intended to state what a client or server is expected to do, but the requirements here are not intended to state what a client or
rather which requirements must be met separately by either a location server is expected to do, but rather which requirements must be met
configuration protocol, or a location dereference protocol, for the separately by any location configuration protocol or location
purposes of using a location URI. 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 configuration protocol MUST support a
skipping to change at page 10, line 5 skipping to change at page 10, line 5
C3. Location URI cancellation: The location configuration protocol C3. Location URI cancellation: The location configuration protocol
SHOULD support the ability to request a cancellation of a specific SHOULD 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. [Deleted, replaced by C8,C9,C10]: C4. 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 C5. User Identity Protection: The location URI MUST NOT contain any
user identifying information that identifies the user, device or user identifying information that identifies the user, device or
address of record, (e.g., which includes phone extensions, badge address of record, (e.g., which includes phone extensions, badge
numbers, first or last names, etc.), within the URI form. 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.
skipping to change at page 10, line 32 skipping to change at page 10, line 38
opposed to a location URI having multiple reuse capability. opposed to a location URI having multiple reuse capability.
C7. Location URI Valid-for: A location URI validity interval, if C7. Location URI Valid-for: A location URI validity interval, if
used, MUST include the validity time, in seconds, as an indication used, MUST include the validity time, in seconds, as an indication
of how long the client can consider a location URI to be valid. 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 Motivation: It is important to be able to determine how long a
location URI is to remain useful for, and when it must be location URI is to remain useful for, and when it must be
refreshed. refreshed.
C8. Location URI Anonymous: The location URI MUST NOT reveal any C8. Location URI Anonymous: The location URI MUST NOT point to any
information about the Target other than it's location. information about the Target other than it's location.
Motivation: A user should have the option to control how much Motivation: A user should have the option to control how much
information is revealed about them. This provides that control by information is revealed about them. This provides that control by
not forcing the inclusion of other information with location, not forcing the inclusion of other information with location,
(e.g., to not include any identification information in the (e.g., to not include any identification information in the
location URI.) location URI.)
C9. Location URI Not guessable: Location URIs that do not require C9. Location URI Not guessable: Where location URIs are used
authentication and authorization MUST NOT be guessable, based on publicly, any location URI MUST be constructed using properties of
the use of a cryptographically random sequence somewhere within uniqueness and cryptographically random sequences so that it is
the URI. (Note that the number of bits depends to some extent on not guessable. (Note that the number of bits depends to some
the number of active location URIs that might exist at the one extent on the number of active location URIs that might exist at
time; 128-bit is most likely enough for the short term.) the one time; 128-bit is most likely enough for the near term.)
Motivation: Location URIs need to guard against any observing node
Motivation: Location URIs without access control reveal private or individual stripping off meaningful information about the
information, and a guessable location URI could be easily Target.
exploited to obtain private information.
C10. Location URI Optional: In the case of user-provided C10. 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.
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 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
model.
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
skipping to change at page 12, line 32 skipping to change at page 12, line 43
D7. Location URI anonymized: Any location URI whose dereference will D7. Location URI anonymized: Any location URI whose dereference will
not be subject to authentication and access control MUST be not be subject to authentication and access control MUST be
anonymized. anonymized.
Motivation: The dereference protocol must define an anonymized Motivation: The dereference protocol must define an anonymized
format for location URIs. This format must identify the desired format for location URIs. This format must identify the desired
location information via a random token with at least 128 bits of location information via a random token with at least 128 bits of
entropy (rather than some kind of explicit identifier, such as an entropy (rather than some kind of explicit identifier, such as an
IP address). IP address).
D8. Location URI non-anonymized: The dereference protocol MAY define D8. Location Information Masking: The location URI form MUST,
a more general, non-anonymized URI format. through randomization and uniqueness, ensure that any location
specific information embedded within the location URI itself is
kept obscure during location URI dereferencing.
Motivation: Only location URIs for which dereference is subject to Motivation: It is important to keep any location information
access-control policy by the LIS may use this format. 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 D9. Location Privacy: The location dereference protocol MUST support
the application of privacy rules to the dissemination of a the application of privacy rules to the dissemination of a
requested location object. requested location object.
Motivation: The dereference server must obey all provisioned Motivation: The dereference server must obey all provisioned
privacy rules that apply to a requested location object. privacy rules that apply to a requested location object.
D10. Location Confidentiality: The dereference protocol MUST D10. Location Confidentiality: The dereference protocol MUST
support encryption of messages sent between the location support encryption of messages sent between the location
dereference client and the location dereference server, and MAY dereference client and the location dereference server, and MAY
alternatively provide messaging unencrypted. alternatively provide messaging unencrypted.
Motivation: Environmental and local configuration policy will Motivation: Environmental and local configuration policy will
guide the requirement for encryption for certain transactions. In guide the requirement for encryption for certain transactions. In
some cases, encryption may be the rule, in others, it may be some cases, encryption may be the rule, in others, it may be
acceptable to send and receive messages without encryption. 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 5. Security Considerations
The LbyR mechanism currently addresses security issues as follows. The LbyR mechanism currently addresses security issues as follows.
A location URI, regardless of its construction, if public, implies A location URI, regardless of its construction, if public, by
no safeguard against anyone being able to dereference and get the itself, implies no safeguard against anyone being able to
location. The method of constructing a location URI in its naming dereference and get the location. The method of constructing the
does help prevent some potential guessing, according to some location URI form to include randomization along with encryption
defined pattern. In the instance of one-time-use location URIs, does help prevent some potential pattern guessing. In the case of
which function similarly to a pawn ticket, the argument can be one time use location URIs, (referred to as a pawn ticket), the
made that with a pawn ticket, possession implies permission, and argument can be made that possession implies permission, and
location URIs which are public are protected only by privacy rules location URIs that are public are protected only by privacy rules
enforced at the dereference server. enforced at the dereference 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
We would like to thank the IETF GEOPRIV working group chairs, Andy We would like to thank the IETF GEOPRIV working group chairs, Andy
Newton, Allison Mankin and Randall Gellens, for creating the design Newton, Allison Mankin and Randall Gellens, for creating the design
skipping to change at page 17, line 17 skipping to change at page 17, line 17
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-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-05 (work in draft-ietf-geopriv-http-location-delivery-07 (work in
progress), February 2008. progress), April 2008.
[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-06 (work in Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
progress), November 2007. progress), June 2008.
[I-D.ietf-geopriv-loc-filters] [I-D.ietf-geopriv-loc-filters]
Mahy, R., "A Document Format for Filtering and Reporting Mahy, R., "A Document Format for Filtering and Reporting
Location Notications in the Presence Information Document Location Notications in the Presence Information Document
Format Location Object (PIDF-LO)", Format Location Object (PIDF-LO)",
draft-ietf-geopriv-loc-filters-01 (work in progress), draft-ietf-geopriv-loc-filters-01 (work in progress),
March 2007. March 2007.
[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-14 (work in progress), draft-ietf-geopriv-policy-17 (work in progress),
February 2008. June 2008.
[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-09 (work in progress), draft-ietf-sip-location-conveyance-10 (work in progress),
November 2007. February 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 (-03 vs.
-02):
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. Changes to this draft in comparison to the previous version (-02 vs.
-01): -01):
1. Reworded Introduction (Barnes 12/6 list comments). 1. Reworded Introduction (Barnes 12/6 list comments).
2. Changed name of "Basic Actors" section to "Overview of Location 2. Changed name of "Basic Actors" section to "Overview of Location
by Reference" (Barnes). by Reference" (Barnes).
3. Keeping the LCP term away (for now) since it is used as Link 3. Keeping the LCP term away (for now) since it is used as Link
Control Protocol elsewhere (IETF). Control Protocol elsewhere (IETF).
skipping to change at page 20, line 44 skipping to change at line 716
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 23 change blocks. 
76 lines changed or deleted 146 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/