Internet DRAFT - draft-hollenbeck-grrp-reqs
draft-hollenbeck-grrp-reqs
Internet Engineering Task Force S. Hollenbeck
Internet-Draft VeriSign, Inc.
January 19, 2001 Expires: July 19, 2001
Generic Registry-Registrar Protocol Requirements
<draft-hollenbeck-grrp-reqs-06.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared 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 July 19, 2001 [Page 1]
Internet-Draft Generic RRP Requirements January 19, 2001
Table of Contents
1. Introduction ................................................. 3
1.1 Definitions, Acronyms, and Abbreviations .................... 3
2. General Description .......................................... 5
2.1 System Perspective .......................................... 5
2.2 System Functions ............................................ 5
2.3 User Characteristics ........................................ 5
2.4 Assumptions ................................................. 6
3. Functional Requirements ...................................... 7
3.1 Session Management .......................................... 7
3.2 Identification and Authentication ........................... 7
3.3 Transaction Identification .................................. 7
3.4 Object Registration ......................................... 8
3.5 Object Association .......................................... 9
3.6 Object Update ............................................... 10
3.7 Object Transfer ............................................. 10
3.8 Object Renewal/Extension .................................... 11
3.9 Object Deletion ............................................. 11
3.10 Object Existence Query ..................................... 12
3.11 Object Information Query ................................... 12
3.12 Domain Status Indicators ................................... 13
3.13 Transaction Completion Status .............................. 14
4. External Interface Requirements .............................. 15
4.1 User Interfaces ............................................. 15
4.2 Hardware Interfaces ......................................... 15
4.3 Software Interfaces ......................................... 15
4.4 Communications Interfaces ................................... 15
5. Performance Requirements ..................................... 16
6. Design Constraints ........................................... 16
6.1 Standards Compliance ........................................ 16
6.2 Hardware Limitations ........................................ 16
7. Service Attributes ........................................... 17
7.1 Reliability ................................................. 17
7.2 Availability ................................................ 17
7.3 Scalability ................................................. 17
7.4 Maintainability ............................................. 17
7.5 Extensibility ............................................... 18
8. Other Requirements ........................................... 19
8.1 Database Requirements ....................................... 19
8.2 Operations Requirements ..................................... 19
8.3 Site Adaptation Requirements ................................ 19
9. Internationalization Considerations .......................... 20
10. IANA Considerations ......................................... 20
11. Security Considerations ..................................... 21
12. References .................................................. 22
13. Editor's Address ............................................ 22
14. Full Copyright Statement .................................... 22
Hollenbeck Expires July 19, 2001 [Page 2]
Internet-Draft Generic RRP Requirements January 19, 2001
1. Introduction
The advent of shared domain name registration systems illustrates the
utility of a common, generic protocol for registry-registrar
interaction. A standard generic protocol will allow registrars to
communicate with multiple registries through a common interface,
reducing operational complexity. This document describes high level
functional and interface requirements for a generic provisioning
protocol suitable for registry-registrar operations. Detailed
technical requirements are not addressed in this document.
This document is being discussed on the "ietf-provreg" mailing list.
To join the list, send a message to <majordomo@cafax.se> with the
words "subscribe ietf-provreg" in the body of the message. There is a
web site for the list archives at http://www.cafax.se/ietf-provreg.
1.1 Definitions, Acronyms, and Abbreviations
ccTLD: Country Code Top Level Domain. ".us" is an example of a ccTLD.
CORE: Council of Registrars
DNS: Domain Name System
Exclusive Registration System: A domain name registration system in
which registry services are limited to a single registrar. Exclusive
Registration Systems may be either loosely coupled (in which case the
separation between registry and registrar systems is readily evident),
or tightly coupled (in which case the separation between registry and
registrar systems is obscure).
gTLD: Generic Top Level Domain. ".com" is an example of a gTLD.
IANA: Internet Assigned Numbers Authority
IETF: Internet Engineering Task Force
IP Address: Either or both IPv4 or IPv6 address.
NSI: Network Solutions, Inc.
Object: A generic term used to describe entities that are created,
updated, deleted, and otherwise managed by a generic registry-
registrar protocol.
Registrant: An entity that registers domain names in a registry
through the services provided by a registrar. Registrants include
individuals, organizations, and corporations.
Hollenbeck Expires July 19, 2001 [Page 3]
Internet-Draft Generic RRP Requirements January 19, 2001
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. A registry is typically responsible for publication
and distribution of TLD zone files used by the Domain Name System.
Shared Registration System: A domain name registration system in which
registry services are shared among multiple independent registrars.
Shared Registration Systems require a loose coupling between
registrars and a registry.
Thick Registry: A registry in which all of the information associated
with registered entities, including both technical information
(information needed to produce zone files) and social information
(information needed to implement operational, business, or legal
practices), is stored within the registry repository.
Thin Registry: A registry in which some element of the social
information associated with registered entities is distributed between
a shared registry and the registrars served by the registry.
TLD: Top Level Domain. A generic term used to describe both gTLDs and
ccTLDs that exist under the top-level root of the domain name
hierarchy.
Hollenbeck Expires July 19, 2001 [Page 4]
Internet-Draft Generic RRP Requirements January 19, 2001
2. General Description
A basic understanding of domain name registration systems provides
focus for the enumeration of functional and interface requirements of
a protocol to serve those systems. This section provides a high-level
description of domain name registration systems to provide context for
the requirements identified later in this document.
2.1 System Perspective
A domain name registration system consists of a protocol and
associated software and hardware that permits registrars to provide
Internet domain name registration services within the TLDs
administered by a registry. A registration system may be shared among
multiple competing registrars, or it may be served by a single
registrar that is either tightly or loosely coupled with back-end
registry services. The system providing registration services for the
.com, .net, and .org gTLDs is an example of a shared registration
system serving multiple competing registrars. The systems providing
registration services for some ccTLDs and the .gov and .mil gTLDs are
examples of TLDs served by a single registrar.
2.2 System Functions
Registrars access a registry through a protocol to register objects
and perform object management functions. Required functions include
session management; object creation, update, renewal, and deletion;
object query; and object transfer.
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. Specific details describing
whois functions are not covered in this document.
2.3 User Characteristics
Protocol users fall into two broad categories: registrars who develop
or use protocol client implementations, and registries who develop or
Hollenbeck Expires July 19, 2001 [Page 5]
Internet-Draft Generic RRP Requirements January 19, 2001
use protocol server implementations. A protocol provides a loose
coupling between a registry and the registrars that access the
registry.
2.4 Assumptions
There is one and only one registry that is authoritative for a given
TLD.
A registry can be authoritative for more than one TLD.
Some registry operations MAY be billable. The impact of a billable
operation SHOULD be mitigated through the specification of non-
billable operations that allow a registrar to make informed decisions
before executing billable operations.
A registry MAY choose to implement a subset of the features provided
by a generic registry-registrar protocol. A thin registry, for
example, might not provide services to register contact information.
Specification of minimal implementation compliance requirements is
thus an exercise left for a formal protocol definition document that
addresses the requirements specified here.
A protocol that meets the requirements described here MAY be called
something other than "Generic Registry Registrar Protocol".
The requirements described in this document are not intended to limit
the set of objects that may be managed by a generic registry-registrar
protocol.
Hollenbeck Expires July 19, 2001 [Page 6]
Internet-Draft Generic RRP Requirements January 19, 2001
3. Functional Requirements
This section describes the complete, high-level requirements for a
generic registry-registrar protocol. Functional requirements define
the object registration and management services that must be provided
by a registration system provisioned through a generic registry-
registrar protocol.
3.1 Session Management
[1] The protocol MUST provide services to explicitly establish a
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 ensure transactional
integrity if a session is aborted prematurely.
3.2 Identification and Authentication
[1] The protocol MUST provide services to identify registrar clients
before granting access to other protocol services.
[2] The protocol MUST provide services to authenticate registrar
clients before granting access to other protocol services.
[3] The protocol or another layered protocol MUST provide services to
negotiate an identification and authentication mechanism acceptable to
both the server and the client.
3.3 Transaction Identification
[1] Registry operations that create, update, or delete objects MUST be
Hollenbeck Expires July 19, 2001 [Page 7]
Internet-Draft Generic RRP Requirements January 19, 2001
associated with a registry-unique identifier. The protocol MUST allow
each transaction to be identified in a permanent and globally unique
manner.
3.4 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,
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. 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] When a domain name has been successfully registered, the protocol
MAY return a definite expiration date and time derived from the
requested registration period and the date and time of initial
registration.
[4] A request to register an object MUST be associated with a
registry-unique transaction identifier.
[5] 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 version 4 (IPv4) or
version 6 (IPv6) address. A name server MAY be registered with
multiple IP addresses. An IP address MAY be shared among multiple
name servers using distinct server names. Name servers that exist in
TLDs other than those for which the registry is authoritative MUST be
registered without an IP address providing that the server TLD is
itself a valid TLD.
[6] The protocol MUST consider that the name server associated with a
domain might not be registered in the same domain or even in a TLD for
which the registry is authoritative. This means that IP addresses for
name servers whose parent domain exists in another TLD MUST be
registered only in the registry that is authoritative for the TLD of
the name server. Glue records (DNS "A" records) MUST NOT be created
for DNS NS records for which the registry is not authoritative.
Hollenbeck Expires July 19, 2001 [Page 8]
Internet-Draft Generic RRP Requirements January 19, 2001
[7] The protocol MUST provide services to register contact information
describing human and organizational entities. Contact registration
MUST NOT be limited to a specific period of time. Contact
registration 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,
e-mail address, and facsimile telephone number.
[8] Telephone numbers associated with a registered object MUST conform
to international standards for telephone number formatting.
[9] All registered objects MUST be referenced using identifiers that
are unique to the registry. For example, a domain name MUST be unique
within a registry. A name server name MUST be unique within a
registry. A contact identifier MUST be unique within a registry.
[10] All registrars MUST be authorized to register objects in the
registry. Name server registration MUST be limited to the registrar
of the name server's parent domain. Unauthorized attempts to register
a name server in a parent domain administered by another registrar
MUST be explicitly rejected.
3.5 Object Association
[1] The protocol MUST provide services to associate name servers with
domain names. A domain name MAY have multiple authoritative name
servers. A name server MAY be authoritative for multiple domain
names.
[2] The protocol MUST provide services to associate IP addresses with
name servers. A name server MAY have multiple IP addresses. An IP
address MAY be associated with multiple name servers.
[3] The protocol MUST provide services to associate contacts with
domain names. Associated contacts name MUST be identified by type.
Contact types that MAY be associated with a domain name include
"registrant", "technical", "administrative", and "billing". A
registry MAY support a subset of these contact types.
[4] Some managed objects represent shared resources that MAY be
referenced by multiple registrars. Requests to an associate a known
shared resource object with another registered object MUST NOT be
limited to the registrar that sponsors the registered objects. For
example, server ns1.example.com (managed by registrar X) MAY be
associated with both domain example.com (managed by registrar X) and
domain test.com (managed by registrar Y). Registrar X maintains
administrative control over domain example.com and server
ns1.example.com, and registrar Y maintains administrative control over
Hollenbeck Expires July 19, 2001 [Page 9]
Internet-Draft Generic RRP Requirements January 19, 2001
domain test.com. Registrar Y does not have administrative control
over server ns1.example.com.
3.6 Object Update
[1] The protocol MUST provide services to update information
associated with registered Internet domain names. Domain name update
services MUST allow changes to status, associated name servers, and
associated contacts.
[2] The protocol MUST provide services to update information
associated with registered name servers. Name server update services
MUST allow change to IP addresses and server name.
[3] The protocol MUST provide services to update information
associated with registered contacts. Contact update services MUST
allow change to all attributes associated with a contact.
[4] The protocol MUST provide services to confirm registrar
authorization to update an object.
[5] Requests to update a registered object MUST be limited to the
registrar that currently sponsors the registered object. Unauthorized
attempts to update a registered object MUST be explicitly rejected.
3.7 Object Transfer
[1] The protocol MUST provide services to transfer domain names among
authorized registrars. Name servers registered in a domain being
transferred MUST be transferred along with the domain itself. For
example, name servers "ns1.example.com" and "ns2.example.com" MUST be
implicitly transferred when domain "example.com" is transferred.
[2] The protocol MUST provide services to transfer contacts among
authorized registrars.
[3] Transfer requests MUST be initiated by the registrar who wishes to
become the new administrator of an object.
[4] The protocol MUST provide services to confirm registrar
authorization to transfer an object.
[5] 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
Hollenbeck Expires July 19, 2001 [Page 10]
Internet-Draft Generic RRP Requirements January 19, 2001
MUST be explicitly rejected.
[6] 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.
[7] 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.
[8] Object transfer requests MUST NOT be acted upon without giving the
losing registrar an opportunity to respond to the request.
[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.
[10] Requests to initiate the transfer of a registered object MUST be
available to all authorized registrars.
3.8 Object Renewal/Extension
[1] The protocol MUST provide services to renew or extend the 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] The protocol MUST provide services to confirm registrar
authorization to renew or extend the validity period of an object.
3.9 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 contact from the
Hollenbeck Expires July 19, 2001 [Page 11]
Internet-Draft Generic RRP Requirements January 19, 2001
registry.
[4] The protocol MUST provide services to confirm registrar
authorization to remove an object.
[5] 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.10 Object Existence Query
This section describes requirements for a light weight 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.
[2] The protocol MUST provide services to determine if a name server
exists in the registry. Name servers MUST be searchable by fully
qualified name.
[3] The protocol MUST provide services to determine if a contact
exists in the registry. Contacts MUST be searchable by registry
identifier.
[4] A query to determine if an object exists in the registry MUST
return only a positive or negative response so that server software
that responds to this query can be optimized for speed.
[5] Requests to determine the existence of a registered object MUST be
available to all authorized registrars.
3.11 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 successful transfer request or completed transfer (if any), the
current status of the domain, the most recent authorization
Hollenbeck Expires July 19, 2001 [Page 12]
Internet-Draft Generic RRP Requirements January 19, 2001
identifier, contact identifiers associated with the domain, and the
child name servers registered in the domain. The most recent
authorization identifier MUST be returned only to the current
sponsoring registrar.
[2] The protocol MUST provide services to retrieve information
describing a name server from the registry. Returned information MUST
include the identifier of the current sponsoring registrar, the
identifier of the registrar that originally registered the name
server, the creation date and time, the date and time of the last
successful update (if any), the identifier of the registrar that
performed the last update, the date and time of last successful
transfer request or completed transfer (if any), the IP addresses
currently associated with the name server, and the most recent
authorization identifier. The most recent authorization identifier
MUST be returned only to the current sponsoring registrar.
[3] The protocol MUST provide services to retrieve information
describing a contact from the registry. Contacts MUST be referenced
by registry identifier. Returned information MUST include the
identification attributes of the contact (which MAY include name,
address, telephone numbers, and e-mail address), the identifier of the
registrar that originally registered the contact, the creation date
and time, the date and time of the last successful update (if any),
the identifier of the registrar that performed the last update, the
date and time of last successful transfer request or completed
transfer (if any), and the most recent authorization identifier. The
most recent authorization identifier MUST be returned only to the
current sponsoring registrar.
[4] Requests to retrieve information describing a registered object
MAY be limited to the registrar that currently sponsors the registered
object. Unauthorized attempts to retrieve information describing a
registered object MUST be explicitly rejected.
3.12 Domain Status Indicators
[1] The protocol MUST provide status indicators that identify the
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 nominal active state (the domain can be
modified and is published in a zone), an inactive state (the domain
can be modified but is not published in a zone because it has no
authoritative name servers), a hold state (the domain may not be
modified and is not published in a zone), a lock state (the domain may
not be modified and is published in a zone), a pending transfer state,
and a pending removal state.
Hollenbeck Expires July 19, 2001 [Page 13]
Internet-Draft Generic RRP Requirements January 19, 2001
[2] If provided, 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.13 Transaction Completion Status
[1] The protocol MUST provide services that unambiguously note the
success or failure of every transaction. Individual success and error
conditions MUST be noted distinctly.
Hollenbeck Expires July 19, 2001 [Page 14]
Internet-Draft Generic RRP Requirements January 19, 2001
4. External Interface Requirements
External interfaces define the interaction points between a system and
entities that communicate with the system. Specific areas of interest
include user interfaces, hardware interfaces, software interfaces, and
communications interfaces.
4.1 User Interfaces
[1] A generic registry-registrar protocol MUST NOT define any features
that introduce user interface limitations.
4.2 Hardware Interfaces
[1] A generic registry-registrar protocol MUST NOT define any features
that introduce hardware interface limitations.
4.3 Software Interfaces
[1] A generic registry-registrar protocol MUST NOT define any features
that introduce software interface limitations.
4.4 Communications Interfaces
[1] Registries, registrars, and registrants interact using a wide
spectrum of communications interfaces built upon multiple protocols,
including transport layer protocols such as TCP and application layer
protocols such as SMTP. A generic registry-registrar protocol SHOULD
be serviceable over multiple standard communications protocols.
Hollenbeck Expires July 19, 2001 [Page 15]
Internet-Draft Generic RRP Requirements January 19, 2001
5. Performance Requirements
[1] Run-time performance is an absolutely critical aspect of protocol
usability. While performance is very heavily dependent on the hardware
and software architecture that implements a protocol, protocol
features can have a direct impact on the ability of the underlying
architecture to provide optimal performance. A generic registry-
registrar protocol MUST be usable in both high volume and low volume
operating environments.
6. Design Constraints
Protocol designers need to be aware of issues beyond functional and
interface requirements when balancing protocol design decisions. This
section describes additional factors that may have an impact on
protocol design, including standards compliance and hardware
limitations.
6.1 Standards Compliance
[1] A generic registry-registrar protocol MUST conform to current IETF
standards. Standards for domain and host name syntax, IP address
syntax, security, and transport are particularly relevant. Emerging
standards for the Domain Name System MUST be considered as they
approach maturity.
6.2 Hardware Limitations
[1] A generic registry-registrar protocol MUST NOT define any features
that preclude hardware independence.
Hollenbeck Expires July 19, 2001 [Page 16]
Internet-Draft Generic RRP Requirements January 19, 2001
7. Service Attributes
Elements of service beyond functional and interface requirements are
essential factors to consider as part of a protocol design effort.
This section describes several important service elements that MUST be
addressed by protocol designers, including reliability, availability,
scalability, and maintainability.
7.1 Reliability
[1] Reliability is a measure of the extent to which a protocol
provides a consistent, dependable level of service. Reliability is an
important attribute for a domain name management protocol. An
unreliable protocol increases the risk of data exchange errors, which
at one extreme may have a direct impact on protocol usability and at
the other extreme may introduce discontinuity between registry and
registrar data stores. A generic registry-registrar protocol MUST
include features that maximize reliability at the application protocol
layer. Services provided by underlying transport, session, and
presentation protocols SHOULD also be considered when addressing
application protocol reliability.
[2] Default actions for when a request or event times out MUST be well
defined, and the protocol MUST consider the risks and consequences of
losing such events.
7.2 Availability
[1] Availability is a measure of the extent to which the services
provided by a protocol are accessible for an intended use.
Availability of an application layer protocol is primarily dependent
on the software and hardware systems that implement the protocol.
That is, the systems that implement the protocol MUST themselves be
inherently available. As such, a generic registry-registrar protocol
MUST NOT include any features that impinge on the underlying
reliability of the software and hardware systems needed to implement
the protocol.
7.3 Scalability
[1] Scalability is a measure of the extent to which a protocol can
accommodate use growth while preserving acceptable operational
characteristics. A generic registry-registrar protocol MUST be
capable of operating at an acceptable level as the load on registry
and registrar systems increases.
7.4 Maintainability
Hollenbeck Expires July 19, 2001 [Page 17]
Internet-Draft Generic RRP Requirements January 19, 2001
[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 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. 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.
[2] The requirements described in this document are not intended to
limit the set of objects that may be managed by a generic registry-
registrar protocol. A generic 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.
Hollenbeck Expires July 19, 2001 [Page 18]
Internet-Draft Generic RRP Requirements January 19, 2001
8. Other Requirements
Certain aspects of anticipated operational environments SHOULD be
considered when designing a generic registry-registrar protocol.
Areas of concern include database operations, daily operations, site
adaptation, and date formatting.
8.1 Database Requirements
[1] A generic registry-registrar protocol MUST NOT have any database
dependencies. However, efficient use of database operations and
resources MUST be considered as part of the protocol design effort.
The protocol SHOULD provide atomic features that can be efficiently
implemented to minimize database load for anticipated high volume
transactions.
8.2 Operations Requirements
[1] Registry-registrar interactions at the protocol level SHOULD
operate without human intervention. However, intermediate services
that preserve the integrity of the protocol MAY be provided. For
example, an intermediate service that determines if a registrant is
authorized to register a name in a TLD MAY be provided.
8.3 Site Adaptation Requirements
[1] Registries and registrars have varying business and operational
requirements. Several factors, including governance standards, local
laws, customs, and business practices all play roles in determining
how registries and registrars are operated. A generic registry-
registrar protocol MUST be flexible enough to operate in diverse
registry-registrar environments.
Hollenbeck Expires July 19, 2001 [Page 19]
Internet-Draft Generic RRP Requirements January 19, 2001
9. Internationalization Considerations
[1] Current Internet standards restrict the encoding of Internet host
and domain names to a subset of the 7-bit US-ASCII character set.
Registries and registrars now serve customers whose native languages
require encodings other than US-ASCII, which automatically disallows
use of those languages when registering host and domain names.
Support for internationalized host and domain names will greatly
increase world-wide usability of a generic registry registrar
protocol, so standards for exchanging internationalized information
MUST be considered during the protocol design process.
[2] The protocol MUST allow exchange of meta-data associated with
objects in formats consistent with current internationalized character
encoding and language representation standards.
[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.
10. IANA Considerations
IANA has assigned several TCP and UDP ports for use within shared
registration systems. The assignments can be identified in two broad
categories: those assigned for use with the CORE Shared Registry
System Protocol (SRSP) and those assigned for use with the NSI
Registry Registrar Protocol (RRP).
The CORE SRSP assignments are as follows:
srssend 362/tcp SRS Send
srssend 362/udp SRS Send
srsp 2682/tcp SRSP
srsp 2682/udp SRSP
The NSI RRP assignments are as follows:
rrp 648/tcp Registry Registrar Protocol (RRP)
rrp 648/udp Registry Registrar Protocol (RRP)
These assignments SHOULD be preserved as long as the corresponding
systems are operational. Additional IANA services MAY be required to
support testing and deployment of protocol implementations.
Hollenbeck Expires July 19, 2001 [Page 20]
Internet-Draft Generic RRP Requirements January 19, 2001
11. Security Considerations
Several security services, including confidentiality, authentication,
access control, integrity, and non-repudiation SHOULD be applied to
protect interactions between registries and registrars.
Confidentiality services protect sensitive exchanged information from
inadvertent disclosure. Authentication services confirm the claimed
identity of registries and registrars before engaging in online
transactions. Access control services control access to data and
services based on identity. Integrity services guarantee that
exchanged data has not been altered between the registry and the
registrar. Non-repudiation services provide assurance that the sender
of a transaction can not deny being the source of the transaction, and
that the recipient cannot deny being the receiver of the transaction.
[1] Security services MUST be provided to protect against the
following types of attack: eavesdropping, replay, message insertion,
deletion, modification, and man-in-the-middle.
[2] This document describes requirements for basic user identification
and authentication services. A generic protocol MAY include
additional security services to protect against the attacks described
here, or a generic protocol MUST depend on lower-layer protocols to
provide additional security services.
[3] Some of the data exchanged between a registrar and registry can be
considered personal, private, or otherwise sensitive. Disclosure of
such information MAY be restricted by laws and/or business practices.
A generic protocol MUST provide services to identify information whose
disclosure is not strictly required for technical reasons.
Hollenbeck Expires July 19, 2001 [Page 21]
Internet-Draft Generic RRP Requirements January 19, 2001
12. References
[RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13. Editor's Address
Scott Hollenbeck
VeriSign Global Registry Services
21345 Ridgetop Circle
Dulles, VA 20166-6503
USA
shollenbeck@verisign.com
14. Full Copyright Statement
Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hollenbeck Expires July 19, 2001 [Page 22]
