1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5067.txt b/doc/rfc/rfc5067.txt
new file mode 100644
index 0000000..7d6a53b
--- /dev/null
+++ b/doc/rfc/rfc5067.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            S. Lind
+Request for Comments: 5067                                     AT&T Labs
+Category: Informational                                        P. Pfautz
+                                                                    AT&T
+                                                           November 2007
+
+
+                    Infrastructure ENUM Requirements
+
+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 provides requirements for "infrastructure" or "carrier"
+   ENUM (E.164 Number Mapping), defined as the use of RFC 3761
+   technology to facilitate interconnection of networks for E.164 number
+   addressed services, in particular but not restricted to VoIP (Voice
+   over IP.)
+
+Table of Contents
+
+   1.  Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
+     1.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . 1
+     1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  Requirements for Infrastructure ENUM  . . . . . . . . . . . . . 3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+
+1.  Infrastructure ENUM
+
+1.1.  Definition
+
+   Infrastructure ENUM is defined as the use of the technology in RFC
+   3761 [1] by the carrier-of-record (as defined below) for a specific
+   E.164 number [2] to publish the mapping of the E.164 number into a
+   URI [3] that identifies a specific point of interconnection to that
+   service provider's network.  It is separate from any URIs that the
+   end user, who registers their E.164 number, may wish to associate
+   with that E.164 number.
+
+
+
+
+
+
+Lind & Pfautz                Informational                      [Page 1]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+   "Infrastructure ENUM" is distinguished from "End User ENUM", defined
+   in RFC3761 [1], in which the entity or person having the right to use
+   a number has the sole discretion about the content of the associated
+   domain and thus the zone content.  From a domain registration
+   perspective, the end user number assignee is thus the registrant.
+   Within the infrastructure ENUM namespace, we use the term "carrier-
+   of-record" for the entity having discretion over the domain and zone
+   content and acting as the registrant.  The "carrier-of-record" is:
+
+   o The Service Provider to which the E.164 number was allocated for
+   end user assignment, whether by the National Regulatory Authority
+   (NRA) or the International Telecommunication Union (ITU), for
+   instance, a code under "International Networks" (+882) or "Universal
+   Personal Telecommunications (UPT)" (+878) or,
+
+   o if the number is ported, the service provider to which the number
+   was ported, or
+
+   o where numbers are assigned directly to end users, the service
+   provider that the end user number assignee has chosen to provide a
+   Public Switched Telephone Network/Public Land Mobile Network (PSTN/
+   PLMN) point-of-interconnect for the number.
+
+   It is understood that the definition of carrier-of-record within a
+   given jurisdiction is subject to modification by national
+   authorities.
+
+1.2.  Background
+
+   Voice service providers use E.164 numbers currently as their main
+   naming and routing vehicle.  Infrastructure ENUM in e164.arpa or
+   another publicly available tree allows service providers to link
+   Internet-based resources such as URIs to E.164 numbers.  This allows
+   service providers, in addition to interconnecting via the PSTN/PLMN
+   (or exclusively), to peer via IP-based protocols.  Service providers
+   may announce all E.164 numbers or number ranges they host, regardless
+   of whether the final end user device is on the Internet, on IP-based
+   open or closed Next Generation Networks (NGNs), or on the PSTN or
+   PLMN, provided that an access point of some type to the destination
+   service provider's network is available on the Internet.  There is
+   also no guarantee that the originating service provider querying
+   infrastructure ENUM is able to access the ingress network element of
+   the destination provider's network.  Additional peering and
+   accounting agreements requiring authentication may be necessary.  The
+   access provided may also be to a shared network of a group of
+   providers, resolving the final destination network within the shared
+   network.
+
+
+
+
+Lind & Pfautz                Informational                      [Page 2]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC2119 [4].
+
+3.  Requirements for Infrastructure ENUM
+
+   1.  Infrastructure ENUM SHALL provide a means for a provider to
+       populate DNS resource records (RRs) for the E.164 numbering
+       resources for which it is the carrier-of-record in a single
+       common publicly accessible namespace.  The single common
+       namespace ultimately designated may or may not be the same as
+       that designated for End User ENUM (e164.arpa.)  The Fully-
+       Qualified Domain Name (FQDN) in the resulting resource records
+       will not necessarily belong to or identify the carrier-of-record.
+
+   2.  Queries of infrastructure ENUM fully qualified domain names MUST
+       return a result, even if the result is Refused (RCODE = 5).
+       Queries must not be rejected without response, e.g., based on
+       access control lists.
+
+   3.  Infrastructure ENUM SHALL support RRs providing a URI that can
+       identify a point of interconnection for delivery to the carrier-
+       of-record of communications addressed to the E.164 number.
+
+   4.  Infrastructure ENUM SHOULD be able to support an Internet
+       Registry Information Service (IRIS) [5] capability that allows
+       qualified parties to obtain information regarding the E.164
+       numbering resources and the corresponding carrier-of-record.
+       Determination of what information, if any, shall be available
+       which parties for geographic numbers is a national matter.
+
+   5.  Implementation of infrastructure ENUM MUST NOT restrict the
+       ability of an end user, in a competitive environment, to choose a
+       Registrar and/or name server provider for End User ENUM
+       registrations.
+
+   6.  The domain name chosen for infrastructure ENUM and any parent
+       domains MUST be hosted on name servers that have performance
+       characteristics and supporting infrastructure that is comparable
+       to those deployed for the Internet root name servers.  Those name
+       servers for infrastructure ENUM should be configured and operated
+       according to the guidelines described in [6].
+
+   7.  Infrastructure ENUM MUST meet all reasonable privacy concerns
+       about visibility of information over which an end user has no
+       control.  It should, for example, support mechanisms to prevent
+
+
+
+Lind & Pfautz                Informational                      [Page 3]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+       discovery of unlisted numbers by comparison of ENUM registrations
+       against directory listings, or inadvertent disclosure of user
+       identity.
+
+   8.  Proposed implementations of infrastructure ENUM SHOULD:
+
+       A.  Minimize changes required to existing requirements that are
+           part of RFC 3761.
+
+       B.  Work with open as well as closed numbering plans.
+
+       C.  Not require additional functionality of resolvers at large
+           though they may require additional functionality in service
+           provider resolvers that would make use of infrastructure
+           ENUM.
+
+       D.  Minimize the number of lookups required to obtain as many
+           NAPTR (Naming Authority Pointer) records (end user and
+           infrastructure) as possible.
+
+       E.  Minimize knowledge of the numbering plan required of
+           resolvers making use of Infrastructure ENUM.
+
+       F.  Maximize synergies with End User ENUM.
+
+       G.  Support interworking with private ENUM trees.  (In this
+           context, a private ENUM tree is one that is not under
+           e164.arpa or whatever namespace is chosen for infrastructure
+           ENUM but uses instead a privately held domain.)
+
+4.  Security Considerations
+
+   Existing security considerations for ENUM (detailed in [1]) still
+   apply.  Since infrastructure ENUM involves carriers where RFC 3761
+   mainly considered indviduals, implementations meeting these
+   requirements SHOULD reconsider the RFC 3761 security model given this
+   difference in actors concerned.  Note that some registration
+   validation issues concerning End User ENUM may not apply to
+   infrastructure ENUM.  Where the Tier 1 registry is able to identify
+   the provider serving a number, e.g., based on industry data for
+   number block assignments and number portability, registration might
+   be more easily automated and a separate registrar not required.
+
+   Some parties have expressed concern that an infrastructure ENUM could
+   compromise end user privacy by making it possible for others to
+   identify unlisted or unpublished numbers based on their registration
+   in ENUM.  This can be avoided if providers register all of the their
+   allocated (as opposed to assigned) numbers.  Unassigned numbers
+
+
+
+Lind & Pfautz                Informational                      [Page 4]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+   should be provisioned to route to the provider's network in the same
+   fashion as assigned numbers and only then provide an indication that
+   they are unassigned.  In that way, provider registration of a number
+   in ENUM provides no more information about the status of a number
+   than could be obtained by dialing it.
+
+   Implementers should take care to avoid inadvertent disclosure of user
+   identities, for example, in the URIs returned in response to
+   infrastructure ENUM queries.
+
+5.  IANA Considerations
+
+   This document includes no actions to be taken by IANA.  The
+   architecture ultimately chosen to meet the requirements may require
+   IANA actions.
+
+6.  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]  International Telecommunication Union-Telecommunication
+        Standardization Sector, "The International Public
+        Telecommunication Numbering Plan", Recommendation E.164",
+        February 2005.
+
+   [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+        January 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [5]  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
+        Service (IRIS) Core Protocol", RFC 3981, January 2005.
+
+   [6]  Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name
+        Server Operational Requirements", BCP 40, RFC 2870, June 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Lind & Pfautz                Informational                      [Page 5]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+Authors' Addresses
+
+   Steven Lind
+   AT&T Labs
+   180 Park Ave
+   Florham Park, NJ  07932-0971
+   USA
+
+   EMail: sdlind@att.com
+
+
+   Penn Pfautz
+   AT&T
+   200 S. Laurel Ave
+   Middletown, NJ  07748
+   USA
+
+   EMail: ppfautz@att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lind & Pfautz                Informational                      [Page 6]
+
+RFC 5067            Infrastructure ENUM Requirements       November 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Lind & Pfautz                Informational                      [Page 7]
+