draft-ietf-crisp-requirements-01.txt   draft-ietf-crisp-requirements-02.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: April 3, 2003 October 3, 2002 Expires: April 30, 2003 October 30, 2002
Cross Registry Internet Service Protocol (CRISP) Requirements Cross Registry Internet Service Protocol (CRISP) Requirements
draft-ietf-crisp-requirements-01 draft-ietf-crisp-requirements-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 3, 2003. This Internet-Draft will expire on April 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
Internet registries expose administrative and operational data via Internet registries expose administrative and operational data via
varying directory services. This document defines functional varying directory services. This document defines functional
requirements for the directory services of domain registries and the requirements for the directory services of domain registries and the
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 6 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 6 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 6
2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 6 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 6
2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 6 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 6
2.2.4 Incident Coordination Contact Registries . . . . . . . . . 6 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 6
2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 7 2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 7
2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Service Providers and Network Operators . . . . . . . . . 7 2.4.1 Service Providers and Network Operators . . . . . . . . . 7
2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 7 2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 7
2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 7 2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 8 2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 8
2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 8 2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 8
2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 8
3. Functional Requirements . . . . . . . . . . . . . . . . . 9 3. Functional Requirements . . . . . . . . . . . . . . . . . 9
3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 9 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 9 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 9
3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 9 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10
3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 10
3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 10
3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 10 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 10
3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 10 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 10
3.1.8 Query of Access Levels . . . . . . . . . . . . . . . . . . 10 3.1.8 Query of Access Levels . . . . . . . . . . . . . . . . . . 11
3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 11 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 11
3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 11 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 11
3.2.1 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . 11 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . 11 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 12
3.2.3 Domain Registrant Search . . . . . . . . . . . . . . . . . 11 3.2.1 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Domain Registrant Search . . . . . . . . . . . . . . . . . 12
3.2.4 Domain Information Lookup . . . . . . . . . . . . . . . . 12 3.2.4 Domain Information Lookup . . . . . . . . . . . . . . . . 12
3.2.5 Nameserver Search . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Nameserver Search . . . . . . . . . . . . . . . . . . . . 13
3.2.6 Escrow Support . . . . . . . . . . . . . . . . . . . . . . 12 3.2.6 Escrow Support . . . . . . . . . . . . . . . . . . . . . . 13
3.2.7 Domain Name Search . . . . . . . . . . . . . . . . . . . . 12 3.2.7 Domain Name Search . . . . . . . . . . . . . . . . . . . . 13
3.2.8 Result Set Limits . . . . . . . . . . . . . . . . . . . . 13 3.2.8 Result Set Limits . . . . . . . . . . . . . . . . . . . . 14
3.2.9 DNS Label Referencing . . . . . . . . . . . . . . . . . . 13 3.2.9 DNS Label Referencing . . . . . . . . . . . . . . . . . . 14
3.2.10 Distribution for Domain Registry Types . . . . . . . . . . 13 3.2.10 Distribution for Domain Registry Types . . . . . . . . . . 14
4. Feature Requirements . . . . . . . . . . . . . . . . . . . 14 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 15
4.1 Client Authentication . . . . . . . . . . . . . . . . . . 14 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 15
4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 14 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 15
4.4 Structured Queries and Responses . . . . . . . . . . . . . 14 4.4 Structured Queries and Responses . . . . . . . . . . . . . 15
4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 14 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 15
4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 14 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 16
4.7 Serialization Definition . . . . . . . . . . . . . . . . . 15 4.7 Serialization Definition . . . . . . . . . . . . . . . . . 16
5. Internationalization Considerations . . . . . . . . . . . 16 5. Internationalization Considerations . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . 20
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 20 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 22 B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 23
B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 23 B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . 24 Full Copyright Statement . . . . . . . . . . . . . . . . . 25
1. Background 1. Background
The expansion and growth of the Internet has seen the registry The expansion and growth of the Internet has seen the registry
function of a traditionally centralized and managed Network function of a traditionally centralized and managed Network
Information Center become the responsibility of various autonomous, Information Center become the responsibility of various autonomous,
functionally disparate, and globally distributed Internet functionally disparate, and globally distributed Internet registries.
registries. With the broadening number of Internet registries, the With the broadening number of Internet registries, the uses of their
uses of their administrative directory services have expanded from administrative directory services have expanded from the original and
the original and traditional use of the whois[4] protocol to include traditional use of the whois [4] protocol to include the use of whois
the use of whois outside the scope of its specification, formal and outside the scope of its specification, formal and informal
informal definitions of syntax, undocumented security mechanisms, definitions of syntax, undocumented security mechanisms, the use of
the use of other protocols, such as rwhois[3], to fulfill other other protocols, such as rwhois [3], to fulfill other needs, and
needs, and proposals for the use of other technologies such as proposals for the use of other technologies such as LDAP [1] and XML.
LDAP[1] and XML.
The scope of the requirements captured in this document relate to The scope of the requirements captured in this document relate to the
the directory services of Internet registries and their related directory services of Internet registries and their related
communities (Section 2.3,Section 2.4, and Section 2.5). This scoping communities (Section 2.3,Section 2.4, and Section 2.5). This scoping
specifically targets the requirements of domain name registries specifically targets the requirements of domain name registries
(Section 2.1) while acknowledging extensibility needs for possible (Section 2.1) while acknowledging extensibility needs for possible
future support of the requirements for other registry (Section 2.2) future support of the requirements for other registry (Section 2.2)
types. The requirements are of both the current use of these types. The requirements are of both the current use of these
directory services and the desired functionality based on input from directory services and the desired functionality based on input from
relevant forums (Appendix B.1). These requirements are not specific relevant forums (Appendix B.1). These requirements are not specific
to any protocol. Terms used in the definition of requirements in to any protocol. Terms used in the definition of requirements in
this document may be found in the glossary (Appendix A). this document may be found in the glossary (Appendix A).
The requirements captured in this document are for the purpose of The requirements captured in this document are for the purpose of
designing technical specifications. The words used in this document designing technical specifications. The words used in this document
for compliance with RFC2119[8] do not reference or specify policy for compliance with RFC2119[8] do not reference or specify policy
and speak only to the capabilities in the derived technology. The and speak only to the capabilities in the derived technology. For
scope of the requirements in this document are also restricted to instance, this document may say that the service "MUST" support
certain features. An actual service operator is always free to
disable it (and then to return an error such as "permission denied".)
The scope of the requirements in this document are also restricted to
access of data from Internet registries. Requirements for access of data from Internet registries. Requirements for
modification, addition, or provisioning of data in Internet modification, addition, or provisioning of data in Internet
registries are out of scope. registries are out of scope.
2. Internet Registry Communities 2. Internet Registry Communities
The Internet registries are composed of various communities which The Internet registries are composed of various communities which
provide scope for the requirements in this document. These provide scope for the requirements in this document. These
communities can be generalized into the following categories: communities can be generalized into the following categories:
registries, registrars, implementers, end-users, and other actors. registries, registrars, implementers, end-users, and other actors.
2.1 Domain Name System Registries 2.1 Domain Name System Registries
2.1.1 Domain Registries 2.1.1 Domain Registries
Domain registries are responsible for the registration of domains Domain registries are responsible for the registration of domains for
for use with DNS[2] and forward lookups (i.e. does not include the use with DNS [2] and forward lookups (i.e. does not include the IN-
IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically ADDR.ARPA or IP6.ARPA domains). These registries have typically
served two main domain functions: as the registry for a gTLD or as a served two main domain functions: as the registry for a gTLD or as a
registry for a ccTLD. In some instances, one entity will operate registry for a ccTLD. In some instances, one entity will operate
multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD multiple TLD's, both of the gTLD and ccTLD type. A gTLD or ccTLD
domain registry operator may be a governmental entity, domain registry operator may be a governmental entity, non-
non-governmental, non-commercial entity, or a commercial entity. governmental, non-commercial entity, or a commercial entity.
Some ccTLD's have second-level domain registrations similar in Some ccTLD's have second-level domain registrations similar in nature
nature to gTLD's or have distinctly separate entities operating to gTLD's or have distinctly separate entities operating second-level
second-level domain registries similar in nature to gTLD's within domain registries similar in nature to gTLD's within the ccTLD.
the ccTLD.
Domain registries usually follow one of two models for conducting Domain registries usually follow one of two models for conducting
registrations of domains. The "thick" model is the more traditional registrations of domains. The "thick" model is the more traditional
model. In a "thick" domain registry, the registry contains both the model. In a "thick" domain registry, the registry contains both the
operational data for the domain and the contact or social data operational data for the domain and the contact or social data
(Appendix A) for the domain. In this model, the registry is (Appendix A) for the domain. In this model, the registry is
typically the interface to the domain registrant but may also typically the interface to the domain registrant but may also
interface with the domain registrant through domain registrars. The interface with the domain registrant through domain registrars. The
"thin" model domain registry contains only operational data for "thin" model domain registry contains only operational data for
domains. In the "thin" model, contact or social data for the domain domains. In the "thin" model, contact or social data for the domain
skipping to change at page 6, line 14 skipping to change at page 6, line 14
domain on behalf of a registrant in more than one domain registry. domain on behalf of a registrant in more than one domain registry.
2.2 Other Registries 2.2 Other Registries
2.2.1 Regional Internet Registries 2.2.1 Regional Internet Registries
Regional Internet Registries (RIR's) administer the allocation of IP Regional Internet Registries (RIR's) administer the allocation of IP
address space and autonomous system numbers. Each RIR serves a address space and autonomous system numbers. Each RIR serves a
specific geographic region, and collectively they service the entire specific geographic region, and collectively they service the entire
Internet. Each RIR is a membership-based, non-profit organization Internet. Each RIR is a membership-based, non-profit organization
that facilitates and implements global addressing policy based on that facilitates and implements global addressing policy based on the
the direction of their regional community. direction of their regional community.
2.2.2 Local Internet Registries 2.2.2 Local Internet Registries
Local Internet Registries (LIR's) and National Internet Registries Local Internet Registries (LIR's) and National Internet Registries
(NIR's) are sub-registries of RIR's and coordinate the same (NIR's) are sub-registries of RIR's and coordinate the same functions
functions of the RIR's for smaller, more specific geographic of the RIR's for smaller, more specific geographic regions, sovereign
regions, sovereign nations, and localities. nations, and localities.
2.2.3 Internet Routing Registries 2.2.3 Internet Routing Registries
Internet Routing Registries are routing policy databases. Their Internet Routing Registries are routing policy databases. Their
purpose is to provide information helpful in administering Internet purpose is to provide information helpful in administering Internet
routers. Frequently, the syntax and contents are defined by RPSL[5]. routers. Frequently, the syntax and contents are defined by RPSL
[5].
IRR's are operated by academic, commercial, governmental, and other IRR's are operated by academic, commercial, governmental, and other
types of organizations, including several of the RIR's. The contents types of organizations, including several of the RIR's. The contents
of the databases vary and reflect the needs of the users directly of the databases vary and reflect the needs of the users directly
served (e.g. an ISP may look up route entries added by their served (e.g. an ISP may look up route entries added by their
customers to decide whether to accept specific route advertisements customers to decide whether to accept specific route advertisements
they receive). they receive).
Unlike RIR and domain registry data, IRR data is often duplicated Unlike RIR and domain registry data, IRR data is often duplicated
between separate organizations. The IRR data has the unique between separate organizations. The IRR data has the unique
characteristics of being largely available through other sources characteristics of being largely available through other sources
(i.e. it is advertised by the Internet routing protocols) and most (i.e. it is advertised by the Internet routing protocols) and most
often having a common data format, RPSL. often having a common data format, RPSL.
2.2.4 Incident Coordination Contact Registries 2.2.4 Incident Coordination Contact Registries
Incident coordination contact registries allow operators of network Incident coordination contact registries allow operators of network
resources such as network infrastructure, network names, or network resources such as network infrastructure, network names, or network
services to register contact information for the purpose of services to register contact information for the purpose of providing
providing a means of incident notification. Using this type of a means of incident notification. Using this type of registry, an
registry, an operators of network resources are provided information operators of network resources are provided information for
for contacting the operator of another network resource from which contacting the operator of another network resource from which an
an incident may be occurring. incident may be occurring.
2.2.5 Network Edge Resource Registries 2.2.5 Network Edge Resource Registries
Network edge resource registries provide specific information about Network edge resource registries provide specific information about
"edge" resources. They are administered by the operators of the "edge" resources. They are administered by the operators of the
resources. Examples of such registries are rwhois[3] servers resources. Examples of such registries are rwhois[3] servers
operated by networks to describe the assignment of address space operated by networks to describe the assignment of address space
allocated by RIR's or LIR's and whois[4] servers operated by allocated by RIR's or LIR's and whois[4] servers operated by
networks to specifically announce routing policy of that network. networks to specifically announce routing policy of that network.
skipping to change at page 7, line 35 skipping to change at page 7, line 36
2.4 End Users 2.4 End Users
2.4.1 Service Providers and Network Operators 2.4.1 Service Providers and Network Operators
Service providers and network operators provide connectivity, Service providers and network operators provide connectivity,
routing, and naming services to many other entities, some commercial routing, and naming services to many other entities, some commercial
and some non-commercial, both large and small. Their operational and and some non-commercial, both large and small. Their operational and
administrative staff often interact with Internet registries on administrative staff often interact with Internet registries on
behalf of other end-users. Service providers and network operators behalf of other end-users. Service providers and network operators
interact with all of the Internet registry operators outlined in interact with all of the Internet registry operators outlined in this
this document on a frequent and consistent basis. For example, document on a frequent and consistent basis. For example, network
network operators use the directory services of Internet registries operators use the directory services of Internet registries to
to determine contact information for network resources that have determine contact information for network resources that have
technical problems. technical problems.
2.4.2 Intellectual Property Holders 2.4.2 Intellectual Property Holders
Intellectual Property Holders have legal rights to the use of domain Intellectual Property Holders have legal rights to the use of domain
names based on copyright and trademark laws of various governments. names based on copyright and trademark laws of various governments.
They use the directory services of Internet registries, mostly They use the directory services of Internet registries, mostly domain
domain registries and registrars, for purposes of maintaining and registries and registrars, for purposes of maintaining and defending
defending claims to domain names consistent with applicable laws and claims to domain names consistent with applicable laws and
regulations. regulations.
2.4.3 Law Enforcement 2.4.3 Law Enforcement
Law enforcement agencies use the directory services of Internet Law enforcement agencies use the directory services of Internet
registries to find information used to carry out the enforcement of registries to find information used to carry out the enforcement of
laws within their jurisdictions. laws within their jurisdictions.
2.4.4 Certificate Authorities 2.4.4 Certificate Authorities
Certificate authorities use the directory services of Internet Certificate authorities use the directory services of Internet
registries as part of their verification process when issuing registries as part of their verification process when issuing
certificates for Internet named hosts. certificates for Internet named hosts.
2.4.5 DNS Users 2.4.5 DNS Users
Users of the Internet have client software that resolves domain Users of the Internet have client software that resolves domain names
names to IP addresses. Often when trouble occurs in the resolution to IP addresses. Often when trouble occurs in the resolution process
process of DNS, these users trouble shoot system problems with the of DNS, these users trouble shoot system problems with the aid of
aid of information from the directory services of Internet information from the directory services of Internet registries.
registries.
2.4.6 Domain Registrants 2.4.6 Domain Registrants
Entities given authority over a domain via purchase, lease, or grant Entities given authority over a domain via purchase, lease, or grant
from a domain registry, either directly or via the services of a from a domain registry, either directly or via the services of a
domain registrar. domain registrar.
2.5 Other Actors 2.5 Other Actors
Requirements must also consider the positions and policies of other Requirements must also consider the positions and policies of other
actors on the use of Internet registry directory services by other actors on the use of Internet registry directory services by other
actors. These actors include governments, non-governmental actors. These actors include governments, non-governmental policy-
policy-setting bodies, and other non-governmental organizations. setting bodies, and other non-governmental organizations.
3. Functional Requirements 3. Functional Requirements
Functional requirements describe an overall need or process for Functional requirements describe an overall need or process for which
which the directory service is used by an Internet registry to the directory service is used by an Internet registry to fulfill its
fulfill its obligations to provide access to its respective obligations to provide access to its respective customers, members,
customers, members, or other constituents. This section makes or other constituents. This section makes reference to terms and
reference to terms and definitions declared in Appendix A. This definitions declared in Appendix A. This section makes use of the
section makes use of the term "service" to denote the set of term "service" to denote the set of functions to be provided by, and
functions to be provided by, and the expected behavior of, software the expected behavior of, software built to meet these requirements
built to meet these requirements in one or more protocols. in one or more protocols.
These requirements are for the purpose of designing a technical These requirements are for the purpose of designing a technical
specification. The words used in this section are for compliance specification. The words used in this section are for compliance
with RFC2119[8], do not reference or specify policy, and speak only with RFC2119[8], do not reference or specify policy, and speak only
to the capabilities in the derived technology. to the capabilities in the derived technology. For instance, this
document may say that the service "MUST" support search features. An
actual service operator is always free to disable it (and the to
return an error such as "permission denied").
3.1 Base Functions 3.1 Base Functions
This section describes basic service requirements for an Internet This section describes basic service requirements for an Internet
registry service for any of the registries (domain name registries registry service for any of the registries (domain name registries
(Section 2.1) and other registries (Section 2.2)). Additional (Section 2.1) and other registries (Section 2.2)). Additional
requirements, specific to domain registries, are described in Domain requirements, specific to domain registries, are described in Domain
Specific Functions (Section 3.2). Specific Functions (Section 3.2).
3.1.1 Mining Prevention 3.1.1 Mining Prevention
skipping to change at page 10, line 20 skipping to change at page 10, line 24
3.1.4 Level of Access 3.1.4 Level of Access
The service MUST allow the classification of data as being either The service MUST allow the classification of data as being either
privileged or non-privileged, for the purpose of restricting access privileged or non-privileged, for the purpose of restricting access
to privileged data. Note that this requirement makes no assumption to privileged data. Note that this requirement makes no assumption
or prescription as to what data (social or operational) might be or prescription as to what data (social or operational) might be
considered privileged, but merely provides the ability to make the considered privileged, but merely provides the ability to make the
classification as necessary. classification as necessary.
The service MUST be capable of serving both privileged and The service MUST be capable of serving both privileged and non-
non-privileged data. privileged data.
The service MUST be capable of authenticating privileged entities The service MUST be capable of authenticating privileged entities and
and ensuring that only those entities have access to both privileged ensuring that only those entities have access to both privileged and
and non-privileged data. non-privileged data.
The service MUST be capable of providing access to non-privileged The service MUST be capable of providing access to non-privileged
data without requiring authentication of any type (i.e. anonymous data without requiring authentication of any type (i.e. anonymous
access). access).
3.1.5 Client Processing 3.1.5 Client Processing
The service MUST be capable of allowing machine parsable requests The service MUST be capable of allowing machine parsable requests and
and responses. responses.
3.1.6 Entity Referencing 3.1.6 Entity Referencing
There MUST be a mechanism for an entity contained within a server to There MUST be a mechanism for an entity contained within a server to
be referenced uniquely by an entry in another server. be referenced uniquely by an entry in another server.
3.1.7 Decentralization 3.1.7 Decentralization
The service MUST be decentralized in design and principle and MUST The service MUST be decentralized in design and principle and MUST
NOT require the aggregation of data to a central repository, server, NOT require the aggregation of data to a central repository, server,
skipping to change at page 11, line 18 skipping to change at page 11, line 23
It is the intent of this requirement for clients to learn of It is the intent of this requirement for clients to learn of
inadequate permission status for a query only after the query has inadequate permission status for a query only after the query has
been submitted. Operating modes allowing a client to predetermine been submitted. Operating modes allowing a client to predetermine
the queries that will or will not be denied are not encouraged for the queries that will or will not be denied are not encouraged for
security considerations. security considerations.
3.1.9 Authentication Distribution 3.1.9 Authentication Distribution
The service MUST NOT require any Internet registries to participate The service MUST NOT require any Internet registries to participate
in any particular distributed authentication system. The service in any particular distributed authentication system. The service
SHOULD allow the participation by an Internet registry in SHOULD allow the participation by an Internet registry in distributed
distributed authentication by many centralized authorities. authentication by many centralized authorities.
3.1.10 Base Error Responses
The service MUST be capable of returning the following types of non-
result or error responses to all lookups and searches:
o permission denied - a response indicating that the search or
lookup has failed due to insufficient authorization.
o not found - the desired results do not exist.
o insufficient resources - the search or lookup requires resources
that cannot be allocated.
3.1.11 Query Distribution
For lookups and searches requiring distribution of queries, the
service MUST be capable of distributing these queries among the
participants in an established mesh of service operators. It is not
a requirement that the service enable the discovery of service
operators, but the service should be able to intelligently handle
distribution with its established mesh. Individual service operators
will respond to all queries received according to their policies for
authentication, privacy, and performance.
3.2 Domain Specific Functions 3.2 Domain Specific Functions
These functions describe requirements specifically needed by domain These functions describe requirements specifically needed by domain
registries (Section 2.1.1) and domain registrars (Section 2.1.2). registries (Section 2.1.1) and domain registrars (Section 2.1.2).
Requirements specific to other registries (Section 2.2) MUST be Requirements specific to other registries (Section 2.2) MUST be
specified separately. No compliant service entity is required to specified separately. No compliant service entity is required to
support the functions required by every registry type. support the functions required by every registry type.
3.2.1 Contact Lookup 3.2.1 Contact Lookup
skipping to change at page 11, line 51 skipping to change at page 12, line 35
nameserver. The host information set MUST be able to express and nameserver. The host information set MUST be able to express and
represent the attributes and allowable values of nameservers in represent the attributes and allowable values of nameservers in
domain registration and provisioning protocols. domain registration and provisioning protocols.
3.2.3 Domain Registrant Search 3.2.3 Domain Registrant Search
The service MUST provide the capability of searching for registrants The service MUST provide the capability of searching for registrants
by exact name match or a reasonable name subset. This search must by exact name match or a reasonable name subset. This search must
comply with Section 3.2.8. comply with Section 3.2.8.
The service MUST provide a mechanism to distribute this search The service MUST provide a mechanism to distribute this search across
across all applicable domain registries and registrars. The service all applicable domain registries and registrars. The service SHOULD
SHOULD have a means to narrow the scope of a search to a specific have a means to narrow the scope of a search to a specific TLD. The
TLD. The service MUST be able to specify to the client an empty service MUST be able to specify to the client an empty result set
result set should the search yield no results. should the search yield no results.
3.2.4 Domain Information Lookup 3.2.4 Domain Information Lookup
The service MUST provide access to operational and social data The service MUST provide access to operational and social data
specific to a domain given the domain's fully qualified name (FQDN). specific to a domain given the domain's fully qualified name (FQDN).
The service MUST be capable of supplying the following information The service MUST be capable of supplying the following information
for this lookup: for this lookup:
o activation status o activation status
skipping to change at page 12, line 20 skipping to change at page 13, line 4
The service MUST provide access to operational and social data The service MUST provide access to operational and social data
specific to a domain given the domain's fully qualified name (FQDN). specific to a domain given the domain's fully qualified name (FQDN).
The service MUST be capable of supplying the following information The service MUST be capable of supplying the following information
for this lookup: for this lookup:
o activation status o activation status
o registrant name and contact data o registrant name and contact data
o hosting nameservers o hosting nameservers
o technical, billing or other entity types associated with the o technical, billing or other entity types associated with the
domain and their relevant contact data, if any exist domain and their relevant contact data, if any exist
o the name of or a reference to the registry delegating the domain o the name of or a reference to the registry delegating the domain
o the name of or a reference to the registrar for the domain, if o the name of or a reference to the registrar for the domain, if one
one exists exists
The domain information set MUST be able to express and represent the The domain information set MUST be able to express and represent the
attributes and allowable values of domain registration requests in attributes and allowable values of domain registration requests in
domain registration and provisioning protocols. domain registration and provisioning protocols.
3.2.5 Nameserver Search 3.2.5 Nameserver Search
The service MAY allow the ability to list all domains hosted by a The service MAY allow the ability to list all domains hosted by a
specific nameserver given the fully-qualified host name or IP specific nameserver given the fully-qualified host name or IP
address, if applicable, of the nameserver. The service MAY provide a address, if applicable, of the nameserver. The service MAY provide a
skipping to change at page 12, line 50 skipping to change at page 13, line 33
3.2.6 Escrow Support 3.2.6 Escrow Support
The service MUST provide a means to escrow data of domain registrars The service MUST provide a means to escrow data of domain registrars
to an escrow entity using a common schema. This escrow capability to an escrow entity using a common schema. This escrow capability
SHOULD be "off-line" and "out-of-band" from the normal operations of SHOULD be "off-line" and "out-of-band" from the normal operations of
the service. the service.
3.2.7 Domain Name Search 3.2.7 Domain Name Search
The service MUST allow searching for domains by exact name match or The service MUST allow searching for domains by exact name match or a
a reasonable subset of a domain name. This search SHOULD allow for reasonable subset of a domain name. This search SHOULD allow for
parameters and qualifiers designed to allow better matching of parameters and qualifiers designed to allow better matching of
internationalized domain names and SHOULD allow for both exact and internationalized domain names and SHOULD allow for both exact and
partial matching within the limits of internationalized domain partial matching within the limits of internationalized domain names.
names. The service SHOULD NOT require special transformations of The service SHOULD NOT require special transformations of
internationalized domain names to accommodate this search. This internationalized domain names to accommodate this search. This
search MUST comply with Section 3.2.8. search MUST comply with Section 3.2.8.
The service MUST provide a mechanism to distribute this search The service MUST provide a mechanism to distribute this search across
across all applicable domain registries and registrars. There should all applicable domain registries and registrars. There should be a
be a means to narrow this search based on a TLD. means to narrow this search based on a TLD.
The search mechanism SHOULD provide for differences in domain names The search mechanism SHOULD provide for differences in domain names
between the native representation and the canonical form existing in between the native representation and the canonical form existing in
the registry. the registry.
3.2.8 Result Set Limits 3.2.8 Result Set Limits
The service MAY provide limits to the number of results from The service MAY provide limits to the number of results from searches
searches and lookups to improve performance bottlenecks or comply and lookups to improve performance bottlenecks or comply with Section
with Section 3.1.1. The service MUST be capable of providing to the 3.1.1. The service MUST be capable of providing to the client an
client an indication that a result set has been truncated or indication that a result set has been truncated or limited. The
limited. The service MUST be capable of distinguishing the cause of service MUST be capable of distinguishing the cause of this condition
this condition as either a mechanism to improve performance as either a mechanism to improve performance bottlenecks, as
bottlenecks, as specified above, or a means of compliance with specified above, or a means of compliance with Section 3.1.1.
Section 3.1.1.
3.2.9 DNS Label Referencing 3.2.9 DNS Label Referencing
The service MUST use DNS[2] to determine the authoritative source of The service MUST use DNS[2] to determine the authoritative source of
information about domain names. It is the intention of this information about domain names. It is the intention of this
requirement that a client be able to determine via DNS and query the requirement that a client be able to determine via DNS and query the
servers or set of servers of the domain registry delegating the servers or set of servers of the domain registry delegating the
domain name, the domain registrar responsible for registering the domain name, the domain registrar responsible for registering the
domain name if one is applicable, and the domain registrant of the domain name if one is applicable, and the domain registrant of the
domain name. The service SHOULD provide procedures or mechanisms to domain name. The service SHOULD provide procedures or mechanisms to
allow this determination if it cannot be done using DNS. This allows allow this determination if it cannot be done using DNS. This allows
the service to operate when an operator chooses not to take the service to operate when an operator chooses not to take advantage
advantage of DNS label referencing and during periods of transient of DNS label referencing and during periods of transient or erroneous
or erroneous state of DNS configuration. state of DNS configuration.
3.2.10 Distribution for Domain Registry Types 3.2.10 Distribution for Domain Registry Types
The service MUST allow for the various registration distribution The service MUST allow for the various registration distribution
models of domain registry types described in Section 2.1.1 while models of domain registry types described in Section 2.1.1 while
complying with Section 3.1.7. complying with Section 3.1.7.
4. Feature Requirements 4. Feature Requirements
Feature requirements describe the perceived need derived from the Feature requirements describe the perceived need derived from the
functional requirements for specific technical criteria of the functional requirements for specific technical criteria of the
directory service. This section makes references to terms and directory service. This section makes references to terms and
definitions declared in Appendix A . This section uses the term definitions declared in Appendix A . This section uses the term
"service" to denote the set of features to be provided by, and the "service" to denote the set of features to be provided by, and the
expected behavior of, software built to meet these requirements in expected behavior of, software built to meet these requirements in
one or more protocols. one or more protocols.
These requirements are for the purpose of designing a technical These requirements are for the purpose of designing a technical
specification. The words used in this section are for compliance specification. The words used in this section are for compliance
with RFC2119[8], do not reference or specify policy, and speak only with RFC2119[8], do not reference or specify policy, and speak only
to the capabilities in the derived technology. to the capabilities in the derived technology. For instance, this
document may say that the service "MUST" support certain features.
An actual service operator is always free to disable it (and then to
return an error such as "permission denied").
4.1 Client Authentication 4.1 Client Authentication
Entities accessing the service (users) MUST be provided a mechanism Entities accessing the service (users) MUST be provided a mechanism
for passing credentials to a server for the purpose of for passing credentials to a server for the purpose of
authentication. The service MUST provide a mechanism capable of authentication. The service MUST provide a mechanism capable of
employing many authentication types and capable of extension for employing many authentication types and capable of extension for
future authentication types. future authentication types.
4.2 Referrals 4.2 Referrals
To distribute queries for search continuations and to issue entity To distribute queries for search continuations and to issue entity
references, the service MUST provide a referral mechanism. references, the service MUST provide a referral mechanism.
4.3 Common Referral Mechanism 4.3 Common Referral Mechanism
To distribute queries for search continuation and to issue entity To distribute queries for search continuations and to issue entity
references, the service MUST define a common referral scheme and references, the service MUST define a common referral scheme and
syntax. syntax.
4.4 Structured Queries and Responses 4.4 Structured Queries and Responses
To provide for machine consumption as well as human consumption, the To provide for machine consumption as well as human consumption, the
service MUST employ structured queries and responses. service MUST employ structured queries and responses.
4.5 Existing Schema Language 4.5 Existing Schema Language
skipping to change at page 19, line 24 skipping to change at page 20, line 24
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997. June 1997.
[4] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC [4] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985. 954, October 1985.
[5] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [5] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language (RPSL)", RFC 2622, June 1999. Policy Specification Language (RPSL)", RFC 2622, June 1999.
[6] Alvestrand, H.T., "IETF Policy on Character Sets and [6] Alvestrand, H., "IETF Policy on Character Sets and Languages",
Languages", BCP 18, RFC 2277, January 1998. BCP 18, RFC 2277, January 1998.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC [7] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[9] <http://www.ietf.org/proceedings/00dec/00dec-41.htm> [9] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[10] <http://www.ietf.org/proceedings/01aug/51-40.htm> [10] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[11] <http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-Resume [11] <http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-
.pdf> Resume.pdf>
[12] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/min_ [12] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
database.html> min_database.html>
[13] <http://www.nanog.org/mtg-0110/lookup.html> [13] <http://www.nanog.org/mtg-0110/lookup.html>
Author's Address Author's Address
Andrew L. Newton Andrew L. Newton
VeriSign, Inc. VeriSign, Inc.
21345 Ridgetop Circle 21355 Ridgetop Circle
Sterling, VA 20166 Sterling, VA 20166
USA USA
Phone: +1 703 948 3382 Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com EMail: anewton@ecotroph.net
URI: http://www.verisignlabs.com/ URI: http://www.verisignlabs.com/
Appendix A. Glossary Appendix A. Glossary
o TLD: Initials for "top level domain." Referes to domains in o TLD: Initials for "top level domain." Referes to domains in DNS
DNS[2]that are hierarchically at the level just beneath the root. [2]that are hierarchically at the level just beneath the root.
o ccTLD: Initials for "country code top level domain." TLD's which o ccTLD: Initials for "country code top level domain." TLD's which
use one of the two character country codes defined by ISO. use one of the two character country codes defined by ISO.
o gTLD: Initials for "generic top level domain." TLD's that do not o gTLD: Initials for "generic top level domain." TLD's that do not
use one of the two character country codes defined by ISO. use one of the two character country codes defined by ISO.
o social data: Data containing names and contact information (i.e. o social data: Data containing names and contact information (i.e.
postal addresses, phone numbers, e-mail addresses) of humans or postal addresses, phone numbers, e-mail addresses) of humans or
legal entities. legal entities.
skipping to change at page 21, line 48 skipping to change at page 22, line 48
organization, with authorization to access data. organization, with authorization to access data.
o non-privileged entity: A person, or person acting on behalf on an o non-privileged entity: A person, or person acting on behalf on an
organization, with no authorization to access data. organization, with no authorization to access data.
o privileged data: Data accessible by a privileged entities. o privileged data: Data accessible by a privileged entities.
o non-privileged data: Data accessible by privileged entities and o non-privileged data: Data accessible by privileged entities and
non-privileged entities. non-privileged entities.
o forward lookup: a DNS lookup where a domain name is resolved to o forward lookup: a DNS lookup where a domain name is resolved to an
an IP address. IP address.
o reverse lookup: a DNS lookup where an IP address is resolved to a o reverse lookup: a DNS lookup where an IP address is resolved to a
domain name. domain name.
o mining: In the context of this document, this term is specific to o mining: In the context of this document, this term is specific to
data mining. This is a methodical process to obtain the contents data mining. This is a methodical process to obtain the contents
of directory service, usually as much as possible, not relevant of directory service, usually as much as possible, not relevant to
to any immediate need. Data mining is often not a practice any immediate need. Data mining is often not a practice welcomed
welcomed by registry operators. by registry operators.
Appendix B. Acknowledgements Appendix B. Acknowledgements
B.1 Forums B.1 Forums
The proceedings of the following public forums were used as input to The proceedings of the following public forums were used as input to
the scope and requirements for this document: the scope and requirements for this document:
o whois BOF of the 49th IETF[9]; December 10-15, 2000; San Diego, o whois BOF of the 49th IETF[9]; December 10-15, 2000; San Diego,
CA, USA CA, USA
skipping to change at page 23, line 48 skipping to change at page 24, line 48
o CENTR General Assembly, February 21-22, 2002; Rambouillet, France o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
Minnesota, USA Minnesota, USA
B.2 Working Group B.2 Working Group
This document is a work item of the Cross-Registry Internet Service This document is a work item of the Cross-Registry Internet Service
Protocol (CRISP) Working Group in the Applications Area of the IETF. Protocol (CRISP) Working Group in the Applications Area of the IETF.
Discussions for this working group are held on the email list Discussions for this working group are held on the email list ietf-
ietf-not43@lists.verisignlabs.com. To subscribe to this email list, not43@lists.verisignlabs.com. To subscribe to this email list, send
send email to ietf-not43-request@lists.verisignlabs.com with a email to ietf-not43-request@lists.verisignlabs.com with a subject
subject line of "subscribe". Archives of this list may be found out line of "subscribe". Archives of this list may be found out http://
http://lists.verisignlabs.com/pipermail/ietf-not43/. lists.verisignlabs.com/pipermail/ietf-not43/.
B.3 Contributions B.3 Contributions
Comments, suggestions, and feedback of significant substance have Comments, suggestions, and feedback of significant substance have
been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
Kerr, and Cathy Murphy. Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
Hall, and Patrick Mevzek.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/