Appendix D15.2.2_A, RRP Protocol Draft

Internet Engineering Task Force S. Hollenbeck

Internet-Draft VeriSign, Inc.

September 21, 2000 Expires: March 21, 2001

Generic Registry-Registrar Protocol Requirements

Status of this Memo

This document is an Internet-Draft and is in full conformance with all

provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task

Force (IETF), its areas, and its working groups. Note that other

groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at

http://www.ietf.org/shadow.html.

Abstract

This document describes high-level functional and interface

requirements for a client-server protocol for the registration and

management of Internet domain names in shared Top Level Domain (TLD)

registries. Specific technical requirements detailed for protocol

design are not presented here. Instead, this document focuses on the

basic functions and interfaces required of a protocol to support

multiple registry and registrar operational models.

Conventions Used In This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [RFC2119].

Hollenbeck Expires March 21, 2001 [Page 1]

Internet-Draft Generic RRP Requirements September 21, 2000

Table of Contents

1. Introduction ................................................. 4

1.1 Definitions, Acronyms, and Abbreviations .................... 4

2. General Description .......................................... 6

2.1 System Perspective .......................................... 6

2.2 System Functions ............................................ 6

2.3 User Characteristics ........................................ 6

2.4 Assumptions ................................................. 7

3. Functional Requirements ...................................... 8

3.1 Session Management .......................................... 8

3.2 Identification and Authentication ........................... 8

3.3 Transaction Identification .................................. 8

3.4 Object Registration ......................................... 9

3.5 Object Association .......................................... 10

3.6 Object Update ............................................... 10

3.7 Object Transfer ............................................. 11

3.8 Object Renewal/Extension .................................... 12

3.9 Object Existence Query ...................................... 13

3.10 Object Deletion ............................................ 13

3.11 Object Information Query ................................... 14

3.12 Domain Status Indicators ................................... 14

3.13 Transaction Completion Status .............................. 15

4. External Interface Requirements .............................. 16

4.1 User Interfaces ............................................. 16

4.2 Hardware Interfaces ......................................... 16

4.3 Software Interfaces ......................................... 16

4.4 Communications Interfaces ................................... 16

5. Performance Requirements ..................................... 17

6. Design Constraints ........................................... 17

6.1 Standards Compliance ........................................ 17

6.2 Hardware Limitations ........................................ 17

7. Service Attributes ........................................... 18

7.1 Reliability ................................................. 18

7.2 Availability ................................................ 18

7.3 Scalability ................................................. 18

7.4 Maintainability ............................................. 18

7.5 Extensibility ............................................... 19

8. Other Requirements ........................................... 20

8.1 Database Requirements ....................................... 20

8.2 Operations Requirements ..................................... 20

8.3 Site Adaptation Requirements ................................ 20

8.4 Date Format Requirements .................................... 20

9. Internationalization Considerations .......................... 21

10. IANA Considerations ......................................... 21

11. Security Considerations ..................................... 22

12. References .................................................. 23

13. Author's Address ............................................ 23

Hollenbeck Expires March 21, 2001 [Page 2]

Internet-Draft Generic RRP Requirements September 21, 2000

14. Full Copyright Statement .................................... 23

Hollenbeck Expires March 21, 2001 [Page 3]

Internet-Draft Generic RRP Requirements September 21, 2000

1. Introduction

The advent of shared domain name registration systems illustrates the

utility of a common, generic protocol for registry-registrar

interaction. A standard generic protocol will allow registrars to

communicate with multiple registries through a common interface,

reducing operational complexity. This document describes high level

functional and interface requirements for a generic provisioning

protocol suitable for registry-registrar operations. Detailed

technical requirements are not addressed in this document.

This document is being discussed on the "rrp" mailing list. To join

the list, send a message to with the words

"subscribe rrp" in the body of the message. There is a web site for

the list archives at .

1.1 Definitions, Acronyms, and Abbreviations

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

CORE: Council of Registrars

