draft-ietf-ecrit-framework-06.txt   draft-ietf-ecrit-framework-07.txt 
ecrit B. Rosen ecrit B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: January 11, 2009 Columbia U. Expires: July 31, 2009 Columbia U.
J. Polk J. Polk
Cisco Systems Cisco Systems
A. Newton A. Newton
TranTech/MediaSolv TranTech/MediaSolv
July 10, 2008 January 27, 2009
Framework for Emergency Calling using Internet Multimedia Framework for Emergency Calling using Internet Multimedia
draft-ietf-ecrit-framework-06 draft-ietf-ecrit-framework-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 January 11, 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 has several efforts targeted at standardizing various The IETF has several efforts targeted at standardizing various
aspects of placing emergency calls. This document describes how all aspects of placing emergency calls. This document describes how all
of those component parts are used to support emergency calls from of those component parts are used to support emergency calls from
citizens and visitors to authorities. citizens and visitors to authorities.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of how emergency calls are placed . . . . . . . . . . 7 3. Overview of how emergency calls are placed . . . . . . . . . . 8
4. Which devices and services should support emergency calls . . 10 4. Which devices and services should support emergency calls . . 11
5. Identifying an emergency call . . . . . . . . . . . . . . . . 11 5. Identifying an emergency call . . . . . . . . . . . . . . . . 12
6. Location and its role in an emergency call . . . . . . . . . . 12 6. Location and its role in an emergency call . . . . . . . . . . 13
6.1. Types of location information . . . . . . . . . . . . . . 14 6.1. Types of location information . . . . . . . . . . . . . . 15
6.2. Location determination . . . . . . . . . . . . . . . . . . 15 6.2. Location determination . . . . . . . . . . . . . . . . . . 16
6.2.1. User-entered location information . . . . . . . . . . 16 6.2.1. User-entered location information . . . . . . . . . . 17
6.2.2. Access network "wire database" location information . 16 6.2.2. Access network "wire database" location information . 17
6.2.3. End-system measured location information . . . . . . . 17 6.2.3. End-system measured location information . . . . . . . 18
6.2.4. Network measured location information . . . . . . . . 18 6.2.4. Network measured location information . . . . . . . . 19
6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 18 6.3. Who adds location, endpoint or proxy . . . . . . . . . . . 19
6.4. Location and references to location . . . . . . . . . . . 19 6.4. Location and references to location . . . . . . . . . . . 20
6.5. End system location configuration . . . . . . . . . . . . 19 6.5. End system location configuration . . . . . . . . . . . . 20
6.6. When location should be configured . . . . . . . . . . . . 21 6.6. When location should be configured . . . . . . . . . . . . 22
6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 21 6.7. Conveying location in SIP . . . . . . . . . . . . . . . . 22
6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 22 6.8. Location updates . . . . . . . . . . . . . . . . . . . . . 23
6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 23 6.9. Multiple locations . . . . . . . . . . . . . . . . . . . . 24
6.10. Location validation . . . . . . . . . . . . . . . . . . . 23 6.10. Location validation . . . . . . . . . . . . . . . . . . . 25
6.11. Default location . . . . . . . . . . . . . . . . . . . . . 24 6.11. Default location . . . . . . . . . . . . . . . . . . . . . 25
6.12. Location format conversion . . . . . . . . . . . . . . . . 24 6.12. Location format conversion . . . . . . . . . . . . . . . . 26
7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 24 7. LIS and LoST Discovery . . . . . . . . . . . . . . . . . . . . 26
8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 25 8. Routing the call to the PSAP . . . . . . . . . . . . . . . . . 26
9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 27 9. Signaling of emergency calls . . . . . . . . . . . . . . . . . 28
9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. SIP signaling requirements for User Agents . . . . . . . . 27 9.2. SIP signaling requirements for User Agents . . . . . . . . 29
9.3. SIP signaling requirements for proxy servers . . . . . . . 28 9.3. SIP signaling requirements for proxy servers . . . . . . . 29
10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Call backs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 28 11. Mid-call behavior . . . . . . . . . . . . . . . . . . . . . . 30
12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 29 12. Call termination . . . . . . . . . . . . . . . . . . . . . . . 30
13. Disabling of features . . . . . . . . . . . . . . . . . . . . 29 13. Disabling of features . . . . . . . . . . . . . . . . . . . . 30
14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 15. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
19. Informative References . . . . . . . . . . . . . . . . . . . . 31 19. Informative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Terminology 1. Terminology
This document uses terms from [RFC3261] and [RFC5012]. In addition This document uses terms from [RFC3261] and [RFC5012]. In addition
the following terms are used: the following terms are used:
Access network: The access network supplies IP packet service to an Access network: The access network supplies IP packet service to an
endpoint. Examples of access networks include digital subscriber endpoint. Examples of access networks include digital subscriber
lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local lines (DSL), cable modems, IEEE 802.11, WiMaX, enterprise local
area networks, or cellular data networks. area networks, or cellular data networks.
(Emergency) Call taker: An emergency call taker answers an emergency (Emergency) Call taker: An emergency call taker answers an emergency
call at the PSAP. call at the PSAP.
Confidence: Confidence is an estimate indicating how sure the Confidence: Confidence is an estimate indicating how sure the
measuring system is that the actual location of the person is measuring system is that the actual location of the person is
within the bounds defined by the uncertainty value, expressed as a within the bounds defined by the uncertainty value, expressed as a
percentage. For example, a value of 90% indicates that the actual percentage. For example, a value of 90% indicates that the actual
location is within the uncertainty nine times out of ten. location is within the uncertainty nine times out of ten.
Dispatch Location: The dispatch location is the location used for Dispatch Location: The dispatch location is the location used for
dispatching responders to the person in need of assistance. The dispatching responders to the person in need of assistance. The
dispatch location must be sufficiently precise to easily locate dispatch location must be sufficiently precise to easily locate
the callee; it typically needs to be more accurate than the the caller; it typically needs to be more accurate than the
routing location. routing location.
Emergency services routing proxy (ESRP): An emergency services Emergency services routing proxy (ESRP): An emergency services
routing proxy provides routing services for a group of PSAPs. routing proxy provides routing services for a group of PSAPs.
Location configuration: During location configuration, an endpoint Location configuration: During location configuration, an endpoint
learns its physical location. learns its physical location.
Location conveyance: Location conveyance delivers location Location conveyance: Location conveyance delivers location
information to another element. information to another element.
Location determination: Location determination finds where an Location determination: Location determination finds where an
endpoint is physically located. For example, the endpoint may endpoint is physically located. For example, the endpoint may
contain a GPS receiver used to measure its own location or the contain a GPS receiver used to measure its own location or the
skipping to change at page 7, line 26 skipping to change at page 8, line 26
call by a unique Service URN [RFC5031] that is placed in the call call by a unique Service URN [RFC5031] that is placed in the call
set-up signaling when a home or visited emergency dial string is set-up signaling when a home or visited emergency dial string is
detected. Because emergency services are local to specific detected. Because emergency services are local to specific
geographic regions, a caller must obtain his location ( Section 6) geographic regions, a caller must obtain his location ( Section 6)
prior to making emergency calls. To get this location, either a form prior to making emergency calls. To get this location, either a form
of measuring, for example, GPS (Section 6.2.3) is deployed, or the of measuring, for example, GPS (Section 6.2.3) is deployed, or the
endpoint is configured (Section 6.5) with its location from the endpoint is configured (Section 6.5) with its location from the
access network's Location Information Server (LIS). The location is access network's Location Information Server (LIS). The location is
conveyed (Section 6.7) in the SIP signaling with the call. The call conveyed (Section 6.7) in the SIP signaling with the call. The call
is routed (Section 8) based on location using the LoST protocol is routed (Section 8) based on location using the LoST protocol
[I-D.ietf-ecrit-lost], which maps a location to a set of PSAP URIs. [RFC5222], which maps a location to a set of PSAP URIs. Each URI
Each URI resolves to a PSAP or an Emergency Services Routing Proxy resolves to a PSAP or an Emergency Services Routing Proxy (ESRP) that
(ESRP) that serves as an incoming proxy for a group of PSAPs. The serves as an incoming proxy for a group of PSAPs. The call arrives
call arrives at the PSAP with the location included in the INVITE at the PSAP with the location included in the INVITE request.
request.
The following is a quick overview for a typical Ethernet connected The following is a quick overview for a typical Ethernet connected
telephone using SIP signaling. It illustrates one set of choices for telephone using SIP signaling. It illustrates one set of choices for
various options presented later in this document. various options presented later in this document.
o The phone "boots" and connects to its access network o The phone "boots" and connects to its access network
o The phone gets location from the DHCP server in civic [RFC4776] or o The phone gets location from the DHCP server in civic [RFC4776]
geo [RFC3825] forms, a HELD server and/or geo [RFC3825] forms, a HELD server
[I-D.ietf-geopriv-http-location-delivery] or the first level [I-D.ietf-geopriv-http-location-delivery] or the first level
switch's LLDP server [LLDP]. switch's LLDP server [LLDP].
o The phone obtains the local emergency dial string(s) from the o The phone obtains the local emergency dial string(s) from the
[I-D.ietf-ecrit-lost] server for its current location. It also [RFC5222] server for its current location. It also receives and
receives and caches the PSAP URI obtained from LoST. caches the PSAP URI obtained from LoST.
o Some time later, the user places an emergency call. The phone o Some time later, the user places an emergency call. The phone
recognizes an emergency call from the dial strings and uses recognizes an emergency call from the dial strings and uses
"urn:service:sos" [RFC5031] to mark an emergency call. "urn:service:sos" [RFC5031] to mark an emergency call.
o It determines the PSAP's URI by querying the LoST mapping server o It refreshes its location via DHCP and updates the PSAP's URI by
with its location. querying the LoST mapping server with its location.
o It puts its location in the SIP INVITE in a Geolocation header o It puts its location in the SIP INVITE in a Geolocation header
[I-D.ietf-sip-location-conveyance] and forwards the call using its [I-D.ietf-sip-location-conveyance] and forwards the call using its
normal outbound call processing, which commonly involves an normal outbound call processing, which commonly involves an
outgoing proxy. outgoing proxy.
o The proxy recognizes the call as an emergency call and routes the o The proxy recognizes the call as an emergency call and routes the
call using normal SIP routing mechanisms to the URI specified. call using normal SIP routing mechanisms to the URI specified.
o The call routing commonly traverses an incoming proxy server o The call routing commonly traverses an incoming proxy server
(ESRP) in the emergency services network. That proxy would route (ESRP) in the emergency services network. That proxy would route
the call to the PSAP. the call to the PSAP.
o The call is established with the PSAP and mutually agreed upon o The call is established with the PSAP and mutually agreed upon
media streams are created. media streams are created.
o The location of the caller is displayed to the call taker. o The location of the caller is displayed to the call taker.
Configuration Servers Configuration Servers
skipping to change at page 9, line 34 skipping to change at page 10, line 34
200 OK and ACK propogated back from PSAP to Alice 200 OK and ACK propogated back from PSAP to Alice
Figure 2 Figure 2
Figure 1 shows emergency call component topology and the text above Figure 1 shows emergency call component topology and the text above
shows call establishment. These include the following components: shows call establishment. These include the following components:
o Alice - who makes the emergency call. o Alice - who makes the emergency call.
o Configuration Servers - Servers providing Alice's UA its IP o Configuration Servers - Servers providing Alice's UA its IP
address and other configuration information, perhaps including address and other configuration information, perhaps including
location by-value or by-reference. In this flow, DHCP is used as location by-value or by-reference. Configuration servers also may
an example location configuration protocol (LCP). Configuration include a SIP registrar for Alice's UA. Most SIP UAs will
servers also may include a SIP registrar for Alice's UA. Most SIP register, so it will be a common scenario for UAs that make
UAs will register, so it will be a common scenario for UAs that emergency calls to be registered with such a server in the
make emergency calls to be registered with such a server in the
originating calling network. Registration would be required for originating calling network. Registration would be required for
the PSAP to be able to call back after an emergency call is the PSAP to be able to call back after an emergency call is
completed. All the configuration messages are labeled M1 through completed. All the configuration messages are labeled M1 through
M3, but could easily require more than 3 messages to complete. M3, but could easily require more than 3 messages to complete.
o LoST server - Processes the LoST request for Location + Service o LoST server - Processes the LoST request for Location + Service
URN to PSAP-URI Mapping function, either for an initial request URN to PSAP-URI Mapping function, either for an initial request
from a UA, or an in-call routing by the Proxy server in the from a UA, or an in-call routing by the Proxy server in the
originating network, or possibly by an ESRP. originating network, or possibly by an ESRP.
o ESRP - The emergency services routing proxy server that is the o ESRP - The emergency services routing proxy server that is the
incoming call proxy in the emergency services domain. The ESRP incoming call proxy in the emergency services domain. The ESRP
skipping to change at page 10, line 16 skipping to change at page 11, line 16
Generally, Alice's UA either has location configured manually, has an Generally, Alice's UA either has location configured manually, has an
integral location measurement mechanism, or it runs a LCP [M1] to integral location measurement mechanism, or it runs a LCP [M1] to
obtain location from the access (broadband) network. For most obtain location from the access (broadband) network. For most
devices, a LCP will be used, for example a DHCPREQUEST message or devices, a LCP will be used, for example a DHCPREQUEST message or
another location acquisition mechanism. Alice's UA then will most another location acquisition mechanism. Alice's UA then will most
likely register [M2] with a SIP domain. This allows her to be likely register [M2] with a SIP domain. This allows her to be
contacted by other SIP entities. Next, her UA will perform an contacted by other SIP entities. Next, her UA will perform an
initial LoST query [M3] to learn a URI for use if the LoST query initial LoST query [M3] to learn a URI for use if the LoST query
fails during an emergency call, or to use to test the emergency call fails during an emergency call, or to use to test the emergency call
mechanism. The LoST response may contain the dial string for mechanism. The LoST response contains the dial string for emergency
emergency calls appropriate for the location provided. calls appropriate for the location provided.
At some time after her device has booted, Alice initiates an At some time after her device has booted, Alice initiates an
emergency call. She may do this by dialing an emergency dial string emergency call. She may do this by dialing an emergency dial string
valid for her current ("local") location, or for her "home" location. valid for her current ("local") location, or for her "home" location.
The UA recognizes the dial string. The UA attempts to refresh its The UA recognizes the dial string. The UA attempts to refresh its
location [M4], and with that location, to refresh the LoST mapping location [M4], and with that location, to refresh the LoST mapping
[M5], in order to get the most accurate information to use for [M5], in order to get the most accurate information to use for
routing the call. If the location request or the LoST request fails, routing the call. If the location request or the LoST request fails,
or takes too long, the UA uses values it has cached. or takes too long, the UA uses values it has cached.
skipping to change at page 12, line 10 skipping to change at page 13, line 10
For devices that are mobile or nomadic, an issue arises of whether For devices that are mobile or nomadic, an issue arises of whether
the home or visited dial strings should be used. Many users would the home or visited dial strings should be used. Many users would
prefer that their home dialing sequences work no matter where they prefer that their home dialing sequences work no matter where they
are. However, local laws and regulations may require the visited are. However, local laws and regulations may require the visited
dialing sequence(s) work. Therefore, the visited dial string must dialing sequence(s) work. Therefore, the visited dial string must
work. Devices must allow at least the configuration of the home work. Devices must allow at least the configuration of the home
country, from which a home dial string can be determined. country, from which a home dial string can be determined.
The mechanism for obtaining the dialing sequences for a given The mechanism for obtaining the dialing sequences for a given
location is provided by LoST [I-D.ietf-ecrit-lost]. Lost servers location is provided by LoST [RFC5222]. Lost servers must return
must return dial strings for emergency services. If the endpoint dial strings for emergency services. If the endpoint does not
does not support the translation of dial strings to telephone support the translation of dial strings to telephone numbers, the
numbers, the dialing sequence is represented as a dial string dialing sequence is represented as a dial string [RFC4967] and the
[RFC4967] and the outgoing proxy has to recognize the dial string and outgoing proxy has to recognize the dial string and translate to the
translate to the service URN. To determine the local emergency dial service URN. To determine the local emergency dial string, the proxy
string, the proxy needs the location of the endpoint. This may be needs the location of the endpoint. This may be difficult in
difficult in situations where the user can roam or be nomadic. situations where the user can roam or be nomadic. Endpoint
Endpoint recognition of emergency dial strings is therefore recognition of emergency dial strings is therefore preferred. If a
preferred. If a service provider is unable to guarantee that it can service provider is unable to guarantee that it can correctly
correctly determine local emergency dialstrings, wherever its determine local emergency dialstrings, wherever its subscribers may
subscribers may be, then it is required that the endpoint do the be, then it is required that the endpoint do the recognition.
recognition.
Note: It is undesirable to have a single button emergency call user Note: It is undesirable to have a single button emergency call user
interface element. These mechanisms tend to result in a very high interface element. These mechanisms tend to result in a very high
rate of false or accidental emergency calls. In order to minimize rate of false or accidental emergency calls. In order to minimize
this rate, devices should only initiate emergency calls based on this rate, devices should only initiate emergency calls based on
entry of specific emergency call dial strings. Speed dial mechanisms entry of specific emergency call dial strings. Speed dial mechanisms
may effectively create single button emergency call invocation and may effectively create single button emergency call invocation and
should not be permitted. should not be permitted.
6. Location and its role in an emergency call 6. Location and its role in an emergency call
skipping to change at page 13, line 24 skipping to change at page 14, line 23
Routing to the most appropriate PSAP is always calculated on the Routing to the most appropriate PSAP is always calculated on the
location of the caller, despite the fact that some emergency calls location of the caller, despite the fact that some emergency calls
are placed on behalf of someone else, and the location of the are placed on behalf of someone else, and the location of the
incident is sometimes not the location of the caller. In some cases, incident is sometimes not the location of the caller. In some cases,
there are other factors that enter into the choice of the PSAP that there are other factors that enter into the choice of the PSAP that
gets the call, such as time of day, caller media requests and gets the call, such as time of day, caller media requests and
language preference, call load, etc. However, location of the caller language preference, call load, etc. However, location of the caller
is the primary input to the routing decision. is the primary input to the routing decision.
Routing is but one of two uses for location in an emergency call. Location is used for two purposes in emergency call handling: routing
The other is for dispatch of a responder, which must be very precise. of the call and dispatch of responders. Many mechanisms used to
Many mechanisms used to locate a caller have a relatively long "cold locate a caller have a relatively long "cold start" time. To get a
start" time. To get a location accurate enough for dispatch may take location accurate enough for dispatch may take as much as 30 seconds.
as much as 30 seconds. This is too long to wait for emergencies. This is too long to wait for emergencies. Accordingly, it is common,
Accordingly, it is common, especially in mobile systems, to use a especially in mobile systems, to use a coarse location, for example,
coarse location, for example, the cell site and sector serving the the cell site and sector serving the call, for call routing purposes,
call, for call routing purposes, and then to update the location when and then to update the location when a more precise value is known
a more precise value is known prior to dispatch. In this document we prior to dispatch. In this document we use "routing location" and
use "routing location" and "dispatch location" when the distinction "dispatch location" when the distinction matters.
matters.
Accuracy of dispatch location is sometimes determined by local Accuracy of dispatch location is sometimes determined by local
regulation, and is constrained by available technology. The actual regulation, and is constrained by available technology. The actual
requirement exceeds available technology. It is required that a requirement exceeds available technology. It is required that a
device making an emergency call close to the "demising" or separation device making an emergency call close to the "demising" or separation
wall between two apartments in a high rise apartment building report wall between two apartments in a high rise apartment building report
location with sufficient accuracy to determine on what side of the location with sufficient accuracy to determine on what side of the
wall it is on. This implies perhaps a 3 cm accuracy requirement. As wall it is on. This implies perhaps a 3 cm accuracy requirement. As
of the date of this memo, typical assisted GPS uncertainty with 95% of the date of this memo, typical assisted GPS uncertainty with 95%
confidence is 100 m. As technology advances, the accuracy confidence is 100 m. As technology advances, the accuracy
skipping to change at page 15, line 21 skipping to change at page 16, line 21
calls originating from that tower/sector, and routing decisions calls originating from that tower/sector, and routing decisions
are made on that point. Cell/sector information could also be are made on that point. Cell/sector information could also be
represented as an irregularly shaped polygon of geospatial represented as an irregularly shaped polygon of geospatial
coordinates reflecting the likely geospatial location of the coordinates reflecting the likely geospatial location of the
mobile device. Whatever representation is used must route mobile device. Whatever representation is used must route
correctly in the LoST database, where "correct" is determined by correctly in the LoST database, where "correct" is determined by
local PSAP management. local PSAP management.
In IETF protocols, both civic and geospatial forms are supported. In IETF protocols, both civic and geospatial forms are supported.
The civic forms include both postal and jurisdictional fields. A The civic forms include both postal and jurisdictional fields. A
cell tower/sector can be represented as a point (geo or civic) or cell tower/sector can be represented as a geo point or polygon or
polygon. Other forms of location representation must be mapped into civic location. Other forms of location representation must be
either a geo or civic for use in emergency calls. mapped into either a geo or civic for use in emergency calls.
For emergency call purposes, conversion of location information from For emergency call purposes, conversion of location information from
civic to geo or vice versa prior to conveyance is not desirable. The civic to geo or vice versa prior to conveyance is not desirable. The
location should be sent in the form it was determined. Conversion location should be sent in the form it was determined. Conversion
between geo and civic requires a database. Where PSAPs need to between geo and civic requires a database. Where PSAPs need to
convert from whatever form they receive to another for responder convert from whatever form they receive to another for responder
purposes, they have a suitable database. However, if a conversion is purposes, they have a suitable database. However, if a conversion is
done before the PSAP's, and the database used is not exactly the same done before the PSAP's, and the database used is not exactly the same
one the PSAP uses, the double conversion has a high probability of one the PSAP uses, the double conversion has a high probability of
introducing an error. introducing an error.
skipping to change at page 20, line 38 skipping to change at page 21, line 38
at network attachment time and retained by the device. It should be at network attachment time and retained by the device. It should be
refreshed when the cached value expires. For example, if DHCP is the refreshed when the cached value expires. For example, if DHCP is the
acquisition protocol, refresh of location may occur when the IP acquisition protocol, refresh of location may occur when the IP
address lease is renewed. At the time of an emergency call, the address lease is renewed. At the time of an emergency call, the
location should be refreshed, with the retained location used if the location should be refreshed, with the retained location used if the
location acquisition does not immediately return a value. Mobile location acquisition does not immediately return a value. Mobile
devices may determine location at network attachment time and devices may determine location at network attachment time and
periodically thereafter as a backup in case location determination at periodically thereafter as a backup in case location determination at
the time of call does not work. Mobile device location may be the time of call does not work. Mobile device location may be
refreshed when a TTL expires or the device moves beyond some refreshed when a TTL expires or the device moves beyond some
boundaries (as provided by [I-D.ietf-ecrit-lost]). Normally, mobile boundaries (as provided by [RFC5222]). Normally, mobile devices will
devices will acquire its location at call time for use in an acquire its location at call time for use in an emergency call
emergency call routing. See Section 6.8 for a further discussion on routing. See Section 6.8 for a further discussion on location
location updates for dispatch location. updates for dispatch location.
There are many examples of end devices which are applications running There are many examples of end devices which are applications running
on a more general purpose device, such as a personal computer. In on a more general purpose device, such as a personal computer. In
some circumstances, it is not possible for application programs to some circumstances, it is not possible for application programs to
access the network device at a level necessary to implement the LLDP- access the network device at a level necessary to implement the LLDP-
MED protocol, and in other cases, obtaining location via DHCP may be MED protocol, and in other cases, obtaining location via DHCP may be
impossible. In any case it is desirable for an operating system impossible. In any case it is desirable for an operating system
which could be used for any application which could make emergency which could be used for any application which could make emergency
calls to have an API which provides the location of the device for calls to have an API which provides the location of the device for
use by any application. use by any application.
skipping to change at page 23, line 21 skipping to change at page 24, line 21
information is particularly harmful if different routes (PSAPs) information is particularly harmful if different routes (PSAPs)
result from LoST queries for the multiple locations. When they occur result from LoST queries for the multiple locations. When they occur
anyway, the general guidance is that the entity earliest in the chain anyway, the general guidance is that the entity earliest in the chain
generally has more knowledge than later elements to make an generally has more knowledge than later elements to make an
intelligent decision, especially about which location will be used intelligent decision, especially about which location will be used
for routing. It is permissible to send multiple locations towards for routing. It is permissible to send multiple locations towards
the PSAP, but the element that chooses the route must select one (and the PSAP, but the element that chooses the route must select one (and
only one) location to use with LoST. only one) location to use with LoST.
Guidelines for dealing with multiple locations are also given in Guidelines for dealing with multiple locations are also given in
[I-D.ietf-ecrit-lost]. If a UA gets multiple locations, it must [RFC5222]. If a UA gets multiple locations, it must choose the one
choose the one to use for routing, but it may send all of the to use for routing, but it may send all of the locations it has in
locations it has in the signaling. If a proxy is inserting location the signaling. If a proxy is inserting location and has multiple
and has multiple locations, it must choose the one to use to route locations, it must choose the one to use to route and send any others
and send any others it has. it has.
The UA or proxy should have the ability to understand how and from The UA or proxy should have the ability to understand how and from
whom it learned its location, and should include this information in whom it learned its location, and should include this information in
the location objects that are sent to the PSAP. That labeling the location objects that are sent to the PSAP. That labeling
provides the call-taker with many pieces of information to make provides the call-taker with many pieces of information to make
decisions upon, as well as guidance for what to ask the caller and decisions upon, as well as guidance for what to ask the caller and
what to tell the responders. what to tell the responders.
The call must indicate the location information that has been used The call must indicate the location information that has been used
for routing, so that the same location information is used for all for routing, so that the same location information is used for all
call routing decisions. The location conveyance mechanism call routing decisions. The location conveyance mechanism
[I-D.ietf-sip-location-conveyance] contains a parameter for this [I-D.ietf-sip-location-conveyance] contains a parameter for this
purpose. purpose.
An entity may also recieve multiple versions of the same location.
For example a database may be used to "geocode" or "reverse geocode",
that is, convert from civic to geo or vice versa. It is very
problematic to use derived locations in emergency calls. The PSAP
and the responders have very accurate databases which they use to
convert, most commonly from a reported geo to a civic suitable for
dispatching responders. If one database is used to convert from,
say, civic to geo, and another converts from geo to civic, errors
will often occur where the databases are slightly different. "Off by
one" errors are serious when responders go to the wrong location.
Derived locations should be marked with a "derived" method token
[RFC4119]. If an entity gets a location which has a measured or
other original method, and another with a derived method, it must use
the original value for the emergency call.
6.10. Location validation 6.10. Location validation
It is recommended that location be validated prior to a device It is recommended that location be validated prior to a device
placing an actual emergency call; some jurisdictions require that placing an actual emergency call; some jurisdictions require that
this be done. Validation in this context means both that there is a this be done. Validation in this context means both that there is a
mapping from the address to a PSAP and that the PSAP understands how mapping from the address to a PSAP and that the PSAP understands how
to direct responders to the location. Determining the addresses that to direct responders to the location. Determining the addresses that
are valid can be difficult. There are, for example, many cases of are valid can be difficult. There are, for example, many cases of
two names for the same street, or two streets with the same name in a two names for the same street, or two streets with the same name in a
city. In some countries, the current system provides validation. city. In some countries, the current system provides validation.
For example, in the United States, the Master Street Address Guide For example, in the United States, the Master Street Address Guide
(MSAG) records all valid street addresses and is used to ensure that (MSAG) records all valid street addresses and is used to ensure that
the service addresses in phone billing records correspond to valid the service addresses in phone billing records correspond to valid
emergency service street addresses. Validation is normally a concern emergency service street addresses. Validation is normally a concern
for civic addresses, although there could be a concern that a given for civic addresses, although there could be a concern that a given
geo is within at least one PSAP service boundary; that is, a "valid" geo is within at least one PSAP service boundary; that is, a "valid"
geo is one where there is a mapping. geo is one where there is a mapping.
LoST [I-D.ietf-ecrit-lost] includes a location validation function. LoST [RFC5222] includes a location validation function. Validation
Validation is normally performed when a location is entered into a is normally performed when a location is entered into a Location
Location Information Server. It should be confirmed periodically, Information Server. It should be confirmed periodically, because the
because the mapping database undergoes slow change; new streets are mapping database undergoes slow change; new streets are added or
added or removed, community names change, postal codes change, etc. removed, community names change, postal codes change, etc. Endpoints
Endpoints may wish to validate locations they receive from the access may wish to validate locations they receive from the access network,
network, and will need to validate manually entered locations. and will need to validate manually entered locations. Proxies that
Proxies that insert location may wish to validate locations they insert location may wish to validate locations they receive from a
receive from a LIS. When the Test functions (Section 15) are LIS. When the Test functions (Section 15) are invoked, the location
invoked, the location used should be re-validated. used should be re-validated.
When validation fails, the location given must not be used for an When validation fails, the location given must not be used for an
emergency call. If validation is complete when location is first emergency call. If validation is complete when location is first
loaded into a LIS, any problems can be found and fixed before devices loaded into a LIS, any problems can be found and fixed before devices
could get the bad location. Failure of validation arises because an could get the bad location. Failure of validation arises because an
error is made in determining the location, although occasionally the error is made in determining the location, although occasionally the
LoST database is not up to date or has faulty information. In either LoST database is not up to date or has faulty information. In either
case, the problem must be identified and corrected before using the case, the problem must be identified and corrected before using the
location. location.
skipping to change at page 25, line 4 skipping to change at page 26, line 18
6.12. Location format conversion 6.12. Location format conversion
The endpoint is responsible for mapping any form of location it The endpoint is responsible for mapping any form of location it
receives from an LCP into PIDF-LO form if the LCP did not directly receives from an LCP into PIDF-LO form if the LCP did not directly
return a PIDF. return a PIDF.
7. LIS and LoST Discovery 7. LIS and LoST Discovery
Endpoints must be able to discover a LIS (if the HELD protocol is Endpoints must be able to discover a LIS (if the HELD protocol is
used), and a LoST server. DHCP options are defined for this purpose used), and a LoST server. DHCP options are defined for this purpose
[I-D.ietf-geopriv-lis-discovery] and [I-D.ietf-geopriv-lis-discovery] and [RFC5223]
[I-D.ietf-ecrit-dhc-lost-discovery]
Until such DHCP records are widely available, it may be necessary for Until such DHCP records are widely available, it may be necessary for
the service provider to provision a LoST server address in the the service provider to provision a LoST server address in the
device. The endpoint can also do an SRV query within its SIP domain device. The endpoint can also do an SRV query within its SIP domain
to find a LoST server. In any environment, more than one of these to find a LoST server. In any environment, more than one of these
mechanisms may yield a LoST server, and they may be differernt. The mechanisms may yield a LoST server, and they may be differernt. The
recommended priority is DHCP first, provisioned value second, and SRV recommended priority is DHCP first, provisioned value second, and SRV
query in the SIP domain third. query in the SIP domain third.
8. Routing the call to the PSAP 8. Routing the call to the PSAP
skipping to change at page 25, line 47 skipping to change at page 27, line 16
for specific caller media preferences, such as typed text or for specific caller media preferences, such as typed text or
video, are separate from PSAPs serving voice calls. ESRPs are video, are separate from PSAPs serving voice calls. ESRPs are
expected to be able to provide routing based on media. Also, even expected to be able to provide routing based on media. Also, even
if media capability does not affect the selection of the PSAP, if media capability does not affect the selection of the PSAP,
there may be call takers within the PSAP that are specifically there may be call takers within the PSAP that are specifically
trained, e.g., in interactive text or sign language trained, e.g., in interactive text or sign language
communications, where routing within the PSAP based on the media communications, where routing within the PSAP based on the media
offer would be provided. offer would be provided.
Routing for calls by location and by service is the primary function Routing for calls by location and by service is the primary function
LoST [I-D.ietf-ecrit-lost] provides. LoST accepts a query with LoST [RFC5222] provides. LoST accepts a query with location (by-
location (by-value) in either civic or geospatial form, plus a value) in either civic or geospatial form, plus a service identifier,
service identifier, and returns a URI (or set of URIs) to route the and returns a URI (or set of URIs) to route the call to. Normal SIP
call to. Normal SIP [RFC3261] routing functions are used to resolve [RFC3261] routing functions are used to resolve the URI to a next hop
the URI to a next hop destination. destination.
The endpoint can complete the LoST mapping from its location at boot The endpoint can complete the LoST mapping from its location at boot
time, and periodically thereafter. It should attempt to obtain a time, and periodically thereafter. It should attempt to obtain a
"fresh" location, and from that a current mapping when it places an "fresh" location, and from that a current mapping when it places an
emergency call. If accessing either its location acquisition or emergency call. If accessing either its location acquisition or
mapping functions fail, it should use its cached value. The call mapping functions fail, it should use its cached value. The call
would follow its normal outbound call processing. would follow its normal outbound call processing.
Determining when the device leaves the area provided by the LoST Determining when the device leaves the area provided by the LoST
service can tax small mobile devices. For this reason, the LoST service can tax small mobile devices. For this reason, the LoST
skipping to change at page 27, line 49 skipping to change at page 29, line 17
path. Confidentiality mechanisms such as S/MIME encryption of SIP path. Confidentiality mechanisms such as S/MIME encryption of SIP
signaling [RFC3261] cannot be used because they obscure location. signaling [RFC3261] cannot be used because they obscure location.
Only hop-by-hop mechanisms such as TLS should be used. Many SIP Only hop-by-hop mechanisms such as TLS should be used. Many SIP
devices do not support TLS. Implementing location conveyance in SIP devices do not support TLS. Implementing location conveyance in SIP
mandates inclusion of TLS support. mandates inclusion of TLS support.
9.2. SIP signaling requirements for User Agents 9.2. SIP signaling requirements for User Agents
SIP UAs that do local dial string interpretation, location, and SIP UAs that do local dial string interpretation, location, and
emergency call route will create SIP INVITE messages with the Service emergency call route will create SIP INVITE messages with the Service
URN in the Request URI, the LoST-determined URI for the PSAP in a URN in the Request URI and To header, the LoST-determined URI for the
Route header, and the location in a Geolocation header. The INVITE PSAP in a Route header, and the location in a Geolocation header.
request must also have appropriate call back identifiers. To enable The INVITE request must also have appropriate call back identifiers.
media sensitive routing, the call should include an SDP offer. To enable media sensitive routing, the call should include an SDP
offer.
9.3. SIP signaling requirements for proxy servers 9.3. SIP signaling requirements for proxy servers
SIP proxy servers in the path of an emergency call must be able to SIP proxy servers in the path of an emergency call must be able to
assist UAs that are unable to provide any of the location based assist UAs that are unable to provide any of the location based
routing steps and recognition of dial strings. They are also routing steps and recognition of dial strings. They are also
expected to provide identity information for the caller. expected to provide identity information for the caller.
10. Call backs 10. Call backs
skipping to change at page 31, line 21 skipping to change at page 32, line 33
Design Team members participating in this draft creation include Design Team members participating in this draft creation include
Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger Hannes Tschofenig, Ted Hardie, Martin Dolly, Marc Linsner, Roger
Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further Marshall, Stu Goldman, Shida Schubert and Tom Taylor. Further
comments and input were provided by Richard Barnes, Barbara Stark and comments and input were provided by Richard Barnes, Barbara Stark and
James Winterbottom. James Winterbottom.
19. Informative References 19. Informative References
[I-D.barnes-geopriv-lo-sec] [I-D.barnes-geopriv-lo-sec]
Barnes, R., Lepinski, M., Tschofenig, H., and H. Barnes, R., Lepinski, M., Tschofenig, H., and H.
Schulzrinne, "Security Requirements for the Geopriv Schulzrinne, "Additional Location Privacy Considerations",
Location System", draft-barnes-geopriv-lo-sec-02 (work in draft-barnes-geopriv-lo-sec-03 (work in progress),
progress), February 2008. July 2008.
[I-D.ietf-ecrit-dhc-lost-discovery]
Schulzrinne, H., Polk, J., and H. Tschofenig, "A Dynamic
Host Configuration Protocol (DHCP) based Location-to-
Service Translation Protocol (LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-03 (work in progress),
May 2008.
[I-D.ietf-ecrit-lost]
Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", draft-ietf-ecrit-lost-10 (work in progress),
May 2008.
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-04 (work in progress), draft-ietf-ecrit-phonebcp-06 (work in progress),
February 2008. 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-08 (work in draft-ietf-geopriv-http-location-delivery-11 (work in
progress), July 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-01 (work in progress), draft-ietf-geopriv-lis-discovery-05 (work in progress),
June 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-11 Recommendations", draft-ietf-geopriv-pdif-lo-profile-14
(work in progress), February 2008. (work in progress), November 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-10 (work in progress), draft-ietf-sip-location-conveyance-12 (work in progress),
February 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-15 (work in progress), June 2008. draft-ietf-sip-outbound-16 (work in progress),
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.
[I-D.ietf-sipping-service-examples] [I-D.ietf-sipping-service-examples]
Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
K. Summers, "Session Initiation Protocol Service K. Summers, "Session Initiation Protocol Service
Examples", draft-ietf-sipping-service-examples-14 (work in Examples", draft-ietf-sipping-service-examples-15 (work in
progress), February 2008. progress), July 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".
[NENAi3TRD] [NENAi3TRD]
NENA, "08-751 NENA i3 Technical Requirements for", 2006. NENA, "08-751 NENA i3 Technical Requirements for", 2006.
skipping to change at page 35, line 9 skipping to change at page 36, line 11
January 2008. January 2008.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
Format for Presence Information Data Format Location Format for Presence Information Data Format Location
Object (PIDF-LO)", RFC 5139, February 2008. Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
August 2008.
[WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of [WGS84] NIMA, "NIMA Technical Report TR8350.2, Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems, Third Edition", Relationships With Local Geodetic Systems, Third Edition",
July 1997. July 1997.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc. NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
skipping to change at page 35, line 34 skipping to change at page 37, line 4
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7042 Phone: +1 212 939 7042
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
James Polk James Polk
Cisco Systems Cisco Systems
3913 Treemont Circle 3913 Treemont Circle
Colleyville, Texas 76034 Colleyville, Texas 76034
US US
Phone: +1-817-271-3552 Phone: +1-817-271-3552
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Andrew Newton Andrew Newton
TranTech/MediaSolv TranTech/MediaSolv
4900 Seminary Road 4900 Seminary Road
Alexandria, VA 22311 Alexandria, VA 22311
US US
Phone: +1 703 845 0656 Phone: +1 703 845 0656
Email: andy@hxr.us Email: andy@hxr.us
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. 37 change blocks. 
156 lines changed or deleted 174 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/