doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc5346.txt b/doc/rfc/rfc5346.txt
new file mode 100644
index 0000000..308783d
--- /dev/null
+++ b/doc/rfc/rfc5346.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                             J. Lim
+Request for Comments: 5346                                        W. Kim
+Category: Informational                                          C. Park
+                                                                    NIDA
+                                                               L. Conroy
+                                                                    RMRL
+                                                            October 2008
+
+
+         Operational Requirements for ENUM-Based Softswitch Use
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   This document describes experiences of operational requirements and
+   several considerations for ENUM-based softswitches concerning call
+   routing between two Korean Voice over IP (VoIP) carriers, gained
+   during the ENUM pre-commercial trial hosted by the National Internet
+   Development Agency of Korea (NIDA) in 2006.
+
+   These experiences show that an interim solution can maintain the
+   stability of ongoing commercial softswitch system operations during
+   the initial stage of ENUM service, where the DNS does not have
+   sufficient data for the majority of calls.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Call Routing on Softswitch . . . . . . . . . . . . . . . . . .  2
+   3.  Infrastructure ENUM Trial in Korea . . . . . . . . . . . . . .  3
+   4.  Operational Requirements for ENUM-Based Softswitches . . . . .  4
+     4.1.  Call Routing Cases for DNS Response Codes  . . . . . . . .  4
+       4.1.1.  Trial Policies . . . . . . . . . . . . . . . . . . . .  4
+       4.1.2.  Trial ENUM Lookup Rules  . . . . . . . . . . . . . . .  6
+     4.2.  Call Routing Cases for Domainparts . . . . . . . . . . . .  7
+   5.  Trial Results  . . . . . . . . . . . . . . . . . . . . . . . .  9
+   6.  'e164.arpa' Considerations . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
+     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+Lim, et al.                  Informational                      [Page 1]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+1.  Introduction
+
+   ENUM [RFC3761] is a mapping system based on DNS [RFC1034] [RFC1035]
+   that converts from an E.164 [E164] number to a domain name using the
+   Naming Authority Pointer (NAPTR) [RFC3403] resource record type.
+   ENUM is able to store different service types (such as fax, email,
+   homepage, SIP, H.323 and so on) for every E.164 number.  It
+   originally focused on how end-users could gain access to other end-
+   users' communication contact information through the Internet.
+
+   Recently, discussion on the need to update RFC 3761 has begun to
+   ensure that the standard also works in the "Infrastructure ENUM"
+   scenario, where ENUM provides routing information between carriers.
+   This resulted in two documents, the updated ENUM specification
+   [RFC3761bis] and an Enumservice guide [ENUMSERVICE-GUIDE].
+
+   When providing VoIP service, a VoIP carrier that wants to integrate
+   various protocols typically uses a softswitch.  However, such a
+   system is still inefficient for interconnection, number portability,
+   and sharing protocol support information among carriers, because each
+   softswitch does not have complete end-to-end routing information for
+   all carriers.  This information can be stored in DNS, using ENUM.
+   Therefore, carriers can expect to gain many advantages if they use
+   ENUM within the call routing functions of their softswitches.
+
+   To confirm these benefits and to verify the performance of ENUM-
+   enabled softswitches, NIDA cooperated with two Korean VoIP service
+   providers for an Infrastructure ENUM trial in 2006.  NIDA is a non-
+   profit organization with a mandate to manage 2.8.e164.arpa.
+   (representing the +82 country code of Korea).  NIDA promotes and
+   facilitates technical cooperation on a national scale between
+   partners, and this includes ENUM.  During the trial, NIDA provided a
+   centralized ENUM DNS to each VoIP service provider for call routing.
+   The data used in this Infrastructure trial was also accessible to the
+   public (i.e., it was an Internet-based system, rather than a closed
+   scheme).
+
+2.  Call Routing on Softswitch
+
+   In the PSTN (Public Switched Telephone Network), hardware-based
+   switches predominate.  A softswitch provides similar functionality,
+   but is implemented on a computer system by software.  It typically
+   has to support various signalling protocols (such as SIP [RFC3261],
+   H.323 [H323], Media Gateway Control Protocol (MGCP) [RFC3435], and
+   others) to make call connections for VoIP service, often on the
+   boundary point between the circuit and packet network.
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 2]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   To make a call, first of all a softswitch must discover routing
+   information.  It has to process the E.164 number that comes from a
+   caller through its own routing table.  The goal is to determine how
+   the call can be routed towards the callee, so that either the call
+   can be processed through the softswitch or the caller can connect to
+   the callee directly.
+
+   Today, call routing is often based on a prefix of the dialled number.
+   This is used very widely not only for legacy PSTN switches, but also
+   for softswitches.  So, if a softswitch exclusively uses ENUM DNS for
+   call routing, then, in the beginning most of the calls queried to
+   ENUM DNS would fail if there are only a small group of carriers
+   provisioning data into ENUM.  However, a softswitch will have a
+   higher success rate with ENUM DNS as the number of carriers grows,
+   and so the overall percentage of numbers provisioned in ENUM
+   increases.  In short, ENUM as a long-term solution has obvious
+   benefits, but the problem lies in migrating from today's prefix-based
+   routing towards that long-term ENUM-based solution.
+
+3.  Infrastructure ENUM Trial in Korea
+
+   As described in Section 1, NIDA and two VoIP service providers built
+   ENUM-processing modules into their softswitches, interconnected these
+   via the IP network, and provisioned their trial users' numbers into a
+   centralized ENUM DNS system operated by NIDA.  The carriers
+   provisioned their E.164 numbers using Extensible Provisioning
+   Protocol (EPP) [RFC4114] to a centralized Registration Server (also
+   operated by NIDA).  Changes to the ENUM data were implemented and
+   updated to the ENUM DNS instantly, using DNS Dynamic Update
+   [RFC2136].
+
+   In the trial, the EPP-based provisioning sub-system was developed and
+   operated separately from the carriers' main customer provisioning
+   systems and protocols.  It was not integrated, as the carriers
+   already operated their own customer provisioning systems that were
+   totally different from the EPP-based model, and (as mission-critical
+   components) those were not open to modification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 3]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+                                    Call routing
+                  +---------------------------------------------+
+                  |                                             |
+                  |                                             |
+            +-----+------+      +-----------------+      +------+-----+
+            |Softswitch A|------|  ENUM DNS(+82)  |------|Softswitch B|
+            +-----+------+      |    (Tier1,2)    |      +------+-----+
+                  |             +--------+--------+             |
+            +-----+------+               |               +------+-----+
+            | IP Phone A |               |Dynamic Update | IP Phone B |
+            +------------+               |(RFC 2136)     +------------+
+                                         |
+            +------------+      +--------+--------+      +------------+
+            | EPP Client |      |  Registration   |      | EPP Client |
+            |            |------|     Server      |------|            |
+            +------------+      +-----------------+      +------------+
+                       Provisioning E.164 Numbers(RFC 4114)
+
+              Carrier A                 NIDA                Carrier B
+
+            Figure 1: Infrastructure ENUM Trial System Topology
+
+4.  Operational Requirements for ENUM-Based Softswitches
+
+4.1.  Call Routing Cases for DNS Response Codes
+
+   To use ENUM DNS, each softswitch needs to have an ENUM module that
+   converts from an E.164 number to the ENUM domain name (as defined in
+   RFC 3761) and processes a query to ENUM DNS.  This ENUM module uses
+   the algorithm specified in RFC 3761.
+
+   However, in the initial stage of ENUM DNS roll-out, ENUM shares call
+   routing information from a limited number of carriers.  There is the
+   problem that a softswitch can't find all of the call routing
+   information it needs just using ENUM.  To solve this problem, ENUM-
+   based softswitches have to follow a consistent set of rules.
+
+4.1.1.  Trial Policies
+
+   As a matter of policy in this trial, all telephone numbers in use
+   within an "ENUM only" number range (i.e., ones in which an endpoint
+   could only be reached via a URI found during an ENUM lookup of a
+   telephone number in this range, and for which there was no PSTN Point
+   of Interconnect) were arranged to return a NAPTR response.  For
+   ranges in which there was a PSTN Point of Interconnect, this was not
+   required.
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 4]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   Thus, no data (at all) needed to be provisioned into an associated
+   ENUM domain for such a number if it were possible to "reach" that
+   number via the PSTN, unless there were also an IP-based Point of
+   Interconnect serving that number and the serving carrier chose to
+   make this option available.
+
+   In those domains in which NAPTRs for ENUM processing were
+   provisioned, these NAPTRs were always 'terminal' rules -- non-
+   terminal NAPTRs were not used.  If non-terminal NAPTRs were to be
+   provisioned, then the standard operation of ENUM processing might
+   have required extra DNS lookups before the set of NAPTRs for a
+   telephone number could be evaluated.  The delay and indeterminacy
+   this would introduce was not considered acceptable.
+
+   The case where a valid URI was present is covered in Section 4.1.2
+   (rule 2 A, second point).  The case where an ENUM entry was not
+   provisioned for a number that had an active PSTN Point of
+   Interconnect is covered in Section 4.1.2 (rule 2 B).
+
+   For "ENUM only" ranges, where a given number in that range was in
+   service (i.e., there was an IP-based Point of Interconnect to a
+   carrier), a valid SIP or H.323 URI was always provisioned into the
+   associated ENUM domain.  This is covered in Section 4.1.2 (rule 2 A,
+   second point).
+
+   In such an "ENUM only" range, if the number was not in service, a TXT
+   record was provisioned but no valid NAPTRs would be present.  This
+   ensured that a query for NAPTRs in a given (out of service, "ENUM
+   only" range) domain would succeed (i.e., return a RCODE of 0), but
+   that the number of answers would also be zero.  This is covered in
+   Section 4.1.2 (rule 2 A, first point).  Note that this point also
+   covers the case where only NAPTRs that cannot be used to initiate a
+   call exist in such a zone.
+
+   Where a valid URI was provisioned, the ENUM lookup would complete by
+   returning that value for further processing.  This further processing
+   is covered in Section 4.2.
+
+   For "ENUM only" ranges, there was a further policy requirement that
+   an IP-based Point of Interconnect specified inside a NAPTR (as the
+   domainpart of a valid URI) must be accessible for all potential
+   carriers.  The server could reject a subsequent SIP Invitation, but
+   its machine address had to resolve.  This was intended to avoid the
+   condition where the domain name did not resolve, the softswitch logic
+   would attempt to place the call via the PSTN, and this would fail
+   and/or loop.
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 5]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   This "must resolve" requirement was not needed for numbers that had
+   an active PSTN Point of Interconnect (i.e., the vast majority of
+   assigned numbers).  If the domain name did not resolve, the call
+   would "drop back" to PSTN processing.
+
+4.1.2.  Trial ENUM Lookup Rules
+
+   In the Korean trial, the rules were:
+
+   1.  The ENUM module of the softswitch converts an E.164 number coming
+       from the VoIP subscriber to an ENUM domain name (as defined in
+       RFC 3761).
+
+   2.  The ENUM module, acting as a DNS stub resolver, sends a query to
+       a recursive name server.
+
+   3.  If the ENUM module receives a DNS answer, the call routing
+       process may branch off in several ways, depending on the Rcode
+       value in the DNS response message, as shown below.
+
+       A.  Rcode=0 (No error condition)
+           There is, potentially, an answer to the corresponding query.
+           The normal call routing process needs to differentiate
+           between the following conditions:
+
+           +  The response includes no URI (such as SIP or H.323) that
+              can be used to initiate a call --
+              The call fails immediately.
+              Note: In the trial, the condition in which a telephone
+              number:
+
+              -  is valid,
+
+              -  can only be reached via the Internet, but
+
+              -  is not currently in service
+
+              is indicated by an ENUM domain that DOES exist but DOES
+              NOT include any supported (routable) NAPTRs.  A softswitch
+              receiving this response interprets it as indicating that
+              the call can be dropped immediately -- it would fail if
+              passed to the PSTN.
+
+           +  There is at least one usable URI (such as SIP and/or H.323
+              URIs) --
+              The softswitch picks one based on the preference and order
+              field values in the NAPTR Resource Record Set, and routes
+              the call using the method described in Section 4.2.
+
+
+
+Lim, et al.                  Informational                      [Page 6]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+       B.  Rcode=3 (Name error), 1 (Format Error), 2 (Server Failure), 4
+           (Not Implemented), or 5 (Refused)
+           There is no valid answer for the query.
+           The softswitch has no choice but to route the call using the
+           E.164 number with its vendor-specific method (such as a
+           prefix-based method).  In this case, it means that the call
+           has to be delivered through the PSTN for onward call routing.
+
+           It is also important to stress that the ENUM DNS servers must
+           respond to all queries they receive from the softswitches.
+           If the ENUM module in a softswitch does not receive a
+           response, it will eventually time out, and the ENUM module
+           will treat this as a DNS error.  However, the delay involved
+           is long in terms of the normal call setup time, and should be
+           avoided.
+           It would have been possible to modify the DNS code in each
+           softswitch to have shorter time-outs than normal to cover
+           misconfiguration of a DNS server, but this choice was not
+           considered in the trial.  The softswitch DNS stack was used
+           for several purposes other than "pure" ENUM lookups.
+           Configuring it in a non-complaint manner was considered
+           unacceptable, due to the need to analyze the impact of that
+           choice on other DNS operations thoroughly before it could be
+           implemented safely.
+
+4.2.  Call Routing Cases for Domainparts
+
+   If the DNS response has a valid URI, such as SIP or H.323, the
+   softswitch can resolve the domain name part of that URI to route a
+   call by searching two different sources.  One is a recursive
+   nameserver, and the other is a fixed routing table held in the
+   softswitch, mapping from the domain name to the corresponding
+   gateway's host name and IP address.
+
+   If there are many points of interconnection, using a recursive
+   nameserver is useful for resolving a domain name, but if there are
+   just a few known carriers and they do not change this interconnection
+   information frequently, a fixed (internal) routing table mapping from
+   domain name to the corresponding gateway hostname and IP address is
+   more efficient (rather than querying the recursive nameserver every
+   time).  In addition, carriers would like to charge an interconnection
+   fee for all received calls, so they tend to make interconnection only
+   with trusted carriers based on some sort of bilateral agreement
+   between these carriers.  They may agree on a specific gateway for
+   this purpose, so the interconnection information is often private to
+   the parties of this particular agreement.
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 7]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   In principle, these two approaches could be used in parallel, but in
+   practice, if the DNS-based approach could be used, there would be no
+   point in retaining the expensive and elaborate "offline"
+   infrastructure to exchange and install the tables for domain routing.
+   In this trial, uncertainty over the performance and reliability of
+   ENUM-based processing meant that the softswtitches were configured so
+   that they could be switched between the two approaches immediately.
+   This was a temporary expedient only, and would not be a reasonable
+   approach in the long term.
+
+   These two types of domain routing are also affected by the Rcode=0
+   case described in Section 4.1.
+
+   There are two choices for routing.  These are described and compared
+   here:
+
+   1.  Case when using a fixed routing table:
+
+       A.  If the domain name part of the URI is found in the internal
+           fixed routing table, the softswitch can use it.
+
+       B.  If the domain name part of the URI does not exist in the
+           fixed routing table, the call is forwarded to the PSTN.
+
+   2.  Case when using a recursive nameserver:
+
+       A.  If the domain name part of the URI can be resolved via the
+           recursive nameserver, the softswitch can use it.
+
+       B.  If the domain name part of the URI cannot be resolved on the
+           recursive nameserver for any reason (such as a response with
+           no usable resource records according to [RFC3263] and
+           [RFC3261], or with Rcode=1, 2, 3, 4, or 5), the call must be
+           forwarded to the PSTN.
+
+   Case (1) seems inefficient because the administrator maintains two
+   management points for numbers: the ENUM DNS and the softswitch
+   itself.  However, this configuration can minimize the call routing
+   failure ratio during the transition period of ENUM (when there are
+   relatively few provisioned ENUM entries and so few IP-based Points Of
+   Interconnection).  Thus, case (1) could reasonably be implemented on
+   the softswitches during the trial phase, and thereafter, as ENUM
+   entries are populated, case (2) would be a reasonable choice.
+
+   With these choices, the two carriers could use ENUM DNS for call
+   routing without any impact on their ongoing commercial VoIP service.
+
+
+
+
+
+Lim, et al.                  Informational                      [Page 8]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+5.  Trial Results
+
+   To provide a stable commercial service, an ENUM-based softswitch must
+   have a defined performance, in the same way as must any non-ENUM-
+   based softswitch.  The only difference between these two types of
+   softswitches is the searching mechanism for call routing information,
+   which can be stored in the softswitch itself or in the DNS.
+   Therefore, a similar delay time for call routing is important to
+   guarantee quality of service.  During the trial, each carrier
+   measured this delay time when using the SIP protocol.  This was based
+   on the "Answer Delay time", defined as the elapsed time between
+   requesting a call ('INVITE' message) and receiving a response ('200
+   OK' message) [RFC3261].
+
+               +------------------------+------+----------+
+               |        Call Type       | ENUM | Non-ENUM |
+               +------------------------+------+----------+
+               |      Carrier A->A      | 2.33 |   2.28   |
+               |      Carrier A->B      | 2.23 |   2.25   |
+               | Carrier A->other(PSTN) | 4.11 |   3.79   |
+               |      Carrier B->B      | 2.18 |   2.05   |
+               |      Carrier B->A      | 2.19 |   2.19   |
+               | Carrier B->other(PSTN) | 3.95 |   3.41   |
+               +------------------------+------+----------+
+
+                 Table 1: Average Answer Delay Time (Sec)
+
+   As shown in Table 1, there is little difference in time (under a
+   second) between the ENUM and non-ENUM cases.  Therefore, it is
+   difficult for a caller with either carrier to detect the choice (ENUM
+   or non-ENUM) as an aspect of quality when a call initiates.  This
+   means that ENUM definitely works well with softswitches on a
+   commercial basis.
+
+   To make the trial more realistic, the resolver that was used by these
+   ENUM-based softswitches was a recursive nameserver that could be
+   accessed publicly.  This was done as it was felt that a tough
+   condition would be better to verify the fact that an ENUM-based
+   softswitch works as well as a non-ENUM-based softswitch in providing
+   a commercial VoIP service.
+
+6.  'e164.arpa' Considerations
+
+   During the trial, the Infrastructure ENUM deployed in the
+   2.8.e164.arpa zone could be accessed via the (public) Internet.  In
+   this situation, each carrier questioned whether or not the
+   centralized number management under the ENUM DNS was realistic.
+
+
+
+
+Lim, et al.                  Informational                      [Page 9]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   Another issue concerned responsibility for routing errors.  All
+   carriers can use the shared ENUM data to route their calls.  However,
+   if there are routing errors (due to the data being provisioned
+   incorrectly), it is not always clear who has responsibility for these
+   errors and who can correct the data.  The errors occur in the
+   networks of the carriers placing the calls.  Unless the identity of
+   the carrier responsible for delivering service to this telephone
+   number is known, it is not obvious (to the carrier handling the
+   error) who should be informed of these problems.  This is a
+   particular issue when number portability is introduced.
+
+   In addition, the carriers also question whether or not Infrastructure
+   ENUM needs to be accessible publicly.  To prevent disclosure of
+   telephone numbers, they would prefer to access the ENUM DNS
+   privately.  Therefore, any ENUM module embedded in a softswitch needs
+   to be flexible to adopt these considerations during the interim
+   period of ENUM, before common policies and agreements have been
+   forged.
+
+7.  Security Considerations
+
+   This document inherits the security considerations described in RFC
+   3761 and [RFC5067], as the ENUM DNS used with softswitches in this
+   trial could be accessed publicly.
+
+   In addition, if the recursive resolvers handling ENUM queries coming
+   from a softswitch were to be compromised by an attacker, that
+   attacker would be able to force calls to fail or cause delay to
+   calls.  Therefore, the DNS resolvers used should allow access from
+   the local network to which the softswitch is connected, whilst
+   restricting access from outside, using a proper access-list policy.
+
+8.  Acknowledgements
+
+   Thanks to Richard Shockey, Jason Livingood, Karsten Fleischhauer, Jim
+   Reid, and Otmar Lendl who helped guide the direction of this
+   document, and to Suresh Krishnan, whose GEN-ART review was very
+   helpful.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lim, et al.                  Informational                     [Page 10]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+9.  References
+
+9.1.  Normative References
+
+   [E164]        ITU-T, "The International Public Telecommunication
+                 Number Plan", Recommendation E.164, February 2005.
+
+   [RFC1034]     Mockapetris, P., "Domain names - concepts and
+                 facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]     Mockapetris, P., "Domain names - implementation and
+                 specification", STD 13, RFC 1035, November 1987.
+
+   [RFC3403]     Mealling, M., "Dynamic Delegation Discovery System
+                 (DDDS)  Part Three: The Domain Name System (DNS)
+                 Database", RFC 3403, October 2002.
+
+   [RFC3761]     Faltstrom, P. and M. Mealling, "The E.164 to Uniform
+                 Resource Identifiers (URI) Dynamic Delegation Discovery
+                 System (DDDS) Application (ENUM)", RFC 3761,
+                 April 2004.
+
+9.2.  Informative References
+
+   [ENUMSERVICE-GUIDE]
+                 Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
+                 Registration of Enumservices: Guide, Template, and IANA
+                 Considerations", Work in Progress, September 2008.
+
+   [H323]        ITU-T, "Packet-based multimedia communications
+                 systems", Recommendation H.323, 2003.
+
+   [RFC2136]     Vixie, P., Thomson, S., Rekhter, Y., and J.  Bound,
+                 "Dynamic Updates in the Domain Name System (DNS
+                 UPDATE)", RFC 2136, April 1997.
+
+   [RFC3261]     Rosenberg, J., Schulzrinne, H., Camarillo, G.,
+                 Johnston, A., Peterson, J., Sparks, R., Handley, M.,
+                 and E. Schooler, "SIP: Session Initiation Protocol",
+                 RFC 3261, June 2002.
+
+   [RFC3263]     Rosenberg, J., "Session Initiation Protocol (SIP):
+                 Locating SIP Servers", RFC 3263, June 2002.
+
+   [RFC3435]     Andreasen, F. and B. Foster, "Media Gateway Control
+                 Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
+
+
+
+
+
+Lim, et al.                  Informational                     [Page 11]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+   [RFC3761bis]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
+                 Uniform Resource Identifiers (URI) Dynamic Delegation
+                 Discovery System (DDDS) Application (ENUM)", Work
+                 in Progress, February 2008.
+
+   [RFC4114]     Hollenbeck, S., "E.164 Number Mapping for the
+                 Extensible Provisioning Protocol (EPP)", RFC 4114,
+                 June 2005.
+
+   [RFC5067]     Lind, S. and P. Pfautz, "Infrastructure ENUM
+                 Requirements", RFC 5067, November 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lim, et al.                  Informational                     [Page 12]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+Authors' Addresses
+
+   JoonHyung Lim
+   National Internet Development Agency of Korea(NIDA)
+   3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
+   Seoul
+   Korea
+
+   Phone: +82-2-2186-4548
+   EMail: jhlim@nida.or.kr
+   URI:   http://www.nida.or.kr
+
+
+   Weon Kim
+   National Internet Development Agency of Korea(NIDA)
+   3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
+   Seoul
+   Korea
+
+   Phone: +82-2-2186-4502
+   EMail: wkim@nida.or.kr
+   URI:   http://www.nida.or.kr
+
+
+   ChanKi Park
+   National Internet Development Agency of Korea(NIDA)
+   3F. KTF B/D 1321-11, Seocho-dong, Seocho-gu
+   Seoul
+   Korea
+
+   Phone: +82-2-2186-4504
+   EMail: ckp@nida.or.kr
+   URI:   http://www.nida.or.kr
+
+
+   Lawrence Conroy
+   Roke Manor Research
+   Roke Manor
+   Old Salisbury Lane
+   Romsey
+   United Kingdom
+
+   Phone: +44-1794-833666
+   EMail: lconroy@insensate.co.uk
+   URI:   http://www.sienum.co.uk
+
+
+
+
+
+
+Lim, et al.                  Informational                     [Page 13]
+
+RFC 5346               Enum-Based Softswitch Use            October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Lim, et al.                  Informational                     [Page 14]
+