Exclusive Registration System: A domain name registration system in

which registry services are limited to a single registrar. Exclusive

Registration Systems may be either loosely coupled (in which case the

separation between registry and registrar systems is readily evident),

or tightly coupled (in which case the separation between registry and

registrar systems is obscure).

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

IANA: Internet Assigned Numbers Authority

IETF: Internet Engineering Task Force

IP Address: Either or both IPv4 or IPv6 address.

NSI: Network Solutions, Inc.

Object: A generic term used to describe entities that are created,

updated, deleted, and otherwise managed by a generic registry-

registrar protocol.

Registrant: An entity that registers domain names in a registry

through the services provided by a registrar. Registrants include

individuals, organizations, and corporations.

Registrar: An entity that provides front-end domain name registration

Hollenbeck Expires March 21, 2001 [Page 4]

Internet-Draft Generic RRP Requirements September 21, 2000

services to registrants, providing a public interface to registry

services.

Registry: An entity that provides back-end domain name registration

services to registrars, managing a central repository of information

for a given TLD. A registry is typically responsible for publication

and distribution of TLD zone files used by the Domain Name System.

Shared Registration System: A domain name registration system in which

registry services are shared among multiple independent registrars.

Shared Registration Systems require a loose coupling between

registrars and a registry.

Thick Registry: A registry in which all of the information associated

with registered entities, including both technical information

(information needed to produce zone files) and social information

(information needed to implement operational, business, or legal

practices), is stored within the registry repository.

Thin Registry: A registry in which some element of the social

information associated with registered entities is distributed between

a shared registry and the registrars served by the registry.

TLD: Top Level Domain. A generic term used to describe both gTLDs and

ccTLDs that exist under the top-level root of the domain name

hierarchy.

Hollenbeck Expires March 21, 2001 [Page 5]

Internet-Draft Generic RRP Requirements September 21, 2000

2. General Description

A basic understanding of domain name registration systems provides

focus for the enumeration of functional and interface requirements of

a protocol to serve those systems. This section provides a high-level

description of domain name registration systems to provide context for

the requirements identified later in this document.

2.1 System Perspective

A domain name registration system consists of a protocol and

associated software and hardware that permits registrars to provide

Internet domain name registration services within the TLDs

administered by a registry. A registration system may be shared among

multiple competing registrars, or it may be served by a single

registrar that is either tightly or loosely coupled with back-end

registry services. The system providing registration services for the

.com, .net, and .org gTLDs is an example of a shared registration

system serving multiple competing registrars. The systems providing

registration services for many ccTLDs and the .gov and .mil gTLDs are

examples of TLDs served by a single registrar.

2.2 System Functions

Registrars access a registry through a protocol to register objects

and perform object management functions. Required functions include

session management; object creation, update, and deletion; and object

query.

The registry generates DNS zone files for the TLDs it serves. These

zone files are created and distributed to a series of name servers

that provide the foundation for the domain name system.

Registries also provide a whois search capability that provides basic

query services for the objects managed by the registry. Registry

whois services may be centralized or distributed. A centralized

registry whois service provides information access to all registered

objects without the need for referral to other whois services. A

distributed registry whois service provides basic object information

at the registry level, and requires referral to other registry or

registrar whois services to obtain information for objects not

maintained with the queried registry.

2.3 User Characteristics

Protocol users fall into two broad categories: registrars who develop

or use protocol client implementations, and registries who develop or

use protocol server implementations. A protocol provides a loose

Hollenbeck Expires March 21, 2001 [Page 6]

Internet-Draft Generic RRP Requirements September 21, 2000

coupling between a registry and the registrars that access the

registry.

2.4 Assumptions

There is one and only one registry that is authoritative for a given

TLD.

A registry can be authoritative for more than one TLD.

Some registry operations MAY be billable. The impact of a billable

operation SHOULD be mitigated through the specification of non-

billable operations that allow a registrar to make informed decisions

before executing billable operations.

A registry MAY choose to implement a subset of the features provided

