idnits 2.17.1 draft-ietf-ecrit-car-crash-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3107 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5031' is defined on line 1130, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-37 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Qualcomm Technologies, Inc 4 Intended status: Informational B. Rosen 5 Expires: April 20, 2016 NeuStar, Inc. 6 H. Tschofenig 7 (Individual) 8 October 18, 2015 10 Next-Generation Vehicle-Initiated Emergency Calls 11 draft-ietf-ecrit-car-crash-04.txt 13 Abstract 15 This document describes how to use IP-based emergency services 16 mechanisms to support the next generation of emergency calls placed 17 by vehicles (automatically in the event of a crash or serious 18 incident, or manually invoked by a vehicle occupant) and conveying 19 vehicle, sensor, and location data related to the crash or incident. 20 Such calls are often referred to as "Automatic Crash Notification" 21 (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the 22 case of manual trigger. The "Advanced" qualifier refers to the 23 ability to carry a richer set of data. 25 This document also registers a MIME Content Type and an Emergency 26 Call Additional Data Block for the vehicle, sensor, and location data 27 (often referred to as "crash data" even though there is not 28 necessarily a crash). An external specification for the data format, 29 contents, and structure are referenced in this document. 31 This document reuses the technical aspects of next-generation pan- 32 European eCall (a mandated and standardized system for emergency 33 calls by in-vehicle systems within Europe and other regions). 34 However, this document specifies a different set of vehicle (crash) 35 data, specifically, the Vehicle Emergency Data Set (VEDS) rather than 36 the eCall Minimum Set of Data (MSD). This document is an extension 37 of the eCall document, with the differences being that this document 38 makes the MSD data set optional and VEDS mandatory. This document 39 also discusses legacy (curcuit-switched) ACN systems and their 40 migration to next-generation emergency calling. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on April 20, 2016. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Overview of Legacy Deployment Models . . . . . . . . . . . . 8 80 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9 81 6. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 13.1. MIME Content-type Registration for 90 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 21 91 13.2. Registration of the 'VEDS' entry in the Emergency Call 92 Additional Data registry . . . . . . . . . . . . . . . . 22 93 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 94 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 95 16. Changes from Previous Versions . . . . . . . . . . . . . . . 23 96 16.1. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 23 97 16.2. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 23 98 16.3. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 23 99 16.4. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 23 100 16.5. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 23 101 16.6. Changes from draft-gellens-01 to -02 . . . . . . . . . . 24 102 16.7. Changes from draft-gellens-00 to -01 . . . . . . . . . . 24 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 17.1. Normative References . . . . . . . . . . . . . . . . . . 24 105 17.2. Informative references . . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 This document re-uses terminology defined in Section 3 of [RFC5012]. 116 Additionally, we use the following abbreviations: 118 +--------+----------------------------------------------------------+ 119 | Term | Expansion | 120 +--------+----------------------------------------------------------+ 121 | 3GPP | 3rd Generation Partnership Project | 122 | AACN | Advanced Automatic Crash Notification | 123 | ACN | Automatic Crash Notification | 124 | APCO | Association of Public-Safety Communications Officials | 125 | EENA | European Emergency Number Association | 126 | ESInet | Emergency Services IP network | 127 | GNSS | Global Satellite Navigation System (which includes the | 128 | | various such systems including the Global Positioning | 129 | | System or GPS) | 130 | IVS | In-Vehicle System | 131 | MNO | Mobile Network Operator | 132 | NENA | National Emergency Number Association | 133 | TSP | Telematics Service Provider | 134 | VEDS | Vehicle Emergency Data Set | 135 +--------+----------------------------------------------------------+ 137 2. Introduction 139 Emergency calls made by in-vehicle systems (e.g., in the event of a 140 crash) assist in significantly reducing road deaths and injuries by 141 allowing emergency services to respond quickly and often with better 142 location. 144 Drivers often have a poor location awareness, especially outside of 145 major cities, at night and when away from home (especially abroad). 146 In the most crucial cases, the victim(s) might not be able to call 147 because they have been injured or trapped. 149 For more than a decade, some vehicles have been equipped with 150 telematics systems that, among other features, place an emergency 151 call automatically in the event of a crash or manually in response to 152 an emergency call button. Such systems generally have on-board 153 location determination systems that make use of satellite-based 154 positioning technology, inertial sensors, gyroscopes, etc., to 155 provide a fairly accurate position for the vehicle. Such built-in 156 systems can take advantage of the benefits of being integrated into a 157 vehicle, such as more reliable power, ability to have larger or 158 specialized antenna, ability to be engineered to avoid or minimise 159 degradation by vehicle glass coatings, interference from other 160 vehicle systems, etc. Thus, the PSAP can be provided with a good 161 estimate of where the vehicle is during an emergency. Vehicle 162 manufacturers are increasingly adopting such systems, both for the 163 safety benefits and for the additional features and services they 164 enable (e.g., remote engine diagnostics, remote door unlock, stolen 165 vehicle tracking and disabling, etc.). 167 The general term for such systems is Automatic Crash Notification 168 (ACN) or "Advanced Automatic Crash Notification" (AACN). "ACN" is 169 used in this document as a general term. ACN systems transmit some 170 amount of data specific to the incident, referred to generally as 171 "crash data" (the term is commonly used even though there might not 172 have been a crash). While different systems transmit different 173 amounts of crash data, standardized formats, structures, and 174 mechanisms are needed to provide interoperability among systems and 175 PSAPs. 177 As of the date of this document, currently deployed in-vehicle 178 telematics systems are circuit-switched and lack a standards-based 179 ability to convey crash data directly to the PSAP (generally relying 180 on either a human call taker or an automated system to provide the 181 PSAP call taker with some crash data orally, or possibly a 182 proprietary mechanism). The PSAP call taker needs to first realize 183 that the call is related to a vehicle incident, and in most cases 184 must then listen to the data and transcribe it. 186 The transition to next-generation calling in general, and emergency 187 calling in particular, provides an opportunity to vastly improve the 188 scope, breadth, reliability and usefulness of crash data during an 189 emergency by allowing it to be presented alongside the call, and to 190 be automatically processed by the PSAP and made available to the call 191 taker in an integrated, automated way. In addition, vehicle 192 manufacturers are provided an opportunity to take advantage of the 193 same standardized mechanisms for data transmission for internal use 194 if they wish (such as telemetry between the vehicle and a service 195 center for both emergency and non-emergency uses, including location- 196 based services, multi-media entertainment systems, and road-side 197 assistance applications). 199 Next-generation ACN provides an opportunity for such calls to be 200 recognized and processed as such during call set-up, and optionally 201 routed to an upgraded PSAP where the vehicle data is available to 202 assist the call taker in assessing and responding to the situation. 204 An ACN call can be either occupant-initiated or automatically 205 triggered. (The "A" in "ACN" does stand for "Automatic," but the 206 term is often used to refer to the class of calls that are placed by 207 an in-vehicle system (IVS) and that carry incident-related data as 208 well as voice.) Automatically triggered calls indicate a car crash 209 or some other serious incident (e.g., a fire) and carry a greater 210 presumption of risk of injury. Manually triggered calls are often 211 reports of serious hazards (such as impaired drivers or roadway 212 debris) and might require different responses depending on the 213 situation. Manually triggered calls are also more likely to be false 214 (e.g., accidental) calls and so might be subject to different 215 operational handling by the PSAP. 217 This document describes how the IETF mechanisms for IP-based 218 emergency calls, including [RFC6443] and 219 [I-D.ietf-ecrit-additional-data], are used to provide the realization 220 of next-generation ACN. 222 This document reuses the technical aspects of next-generation pan- 223 European eCall (a mandated and standardized system for emergency 224 calls by in-vehicle systems within Europe and other regions), as 225 described in [I-D.ietf-ecrit-ecall]. However, this document 226 specifies a different set of vehicle (crash) data, specifically, the 227 Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set 228 of Data (MSD). This document is an extension of 229 [I-D.ietf-ecrit-ecall], with the differences being that this document 230 makes the MSD data set optional and VEDS mandatory. 232 The Association of Public-Safety Communications Officials (APCO) and 233 the National Emergency Number Association (NENA) have jointly 234 developed a standardized set of incident-related vehicle data for ACN 235 use, called the Vehicle Emergency Data Set (VEDS) [VEDS]. Such data 236 is often referred to as crash data although it is applicable in 237 incidents other than crashes. 239 VEDS provides a standard data set for the transmission, exchange, and 240 interpretation of vehicle-related data. A standard data format 241 allows the data to be generated by an IVS, and interpreted by PSAPs, 242 emergency responders, and medical facilities (including those capable 243 of providing trauma level patient care). It includes incident- 244 related information such as airbag deployment, location of the 245 vehicle, if the vehicle was involved in a rollover, various sensor 246 data that can indicate the potential severity of the crash and the 247 likelihood of severe injuries to the vehicle occupants, etc. This 248 data better informs the PSAP and emergency responders as to the type 249 of response that might be needed. This information was recently 250 included in the federal guidelines for field triage of injured 251 patients. These guidelines are designed to help responders at the 252 accident scene identify the potential existence of severe internal 253 injuries and to make critical decisions about how and where a patient 254 needs to be transported. 256 This document registers the 'application/EmergencyCallData.VEDS+xml' 257 MIME content-type, and registers the 'VEDS' entry in the Emergency 258 Call Additional Data registry. 260 VEDS is an XML structure (see [VEDS]). The 'application/ 261 EmergencyCallData.VEDS+xml' MIME content-type is used to identify it. 262 The 'VEDS' entry in the Emergency Call Additional Data registry is 263 used to construct a 'purpose' parameter value for conveying VEDS data 264 in a Call-Info header (as described in 265 [I-D.ietf-ecrit-additional-data]). 267 VEDS is a versatile structure that can accomodate varied needs. 268 However, if additional sets of data are determined to be needed 269 (e.g., in the future or in different regions), the steps to enable 270 each data block are very briefly summarized below: 272 o A standardized format and encoding (such as XML) is defined and 273 published by a Standards Development Organization (SDO) 275 o A MIME Content-Type is registered for it (typically under the 276 'Application' media type) with a sub-type starting with 277 'EmergencyCallData.' 279 o An entry for the block is added to the Emergency Call Additional 280 Data Blocks sub-registry (established by 281 [I-D.ietf-ecrit-additional-data]); the registry entry is the root 282 of the MIME sub-type (not including the 'EmergencyCallData' prefix 283 and any suffix such as '+xml') 285 A next-generation In-Vehicle System (IVS) transmits crash data by 286 encoding it in a standardized and registered format (such as VEDS) 287 and attaching it to an INVITE as a MIME body part. The body part is 288 identified by its MIME content-type (such as 'application/ 289 EmergencyCallData.VEDS+xml') in the Content-Type header field of the 290 body part. The body part is assigned a unique identifier which is 291 listed in a Content-ID header field in the body part. The INVITE is 292 marked as containing the crash data by adding a Call-Info header 293 field at the top level of the INVITE. This Call-Info header field 294 contains a CID URL referencing the body part's unique identifier, and 295 a 'purpose' parameter identifying the data as the crash data per the 296 registry entry; the 'purpose' parameter's value is 297 'EmergencyCallData.' and the root of the MIME type (the 298 'EmergencyCallData' prefix is not repeated), omitting any suffix such 299 as '+xml' (e.g., 'purpose=EmergencyCallData.VEDS'). 301 These mechanisms are thus used to place emergency calls that are 302 identifiable as ACN calls and that carry one or more standardized 303 crash data objects in an interoperable way. 305 3. Document Scope 307 This document is focused on the interface to the PSAP, that is, how 308 an ACN emergency call is setup and incident-related data (including 309 vehicle, sensor, and location data) is transmitted to the PSAP using 310 IETF specifications. (The goal is to re-use specifications rather 311 than to invent new.) For the direct model, this is the end-to-end 312 description (between the vehicle and the PSAP). For the TSP model, 313 this describes the right-hand side (between the TSP and the PSAP), 314 leaving the left-hand side (between the vehicle and the TSP) up to 315 the entities involved (i.e., IVS and TSP vendors) who are then free 316 to use the same mechanism as for the right-hand side (or not). 318 Note that while ACN systems in the U.S. and other regions are not 319 currently (as of the date of this document) mandated, Europe has a 320 mandated and standardized system for emergency calls by in-vehicle 321 systems. This pan-European system is known as "eCall" and is the 322 subject of a separate document, [I-D.ietf-ecrit-ecall], which this 323 document build on. Vehicles designed to operate in multiple regions 324 might need to support eCall as well as the ACN described here. If 325 other regions devise their own specifications or data formats, a 326 multi-region vehicle might need to support those as well. This 327 document adopts the call set-up and other technical aspects of 328 [I-D.ietf-ecrit-ecall], which uses [I-D.ietf-ecrit-additional-data], 329 which makes it easy to substitute a different data set while keeping 330 other technical aspects unchanged. Hence, both NG-eCall and the NG- 331 ACN mechanism described here are fully compatible, differing only in 332 the specific data block that is sent (the eCall MSD in the case of 333 NG-eCall, and the APCO/NENA VEDS used in this document). If other 334 regions adopt their own data set, this can be similarly accomodated 335 without changing other technical aspects. 337 4. Overview of Legacy Deployment Models 339 Legacy (circuit-switched) systems for placing emergency calls by in- 340 vehicle systems, including automatic crash notification systems, 341 generally have some ability to convey at least location and in some 342 cases telematics data to the PSAP. Most such systems use one of 343 three architectural models, which are described here as: "Telematics 344 Service Provider" (TSP), "direct", and "paired". These three models 345 are illustrated below. 347 In the TSP model, both emergency and non-emergency calls are placed 348 to a Telematics Service Provider (TSP); a proprietary technique is 349 used for data transfer (such as proprietary in-band modems) to the 350 TSP. 352 In an emergency, the TSP call taker bridges in the PSAP and 353 communicates location, crash data (such as impact severity and trauma 354 prediction), and other data (such as the vehicle description) to the 355 PSAP call taker verbally. Since the TSP knows the location of the 356 vehicle (from on-board GNSS), location-based routing is usually used 357 to route to the appropriate PSAP. In some cases, the TSP is able to 358 transmit location automatically, using similar techniques as for 359 wireless calls. Typically, a three-way voice call is established 360 between the vehicle, the TSP, and the PSAP, allowing communication 361 between the PSAP call taker, the TSP call taker, and the vehicle 362 occupants (who might be unconscious). 364 ///----\\\ proprietary +------+ 911 trunk +------+ 365 ||| IVS |||-------------->+ TSP +------------------>+ PSAP | 366 \\\----/// crash data +------+ +------+ 368 Figure 1: Legacy TSP Model. 370 In the paired model, the IVS uses a Bluetooth link with a previously- 371 paired handset to establish an emergency call with the PSAP (by 372 dialing a standard emergency number such as 9-1-1), and then 373 communicates location data to the PSAP via text-to-speech; crash data 374 might or might not be conveyed also using text-to-speech in an 375 initial voice greeting. Some such systems use an automated voice 376 prompt menu for the PSAP call taker (e.g., "this is an automatic 377 emergency call from a vehicle; press 1 to open a voice path to the 378 vehicle; press 2 to hear the location read out") to allow the call 379 taker to request location data via text-to-speech. 381 +---+ 382 ///----\\\ | H | 911/etc voice call via handset +------+ 383 ||| IVS |||-->| S +----------------------------------->+ PSAP | 384 \\\----/// +---+ location via text-to-speech +------+ 386 Figure 2: Legacy Paired Model 388 In the direct model, the IVS directly places an emergency call with 389 the PSAP by dialing a standard emergency number such as 9-1-1. Such 390 systems might communicate location data to the PSAP via text-to- 391 speech; crash data might or might not be conveyed using text-to- 392 speech in an initial voice greeting. Some such systems use an 393 automated voice prompt menu (e.g., "this is an automatic emergency 394 call from a vehicle; press 1 to open a voice path to the vehicle; 395 press 2 to hear the location read out") to allow the call taker to 396 request location data via text-to-speech. 398 ///----\\\ 911/etc voice call via IVS +------+ 399 ||| IVS |||---------------------------------------->+ PSAP | 400 \\\----/// location via text-to-speech +------+ 402 Figure 3: Legacy Direct Model 404 5. Migration to Next-Generation 406 Migration of emergency calls placed by in-vehicle systems to next- 407 generation (all-IP) technology provides a standardized mechanism to 408 identify such calls and to present crash data with the call, as well 409 as enabling additional communications modalities and enhanced 410 functionality. This allows ACN calls and crash data to be 411 automatically processed by the PSAP and made available to the call 412 taker in an integrated, automated way. Because the crash data is 413 carried in the initial SIP INVITE (per 414 [I-D.ietf-ecrit-additional-data]) the PSAP can present it to the call 415 taker simultaneously with the appearance of the call. 417 Migration to next-generation (NG) thus provides an opportunity to 418 significantly improve the handling and response to vehicle-initiated 419 emergency calls. Such calls can be recognized as originating from a 420 vehicle, routed to a PSAP equipped both technically and operationally 421 to handle such calls, and the vehicle-determined location and crash 422 data can be made available to the call taker simultaneously with the 423 call appearance. 425 Vehicle manufacturers using the TSP model can choose to take 426 advantage of the same mechanism to carry telematics data between the 427 vehicle and the TSP for both emergency and non-emergency calls as are 428 used to convey this data to the PSAP. 430 A next-generation IVS establishes an emergency call using the 431 emergency call solution as described in [RFC6443] and [RFC6881], with 432 the difference that the Request-URI indicates an ACN type of 433 emergency call and a Call-Info header field indicates that vehicle 434 crash data is attached. When an ESInet is deployed, the MNO only 435 needs to recognize the call as an emergency call and route it to an 436 ESInet. The ESInet can recognize the call as an ACN with vehicle 437 data and can route the call to an NG-ACN capable PSAP. Such a PSAP 438 can interpret the vehicle data sent with the call and make it 439 available to the call taker. 441 Because of the need to identify and specially process Next-Generation 442 ACN calls (as discussed above), [I-D.ietf-ecrit-ecall] registers new 443 service URN children within the "sos" subservice. These URNs provide 444 a mechanism by which an NG-ACN call is identified, and differentiate 445 between manually and automatically triggered NG-ACN calls, which 446 might be subject to different treatment depending on policy. (The 447 two service URNs registered in [I-D.ietf-ecrit-ecall] are 448 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual.) 450 Note that in North America, routing queries performed by clients 451 outside of an ESInet typically treat all sub-services of "sos" 452 identically to "sos" with no sub-service. However, the Request-URI 453 header field retains the full sub-service; route and handling 454 decisions within an ESInet or PSAP can take the sub-service into 455 account. For example, in a region with multiple cooperating PSAPs, 456 an NG-ACN call might be routed to a PSAP that is NG-ACN capable, or 457 one that specializes in vehicle-related incidents. 459 Migration of the three architectural models to next-generation (all- 460 IP) is described below. 462 In the TSP model, the IVS transmits crash and location data to the 463 TSP using either a protocol that is based on a proprietary design or 464 one that re-uses the mechanisms and data objects described here. In 465 an emergency, the TSP call taker bridges in the PSAP and the TSP 466 transmits crash and other data to the PSAP using the mechanisms and 467 data objects described here. There is a three-way call between the 468 vehicle, the TSP, and the PSAP, allowing communication between the 469 PSAP call taker, the TSP call taker, and the vehicle occupants (who 470 might be unconscious). 472 proprietary 473 ///----\\\ or standard +------+ standard +------+ 474 ||| IVS ||| ------------------->+ TSP +------------------->+ PSAP | 475 \\\----/// crash + other data +------+ crash + other data +------+ 477 Figure 4: Next-Generation TSP Model 479 The vehicle manufacturer and the TSP can choose to use the same 480 mechanisms and data objects to transmit crash and location data from 481 the vehicle to the TSP as are described here to transmit such data 482 from to the PSAP. 484 In the direct model, the IVS communicates crash data to the PSAP 485 directly using the mechanisms and data objects described here. 487 ///----\\\ NG emergency call +------+ 488 ||| IVS |||----------------------------------------->+ PSAP | 489 \\\----/// crash + other data +------+ 491 Figure 5: Next-Generation Direct Model 493 In the paired model, the IVS uses a Bluetooth link to a previously- 494 paired handset to establish an emergency call with the PSAP; it is 495 undefined what facilities are or will be available for transmitting 496 crash data through the Bluetooth link to the handset for inclusion in 497 an NG emergency call. Hence, manufacturers that use the paired model 498 for legacy calls might choose to adopt either the direct or TSP 499 models for next-generation calls. 501 +---+ 502 ///----\\\ (undefined) | H | standard +------+ 503 ||| IVS |||------------------>| S +------------------->+ PSAP | 504 \\\----/// (undefined) +---+ crash + other data +------+ 506 Figure 6: Next-Generation Paired Model 508 If the call is routed to a PSAP that is not capable of processing the 509 vehicle data, the PSAP ignores (or does not receive) the vehicle 510 data. This is detectable by the IVS or TSP when it receives a 200 OK 511 to the INVITE which lacks an eCall control structure acknowledging 512 receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then 513 proceeds as it would for a non-NG ACN call (e.g., verbal conveyance 514 of data) 516 6. Profile 518 In the context of emergncy calls placed by an in-vehicle system it is 519 assumed that the car is equipped with a built-in GNSS receiver. For 520 this reason only geodetic location information will be sent within an 521 emergency call. The following location shapes MUST be implemented: 522 2d and 3d Point (see Section 5.2.1 of [RFC5491]), Circle (see 523 Section 5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of 524 [RFC5491]). The coordinate reference systems (CRS) specified in 525 [RFC5491] are also mandatory for this document. The 526 element, as defined in [RFC5962] which indicates the direction of 527 travel of the vehicle, is important for dispatch and hence it MUST be 528 included in the PIDF-LO [RFC4119]. The element specified 529 in [RFC5962] MUST be implemented and MAY be included. 531 Calls by in-vehicle systems are placed via cellular networks, which 532 might ignore location sent by an originating device in an emergency 533 call INVITE, instead attaching their own location (often determined 534 in cooperation with the originating device). Standardized crash data 535 structures often include location as determined by the IVS. A 536 benefit of this is that it allows the PSAP to see both the location 537 as determined by the cellular network (often in cooperation with the 538 originating device) and the location as determined by the IVS. 540 This specification inherits the ability to utilize test call 541 functionality from Section 15 of [RFC6881]. 543 7. Call Setup 545 It is important that ACN calls be easily identifiable as such at all 546 stages of call handling, and that automatic versus manual triggering 547 be known. ACN calls differ from general emergency calls in several 548 aspects, including the presence of standardized crash data, the fact 549 that the call is known to be placed by an in-vehicle system (which 550 has implications for PSAP operational processes), and, especially for 551 automatic calls, information that can indicate a likelihood of severe 552 injury and hence need for trauma services. Knowledge that a call is 553 an ACN and further that it was automatically or manually invoked 554 carries a range of implications about the call, the circumstances, 555 and the vehicle occupants. Calls by in-vehicle systems can be 556 considered a specific sub-class of general emergency calls and are 557 optimally handled by a PSAP with the technical and operational 558 capabilities to serve such calls. (This is especially so in 559 environments such as the U.S. where there are many PSAPs and where 560 individual PSAPs have a range of capabilities.) Technical 561 capabilities include the ability to recognize and process 562 standardized crash data. Operational capabilities include training 563 and processes for assessing severe injury likelihood and responding 564 appropriately (e.g., dispatching trauma-capable medical responders or 565 those trained and equipped to extract occupants from crashed vehicles 566 and handle gasoline or other hazardous materials, transporting 567 victims to a trauma center, alerting the receiving facility, etc.). 569 Because ACN calls differ in significant ways from general emergency 570 calls, and because such calls typically generally are best handled by 571 PSAPs equipped technically to interpet and make use of crash data, 572 and operationally to handle emergency calls placed by in-vehicle 573 systems, [I-D.ietf-ecrit-ecall] registers SOS sub-services. Using a 574 sub-service allows the call to be treated as an amergency call and 575 makes it readily obvious that the call is an ACN; a further child 576 element distinguishes calls automatically placed due to a crash or 577 other serious incident (such as a fire) from those manually invoked 578 by a vehicle occupant (specifically, "SOS.ecall.automatic" and 579 "SOS.ecall.manual"). The distinction between automatic and manual 580 invocation is also significant; automatically triggered calls 581 indicate a car crash or some other serious incident (e.g., a fire) 582 and carry a greater presumption of risk of injury and hence need for 583 specific responders (such as trauma or fire). Manually triggered 584 calls are often reports of serious hazards (such as impaired drivers 585 or roadway debris) and might require different responses depending on 586 the situation. Manually triggered calls also have a greater chance 587 of being false (e.g., accidental) calls and might thus be subject to 588 different handling by the PSAP. 590 A next-generation In-Vehicle System (IVS) transmits crash data by 591 encoding it in a standardized and registered format and attaching it 592 to an INVITE as an additional data block as specified in Section 4.1 593 of [I-D.ietf-ecrit-additional-data]. As described in that document, 594 the block is identified by its MIME content-type, and pointed to by a 595 CID URL in a Call-Info header with a 'purpose' parameter value 596 corresponding to the block. 598 Specifically, the steps required during standardization are: 600 o A set of crash data is standardized by an SDO or appropriate 601 organization 603 o A MIME Content-Type for the crash data set is registered with IANA 605 * If the data is specifically for use in emergency calling, the 606 MIME type is normally under the 'application' type with a 607 subtype starting with 'EmergencyCallData.' 609 * If the data format is XML, then by convention the name has a 610 suffix of '+xml' 612 o The item is registered in the Emergency Call Additional Data 613 registry, as defined in Section 9.1.7 of 614 [I-D.ietf-ecrit-additional-data] 616 * For emergency-call-specific formats, the registered name is the 617 root of the MIME Content-Type (not including the 618 'EmergencyCallData' prefix and any suffix such as '+xml') as 619 described in Section 4.1 of [I-D.ietf-ecrit-additional-data] 621 When placing an emergency call: 623 o The crash data set is created and encoded per its specification 625 o The crash data set is attached to the emergency call INVITE as 626 specified in Section 4.1 of [I-D.ietf-ecrit-additional-data], that 627 is, as a MIME body part identified by its MIME Content-Type in the 628 body part's Content-Type header field 630 o The body part is assigned a unique identifier label in a Content- 631 ID header field of the body part 633 o A Call-Info header field at the top level of the INVITE is added 634 that references the crash data and identifies it by its MIME root 635 (as registered in the Emergency Call Additional Data registry) 637 * The crash data is referenced in the Call-Info header field by a 638 CID URL that contains the unique Content ID assigned to the 639 crash data body part 641 * The crash data is identified in the Call-Info header field by a 642 'purpose' parameter whose value is 'EmergencyCallData.' 643 concatenated with the specific crash data entry in the 644 Emergency Call Additional Data registry 646 * The Call-Info header field MAY be either solely to reference 647 the crash data (and hence have only the one URL) or can also 648 contain other URLs referencing other data 650 o Additional crash data sets MAY be included by following the same 651 steps 653 The Vehicle Emergency Data Set (VEDS) is an XML structure defined by 654 the Association of Public-Safety Communications Officials (APCO) and 655 the National Emergency Number Association (NENA) [VEDS]. The 656 'application/EmergencyCallData.VEDS+xml' MIME content-type is used to 657 identify it. The 'VEDS' entry in the Emergency Call Additional Data 658 registry is used to construct a 'purpose' parameter value for 659 conveying VEDS data in a Call-Info header. 661 The VEDS data is attached as a body part with MIME content type 662 'application/EmergencyCallData.VEDS+xml' which is pointed at by a 663 Call-Info URL of type CID with a 'purpose' parameter of 664 'EmergencyCallData.VEDS'. 666 Entities along the path between the vehicle and the PSAP are able to 667 identify the call as an ACN call and handle it appropriately. The 668 PSAP is able to identify the crash data as well as any other 669 additional data attached to the INVITE by examining the Call-Info 670 header fields for 'purpose' parameters whose values start with 671 'EmergencyCallData.' The PSAP is able to access and the data it is 672 capable of handling and is interested in by checking the 'purpose' 673 parameter values. 675 This document extends [I-D.ietf-ecrit-ecall] by reusing the call set- 676 up and other normative requirements except that in this document, 677 support for the eCall MSD is OPTIONAL and support for VEDS in 678 REQUIRED. 680 8. Call Routing 682 An Emergency Services IP Network (ESInet) is a network operated by or 683 on behalf of emergency services authorities. It handles emergency 684 call routing and processing before delivery to a PSAP. In the 685 NG9-1-1 architecture adopted by NENA as well as the NG1-1-2 686 architecture adopted by EENA, each PSAP is connected to one or more 687 ESInets. Each originating network is also connected to one or more 688 ESInets. The ESInets maintain policy-based routing rules which 689 control the routing and processing of emergency calls. The 690 centralization of such rules within ESInets provides for a cleaner 691 separation between the responsibilities of the originating network 692 and that of the emergency services network, and provides greater 693 flexibility and control over processing of emergency calls by the 694 emergency services authorities. This makes it easier to react 695 quickly to unusual situations that require changes in how emergency 696 calls are routed or handled (e.g., a natural disaster closes a PSAP), 697 as well as ease in making long-term changes that affect such routing 698 (e.g., cooperative agreements to specially handle calls requiring 699 translation or relay services). 701 In an environment that uses ESInets, the originating network need 702 only detect that the service URN of an emergency call is or starts 703 with "sos", passing all types of emergency calls to an ESInet. The 704 ESInet is then responsible for routing such calls to an appropriate 705 PSAP. In an environment without an ESInet, the emergency services 706 authorities and the originating carriers would need to determine how 707 such calls are routed. 709 9. Test Calls 711 This document builds on [I-D.ietf-ecrit-ecall], which inherits the 712 ability to utilize test call functionality from Section 15 of 713 [RFC6881]. 715 A service URN starting with "test." indicates a request for an 716 automated test. Per [I-D.ietf-ecrit-ecall], 717 "urn:service:test.sos.ecall.automatic" indicates such a test feature. 718 This functionality is defined in [RFC6881]. 720 Note that since test calls are placed using "test" as the parent 721 service URN and "sos" as a child, such calls are not treated as an 722 emergency call and so some functionality will not apply (such as 723 preemption or service availability for devices lacking service ("non- 724 service-initialized" or "NSI") if those are available for emergency 725 calls); this is by design. MNOs can recognize test calls and treat 726 them in a way that tests as much functionality as desired, but this 727 is outside the scope of this document. 729 10. Example 731 Figure 7 shows an emergency call placed by a vehicle whereby location 732 information and VEDS crash data are both attached to the SIP INVITE 733 message. The INVITE has a request URI containing the 734 'urn:service:sos.ecall.automatic' service URN and is thus recognized 735 as an ACN type of emergency call, and is also recognizable as an 736 emergency call because the request URI starts with 'urn:service:sos'. 737 The mobile network operator (MNO) routes the call to an Emergency 738 services IP Network (ESInet), as for any emergency call. The ESInet 739 processes the call as an ACN and routes the call to an appropriate 740 ACN-capable PSAP (using location information and the fact that that 741 it is an ACN). The call is processed by the Emergency Services 742 Routing Proxy (ESRP), as the entry point to the ESInet. The ESRP 743 routes the call to an appropriate ACN-capable PSAP, where the call is 744 received by a call taker. (In deployments where there is no ESInet, 745 the MNO itself routes the call directly to an appropriate ACN-capable 746 PSAP.) 747 +---------------------------------------+ 748 | | 749 +------------+ | +-------+ | 750 | | | | PSAP2 | | 751 | | | +-------+ | 752 | Originating| | | 753 | Mobile | | +------+ +-------+ | 754 Vehicle-->| Network |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 755 | | | +------+ +-------+ | 756 | | | | 757 +------------+ | +-------+ | 758 | | PSAP3 | | 759 | +-------+ | 760 | | 761 | | 762 | | 763 | ESInet | 764 +---------------------------------------+ 766 Figure 7: Example of Vehicle-Placed Emergency Call Message Flow 768 The example, shown in Figure 8, illustrates a SIP emergency call 769 INVITE that is being conveyed with location information (a PIDF-LO) 770 and crash data (as VEDS data). 772 The example VEDS data structure shows information about about a 773 crashed vehicle. The example communicates that the car is a model 774 year 2015 Saab 9-5 (a car which does not exist). The front airbag 775 deployed as a consequence of the crash. The 776 'VehicleBodyCategoryCode' indicates that the crashed vehicle is a 777 passenger car (the code is set to '101') and that it is not a 778 convertible (the 'ConvertibleIndicator' value is set to 'false'). 780 The 'VehicleCrashPulse' element provides further information about 781 the crash, namely that the force of impact based on the change in 782 velocity over the duration of the crash pulse was 100 MPH. The 783 principal direction of the force of the impact is set to '12' (which 784 refers to 12 O'Clock, corresponding to a frontal collision). This 785 value is described in the 'CrashPulsePrincipalDirectionOfForceValue' 786 element. 788 The 'CrashPulseRolloverQuarterTurnsValue' indicates the number of 789 quarter turns in concert with a rollover expressed as a number; in 790 our case 1. 792 No roll bar was deployed, as indicated in 793 'VehicleRollbarDeployedIndicator' being set to 'false'. 795 Next, there is information indicating seatbelt and seat sensor data 796 for individual seat positions in the vehicle. In our example, 797 information from the driver seat is available (value '1' in the 798 'VehicleSeatLocationCategoryCode' element), that the seatbelt was 799 monitored ('VehicleSeatbeltMonitoredIndicator' element), that the 800 seatbelt was fastened ('VehicleSeatbeltFastenedIndicator' element) 801 and the seat sensor determined that the seat is occupied 802 ('VehicleSeatOccupiedIndicator' element). 804 Finally, information about the weight of the vehicle, which is 600 805 kilogram in our example. 807 In addition to the information about the vehicle, further indications 808 are provided, namely the presence of fuel leakage 809 ('FuelLeakingIndicator' element), an indication whether the vehicle 810 was subjected to multiple impacts ('MultipleImpactsIndicator' 811 element), the orientation of the vehicle at final rest 812 ('VehicleFinalRestOrientationCategoryCode' element) and an indication 813 that there are no parts of the vehicle on fire (the 814 'VehicleFireIndicator' element). 816 INVITE urn:service:sos.ecall.automatic SIP/2.0 817 To: urn:service:sos.ecall.automatic 818 From: ;tag=9fxced76sl 819 Call-ID: 3848276298220188511@atlanta.example.com 820 Geolocation: 821 Geolocation-Routing: no 822 Call-Info: cid:1234567890@atlanta.example.com; 823 purpose=EmergencyCallData.VEDS 824 Accept: application/sdp, application/pidf+xml 825 CSeq: 31862 INVITE 826 Content-Type: multipart/mixed; boundary=boundary1 827 Content-Length: ... 829 --boundary1 830 Content-Type: application/sdp 832 ...Session Description Protocol (SDP) goes here 834 --boundary1 835 Content-Type: application/pidf+xml 836 Content-ID: 838 839 847 848 849 850 851 -34.407 150.883 852 853 854 278 855 856 857 858 859 gps 860 861 2012-04-5T10:18:29Z 862 1M8GDM9A_KP042788 863 864 866 --boundary1 867 Content-Type: application/EmergencyCallData.VEDS+xml 868 Content-ID: 1234567890@atlanta.example.com 869 Content-Disposition: by-reference;handling=optional 871 872 876 877 878 Saab 879 880 881 9-5 882 883 885 2015 886 887 888 FRONT 889 true 890 892 893 false 894 MAIN 895 897 101 898 899 900 901 903 100 904 905 907 MPH 908 909 12 910 911 1 912 913 914 false 915 916 917 1 918 919 true 920 921 true 922 923 true 924 925 926 928 930 600 931 932 934 kilogram 935 936 937 938 true 939 false 940 true 941 Driver 942 943 false 944 945 947 --boundary1-- 949 Figure 8: SIP INVITE indicating a Vehicule-Initated Emergency Call 951 11. Security Considerations 953 This document does not raise security considerations beyond those 954 described in [RFC5069]. As with emergency service systems with end 955 host provided location information there is the possibility that that 956 location is incorrect, either intentially (in case of an a denial of 957 service attack against the emergency services infrastructure) or due 958 to a malfunctioning device. The reader is referred to [RFC7378] for 959 a discussion of some of these vulnerabilities. 961 12. Privacy Considerations 963 Since this document builds on [I-D.ietf-ecrit-ecall], which itself 964 builds on [I-D.ietf-ecrit-additional-data], the data structures 965 specified there, and the corresponding privacy considerations 966 discussed there, apply here as well. The VEDS data structure 967 contains optional elements that can carry identifying and personal 968 information, both about the vehicle and about the owner, as well as 969 location information, and so needs to be protected against 970 unauthorized disclosure. Local regulations may impose additional 971 privacy protection requirements. 973 13. IANA Considerations 975 13.1. MIME Content-type Registration for 'application/ 976 EmergencyCall.VEDS+xml' 978 This specification requests the registration of a new MIME type 979 according to the procedures of RFC 4288 [RFC4288] and guidelines in 980 RFC 3023 [RFC3023]. 982 MIME media type name: application 984 MIME subtype name: EmergencyCallData.VEDS+xml 986 Mandatory parameters: none 987 Optional parameters: charset 989 Indicates the character encoding of enclosed XML. 991 Encoding considerations: Uses XML, which can employ 8-bit 992 characters, depending on the character encoding used. See 993 Section 3.2 of RFC 3023 [RFC3023]. 995 Security considerations: This content type is designed to carry 996 vehicle crash data during an emergency call. This data can 997 contain personal information including vehicle VIN, location, 998 direction, etc. Appropriate precautions need to be taken to limit 999 unauthorized access, inappropriate disclosure to third parties, 1000 and eavesdropping of this information. Please refer to Section 7 1001 and Section 8 of [I-D.ietf-ecrit-additional-data] for more 1002 information. 1004 Interoperability considerations: None 1006 Published specification: [VEDS] 1008 Applications which use this media type: Emergency Services 1010 Additional information: None 1012 Magic Number: None 1014 File Extension: .xml 1016 Macintosh file type code: 'TEXT' 1018 Person and email address for further information: Hannes 1019 Tschofenig, Hannes.Tschofenig@gmx.net 1021 Intended usage: LIMITED USE 1023 Author: This specification is a work item of the IETF ECRIT 1024 working group, with mailing list address . 1026 Change controller: The IESG 1028 13.2. Registration of the 'VEDS' entry in the Emergency Call Additional 1029 Data registry 1031 This specification requests IANA to add the 'VEDS' entry to the 1032 Emergency Call Additional Data registry, with a reference to this 1033 document. The Emergency Call Additional Data registry has been 1034 established by [I-D.ietf-ecrit-additional-data]. 1036 14. Contributors 1038 We would like to thank Ulrich Dietz for his help with earlier 1039 versions of the original version of this document. 1041 15. Acknowledgements 1043 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 1044 and Gunnar Hellstrom for their feedback. 1046 16. Changes from Previous Versions 1048 16.1. Changes from draft-ietf-03 to draft-ietf-04 1050 o Added example VEDS object 1051 o Additional clarifications and corrections 1052 o Removed references from Abstract 1053 o Moved Document Scope section to follow Introduction 1055 16.2. Changes from draft-ietf-02 to draft-ietf-03 1057 o Additional clarifications and corrections 1059 16.3. Changes from draft-ietf-01 to draft-ietf-02 1061 o This document now refers to [I-D.ietf-ecrit-ecall] for technical 1062 aspects including the service URN; this document no longer 1063 proposes a unique service URN for non-eCall NG-ACN calls; the same 1064 service URN is now used for all NG-ACN calls including NG-eCall 1065 and non-eCall 1066 o Added discussion of an NG-ACN call placed to a PSAP that doesn't 1067 support it 1068 o Minor wording improvements and clarifications 1070 16.4. Changes from draft-ietf-00 to draft-ietf-01 1072 o Added further discussion of test calls 1073 o Added further clarification to the document scope 1074 o Mentioned that multi-region vehicles may need to support other 1075 crash notification specifications such as eCall 1076 o Minor wording improvements and clarifications 1078 16.5. Changes from draft-gellens-02 to draft-ietf-00 1080 o Renamed from draft-gellens- to draft-ietf- 1081 o Added text to Introduction to clarify that during a CS ACN, the 1082 PSAP call taker usually needs to listen to the data and transcribe 1083 it 1085 16.6. Changes from draft-gellens-01 to -02 1087 o Fixed case of 'EmergencyCallData', in accordance with changes to 1088 [I-D.ietf-ecrit-additional-data] 1090 16.7. Changes from draft-gellens-00 to -01 1092 o Now using 'EmergencyCallData' for purpose parameter values and 1093 MIME subtypes, in accordance with changes to 1094 [I-D.ietf-ecrit-additional-data] 1095 o Added reference to RFC 6443 1096 o Fixed bug that caused Figure captions to not appear 1098 17. References 1100 17.1. Normative References 1102 [I-D.ietf-ecrit-additional-data] 1103 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1104 J. Winterbottom, "Additional Data Related to an Emergency 1105 Call", draft-ietf-ecrit-additional-data-37 (work in 1106 progress), October 2015. 1108 [I-D.ietf-ecrit-ecall] 1109 Gellens, R. and H. Tschofenig, "Next-Generation Pan- 1110 European eCall", draft-ietf-ecrit-ecall (work in 1111 progress), March 2015. 1113 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1114 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1115 RFC2119, March 1997, 1116 . 1118 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1119 Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, 1120 . 1122 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 1123 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 1124 . 1126 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1127 Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, 1128 December 2005, . 1130 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1131 Emergency and Other Well-Known Services", RFC 5031, DOI 1132 10.17487/RFC5031, January 2008, 1133 . 1135 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1136 Presence Information Data Format Location Object (PIDF-LO) 1137 Usage Clarification, Considerations, and Recommendations", 1138 RFC 5491, DOI 10.17487/RFC5491, March 2009, 1139 . 1141 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 1142 Thomson, "Dynamic Extensions to the Presence Information 1143 Data Format Location Object (PIDF-LO)", RFC 5962, DOI 1144 10.17487/RFC5962, September 2010, 1145 . 1147 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1148 "Framework for Emergency Calling Using Internet 1149 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1150 2011, . 1152 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1153 Communications Services in Support of Emergency Calling", 1154 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1155 . 1157 [VEDS] "Vehicular Emergency Data Set (VEDS) version 3", July 1158 2012, . 1161 17.2. Informative references 1163 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1164 Emergency Context Resolution with Internet Technologies", 1165 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1166 . 1168 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1169 Shanmugam, "Security Threats and Requirements for 1170 Emergency Call Marking and Mapping", RFC 5069, DOI 1171 10.17487/RFC5069, January 2008, 1172 . 1174 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1175 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1176 December 2014, . 1178 Authors' Addresses 1180 Randall Gellens 1181 Qualcomm Technologies, Inc 1182 5775 Morehouse Drive 1183 San Diego 92651 1184 US 1186 Email: rg+ietf@randy.pensive.org 1188 Brian Rosen 1189 NeuStar, Inc. 1190 470 Conrad Dr 1191 Mars, PA 16046 1192 US 1194 Email: br@brianrosen.net 1196 Hannes Tschofenig 1197 (Individual) 1199 Email: Hannes.Tschofenig@gmx.net 1200 URI: http://www.tschofenig.priv.at