idnits 2.17.00 (12 Aug 2021) /tmp/idnits43202/draft-hardie-emergency-call-routing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 10. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 282), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 282. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 382 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Concerns with URI-based call routing for emergency services 3 draft-hardie-emergency-call-routing-00.txt 5 Status of this Memo 7 By submitting this Internet-Draft, I certify that any applicable 8 patent or other IPR claims of which I am aware have been disclosed, 9 and any of which I become aware will be disclosed, in accordance 10 with RFC 3668. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 . 25 The list of Internet-Draft Shadow Directories can be accessed at 26 . 28 This Internet-Draft will expire in January 2005. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This document discusses recent proposals that would introduce a 37 common URI or set of URIs to identify and route calls intended to 38 reach emergency services. 40 1. Introduction. 42 In a number of areas the public switched telephone network (PSTN) 43 has been configured to recognize a short, easily memorized number 44 as a call for emergency services. There may be a single such 45 number which is undifferentiated as to service, or there may be 46 multiple numbers associated with distinct emergency services. The 47 number assigned to this purpose varies according to region, though 48 the regions for which each is valid tend to be large and aligned 49 with a major political boundary. (ES-URI) proposes the 50 introduction of a set of global identifiers for emergency services 51 which would augment and possibly supersede these emergency service 52 numbers. 54 The problem inherent in this approach is setting out the 55 appropriate context for the resolution of the URI. This document 56 examines some aspects of that problem. 58 2. URI context and resolution. 60 (URI) sets out that: 62 URIs have a global scope and must be interpreted consistently 63 regardless of context, though the result of that 64 interpretation may be in relation to the end-user's context. 65 For example, "http:// localhost/" has the same interpretation 66 for every user of that reference, even though the network 67 interface corresponding to "localhost" may be different for 68 each end-user: interpretation is independent of access. 69 However, an action made on the basis of that reference will 70 take place in relation to the end-user's context, which 71 implies that an action intended to refer to a single, globally 72 unique thing must use a URI that distinguishes that resource 73 from all other things. URIs that identify in relation to the 74 end-user's local context should only be used when the context 75 itself is a defining aspect of the resource, such as when an 76 on-line Linux manual refers to a file on the end-user's 77 filesystem (e.g., "file:///etc/hosts"). 79 Clearly, a call for emergency services is not intended to refer to 80 a single, globally unique resource. Nor is it, however, something 81 local to an individual user's context. It relates to an emergency 82 service context which depends on a broad, regional configuration 83 of service contact methods and a geographically constrained 84 context of service delivery. 86 The problem of associating that emergency service context, with 87 its irregular geographic boundaries and variability in breadth, to 88 a single set of URIs is formidable. (ES-URI) proposes the use of 89 a convention, in which a well-known string is used to construct a 90 URI which is neither as local as file:///etc/hosts nor as global 91 as http://www.example.com/file.txt. This string concatenates "sos" 92 or a substring-augmented form like "sos.fire" with the domain of 93 record for the caller to create a URI of the form 94 "sip:sos@example.com". 96 (ES-URI) provides the following rational for this choice: 98 The domain-of-record was chosen since a SIP user agent may not 99 be able to determine the local domain it is visiting. This 100 also allows each user to test this facility, as the user can 101 ensure that such services are operational in his home 102 domain. An outbound proxy in the visited domain can handle the 103 call if it believes to be in a position to provide appropriate 104 emergency services. 106 The difficulty here is that there is no existing relationship 107 between the domain of record and the emergency service context. 108 In addition, maintaining a relationship between the two when the 109 calling device is mobile is quite challenging. 111 3. Call routing. 113 In order for the method proposed in (ES-URI) to work, some network 114 element must examine the SIP request URI and associate the request 115 with an emergency service context appropriate for the user at her 116 or his current location. That network element must then either 117 directly or indirectly route the call to the Emergency Call Center 118 (ECC) appropriate to that context. Without more granular 119 geographic information, the location used must be assumed from 120 network topology; given the prevalence of tunnels in modern IP 121 networks, this can be very difficult and can produce incorrect 122 results. 124 There is no mechanism of which this author is aware for globally 125 associating the data needed for geographically based resolution 126 with domains of record; those devices which are capable of mapping 127 a location to an ECC do so based on local databases whose form, 128 scope, and granularity are currently all variable. (DNS-SOS) 129 proposes using the DNS as a publication mechanism for this data, 130 but notes that once published, data of local interest would have 131 to be computed and locally stored to be usable by this system. 132 Discovering what data is of local interest is an unsolved problem 133 even under that proposal, and the DNS storage of location data is 134 unrelated to the use of domains of record. 136 While it is theoretically possible to maintain a local copy of a 137 global mapping table of every possible ECC to its service area, 138 this author believes that this will remain theoretical. Further, 139 maintaining even incomplete mapping tables at every SIP proxy is 140 clearly onerous to the point of impossibility. It may be possible 141 to maintain them at specially designated route servers, to which 142 SIP servers can forward requests for emergency service for onward 143 call routing. SIP servers would, in such a case, need to be 144 configured with the appropriate route server, which would actually 145 perform the mapping function and route the call. 147 4) An alternate role for configuration. 149 Rather than using a constructed URI which must be recognized and 150 interpreted by a network element which is already performing other 151 functions, one alternative would be to automatically configure 152 devices with an appropriate URI. In some situations, this URI 153 might be local PSTN emergency number encoded as a tel: URI. 154 (ES-URI) describes the use of tel: URIs in emergency calls and 155 notes that automatic configuration may be required to inform 156 mobile devices of the local emergency service number. In other 157 situations, this might be an emergency services call routing 158 server, as is mentioned in section 3 above. Note that in this 159 case, though, the intention would be to eliminate the initial 160 connection and examination by the usual SIP proxy, and have the 161 device talk directly to the emergency service call routing server, 162 which would act as a SIP proxy for the emergency call. 164 This configuration would, in essence, set the service context, 165 thus making the URI resolution context clear and unambiguous. 166 Even if the "sos" convention were retained for the left hand side 167 of the URI (e.g. sos@local.call.routing.server.example.net), the 168 need for intermediate elements to identify a device with 169 appropriate local mapping tables is eliminated, and much of the 170 complexity of the universal URI proposal reduced. 172 4.1) Barriers to the use of configuration. 174 The use of configuration to set a service context would require 175 that the common means of configuring devices would need to be 176 extended to carry this data. At a minimum, this would require 177 both DHCP (DHCP) and DHCPv6 (DHCPv6) to set aside appropriate code 178 points, and it might require other systems (such as over-the-air 179 configuration) to do so as well. Once the protocol mechanisms 180 were in place, devices handling node configuration would have to 181 be configured with this data and the data kept up to date. Route 182 servers capable of both associating the location of a caller with 183 the appropriate ECC and of handling the SIP call flows would have 184 to be deployed. In cases where a mobile device receives no 185 configuration data from a visited network, the home network would 186 also have to maintain mapping tables sufficient for associating 187 the device to an ECC. 189 4.2) Advantages to the use of configuration. 191 The use of configuration for this level of call routing eliminates 192 one network element from the emergency call flow, which should 193 speed the call and eliminate a risk that other, non-emergency 194 traffic may hinder call completion. It also supports a relatively 195 flexible set of route server deployments; a network may choose to 196 provide a very complete set of mappings in one large-scale route 197 server farm or may distribute the data around their network. 198 Depending on the format of the configuration record, extensibility 199 to non-SIP flows might be possible in the future. For non-mobile 200 devices, the configuration of this data should be relatively 201 static and easily maintained over long periods of time. 203 5) Presentation layer vs. call routing. 205 One of the chief advantages of national or regional schemes for 206 emergency service numbers is that the numbers selected are short, 207 easily remembered, and easily dialed. These are essentially 208 presentation layer characteristics, though, and they mask the 209 complexity of effort taken within the PSTN to route the call to 210 the appropriate ECC. Part of the (ES-URI) proposal is clearly 211 aimed at the same presentation layer characteristics--having a 212 short, mnemonic string to associate with emergency services. 214 There is no need, however, for this presentation layer string to 215 constrain the development of the protocol elements used to support 216 the underlying call routing. As a thought exercise, imagine every 217 phone having an "emergency" button--the UI in this is clear, 218 unambiguous, and easy for the end user to understand. What 219 happens when that button is pressed is not constrained by the 220 label on the button, though, and a similar independence between 221 user interface and call routing can be achieved in this case. 222 Just as (ES-URI) notes that a device should recognize both local 223 dialing plan and "home region" dialing plan emergency service 224 numbers as calls for help, a presentation layer convention can be 225 set without it affecting the underlying routing. 227 6. Security Considerations. 229 Any system used to deliver emergency services must be robust, 230 timely and protected against malicious interference. The use of 231 automatic configuration methods to derive some element of the 232 emergency call routing will inherent any weaknesses of the 233 configuration methods; in some instances, those might be severe. 234 There is also risk that out of data information may cause 235 emergency call information to be routed to route servers which are 236 no longer available. A fallback mechanism (probably to route such 237 calls to the usual SIP proxy, which would then use its local 238 configuration) is probably necessary. 240 If an attacker can spoof or DoS the emergency call routing center, 241 calls will not go through. 243 7. IANA Considerations. 245 This document contains no instructions to IANA. 247 8. Normative References 249 Schulzrinne, H. "Emergency Services URI for the Session Initiation Protocol" 250 draft-ietf-sipping-sos-00.txt (ES-URI) 252 Berners-Lee, T., Fielding, R., Masinter, L. "Uniform Resource Identifier (URI): 253 Generic Syntax" draft-fielding-uri-rfc2396bis-05.txt (URI) 255 Rosen, B. "Emergency Call Information in the Domain Name System" 256 draft-rosen-dns-sos-00.txt (DNS-SOS) 258 9. Non-Normative References 260 Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 261 1997. (DHCP) 263 Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and 264 M. Carney, "Dynamic Host Configuration Protocol for IPv6 265 (DHCPv6)", RFC 3315, July 2003. (DHCPv6) 267 10. Acknowledgements 269 The author would like to acknowledge discussions with 270 Randy Gellens, AC Mahendran, and Raymond Hsu. 272 11. Author's Address 274 Ted Hardie 275 Qualcomm, Inc. 675 Campbell Technology Parkway 276 Campbell, CA U.S.A. 278 EMail: hardie@qualcomm.com 280 Full Copyright Statement 282 Copyright (C) The Internet Society (2004). All Rights Reserved. 284 This document and translations of it may be copied and furnished to 285 others, and derivative works that comment on or otherwise explain 286 it or assist in its implementation may be prepared, copied, 287 published and distributed, in whole or in part, without restriction 288 of any kind, provided that the above copyright notice and this 289 paragraph are included on all such copies and derivative works. 290 However, this document itself may not be modified in any way, such 291 as by removing the copyright notice or references to the Internet 292 Society or other Internet organizations, except as needed for the 293 purpose of developing Internet standards in which case the 294 procedures for copyrights defined in the Internet Standards process 295 must be followed, or as required to translate it into languages 296 other than English. 298 The limited permissions granted above are perpetual and will not be 299 revoked by the Internet Society or its successors or assigns. 301 This document and the information contained herein is provided on 302 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 303 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 304 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 305 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 308 Acknowledgement 310 Funding for the RFC Editor function is currently provided by the 311 Internet Society.