by a generic registry-registrar protocol. A thin registry, for

example, might not provide services to register contact information.

Specification of minimal implementation compliance requirements is

thus an exercise left for a formal protocol definition document that

addresses the requirements specified here.

A protocol that meets the requirements described here MAY be called

something other than "Generic Registry Registrar Protocol".

Hollenbeck Expires March 21, 2001 [Page 7]

Internet-Draft Generic RRP Requirements September 21, 2000

3. Functional Requirements

This section describes the complete, high-level requirements for a

generic registry-registrar protocol. Functional requirements define

the object registration and management services that must be provided

by a registration system provisioned through a generic registry-

registrar protocol.

3.1 Session Management

[1] The protocol MUST provide services to explicitly establish a

session with a registry server.

[2] In a connection-oriented environment, a server MUST respond to

connection attempts with a banner that identifies the server and the

default server protocol version.

[3] The protocol MUST provide services that allow a client to request

use of a specific protocol version as part of negotiating a session.

[4] The protocol MUST provide services that allow a server to decline

use of a specific protocol version as part of negotiating a session.

[5] A session MUST NOT be established if the client and server are

unable to reach agreement on the protocol version to be used for the

requested session.

[6] The protocol MUST provide services to explicitly end an

established session.

3.2 Identification and Authentication

[1] The protocol MUST provide services to identify registrar clients

before granting access to other protocol services.

[2] The protocol MUST provide services to authenticate registrar

clients before granting access to other protocol services.

3.3 Transaction Identification

[1] Registry operations that create, update, or delete objects MUST be

associated with a registry-unique transaction identifier. The

identifier SHOULD be created using the current date and a combination

of identification information assigned by and unique to the registry

(such as a registrar identifier) and information assigned by and

unique to the registrar requesting the operation (such as a

monotonically increasing transaction number).

Hollenbeck Expires March 21, 2001 [Page 8]

Internet-Draft Generic RRP Requirements September 21, 2000

[2] A generic registry-registrar protocol MUST provide features that

allow a registrar to provide a transaction identifier when performing

a create, update, or delete operation. The registry MUST associate

the identifier with the requested operation, and MUST return the

identifier to the registrar upon completion of the operation.

3.4 Object Registration

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

names. The registration period for domain names MUST be measured in

years, with a minimum period of one year and a maximum period defined

by registry policy.

[2] When a domain name has been successfully registered, the protocol

MUST return a definite expiration date and time derived from the

requested registration period and the date and time of initial

registration.

[3] A request to register an object MUST include a transaction

identifier. The transaction identifier MUST be returned to the

registrant by the registrar to facilitate authorization of future

transfer requests.

[4] The protocol MUST provide services to register name servers. Name

server registration MUST NOT be limited to a specific period of time.

Name servers registered within the registry's authoritative TLDs MUST

be registered with a valid Internet Protocol (IP) address. A name

server MAY be registered with multiple IP addresses. An IP address

MAY be shared among multiple name servers using distinct server names.

Name servers that exist in TLDs other than those for which the

registry is authoritative MUST be registered without an IP address

providing that the server TLD is itself a valid TLD.

[5] The protocol MUST consider that the name server associated with a

domain might not be registered in the same domain or even in a TLD for

which the registry is authoritative. This means that IP addresses for

name servers whose parent domain exists in another TLD MUST be

registered only in the registry that is authoritative for the TLD of

the name server. Glue records (DNS "A" records) MUST NOT be created

for DNS NS records for which the registry is not authoritative.

[6] The protocol MUST provide services to register contact information

describing human and organizational entities. Contact registration

MUST NOT be limited to a specific period of time. Contact

registration MUST include a name (individual name, organization name,

or both), address (including street address, city, state or province

(if applicable), postal code, and country), telephone number, and e-

mail address. A facsimile telephone number MAY be provided.

Hollenbeck Expires March 21, 2001 [Page 9]

Internet-Draft Generic RRP Requirements September 21, 2000

