Internet Engineering Task Force S. Hollenbeck Internet-Draft VeriSign, Inc. October 9, 2000 Expires: April 9, 2001 Generic Registry-Registrar Protocol 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 shared Top Level Domain (TLD) 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 April 9, 2001 [Page 1] Internet-Draft Generic RRP Requirements October 9, 2000 Table of Contents 1. Introduction ................................................. 4 1.1 Definitions, Acronyms, and Abbreviations .................... 4 2. General Description .......................................... 6 2.1 System Perspective .......................................... 6 2.2 System Functions ............................................ 6 2.3 User Characteristics ........................................ 6 2.4 Assumptions ................................................. 7 3. Functional Requirements ...................................... 8 3.1 Session Management .......................................... 8 3.2 Identification and Authentication ........................... 8 3.3 Transaction Identification .................................. 8 3.4 Object Registration ......................................... 9 3.5 Object Association .......................................... 10 3.6 Object Update ............................................... 10 3.7 Object Transfer ............................................. 11 3.8 Object Renewal/Extension .................................... 12 3.9 Object Existence Query ...................................... 13 3.10 Object Deletion ............................................ 13 3.11 Object Information Query ................................... 13 3.12 Domain Status Indicators ................................... 14 3.13 Transaction Completion Status .............................. 15 4. External Interface Requirements .............................. 16 4.1 User Interfaces ............................................. 16 4.2 Hardware Interfaces ......................................... 16 4.3 Software Interfaces ......................................... 16 4.4 Communications Interfaces ................................... 16 5. Performance Requirements ..................................... 17 6. Design Constraints ........................................... 17 6.1 Standards Compliance ........................................ 17 6.2 Hardware Limitations ........................................ 17 7. Service Attributes ........................................... 18 7.1 Reliability ................................................. 18 7.2 Availability ................................................ 18 7.3 Scalability ................................................. 18 7.4 Maintainability ............................................. 18 7.5 Extensibility ............................................... 19 8. Other Requirements ........................................... 20 8.1 Database Requirements ....................................... 20 8.2 Operations Requirements ..................................... 20 8.3 Site Adaptation Requirements ................................ 20 8.4 Date Format Requirements .................................... 20 9. Internationalization Considerations .......................... 21 10. IANA Considerations ......................................... 21 11. Security Considerations ..................................... 22 12. References .................................................. 23 13. Author's Address ............................................ 23 Hollenbeck Expires April 9, 2001 [Page 2] Internet-Draft Generic RRP Requirements October 9, 2000 14. Full Copyright Statement .................................... 23 Hollenbeck Expires April 9, 2001 [Page 3] Internet-Draft Generic RRP Requirements October 9, 2000 1. Introduction The advent of shared domain name registration systems illustrates the utility of a common, 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. This document describes high level functional and interface requirements for a generic provisioning protocol suitable for registry-registrar operations. 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 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 IP Address: Either or both IPv4 or IPv6 address. NSI: Network Solutions, Inc. Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic registry- registrar protocol. 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 Hollenbeck Expires April 9, 2001 [Page 4] Internet-Draft Generic RRP Requirements October 9, 2000 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. A registry is typically responsible for publication and distribution of TLD zone files used by the Domain Name System. 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 a registry. Thick Registry: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository. Thin Registry: A registry in which some element of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry. TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy. Hollenbeck Expires April 9, 2001 [Page 5] Internet-Draft Generic RRP Requirements October 9, 2000 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 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 objects and perform object management functions. Required functions include session management; object creation, update, and deletion; and object query. The registry generates DNS zone files for the TLDs it serves. These zone files are created 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 provides basic query services for the objects managed by the registry. Registry whois services may be centralized or distributed. A centralized registry whois service provides information 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 maintained 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. A protocol provides a loose Hollenbeck Expires April 9, 2001 [Page 6] Internet-Draft Generic RRP Requirements October 9, 2000 coupling between a registry and the registrars that access the registry. 2.4 Assumptions There is one and only one registry that is authoritative 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 informed decisions before executing billable operations. A registry MAY choose to implement a subset of the features provided by a generic registry-registrar protocol. A thin registry, for example, might not provide services to register contact information. Specification of minimal implementation compliance requirements is thus an exercise left for a formal protocol definition document that addresses the requirements specified here. A protocol that meets the requirements described here MAY be called something other than "Generic Registry Registrar Protocol". Hollenbeck Expires April 9, 2001 [Page 7] Internet-Draft Generic RRP Requirements October 9, 2000 3. Functional Requirements This section describes the complete, high-level requirements for a generic registry-registrar protocol. Functional requirements define the object registration and management services that must be provided by a registration system provisioned through a generic registry- registrar protocol. 3.1 Session Management [1] The protocol MUST provide services to explicitly establish a session with a registry server. [2] In a connection-oriented environment, a server MUST respond to connection attempts with a banner that identifies the server and the default server protocol version. [3] The protocol MUST provide services that allow a client to request use of a specific protocol version as part of negotiating a session. [4] The protocol MUST provide services that allow a server to decline use of a specific protocol version as part of negotiating a session. [5] A session MUST NOT be established if the client and server are unable to reach agreement on the protocol version to be used for the requested session. [6] The protocol MUST provide services to explicitly end an established session. 3.2 Identification and Authentication [1] The protocol MUST provide services to identify registrar clients before granting access to other protocol services. [2] The protocol MUST provide services to authenticate registrar clients before granting access to other protocol services. 3.3 Transaction Identification [1] Registry operations that create, update, or delete objects MUST be associated with a registry-unique transaction identifier. The identifier SHOULD be created using the current date and a combination of identification information assigned by and unique to the registry (such as a registrar identifier) and information assigned by and unique to the registrar requesting the operation (such as a coded combination of letters and numbers). Hollenbeck Expires April 9, 2001 [Page 8] Internet-Draft Generic RRP Requirements October 9, 2000 [2] A generic registry-registrar protocol MUST provide features that allow a registrar to provide a transaction identifier when performing a create, update, or delete operation. The registry MUST associate the identifier with the requested operation, and MUST return the identifier to the registrar upon completion of the operation. 3.4 Object Registration [1] The protocol MUST provide services to register Internet domain names. The registration period for domain names MUST be measured in years, with a minimum period of one year and a maximum period defined by registry policy. [2] When a domain name has been successfully registered, the protocol MUST return a definite expiration date and time derived from the requested registration period and the date and time of initial registration. [3] A request to register an object MUST include a transaction identifier. The transaction identifier MUST be returned to the registrant by the registrar to facilitate authorization of future transfer requests. [4] The protocol MUST provide services to register name servers. Name server registration MUST NOT be limited to a specific period of time. Name servers registered within the registry's authoritative TLDs MUST be registered with a valid Internet Protocol (IP) address. A name server MAY be registered with multiple IP addresses. An IP address MAY be shared among multiple name servers using distinct server names. Name servers that exist in TLDs other than those for which the registry is authoritative MUST be registered without an IP address providing that the server TLD is itself a valid TLD. [5] The protocol MUST consider that the name server associated with a domain might not be registered in the same domain or even in a TLD for which the registry is authoritative. This means that IP addresses for name servers whose parent domain exists in another TLD MUST be registered only in the registry that is authoritative for the TLD of the name server. Glue records (DNS "A" records) MUST NOT be created for DNS NS records for which the registry is not authoritative. [6] The protocol MUST provide services to register contact information describing human and organizational entities. Contact registration MUST NOT be limited to a specific period of time. Contact registration MUST include a name (individual name, organization name, or both), address (including street address, city, state or province (if applicable), postal code, and country), telephone number, and e- mail address. A facsimile telephone number MAY be provided. Hollenbeck Expires April 9, 2001 [Page 9] Internet-Draft Generic RRP Requirements October 9, 2000 [7] Telephone numbers associated with a registered object MUST conform to international standards for telephone number formatting. [8] All registered objects MUST be referenced using identifiers that are unique to the registry. For example, a domain name MUST be unique within a registry. A name server name MUST be unique within a registry. A contact identifier MUST be unique within a registry. [9] A registry MUST provide services to support a configurable grace period during which time a request to register a domain name or other billable object can be undone without harm. [10] All registrars MUST be authorized to register objects in the registry. Name server registration MUST be limited to the registrar of the name server's parent domain. Unauthorized attempts to register a name server in a parent domain administered by another registrar MUST be explicitly rejected. 3.5 Object Association [1] The protocol MUST provide services to associate name servers with domain names. A domain name MAY have multiple authoritative name servers. A name server MAY be authoritative for multiple domain names. [2] The protocol MUST provide services to associate IP addresses with name servers. A name server MAY have multiple IP addresses. An IP address MAY be associated with multiple name servers. [3] The protocol MUST provide services to associate contacts with domain names. Associated contacts name MUST be identified by type. Contact types that MAY be associated with a domain name include "registrant", "technical", "administrative", and "billing". A registry MAY support a subset of these contact types. [4] Some managed objects represent shared resources that MAY be referenced by multiple registrars. Requests to an associate a known shared resource object with another registered object MUST NOT be limited to the registrar that sponsors the registered objects. For example, server ns1.example.com (managed by registrar X) MAY be associated with both domain example.com (managed by registrar X) and domain test.com (managed by registrar Y). Registrar X maintains administrative control over domain example.com and server ns1.example.com, and registrar Y maintains administrative control over domain test.com. Registrar Y does not have administrative control over server ns1.example.com. 3.6 Object Update Hollenbeck Expires April 9, 2001 [Page 10] Internet-Draft Generic RRP Requirements October 9, 2000 [1] The protocol MUST provide services to update information associated with registered Internet domain names. Domain name update services MUST allow changes to status, associated name servers, and associated contacts. [2] The protocol MUST provide services to update information associated with registered name servers. Name server update services MUST allow change to IP addresses and server name. [3] The protocol MUST provide services to update information associated with registered contacts. Contact update services MUST allow change to all attributes associated with a contact. [4] Requests to update registered objects MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to update a registered object MUST be explicitly rejected. 3.7 Object Transfer [1] The protocol MUST provide services to transfer domain names among authorized registrars. Name servers registered in a domain being transferred MUST be transferred along with the domain itself. For example, name servers "ns1.example.com" and "ns2.example.com" MUST be implicitly transferred when domain "example.com" is transferred. [2] The protocol MUST provide services to transfer contacts among authorized registrars. [3] Transfer requests MUST be initiated by the registrar who wishes to become the new administrator of an object. [4] A transfer request MUST include the transaction identifier associated with either creation of the object or the most recently completed transfer of the object. [5] A transfer request MUST include a new transaction identifier. The new transaction identifier MUST be returned to the registrant by the registrar to facilitate authorization of future transfer requests. [6] The protocol MUST provide services that allow the requesting registrar to cancel a requested object transfer before the request has been approved or rejected by the original sponsoring registrar. Requests to cancel the transfer of registered objects MUST be limited to the registrar that requested transfer of the registered object. A request to cancel the transfer of an object MUST include the transaction identifier associated with either creation of the object or the most recently completed transfer of the object. Unauthorized attempts to cancel the transfer of a registered object MUST be Hollenbeck Expires April 9, 2001 [Page 11] Internet-Draft Generic RRP Requirements October 9, 2000 explicitly rejected. [7] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. Requests to approve or reject the transfer of registered objects MUST be limited to the registrar that currently sponsors the registered object. A request to approve the transfer of an object MUST include the transaction identifier associated with either creation of the object or the most recently completed transfer of the object. Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected. [8] The protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to monitor the status of both pending and completed transfer requests. [9] Object transfer requests MUST NOT be acted upon without giving the losing registrar an opportunity to respond to the request. A registry MUST provide services to support a configurable period during which time a request to transfer the registration of an object MAY be approved, rejected, or cancelled. [10] A registry MUST provide a default transfer action in case of registrar inaction. If a registry-specified period of time elapses without explicit approval, rejection, or cancellation, a registry MUST perform the default transfer action on behalf of the requesting registrar. [11] Transfer of an object MAY extend the object's registration period. If an object's registration period will be extended as the result of a transfer, the new expiration date and time MUST be returned after successful completion of a transfer request. [12] Requests to initiate the transfer of a registered object MUST be available to all authorized registrars. 3.8 Object Renewal/Extension [1] The protocol MUST provide services to renew or extend the registration of registered domain names. The renewal or extension period MUST be measured in annual increments subject to minimum and maximum registration periods supported by the registry. The new expiration date and time MUST be returned after successful completion of a renewal/extension request. [2] A registry MUST provide services to support a configurable grace period during which time a request to renew or extend the registration of a domain name can be undone without harm. Hollenbeck Expires April 9, 2001 [Page 12] Internet-Draft Generic RRP Requirements October 9, 2000 [3] Requests to renew or extend the registration of registered objects MUST be limited to the registrar that currently sponsors the registered objects. Unauthorized attempts to renew or extend the registration of registered objects MUST be explicitly rejected. 3.9 Object Existence Query [1] The protocol MUST provide services to determine if a domain name exists in the registry. Domain names MUST be searchable by fully qualified name. [2] The protocol MUST provide services to determine if a name server exists in the registry. Name servers MUST be searchable by fully qualified name. [3] The protocol MUST provide services to determine if a contact exists in the registry. Contacts MUST be searchable by registry identifier. [4] A query to determine if an object exists in the registry MUST return only a positive or negative response so that server software that responds to this query can be optimized for speed. [5] Requests to determine the existence of a registered object MUST be available to all authorized registrars. 3.10 Object Deletion [1] The protocol MUST provide services to remove a domain name from the registry. Deleting a domain name MUST also delete all child name servers. A domain name MUST NOT be deleted if child name servers are being used to host other domain names. [2] The protocol MUST provide services to remove a name server from the registry. Name servers MUST be referenced by fully-qualified name. A name server MUST NOT be deleted if it is being used to host a domain name. [3] The protocol MUST provide services to remove a contact from the registry. Contacts MUST be referenced by registry identifier. A contact MUST NOT be deleted if it is associated with a domain. [4] Requests to delete a registered object MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to delete a registered object MUST be explicitly rejected. 3.11 Object Information Query Hollenbeck Expires April 9, 2001 [Page 13] Internet-Draft Generic RRP Requirements October 9, 2000 [1] The protocol MUST provide services to retrieve information describing a domain name from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the domain, the creation date and time, the expiration date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), the current status of the domain, the most recent creation or transfer transaction identifier, contact identifiers associated with the domain, and the child name servers registered in the domain. The most recent creation or transfer transaction identifier MUST be returned only to the current sponsoring registrar. [2] The protocol MUST provide services to retrieve information describing a name server from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the name server, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), the IP addresses currently associated with the name server, and the most recent creation or transfer transaction identifier. The most recent creation or transfer transaction identifier MUST be returned only to the current sponsoring registrar. [3] The protocol MUST provide services to retrieve information describing a contact from the registry. Contacts MUST be referenced by registry identifier. Returned information MUST include the identification attributes of the contact (name, address, telephone numbers, and e-mail address), the identifier of the registrar that originally registered the contact, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last successful transfer request or completed transfer (if any), and the most recent creation or transfer transaction identifier. The most recent creation or transfer transaction identifier MUST be returned only to the current sponsoring registrar. [4] Requests to retrieve information describing a registered object MAY be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to retrieve information describing a registered object MUST be explicitly rejected. 3.12 Domain Status Indicators [1] The protocol MUST provide status indicators that identify the Hollenbeck Expires April 9, 2001 [Page 14] Internet-Draft Generic RRP Requirements October 9, 2000 operational state of a domain name. Indicators MUST be provided to identify a newly created state (the domain has been registered but has not yet appeared in a zone), a nominal active state (the domain can be modified and is published in a zone), an inactive state (the domain can be modified but is not published in a zone because it has no authoritative name servers), a hold state (the domain may not be modified and is not published in a zone), a lock state (the domain may not be modified and is published in a zone), a pending transfer state, and a pending removal state. [2] Indicators for hold and lock status MUST be available to allow independent setting by both registry and registrar. [3] A domain MAY have multiple statuses at any given time. Some statuses MAY be mutually exclusive. 3.13 Transaction Completion Status [1] The protocol MUST provide services that unambiguously note the success or failure of every transaction. Individual success and error conditions MUST be noted distinctly. Hollenbeck Expires April 9, 2001 [Page 15] Internet-Draft Generic RRP Requirements October 9, 2000 4. 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. 4.1 User Interfaces [1] A generic registry-registrar protocol MUST NOT define any features that introduce user interface limitations. 4.2 Hardware Interfaces [1] A generic registry-registrar protocol MUST NOT define any features that introduce hardware interface limitations. 4.3 Software Interfaces [1] A generic registry-registrar protocol MUST NOT define any features that introduce software interface limitations. 4.4 Communications Interfaces [1] 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 SHOULD be serviceable over multiple standard communications protocols. Hollenbeck Expires April 9, 2001 [Page 16] Internet-Draft Generic RRP Requirements October 9, 2000 5. Performance Requirements [1] 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. 6. 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 protocol design, including standards compliance and hardware limitations. 6.1 Standards Compliance [1] 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 MUST be considered as they approach maturity. 6.2 Hardware Limitations [1] A generic registry-registrar protocol MUST NOT define any features that preclude hardware independence. Hollenbeck Expires April 9, 2001 [Page 17] Internet-Draft Generic RRP Requirements October 9, 2000 7. 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. 7.1 Reliability [1] 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 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. [2] Default actions for when a request/event times out MUST be well defined, and the protocol MUST consider the risk/consequences of losing such events. 7.2 Availability [1] 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. 7.3 Scalability [1] 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. 7.4 Maintainability Hollenbeck Expires April 9, 2001 [Page 18] Internet-Draft Generic RRP Requirements October 9, 2000 [1] 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. 7.5 Extensibility [1] Extensibility is a measure of the extent to which a protocol can be adapted for future uses that were not readily evident when the protocol was originally designed. A generic registry-registrar protocol SHOULD provide features that at a minimum allow for the management of new object types without requiring revisions to the protocol itself. Hollenbeck Expires April 9, 2001 [Page 19] Internet-Draft Generic RRP Requirements October 9, 2000 8. 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, site adaptation, and date formatting. 8.1 Database Requirements [1] 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. 8.2 Operations Requirements [1] Registry-registrar interactions at the protocol level SHOULD operate without human intervention. However, intermediate services that preserve the integrity of the protocol MAY be provided. For example, an intermediate service that determines if a registrant is authorized to register a name in a TLD MAY be provided. 8.3 Site Adaptation Requirements [1] 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. 8.4 Date Format Requirements [1] All date and time values specified in the generic registry- registrar protocol MUST be expressed in Universal Coordinated Time, also known as Greenwich Mean Time, or Zulu. Dates and times MUST include information similar to that available in the following format: YYYYMMDDHHMMSS.fffZ where "YYYY" represents the year, the first "MM" represents the calendar month (with values ranging from 01 - 12 representing January through December), "DD" represents the calendar day, "HH" represents the hour in 24-hour format, the second "MM" represents minutes, "SS" represents seconds, ".fff" represents fractional seconds, and "Z" represents Zulu time. Hollenbeck Expires April 9, 2001 [Page 20] Internet-Draft Generic RRP Requirements October 9, 2000 9. Internationalization Considerations [1] 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. 10. IANA Considerations IANA has assigned several TCP and UDP ports for use within shared 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. Hollenbeck Expires April 9, 2001 [Page 21] Internet-Draft Generic RRP Requirements October 9, 2000 11. Security Considerations Several security services, including confidentiality, authentication, access control, integrity, and non-repudiation MAY be applied to protect interactions between registries and registrars. Confidentiality services protect sensitive exchanged information from inadvertent disclosure. Authentication services confirm the claimed identity of registries and registrars before engaging in online transactions. Access control services control access to data and services based on identity. Integrity services guarantee that exchanged data has not been altered between the registry and the registrar. Non-repudiation services provide assurance that the sender of a transaction can not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction. [1] Security services MUST be provided to protect against the following types of attack: eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle. A registry MUST also provide mechanisms to protect against denial of service attacks. [2] This document describes requirements for basic user identification and authentication services. A generic protocol MAY include additional security services to protect against the attacks described here, or a generic protocol MAY depend on lower-layer protocols to provide additional security services. Hollenbeck Expires April 9, 2001 [Page 22] Internet-Draft Generic RRP Requirements October 9, 2000 12. References [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 13. Author's Address Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166 USA shollenb@netsol.com 14. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hollenbeck Expires April 9, 2001 [Page 23]