ENUM S. Lind
Internet-Draft AT&T Labs
Expires: September 23, 2006 P. Pfautz
AT&T
March 22, 2006
Infrastrucure ENUM Requirements
draft-ietf-enum-infrastructure-enum-reqs-01
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 September 23, 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 September 23, 2006 [Page 1]
Internet-Draft Infrastructure ENUM Requirements March 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 September 23, 2006 [Page 2]
Internet-Draft Infrastructure ENUM Requirements March 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.
In User ENUM, the entity or person having the right-to-use in 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" will
typically be a service provider authorized to issue E.164 numbers for
the provisioning of Public Switched Telephone Network (PSTN) service
under the authority of a National Regulatory Authority (NRA), but
generally exhibits one or more of the following properties:
o it has been assigned one or more national number ranges by an NRA.
o it has been assigned a number range directly by the International
Telecommunications Union (ITU), for instance a code under
"International Networks" (+882) or "Universal Personal
Telecommunications (UPT)" (+878).
o it can be the recipient of a number porting operation.
o it provides a PSTN point-of-interconnect for the number.
It is understood that definition of carrier or record is ultimately a
matter for national authorities to determine.
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 (Note: this is
the other way round then User ENUM). This allows service providers
in addition to interconnecting via the PSTN (or exclusively) to peer
via IP-based protocols. Service providers may announce all E.164
Lind & Pfautz Expires September 23, 2006 [Page 3]
Internet-Draft Infrastructure ENUM Requirements March 2006
numbers or number ranges they host, regardless of whether the final
end-user device is on the Internet, on IP-based closed Next
Generation Networks (NGNs) or on the PSTN, 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) in a common publicly
accessible namespace for the E.164 numbering resources for which
it is the carrier-of-record.
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 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
applications.
7. Infrastructure ENUM MUST meet all reasonable privacy concerns
about visibility of information an end user has no control over,
for example discovery of unlisted numbers, 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 numbering plans
Lind & Pfautz Expires September 23, 2006 [Page 4]
Internet-Draft Infrastructure ENUM Requirements March 2006
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.
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.
[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 Telecommunications Union-T, "The International
Public Telecommunication Number Plan", Recommendation E.164",
Lind & Pfautz Expires September 23, 2006 [Page 5]
Internet-Draft Infrastructure ENUM Requirements March 2006
May 1997.
[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 September 23, 2006 [Page 6]
Internet-Draft Infrastructure ENUM Requirements March 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 September 23, 2006 [Page 7]
Internet-Draft Infrastructure ENUM Requirements March 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 September 23, 2006 [Page 8]