[7] Telephone numbers associated with a registered object MUST conform

to international standards for telephone number formatting.

[8] All registered objects MUST be referenced using identifiers that

are unique to the registry. For example, a domain name MUST be unique

within a registry. A name server name MUST be unique within a

registry. A contact identifier MUST be unique within a registry.

[9] A registry MUST provide services to support a configurable grace

period during which time a request to register a domain name or other

billable object can be undone without harm.

[10] All registrars MUST be authorized to register objects in the

registry. Name server registration MUST be limited to the registrar

of the name server's parent domain. Unauthorized attempts to register

a name server in a parent domain administered by another registrar

MUST be explicitly rejected.

3.5 Object Association

[1] The protocol MUST provide services to associate name servers with

domain names. A domain name MAY have multiple authoritative name

servers. A name server MAY be authoritative for multiple domain

names.

[2] The protocol MUST provide services to associate IP addresses with

name servers. A name server MAY have multiple IP addresses. An IP

address MAY be associated with multiple name servers.

[3] The protocol MUST provide services to associate contacts with

domain names. Associated contacts name MUST be identified by type.

Contact types that MAY be associated with a domain name include

"registrant", "technical", "administrative", and "billing". A

registry MAY support a subset of these contact types.

[4] Some managed objects represent shared resources that MAY be

referenced by multiple registrars. Requests to an associate a known

shared resource object with another registered object MUST NOT be

limited to the registrar that sponsors the registered objects. For

example, server ns1.example.com (managed by registrar X) MAY be

associated with both domain example.com (managed by registrar X) and

domain test.com (managed by registrar Y). Registrar X maintains

administrative control over domain example.com and server

ns1.example.com, and registrar Y maintains administrative control over

domain test.com. Registrar Y does not have administrative control

over server ns1.example.com.

3.6 Object Update

Hollenbeck Expires March 21, 2001 [Page 10]

Internet-Draft Generic RRP Requirements September 21, 2000

[1] The protocol MUST provide services to update information

associated with registered Internet domain names. Domain name update

services MUST allow changes to status, associated name servers, and

associated contacts.

[2] The protocol MUST provide services to update information

associated with registered name servers. Name server update services

MUST allow change to IP addresses and server name.

[3] The protocol MUST provide services to update information

associated with registered contacts. Contact update services MUST

allow change to all attributes associated with a contact.

[4] Requests to update registered objects MUST be limited to the

registrar that currently sponsors the registered object. Unauthorized

attempts to update a registered object MUST be explicitly rejected.

3.7 Object Transfer

[1] The protocol MUST provide services to transfer domain names among

authorized registrars. Name servers registered in a domain being

transferred MUST be transferred along with the domain itself. For

example, name servers "ns1.example.com" and "ns2.example.com" MUST be

implicitly transferred when domain "example.com" is transferred.

[2] The protocol MUST provide services to transfer contacts among

authorized registrars.

[3] Transfer requests MUST be initiated by the registrar who wishes to

become the new administrator of an object.

[4] A transfer request MUST include the transaction identifier

associated with either creation of the object or the most recently

completed transfer of the object.

[5] A transfer request MUST include a new transaction identifier. The

new transaction identifier MUST be returned to the registrant by the

registrar to facilitate authorization of future transfer requests.

[6] The protocol MUST provide services that allow the requesting

registrar to cancel a requested object transfer before the request has

been approved or rejected by the original sponsoring registrar.

Requests to cancel the transfer of registered objects MUST be limited

to the registrar that requested transfer of the registered object. A

request to cancel the transfer of an object MUST include the

transaction identifier associated with either creation of the object

or the most recently completed transfer of the object. Unauthorized

attempts to cancel the transfer of a registered object MUST be

Hollenbeck Expires March 21, 2001 [Page 11]

Internet-Draft Generic RRP Requirements September 21, 2000

explicitly rejected.

[7] The protocol MUST provide services that allow the original

sponsoring registrar to approve or reject a requested object transfer.

