[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
INTERNET-DRAFT                                                Edward Lewis
January 23, 2007                                              NeuStar, Inc.

                    ENUM Registry Interface Requirements

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

The list of Internet-Draft Shadow Directories can be accessed at

Discussion of this document should include the following list address:
      Provisioning Extensions in Peering Registries for Multimedia
      INTerconnection <peppermint@ietf.org>


An ENUM registry interacts with various elements to maintain what is
essentially a telephone number to uniform (or a more modern version)
resource identifier.  The interfaces needed are identified in this
requirements document, as well as the requirements for the more generic

1 Introduction

An ENUM registry supporting the DDDS [RFC3761] requires two specific
interfaces and a third class of other interfaces.  One specific interface
is shared with a legacy telephone Operating Support System (OSS), through
which telephone number (account) activity is reported.  The other
specific interface is to the resolution system, for the most part a DNS
constellation.  The third class of interfaces are those needed to obtain
information about telephone number from other regulatory sources, such
as a national telephone number plan administrator.  Interfaces of this
latter sort will vary according to the environment, the structure of
those interfaces will be determined by the appropriate regulatory

The first of the specific interfaces is named the ENUM Provisioning
interface.  The kind of activity that is reported over this interface
are telephone number activations and deactivations, service additions
and deletions from telephone numbers and other activity usually driven
by customer account activity.  Ancillary traffic on this interface
will exist for the purpose of setting up short cuts, or profiles, to
be automatically applied when a information about a number or a range
of numbers is changed.

The second of the specific interfaces is named the ENUM Resolution
Database interface.  This interface dispenses resolution information
to the resolution system, roughly equivalent to a DNS IXFR [RFC1995]
in content.  For reasons of openness, this interface is not strictly
assumed to be a DNS data flow.

The other interfaces are too varied and already specifically defined
by the administration involved that they will not be discussed further
in this requirement document.

2 Terminology

The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
document are to be interpreted as described in RFC 2119.

Terms used elsewhere in the document (including in the introduction):

ASCII - American Standard Code for Information Interchange [RFC0020]
DNS   - Domain Name System [RFC1034]
RR    - Resource Record [RFC1034]
SOA   - Start of Authority [RFC1034] [RFC1035]
AXFR  - Authoritative Zone Transfer [RFC1034] [RFC1035]
TXT   - DNS Text record [RFC1035]
IXFR  - Incremental Zone Transfer [RFC1995]
SIP   - Session Initiation Protocol [RFC3261]
DDDS  - Dynamic Delegation Discovery Service [RFC3401]
NAPTR - Naming Authority Pointer record [RFC3403]
EPP   - Extensible Provisioning Protocol [RFC3730]
ENUM  - E.164 to URI DDDS [RFC3761]
URI   - Uniform Resource Identifiers [RFC3986]
IRI   - Internationalized Resource Identifiers [RFC3987]
TLS   - Transaction Layer Security [RFC4366]
E.164 - International Public Telecommunications Numbers [ITUE164]
SOAP  - Simple Object Access Protocol [SOAP1] [SOAP2] [SOAP3]
XML   - Extensible Markup Language [XML]
WSDL  - Web Services Description Language [WSDL1] [WSDL2] [WSDL3]
OSS   - Operational Support Systems [OSS]

3 ENUM Provisioning interface

The ENUM Provisioning interface has the following requirements.  Most of
these requirements also apply to the ENUM Resolution Database interface.

3.1 Application Layer

These requirements match fit at the application layer of the network stack.

3.1.1 MUST be able to covey all of the information required for a DNS
NAPTR resource record.

o The DDDS operates on the NAPTR record.  Public standards are based on
this record.  It is not that the record is important, but that the
information in it has been well thought out.  Deviating from this may
curtail future growth.

3.1.2 MUST be able to convey all of the information required for a DNS TXT
resource record or any other record type that can conceivably be used in

o As a temporary measure for data that is not present in any ENUM service
definition [IANAENUM].

3.1.3 MUST be able to associate an RR set with any E.164 number, whether
the number refers to a specific telephone number or a range or block of
telephone numbers.

o E.164 is a string up upto 15 digits, but operating on just 7 (a North
American 1000 block) is permitted.

3.1.4 MUST be able to express the maximum number of digits in an E.164

o Because the number of digits varies, when operating on a block, the
number of digits of individual numbers must be known.  Perhaps this will
be available via another source, so this may be MUST to be able, MAY be

3.1.5 MUST be able to express the publication rules for any registered

o For data that differs upon the querier, such as the difference between
contacts and address-of-records in SIP.

3.1.6 MUST provide a means of tracking individual commands.

o Each command has to be identifiable for later actions.  The interface is
not involved in tracking.

3.1.7 SHOULD follow any applicable standards.

o Public standards are hardier than internally developed solutions.

3.1.8 SHOULD be easy to implement within legacy software development

o The participants in the environment have already established practices
based on SOAP/XML, WSDL, and TLS.

3.1.9 SHOULD provide a profile facility to allow a set of URI's for a set
of services to be associated with telephone numbers.

o One of the common "rewrite" rules for the URI will be of the form
"\1@somehost.company.example."  The "\1" refers to the telephone number
being processed, hence this kind of shorthand should be available when
activating a bulk of telephone numbers that will all be serviced the same

3.2 Presentation Layer

These requirements refer to the rendering of the messages in transmission.

3.2.1 MUST use an encoding method that is robust, easy to design and
troubleshoot, and is capable of supporting IRI's.

o Easy to design and troubleshoot lends itself to mechanisms that are text
based as opposed to binary or hexadecimal.  Internationalization is
important, for now at least host names might be in non-ASCII and sooner
or later other parts of a URI may also be.

3.2.2 SHOULD use a widely recognized standard.

o Avoiding specifically developed mechanisms.

3.3 Session Layer

Relates to methods, functions.

3.3.1 MUST provide methods for adding and deleting signal RR sets.

o Specifically adding an RR set or an RR to an existing set has to be
addressed, deleting a specific RR from a set or an entire RR set or
even a telephone number.

3.3.2 MUST provide methods for adding and deleting in bulk.

o At times an individual telephone number will be changed, but often times
many updates will be queued and sent at a fixed interval.

3.3.3 MUST provide atomic add and delete or change methods.

o Either having a change command or having atomic action guarantees is

3.3.4 SHOULD be constructed in a way compatible with legacy environments.

o Legacy environments use SOAP/XML, WSDL, and TLS.  That is not to say
that this interface as to do the same, but if it does, it will be
easier on the participants.

3.4 Transport Layer

The transport layer is strictly point-to-point, with no caching or
forwarding.  The requirements herein are related to security.  Security
is to be implemented in the applications exchanging data, the requirements
here are meant to say that relevant security data will be exchanged in the
building of the transport.

3.4.1 MUST provide data integrity.

3.4.2 MUST provide authentication (data).

3.4.3 MUST provide data secrecy.

o All three of these can be provided by using TLS, with the certificate
handshake being used by the application to complete the security needs.
Yes, this is an example of mentioning a solution in the requirements.

4 ENUM Resolution Database interface

All of the requirements for the ENUM Provisioning interface apply plus
the following, with the exception of requirement 3.1.5.

4.1 MUST allow the client to control the rate of flow of updates.

o The client could do this by asking the server to send up to some number
of records.  This is merely to allow the client to keep up with the

4.2 SHOULD be able to populate a DNS zone transfer message, once the
SOA RR is included.

o A DNS AXFR or IXFR consist of a zone's SOA resource record, followed by
a list of resource records, and followed by another copy of the SOA
resource record.  The SOA resource record has parameters best set by the
resolution system, so that is left to the client-side of this interface.
  But all of the rest of the zone transfer data ought to be able to be
pulled from the formats exchanged over this interface.

4.3 SHOULD be able to be used to populate a non-DNS resolution system.

o If for any reason an environment wants to not use DNS but still get the
benefit of an ENUM registry, they ought to be able to pull from the data
feed the relevant information.  How that would be done is not a subject
for this document, but it is assumed that it would be possible based on
the community review of DDDS and ENUM to date.

5 EPP Protocol

Breaking from requirements, there has been some consideration to EPP
extensions for ENUM [RFC4114], and why it has not been adopted and why
a requirements document is now being produced to cover what would
seemingly be addressed by that solution.

There are two reasons for EPP not being adopted.  One is that it isn't
compatible with legacy participants.  The other reason is that it
requires more implementation work.

Legacy participants have an existing base of software development built
around SOAP/XML and WSDL, and are familiar with TLS.  Approaches to ENUM
registry interfaces that use these tools will blend more easily into
the software products already in use to manage telephone numbers.

The use of SOAP permits automatic generation of software to handle the
client side of the exchange.  Domain name registries had to provide
software tool kits to give to registrars to match this functionality.
When a change is made to EPP, there will be a lot of software exchanged.

 From experience with both EPP and SOAP based approaches to registry
software, the SOAP based approach is much easier on the software
engineering process.  The difference between the approaches is not seen
in a protocol analysis, but in an analysis of software engineering.

6 Security Considerations

These interfaces are assumed to operate in a pre-arranged and secure
environment.  The interfaces are expected to uphold the security, other
than that the interfaces have no security concerns.

7 IANA Considerations

As this is a requirements document, there is nothing requested of IANA.

8 Internationalization Considerations

The only data sensitive to internationalization are the URI's (IRI's)
associated with ENUM services at a telephone number.  Solutions to these
requirements are called upon to provide a means to express URI's in any

