idnits 2.17.1 draft-ietf-enum-softswitch-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 625. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2008) is 5770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM J. Lim 3 Internet-Draft W. Kim 4 Intended status: Informational C. Park 5 Expires: January 10, 2009 NIDA 6 L. Conroy 7 RMRL 8 July 9, 2008 10 Operational Requirements for ENUM-Based Softswitch Use 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 10, 2009. 38 Abstract 40 This document describes experiences of operational requirements and 41 several considerations for ENUM-based softswitches concerning call 42 routing between two Korean VoIP carriers, gained during the ENUM pre- 43 commercial trial hosted by National Internet Development Agency of 44 Korea (NIDA) in 2006. 46 These experiences show that an interim solution can maintain the 47 stability of on-going commercial softswitch system operations during 48 the initial stage of ENUM service, where the DNS does not have 49 sufficient data for the majority of calls. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Call Routing on Softswitch . . . . . . . . . . . . . . . . . . 4 55 3. Infrastructure ENUM trial in Korea . . . . . . . . . . . . . . 5 56 4. Operational Requirements for ENUM-based Softswitches . . . . . 6 57 4.1. Call routing cases for DNS response codes . . . . . . . . 6 58 4.1.1. Trial Policies . . . . . . . . . . . . . . . . . . . . 6 59 4.1.2. Trial ENUM Lookup Rules . . . . . . . . . . . . . . . 7 60 4.2. Call routing cases for domainparts . . . . . . . . . . . . 8 61 5. Trial Results . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6. 'e164.arpa' considerations . . . . . . . . . . . . . . . . . . 12 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction 74 ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035] 75 that converts from an E.164 [E164] number to a domain name using the 76 Naming Authority Pointer (NAPTR) [RFC3403] resource record type. 77 ENUM is able to store different service types (such as fax, email, 78 homepage, SIP, H.323 and so on), for every E.164 number. It 79 originally focused on how end-users could gain access to other end- 80 user's communications contact information through the Internet. 82 Recently, discussion on the need to update RFC 3761 has begun, to 83 ensure that the standard also works in the "Infrastructure ENUM" 84 scenario, where ENUM provides routing information between carriers. 85 This has resulted in two documents, the updated ENUM specification 86 [draft-rfc3761bis] and an Enumservice guide 87 [draft-enumservice-guide]. 89 When providing VoIP service, a VoIP carrier that wants to integrate 90 various protocols typically uses a softswitch. However, such a 91 system is still inefficient for interconnection, number portability, 92 and sharing protocol support information among carriers, because each 93 softswitch does not have complete end-to-end routing information for 94 all carriers. This information can be stored in DNS, using ENUM. 95 Therefore, carriers can expect to gain many advantages if they use 96 ENUM within the call routing functions of their softswitches. 98 To confirm these benefits and to verify the performance of ENUM- 99 enabled softswitches, NIDA cooperated with two Korean VoIP service 100 providers for an Infrastructure ENUM trial in 2006. NIDA is a non- 101 profit organization with a mandate to manage 2.8.e164.arpa. 102 (representing the +82 country code of Korea). NIDA promotes and 103 facilitates technical cooperation on a national scale between 104 partners, and this includes ENUM. During the trial, NIDA provided a 105 centralized ENUM DNS to each VoIP service provider for call routing. 106 The data used in this Infrastructure trial was also accessible to the 107 public (i.e. it was an Internet-based system, rather than a closed 108 scheme). 110 2. Call Routing on Softswitch 112 In the PSTN (Public Switched Telephone Network), hardware-based 113 switches predominate in the network. A softswitch provides similar 114 functionality, but is implemented on a computer system by software. 115 It typically has to support various signalling protocols (such as SIP 116 [RFC3261], H.323 [H323], MGCP [RFC3435], and others), to make call 117 connections for VoIP service, often on the boundary point between the 118 circuit and packet network. 120 To make a call, first of all a softswitch must discover routing 121 information. It has to process the E.164 number that comes from a 122 caller through its own routing table. The goal is to determine how 123 the call can be routed towards the callee, so that either the call 124 can be processed through the softswitch or the caller can connect to 125 the callee directly. 127 Today, call routing is often based on a prefix of the dialled number. 128 This is used very widely not only for legacy PSTN switches, but also 129 for softswitches. So, if a softswitch exclusively uses ENUM DNS for 130 call routing, then in the beginning most of the calls queried to ENUM 131 DNS would fail if there are only a small group of carriers 132 provisioning data into ENUM. However a softswitch will have a higher 133 success rate with ENUM DNS as the number of carriers grows, and so 134 the overall percentage of numbers provisioned in ENUM increases. In 135 short, ENUM as a long term solution has obvious benefits, but the 136 problem lies in migrating from today's prefix based routing towards 137 that long term ENUM-based solution. 139 3. Infrastructure ENUM trial in Korea 141 As described in Section 1, NIDA and two VoIP Service Providers built 142 ENUM-processing modules into their softswitches, interconnected these 143 via the IP network, and provisioned their trial users' numbers into a 144 centralized ENUM DNS system operated by NIDA. The carriers 145 provisioned their E.164 numbers using EPP [RFC4114] to a centralized 146 Registration Server (also operated by NIDA). Changes to the ENUM 147 data were implemented and updated to the ENUM DNS instantly, using 148 DNS Dynamic Update [RFC2136]. 150 In the trial, the EPP-based provisioning sub-system was developed and 151 operated separately from the carriers' main customer provisioning 152 systems and protocols. It was not integrated as the carriers already 153 operated their own customer provisioning systems that were totally 154 different from the EPP-based model, and (as mission-critical 155 components) those were not open to modification. 157 Call routing 158 +---------------------------------------------+ 159 | | 160 | | 161 +-----+------+ +-----------------+ +------+-----+ 162 |Softswitch A|------| ENUM DNS(+82) |------|Softswitch B| 163 +-----+------+ | (Tier1,2) | +------+-----+ 164 | +--------+--------+ | 165 +-----+------+ | +------+-----+ 166 | IP Phone A | |Dynamic update | IP Phone B | 167 +------------+ |(RFC 2136) +------------+ 168 | 169 +------------+ +--------+--------+ +------------+ 170 | EPP Client | | Registration | | EPP Client | 171 | |------| server |------| | 172 +------------+ +-----------------+ +------------+ 173 Provisioning E.164 Numbers(RFC 4114) 175 Carrier A NIDA Carrier B 177 Figure 1: Infrastructure ENUM Trial System Topology 179 4. Operational Requirements for ENUM-based Softswitches 181 4.1. Call routing cases for DNS response codes 183 To use ENUM DNS, each softswitch needs to have an ENUM module that 184 converts from an E.164 number to the ENUM domain name (as defined in 185 RFC 3761) and processes a query to ENUM DNS. This ENUM module uses 186 the algorithm specified in RFC 3761. 188 However, in the initial stage of ENUM DNS roll-out, ENUM shares call 189 routing information from a limited number of carriers. There is the 190 problem that a softswitch can't find all of the call routing 191 information it needs just using ENUM. To solve this problem, ENUM- 192 based softswitches have to follow a consistent set of rules. 194 4.1.1. Trial Policies 196 As a matter of policy in this trial, all telephone numbers in use 197 within an "ENUM only" number range (i.e. ones in which an endpoint 198 could only be reached via a URI found during an ENUM lookup of a 199 telephone number in this range, and for which there was no PSTN Point 200 of Interconnect) were arranged to return a NAPTR response. For 201 ranges in which there was a PSTN Point of Interconnect, this was not 202 required. 204 Thus no data needed to be provisioned at all into an associated ENUM 205 domain for such a number if it were possible to "reach" that number 206 via the PSTN, unless there were also an IP based Point of 207 Interconnect serving that number and the serving carrier chose to 208 make this option available. 210 In those domains in which NAPTRs for ENUM processing were 211 provisioned, these NAPTRs were always 'terminal' rules - non-terminal 212 NAPTRs were not used. If non-terminal NAPTRs were to be provisioned, 213 then the standard operation of ENUM processing might have required 214 extra DNS lookups before the set of NAPTRs for a telephone number 215 could be evaluated. The delay and indeterminacy this would introduce 216 was not considered acceptable. 218 The case where a valid URI was present is covered in Section 4.1.2 219 rule 2 A, second point. The case where an ENUM entry was not 220 provisioned for a number that had an active PSTN Point of 221 Interconnect is covered in Section 4.1.2 rule 2 B. 223 For "ENUM only" ranges, where a given number in that range was in 224 service (i.e. there was an IP based Point of Interconnect to a 225 carrier), a valid SIP or H.323 URI was always provisioned into the 226 associated ENUM domain. This is covered in Section 4.1.2 rule 2 A, 227 second point. 229 In such an "ENUM only" range, if the number was not in service, a TXT 230 record was provisioned but no valid NAPTRs would be present. This 231 ensured that a query for NAPTRs in an given (out of service, "ENUM 232 only" range) domain would succeed (i.e. return a RCODE of 0), but 233 that the number of answers would also be zero. This is covered in 234 Section 4.1.2 rule 2 A, first point. Note that this point also 235 covers the case where only NAPTRs that cannot be used to initiate a 236 call exist in such a zone. 238 Where a valid URI was provisioned, the ENUM lookup would complete by 239 returning that value for further processing. This further processing 240 is covered in Section 4.2. 242 For "ENUM only" ranges, there was a further policy requirement that 243 an IP based Point of Interconnect specified inside a NAPTR (as the 244 domainpart of a valid URI) must be accessible for all potential 245 carriers. The server could reject a subsequent SIP Invitation, but 246 its machine address had to resolve. This was intended to avoid the 247 condition where the domain name did not resolve, the softswitch logic 248 would attempt to place the call via the PSTN, and this would fail 249 and/or loop. 251 This "must resolve" requirement was not needed for numbers that had 252 an active PSTN point of Interconnect (i.e. the vast majority of 253 assigned numbers). If the domain name did not resolve, the call 254 would "drop back" to PSTN processing. 256 4.1.2. Trial ENUM Lookup Rules 258 In the Korean trial, the rules were: 260 1. The ENUM module of the softswitch converts an E.164 number coming 261 from the VoIP subscriber to an ENUM domain name (as defined in 262 RFC 3761). 264 2. The ENUM module, acting as a DNS stub resolver, sends a query to 265 a recursive name server. 267 3. if the ENUM module receives a DNS answer, the call routing 268 process may branch off in several ways, depending on the Rcode 269 value in the DNS response message, as shown below. 271 A. Rcode=0 (No error condition) 272 There is, potentially, an answer to the corresponding query. 273 The normal call routing process needs to differentiate 274 between the following conditions: 276 + The response includes no URI (such as SIP or H.323) that 277 can be used to initiate a call - 278 The call fails immediately. 279 Note: In the trial, the condition in which a telephone 280 number is valid, can only be reached via the Internet, but 281 is not currently in service is indicated by an ENUM domain 282 that DOES exist but DOES NOT include any supported 283 (routable) NAPTRs. A softswitch receiving this response 284 interprets it as indicating that the call can be dropped 285 immediately - it would fail if passed to the PSTN. 287 + There is at least one usable URI (such as SIP and/or H.323 288 URIs) - 289 The softswitch picks one based on the preference and order 290 values in the NAPTR Resource Record Set, and routes the 291 call using the method described in Section 4.2. 293 B. Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4 294 (Not Implemented) or 5 (Refused) 295 There is no valid answer for the query. 296 The softswitch has no choice but to route the call using the 297 E.164 number with its vendor-specific method (such as a 298 prefix-based method). In this case, it means that the call 299 has to be delivered through the PSTN for onward call routing. 301 It is also important to stress that the ENUM DNS servers must 302 respond to all queries they receive from the softswitches. 303 If the ENUM module in a softswitch does not receive a 304 response, it will eventually time out, and the ENUM module 305 will treat this as a DNS error. However, the delay involved 306 is long in terms of the normal call setup time, and should be 307 avoided. 308 It would have been possible to modify the DNS code in each 309 softswitch to have shorter time-outs than normal to cover 310 misconfiguration of a DNS server, but this choice was not 311 considered in the trial. The softswitch DNS stack was used 312 for several purposes other than "pure" ENUM lookups. 313 Configuring it in a non-complaint manner was considered 314 unacceptable, due to the need to analyze the impact of that 315 choice on other DNS operations thoroughly before it could be 316 implemented safely. 318 4.2. Call routing cases for domainparts 320 If the DNS response has a valid URI such as SIP or H.323, the 321 softswitch can resolve the domain name part of that URI to route a 322 call by searching two different sources. One is a recursive 323 nameserver, and the other is a fixed routing table held in the 324 softswitch, mapping from the domain name to the corresponding 325 gateway's host name and IP address. 327 If there are many points of interconnection, using a recursive 328 nameserver is useful for resolving a domain name, but if there are 329 just a few known carriers and they do not change this interconnection 330 information frequently, a fixed (internal) routing table mapping from 331 domain name to the corresponding gateway hostname and IP address is 332 more efficient (rather than querying the recursive nameserver every 333 time). In addition, carriers would like to charge an interconnection 334 fee for all received calls, so they tend to make interconnection only 335 with trusted carriers based on some sort of bilateral agreement 336 between these carriers. They may agree on a specific gateway for 337 this purpose, so the interconnection information is often private to 338 the parties of this particular agreement. 340 In principle, these two approaches could be used in parallel, but in 341 practice if the DNS-based approach could be used, there would be no 342 point in retaining the expensive and elaborate "offline" 343 infrastructure to exchange and install the tables for domain routing. 344 In this trial, uncertainty over the performance and reliability of 345 ENUM-based processing meant that the softswtitches were configured so 346 that they could be switched between the two approaches immediately. 347 This was a temporary expedient only, and would not be a reasonable 348 approach in the long term. 350 These two types of domain routing are also affected by the Rcode=0 351 case described in Section 4.1. 353 There are two choices for routing. These are described and compared 354 here: 356 1. Case when using a fixed routing table: 358 A. If the domain name part of the URI is found in the internal 359 fixed routing table, the softswitch can use it. 361 B. If the domain name part of URI does not exist in the fixed 362 routing table, the call is forwarded to the PSTN. 364 2. Case when using a recursive nameserver: 366 A. If the domain name part of the URI can be resolved via the 367 recursive nameserver, the softswitch can use it. 369 B. If the domain name part of the URI cannot be resolved on the 370 recursive nameserver for any reason (such as a response with 371 no usable resource records according to [RFC3263] and 373 [RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be 374 forwarded to the PSTN. 376 Case (1) seems inefficient because the administrator maintains two 377 management points for numbers; the ENUM DNS and the softswitch 378 itself. However this configuration can minimize the call routing 379 failure ratio during the transition period of ENUM (when there are 380 relatively few provisioned ENUM entries and so few IP-based Points Of 381 Interconnection). Thus case (1) could reasonably be implemented on 382 the softswitches during the trial phase, and hereafter as ENUM 383 entries are populated, case (2) would be a reasonable choice. 385 With these choices, the two carriers could use ENUM DNS for call 386 routing without any impact on their on-going commercial VoIP service. 388 5. Trial Results 390 To provide a stable commercial service, an ENUM-based softswitch must 391 have a defined performance, in the same way as must any non-ENUM- 392 based softswitch. The only difference between these two types of 393 softswitch is the searching mechanism for call routing information, 394 which can be stored in the softswitch itself or in the DNS. 395 Therefore a similar delay time for call routing is important to 396 guarantee quality of service. During the trial, each carrier 397 measured this delay time when using the SIP protocol. This was based 398 on the "Answer Delay time", defined as the elapsed time between 399 requesting a call ('INVITE' message) and receiving a response ('200 400 OK' message) [RFC3261]. 402 +------------------------+------+----------+ 403 | Call Type | ENUM | Non-ENUM | 404 +------------------------+------+----------+ 405 | Carrier A->A | 2.33 | 2.28 | 406 | | | | 407 | Carrier A->B | 2.23 | 2.25 | 408 | | | | 409 | Carrier A->other(PSTN) | 4.11 | 3.79 | 410 | | | | 411 | Carrier B->B | 2.18 | 2.05 | 412 | | | | 413 | Carrier B->A | 2.19 | 2.19 | 414 | | | | 415 | Carrier B->other(PSTN) | 3.95 | 3.41 | 416 +------------------------+------+----------+ 418 Table 1: Average Answer Delay time (sec) 420 As shown in Table 1, there is little difference in time (under a 421 second) between the ENUM and non-ENUM cases. Therefore it is 422 difficult for a caller with either carrier to detect the choice (ENUM 423 or non-ENUM) as an aspect of quality when a call initiates. This 424 means that ENUM definitely works well with softswitches on a 425 commercial basis. 427 To make the trial more realistic, the resolver that was used by these 428 ENUM-based softswitches was a recursive nameserver that could be 429 accessed publicly. This was done as it was felt that a tough 430 condition would be better to verify the fact that an ENUM-based 431 softswitch works as well as non-ENUM-based softswitch in providing a 432 commercial VoIP service. 434 6. 'e164.arpa' considerations 436 During the trial, the Infrastructure ENUM deployed in the 437 2.8.e164.arpa zone could be accessed via the (public) Internet. In 438 this situation, each carrier questioned whether the centralized 439 number management under the ENUM DNS was realistic or not. 441 Another issue concerned responsibility for routing errors. All 442 carriers can use the shared ENUM data to route their calls. However, 443 if there are routing errors (due to the data being provisioned 444 incorrectly), it is not always clear who has responsibility for these 445 errors and who can correct the data. The errors occur in the 446 networks of the carriers placing the calls. Unless the identity of 447 the carrier responsible for delivering service to this telephone 448 number is known, it is not obvious (to the carrier handling the 449 error) who should be informed of these problems. This is a 450 particular issue when number portability is introduced. 452 In addition, the carriers also question whether or not Infrastructure 453 ENUM needs to be accessible publicly. To prevent disclosure of 454 telephone numbers, they would prefer to access the ENUM DNS 455 privately. Therefore any ENUM module embedded in a softswitch needs 456 to be flexible, to adopt these considerations during the interim 457 period of ENUM, before common policies and agreements have been 458 forged. 460 7. Security Considerations 462 This document inherits the security considerations described in RFC 463 3761 and [RFC5067], as the ENUM DNS used with softswitches in this 464 trial could be accessed publicly. 466 In addition, if the recursive resolvers handling ENUM queries coming 467 from a softswitch were to be compromised by an attacker, that 468 attacker would be able to force calls to fail or cause delay to 469 calls. Therefore, the DNS resolvers used should allow access from 470 the local network to which the softswitch is connected, whilst 471 restricting access from outside, using a proper access-list policy. 473 8. IANA Considerations 475 This document is only advisory, and does not have any IANA 476 considerations. 478 9. Acknowledgements 480 Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim 481 Reid and Otmar Lendl who helped guide the direction of this document, 482 and to Suresh Krishnan, whose GEN-ART review was very helpful. 484 10. References 486 10.1. Normative References 488 [E164] ITU-T, "The International Public Telecommunication Number 489 Plan", Recommendation E.164, February 2005. 491 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 492 RFC 1034, November 1987. 494 [RFC1035] Mockapetris, P., "Domain names - implementation and 495 specification", STD 13, RFC 1035, November 1987. 497 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 498 Part Three: The Domain Name System (DNS) Database", 499 RFC 3403, October 2002. 501 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 502 Resource Identifiers (URI) Dynamic Delegation Discovery 503 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 505 10.2. Informative References 507 [H323] ITU-T, "Packet-based multimedia communications systems", 508 Recommendation H.323, 2003. 510 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 511 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 512 RFC 2136, April 1997. 514 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 515 A., Peterson, J., Sparks, R., Handley, M., and E. 516 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 517 June 2002. 519 [RFC3263] Rosenberg, J., "Session Initiation Protocol (SIP): 520 Locating SIP Servers", RFC 3263, June 2002. 522 [RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control 523 Protocol (MGCP) Version 1.0", RFC 3435, January 2003. 525 [RFC4114] Hollenbeck, S., "E.164 Number Mapping for the Extensible 526 Provisioning Protocol (EPP)", RFC 4114, June 2005. 528 [RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM 529 Requirements", RFC 5067, November 2007. 531 [draft-enumservice-guide] 532 Hoeneisen, B., Mayrhofer, A., and J. Livingood, "Guide and 533 Template for IANA Registrations of Enumservices", 534 draft-ietf-enum-enumservices-guide-10.txt (work in 535 progress), May 2008. 537 [draft-rfc3761bis] 538 Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 539 Uniform Resource Identifiers (URI) Dynamic Delegation 540 Discovery System (DDDS) Application (ENUM)", 541 draft-ietf-enum-rfc3761bis-03.txt (work in progress), 542 February 2008. 544 Authors' Addresses 546 JoonHyung Lim 547 National Internet Development Agency of Korea(NIDA) 548 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu 549 Seoul 550 Korea 552 Phone: +82-2-2186-4548 553 Email: jhlim@nida.or.kr 554 URI: http://www.nida.or.kr 556 Weon Kim 557 National Internet Development Agency of Korea(NIDA) 558 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu 559 Seoul 560 Korea 562 Phone: +82-2-2186-4502 563 Email: wkim@nida.or.kr 564 URI: http://www.nida.or.kr 566 ChanKi Park 567 National Internet Development Agency of Korea(NIDA) 568 3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu 569 Seoul 570 Korea 572 Phone: +82-2-2186-4504 573 Email: ckp@nida.or.kr 574 URI: http://www.nida.or.kr 576 Lawrence Conroy 577 Roke Manor Research 578 Roke Manor 579 Old Salisbury Lane 580 Romsey 581 United Kingdom 583 Phone: +44-1794-833666 584 Email: lconroy@insensate.co.uk 585 URI: http://www.sienum.co.uk 587 Full Copyright Statement 589 Copyright (C) The IETF Trust (2008). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 598 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 599 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 600 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 Intellectual Property 605 The IETF takes no position regarding the validity or scope of any 606 Intellectual Property Rights or other rights that might be claimed to 607 pertain to the implementation or use of the technology described in 608 this document or the extent to which any license under such rights 609 might or might not be available; nor does it represent that it has 610 made any independent effort to identify any such rights. Information 611 on the procedures with respect to rights in RFC documents can be 612 found in BCP 78 and BCP 79. 614 Copies of IPR disclosures made to the IETF Secretariat and any 615 assurances of licenses to be made available, or the result of an 616 attempt made to obtain a general license or permission for the use of 617 such proprietary rights by implementers or users of this 618 specification can be obtained from the IETF on-line IPR repository at 619 http://www.ietf.org/ipr. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights that may cover technology that may be required to implement 624 this standard. Please address the information to the IETF at 625 ietf-ipr@ietf.org.