Generic Registry-Registrar Protocol Requirements
RFC 3375

Network Working Group                                      S. Hollenbeck
Request for Comments: 3375                                Verisign, Inc.
Category: Informational                                   September 2002

            Generic Registry-Registrar Protocol Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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

Table of Contents

   1.  Introduction .......................................  2
   1.1 Definitions, Acronyms, and Abbreviations ...........  2
   2.  General Description ................................  4
   2.1 System Perspective .................................  4
   2.2 System Functions ...................................  4
   2.3 User Characteristics ...............................  5
   2.4 Assumptions ........................................  5
   3.  Functional Requirements ............................  5
   3.1 Session Management .................................  6
   3.2 Identification and Authentication ..................  6
   3.3 Transaction Identification .........................  7
   3.4 Object Management ..................................  7
   3.5 Domain Status Indicators ........................... 13

Hollenbeck                   Informational                      [Page 1]
RFC 3375                Generic RRP Requirements          September 2002

   3.6 Transaction Completion Status ...................... 13
   4.  External Interface Requirements .................... 14
   4.1 User, Hardware, and Software Interfaces ............ 14
   4.2 Communications Interfaces .......................... 14
   5.  Performance Requirements ........................... 14
   6.  Design Constraints ................................. 14
   6.1 Standards Compliance ............................... 14
   6.2 Hardware Limitations ............................... 15
   7.  Service Attributes ................................. 15
   7.1 Reliability ........................................ 15
   7.2 Availability ....................................... 15
   7.3 Scalability ........................................ 16
   7.4 Maintainability .................................... 16
   7.5 Extensibility ...................................... 16
   7.6 Security ........................................... 16
   8.  Other Requirements ................................. 17
   8.1 Database Requirements .............................. 17
   8.2 Operational Requirements ........................... 17
   8.3 Site Adaptation Requirements ....................... 17
   8.4 Data Collection Requirements ....................... 17
   9.  Internationalization Requirements .................. 18
   10. IANA Considerations ................................ 18
   11. Security Considerations ............................ 18
   12. Acknowledgements ................................... 19
   13. References ......................................... 19
   14. Editor's Address ................................... 20
   15. Full Copyright Statement ........................... 21

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.

1.1 Definitions, Acronyms, and Abbreviations

   ccTLD: Country Code Top Level Domain.  ".us" is an example of a
   ccTLD.

   DNS: Domain Name System

   gTLD: Generic Top Level Domain.  ".com" is an example of a gTLD.

Hollenbeck                   Informational                      [Page 2]
RFC 3375                Generic RRP Requirements          September 2002

   IANA: Internet Assigned Numbers Authority

   IETF: Internet Engineering Task Force

   IP Address: Either or both IPv4 or IPv6 address.

   IPv4: Internet Protocol version 4

   IPv6: Internet Protocol version 6

   RRP: Registry-Registrar Protocol

   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.

   Exclusive Registration System: A domain name registration system in
   which registry services are limited to a single registrar.  Exclusive
   Registration Systems are 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).

   Name Space: The range of values that can be assigned within a
   particular node of the domain name hierarchy.

   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
   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
   associated with domain name delegations.  A registry is typically
   responsible for publication and distribution of 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.

Hollenbeck                   Informational                      [Page 3]
RFC 3375                Generic RRP Requirements          September 2002

   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 all elements of the social
   information associated with registered entities is distributed
   between a shared registry and the registrars served by the registry.

   Zone: The complete set of information for a particular "pruned"
   subtree of the domain space.  The zone concept is described fully in
   [RFC1035].

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 name spaces
   administered by a registry.  A registration system can be shared
   among multiple competing registrars, or it can 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 some ccTLDs and the .gov and .mil gTLDs are
   examples of registration systems 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, renewal, and deletion;
   object query; and object transfer.

   A registry generates DNS zone files for the name spaces it serves.
   Zone files are created and distributed to a series of name servers
   that provide the foundation for the domain name system.

