Internet Engineering Task Force Scott Hollenbeck Internet-Draft Network Solutions, Inc. Registry June 12, 2000 Expires: December 12, 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 December 12, 2000 [Page 1] Internet-Draft Generic RRP Requirements June 12, 2000 Table of Contents 1. Introduction ................................................. 2 1.1 Definitions, Acronyms, and Abbreviations .................... 2 2. General Description .......................................... 3 2.1 System Perspective .......................................... 4 2.2 System Functions ............................................ 4 2.3 User Characteristics ........................................ 4 2.4 Assumptions and Dependencies ................................ 5 3. Specific Requirements ........................................ 5 3.1 Functional Requirements ..................................... 5 3.2 External Interface Requirements ............................. 11 3.3 Performance Requirements .................................... 11 3.4 Design Constraints .......................................... 11 3.5 Service Attributes .......................................... 12 3.6 Other Requirements .......................................... 13 4. Internationalization Considerations .......................... 14 5. IANA Considerations .......................................... 14 6. Security Considerations ...................................... 15 7. References ................................................... 16 8. Author's Address ............................................. 16 9. Full Copyright Statement ..................................... 16 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 December 12, 2000 [Page 2] Internet-Draft Generic RRP Requirements June 12, 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. 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. 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 Hollenbeck Expires December 12, 2000 [Page 3] Internet-Draft Generic RRP Requirements June 12, 2000 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 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 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. The protocol provides a loose coupling between a registry and the registrars that access the registry. Hollenbeck Expires December 12, 2000 [Page 4] Internet-Draft Generic RRP Requirements June 12, 2000 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. A registry MAY choose to implement a subset of the features provided by a generic registry-registrar protocol. A thin registry, for example, may 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. 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 Version Negotiation [1] The protocol MUST provide services to identify the protocol version requested by the client and provided by the server as part of negotiating a session. [2] 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. 3.1.2 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 of 99 years. Registries MAY support a lesser maximum registration period subject to local policies and practices. Hollenbeck Expires December 12, 2000 [Page 5] Internet-Draft Generic RRP Requirements June 12, 2000 [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] 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 MAY be registered without an IP address providing that the server TLD is itself a valid TLD. [4] 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 responsible. This means that the IP address(es) for name servers whose parent domain exists in another TLD SHOULD not be registered in the registry, but should instead fetched from the authoritative zone when needed. Glue records (DNS "A" records) MUST NOT be created for DNS NS records for which the registry is not authoritative. [5] 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. Contact registration MUST include a contact name, address (including street address, city, state or province, postal code, and country), telephone number (including country code), and e-mail address. Contact registration MAY include a facsimile telephone number (including country code). [6] All registered objects MUST be referenced using identifiers that are unique to the registry. For example, a domain name MUST be unique within a given registry. A name server name MUST be unique within a given registry. A name server IP address MAY be unique within a given registry. A contact MUST be unique within a given registry. [7] The protocol 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. [8] 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. Hollenbeck Expires December 12, 2000 [Page 6] Internet-Draft Generic RRP Requirements June 12, 2000 3.1.3 Object Association [1] The protocol MUST provide services to associate multiple name servers with domain names. Name servers MAY be associated with multiple domain names. [2] The protocol MUST provide services to associate IP addresses with name servers. A name server MAY be referenced by 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. REQUIRED contact types for a domain name include "registrant", "technical", "administrative", and "billing". [4] Requests to associate registered objects MUST NOT be limited to the registrar that currently sponsors the registered objects. While the registrar that registers an object retains administrative control of the object, registered name servers and contacts MAY be associated with objects registered by other registrars. 3.1.4 Object Modification [1] The protocol MUST provide services to modify information associated with registered Internet domain names. Domain name modification services MUST allow changes to status, associated name servers, and contacts. [2] The protocol MUST provide services to modify information associated with registered name servers. Name server modification services MUST allow change to IP addresses. [3] The protocol MUST provide services to modify information associated with registered contacts. Contact modification services MUST allow change to all attributes associated with a contact. [4] Requests to modify registered objects MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to modify a registered object MUST be explicitly rejected. 3.1.5 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. Hollenbeck Expires December 12, 2000 [Page 7] Internet-Draft Generic RRP Requirements June 12, 2000 [2] The protocol MUST provide services to transfer contacts among authorized registrars. [3] 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. Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected. [4] The protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to become aware of requested object transfers. [5] Transfer requests MUST be initiated by the registrar who wishes to become the new administrator of an object. [6] Implementations of the protocol MUST provide a default transfer action in case of registrar inaction. If a configurable period of time elapses without explicit approval or rejection, a registry MUST perform the default transfer action on behalf of the requesting registrar. [7] The protocol MUST provide services to support a configurable grace period during which time a request to transfer the registration of an object can be undone without harm. [8] Requests to initiate the transfer of a registered object MUST be available to all authorized registrars. 3.1.6 Object Renewal/Extension [1] 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 subject to the same minimum and maximum periods allowed during initial registration. The new expiration date and time MUST be returned after successful completion of a renewal/extension request. [2] The protocol 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. [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. Hollenbeck Expires December 12, 2000 [Page 8] Internet-Draft Generic RRP Requirements June 12, 2000 3.1.7 Object Existence Query [1] The protocol MUST provide services to determine if a domain name exists in the registry. Domain names SHOULD be searchable by fully qualified name. [2] The protocol MUST provide services to determine if a name server exists in the registry. Name servers SHOULD be searchable by fully- qualified name or IP address. [3] The protocol MUST provide services to determine if a contact exists in the registry. Contacts should 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.1.8 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 SHOULD be accessible by either fully- qualified name or IP address. A name server MUST NOT be deleted if it is being used to host a domain name. Removing a name server MUST also remove references to the name server from all associated domains. [3] The protocol MUST provide services to remove a contact from the registry. Contacts SHOULD be accessible by registry identifier. A contact MUST NOT be deleted if it is associated with a domain. Removing a contact MUST also remove all references to the contact from all associated domains. [4] The protocol MUST provide services to support a configurable grace period during which time requests to delete objects can be undone without harm. [5] 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. Hollenbeck Expires December 12, 2000 [Page 9] Internet-Draft Generic RRP Requirements June 12, 2000 3.1.9 Object Information Query [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 modification (if any), the identifier of the registrar that performed the last modification, the date and time of last successful transfer request or completed transfer (if any), and the current state of the domain. [2] The protocol MUST provide services to retrieve information describing a name server from the registry. A name server SHOULD be accessible by either name or IP address. 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 modification (if any), the identifier of the registrar that performed the last modification, the date and time of last successful transfer request or completed transfer (if any), and the IP addresses currently associated with the name server. If queried by IP address, the returned information MUST also include all names associated with the IP address. [3] The protocol MUST provide services to retrieve information describing a contact from the registry. Contacts SHOULD be accessible 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 modification (if any), and the identifier of the registrar that performed the last modification. [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 MAY be explicitly rejected. 3.1.10 Domain Status Indicators [1] The protocol MUST provide status indicators that identify the operational state of a domain name. Indicators MUST be provided to identify a nominal active state, a hold state (the domain may not be modified and is not published in the corresponding zone file), and a lock state (the domain may not be modified and is published in the corresponding zone file). Indicators for hold and lock status MUST be available to allow independent setting by both registry and registrar. Hollenbeck Expires December 12, 2000 [Page 10] Internet-Draft Generic RRP Requirements June 12, 2000 3.1.11 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. 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 [1] A generic registry registrar protocol MUST NOT define any features that introduce user interface limitations. 3.2.2 Hardware Interfaces [1] A generic registry registrar protocol MUST NOT define any features that introduce hardware interface limitations. 3.2.3 Software Interfaces [1] 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 [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. 3.4 Design Constraints Hollenbeck Expires December 12, 2000 [Page 11] Internet-Draft Generic RRP Requirements June 12, 2000 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. 3.4.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 SHOULD be considered as they approach maturity. 3.4.2 Hardware Limitations [1] 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 [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 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. [2] Default actions for when a request/event time out MUST be well defined, and the protocol MUST consider the risk/consequences of losing such events. 3.5.2 Availability [1] Availability is a measure of the extent to which the services Hollenbeck Expires December 12, 2000 [Page 12] Internet-Draft Generic RRP Requirements June 12, 2000 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. 3.5.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. 3.5.4 Maintainability [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. 3.5.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. 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 [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 Hollenbeck Expires December 12, 2000 [Page 13] Internet-Draft Generic RRP Requirements June 12, 2000 transactions. 3.6.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. 3.6.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. 3.6.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 be represented using this 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 is OPTIONAL), and "Z" represents Zulu time. 4. 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. 5. IANA Considerations Hollenbeck Expires December 12, 2000 [Page 14] Internet-Draft Generic RRP Requirements June 12, 2000 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 [1] 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 not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction. [2] Registry operations that create, update, or delete (CUD) objects MUST be associated with a registry-unique transaction identifier. The identifier SHOULD be created using 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 monotonically increasing transaction number). [3] A generic registry registrar protocol MUST provide features that Hollenbeck Expires December 12, 2000 [Page 15] Internet-Draft Generic RRP Requirements June 12, 2000 allow a registrar to provide a transaction identifier when performing a CUD operation. The registry MUST associate the identifier with the operation, and MUST return the identifier to the registrar upon completion of the operation. Associating a registrar-provided identifier with each CUD operation ensures that the identifier is known to the registrar at all times, even in cases when the registry fails to respond to the request or if the registry response is lost in transit to the registrar. 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 Hollenbeck Expires December 12, 2000 [Page 16] Internet-Draft Generic RRP Requirements June 12, 2000 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hollenbeck Expires December 12, 2000 [Page 17]