idnits 2.17.00 (12 Aug 2021) /tmp/idnits45121/draft-winterbottom-ecrit-priv-loc-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 3595 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 480, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC4079' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC5012' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC5774' is defined on line 547, 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-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: A later version (-05) exists of draft-ietf-ecrit-rough-loc-04 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 2 errors (**), 0 flaws (~~), 12 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: January 17, 2013 Nokia Siemens Networks 6 L. Liess 7 Deutsche Telekom 8 July 16, 2012 10 Out of Jurisdiction Emergency Routing 11 draft-winterbottom-ecrit-priv-loc-01.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 January 17, 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. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction and Motivation 74 The Internet emergency calling architecture specified in 75 [I-D.ietf-ecrit-phonebcp] describes two main models for emergency 76 call processing. The first is a device-centric model, where a device 77 obtains location information using a location configuration protocol, 78 such a HELD [RFC5985], and then proceeds to determine the address of 79 the next hop closer to the local PSAP using LoST [RFC5222]. Figure 1 80 shows this model in a simplified form. 82 +---Location Request---+ 83 | (1) | 84 +---+----+ +---V---+ 85 | |<--Location--| LIS | 86 | Caller | (2) +-------+ +--------+ 87 | | | ESRP/ | 88 | |----Find Service-------+ | PSAP | 89 +------^-+ (3) | +--------+ 90 | | +--------V----+ ^ 91 | +-----Service----| LoST Server | | 92 | (4) +-------------+ +---+---+ 93 +-------------Call Initiation------------>| VSP | 94 (5) +-------+ 96 Figure 1: Device-Centric Emergency Services Model 98 With the ever increasing deployment of smart phones and tablet 99 devices a variation of the device-centric model is the ability to use 100 location available to the device for routing and then consult a LIS 101 when location is needed for dispatch. Location can come in various 102 forms to the device, e.g., from GPS, third party location databases, 103 as well as IP-to-geolocation services. 105 The second approach is a softswitch-centric model, where a device 106 initiates and emergency call and the serving softswitch detects that 107 the call is an emergency and initiates retrieving the caller's 108 location from a Location Information Server (LIS) using HELD 109 [RFC5985] with identity extensions [RFC6155] and then determining the 110 route to the local PSAP using LoST [RFC5222]. Figure 2 shows the 111 high-level protocol interactions. 113 +---Location Request---+ 114 | (2) | 115 +---V---+ | 116 | LIS | | 117 +----+--+ +----+----+ 118 | | | 119 +----Location--->| Soft | 120 +--------+ (3) | Switch | 121 | Caller |------Call Initiation------------> | | 122 +--------+ (1) +-+-^---+-+ 123 +-------------+ | | | 124 | LoST Server |<-Find Service--+ | | 125 +------+------+ (4) | | 126 | | | 127 +----------Service--------+ | 128 (5) | 129 +-----------+ | 130 | ESRP/PSAP |<------Call----+ 131 +-----------+ (6) 133 Figure 2: Softswitch-Centric Calling Model 135 In the softswitch-centric model when a VSP receives an emergency call 136 it will encounter several difficulties. The first hurdle is for the 137 VSP to determine the correct LIS to ask for location information. 138 Having obtained the location, the VSP must then determine the correct 139 PSAP using a LoST server and this requires wide-spread deployment of 140 forest guides. This leads to a failure in the softswitch-centric 141 approach to deliver emergency calls correctly because the VSP is 142 unable to determine the correct PSAP to route the call to. The 143 softswitch-centric model should therefore seen only as a transition 144 architecture towards the end-device model where end devices have not 145 been upgraded. Software updates of end devices are, however, not a 146 problem anymore since software updates have to be provided to end 147 devices on a regular basis to patch security vulnerabilities. Any 148 service provider that does not have an ability to update devices will 149 not only put their own customers at risk but also other Internet 150 users as well since those can become the victims of attacks as well. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 The terms LIS, ESRP, VSP and PSAP are used as defined in [RFC6443]. 160 The term "Access Network Provider" is used as defined in [RFC5687] 161 and incompasses both the Internet Access Provider (IAP) and Internet 162 Service Provider (ISP). 164 3. Problem Description 166 There is a significant faction in the emergency services and the 167 regulatory community that do not want to rely on emergency calls 168 solutions with end-device provided location. This includes location 169 information that is determined by the network but subsequently 170 traverses the end-point prior to being delivered to the emergency 171 organization. 173 There are two concerns: 175 Security: One concern is about the possibility of the software of 176 the end device being able to tamper with location. This can lead 177 to denial of service attacks against the emergency services 178 infrastructure. [I-D.ietf-ecrit-trustworthy-location] describes 179 these concerns in detail. 181 Privacy: There is the desire to allow location information to be 182 provided to emergency organizations rather than any other party, 183 including the end device or a VSP. In the softswitch model the 184 VSP would have to ask the access provider for location 185 information. However, the number of VSPs asking for location 186 information could, at least in theory depending on the scope of 187 emergency services regulation be very large and is likely to 188 include VSPs that are located in a jurisdiction that is different 189 from the one of the access network provider. Allowing VSPs to ask 190 for location information of end devices at access network 191 providers in a third party fashion without the ability to present 192 the user's consent or the emergency service nature calls for 193 privacy problems. [RFC6155] discusses some of these privacy 194 challenges as part of the third party requests. 196 These arguments may, however, also jacked into place to hide another 197 reason, namely the desire to create an artifical relationship between 198 the VSP and the access network provider. [RFC6444] provides a 199 problem description and [I-D.ietf-ecrit-rough-loc] even offers a 200 solution based on rough location. This solutions, however, requires 201 the access network provider to compute these rough location shapes. 202 Countries that have a large number of PSAPs and neither an ESRP nor a 203 stage-1 PSAP architecture may encounter problems computing these 204 shapes. 206 The Internet calling model does not constrain the call to a single 207 jurisdictional boundary nor does it assume that the Voice Service 208 provider (VSP) role is provided by the access provider. This allows 209 the VSP to be located anywhere on the Internet without requiring any 210 association with Internet access providers. 212 +----------------+ +----------------+ +----------------+ 213 | Jurisdiction 1 | | Jurisdiction 2 | | Jurisdiction 3 | 214 | | | | | | 215 | | | | | | 216 | +--------------+--+----------------+--+--------------+ | 217 | | EMERGENCY CALL CENTRES | | 218 | +--------------+--+----------------+--+--------------+ | 219 | ^ ^ ^ | | | | | 220 | | | | | | | | | 221 | +-----+ | | | | +-----+ | | +-----+ | 222 | | VSP | | +--------| VSP | | | | VSP | | 223 | +--^--+ | | | +---^-+ | | +-----+ | 224 | | | | | | | | | 225 | +--------+-----+--+-------+--------+--+--------------+ | 226 | | | | | INTERNET | | 227 | +--------+-----+--+-----+----------+--+--------------+ | 228 | | | | | | | | | 229 | +--------+-----+--+-------+--------+--+--------------+ | 230 | | | | ACCESS | NETWORKS | | 231 | +--------------+--+-------+--------+--+--------------+ | 232 | | | | | | | | | 233 | | | +-------------+ | | | 234 | | | | | | | | | 235 | +------------+ | | | | | 236 | | EMERGENCY | | | | | | 237 | | CALLS | | | | | | 238 | +------------+ | | | | | 239 | +--------+-----+--+-----+----------+--+--------------+ | 240 | | | | DEVICES | | 241 | +--------------+--+-----+----------+--+--------------+ | 242 | | | | | | 243 +----------------+ +----------------+ +----------------+ 244 e.g US State e.g. Australia e.g. European 245 Country 247 Figure 3: Internet Calling Models 249 4. Key Observations 251 When these security and privacy requirements are taken into 252 consideration then the emergency calling architecture and associated 253 procedures described in [I-D.ietf-ecrit-phonebcp] and [RFC6443] 254 require some adaptation in some configurations to ensure universal 255 operation. The softswitch model fails to meet the privacy 256 requirements and the end-device model has to wrangle with security 257 challenges. 259 Several observations have been posed thus far: 261 Problem#1: Rough location information is required to route emergency 262 calls. 264 Problem#2: The VSP needs the ability to determine the correct LIS to 265 retrieve location information. 267 Problem#3: The VSP needs the ability to contact a LoST server to 268 acquire routing information from. 270 Problem#4: The end host does not acquire or convey location to the 271 emergency network. 273 Problem#5: Access network provider aim to provide location only to 274 emergency service authorities. 276 Problem#6: Precise location information is required to dispatch 277 first responders. 279 5. Available Building Blocks 281 To fulfill A number of building blocks are already available. There 282 is no need to start from a clean sheet. 284 Location: Location standards have existed for mobile cellular 285 networks since the mid to late 1990s, and location standards for 286 the Internet have existed since the mid to late 2000s. The exact 287 determination techniques for each access technology are different 288 but the ability to direct communications across a communications 289 network is inherenetly premised on being able to reach a specific 290 device and this requires some knowledge of where the device is 291 physically located. The term Location Information Server (LIS) is 292 used to identify the element in an access network responsible for 293 providing the location of a device in its administrative domain. 294 LIS service discovery techniques are described in [RFC5986] and 295 [I-D.ietf-geopriv-res-gw-lis-discovery]. 297 Call Routing: The LoST protocol [RFC5222] specifies a means to map 298 location and service information into a destination URI. Next 299 generation emergency services architectures and procedures, such 300 as those defined in [RFC6443], NENA i3, and the EENA NG112 301 document, use LoST for providing routing to local emergency 302 service authorities. LoST servers are discovered using DNS 303 U-NAPTR [RFC4848] to obtain a service URI. The discovered LoST 304 server services the domain in which the device is resident, or is 305 able to provide the identity of a LoST server that can service the 306 request. A access network provider that operates in an area 307 capable of receiving next generation emergency calls is able to 308 include a U-NAPTR record in their DNS servers that identifies the 309 local serving LoST server able to resolve emergency routing 310 requests. 312 LIS Discovery: [I-D.ietf-geopriv-res-gw-lis-discovery] provides a 313 means for discovering a LIS based on the IP address of a device 314 and this could be used in conjunction with [RFC6155] to provide a 315 solution to problem 2. The domain name discovered for the LIS 316 could be reused to discover the correct LoST server to contact 317 thereby solving problem 3. 319 6. The Missing Link 321 Problem 5 does not allow the LIS to provide location information 322 except to emergency authorities, and while the HELD protocol 323 [RFC5985] does allow a location URI to be returned to the requesting 324 entitiy, the LoST protocol [RFC5222] requires a location value and 325 does not support a location reference. 327 One possible solution to problem 5 is to extend LoST to support a 328 location URI in the findService request method. In this case a VSP 329 would detect that a device was making an emergency call, determine 330 the correct LIS to contact using 331 [I-D.ietf-geopriv-res-gw-lis-discovery], contact the LIS using HELD 332 [RFC5985] using the IP address of the calling device as an identity 333 extension [RFC6155] and the LIS would respond with a location URI 334 that requires client-side authentication for dereferencing Using the 335 LIS domain identifier the VSP would then determine the correct LoST 336 server and request emergency services using the location URI as the 337 location reference. The LoST server must have permission to 338 dereference the location URI, if any form of recurision is 339 encountered then the URI must be dereferenced multiple times 340 increasing the likelihood of failure. 342 An alternative approach is to leave LoST unchanged, but extend the 343 HELD protocol and requirements of the local LIS. In this solution, 344 when the LIS receives the third-party request, it performs the 345 necessary LoST request using the location of the device. The LIS 346 responds with a location URI and the destination URI of the correct 347 emergency service authority. The Location URI will only yield 348 location information to the authorized emergency authority. This 349 solution addresses problem 1 problem 3, problem 4, problem 5. 350 Problem 2 is solved using a combination of 351 [I-D.ietf-geopriv-res-gw-lis-discovery] and HELD with identity 352 extensions. 354 6.1. Call Flow 356 1. Device initiates an emergency call to the user's VSP 358 2. The VSP's proxy detects emergency call and uses IP address to 359 determine the correct LIS to query using 360 [I-D.ietf-geopriv-res-gw-lis-discovery]. 362 3. The VSP queries the LIS using HELD and the IP address of the 363 calling device as an identity extension. 365 4. The LIS determines the location and uses it request routing 366 information for the local LoST server. 368 5. The LIS return a location URI and the local Emergency Service 369 Routing Proxy (ESRP) URI to the VSP. 371 6. The VSP follows the guidance from [I-D.ietf-ecrit-phonebcp] and 372 routes the call to the ESRP. 374 7. The ESRP authenticates itself with the LIS when it dereferences 375 the location URI. 377 8. The returns location information to the ESRP allowing it route 378 the call to the correct PSAP. 380 +------(2)Find LIS-----+ 381 | | 382 +---V---+ | 383 | DNS | | 384 +----+--+ +----+---------+ 385 | | | 386 +----LIS URI---->| | 387 +--------+ | VSP | 388 | Caller |------(1)-Call Initiation--------> | | 389 +--------+ +-+--^-------+-+ 390 | | | 391 +-------------+ | | | 392 | |<------(3)-locationReq(IP)-------+ | | 393 | LIS | | | 394 | |--(5)-locationResp(locURI,EcrfURI)--+ | 395 +-+--^---+--^-+ | 396 | | | | +-------------+ | 397 | | | +-----Service----+ | | 398 | | | | LoST Server | | 399 | | +-(4)-Find Service->| | | 400 | | +-------------+ | 401 | | | 402 | | +-----------+ | 403 | +--(7)-locReq(Auth)--+ | | 404 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 405 +---(8)-locResp(Loc)--->| | 406 +-----------+ 408 Figure 4: Modified Softswitch-Centric Emergency Call Flow 410 6.2. Domain Breakdown 412 The key advantage of the call flow show in Section 6.1 is that it 413 separates the entities into two clear groups, those that are inside 414 the regulatory emergency jurisdiction and those that are in the 415 Internet. This is evident in Figure 5. 417 +------(2)Find LIS-----+ 418 | | 419 +---V---+ | 420 | DNS | | 421 +----+--+ +----+---------------+ 422 | | | 423 +----LIS URI---->| | 424 | VSP | 425 | | 426 +-^---+----^-------+-+ 427 I N T E R N E T | | | | 428 =========================================|===|====|=======|=== 429 LOCAL JURISDICTION | | | | 430 +--------+ | | | | 431 | Caller |------(1)-Call Initiation------+ | | | 432 +--------+ | | | 433 | | | 434 +-------------+ | | | 435 | |<------(3)-locationReq(IP)-----+ | | 436 | LIS | | | 437 | |--(5)-locationResp(locURI,EcrfURI)--+ | 438 +-+--^---+--^-+ | 439 | | | | +-------------+ | 440 | | | +-----Service----+ | | 441 | | | | LoST Server | | 442 | | +-(4)-Find Service->| | | 443 | | +-------------+ | 444 | | | 445 | | +-----------+ | 446 | +--(7)-locReq(Auth)--+ | | 447 | | ESRP/PSAP |<--(6)-Call(locURI)-+ 448 +---(8)-locResp(Loc)--->| | 449 +-----------+ 451 Figure 5: Emergency Call Domains 453 7. Privacy Considerations 455 [[TBD.]] 457 8. Security Considerations 459 [[TBD.]] 461 9. IANA Considerations 463 [[TBD.]] 465 10. Acknowledgements 467 We would like to thank Wilfried Lange for sharing his views with us. 468 We would also like to thank Bruno Chatras for his review comments. 470 11. References 472 11.1. Normative References 474 [I-D.ietf-ecrit-phonebcp] 475 Rosen, B. and J. Polk, "Best Current Practice for 476 Communications Services in support of Emergency Calling", 477 draft-ietf-ecrit-phonebcp-20 (work in progress), 478 September 2011. 480 [I-D.ietf-geopriv-deref-protocol] 481 Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. 482 Thomson, "A Location Dereferencing Protocol Using HELD", 483 draft-ietf-geopriv-deref-protocol-07 (work in progress), 484 July 2012. 486 [I-D.ietf-geopriv-res-gw-lis-discovery] 487 Thomson, M. and R. Bellis, "Location Information Server 488 (LIS) Discovery using IP address and Reverse DNS", 489 draft-ietf-geopriv-res-gw-lis-discovery-03 (work in 490 progress), March 2012. 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 496 Tschofenig, "LoST: A Location-to-Service Translation 497 Protocol", RFC 5222, August 2008. 499 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 500 Location Configuration Protocol: Problem Statement and 501 Requirements", RFC 5687, March 2010. 503 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 504 RFC 5985, September 2010. 506 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 507 Location Information Server (LIS)", RFC 5986, 508 September 2010. 510 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 511 Barnes, "Use of Device Identity in HTTP-Enabled Location 512 Delivery (HELD)", RFC 6155, March 2011. 514 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 515 "Framework for Emergency Calling Using Internet 516 Multimedia", RFC 6443, December 2011. 518 11.2. Informative References 520 [I-D.ietf-ecrit-rough-loc] 521 Barnes, R. and M. Lepinski, "Using Imprecise Location for 522 Emergency Context Resolution", 523 draft-ietf-ecrit-rough-loc-04 (work in progress), 524 March 2011. 526 [I-D.ietf-ecrit-trustworthy-location] 527 Tschofenig, H., Schulzrinne, H., and B. Aboba, 528 "Trustworthy Location Information", 529 draft-ietf-ecrit-trustworthy-location-03 (work in 530 progress), April 2012. 532 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 533 10646", STD 63, RFC 3629, November 2003. 535 [RFC4079] Peterson, J., "A Presence Architecture for the 536 Distribution of GEOPRIV Location Objects", RFC 4079, 537 July 2005. 539 [RFC4848] Daigle, L., "Domain-Based Application Service Location 540 Using URIs and the Dynamic Delegation Discovery Service 541 (DDDS)", RFC 4848, April 2007. 543 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 544 Emergency Context Resolution with Internet Technologies", 545 RFC 5012, January 2008. 547 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 548 Addresses in the Presence Information Data Format Location 549 Object (PIDF-LO): Guidelines and IANA Registry 550 Definition", BCP 154, RFC 5774, March 2010. 552 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 553 A. Kuett, "Location Hiding: Problem Statement and 554 Requirements", RFC 6444, January 2012. 556 Authors' Addresses 558 James Winterbottom 559 CommScope 560 Suit 1, Level 2 561 iC Enterprise 1, Innovation Campus 562 Squires Way 563 North Wollongong, NSW 2500 564 AU 566 Phone: +61 242 212938 567 Email: james.winterbottom@commscope.com 569 Hannes Tschofenig 570 Nokia Siemens Networks 571 Linnoitustie 6 572 Espoo 02600 573 Finland 575 Phone: +358 (50) 4871445 576 Email: Hannes.Tschofenig@gmx.net 577 URI: http://www.tschofenig.priv.at 579 Laura Liess 580 Deutsche Telekom Networks 581 Deutsche Telekom Allee 7 582 Darmstadt, Hessen 64295 583 Germany 585 Phone: 586 Email: L.Liess@telekom.de 587 URI: http://www.telekom.de