Requests to approve or reject the transfer of registered objects MUST

be limited to the registrar that currently sponsors the registered

object. A request to approve the transfer of an object MUST include

the transaction identifier associated with either creation of the

object or the most recently completed transfer of the object.

Unauthorized attempts to approve or reject the transfer of a

registered object MUST be explicitly rejected.

[8] The protocol MUST provide services that allow both the original

sponsoring registrar and the potential new registrar to become aware

of active requested transfers and transfers completed within a

specific time period.

[9] Object transfer requests MUST NOT be acted upon without giving the

losing registrar an opportunity to respond to the request. A registry

MUST provide services to support a configurable period during which

time a request to transfer the registration of an object MAY be

approved, rejected, or cancelled.

[10] A registry MUST provide a default transfer action in case of

registrar inaction. If a registry-specified period of time elapses

without explicit approval, rejection, or cancellation, a registry MUST

perform the default transfer action on behalf of the requesting

registrar.

[11] Transfer of an object MAY extend the object's registration

period. If an object's registration period will be extended as the

result of a transfer, the new expiration date and time MUST be

returned after successful completion of a transfer request.

[12] Requests to initiate the transfer of a registered object MUST be

available to all authorized registrars.

3.8 Object Renewal/Extension

[1] The protocol MUST provide services to renew or extend the

registration of registered domain names. The renewal or extension

period MUST be measured in annual increments subject to minimum and

maximum registration periods supported by the registry. The new

expiration date and time MUST be returned after successful completion

of a renewal/extension request.

[2] A registry MUST provide services to support a configurable grace

period during which time a request to renew or extend the registration

Hollenbeck Expires March 21, 2001 [Page 12]

Internet-Draft Generic RRP Requirements September 21, 2000

of a domain name can be undone without harm.

[3] Requests to renew or extend the registration of registered objects

MUST be limited to the registrar that currently sponsors the

registered objects. Unauthorized attempts to renew or extend the

registration of registered objects MUST be explicitly rejected.

3.9 Object Existence Query

[1] The protocol MUST provide services to determine if a domain name

exists in the registry. Domain names MUST be searchable by fully

qualified name.

[2] The protocol MUST provide services to determine if a name server

exists in the registry. Name servers MUST be searchable by fully

qualified name.

[3] The protocol MUST provide services to determine if a contact

exists in the registry. Contacts MUST be searchable by registry

identifier.

[4] A query to determine if an object exists in the registry MUST

return only a positive or negative response so that server software

that responds to this query can be optimized for speed.

[5] Requests to determine the existence of a registered object MUST be

available to all authorized registrars.

3.10 Object Deletion

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

the registry. Deleting a domain name MUST also delete all child name

servers. A domain name MUST NOT be deleted if child name servers are

being used to host other domain names.

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

the registry. Name servers MUST be referenced by fully-qualified

name. A name server MUST NOT be deleted if it is being used to host a

domain name.

[3] The protocol MUST provide services to remove a contact from the

registry. Contacts MUST be referenced by registry identifier. A

contact MUST NOT be deleted if it is associated with a domain.

[4] Requests to delete a registered object MUST be limited to the

registrar that currently sponsors the registered object. Unauthorized

attempts to delete a registered object MUST be explicitly rejected.

Hollenbeck Expires March 21, 2001 [Page 13]

Internet-Draft Generic RRP Requirements September 21, 2000

3.11 Object Information Query

[1] The protocol MUST provide services to retrieve information

describing a domain name from the registry. Returned information MUST

include the identifier of the current sponsoring registrar, the

identifier of the registrar that originally registered the domain, the

creation date and time, the expiration date and time, the date and

time of the last successful update (if any), the identifier of the

registrar that performed the last update, the date and time of last

successful transfer request or completed transfer (if any), the

current status of the domain, the most recent creation or transfer

transaction identifier, and the child name servers registered in the

domain. The most recent creation or transfer transaction identifier

MUST be returned only to the current sponsoring registrar.

