The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM
RFC 5526
|
Document |
Type |
|
RFC - Informational
(April 2009; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 5526 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
(None)
|
Network Working Group J. Livingood
Request for Comments: 5526 Comcast Cable Communications
Category: Informational P. Pfautz
AT&T
R. Stastny
Unaffiliated
April 2009
The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application
for Infrastructure ENUM
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) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Livingood, et al. Informational [Page 1]
RFC 5526 Infrastructure ENUM April 2009
Abstract
This document defines the use case for Infrastructure ENUM and
proposes its implementation as a parallel namespace to "e164.arpa",
as defined in RFC 3761, as the long-term solution to the problem of
allowing carriers to provision DNS records for telephone numbers
independently of those provisioned by end users (number assignees).
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Zone Apex for Infrastructure ENUM ...............................3
4. IANA Considerations .............................................3
5. Security and Privacy Considerations .............................4
6. Acknowledgements ................................................4
7. Normative References ............................................4
1. Introduction
ENUM (E.164 Number Mapping [1]) is a system that transforms E.164
numbers [2] into domain names and then uses the DNS (Domain Name
Service) [3] to discover NAPTR records that specify what services are
available for a specific domain name.
ENUM as originally defined was based on the end-user opt-in
principle. While this has great potential to foster new services and
end-user choices in the long term, the current requirements for
IP-based interconnection of Voice over IP (VoIP) domains require the
provisioning of large numbers of allocated or served (hosted) numbers
of a participating service provider, without the need for individual
users to opt-in. This way, service providers can provision their own
ENUM information that is separate, distinct, and likely to be
different from what an end-user may provision. This is particularly
important if Infrastructure ENUM is used for number-portability
applications, for example, which an end-user would be unlikely
interested in provisioning but which a service provider would likely
find essential.
In addition, while it is possible that service providers could
mandate that their users opt-into e164.arpa through end-user contract
terms and conditions, there are substantial downsides to such an
approach. Thus, for all these reasons and many others, ENUM for
end-user provisioning is ill-suited for use by service providers for
the interconnection of VoIP domains.
Livingood, et al. Informational [Page 2]
RFC 5526 Infrastructure ENUM April 2009
As VoIP evolves and becomes pervasive, E.164-addressed telephone
calls need not necessarily traverse the Public Switched Telephone
Network (PSTN). Therefore, VoIP service providers have an interest
in using ENUM on a so-called "Infrastructure" basis in order to keep
Show full document text