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 <email@example.com> 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. 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 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. 2 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] 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 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 "\firstname.lastname@example.org." 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. 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 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. 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 script. 9 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 10 Author's Address Edward Lewis NeuStar 46000 Center Oak Plaza Sterling, VA 20166, US Phone: +1-571-434-5468 EMail: email@example.com 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 firstname.lastname@example.org.