One document matched: draft-ietf-enum-infrastructure-enum-reqs-02.txt

Differences from draft-ietf-enum-infrastructure-enum-reqs-01.txt

ENUM                                                             S. Lind
Internet-Draft                                                 AT&T Labs
Expires: October 26, 2006                                      P. Pfautz
                                                                    AT&T
                                                          April 24, 2006


                    Infrastrucure ENUM Requirements
              draft-ietf-enum-infrastructure-enum-reqs-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.)

Conventions used in this document



Lind & Pfautz           Expires October 26, 2006                [Page 1]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


   RFC2119 [1] provides the interpretations for the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" found in this document.


Table of Contents

   1.  Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements for Infrastructure ENUM  . . . . . . . . . . . . . 4
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8



































Lind & Pfautz           Expires October 26, 2006                [Page 2]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


1.  Infrastructure ENUM

1.1.  Definition

   Infrastructure ENUM is defined as the use of the technology in
   RFC3761 [2] by the carrier-of-record for a specific E.164 number [3]
   to map a telephone number into a URI [4] that identifies a specific
   point of interconnection to that service provider's network that
   could enable the originating party to establish communication with
   the associated terminating party.  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.

   Infrastructure ENUM is distinguished from user ENUM, defined in
   RFC3761 [2], 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



Lind & Pfautz           Expires October 26, 2006                [Page 3]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


   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 an access (e.g., Session Border Controller (SBC) or
   gateway) 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.


2.  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 ulimtately designated may or may not be the same as
       that designated for user ENUM (e164.arpa.)
   2.  Queries of infrastructure ENUM fully qualified domain names MUST
       return a result, even if the result is NXDOMAIN.  Queries must
       not be rejected, 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 SHALL support an 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 to which parties 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 Tier 2 name server provider for end-user ENUM
       registrations.
   6.  Infrastructure ENUM SHALL be implemented under a top level domain
       that can support reliability and performance suitable for PSTN/
       PLMN applications.
   7.  Infrastructure ENUM MUST meet all reasonable privacy concerns
       about visibility of information an end user has no control over.
       It should, for example, support mechanisms to prevent discovery
       of unlisted numbers by comparision of ENUM registrations against
       directory listings, or inadvertent disclosure of user identity.
   8.  Proposed implementations of Infrastructure ENUM SHOULD:





Lind & Pfautz           Expires October 26, 2006                [Page 4]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


       A.  Minimize changes required to existing requirements that are
           part of RFC 3761
       B.  Work with open as well as closed numbering plans
       C.  Restrict the need for any additional resolver functionality
           to service provider resolvers.
       D.  Minimize the number of lookups required to obtain as many
           NAPTR (Naming Authority Pointer) records (end-user and
           infrastructure) as possible.
       E.  Minimize the client knowledge of the numbering plan required.
       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.)


3.  Security Considerations

   Existing security considerations for ENUM detailed in [2] still
   apply.  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
   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 status of a number than
   could be obtained by dialing it.


4.  IANA Considerations

   IANA considerations will depend on the architecture ultimately chosen
   to meet the requirements.

5.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.




Lind & Pfautz           Expires October 26, 2006                [Page 5]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


   [2]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
        Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
        Application (ENUM)", RFC 3761, April 2004.

   [3]  International Telecommunication Union-Telecommunication
        Standardization Sector, "The International Public
        Telecommunication Numbering Plan", Recommendation E.164",
        February 2005.

   [4]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

   [5]  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
        Service (IRIS) Core Protocol", RFC 3981, January 2005.




































Lind & Pfautz           Expires October 26, 2006                [Page 6]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


Authors' Addresses

   Steven Lind
   AT&T Labs
   180 Park Ave
   Florham Park, NJ  07932-0971
   USA

   Email: slind@att.com


   Penn Pfautz
   AT&T
   200 S. Laurel Ave
   Middletown, NJ  07748
   USA

   Email: ppfautz@att.com

































Lind & Pfautz           Expires October 26, 2006                [Page 7]

Internet-Draft      Infrastructure ENUM Requirements          April 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Lind & Pfautz           Expires October 26, 2006                [Page 8]