[2] The protocol MUST provide services to retrieve information

describing a name server from the registry. Returned information MUST

include the identifier of the current sponsoring registrar, the

identifier of the registrar that originally registered the name

server, the creation date and time, the date and time of the last

successful update (if any), the identifier of the registrar that

performed the last update, the date and time of last successful

transfer request or completed transfer (if any), the IP addresses

currently associated with the name server, and the most recent

creation or transfer transaction identifier. The most recent creation

or transfer transaction identifier MUST be returned only to the

current sponsoring registrar.

[3] The protocol MUST provide services to retrieve information

describing a contact from the registry. Contacts MUST be referenced

by registry identifier. Returned information MUST include the

identification attributes of the contact (name, address, telephone

numbers, and e-mail address), the identifier of the registrar that

originally registered the contact, the creation date and time, the

date and time of the last successful update (if any), the identifier

of the registrar that performed the last update, the date and time of

last successful transfer request or completed transfer (if any), and

the most recent creation or transfer transaction identifier. The most

recent creation or transfer transaction identifier MUST be returned

only to the current sponsoring registrar.

[4] Requests to retrieve information describing a registered object

MAY be limited to the registrar that currently sponsors the registered

object. Unauthorized attempts to retrieve information describing a

registered object MUST be explicitly rejected.

3.12 Domain Status Indicators

Hollenbeck Expires March 21, 2001 [Page 14]

Internet-Draft Generic RRP Requirements September 21, 2000

[1] The protocol MUST provide status indicators that identify the

operational state of a domain name. Indicators MUST be provided to

identify a newly created state (the domain has been registered but has

not yet appeared in a zone), a nominal active state (the domain can be

modified and is published in a zone), an inactive state (the domain

can be modified but is not published in a zone because it has no

authoritative name servers), a hold state (the domain may not be

modified and is not published in a zone), a lock state (the domain may

not be modified and is published in a zone), a pending transfer state,

a transfer prohibited state, and a pending removal state.

[2] Indicators for hold and lock status MUST be available to allow

independent setting by both registry and registrar.

[3] A domain MAY have multiple statuses at any given time. Some

statuses MAY be mutually exclusive.

3.13 Transaction Completion Status

[1] The protocol MUST provide services that unambiguously note the

success or failure of every transaction. Individual success and error

conditions MUST be noted distinctly.

Hollenbeck Expires March 21, 2001 [Page 15]

Internet-Draft Generic RRP Requirements September 21, 2000

4. External Interface Requirements

External interfaces define the interaction points between a system and

entities that communicate with the system. Specific areas of interest

include user interfaces, hardware interfaces, software interfaces, and

communications interfaces.

4.1 User Interfaces

[1] A generic registry-registrar protocol MUST NOT define any features

that introduce user interface limitations.

4.2 Hardware Interfaces

[1] A generic registry-registrar protocol MUST NOT define any features

that introduce hardware interface limitations.

4.3 Software Interfaces

[1] A generic registry-registrar protocol MUST NOT define any features

that introduce software interface limitations.

4.4 Communications Interfaces

[1] Registries, registrars, and registrants interact using a wide

spectrum of communications interfaces built upon multiple protocols,

including transport layer protocols such as TCP and application layer

protocols such as SMTP. A generic registry-registrar protocol SHOULD

be serviceable over multiple standard communications protocols.

Hollenbeck Expires March 21, 2001 [Page 16]

Internet-Draft Generic RRP Requirements September 21, 2000

5. Performance Requirements

[1] Run-time performance is an absolutely critical aspect of protocol

usability. While performance is very heavily dependent on the hardware

and software architecture that implements a protocol, protocol

features can have a direct impact on the ability of the underlying

architecture to provide optimal performance. A generic registry-

registrar protocol MUST be usable in both high volume and low volume

operating environments.

6. Design Constraints

Protocol designers need to be aware of issues beyond functional and

interface requirements when balancing protocol design decisions. This

section describes additional factors that may have an impact on

