INTERNET-DRAFT                                              Edward Lewis
November 16, 2007                                          NeuStar, Inc.
Expires
May 16, 2008

                  ENUM Registry Interface Requirements
                draft-lewis-peppermint-enum-reg-if-01.txt

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/1id-abstracts.html

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

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

Abstract

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

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

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.

 Terminology

The key words "MUST," "SHOULD," and "MAY" in this document are to be
interpreted as described in RFC 2119 [RFC2119].

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]

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

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

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

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

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

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

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

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.

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

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.

 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.

 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.

 IANA Considerations

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

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

 References

9.1 Normative

(none)

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",
           http://en.wikipedia.org/wiki/Operational_Support_Systems,
           14 January, 2007.
[IANAENUM] http://www.iana.org/assignments/enum-services

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

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


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.

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.

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.

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

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.