draft-ietf-ecrit-phonebcp-06.txt   draft-ietf-ecrit-phonebcp-07.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track J. Polk Intended status: Standards Track J. Polk
Expires: May 7, 2009 Cisco Systems Expires: July 31, 2009 Cisco Systems
November 3, 2008 January 27, 2009
Best Current Practice for Communications Services in support of Best Current Practice for Communications Services in support of
Emergency Calling Emergency Calling
draft-ietf-ecrit-phonebcp-06 draft-ietf-ecrit-phonebcp-07
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 May 7, 2009. This Internet-Draft will expire on July 31, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
The IETF and other standards organization have efforts targeted at The IETF and other standards organization have efforts targeted at
standardizing various aspects of placing emergency calls on IP standardizing various aspects of placing emergency calls on IP
networks. This memo describes best current practice on how devices, networks. This memo describes best current practice on how devices,
networks and services should use such standards to make emergency networks and services should use such standards to make emergency
calls. calls.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 30
6. Location and its role in an emergency call . . . . . . . . . . 6 6. Location and its role in an emergency call . . . . . . . . . . 6
6.1. Types of location information . . . . . . . . . . . . . . 6 6.1. Types of location information . . . . . . . . . . . . . . 6
6.2. Location Determination . . . . . . . . . . . . . . . . . . 7 6.2. Location Determination . . . . . . . . . . . . . . . . . . 7
6.2.1. User-entered location information . . . . . . . . . . 7 6.2.1. User-entered location information . . . . . . . . . . 7
6.2.2. Access network "wire database" location information . 7 6.2.2. Access network "wire database" location information . 7
6.2.3. End-system measured location information . . . . . . . 7 6.2.3. End-system measured location information . . . . . . . 7
6.2.4. Network-measured location information . . . . . . . . 8 6.2.4. Network-measured location information . . . . . . . . 8
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 8
6.4. Location and references to location . . . . . . . . . . . 8 6.4. Location and references to location . . . . . . . . . . . 8
6.5. End system location configuration . . . . . . . . . . . . 9 6.5. End system location configuration . . . . . . . . . . . . 9
6.6. When location should be configured . . . . . . . . . . . . 9 6.6. When location should be configured . . . . . . . . . . . . 10
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 11
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 11
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 11
6.10. Location validation . . . . . . . . . . . . . . . . . . . 12 6.10. Location validation . . . . . . . . . . . . . . . . . . . 12
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 12
6.12. Other location considerations . . . . . . . . . . . . . . 12 6.12. Other location considerations . . . . . . . . . . . . . . 13
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 13
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 14
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 15
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. SIP signaling requirements for User Agents . . . . . . . . 15 9.2. SIP signaling requirements for User Agents . . . . . . . . 15
9.3. SIP signaling requirements for proxy servers . . . . . . . 16 9.3. SIP signaling requirements for proxy servers . . . . . . . 17
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 18
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 18
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 18
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
19.1. Normative References . . . . . . . . . . . . . . . . . . . 21 19.1. Normative References . . . . . . . . . . . . . . . . . . . 21
19.2. Informative References . . . . . . . . . . . . . . . . . . 24 19.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25 Appendix A. BCP Requirements Sorted by Responsible Party . . . . 25
A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25 A.1. Requirements of End Devices . . . . . . . . . . . . . . . 25
A.2. Requirements of Service Providers . . . . . . . . . . . . 34 A.2. Requirements of Service Providers . . . . . . . . . . . . 34
A.3. Requirements of Access Network . . . . . . . . . . . . . . 39 A.3. Requirements of Access Network . . . . . . . . . . . . . . 39
A.4. Requirements of Intermediate Devices . . . . . . . . . . . 41 A.4. Requirements of Intermediate Devices . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Terminology 1. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261], [RFC5012] and This document uses terms from [RFC3261], [RFC5012] and
[I-D.ietf-ecrit-framework]. [I-D.ietf-ecrit-framework].
skipping to change at page 9, line 7 skipping to change at page 9, line 7
6.4. Location and references to location 6.4. Location and references to location
ED-20/INT-11 Devices SHOULD be able to accept and forward location by ED-20/INT-11 Devices SHOULD be able to accept and forward location by
value or by reference. An end device that receives location by value or by reference. An end device that receives location by
reference (and does not also get the corresponding value) MUST be reference (and does not also get the corresponding value) MUST be
able to perform a dereference operation to obtain a value. able to perform a dereference operation to obtain a value.
6.5. End system location configuration 6.5. End system location configuration
ED-21/INT-12 Devices MUST support all of: DHCP location options ED-21/INT-12 Devices MUST support both the DHCP location options
[RFC4776] and [RFC3825], HELD [RFC4776], [RFC3825] and HELD
[I-D.ietf-geopriv-http-location-delivery] and LLDP-MED [LLDP-MED]. [I-D.ietf-geopriv-http-location-delivery]. When devices deploy a
specific access network interface in which that access network
supports location discovery such as LLDP-MED or 802.11, the device
SHOULD support the additional respective access network specific
location discovery mechanism.
AN-12/INT-13 The access network MUST support at least one of: DHCP AN-12/INT-13 The access network MUST support either DHCP location
location options, HELD or LLDP-MED. options or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network.
AN-13/INT-14 Where a router is employed between a LAN and WAN in a AN-13/INT-14 Where a router is employed between a LAN and WAN in a
small (less than approximately 650 square meters) area, the router small (less than approximately 650 square meters) area, the router
MUST be transparent to the location provided by the WAN to the LAN. MUST be transparent to the location provided by the WAN to the LAN.
This may mean the router must obtain location as a client from the This may mean the router must obtain location as a client from the
WAN, and supply an LCP server to the LAN with the location it WAN, and supply an LCP server to the LAN with the location it
obtains. Where the area is larger, the LAN MUST have a location obtains. Where the area is larger, the LAN MUST have a location
configuration mechanism meeting this BCP. configuration mechanism meeting this BCP.
ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in ED-22/INT-15 Endpoints SHOULD try all LCPs supported by the device in
skipping to change at page 21, line 12 skipping to change at page 21, line 19
Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom, Roger Marshall, Stu Goldman, Shida Schubert, James Winterbottom,
Barbara Stark, Richard Barnes and Peter Blatherwick. Barbara Stark, Richard Barnes and Peter Blatherwick.
19. References 19. References
19.1. Normative References 19.1. Normative 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-10 (work in draft-ietf-geopriv-http-location-delivery-11 (work in
progress), October 2008. progress), December 2008.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-04 (work in progress), draft-ietf-geopriv-lis-discovery-05 (work in progress),
October 2008. December 2008.
[I-D.ietf-geopriv-pdif-lo-profile] [I-D.ietf-geopriv-pdif-lo-profile]
Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-13 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), September 2008. (work in progress), November 2008.
[I-D.ietf-mmusic-media-loopback] [I-D.ietf-mmusic-media-loopback]
Hedayat, K., "An Extension to the Session Description Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback", Protocol (SDP) for Media Loopback",
draft-ietf-mmusic-media-loopback-09 (work in progress), draft-ietf-mmusic-media-loopback-09 (work in progress),
August 2008. August 2008.
[I-D.ietf-sip-gruu] [I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress), (SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007. October 2007.
[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-11 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
October 2008. November 2008.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-16 (work in progress), draft-ietf-sip-outbound-16 (work in progress),
October 2008. October 2008.
[I-D.ietf-sip-sips] [I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), February 2008. in progress), November 2008.
[LLDP] IEEE, "IEEE802.1ab Station and Media Access Control", [LLDP] IEEE, "IEEE802.1ab Station and Media Access Control",
Dec 2004. Dec 2004.
[LLDP-MED] [LLDP-MED]
TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media
Endpoint Discovery". Endpoint Discovery".
[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.
skipping to change at page 26, line 44 skipping to change at page 26, line 50
service provider MUST ensure that either the end device is provided service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call. detect the appropriate local dial strings at the time of the call.
ED-20 Devices SHOULD be able to accept and forward location by value ED-20 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to (and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value. perform a dereference operation to obtain a value.
ED-21 Devices MUST support all of: DHCP location options [RFC4776] ED-21 Devices MUST support both the DHCP location options [RFC4776],
and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery] and [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
LLDP-MED [LLDP-MED]. devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or
802.11, the device SHOULD support the additional respective access
network specific location discovery mechanism.
ED-22 Endpoints SHOULD try all LCPs supported by the device in any ED-22 Endpoints SHOULD try all LCPs supported by the device in any
order or in parallel. The first one that succeeds in supplying order or in parallel. The first one that succeeds in supplying
location can be used. location can be used.
ED-23 When HELD is the LCP, the request MUST specify a value of ED-23 When HELD is the LCP, the request MUST specify a value of
"emergencyRouting" for the "responseTime" parameter and use the "emergencyRouting" for the "responseTime" parameter and use the
resulting location for routing. If a value for dispatch location resulting location for routing. If a value for dispatch location
will be sent, another request with the "responseTime" parameter set will be sent, another request with the "responseTime" parameter set
to "emergencyDispatch" must be completed, with the result sent for to "emergencyDispatch" must be completed, with the result sent for
skipping to change at page 40, line 15 skipping to change at page 40, line 20
AN-10 Access networks that provide network measured location MUST AN-10 Access networks that provide network measured location MUST
have at least a coarse location (typically <1km when not location have at least a coarse location (typically <1km when not location
hiding) capability at all times for routing of calls. hiding) capability at all times for routing of calls.
AN-11 Access networks with range of <10 meters (e.g. personnal area AN-11 Access networks with range of <10 meters (e.g. personnal area
networks such as Bluetooth MUST provide a location to mobile devices networks such as Bluetooth MUST provide a location to mobile devices
connected to them. The location provided SHOULD be that of the connected to them. The location provided SHOULD be that of the
access point location unless a more accurate mechanism is provided. access point location unless a more accurate mechanism is provided.
AN-12 The access network MUST support at least one of: DHCP location AN-12 The access network MUST support either DHCP location options or
options, HELD or LLDP-MED. HELD. The access network SHOULD support other location technologies
that are specific to the type of access network.
AN-13 Where a router is employed between a LAN and WAN in a small AN-13 Where a router is employed between a LAN and WAN in a small
(less than approximately 650 square meters) area, the router MUST be (less than approximately 650 square meters) area, the router MUST be
transparent to the location provided by the WAN to the LAN. This may transparent to the location provided by the WAN to the LAN. This may
mean the router must obtain location as a client from the WAN, and mean the router must obtain location as a client from the WAN, and
supply an LCP server to the LAN with the location it obtains. Where supply an LCP server to the LAN with the location it obtains. Where
the area is larger, the LAN MUST have a location configuration the area is larger, the LAN MUST have a location configuration
mechanism meeting this BCP. mechanism meeting this BCP.
AN-14 Access networks that support more than one LCP MUST reply with AN-14 Access networks that support more than one LCP MUST reply with
skipping to change at page 43, line 6 skipping to change at page 43, line 11
service provider MUST ensure that either the end device is provided service provider MUST ensure that either the end device is provided
with the local dial strings for its current location (where the end with the local dial strings for its current location (where the end
device recognizes dial strings), or the service provider proxy MUST device recognizes dial strings), or the service provider proxy MUST
detect the appropriate local dial strings at the time of the call. detect the appropriate local dial strings at the time of the call.
INT-11 Devices SHOULD be able to accept and forward location by value INT-11 Devices SHOULD be able to accept and forward location by value
or by reference. An end device that receives location by reference or by reference. An end device that receives location by reference
(and does not also get the corresponding value) MUST be able to (and does not also get the corresponding value) MUST be able to
perform a dereference operation to obtain a value. perform a dereference operation to obtain a value.
INT-12 Devices MUST support all of: DHCP location options [RFC4776] INT-12 Devices MUST support both the DHCP location options [RFC4776],
and [RFC3825], HELD [I-D.ietf-geopriv-http-location-delivery] and [RFC3825] and HELD [I-D.ietf-geopriv-http-location-delivery]. When
LLDP-MED [LLDP-MED]. devices deploy a specific access network interface in which that
access network supports location discovery such as LLDP-MED or
802.11, the device SHOULD support the additional respective access
network specific location discovery mechanism.
INT-13 The access network MUST support at least one of: DHCP location INT-13 The access network MUST support either DHCP location options
options, HELD or LLDP-MED. or HELD. The access network SHOULD support other location
technologies that are specific to the type of access network.
INT-14 Where a router is employed between a LAN and WAN in a small INT-14 Where a router is employed between a LAN and WAN in a small
(less than approximately 650 square meters) area, the router MUST be (less than approximately 650 square meters) area, the router MUST be
transparent to the location provided by the WAN to the LAN. This may transparent to the location provided by the WAN to the LAN. This may
mean the router must obtain location as a client from the WAN, and mean the router must obtain location as a client from the WAN, and
supply an LCP server to the LAN with the location it obtains. Where supply an LCP server to the LAN with the location it obtains. Where
the area is larger, the LAN MUST have a location configuration the area is larger, the LAN MUST have a location configuration
mechanism meeting this BCP. mechanism meeting this BCP.
INT-15 Endpoints SHOULD try all LCPs supported by the device in any INT-15 Endpoints SHOULD try all LCPs supported by the device in any
skipping to change at page 44, line 41 skipping to change at page 45, line 4
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar NeuStar
470 Conrad Dr. 470 Conrad Dr.
Mars, PA 16046 Mars, PA 16046
US US
Phone: +1 724 382 1051 Phone: +1 724 382 1051
Email: br@brianrosen.net Email: br@brianrosen.net
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, TX 76034 Colleyville, TX 76034
US US
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.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. 23 change blocks. 
40 lines changed or deleted 61 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/