Internet Engineering Task Force Scott Hollenbeck Internet-Draft Network Solutions, Inc. Registry March 9, 2000 Expires: September 9, 2000 Category-to-be: Informational Generic Registry Registrar Protocol (GRRP) Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in both generic Top Level Domain (gTLD) registries and country code Top Level Domain (ccTLD) registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. Conventions Used In This Document 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 [RFC2119]. Hollenbeck Expires September 9, 2000 [Page 1] Internet-Draft Generic RRP Requirements March 9, 2000 Table of Contents 1. Introduction ................................................. 2 1.1 Definitions, Acronyms, and Abbreviations .................... 2 2. General Description .......................................... 3 2.1 System Perspective .......................................... 3 2.2 System Functions ............................................ 4 2.3 User Characteristics ........................................ 4 2.4 Assumptions and Dependencies ................................ 4 3. Specific Requirements ........................................ 5 3.1 Functional Requirements ..................................... 5 3.2 External Interface Requirements ............................. 7 3.3 Performance Requirements .................................... 7 3.4 Design Constraints .......................................... 7 3.5 Service Attributes .......................................... 8 3.6 Other Requirements .......................................... 9 4. Internationalization Considerations .......................... 9 5. IANA Considerations .......................................... 10 6. Security Considerations ...................................... 10 7. References ................................................... 11 8. Author's Address ............................................. 11 9. Full Copyright Statement ..................................... 11 1. Introduction The advent of shared domain name registration systems illustrates the utility of a generic protocol for registry-registrar interaction. A standard generic protocol will allow registrars to communicate with multiple registries through a common interface, reducing operational complexity and expanding business opportunities. This document describes the high-level functional and interface requirements for a generic registry registrar protocol. Detailed technical requirements are not addressed in this document. This document is being discussed on the "rrp" mailing list. To join the list, send a message to with the words "subscribe rrp" in the body of the message. There is a web site for the list archives at . 1.1 Definitions, Acronyms, and Abbreviations ccTLD: Country Code Top Level Domain. ".us" is an example of a ccTLD. CORE: Council of Registrars Exclusive Registration System: A domain name registration system in which registry services are limited to a single registrar. Exclusive Registration Systems may be either loosely coupled (in which case the Hollenbeck Expires September 9, 2000 [Page 2] Internet-Draft Generic RRP Requirements March 9, 2000 separation between registry and registrar systems is readily evident), or tightly coupled (in which case the separation between registry and registrar systems is obscure). gTLD: Generic Top Level Domain. ".com" is an example of a gTLD. IANA: Internet Assigned Numbers Authority IETF: Internet Engineering Task Force NSI: Network Solutions, Inc. Registrant: An entity that registers domain names in a registry through the services provided by a registrar. Registrants include individuals, organizations, and corporations. Registrar: An entity that provides front-end domain name registration services to registrants, providing a public interface to registry services. Registry: An entity that provides back-end domain name registration services to registrars, managing a central repository of information for a given TLD. Shared Registration System: A domain name registration system in which registry services are shared among multiple independent registrars. Shared Registration Systems require a loose coupling between registrars and the registry. TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs. 2. General Description A basic understanding of domain name registration systems provides focus for the enumeration of functional and interface requirements of a protocol to serve those systems. This section provides a high-level description of domain name registration systems to provide context for the requirements identified later in this document. 2.1 System Perspective A domain name registration system consists of a protocol and associated software and hardware that permits registrars to provide Internet domain name registration services within the TLDs administered by a registry. A registration system may be shared among multiple competing registrars, or it may be served by a single registrar that is either tightly or loosely coupled with back-end Hollenbeck Expires September 9, 2000 [Page 3] Internet-Draft Generic RRP Requirements March 9, 2000 registry services. The system providing registration services for the .com, .net, and .org gTLDs is an example of a shared registration system serving multiple competing registrars. The systems providing registration services for many ccTLDs and the .gov and .mil gTLDs are examples of TLDs served by a single registrar. 2.2 System Functions Registrars access a registry through a protocol to register domain names and perform domain name management functions. Management functions include the registration of contacts and name servers; renewal or extension of a domain name registration period; deletions of domain names, name servers, and contacts; transfers of domain names; modification of domain names, name servers, and contacts; registration queries; and status queries. The registry generates DNS zone files for the TLDs it serves. These zone files are updated and distributed to a series of name servers that provide the foundation for the domain name system. Registries also provide a whois search capability that allows non- registrar users to perform basic information queries for the objects managed by the registry. Registry whois services may be centralized or distributed. A centralized registry whois service provides access to all registered objects without the need for referral to other whois services. A distributed registry whois service provides basic object information at the registry level, and requires referral to other registry or registrar whois services to obtain information for objects not registered with the queried registry. 2.3 User Characteristics Protocol users fall into two broad categories: registrars who develop or use protocol client implementations, and registries who develop or use protocol server implementations. The protocol provides a loose coupling between a registry and the registrars that access the registry. 2.4 Assumptions and Dependencies There is one and only one registry for a given TLD. A registry can be authoritative for more than one TLD. Some registry operations MAY be billable. The impact of a billable operation SHOULD be mitigated through the specification of non- billable operations that allow a registrar to make an informed decision before executing a billable operation. Hollenbeck Expires September 9, 2000 [Page 4] Internet-Draft Generic RRP Requirements March 9, 2000 3. Specific Requirements This section describes the complete, high-level requirements for a generic registry registrar protocol. Specific sub-sections that are not relevant are explicitly noted to clearly indicate the absence of requirements in particular areas. 3.1 Functional Requirements Functional requirements define the object registration and management services that must be provided by a generic registry registrar protocol. 3.1.1 Object Registration The protocol MUST provide services to register Internet domain names. Domain names MUST be registered for a yearly period with a definite expiration date and time derived from the date and time of initial registration. The protocol MUST provide services to register name servers. Name server registration MUST NOT be limited to a specific period of time. The protocol MUST provide services to register contact information describing entities associated with the registration of domain names and name servers. Contact registration MUST NOT be limited to a specific period of time. 3.1.2 Object Association The protocol MUST provide services to associate name servers with domain names. The protocol MUST provide services to associate contacts with name servers and domain names. 3.1.3 Object Modification The protocol MUST provide services to modify information associated with registered Internet domain names. The protocol MUST provide services to modify information associated with registered name servers. The protocol MUST provide services to modify information associated with registered contacts. 3.1.4 Object Transfer Hollenbeck Expires September 9, 2000 [Page 5] Internet-Draft Generic RRP Requirements March 9, 2000 The protocol MUST provide services to transfer domain names among authorized registrars. The protocol MUST provide services to transfer name servers among authorized registrars. The protocol MUST provides services to notify both the original sponsoring registrar and the potential new registrar of requested object transfers. The protocol MUST provide services that allow the original sponsoring registrar to explicitly approve or reject the transfer of an object. 3.1.5 Object Renewal/Extension The protocol MUST provide services to renew or extend the registration of registered Internet domain names. The renewal or extension period MUST be measured in annual increments. 3.1.6 Object Registration Status The protocol MUST provide services to determine if a domain name exists in the registry. The protocol MUST provide services to determine if a name server exists in the registry. The protocol MUST provide services to determine if a contact exists in the registry. 3.1.7 Object Deletion The protocol MUST provide services to remove a domain name from the registry. The protocol MUST provide services to remove a name server from the registry. The protocol MUST provide services to remove a contact from the registry. 3.1.8 Object Information Query The protocol MUST provide services to retrieve information describing a domain name from the registry. The protocol MUST provide services to retrieve information describing a name server from the registry. Hollenbeck Expires September 9, 2000 [Page 6] Internet-Draft Generic RRP Requirements March 9, 2000 The protocol MUST provide services to retrieve information describing a contact from the registry. 3.2 External Interface Requirements External interfaces define the interaction points between a system and entities that communicate with the system. Specific areas of interest include user interfaces, hardware interfaces, software interfaces, and communications interfaces. 3.2.1 User Interfaces A generic registry registrar protocol MUST NOT define any features that introduce user interface limitations. 3.2.2 Hardware Interfaces A generic registry registrar protocol MUST NOT define any features that introduce hardware interface limitations. 3.2.3 Software Interfaces A generic registry registrar protocol MUST NOT define any features that introduce software interface limitations. 3.2.4 Communications Interfaces Registries, registrars, and registrants interact using a wide spectrum of communications interfaces built upon multiple protocols, including transport layer protocols such as TCP and application layer protocols such as SMTP. A generic registry registrar protocol MUST be serviceable over multiple standard communications protocols. 3.3 Performance Requirements Run-time performance is an absolutely critical aspect of protocol usability. While performance is very heavily dependent on the hardware and software architecture that implements a protocol, protocol features can have a direct impact on the ability of the underlying architecture to provide optimal performance. A generic registry registrar protocol MUST be usable in both high volume and low volume operating environments. 3.4 Design Constraints Protocol designers need to be aware of issues beyond functional and interface requirements when balancing protocol design decisions. This section describes additional factors that may have an impact on Hollenbeck Expires September 9, 2000 [Page 7] Internet-Draft Generic RRP Requirements March 9, 2000 protocol design, including standards compliance and hardware limitations. 3.4.1 Standards Compliance A generic registry registrar protocol MUST conform to current IETF standards. Standards for domain and host name syntax, IP address syntax, and security are particularly relevant. Emerging standards for the domain name system SHOULD be considered as they approach maturity. 3.4.2 Hardware Limitations A generic registry registrar protocol MUST NOT define any features that preclude hardware independence. 3.5 Service Attributes Elements of service beyond functional and interface requirements are essential factors to consider as part of a protocol design effort. This section describes several important service elements that MUST be addressed by protocol designers, including reliability, availability, scalability, and maintainability. 3.5.1 Reliability Reliability is a measure of the extent to which a protocol provides a consistent, dependable level of service. Reliability is an important attribute for a domain name management protocol. An unreliable protocol increases the risk of data exchange errors, which at one extreme may have a direct impact on protocol usability and at the other extreme may introduce discontinuity between registry and registrar data stores. A generic registry registrar protocol MUST thus include features that maximize reliability at the application protocol layer. Services provided by underlying transport, session, and presentation protocols SHOULD also be considered when addressing application protocol reliability. 3.5.2 Availability Availability is a measure of the extent to which the services provided by a protocol are accessible for an intended use. Availability of an application layer protocol is primarily dependent on the software and hardware systems that implement the protocol. That is, the systems that implement the protocol must themselves be inherently available. As such, a generic registry registrar protocol MUST NOT include any features that impinge on the underlying reliability of the software and hardware systems needed to implement the protocol. Hollenbeck Expires September 9, 2000 [Page 8] Internet-Draft Generic RRP Requirements March 9, 2000 3.5.3 Scalability Scalability is a measure of the extent to which a protocol can accommodate use growth while preserving acceptable operational characteristics. A generic registry registrar protocol MUST be capable of operating at an acceptable level as the load on registry and registrar systems increases. 3.5.4 Maintainability Maintainability is a measure of the extent to which a protocol can be adapted or modified to address unforeseen operational needs or defects. A generic registry registrar protocol SHOULD be developed under the nominal working group processes of the IETF to provide a well-known channel for ongoing maintenance. 3.6 Other Requirements Certain aspects of anticipated operational environments should be considered when designing a generic registry registrar protocol. Areas of concern include database operations, daily operations, and site adaptation. 3.6.1 Database Requirements A generic registry registrar protocol MUST NOT have any database dependencies. However, efficient use of database operations and resources MUST be considered as part of the protocol design effort. The protocol SHOULD provide atomic features that can be efficiently implemented to minimize database load for anticipated high volume transactions. 3.6.2 Operations Requirements Registry-registrar interactions at the protocol level SHOULD operate without human intervention. A generic registry registrar protocol SHOULD NOT require operator involvement to complete transactions. 3.6.3 Site Adaptation Requirements Registries and registrars have varying business and operational requirements. Several factors, including governance standards, local laws, customs, and business practices all play roles in determining how registries and registrars are operated. A generic registry registrar protocol MUST be flexible enough to operate in diverse registry-registrar environments. 4. Internationalization Considerations Hollenbeck Expires September 9, 2000 [Page 9] Internet-Draft Generic RRP Requirements March 9, 2000 Current Internet standards restrict the encoding of Internet host and domain names to a subset of the 7-bit US-ASCII character set. Registries and registrars now serve customers whose native languages require encodings other than US-ASCII, which automatically disallows use of those languages when registering host and domain names. Support for internationalized host and domain names will greatly increase world-wide usability of a generic registry registrar protocol, so standards for internationalized host and domain names MUST be considered during the protocol design process. 5. IANA Considerations IANA has assigned several TCP and UDP ports for use within shared domain name registration systems. The assignments can be identified in two broad categories: those assigned for use with the CORE Shared Registry System Protocol (SRSP) and those assigned for use with the NSI Registry Registrar Protocol (RRP). The CORE SRSP assignments are as follows: srssend 362/tcp SRS Send srssend 362/udp SRS Send srsp 2682/tcp SRSP srsp 2682/udp SRSP The NSI RRP assignments are as follows: rrp 648/tcp Registry Registrar Protocol (RRP) rrp 648/udp Registry Registrar Protocol (RRP) These assignments should be preserved as long as the corresponding systems are operational. Additional port assignments may be required of IANA if the design of the generic registry registrar protocol specifies transport using TCP and/or UDP. 6. Security Considerations A generic registry registrar protocol MUST provide several security services including confidentiality, authentication, access control, integrity, and non-repudiation. Confidentiality services are required to protect sensitive exchanged information from inadvertent disclosure. Authentication services are required to confirm the claimed identity of registries and registrars before engaging in online transactions. Access control services are required to restrict registrar access to data that belongs to other registrars. Integrity services are required to guarantee that exchanged data has not been altered between the registry and the registrar. Non-repudiation services are required to assure that the sender of a transaction can Hollenbeck Expires September 9, 2000 [Page 10] Internet-Draft Generic RRP Requirements March 9, 2000 not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction. 7. References [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Author's Address Scott Hollenbeck Network Solutions, Inc. Registry 505 Huntmar Park Dr. Herndon, VA 20170 USA shollenb@netsol.com 9. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Hollenbeck Expires September 9, 2000 [Page 11]