Hollenbeck                   Informational                      [Page 4]
RFC 3375                Generic RRP Requirements          September 2002

2.3 User Characteristics

   Protocol users fall into two broad categories: entities that use
   protocol client implementations and entities that use protocol server
   implementations, though an entity can provide both client and server
   services if it provides intermediate services.  A protocol provides a
   loose coupling between these communicating entities.

2.4 Assumptions

   There is one and only one registry that is authoritative for a given
   name space and zone.

   A registry can be authoritative for more than one name space and
   zone.  Some registry operations can be billable.  The impact of a
   billable operation can be mitigated through the specification of
   non-billable operations that allow a registrar to make informed
   decisions before executing billable operations.

   A registry can 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 social information.
   Specification of minimal implementation compliance requirements is
   thus an exercise left for a formal protocol definition document that
   addresses the functional requirements specified here.

   A protocol that meets the requirements described here can be called
   something other than "Generic Registry Registrar Protocol".

   The requirements described in this document are not intended to limit
   the set of objects that can be managed by a generic registry-
   registrar protocol.

3. Functional Requirements

   This section describes functional requirements for a registry-
   registrar protocol.  Technical requirements that describe how these
   requirements are to be met are out of scope for this document.

Hollenbeck                   Informational                      [Page 5]
RFC 3375                Generic RRP Requirements          September 2002

3.1 Session Management

   [1] The protocol MUST provide services to explicitly establish a
   client session with a registry server.

   [2] In a connection-oriented environment, a server MUST respond to
   connection attempts with information 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.

   [7] The protocol MUST provide services that provide transactional
   atomicity, consistency, isolation, and durability in the advent of
   session management failures.

   [8] The protocol MUST provide services to confirm that a transaction
   has been completed if a session is aborted prematurely.

3.2 Identification and Authentication

   [1] The protocol or another layered protocol MUST provide services to
   identify registrar clients and registry servers before granting
   access to other protocol services.

   [2] The protocol or another layered protocol MUST provide services to
   authenticate registrar clients and registry servers before granting
   access to other protocol services.

   [3] The protocol or another layered protocol MUST provide services to
   negotiate an authentication mechanism acceptable to both client and
   server.

Hollenbeck                   Informational                      [Page 6]
RFC 3375                Generic RRP Requirements          September 2002

3.3 Transaction Identification

   [1] Registry operations that create, modify, or delete objects MUST
   be associated with a registry-unique identifier.  The protocol MUST
   allow each transaction to be identified in a permanent and globally
   unique manner to facilitate temporal ordering and state management
   services.

3.4 Object Management

   This section describes requirements for object management, including
   identification, registration, association, update, transfer, renewal,
   deletion, and query.

3.4.1 Object Identification

   Some objects, such as name servers and contacts, have utility in
   multiple registries.  However, maintaining disjoint copies of object
   information in multiple registries can lead to inconsistencies that
   have adverse consequences for the Internet.  For example, changing a
   name server name in one registry, but not in a second registry that
   refers to the server for domain name delegation, can produce
   unexpected DNS query results.

   [1] The protocol MUST provide services to associate an object
   identifier with every object.

   [2] Object identifiers MUST be globally unique.

   [3] An object's identifier MUST NOT change during the lifetime of the
   object in a particular repository, even if administrative control of
   the object changes over time.

   [4] An object identifier MUST contain information that unambiguously
   identifies the object.

   [5] Object identifier format specified by the protocol SHOULD be
   easily parsed and understood by humans.

   [6] An object's identifier MUST be generated and stored when an
   object is created.

Hollenbeck                   Informational                      [Page 7]
RFC 3375                Generic RRP Requirements          September 2002

