doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4725.txt b/doc/rfc/rfc4725.txt
new file mode 100644
index 0000000..259aaa4
--- /dev/null
+++ b/doc/rfc/rfc4725.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       A. Mayrhofer
+Request for Comments: 4725                                       enum.at
+Category: Informational                                     B. Hoeneisen
+                                                                  Switch
+                                                           November 2006
+
+
+                      ENUM Validation Architecture
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2006).
+
+Abstract
+
+   An ENUM domain name is tightly coupled with the underlying E.164
+   number.  The process of verifying whether or not the Registrant of an
+   ENUM domain name is identical to the Assignee of the corresponding
+   E.164 number is commonly called "validation".  This document
+   describes validation requirements and a high-level architecture for
+   an ENUM validation infrastructure.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 1]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements ....................................................3
+   3. ENUM Provisioning Model and Roles ...............................4
+      3.1. Number Assignment Entity (NAE) .............................5
+      3.2. Assignee ...................................................7
+      3.3. Registrant .................................................7
+      3.4. Validation Entity (VE) .....................................7
+      3.5. Registry ...................................................8
+      3.6. Registrar ..................................................8
+      3.7. Domain Name System Service Provider (DNS-SP) ...............8
+      3.8. Application Service Provider (ASP) .........................8
+   4. Validation Process Assumptions ..................................9
+      4.1. Workflow ...................................................9
+      4.2. Trust Relations ...........................................10
+      4.3. Data Flow and Format ......................................11
+   5. Example Scenarios ..............................................11
+      5.1. E.164 Number Assignment along with ENUM Registration ......11
+      5.2. Fully Disjoint Roles ......................................13
+   6. Security Considerations ........................................14
+      6.1. Fraud Prevention ..........................................14
+      6.2. Assignee Data .............................................14
+   7. Acknowledgements ...............................................15
+   8. References .....................................................15
+      8.1. Normative References ......................................15
+      8.2. Informative References ....................................15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 2]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+1.  Introduction
+
+   E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [4]
+   to refer from E.164 numbers [2] to Uniform Resource Identifiers
+   (URIs) [3].  E.164 numbers are mapped to domain names through means
+   described further in RFC 3761 [1].
+
+   "Ordinary" domain names are usually allocated on a first-come-first-
+   served basis, where the associated registration data is the complete
+   source of ownership.  However, ENUM domain names are linked to E.164
+   numbers, and thus intrinsically tied to the status and the "Assignee"
+   (defined in Section 3.2) of the corresponding E.164 number.
+
+2.  Requirements
+
+   Preserving integrity between ENUM and E.164 is one of the main
+   concerns in ENUM implementations, and often one of the reasons why
+   "trials" precede commercial implementations.
+
+   To maintain this relationship between E.164 numbers and ENUM domain
+   names, registration processes must ensure that the following
+   requirements are fulfilled during the entire lifetime of an ENUM
+   delegation:
+
+   o  The ENUM domain name corresponds either to an assigned E.164
+      number or to a respective E.164 number that is assigned during the
+      registration process itself.
+
+   o  The corresponding E.164 number is within a number range approved
+      to be used with ENUM.
+
+   o  The registration of the ENUM domain name is authorized by the
+      Assignee of the corresponding E.164 number; i.e., the entity
+      requesting the registration of an ENUM domain name is either the
+      Assignee of the corresponding E.164 number itself or an entity
+      authorized to request registration on behalf of said Assignee.
+
+   o  The "Registrant" (see Section 3.3) of the ENUM domain is identical
+      to the Assignee of the corresponding E.164 number.
+
+   The process of verifying the above requirements during registration
+   is commonly called "initial validation".  In addition to this one-
+   time validation process, provisions must be made that ENUM domain
+   name delegations are revoked when the above requirements are no
+   longer met.  In other words, it must be ensured that the state of the
+   ENUM domain name tracks any change in state and ownership of the
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 3]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   corresponding E.164 number.  The regular process of checking that the
+   above requirements are still satisfied is commonly called "recurring
+   validation" or "revalidation".
+
+   The above requirements are usually part of the local registration
+   policy issued by the authorities in charge of ENUM administration.
+
+3.  ENUM Provisioning Model and Roles
+
+   The above requirements lead to the introduction of a new role in the
+   provisioning model, an entity performing validation related tasks:
+   The Validation Entity (VE).  A typical ENUM provisioning model, on
+   which this document is based, is depicted in Figure 1:
+
+                           +----------+
+                          .| Registry |- -- -- -- -- -- --
+                        .  +----------+                   |
+                      .          |
+                    .            |                        | Trust
+            DNS Delegation       |                          Relation
+                .                | Registration           |
+              .                  |
+            .                    |                        |
+   +--------+              +-----------+                +----+
+   | DNS-SP |-- -- -- -- --| Registrar |----------------| VE |
+   +--------+ Nameservers  +-----------+   Validation   +----+
+       :                         |                     /  |
+       :                         |                  E.164 Number
+       :                         | ENUM             Assignment
+       : NAPTR                   | Management     _ Verification
+       :                         |             /          |
+       :                         |          _
+       :                         |      /                 |
+    +-----+  ENUM enabled  +------------+ E.164 Number +-----+
+    | ASP |- -- -- -- -- --| Assignee = |-- -- -- -- --| NAE |
+    +-----+    Service     | Registrant |  Assignment  +-----+
+                           +------------+
+
+         Legend:
+
+         ASP:    Application Service Provider
+         DNS-SP: Domain Name System Service Provider
+         NAE:    Number Assignment Entity
+         VE:     Validation Entity
+
+                           Figure 1: ENUM Model
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 4]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   These different roles are described further below.  Note that an
+   entity can act in more than one of these roles simultaneously; for
+   example, the Registrar, the DNS-SP, and the ASP roles could be
+   performed by a single company.
+
+3.1.  Number Assignment Entity (NAE)
+
+   A Number Assignment Entity (NAE) assigns E.164 numbers to end-users.
+   Often, but not always, the Communication Service Provider (CSP) of
+   the end-user (Assignee) acts as NAE.  There are two main variants for
+   E.164 number assignments:
+
+   1.  Indirect assignment:
+
+       The National Number Plan Administrator (NNPA) assigns ranges of
+       E.164 numbers to CSPs.  Out of these ranges, the CSPs assign
+       numbers (or number blocks) to their customers (end-users,
+       Assignees).  In this variant, the CSPs perform the role of the
+       NAE.
+
+   2.  Direct assignment:
+
+       In certain cases, an NNPA assigns E.164 numbers directly to
+       Assignees (end-users), and therefore the NNPA acts as NAE in this
+       variant.  Typically, this concerns the assignment of special
+       purpose numbers (e.g., premium rate).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 5]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   These two variants of E.164 number assignment are depicted in
+   Figure 2:
+
+   +--------------------------------------------+
+   | International Telecommunication Union (ITU)|
+   +--------------------------------------------+
+                        |
+              Country codes (e.g., +44)
+                        |
+                        v
+    +-------------------------------------------+
+    | National Number Plan Administrator (NNPA) |------------+
+    +-------------------------------------------+            |
+                        |                                    |
+                  Number Ranges                              |
+            (e.g., +44 20 7946 xxxx)                         |
+                        |                                    |
+                        v                                    |
+      +--------------------------------------+               |
+      | Communication Service Provider (CSP) |               |
+      +--------------------------------------+               |
+                        |                                    |
+                        |                              Single Numbers
+              Either Single Numbers              (e.g., +44 909 8790879)
+                 or Number Blocks                       (Variant 2)
+     (e.g., +44 20 7946 0999, +44 20 7946 07xx)              |
+                   (Variant 1)                               |
+                        |                                    |
+                        v                                    |
+                  +----------+                               |
+                  | Assignee |<------------------------------+
+                  +----------+
+
+                     Figure 2: E.164 Number Assignment
+
+   (Note: Numbers above are "drama" numbers and are shown for
+   illustrative purpose only.  Assignment polices for similar "real"
+   numbers in country code +44 may differ.)
+
+   As the Assignee (subscriber) data associated with an E.164 number is
+   the primary source of number assignment information, the NAE usually
+   holds the authoritative information required to confirm the
+   assignment.
+
+   A CSP that acts as NAE (indirect assignment) may therefore easily
+   assert the E.164 number assignment for its subscribers.  In some
+   cases, such CSPs operate database(s) containing service information
+   on their subscribers' numbers.  Typically, authorized entities such
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 6]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   as other CSPs are allowed to access these databases, in real-time,
+   under contract for the limited purposes of billing and validation (no
+   marketing, data mining, or otherwise).  These databases could be re-
+   used for ENUM validation purposes.
+
+   Number portability transactions may lead to situations where the CSP
+   that originally acted as NAE no longer has authoritative assignment
+   information about ported numbers.  Whether the old and/or the new CSP
+   act(s) as NAE for ported numbers depends on local policy.
+
+   However, it is unlikely that all CSPs acting as NAEs will participate
+   in ENUM validation.
+
+3.2.  Assignee
+
+   The person or organization to whom a NAE assigns an E.164 number is
+   called Assignee of this number.  For the scope of this document, the
+   terms Assignee, subscriber, and number-holder are used equivalently.
+
+   The Assignee has the "right to use" on the assigned E.164 number.
+
+3.3.  Registrant
+
+   The ENUM Registrant is the end-user, the person or organization who
+   is the "holder" of the ENUM domain name.
+
+   The Registrant usually has control over his ENUM domain name(s) and
+   its DNS zone content.
+
+3.4.  Validation Entity (VE)
+
+   The Validation Entity (VE) verifies whether or not the Registrant of
+   an ENUM domain name is identical to the Assignee of the corresponding
+   E.164 number.
+
+   Often it also verifies that the entity requesting the registration of
+   an ENUM domain name is either the Assignee of the corresponding E.164
+   number itself or an entity authorized to request registration on
+   behalf of said Assignee.
+
+   This role may be performed by several parties and is not necessarily
+   limited to a single entity.
+
+   The actual validation methods applied may vary depending on, e.g.,
+   the particular party, available data sources, Assignee's choice, and
+   regulatory requirements.  Validation methods are out of scope of this
+   document.
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 7]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+3.5.  Registry
+
+   The ENUM Registry operates the master database of ENUM domain
+   delegations and runs the authoritative nameservers for the relevant
+   zone under e164.arpa.  There must always be a single authoritative
+   ENUM Registry for a specific zone.
+
+3.6.  Registrar
+
+   An ENUM Registrar performs ENUM domain delegations on behalf of a
+   Registrant by interacting with the Registry, typically through a
+   protocol like Extensible Provisioning Protocol (EPP) [5].  This role
+   is similar to the one that Registrars fulfill in the "ordinary"
+   domain name registration world.
+
+   The Registrar may well not be the same entity as the CSP of the
+   Registrant.  Therefore, a Registrar may lack authoritative number-
+   assignment information.  If the Registrar and the CSP are the same
+   entity (or has a source of authoritative data), the Registrar could
+   perform the role of the VE itself.
+
+   In any case, a Registrar has to ensure a proper validation through a
+   VE prior to the registration of an ENUM domain name.
+
+3.7.  Domain Name System Service Provider (DNS-SP)
+
+   The Domain Name System Service Provider (DNS-SP) operates the
+   nameservers for the ENUM DNS zones, which contain the ENUM Naming
+   Authority Pointer (NAPTR) Resource Record (RR) entries [1].
+
+   In most cases, the Registry delegates the ENUM DNS zones to the
+   nameservers at the DNS-SP.
+
+   The DNS-SP is usually not involved in the validation process.
+
+3.8.  Application Service Provider (ASP)
+
+   The Application Service Provider (ASP) operates a service for the
+   Registrant.  This service could be an IP telephony service, whereby
+   the service provider populates the ENUM zone for its customers so
+   that others can discover that customer's URI.
+
+   Usually, the ASP is not involved in the validation process.
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 8]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+4.  Validation Process Assumptions
+
+4.1.  Workflow
+
+   The prototypical initial validation workflow using the above roles
+   and definitions consists of the following steps:
+
+   1.  A potential Registrant approaches a Registrar, and orders an ENUM
+       domain name.
+
+   2.  The Registrar chooses a cooperating Validation Entity, and
+       requests an initial validation for the ENUM domain name ordered.
+
+   3.  The Validation Entity performs the actual validation, which could
+       require interaction with the Assignee/Registrant.
+
+   4.  The Validation Entity indicates the result of the initial
+       validation to the Registrar.
+
+   5.  If the validation process was successful, the Registrar
+       provisions the ENUM domain name with the Registry.  Depending on
+       the local Registry policy, validation-related information may be
+       provided to the Registry along with this registration.
+
+   In most cases, local policy mandates expiration dates to be imposed
+   on successful validations.  If the ENUM delegation is to be kept
+   beyond this expiration date, recurring validation has to be
+   performed.  A typical revalidation workflow involves the following
+   steps:
+
+   1.  In good time before the current validation expires, the Registrar
+       requests the Validation Entity to revalidate the domain name in
+       question.
+
+   2.  The Validation Entity verifies if the delegation requirements are
+       still met.  It may use information acquired during the initial
+       validation or associated to the registration data.
+
+   3.  The Validation Entity indicates the result of the recurring
+       validation to the Registrar.
+
+   4.  In case the revalidation has been successful, the domain
+       delegation may persist.  Local Registry policy may require
+       updating domain name registration data, especially in case the
+       Registry keeps validation-related expiry information.
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                      [Page 9]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   5.  In case the revalidation has failed, the ENUM domain delegation
+       must be suspended, either by explicit interaction with the
+       Registry or -- if the Registry keeps validation-related
+       information -- automatically when the current validation expires.
+       Local policy may grant a grace period on the expiration date.
+
+   This workflow ensures the integrity between the E.164 and ENUM
+   namespaces.  ENUM domain delegations that fail to meet the validation
+   requirements are suspended from the DNS.
+
+4.2.  Trust Relations
+
+   The above validation workflow implies the following trust relations:
+
+   o  The Registry trusts the Validation Entities to enforce the local
+      validation policy.
+
+   o  The Registrars trust the Validation Entities to properly perform
+      validation based on the Registrar's request.
+
+   o  Depending on the amount of validation data provided to the
+      Registry additional trust relations may be necessary.  Three cases
+      can be differentiated:
+
+      *  The Registry receives no validation-related data: The Registry
+         needs to trust the Registrar that validation has been
+         performed, and the result was positive.  In addition, the
+         Registry needs to trust the Registrar that it will properly
+         remove delegations for which revalidation fails.
+
+      *  The Registry receives validation-related data including expiry
+         date, but there are no means of checking its authenticity: The
+         Registry needs to trust the Registrar that the validation data
+         provided is authentic.
+
+      *  The Registry receives validation-related data including expiry
+         date and means to verify its authenticity (e.g., a
+         cryptographic signature issued by the VE): No additional trust
+         relations are necessary.
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 10]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+4.3.  Data Flow and Format
+
+   The validation process requires the following regular data flows
+   (Note: data flows not directly related to validation are out of scope
+   of this document):
+
+   o  Registrars communicate with Validation Entities to initiate,
+      modify, or cancel validation requests.  Validation Entities act
+      upon validation requests and provide validation results to
+      Registrars.  Since Registrars could potentially communicate with
+      several Validation Entities, and Validation Entities could provide
+      services to several Registrars (worst case: full mesh), a
+      standardized protocol and data format should be used in this data
+      flow.
+
+   o  If the local Registry policy mandates that validation-related
+      information is to be stored along with delegation records, a
+      validation-related data flow between Registry and Registrar is
+      required.  Since the registration itself already requires
+      communication between those entities, validation-related
+      information in a standardized data format should be embedded into
+      the existing Registry-Registrar protocol data flow.
+
+   o  Validation Entities may need to communicate with Assignees to
+      perform validation.  A Validation Entity may choose to perform all
+      communication with the Assignee via the requesting Registrar
+      rather than contacting the Assignee by itself.  Since the actual
+      communication form and process are expected to greatly vary, it
+      does not make sense to specify any data formats or processes for
+      this purpose.
+
+5.  Example Scenarios
+
+5.1.  E.164 Number Assignment along with ENUM Registration
+
+   In this simple scenario, we assume that the roles of the Registrar,
+   the VE, and the NAE are performed by the same entity, e.g., an
+   Internet Telephony Service Provider (ITSP).  This ITSP is a CSP that
+   was assigned number ranges by the NNPA.  Out of these ranges he
+   assigns numbers to his customers (Assignees) to provide those with
+   communication services.  The ITSP chooses to assign an E.164 number
+   together with the corresponding ENUM domain name.  Therefore, it can
+   perform the validation simply by reference to its subscriber
+   database.
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 11]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   Figure 3 shows the external interactions needed for the ENUM domain
+   name provisioning process:
+
+                   +----------+
+                   | Registry |
+                   +----------+
+                        ^
+                        |
+                        |(3)
+                        |
+                +--------------------------------------+
+                |                                      |
+                |                    ITSP              |
+                |  +-----------+              +----+   |
+                |  | Registrar |              | VE |   |
+                |  +-----------+      (2)     +----+   |
+                |                                      |
+                +--------------------------+           |
+                        ^                  |           |
+                        |                  |           |
+                        |(1)               |           |
+                        |                  |           |
+                        |                  |           |
+                  +------------+   (4)     |  +-----+  |
+                  | Assignee = |<----------|  | NAE |  |
+                  | Registrant |           |  +-----+  |
+                  -------------            |           |
+                                           +-----------+
+
+                     Legend:
+
+                     ITSP: Internet Telephony Service Provider
+                     NAE:  Number Assignment Entity
+                     VE:   Validation Entity
+
+      Figure 3: E.164 Number Assignment along with ENUM Registration
+
+   (1)  The ITSP receives an order for ENUM services.
+   (2)  The ITSP assigns a free E.164 number and performs the validation
+        at the same time.
+   (3)  The ITSP sends an ENUM registration request to the Registry,
+        which might contain additional information about the validation
+        applied.
+   (4)  The ITSP sends a confirmation about the E.164 number assignment
+        and the ENUM registration to its customer, who is now Assignee
+        and Registrant.
+
+   This scenario is quite close to "ordinary" domain name registrations.
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 12]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+5.2.  Fully Disjoint Roles
+
+   In this more complex scenario, we assume that all roles of the ENUM
+   provisioning model are performed by different entities.  In contrast
+   with the previous example (in Section 5.1), we assume that the ENUM
+   domain name to be registered is based on an already assigned E.164
+   number and the NAE in question provides the VE with access to the
+   subscriber database.  We further assume that there is a requirement
+   for the VE to verify the intention of the Assignee.  The validation
+   process therefore involves also contacting the Assignee.
+
+   Figure 4 shows the interactions needed for the ENUM domain name
+   provisioning process:
+
+                    +----------+
+                    | Registry |
+                    +----------+
+                         ^
+                         |
+                         |(9)
+                         |
+                         |
+                         |             (3)
+                    +-----------+ ---------->+----+
+                    | Registrar |<---------- | VE |
+                    +-----------+   (8)    > +----+
+                         ^                / /  ^  |
+                         |               / /   |  |
+                         |           (7)/ /    |  |
+                         |(2)          / /     |  |
+                         |            / /   (5)|  |
+                         |           / /       |  |
+                         |          / /        |  |
+                         |         / /(6)      |  |
+                         |        / /          |  |(4)
+                         |       / /           |  |
+                         |      / /            |  |
+                   +------------+<             |  v
+                   | Assignee = |            +-----+
+                   | Registrant |<---------- | NAE |
+                   +------------+    (1)     +-----+
+
+                     Legend:
+
+                     NAE:  Number Assignment Entity
+                     VE:   Validation Entity
+
+                      Figure 4: Fully Disjoint Roles
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 13]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+   (1)  The NAE assigns an E.164 number.  This assignment could have
+        been done long before the ENUM domain name registration, e.g.,
+        at the time when the Assignee subscribed to a common telephony
+        service.
+   (2)  The Assignee orders the corresponding ENUM domain name at a
+        Registrar of his choice.
+   (3)  The Registrar requests validation at an independent VE.
+   (4)  The VE contacts the subscriber database of the NAE, to verify
+        that the Assignee of the E.164 number corresponds to the
+        Registrant of the ENUM domain name.
+   (5)  The result of the NAE subscriber database is positive.
+   (6)  The VE performs a call-back to the E.164 number to be registered
+        as ENUM domain name, makes provisions for authentication, and
+        asks the Assignee to confirm his intention.
+   (7)  The Assignee confirms and the VE documents this confirmation.
+   (8)  The VE returns a positive answer to the Registrar.  The answer
+        might contain some additional information about the validation
+        process, such as expiration date, validation method applied, and
+        so on.
+   (9)  Finally, the Registrar sends an ENUM registration request to the
+        Registry.  Additional information about the validation process
+        might be sent along with the registration request.
+
+6.  Security Considerations
+
+6.1.  Fraud Prevention
+
+   Situations where an entity has control over the ENUM domain of a
+   third party's E.164 number impose high fraud potential.  Unauthorized
+   control over an ENUM domain of a bank could, for example, be used for
+   "man in the middle" attacks on telephone banking applications.  Cases
+   of such attacks could discredit ENUM as a whole.
+
+   Implementing high-quality validation processes is therefore crucial
+   to any ENUM deployment and should receive high attention.
+
+6.2.  Assignee Data
+
+   When handling Assignee data, privacy and discretion issues must be
+   considered.  Implementations transporting assignee data over the
+   Internet must use authenticated and encrypted transport protocols.
+   Local registration/validation policy and agreements should clearly
+   limit usage of Assignee data.
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 14]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+7.  Acknowledgements
+
+   The authors would like to thank the following persons for their
+   valuable suggestions and contributions: Lawrence Conroy, Michael
+   Haberler, Ted Hardie, Otmar Lendl, Hala Mowafy, Marcel Parodi, Jon
+   Peterson, Penn Pfautz, Patrik Schaefer, and Richard Stastny.
+
+8.  References
+
+8.1.  Normative References
+
+   [1]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
+        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
+        Application (ENUM)", RFC 3761, April 2004.
+
+   [2]  ITU-T, "The international public telecommunication numbering
+        plan", Recommendation E.164 (02/05), Feb 2005.
+
+8.2.  Informative References
+
+   [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+        January 2005.
+
+   [4]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [5]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
+        RFC 3730, March 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 15]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+Authors' Addresses
+
+   Alexander Mayrhofer
+   enum.at GmbH
+   Karlsplatz 1/9
+   Wien  A-1010
+   Austria
+
+   Phone: +43 1 5056416 34
+   EMail: alexander.mayrhofer@enum.at
+   URI:   http://www.enum.at/
+
+
+   Bernie Hoeneisen
+   Switch
+   Neumuehlequai 6
+   CH-8001 Zuerich
+   Switzerland
+
+   Phone: +41 44 268 1515
+   EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
+   URI:   http://www.switch.ch/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 16]
+
+RFC 4725              ENUM Validation Architecture         November 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2006).
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+Mayrhofer & Hoeneisen        Informational                     [Page 17]
+