ECRIT Working Group James Polk Internet-Draft Cisco Systems Expires: Sept 6th, 2006 Andrew Newton VeriSign March 6th, 2006 Emergency Context Routing of Internet Technologies Architecture Considerations draft-polk-newton-ecrit-arch-considerations-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6th, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses architectural considerations for emergency context routing of Internet technologies. The purpose of this document is to provide a systemic view of emergency context routing, discuss unresolved issues, and explain the relationship of some of the proposals to these issues, while discussing potential directions that might be still be necessary for the working group to investigate. Polk & Newton Expires Sept 6th, 2006 [Page 1] Internet-Draft ECRIT Arch Considerations Mar 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Division of Labor . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology, Acronyms and Definitions . . . . . . . . . . 4 2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. LCMS Mapping . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Conveyance . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Location Conveyance . . . . . . . . . . . . . . . . . . . 8 5.2 Identity Conveyance . . . . . . . . . . . . . . . . . . . 8 6. Universal Emergency Identifiers . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1 Security of the LCMS . . . . . . . . . . . . . . . . . . 10 7.2 Security of Location Conveyance . . . . . . . . . . . . . 11 7.3 Security of Bootstrapping . . . . . . . . . . . . . . . . 11 7.4 Security of Conversion . . . . . . . . . . . . . . . . . 11 8. Data distribution . . . . . . . . . . . . . . . . . . . . . . 12 9. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Conflation . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Rerouting/Transfer . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1 Normative References . . . . . . . . . . . . . . . . . . 14 13.2 Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 A. Appendix A. Additional stuff . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . 15 1. Introduction The solution to proper emergency call identification, management and routing over the Internet involves many components and coordination between them. This document describes the necessary interaction between these components. The information given in this document may not be complete, and some of the issues presented in this document may not be resolved by the community. The intent of this document is to describe a "big picture" view of the process, describe prevailing thoughts on this subject and describe unresolved issues in hopes of bringing about consensus within the community on these topics. The current architecture of Emergency Context Routing of Internet Technologies is composed of the following: Bootstrapping: delivery of configuration and location information to the client at or near power-up time. Conversion: conversion of location information into forms usable in mapping and conveyance, if necessary. Polk & Newton Expires Sept 6th, 2006 [Page 2] Internet-Draft ECRIT Arch Considerations Mar 2006 LCMS Mapping: conversion of endsystem location information into addresses usable to initiate or progress communication towards an emergency call center (a PSAP). Conveyance: delivery of endsystem location information to an emergency call center during the emergency call (used for first responder dispatch). There are many unresolved issues regarding these steps and related matters. The following list is not exhaustive, but includes most of the issues brought grouping discussions to date (and a few new ones). Universal emergency identifier: there needs to be a universal emergency identifier to prevent highly localized usage and confusion by users and systems of what applies to a certain region, and what does not. Security: the security properties necessary for the proper protection of LCMS data are not well understood. Data distribution: the distribution of LCMS data closer to the points of queries within the Internet. Extensibility: the methods for extensibility in all components of the system must be well understood. Conflation: many of the components proposed for use in the routing of emergency calls have other uses and most have not been primarily designed for the emergency call routing case. 1.1 Division of Labor As stated above, not all of the components used in the process of routing an emergency call to the correct emergency call center over the Internet have been defined for the exclusive use of this case, and therefore not all of the specification work is being conducted within the scope of the charter of the ECRIT working group. Bootstrapping of location information, both geospatial and civic, via DHCP is work in progress in the GEOPRIV working group. Bootstrapping of URI references via DHCP is work in progress in the DHC working group. The definition of location objects and the use of schemas to describe location is work in progress in the GEOPRIV working group. The specification of conveyance of location objects via SIP is work in progress in the SIP working group. The mapping of location information to URIs is the primary function of the ECRIT working group. The set of mechanisms and services Polk & Newton Expires Sept 6th, 2006 [Page 3] Internet-Draft ECRIT Arch Considerations Mar 2006 working in conjunction with each other to conduct this mapping is referred to as the Location Context Mapping System, or LCMS by this document for the purposes of clarity. 1.2 Terminology, Acronyms and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. The following terms and definitions will be used throughout this document: Application (Layer) Provider (ALP) - provider of application level services such as a voice over IP service that is completely divorced from the Link provider, and may be divorced from the Internet Attachment Provider of an endsystem that is merely providing a layer 3 connectivity service. ALP - Application (Layer) Provider Emergency Services Gateway (ESGW) - The special IP to circuit- switched gateway that front-ends an emergency services Selective Router (SR) (which directs all TDM based 911/112 type calls to the appropriate PSAP within a given physical region) Emergency Services Routing Proxy (ESRP) - a special instance of a SIP Proxy that understands emergency routing of messages identified as emergency messages to a PSAP based on the location of the caller that is included in the message ESGW - Emergency Services Gateway ESRP - Emergency Services Routing Proxy IAP - Internet Attachment Provider Internet Attachment Provider (IAP) - typically the organization that provides Internet or IP access to the client (i.e. assigns the client an IP address and/or provides the client with IP transit. Location Context Mapping System – A set of coordinated mechanisms and services that map a physical location (geospatial or civic) to a network address. LCMS – Location Context Mapping System LIS - Location Information Server PSAP - Public Safety Answering Point Polk & Newton Expires Sept 6th, 2006 [Page 4] Internet-Draft ECRIT Arch Considerations Mar 2006 Location Information Server (LIS) – Provides a mapping function to relate unique identifiers for IP devices at physical network access points and the geographic descriptions of their location (e.g., civic location/street addresses or geographic coordinates). Responds to queries for location information. Public Safety Answering Point (PSAP) - the emergency response call center talking the local emergency calls from people in distress. This facility can be logical, and can transfer (reroute) any request sent to it to another facility deemed more appropriate to receive the request. 2. Bootstrapping Bootstrapping delivers configuration information to the client. The most obvious use of bootstrapping is for an endsystem to ask for and receive its IP address, Subnet Mask and Default Gateway addresses. This could also be used to deliver the geospatial or civic address of the client to it for future use. This is typically done at device or individual application boot times. Unlike other parts of the architecture, bootstrapping is the only phase of the emergency call routing process that does not have a single solution. This is due to the many network configuration techniques used by access networks. There are three well-known methods of bootstrapping: 1. Using the DHCP protocol 2. Using the PPP protocol 3. Using IEEE 802.1 LLDP-MED For location information, there are two types: location information regarding a civic address (e.g. 123 Main St ) and geospatial information (e.g. x, y, z coordinates). The set of configuration data types has not been discussed or resolved. But the following types of configuration information have been noted: 1) references to LCMS servers, 2) references to PSAPs, and 3) references to location information servers. References to LCMS servers obviate the need for global hierarchies of LCMS data directories (which have proven politically difficult in other voice over IP matters) and reduce the coordination to only the necessary jurisdictional boundaries. References to PSAPs obviate the need for the mapping steps in cases where location is not likely to be a determining factor in emergency call routing (e.g. location is fixed and the emergency call center is known). References to location information servers enable better separation Polk & Newton Expires Sept 6th, 2006 [Page 5] Internet-Draft ECRIT Arch Considerations Mar 2006 for knowledge of location from the access network. 3. Conversion Conversion of location information from one format to the other format is conducted for the benefit of the LCMS servers and conveyance of the location information. There are two aspects to this conversion: syntactic conversion of the location information from the binary formats used in bootstrapping to the XML format used in PIDF-LO, and conversion of the civic location information to geospatial location information or vice versa. Syntactic conversion is a necessary function, and it can take two different forms: conversion from the binary DHCP format to the PIDF-LO conveyance format and conversion to a LCMS format if the LCMS interface does not use PIDF-LO. Conversion of location information from a civic address to geospatial coordinates or from geospatial coordinates to a civic address is much more controversial. There is no doubt that civic addresses are much easier to consume by humans than geospatial coordinates, however conversion from geospatial coordinates to a civic address can be error prone and in cases involving large areas (e.g. a farm, an outdoor park, etc…) the resulting civic address can be of limited utility. Further, civic coordinates only address a fraction of the land of this planet, as civic addresses are to a great degree tied to the existence of a nearby street, which are prevalent in cities, but are scarce to non-existent in rural areas. Therefore, a combination of the two formats will be required regardless of mankind's consumption preference. 4. LCMS Mapping The creation of an LCMS, which will convert location information into references (i.e. URIs) to emergency call centers, is the primary area of work for the ECRIT working group. There are two times in which this LCMS function can occur successfully: 1. before the device attempts contact with a PSAP, and 2. after the device initiates contact with the PSAP, but before the correct PSAP is determined by the ESRP making the LCMS query. Accomplishing mapping of a device's location with the proper PSAP can be done statically or dynamically, or in a layered - combination - approach. Statically - If a site is small enough, for example residential or Small or single building business scale, all devices in either of these types of locations can be configured to download, or have Polk & Newton Expires Sept 6th, 2006 [Page 6] Internet-Draft ECRIT Arch Considerations Mar 2006 downloaded to them, their location information and the SIP or SIPS URI for contacting the appropriate PSAP for that location. Dynamically - for the above types of locations, or for larger locations, the client's location can be used to "look up" the appropriate PSAP SIP or SIPS URI, and have this configuration information downloaded to each client requesting it. This can also be pushed to all clients regardless of whether they asked for the information or not. This pushing of the PSAP URI(s) can be at some interval to maintain freshness of the URI(s), as stale URI(s) are a concern to some. For the static configuration, for each given endpoint or section of a network, a known PSAP SIP or SIPS URI is downloaded to the client(s) without the clients providing their individual location to perform the LCMS function. In the case of dynamic configuration of a URI, the client provides their location to an LCMS server to do this look-up, with the answer sent to the client for future use by any application on that client, including for emergency services. In a layered approach, there does not need to be a one-size-fits-all solution, but a combination of ways in which the mapping resolution is accomplished towards the goal of having the emergency call set-up reach the appropriate PSAP. For example, a solution with the most risk can be used last, but in a way it does not rely on any other steps to have occurred to function properly. In this scenario, the simplest means of mapping with the least risk can be performed initially, before the device ever knows it will generate an emergency call set-up message. In this way, this first mechanism is done at boot-time, and the mapping during the actual emergency call can still happen whether or not the bootstrapping took place or not. This layered approach would be with a goal of solving the function of mapping one of the independent steps towards entering the appropriate PSAP SIP or SIPS URI into the INVITE message. When this URI is learned should not matter, as long as it is the appropriate URI. Another combined approach can be attained in the following scenario: if the endsystem knows of an authoritative LCMS server regardless of which network or domain the client is connected to, the endsystem can contact this server to get its PSAP SIP/SIPS URI based on its location provided by the local access network. In this scenario, an endsystem can have a trust association established with a particular server (or server service) that it contacts as soon as it either learns its location from a local network/domain or somehow determines it has moved while remaining "connected" to that network/domain. For the device configuration of a PSAP SIP or SIPS URI, currently only DHCP is being proposed as a solution [ID-DHCP-URI]. This proposal is not an LCMS function because it does not send location to a server and receive the mapping answer containing a URI. DHCP Polk & Newton Expires Sept 6th, 2006 [Page 7] Internet-Draft ECRIT Arch Considerations Mar 2006 is used here to only deliver the URI to be used as the Request-URI of the emergency SIP INVITE. To date there are three protocol proposals for LCMS: LUMP, ECON, and DNS SOS. LUMP is an XML-based, SOAP solution with emphasis on data distribution. ECON is an XML-based, IRIS solution with emphasis on lightweight data exchange, and DNS SOS is a DNS-based solution with emphasis on re-using DNS semantics. Finally, some jurisdictions may find it necessary to withdraw the LCMS protocol from public view and place its function within an ESRP. At the option of the jurisdiction, more than one ESRP function may be implemented in series, to provide increasingly precise routing to the appropriate PSAP. 5. Conveyance 5.1 Location Conveyance Once the address of the PSAP is known, either through bootstrapping or through LCMS mapping, a call can be initiated with the PSAP. Location information is sent to the PSAP as meta-data of the call using PIDF-LO. This facet is not part of the ECRIT WG, but cannot be overlooked. Even if the caller contacts the appropriate PSAP, that PSAP will still require knowledge of where the caller is in order to dispatch emergency responders (i.e. help). Issues regarding the acquisition of this knowledge are discussed in Section 7.2. Passing location information within the voice application protocol is commonly referred to as "location-by-value". There exists another concept where a reference to a location server is passed within the voice application protocol instead of the actual location information. This is known a "location-by-reference". Location-by- reference is not without controversy, and its plusses and minuses will be discussed in a future version of this document. 5.2 Identity Conveyance There is a general desire on behalf of PSAP operators to have the identity of a caller conveyed within a call. This identity has two parts: an identity asserted to be authentic and a call-back reference for re-establishment of communications. Of the two parts of this identity conveyance, the authentication of the identity is the most contentious and burdensome to solve. For example, if a traveler with a phone purchased in London were to make an emergency phone call in New York, what trust relationship exists between the authorities of New York and a phone retailer in London? Making matters more complicated, conveyance of identity for Polk & Newton Expires Sept 6th, 2006 [Page 8] Internet-Draft ECRIT Arch Considerations Mar 2006 emergency calling is not a work item for any IETF working group. 6. Universal Emergency Identifiers Throughout the world, there are many different numbers in use to signal emergency phone calls. Some counts have this number as high as 60 unique number sequences worldwide. This lack of uniformity also leads to collision. For example, in some areas of the world, dialing the number 0 is used for calling for help, whereas in other parts of the world, this would not accomplish its intended emergency meaning, resulting in the caller being told to hang up and dial another number. Therefore, one of the ECRIT requirements is for a universal emergency identifier to signal an emergency. The need for it to be universal (or well-known) is threefold: so that all the components in the emergency call routing process may properly operate based on its presence in a message, to avoid collisions with other purposes (as stated above), and so that clients may localize its meaning to end users. The issue is that there is not just one single identifier related to emergency calls, but that there are many identifiers related to emergency calls for various specific types of emergencies. Multiple identifiers lead to confusion and many have overlapping meaning. For example, the separate identifiers "mountain" and "rescue" could mean the same thing to a user needing to be rescued from a mountainous area. Additionally, some jurisdictions have custom identifiers that are either unused globally or have a limited applicability. Each LCMS proposal takes a different approach to solving this problem. ECON takes the simplest approach, specifying a simple list of 3 identifiers. DNS SOS specifies a list of six identifiers. LUMP specifies a hierarchy of identifiers. What is not clear, or has not been well defined, is the need for even the simplest of these approaches. It is not even well understood if end users, in an emergency situation, will be able to rationalize the difference between "emergency" and a simple list of "police", "fire", and "medical". While some have suggested this is in practice in some parts of the world today, that does not necessarily mean this will become universal in usage. It appears that if there is a single master identifier with more than one sub- identifier, that this arrangement should be used where it is understood, and perhaps adopted elsewhere as jurisdictions decide to segment this capability based on education within that area. What appears obvious to avoid is to have different identifiers for help in different parts of the world moving forward. If only 'sos.police@...' reaches the police in a country where Alice does Polk & Newton Expires Sept 6th, 2006 [Page 9] Internet-Draft ECRIT Arch Considerations Mar 2006 not live when she sends a SIP INVITE to 'sos@...', ECRIT as a WG has not likely accomplished its goal. Locales that choose to have sub-identifiers for granularity must have an architected solution for the higher level identifier as well. 7. Security Considerations 7.1 Security of the LCMS It is the goal of the working group to develop a dynamic LCMS protocol that is both secure and responsive, two features that tend to conflict with each other. Security for this mapping solution has fallen into two broad categories: object signing and channel security. Object signing has three benefits: integrity of data during distribution, the potential for utilization in UDP packets, and pre- calculation of cryptographic data. However, in cases where partial matching of the query are to be allowed (i.e. parts of a civic address are to be ignored in the query) or the query cannot be known ahead of time (i.e. the whole set of geospatial coordinates is known but not in practical terms), object signing will require "on- line" signing which negates advantages in data distribution and cryptographic pre-calculations. In addition, the use case regarding the invalidity of a signed object may be no different from that of a validly signed object. Users confronted with an emergency may not be able to appreciate the difference in validity, and even if they did, may not alter their course of action (i.e. they continue with the emergency call anyway). Channel security requires expensive cryptographic calculations that cannot be computed ahead of time and requires multiple packet exchanges (i.e. roundtrips) to establish. However, this approach has the benefit of securing all parts of the transaction, and unlike object signing, is well used and well understood on the Internet. The security properties of each of the three LCMS proposals is as follows: LUMP uses both channel security (TLS connections to the query server) and object signing (signed entries in the database). DNS SOS uses both channel security (TLS in connections to fetching polygons and other information) and object signing (in DNSSEC for the protection of NAPTR records). ECON uses channel security (TLS connections to the query server) as Polk & Newton Expires Sept 6th, 2006 [Page 10] Internet-Draft ECRIT Arch Considerations Mar 2006 an option setup by the operator of the service and a lightweight UDP transfer protocol for scenarios where security is not needed. 7.2 Security of Location Conveyance There is a general desire to protect PSAPs from malicious calls. Yet, how this is to be accomplished is not clear or well defined. Complicating this issue is the simple fact that many PSAPs will accept a call without location information related to the caller. Additionally, many PSAPs give priority or parity to location information collected by a human operator from a human caller. Due to this fact, it has been observed that any security mechanism put into place by ECRIT can simply be routed around by directly contacting a PSAP. In cases where a PSAP would wish to disregard calls of unknown provenance, no guidelines have clearly been stated as to how such trust relationships would be erected. 7.3 Security of Bootstrapping Where critical decisions might be based on the value(s) of the bootstrapping process, such as a URI option from [ID-DHC-URI], DHCP authentication in [RFC3118] SHOULD be used to protect the integrity of the DHCP options. Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the client and destination DHCP server to capture any URIs in transit. When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks. All that said, if DNS is not secure, and bootstrapping is difficult to secure based on what it takes to accomplish [RFC3118], is securing the mapping service worth the effort and pain to achieve? 7.4 Security of Conversion Location is a vital part of emergency messaging. As discussed earlier, an endsystem will not likely be in control of which format of location it receives from a roamed to network. For more fixed endsystems, this should not be the case. If an endsystem does receive location in a format it knows an application on that endsystem does not prefer, the endsystem can contact a server or service, if one is known, to convert this format to the other format. Polk & Newton Expires Sept 6th, 2006 [Page 11] Internet-Draft ECRIT Arch Considerations Mar 2006 As a non-emergency example, most humans understand street addresses much better than GPS coordinates. If a roaming device, say using 802.11 at a hotspot, acquires its location via DHCP Option 123 [RFC 3825], it can determine if an application used by that device prefers the civic format when using an instant messaging application on that device. Before the IM application is launched, or as the app is launched, the device can seek a conversion server to perform this format conversion operation. How does a client learn of a server that can do this? [ID-DHC-URI] provides one means for a device to learn the URL of a server that can do this function, or this can be preconfigured in the device as a trusted source for this conversion, wherever it is - as long as there is connectivity to that trusted source. In the emergency case, perhaps the device knows it needs to convert to the civic format to have an ESRP perform an LCMS query, but the local network gave it a geospatial location only. If the conversion server is preconfigured, this provides the ability to have the two devices, say the phone and the conversion server, establish a trust relationship, perhaps with pre-shared keys. This reduces the round trip times, making it more efficient. This also provides a more secure means of communication since both entities 'know' each other. 8. Data distribution There is a desire to locate LCMS data in the LCMS close to the points of query in the Internet for performance reasons. In addition, some jurisdictions distribute authority for this data upon hierarchical lines. However, the needs for data distribution beyond these high-level requirements are not well known. For instance, the known life expectancy of data distributed to caches is not well known, nor are update procedures in the distribution of this data. Each of the three LCMS proposals addresses this problem in a different way: DNS SOS relies upon the cache machinery of DNS. The population of DNS caches with location information is accomplished through validation of caller locations (a process during provisioning of a callers location and before any emergency call). This proposal does not address early cache expiration due to limited cache memory, by accepted practices of DNS operations, or by routine maintenance of DNS servers. LUMP defines a caching mechanism that identifies objects by hash value in order to accomplish a mesh of caches between nodes. The population of the caches with location information is accomplished through validation of caller locations (a process conducted during provisioning of a callers location and before any emergency call). Polk & Newton Expires Sept 6th, 2006 [Page 12] Internet-Draft ECRIT Arch Considerations Mar 2006 ECON defines no preference for data distribution due to the limited requirements available. However, it does describe two methods that could be employed: the serialization of data to files for distribution via standard transfer protocols and an on-line, incremental approach capable of distributing entries before their activation date. 9. Extensibility Within the ECRIT working group, there appears to be rough consensus on the need for extensible mechanisms, and hence an extensible LCMS protocol capable of extensions in its query interface and resulting output. This desire for extensibility is born from a general sense that not all the problems of emergency call routing over the Internet will be fully exposed until deployment of a first generation solution and from a more specific sense of the incompleteness of the civic address schema in PIDF-LO. As an example of the more general case, the document [ID-ECRIT- JAPAN] describes a numeric address code equivalent to the civic elements through in PIDF-LO used in conjunction with geospatial coordinates to conduct emergency call handling in Japan. As an example of the more specific case, PIDF-LO does not contain an element to describe street section numbers as used in Taiwan. 10. Conflation As mentioned in the introduction, many of the components used in the process of routing emergency calls were not designed primarily for this task and are being developed in working groups that do not have emergency call routing explicitly defined in their chartered scope. As a general example, conveyance of location information within a call also has applicability to delivery businesses, such as pizza restaurants that need to know the location of the caller for delivery purposes. In a more technical sense, much of what is known about civic addresses worldwide is a result of the study of postal delivery, and therefore schemas used as location input for emergency call routing may not be tuned properly. Within the ECRIT working group, there are no requirements regarding the resilience of the emergency call routing process as it relates to inputs that have not been designed for this specific purpose. 11. Rerouting/Transfer Another facet of the ECRIT WG that has not been addressed is what to do if a PSAP receives an emergency call and the call should not have been routed to that PSAP. What does the PSAP do next, and can this Polk & Newton Expires Sept 6th, 2006 [Page 13] Internet-Draft ECRIT Arch Considerations Mar 2006 action be automated? Does the PSAP have an additional screening capability in some ESRP at the PSAP interior edge to do a final check that the call set-up is to the appropriate PSAP, taking steps not yet defined if this PSAP is not the appropriate one for this particular call set-up? This is more a rerouting function of the call set-up, or of a call transfer function if the call is answered before determining this is an inappropriate PSAP. For example, VPNs will likely cause some emergency calls to go erroneously to the city that the caller's corporate offices are located in rather than to where the caller is. This has not been considered to date, yet likely should be - as message reroute should be possible anytime an ESRP misdirects a message towards a PSAP, just not he appropriate PSAP. 12. Acknowledgements Nadine Abbott provided text regarding ESRP usage and comments regarding the inclusion of discussion of location-by-value vs. location-by-reference. Richard Statsny suggested this document would be a more complete introduction to the problem space if it included information regarding identity conveyance. 13. References 13.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 13.2 Informative References [ID-DHC-URI] J. Polk, "A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers", draft-polk-dhc-uri-03.txt, "work in progress", March 2006 [ID-ECRIT-JAPAN] H. Arai, M. Kawanishi, draft-arai-ecrit-japan-req- 01.txt, "work-in-progress", May 2005 Author's Address James M. Polk Polk & Newton Expires Sept 6th, 2006 [Page 14] Internet-Draft ECRIT Arch Considerations Mar 2006 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Fax: none Email: jmpolk@cisco.com Andrew Newton 21345 Ridgetop Circle Dulles, VA 20166 Phone: +17039483382 Email: andy@hxr.us Appendix A. Additional stuff Intellectual Property Statement 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. Disclaimer of Validity 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 AND THE Polk & Newton Expires Sept 6th, 2006 [Page 15] Internet-Draft ECRIT Arch Considerations Mar 2006 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Polk & Newton Expires Sept 6th, 2006 [Page 16]