protocol design, including standards compliance and hardware

limitations.

6.1 Standards Compliance

[1] A generic registry-registrar protocol MUST conform to current IETF

standards. Standards for domain and host name syntax, IP address

syntax, and security are particularly relevant. Emerging standards

for the Domain Name System MUST be considered as they approach

maturity.

6.2 Hardware Limitations

[1] A generic registry-registrar protocol MUST NOT define any features

that preclude hardware independence.

Hollenbeck Expires March 21, 2001 [Page 17]

Internet-Draft Generic RRP Requirements September 21, 2000

7. Service Attributes

Elements of service beyond functional and interface requirements are

essential factors to consider as part of a protocol design effort.

This section describes several important service elements that MUST be

addressed by protocol designers, including reliability, availability,

scalability, and maintainability.

7.1 Reliability

[1] Reliability is a measure of the extent to which a protocol

provides a consistent, dependable level of service. Reliability is an

important attribute for a domain name management protocol. An

unreliable protocol increases the risk of data exchange errors, which

at one extreme may have a direct impact on protocol usability and at

the other extreme may introduce discontinuity between registry and

registrar data stores. A generic registry-registrar protocol MUST

include features that maximize reliability at the application protocol

layer. Services provided by underlying transport, session, and

presentation protocols SHOULD also be considered when addressing

application protocol reliability.

[2] Default actions for when a request/event times out MUST be well

defined, and the protocol MUST consider the risk/consequences of

losing such events.

7.2 Availability

[1] Availability is a measure of the extent to which the services

provided by a protocol are accessible for an intended use.

Availability of an application layer protocol is primarily dependent

on the software and hardware systems that implement the protocol.

That is, the systems that implement the protocol MUST themselves be

inherently available. As such, a generic registry-registrar protocol

MUST NOT include any features that impinge on the underlying

reliability of the software and hardware systems needed to implement

the protocol.

7.3 Scalability

[1] Scalability is a measure of the extent to which a protocol can

accommodate use growth while preserving acceptable operational

characteristics. A generic registry-registrar protocol MUST be

capable of operating at an acceptable level as the load on registry

and registrar systems increases.

7.4 Maintainability

Hollenbeck Expires March 21, 2001 [Page 18]

Internet-Draft Generic RRP Requirements September 21, 2000

[1] Maintainability is a measure of the extent to which a protocol can

be adapted or modified to address unforeseen operational needs or

defects. A generic registry-registrar protocol SHOULD be developed

under the nominal working group processes of the IETF to provide a

well-known channel for ongoing maintenance.

7.5 Extensibility

[1] Extensibility is a measure of the extent to which a protocol can

be adapted for future uses that were not readily evident when the

protocol was originally designed. A generic registry-registrar

protocol SHOULD provide features that at a minimum allow for the

management of new object types without requiring revisions to the

protocol itself.

Hollenbeck Expires March 21, 2001 [Page 19]

Internet-Draft Generic RRP Requirements September 21, 2000

8. Other Requirements

Certain aspects of anticipated operational environments SHOULD be

considered when designing a generic registry-registrar protocol.

Areas of concern include database operations, daily operations, site

adaptation, and date formatting.

8.1 Database Requirements

[1] A generic registry-registrar protocol MUST NOT have any database

dependencies. However, efficient use of database operations and

resources MUST be considered as part of the protocol design effort.

The protocol SHOULD provide atomic features that can be efficiently

implemented to minimize database load for anticipated high volume

transactions.

8.2 Operations Requirements

[1] Registry-registrar interactions at the protocol level SHOULD

operate without human intervention. However, intermediate services

that preserve the integrity of the protocol MAY be provided. For

example, an intermediate service that determines if a registrant is

authorized to register a name in a TLD MAY be provided.

8.3 Site Adaptation Requirements

[1] Registries and registrars have varying business and operational

requirements. Several factors, including governance standards, local

laws, customs, and business practices all play roles in determining

