idnits 2.17.1 draft-winterbottom-ecrit-priv-loc-03.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 16, 2012) is 4207 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-geopriv-deref-protocol' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC4079' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC5012' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC5774' is defined on line 718, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-geopriv-flow-identity-00 == Outdated reference: A later version (-08) exists of draft-ietf-geopriv-res-gw-lis-discovery-04 ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: A later version (-14) exists of draft-ietf-ecrit-trustworthy-location-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft CommScope 4 Updates: I-D.ietf.ecrit.phonebcp H. Tschofenig 5 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track L. Liess 7 Expires: April 19, 2013 Deutsche Telekom 8 October 16, 2012 10 Out of Jurisdiction Emergency Routing 11 draft-winterbottom-ecrit-priv-loc-03 13 Abstract 15 Some countries and regions require location information be 16 constrained to emergency service applications and do not permit 17 location information to traverse the end-point at all. This document 18 describes the requirements of these countries and provides a solution 19 based on an extension to the HELD location protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 19, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 5 58 4. Key Observations . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Available Building Blocks . . . . . . . . . . . . . . . . . . 7 60 6. The Missing Link . . . . . . . . . . . . . . . . . . . . . . . 8 61 6.1. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6.2. Domain Breakdown . . . . . . . . . . . . . . . . . . . . . 10 63 7. HELD Extensions to Support Emergency Routing Information . . . 11 64 7.1. HELD Schema Extension . . . . . . . . . . . . . . . . . . 12 65 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10.1. URN sub-namespace registration for 70 'urn:ietf:params:xml:ns:geopriv:held:eri' . . . . . . . . 14 71 10.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15 72 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 78 1. Introduction and Motivation 80 The Internet emergency calling architecture specified in 81 [I-D.ietf-ecrit-phonebcp] describes two main models for emergency 82 call processing. The first is a device-centric model, where a device 83 obtains location information using a location configuration protocol, 84 such a HELD [RFC5985], and then proceeds to determine the address of 85 the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1 86 shows this model in a simplified form. 88 +---Location Request---+ 89 | (1) | 90 +---+----+ +---V---+ 91 | |<--Location--| LIS | 92 | Caller | (2) +-------+ +--------+ 93 | | | ESRP/ | 94 | |----Find Service-------+ | PSAP | 95 +------^-+ (3) | +--------+ 96 | | +--------V----+ ^ 97 | +-----Service----| LoST Server | | 98 | (4) +-------------+ +---+---+ 99 +-------------Call Initiation------------>| VSP | 100 (5) +-------+ 102 Figure 1: Device-Centric Emergency Services Model 104 With the ever increasing deployment of smart phones and tablet 105 devices a variation of the device-centric model is the ability to use 106 location available to the device for routing and then consult a LIS 107 when location is needed for dispatch. Location can come in various 108 forms to the device, e.g., from GPS, third party location databases, 109 as well as IP-to-geolocation services. 111 The second approach is a softswitch-centric model, where a device 112 initiates and emergency call and the serving softswitch detects that 113 the call is an emergency and initiates retrieving the caller's 114 location from a Location Information Server (LIS) using HELD 115 [RFC5985] with identity extensions [RFC6155] and then determining the 116 route to the local PSAP using LoST [RFC5222]. Figure 2 shows the 117 high-level protocol interactions. 119 +---Location Request---+ 120 | (2) | 121 +---V---+ | 122 | LIS | | 123 +----+--+ +----+----+ 124 | | | 125 +----Location--->| Soft | 126 +--------+ (3) | Switch | 127 | Caller |------Call Initiation------------> | | 128 +--------+ (1) +-+-^---+-+ 129 +-------------+ | | | 130 | LoST Server |<-Find Service--+ | | 131 +------+------+ (4) | | 132 | | | 133 +----------Service--------+ | 134 (5) | 135 +-----------+ | 136 | ESRP/PSAP |<------Call----+ 137 +-----------+ (6) 139 Figure 2: Softswitch-Centric Calling Model 141 In the softswitch-centric model when a VSP receives an emergency call 142 it will encounter several difficulties. The first hurdle is for the 143 VSP to determine the correct LIS to ask for location information. 144 Having obtained the location, the VSP must then determine the correct 145 PSAP using a LoST server and this requires wide-spread deployment of 146 forest guides. This leads to a failure in the softswitch-centric 147 approach to deliver emergency calls correctly because the VSP is 148 unable to determine the correct PSAP to route the call to. The 149 softswitch-centric model should therefore seen only as a transition 150 architecture towards the end-device model where end devices have not 151 been upgraded. Software updates of end devices are, however, not a 152 problem anymore since software updates have to be provided to end 153 devices on a regular basis to patch security vulnerabilities. Any 154 service provider that does not have an ability to update devices will 155 not only put their own customers at risk but also other Internet 156 users as well since those can become the victims of attacks as well. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in [RFC2119]. 164 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 166 The term "Access Network Provider" is used as defined in [RFC5687] 167 and incompasses both the Internet Access Provider (IAP) and Internet 168 Service Provider (ISP). 170 3. Problem Description 172 There is a significant faction in the emergency services and the 173 regulatory community that do not want to rely on emergency calls 174 solutions with end-device provided location. This includes location 175 information that is determined by the network but subsequently 176 traverses the end-point prior to being delivered to the emergency 177 organization. 179 There are two concerns: 181 Security: One concern is about the possibility of the software of 182 the end device being able to tamper with location. This can lead 183 to denial of service attacks against the emergency services 184 infrastructure. [I-D.ietf-ecrit-trustworthy-location] describes 185 these concerns in detail. 187 Privacy: There is the desire to allow location information to be 188 provided to emergency organizations rather than any other party, 189 including the end device or a VSP. In the softswitch model the 190 VSP would have to ask the access provider for location 191 information. However, the number of VSPs asking for location 192 information could, at least in theory depending on the scope of 193 emergency services regulation be very large and is likely to 194 include VSPs that are located in a jurisdiction that is different 195 from the one of the access network provider. Allowing VSPs to ask 196 for location information of end devices at access network 197 providers in a third party fashion without the ability to present 198 the user's consent or the emergency service nature calls for 199 privacy problems. [RFC6155] discusses some of these privacy 200 challenges as part of the third party requests. 202 These arguments may, however, also jacked into place to hide another 203 reason, namely the desire to create an artifical relationship between 204 the VSP and the access network provider. [RFC6444] provides a 205 problem description and [I-D.ietf-ecrit-rough-loc] even offers a 206 solution based on rough location. This solutions, however, requires 207 the access network provider to compute these rough location shapes. 208 Countries that have a large number of PSAPs and neither an ESRP nor a 209 stage-1 PSAP architecture may encounter problems computing these 210 shapes. 212 The Internet calling model does not constrain the call to a single 213 jurisdictional boundary nor does it assume that the Voice Service 214 provider (VSP) role is provided by the access provider. This allows 215 the VSP to be located anywhere on the Internet without requiring any 216 association with Internet access providers. 218 +----------------+ +----------------+ +----------------+ 219 | Jurisdiction 1 | | Jurisdiction 2 | | Jurisdiction 3 | 220 | | | | | | 221 | | | | | | 222 | +--------------+--+----------------+--+--------------+ | 223 | | EMERGENCY CALL CENTRES | | 224 | +--------------+--+----------------+--+--------------+ | 225 | ^ ^ ^ | | | | | 226 | | | | | | | | | 227 | +-----+ | | | | +-----+ | | +-----+ | 228 | | VSP | | +--------| VSP | | | | VSP | | 229 | +--^--+ | | | +---^-+ | | +-----+ | 230 | | | | | | | | | 231 | +--------+-----+--+-------+--------+--+--------------+ | 232 | | | | | INTERNET | | 233 | +--------+-----+--+-----+----------+--+--------------+ | 234 | | | | | | | | | 235 | +--------+-----+--+-------+--------+--+--------------+ | 236 | | | | ACCESS | NETWORKS | | 237 | +--------------+--+-------+--------+--+--------------+ | 238 | | | | | | | | | 239 | | | +-------------+ | | | 240 | | | | | | | | | 241 | +------------+ | | | | | 242 | | EMERGENCY | | | | | | 243 | | CALLS | | | | | | 244 | +------------+ | | | | | 245 | +--------+-----+--+-----+----------+--+--------------+ | 246 | | | | DEVICES | | 247 | +--------------+--+-----+----------+--+--------------+ | 248 | | | | | | 249 +----------------+ +----------------+ +----------------+ 250 e.g US State e.g. Australia e.g. European 251 Country 253 Figure 3: Internet Calling Models 255 4. Key Observations 257 When these security and privacy requirements are taken into 258 consideration then the emergency calling architecture and associated 259 procedures described in [I-D.ietf-ecrit-phonebcp] and [RFC6443] 260 require some adaptation in some configurations to ensure universal 261 operation. The softswitch model fails to meet the privacy 262 requirements and the end-device model has to wrangle with security 263 challenges. 265 Several observations have been posed thus far: 267 Problem#1: Rough location information is required to route emergency 268 calls. 270 Problem#2: The VSP needs the ability to determine the correct LIS to 271 retrieve location information. 273 Problem#3: The VSP needs the ability to contact a LoST server to 274 acquire routing information from. 276 Problem#4: The end host does not acquire or convey location to the 277 emergency network. 279 Problem#5: Access network provider aim to provide location only to 280 emergency service authorities. 282 Problem#6: Precise location information is required to dispatch 283 first responders. 285 5. Available Building Blocks 287 To fulfill A number of building blocks are already available. There 288 is no need to start from a clean sheet. 290 Location: Location standards have existed for mobile cellular 291 networks since the mid to late 1990s, and location standards for 292 the Internet have existed since the mid to late 2000s. The exact 293 determination techniques for each access technology are different 294 but the ability to direct communications across a communications 295 network is inherenetly premised on being able to reach a specific 296 device and this requires some knowledge of where the device is 297 physically located. The term Location Information Server (LIS) is 298 used to identify the element in an access network responsible for 299 providing the location of a device in its administrative domain. 300 LIS service discovery techniques are described in [RFC5986] and 301 [I-D.ietf-geopriv-res-gw-lis-discovery]. 303 Call Routing: The LoST protocol [RFC5222] specifies a means to map 304 location and service information into a destination URI. Next 305 generation emergency services architectures and procedures, such 306 as those defined in [RFC6443], NENA i3, and the EENA NG112 307 document, use LoST for providing routing to local emergency 308 service authorities. LoST servers are discovered using DNS 309 U-NAPTR [RFC4848] to obtain a service URI. The discovered LoST 310 server services the domain in which the device is resident, or is 311 able to provide the identity of a LoST server that can service the 312 request. A access network provider that operates in an area 313 capable of receiving next generation emergency calls is able to 314 include a U-NAPTR record in their DNS servers that identifies the 315 local serving LoST server able to resolve emergency routing 316 requests. 318 LIS Discovery: [I-D.ietf-geopriv-res-gw-lis-discovery] provides a 319 means for discovering a LIS based on the IP address of a device 320 and this could be used in conjunction with [RFC6155] to provide a 321 solution to problem 2. The domain name discovered for the LIS 322 could be reused to discover the correct LoST server to contact 323 thereby solving problem 3. 325 6. The Missing Link 327 Problem 5 does not allow the LIS to provide location information 328 except to emergency authorities, and while the HELD protocol 329 [RFC5985] does allow a location URI to be returned to the requesting 330 entitiy, the LoST protocol [RFC5222] requires a location value and 331 does not support a location reference. 333 One possible solution to problem 5 is to extend LoST to support a 334 location URI in the findService request method. In this case a VSP 335 would detect that a device was making an emergency call, determine 336 the correct LIS to contact using 337 [I-D.ietf-geopriv-res-gw-lis-discovery], contact the LIS using HELD 338 [RFC5985] using the IP address of the calling device as an identity 339 extension [RFC6155] and the LIS would respond with a location URI 340 that requires client-side authentication for dereferencing Using the 341 LIS domain identifier the VSP would then determine the correct LoST 342 server and request emergency services using the location URI as the 343 location reference. The LoST server must have permission to 344 dereference the location URI, if any form of recurision is 345 encountered then the URI must be dereferenced multiple times 346 increasing the likelihood of failure. 348 An alternative approach is to leave LoST unchanged, but extend the 349 HELD protocol and requirements of the local LIS. In this solution, 350 when the LIS receives the third-party request, it performs the 351 necessary LoST request using the location of the device. The LIS 352 responds with a location URI and the destination URI of the correct 353 emergency service authority. The Location URI will only yield 354 location information to the authorized emergency authority. This 355 solution addresses problem 1 problem 3, problem 4, problem 5. 356 Problem 2 is solved using a combination of 357 [I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity 358 extensions. 360 6.1. Call Flow 362 1. Device initiates an emergency call to the user's VSP 364 2. The VSP's proxy detects emergency call and uses IP address to 365 determine the correct LIS to query using 366 [I-D.ietf-geopriv-res-gw-lis-discovery]. 368 3. The VSP queries the LIS using HELD and the IP address of the 369 calling device as an identity extension. 371 4. The LIS determines the location and uses it request routing 372 information for the local LoST server. 374 5. The LIS return a location URI and the local Emergency Service 375 Routing Proxy (ESRP) URI to the VSP. 377 6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and 378 routes the call to the ESRP. 380 7. The ESRP authenticates itself with the LIS when it dereferences 381 the location URI. 383 8. The returns location information to the ESRP allowing it route 384 the call to the correct PSAP. 386 +------(2)Find LIS-----+ 387 | | 388 +---V---+ | 389 | DNS | | 390 +----+--+ +----+---------+ 391 | | | 392 +----LIS URI---->| | 393 +--------+ | VSP | 394 | Caller |------(1)-Call Initiation--------> | | 395 +--------+ +-+--^-------+-+ 396 | | | 397 +-------------+ | | | 398 | |<------(3)-locationReq(IP)-------+ | | 399 | LIS | | | 400 | |--(5)-locationResp(locURI,EcrfURI)--+ | 401 +-+--^---+--^-+ | 402 | | | | +-------------+ | 403 | | | +-----Service----+ | | 404 | | | | LoST Server | | 405 | | +-(4)-Find Service->| | | 406 | | +-------------+ | 407 | | | 408 | | +-----------+ | 409 | +--(7)-locReq(Auth)--+ | | 410 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 411 +---(8)-locResp(Loc)--->| | 412 +-----------+ 414 Figure 4: Modified Softswitch-Centric Emergency Call Flow 416 6.2. Domain Breakdown 418 The key advantage of the call flow show in Section 6.1 is that it 419 separates the entities into two clear groups, those that are inside 420 the regulatory emergency jurisdiction and those that are in the 421 Internet. This is evident in Figure 5. 423 +------(2)Find LIS-----+ 424 | | 425 +---V---+ | 426 | DNS | | 427 +----+--+ +----+---------------+ 428 | | | 429 +----LIS URI---->| | 430 | VSP | 431 | | 432 +-^---+----^-------+-+ 433 I N T E R N E T | | | | 434 =========================================|===|====|=======|=== 435 LOCAL JURISDICTION | | | | 436 +--------+ | | | | 437 | Caller |------(1)-Call Initiation------+ | | | 438 +--------+ | | | 439 | | | 440 +-------------+ | | | 441 | |<------(3)-locationReq(IP)-----+ | | 442 | LIS | | | 443 | |--(5)-locationResp(locURI,EcrfURI)--+ | 444 +-+--^---+--^-+ | 445 | | | | +-------------+ | 446 | | | +-----Service----+ | | 447 | | | | LoST Server | | 448 | | +-(4)-Find Service->| | | 449 | | +-------------+ | 450 | | | 451 | | +-----------+ | 452 | +--(7)-locReq(Auth)--+ | | 453 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 454 +---(8)-locResp(Loc)--->| | 455 +-----------+ 457 Figure 5: Emergency Call Domains 459 7. HELD Extensions to Support Emergency Routing Information 461 Figure 4 shows the enhancements needed to support the new calling 462 model. If the LIS implements this specification then it responds as 463 shown in Figure 4, otherwise it responds with standard HELD [RFC5985] 464 [RFC6155] semantics. Consequently, the locationRequest message is 465 not modified. 467 It is recommended that the location request include a responseTime of 468 emergencyRouting to ensure that the LIS provides a response to the 469 VSP as quickly as possible. 471 When using IP related information to identify the UA to the LIS then 472 the identity information MUST be expressed using the IP flow 473 representation specified in [I-D.ietf-geopriv-flow-identity]. This 474 minimizes any issues caused by address translation entities in the 475 location path. 477 A new optional "emergencyRoutingInformation" element containing the 478 relevant destination URLs is added to the locationResponse message. 479 The list of destination URLs provided MUST conform to the same 480 contraints as the service URLs returned in the LoST protocol 481 [RFC5222] in the findServiceResponse. For clarity these constraints 482 are repreated here: 484 1. The URLs MUST be absolute URLs 486 2. The ordering of the URLs has no particular significance 488 3. Each URL scheme MUST only appear at most once 490 4. It is permissible to include both secured and regular versions of 491 a protocol 493 This specification updates the switch-centric call model in 494 [I-D.ietf-ecrit-phonebcp]. In addition to supporting the return of a 495 location value or location URI set from the LIS, the VSP MUST support 496 receiving only a location URI set and a set of URLs identifying the 497 emergency service routing proxies associated with the UA's location. 499 7.1. HELD Schema Extension 501 This section describes the schema extension to HELD. 503 504 511 512 513 514 515 516 518 520 521 522 523 524 526 528 7.2. Examples 530 Figure 6 illustrates a example that contains IP 531 flow information in the request. 533 535 537 538
192.168.1.1
539 1024 540 541 542
10.0.0.1
543 80 544 545 546 548 Figure 6: Example Location Request. 550 Figure 7 illustrates the message containing two 551 location URIs: a HTTPS and a SIP URI. Additionally, the response 552 contains routing information. 554 555 556 557 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 558 559 560 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 561 562 564 566 sip:nypd@example.com 567 sips:nypd@example.com 568 xmpp:nypd@example.com 569 571 573 Figure 7: Example Location Response 575 8. Privacy Considerations 577 [[TBD.]] 579 9. Security Considerations 581 [[TBD.]] 583 10. IANA Considerations 585 10.1. URN sub-namespace registration for 586 'urn:ietf:params:xml:ns:geopriv:held:eri' 588 This document calls for IANA to register a new XML namespace, as per 589 the guidelines in [RFC3688]. 591 URI: urn:ietf:params:xml:ns:geopriv:held:eri 593 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 594 James Winterbottom (james.winterbottom@commscope.com). 596 XML: 598 BEGIN 599 600 602 603 604 HELD Emergency Routing Information Extensions 605 606 607