9 References

9.1 Normative


9.2 Informative

[RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
            October 1969.
[RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.
[RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, November 1987.
[RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
            August 1996.
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
            Levels", BCP 14, RFC 2119, March 1997.
[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
            Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
            Session Initiation Protocol", RFC 3261, June 2002.
[RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
            One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
            Three: The Domain Name System (DNS) Database", RFC 3403,
            October 2002.
[RFC3730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
            RFC 3730, March 2004.
[RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
            Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
            Application (ENUM)", RFC 3761, April 2004.
[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
            January 2005.
[RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
            Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4114]  Hollenbeck, S., "E.164 Number Mapping for the Extensible
            Provisioning Protocol (EPP)", RFC 4114, June 2005.
[RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
            T. Wright, "Transport Layer Security (TLS) Extensions",
            RFC 4366, April 2006.
[ITUE164]  International Telecommunication Union, "The International
            Public Telecommunication Numbering Plan", Recommendation E.164,
            Approved 2005-02.
[SOAP1]    Nilo Mitra, "SOAP Version 1.2 Part 0: Primer",
            W3C REC-soap12-part0-20030624, 24 June 2003.
[SOAP2]    Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., and
            M. Gudgin, "SOAP Version 1.2 Part 1: Messaging Framework",
            W3C REC-soap12-part1-20030624, June 2003.
[SOAP3]    Moreau, J., Nielsen, H., Gudgin, M., Hadley, M., and
            N. Mendelsohn, "SOAP Version 1.2 Part 2: Adjuncts",
            W3C REC-soap12-part2-20030624, June 2003.
[XML]      John Cowan, Tim Bray, Jean Paoli, Eve Maler,
            C. M. Sperberg-McQueen, Francois Yergeau, "Extensible Markup
            Language (XML) 1.1 (Second Edition)", W3C REC-xml11-20060816,
            16 August 2006.
[WSDL1]    Arthur Ryman, Jean-Jacques Moreau, Roberto Chinnici,
            Sanjiva Weerawaran, "Web Services Description Language (WSDL)
            Version 2.0 Part 1: Core Language", W3C CR-wsdl20-20060327,
            27 March 2006.
[WSDL2]    Jean-Jacques Moreau, Sanjiva Weerawarana, Amelia A. Lewis, Hugo
            Haas, Roberto Chinnici, David Orchard, "Web Services
            Description Language (WSDL) Version 2.0 Part 2: Adjuncts",
            W3C CR-wsdl20-adjuncts-20060106, 27 March 2006.
[WSDL3]    David Booth, Canyang Kevin Liu, "Web Services Description
            Language (WSDL) Version 2.0 Part 0: Primer",
            W3C CR-wsdl20-primer-20060327, 27 March 2006.
[OSS]      "Operational Support Systems",
            14 January, 2007.
[IANAENUM] http://www.iana.org/assignments/enum-services

10 Author's Address
    Edward Lewis
    46000 Center Oak Plaza
    Sterling, VA
    20166, US

    Phone: +1-571-434-5468
    EMail: ed.lewis@neustar.biz

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

Edward Lewis                                                +1-571-434-5468

Dessert - aka Service Pack 1 for lunch.