how registries and registrars are operated. A generic registry-

registrar protocol MUST be flexible enough to operate in diverse

registry-registrar environments.

8.4 Date Format Requirements

[1] All date and time values specified in the generic registry-

registrar protocol MUST be expressed in Universal Coordinated Time,

also known as Greenwich Mean Time, or Zulu. Dates and times MUST

include information similar to that available in the following format:

YYYYMMDDHHMMSS.fffZ

where "YYYY" represents the year, the first "MM" represents the

calendar month (with values ranging from 01 - 12 representing January

through December), "DD" represents the calendar day, "HH" represents

the hour in 24-hour format, the second "MM" represents minutes, "SS"

represents seconds, ".fff" represents fractional seconds, and "Z"

represents Zulu time.

Hollenbeck Expires March 21, 2001 [Page 20]

Internet-Draft Generic RRP Requirements September 21, 2000

9. Internationalization Considerations

[1] Current Internet standards restrict the encoding of Internet host

and domain names to a subset of the 7-bit US-ASCII character set.

Registries and registrars now serve customers whose native languages

require encodings other than US-ASCII, which automatically disallows

use of those languages when registering host and domain names.

Support for internationalized host and domain names will greatly

increase world-wide usability of a generic registry registrar

protocol, so standards for internationalized host and domain names

MUST be considered during the protocol design process.

10. IANA Considerations

IANA has assigned several TCP and UDP ports for use within shared

registration systems. The assignments can be identified in two broad

categories: those assigned for use with the CORE Shared Registry

System Protocol (SRSP) and those assigned for use with the NSI

Registry Registrar Protocol (RRP).

The CORE SRSP assignments are as follows:

srssend 362/tcp SRS Send

srssend 362/udp SRS Send

srsp 2682/tcp SRSP

srsp 2682/udp SRSP

The NSI RRP assignments are as follows:

rrp 648/tcp Registry Registrar Protocol (RRP)

rrp 648/udp Registry Registrar Protocol (RRP)

These assignments SHOULD be preserved as long as the corresponding

systems are operational. Additional port assignments MAY be required

of IANA if the design of the generic registry-registrar protocol

specifies transport using TCP and/or UDP.

Hollenbeck Expires March 21, 2001 [Page 21]

Internet-Draft Generic RRP Requirements September 21, 2000

11. Security Considerations

Several security services, including confidentiality, authentication,

access control, integrity, and non-repudiation MAY be applied to

protect interactions between registries and registrars.

Confidentiality services protect sensitive exchanged information from

inadvertent disclosure. Authentication services confirm the claimed

identity of registries and registrars before engaging in online

transactions. Access control services control access to data and

services based on identity. Integrity services guarantee that

exchanged data has not been altered between the registry and the

registrar. Non-repudiation services provide assurance that the sender

of a transaction can not deny being the source of the transaction, and

that the recipient cannot deny being the receiver of the transaction.

[1] Security services MUST be provided to protect against the

following types of attack: eavesdropping, replay, message insertion,

deletion, modification, and man-in-the-middle. A registry MUST also

provide mechanisms to protect against denial of service attacks.

[2] This document describes requirements for basic user identification

and authentication services. A generic protocol MAY include

additional security services to protect against the attacks described

here, or a generic protocol MAY depend on lower-layer protocols to

provide additional security services.

Hollenbeck Expires March 21, 2001 [Page 22]

Internet-Draft Generic RRP Requirements September 21, 2000

12. References

[RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

13. Author's Address

Scott Hollenbeck

VeriSign Global Registry Services

21345 Ridgetop Circle

Dulles, VA 20166

USA

shollenb@netsol.com

14. Full Copyright Statement

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

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published and

distributed, in whole or in part, without restriction of any kind,

provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of developing

Internet standards in which case the procedures for copyrights defined

in the Internet Standards process must be followed, or as required to

translate it into languages other than English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT

NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN

WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the

Internet Society.

Hollenbeck Expires March 21, 2001 [Page 23]