3.4.2 Object Registration

   [1] The protocol MUST provide services to register Internet domain
   names.

   [2] The protocol MUST permit a starting and ending time for a domain
   name registration to be negotiated, thereby allowing a registry to
   implement policies allowing a range of registration validity periods
   (the start and end points in time during which one normally assumes
   that an object will be active), and enabling registrars to select a
   period for each registration they submit from within the valid range
   based on out-of-band negotiation between the registrar and the
   registrant.  Registries SHOULD be allowed to accept indefinitely
   valid registrations if the policy that they are implementing permits,
   and to specify a default validity period if one is not selected by a
   registrar.  Registries MUST be allowed to specify minimal validity
   periods consistent with prevailing or preferred practices for fee-
   for-service recovery.  The protocol MUST provide features to ensure
   that both registry and registrar have a mutual understanding of the
   validity period at the conclusion of a successful registration event.

   [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 MUST be registered with a valid IPv4 or IPv6
   address when a "glue record" is required for delegation.  A name
   server MAY be registered with multiple IP addresses.  Multiple name
   servers using distinct server names MAY share an IP address.

   [4] The protocol MUST provide services to manage delegation of zone
   authority.  Names of name servers MUST NOT be required to be tied to
   the name of the zone(s) for which the server is authoritative.

   [5] The protocol MUST provide services to register social information
   describing human and organizational entities.  Registration of social
   information MUST NOT be limited to a specific period of time.  Social
   information MAY include a name (individual name, organization name,
   or both), address (including street address, city, state or province
   (if applicable), postal code, and country), voice telephone number,
   email address, and facsimile telephone number.

   [6] Protocol services to register an object MUST be available to all
   authorized registrars.

Hollenbeck                   Informational                      [Page 8]
RFC 3375                Generic RRP Requirements          September 2002

3.4.3 Object Association

   [1] The protocol MUST provide services to associate name servers with
   domain names to delegate authority for zones.  A domain name MAY have
   multiple authoritative name servers.  Name servers MAY be
   authoritative for multiple zones.

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

   [3] The protocol MUST provide services to associate social
   information with other objects.  Social information associations MUST
   be identified by type.  "Registrant" is an example social information
   type that might be associated with an object such as a domain name.

   [4] The protocol MUST provide services to associate object management
   capabilities on a per-registrar basis.

   [5] Some managed objects represent shared resources that might be
   referenced by multiple registrars.  The protocol MUST provide
   services that allow a registrar to associate an existing shared
   resource object with other registered objects sponsored by a second
   registrar.  For example, authority for the example.tld zone
   (example.tld domain object managed by registrar X) and authority for
   the test.tld zone (test.tld domain object managed by registrar Y)
   might be delegated to server ns1.example.tld (managed by registrar
   X).  Registrar X maintains administrative control over domain object
   example.tld and server object ns1.example.tld, and registrar Y
   maintains administrative control over domain object test.tld.
   Registrar Y does not have administrative control over server object
   ns1.example.tld.

3.4.4 Object Update

   [1] The protocol MUST provide services to update information
   associated with registered Internet domain names.

   [2] The protocol MUST provide services to update information
   associated with registered name servers.

   [3] The protocol MUST provide services to update social information
   associated with registered human and organizational entities.

   [4] The protocol MUST provide services to limit requests to update a
   registered object to the registrar that currently sponsors the
   registered object.

Hollenbeck                   Informational                      [Page 9]
RFC 3375                Generic RRP Requirements          September 2002

   [5] The protocol MUST provide services to explicitly reject
   unauthorized attempts to update a registered object.

3.4.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.tld" and "ns2.example.tld" MUST be
   implicitly transferred when domain "example.tld" is transferred.

   [2] The protocol MUST provide services to describe all objects,
   including associated objects, that are transferred as a result of an
   object transfer.

   [3] The protocol MUST provide services to transfer social information
   objects among authorized registrars.

   [4] Protocol transfer requests MUST be initiated by the registrar who
   wishes to become the new administrator of an object.

   [5] The protocol MUST provide services to confirm registrar
   authorization to transfer an object.

   [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.
   Unauthorized attempts to cancel the transfer of a registered object
   MUST be 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.  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] 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.

Hollenbeck                   Informational                     [Page 10]
RFC 3375                Generic RRP Requirements          September 2002

   [10] Requests to initiate the transfer of a registered object MUST be
   available to all authorized registrars.

   [11] Registrars might become non-functional and unable to respond to
   transfer requests.  It might be necessary for one registrar to assume
   management responsibility for the objects associated with another
   registrar in the event of registrar failure.  The protocol MUST NOT
   restrict the ability to transfer objects in the event of registrar
   failure.

3.4.6 Object Renewal/Extension

   [1] The protocol MUST provide services to renew or extend the
   validity period of registered domain names.  If applicable, the new
   expiration date and time MUST be returned after successful completion
   of a request to renew or extend the validity period.

   [2] Requests to renew or extend the validity period of a registered
   object MUST be limited to the registrar that currently sponsors the
   registered object.  Unauthorized attempts to renew or extend the
   validity period of a registered object MUST be explicitly rejected.

3.4.7 Object Deletion

   [1] The protocol MUST provide services to remove a domain name from
   the registry.

   [2] The protocol MUST provide services to remove a name server from
   the registry.

   [3] The protocol MUST provide services to remove a social information
   object from the registry.

   [4] Requests to remove a registered object MUST be limited to the
   registrar that currently sponsors the registered object.
   Unauthorized attempts to remove a registered object MUST be
   explicitly rejected.

3.4.8 Object Existence Query

   This section describes requirements for a lightweight query mechanism
   whose sole purpose is to determine if an object exists in a registry.

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

Hollenbeck                   Informational                     [Page 11]
RFC 3375                Generic RRP Requirements          September 2002

   [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 social
   information object exists in the registry.  Social information MUST
   be searchable by a registry-unique 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.4.9 Object Information Query

   This section describes requirements for a query mechanism whose
   purpose is to provide detailed information describing objects that
   exist in a registry.

   [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 (if any),
   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 completed transfer (if any), the current status of
   the domain, authorization information, identifiers describing social
   information associated with the domain, and the subordinate name
   servers registered in the domain.  Authorization information MUST
   only be returned 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 completed
   transfer (if any), and the IP addresses currently associated with the
   name server.

   [3] The protocol MUST provide services to retrieve social information
   from the registry.  Returned information MUST include identification
   attributes (which MAY include name, address, telephone numbers, and
   email address), the identifier of the registrar that originally

Hollenbeck                   Informational                     [Page 12]
RFC 3375                Generic RRP Requirements          September 2002

   registered the information, 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
   completed transfer (if any), and authorization information.
   Authorization information MUST only be returned to the current
   sponsoring registrar.

   [4] The protocol MUST provide services to identify all associated
   object references, such as name servers associated with domains
   (including delegations and hierarchical relationships) and contacts
   associated with domains.  This information MUST be visible if the
   object associations have an impact on the success or failure of
   protocol operations.

   [5] Requests to retrieve information describing a registered object
   MAY be granted by the registrar that currently sponsors the
   registered object.  Unauthorized attempts to retrieve information
   describing a registered object MUST be explicitly rejected.

3.5 Domain Status Indicators

   [1] The protocol MUST provide status indicators that identify the
   operational state of a domain name.  Indicators MAY be provided to
   identify a newly created state (the domain has been registered but
   has not yet appeared in a zone), a normal 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 can not be
   modified and is not published in a zone), a lock state (the domain
   can not be modified and is published in a zone), a pending transfer
   state, and a pending removal state.

   [2] If provided, protocol indicators for hold and lock status MUST
   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.6 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                   Informational                     [Page 13]
RFC 3375                Generic RRP Requirements          September 2002

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, Hardware, and Software Interfaces

   [1] The protocol MUST define a wire format for data exchange, not an
   application design for user, hardware, or software interfaces so that
   any application able to create the same bits on the wire, and to
   maintain the image of the same integrity constraints, is a valid
   implementation of the protocol.

4.2 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.  The protocol MUST only be run over IETF
   approved protocols that feature congestion control, such as TCP and
   SCTP.

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.  The 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 might have an impact
   on protocol design, including standards compliance and hardware
   limitations.

6.1 Standards Compliance

   [1] The protocol MUST conform to current IETF standards.  Standards
   for domain and host name syntax, IP address syntax, security, and
   transport are particularly relevant.  Emerging standards for the
   Domain Name System MUST be considered as they approach maturity.

Hollenbeck                   Informational                     [Page 14]
RFC 3375                Generic RRP Requirements          September 2002

   [2] The protocol MUST NOT reinvent services offered by lower layer
   protocol standards.  For example, the use of a transport that
   provides reliability is to be chosen over use of a non-reliable
   transport with the protocol itself using retransmission to achieve
   reliability.

6.2 Hardware Limitations

   [1] The protocol MUST NOT define any features that preclude hardware
   independence.

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 to be
   addressed by protocol designers, including reliability, availability,
   scalability, maintainability, extensibility, and security.

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 can have a direct impact on protocol usability and at
   the other extreme can introduce discontinuity between registry and
   registrar data stores.  The 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] The protocol MUST be run over the most reliable transport option
   available in a given environment.  The protocol MUST NOT implement a
   service that is otherwise available in an applicable standard
   transport.

   [3] Default protocol actions for when a request or event times out
   MUST be well defined.

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.

Hollenbeck                   Informational                     [Page 15]
RFC 3375                Generic RRP Requirements          September 2002

   The protocol MUST NOT include any features that impinge on the
   underlying availability of the software and hardware systems needed
   to service 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.  The protocol MUST be capable of operating at an
   acceptable level as the load on registry and registrar systems
   increases.

7.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.  The protocol SHOULD be developed under the nominal working
   group processes of the IETF to provide a well-known mechanism 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.  The protocol SHOULD provide
   features that at a minimum allow for the management of new object
   types without requiring revisions to the protocol itself.

   [2] The requirements described in this document are not intended to
   limit the set of objects that might be managed by the protocol.  The
   protocol MUST include features that allow extension to object types
   that are not described in this document.

   [3] The protocol MUST provide an optional field within all commands
   whose format and use will be controlled by individual registry
   policy.

7.6 Security

   [1] Transactional privacy and integrity services MUST be available at
   some protocol layer.

   [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.  A generic protocol MUST depend on other-layered
   protocols to provide security services that are not provided in the
   generic protocol itself.  A generic protocol that relies on security

Hollenbeck                   Informational                     [Page 16]
RFC 3375                Generic RRP Requirements          September 2002

   services from other-layered protocols MUST specify the protocol
   layers needed to provide security services.

8. Other Requirements

   Certain aspects of anticipated operational environments have to be
   considered when designing a generic registry-registrar protocol.
   Areas of concern include database operations, operations, site
   adaptation, and data collection.

8.1 Database Requirements

   [1] The protocol MUST NOT have any database dependencies.  However,
   efficient use of database operations and resources has to be
   considered as part of the protocol design effort.  The protocol
   SHOULD provide atomic features that can be efficiently implemented to
   minimize database load.

8.2 Operational 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 name space can be provided.

   [2] The protocol MUST provide services that allow clients and servers
   to maintain a consistent understanding of the current date and time
   to effectively manage objects with temporal properties.

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.  The protocol MUST be
   flexible enough to operate in diverse registry-registrar
   environments.

8.4 Data Collection Requirements

   [1] Some of the data exchanged between a registrar and registry might
   be considered personal, private, or otherwise sensitive.  Disclosure
   of such information might be restricted by laws and/or business
   practices.  The protocol MUST provide services to identify data
   collection policies.

Hollenbeck                   Informational                     [Page 17]
RFC 3375                Generic RRP Requirements          September 2002

   [2] Some of the social information exchanged between a registrar and
   registry might be required to create, manage, or operate Internet or
   DNS infrastructure facilities, such as zone files.  Such information
   is subject to public disclosure per relevant IETF standards.

9. Internationalization Requirements

   [1] [RFC1035] describes Internet host and domain names using
   characters traditionally found in a subset of the 7-bit US-ASCII
   character set.  More recent standards, such as [RFC2130] and
   [RFC2277], describe the need to develop protocols for an
   international Internet.  These and other standards MUST be considered
   during the protocol design process to ensure world-wide usability of
   a generic registry registrar protocol.

   [2] The protocol MUST allow exchange of data in formats consistent
   with current international agreements for the representation of such
   objects.  In particular, this means that addresses MUST include
   country, that telephone numbers MUST start with the international
   prefix "+", and that appropriate thought be given to the usability of
   information in both local and international contexts.  This means
   that some elements (like names and addresses) might need to be
   represented multiple times, or formatted for different contexts (for
   instance English/French in Canada, or Latin/ideographic in Japan).

   [3] All date and time values specified in a generic registry-
   registrar protocol MUST be expressed in Universal Coordinated Time.
   Dates and times MUST include information to represent a four-digit
   calendar year, a calendar month, a calendar day, hours, minutes,
   seconds, fractional seconds, and the time zone for Universal
   Coordinated Time.  Calendars apart from the Gregorian calendar MUST
   NOT be used

10. IANA Considerations

   This document does not require any action on the part of IANA.
   Protocol specifications that require IANA action MUST follow the
   guidelines described in [RFC2434].

11. Security Considerations

   Security services, including confidentiality, authentication, access
   control, integrity, and non-repudiation SHOULD be applied to protect
   interactions between registries and registrars as appropriate.
   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

Hollenbeck                   Informational                     [Page 18]
RFC 3375                Generic RRP Requirements          September 2002

   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.

12. Acknowledgements

   This document was originally written as an individual submission
   Internet-Draft.  The provreg working group later adopted it as a
   working group document and provided many invaluable comments and
   suggested improvements.  The author wishes to acknowledge the efforts
   of WG chairs Edward Lewis and Jaap Akkerhuis for their process and
   editorial contributions.

   Specific comments that helped guide development of this document were
   provided by Harald Tveit Alvestrand, Christopher Ambler, Karl
   Auerbach, Jorg Bauer, George Belotsky, Eric Brunner-Williams, Jordyn
   Buchanan, Randy Bush, Bruce Campbell, Dan Cohen, Andre Cormier, Kent
   Crispin, Dave Crocker, Ayesha Damaraju, Lucio De Re, Mats Dufberg,
   Peter Eisenhauer, Sheer El-Showk, Urs Eppenberger, Patrik Faltstrom,
   Paul George, Patrick Greenwell, Jarle Greipsland, Olivier Guillard,
   Alf Hansen, Paul Hoffman, Paul Kane, Shane Kerr, Elmar Knipp, Mike
   Lampson, Matt Larson, Ping Lu, Klaus Malorny, Bill Manning, Michael
   Mealling, Patrick Mevzek, Peter Mott, Catherine Murphy, Martin
   Oldfield, Geva Patz, Elisabeth Porteneuve, Ross Wm. Rader, Budi
   Rahardjo, Annie Renard, Scott Rose, Takeshi Saigoh, Marcos Sanz,
   Marcel Schneider, J.  William Semich, James Seng, Richard Shockey,
   Brian Spolarich, William Tan, Stig Venaas, Herbert Vitzthum, and Rick
   Wesson.

13. References

Normative References:

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

Informative References:

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specification", STD 13, RFC 1035, November 1987.

Hollenbeck                   Informational                     [Page 19]
RFC 3375                Generic RRP Requirements          September 2002

   [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
             Atkinson, R., Cripsin, M. and P. Svanberg, "The Report of
             the IAB Character Set Workshop", RFC 2130, April 1997.

   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
             Languages", BCP 18, RFC 2277, January 1998.

14. Editor's Address

   Scott Hollenbeck
   VeriSign Global Registry Services
   21345 Ridgetop Circle
   Dulles, VA 20166-6503
   USA

   EMail: shollenbeck@verisign.com

Hollenbeck                   Informational                     [Page 20]
RFC 3375                Generic RRP Requirements          September 2002

15.  Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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                   Informational                     [Page 21]