summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3375.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3375.txt')
-rw-r--r--doc/rfc/rfc3375.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc3375.txt b/doc/rfc/rfc3375.txt
new file mode 100644
index 0000000..babf1d3
--- /dev/null
+++ b/doc/rfc/rfc3375.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+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]
+