idnits 2.17.00 (12 Aug 2021) /tmp/idnits45636/draft-winterbottom-ecrit-priv-loc-02.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 3503 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 637, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC4079' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC5012' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC5774' is defined on line 712, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-geopriv-deref-protocol has been published as RFC 6753 == Outdated reference: draft-ietf-geopriv-flow-identity has been published as RFC 6915 == Outdated reference: draft-ietf-geopriv-res-gw-lis-discovery has been published as RFC 7216 ** Downref: Normative reference to an Informational RFC: RFC 5687 ** Downref: Normative reference to an Informational RFC: RFC 6443 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 2 errors (**), 0 flaws (~~), 11 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 Intended status: Standards Track H. Tschofenig 5 Expires: April 19, 2013 Nokia Siemens Networks 6 L. Liess 7 Deutsche Telekom 8 October 16, 2012 10 Out of Jurisdiction Emergency Routing 11 draft-winterbottom-ecrit-priv-loc-02.txt 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 describes the enhancements needed to support the new calling 462 model. Since the VSP has no means of determining if the LIS in the 463 access network supports this modified calling model or not, there is 464 no need to modify the syntax of locationRequest message sent to the 465 LIS. The location request MUST include a responseTime of 466 emergencyRouting to ensure that the LIS provides a response to the 467 VSP as quickly as possible. When using IP related information 468 identify the UA to the LIS then the identify information MUST be 469 expressed using the IP flow representation specified in 470 [I-D.ietf-geopriv-flow-identity]. This approach ensures that any 471 issues caused by address translation entities in the path can be 472 mitigated as far as possible. It also supports the LIS returning a 473 location allowing invocation of the standard switch-centric calling 474 procedures. A new optional "emergencyRoutingInformation" element is 475 added to the locationResponse message containing the relevant 476 destination URLs. 478 The list of destination URLs provided in the 479 "emergencyRoutingInformation" element MUST conform to the same 480 contraints as the service URLs returned in the LoST [RFC5222] in the 481 findServiceResponse. For clarity these constraints are repreated 482 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 7.1. HELD Schema Extension 495 This section describes the schema extension to HELD. 497 498 505 506 507 508 509 510 512 514 515 516 517 518 520 522 7.2. Examples 524 Figure 6 illustrates a example that contains IP 525 flow information in the request. 527 529 531 532
192.168.1.1
533 1024 534 535 536
10.0.0.1
537 80 538 539 540 542 Figure 6: Example Location Request. 544 Figure 7 illustrates the message containing two 545 location URIs: a HTTPS and a SIP URI. Additionally, the response 546 contains routing information. 548 549 550 551 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 552 553 554 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com 555 556 558 560 sip:nypd@example.com 561 sips:nypd@example.com 562 xmpp:nypd@example.com 563 565 567 Figure 7: Example Location Response 569 8. Privacy Considerations 571 [[TBD.]] 573 9. Security Considerations 575 [[TBD.]] 577 10. IANA Considerations 579 10.1. URN sub-namespace registration for 580 'urn:ietf:params:xml:ns:geopriv:held:eri' 582 This document calls for IANA to register a new XML namespace, as per 583 the guidelines in [RFC3688]. 585 URI: urn:ietf:params:xml:ns:geopriv:held:eri 587 Registrant Contact: IETF, ECRIT working group (ecrit@ietf.org), 588 James Winterbottom (james.winterbottom@commscope.com). 590 XML: 592 BEGIN 593 594 596 597 598 HELD Emergency Routing Information Extensions 599 600 601

Additional Element for HELD Emergency Routing Information

602

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

603 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 604 with the RFC number for this specification.]] 605

See RFCXXXX.

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