Additional Element for HELD Emergency Routing Information

608

urn:ietf:params:xml:ns:geopriv:held:eri

609 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 610 with the RFC number for this specification.]] 611

See RFCXXXX.

612 613 614 END 616 10.2. XML Schema Registration 618 This section registers an XML schema as per the procedures in 619 [RFC3688]. 621 URI: urn:ietf:params:xml:schema:geopriv:held:eri 623 Registrant Contact: IETF, ECRIT working group, (ecrit@ietf.org), 624 James Winterbottom (james.Winterbottom@commscope.com). 626 The XML for this schema can be found as the entirety of 627 Section 7.1 of this document. 629 11. Acknowledgements 631 We would like to thank Wilfried Lange for sharing his views with us. 632 We would also like to thank Bruno Chatras for his review comments. 634 12. References 635 12.1. Normative References 637 [I-D.ietf-ecrit-phonebcp] 638 Rosen, B. and J. Polk, "Best Current Practice for 639 Communications Services in support of Emergency Calling", 640 draft-ietf-ecrit-phonebcp-20 (work in progress), 641 September 2011. 643 [I-D.ietf-geopriv-deref-protocol] 644 Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. 645 Thomson, "A Location Dereferencing Protocol Using HELD", 646 draft-ietf-geopriv-deref-protocol-07 (work in progress), 647 July 2012. 649 [I-D.ietf-geopriv-flow-identity] 650 Bellis, R., "Flow Identity Extension for HELD", 651 draft-ietf-geopriv-flow-identity-00 (work in progress), 652 September 2012. 654 [I-D.ietf-geopriv-res-gw-lis-discovery] 655 Thomson, M. and R. Bellis, "Location Information Server 656 (LIS) Discovery using IP address and Reverse DNS", 657 draft-ietf-geopriv-res-gw-lis-discovery-04 (work in 658 progress), September 2012. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 664 January 2004. 666 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 667 Tschofenig, "LoST: A Location-to-Service Translation 668 Protocol", RFC 5222, August 2008. 670 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 671 Location Configuration Protocol: Problem Statement and 672 Requirements", RFC 5687, March 2010. 674 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 675 RFC 5985, September 2010. 677 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 678 Location Information Server (LIS)", RFC 5986, 679 September 2010. 681 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 682 Barnes, "Use of Device Identity in HTTP-Enabled Location 683 Delivery (HELD)", RFC 6155, March 2011. 685 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 686 "Framework for Emergency Calling Using Internet 687 Multimedia", RFC 6443, December 2011. 689 12.2. Informative References 691 [I-D.ietf-ecrit-rough-loc] 692 Barnes, R. and M. Lepinski, "Using Imprecise Location for 693 Emergency Context Resolution", 694 draft-ietf-ecrit-rough-loc-05 (work in progress), 695 July 2012. 697 [I-D.ietf-ecrit-trustworthy-location] 698 Tschofenig, H., Schulzrinne, H., and B. Aboba, 699 "Trustworthy Location Information", 700 draft-ietf-ecrit-trustworthy-location-03 (work in 701 progress), April 2012. 703 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 704 10646", STD 63, RFC 3629, November 2003. 706 [RFC4079] Peterson, J., "A Presence Architecture for the 707 Distribution of GEOPRIV Location Objects", RFC 4079, 708 July 2005. 710 [RFC4848] Daigle, L., "Domain-Based Application Service Location 711 Using URIs and the Dynamic Delegation Discovery Service 712 (DDDS)", RFC 4848, April 2007. 714 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 715 Emergency Context Resolution with Internet Technologies", 716 RFC 5012, January 2008. 718 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 719 Addresses in the Presence Information Data Format Location 720 Object (PIDF-LO): Guidelines and IANA Registry 721 Definition", BCP 154, RFC 5774, March 2010. 723 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 724 A. Kuett, "Location Hiding: Problem Statement and 725 Requirements", RFC 6444, January 2012. 727 Authors' Addresses 729 James Winterbottom 730 CommScope 731 Suit 1, Level 2 732 iC Enterprise 1, Innovation Campus 733 Squires Way 734 North Wollongong, NSW 2500 735 AU 737 Phone: +61 242 212938 738 Email: james.winterbottom@commscope.com 740 Hannes Tschofenig 741 Nokia Siemens Networks 742 Linnoitustie 6 743 Espoo 02600 744 Finland 746 Phone: +358 (50) 4871445 747 Email: Hannes.Tschofenig@gmx.net 748 URI: http://www.tschofenig.priv.at 750 Laura Liess 751 Deutsche Telekom Networks 752 Deutsche Telekom Allee 7 753 Darmstadt, Hessen 64295 754 Germany 756 Phone: 757 Email: L.Liess@telekom.de 758 URI: http://www.telekom.de