draft-ietf-crisp-requirements-06.txt   rfc3707.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Request for Comments: 3707 VeriSign, Inc.
Expires: February 20, 2004 August 22, 2003 Category: Informational February 2004
Cross Registry Internet Service Protocol (CRISP) Requirements Cross Registry Internet Service Protocol (CRISP) Requirements
draft-ietf-crisp-requirements-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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.
This Internet-Draft will expire on February 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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
common base requirements for extending the use of these services for common base requirements for extending the use of these services for
other types of Internet registries. other types of Internet registries.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Scope . . . . . . . . . . . . . . . . . . . 3
1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 1.3. Requirements Specification . . . . . . . . . . . . . . . 3
2. Internet Registry Communities . . . . . . . . . . . . . . 6 2. Internet Registry Communities . . . . . . . . . . . . . . . . 4
2.1 Domain Name System Registries . . . . . . . . . . . . . . 6 2.1. Domain Name System Registries . . . . . . . . . . . . . 4
2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Domain Registries . . . . . . . . . . . . . . . 4
2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Domain Registrars . . . . . . . . . . . . . . . 5
2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7 2.2. Other Registries . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7 2.2.1. Regional Internet Registries . . . . . . . . . . 5
2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7 2.2.2. Local Internet Registries . . . . . . . . . . . 5
2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7 2.2.3. Internet Routing Registries . . . . . . . . . . 5
2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7 2.2.4. Incident Coordination Contact Registries . . . . 6
2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Implementers . . . . . . . . . . . . . . . . . . . . . . 6
2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. End Users . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Internet Resource Registrants . . . . . . . . . . . . . . 8 2.4.1. Internet Resource Registrants . . . . . . . . . 6
2.4.2 Service Providers and Network Operators . . . . . . . . . 8 2.4.2. Service Providers and Network Operators . . . . 6
2.4.3 Intellectual Property Holders . . . . . . . . . . . . . . 8 2.4.3. Intellectual Property Holders . . . . . . . . . 7
2.4.4 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9 2.4.4. Law Enforcement . . . . . . . . . . . . . . . . 7
2.4.5 Certificate Authorities . . . . . . . . . . . . . . . . . 9 2.4.5. Certificate Authorities . . . . . . . . . . . . 7
2.4.6 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.6. DNS Users . . . . . . . . . . . . . . . . . . . 7
2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 2.4.7. Abusive Users . . . . . . . . . . . . . . . . . 7
2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Other Actors . . . . . . . . . . . . . . . . . . . . . . 8
3. Functional Requirements . . . . . . . . . . . . . . . . . 10 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 8
3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Base Functions . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Mining Prevention . . . . . . . . . . . . . . . 8
3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10 3.1.2. Minimal Technical Reinvention . . . . . . . . . 8
3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 3.1.3. Standard and Extensible Schemas . . . . . . . . 9
3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11 3.1.4. Level of Access . . . . . . . . . . . . . . . . 9
3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 12 3.1.5. Client Processing . . . . . . . . . . . . . . . 10
3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 12 3.1.6. Entity Referencing . . . . . . . . . . . . . . . 10
3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 12 3.1.7. Decentralization . . . . . . . . . . . . . . . . 10
3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12 3.1.8. Query of Access Permission . . . . . . . . . . . 11
3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12 3.1.9. Authentication Distribution . . . . . . . . . . 11
3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 13 3.1.10. Base Error Responses . . . . . . . . . . . . . . 11
3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13 3.1.11. Query Distribution . . . . . . . . . . . . . . . 12
3.1.12 Protocol and Schema Versioning . . . . . . . . . . . . . . 13 3.1.12. Protocol and Schema Versioning . . . . . . . . . 12
3.1.13 Relay Bag . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.13. Relay Bag . . . . . . . . . . . . . . . . . . . 13
3.1.14 Privacy Labels . . . . . . . . . . . . . . . . . . . . . . 15 3.1.14. Privacy Labels . . . . . . . . . . . . . . . . . 14
3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 15 3.2. Domain Specific Functions . . . . . . . . . . . . . . . 14
3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1. Lookups . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.2. Searches . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Information Sets . . . . . . . . . . . . . . . . . . . . . 17 3.2.3. Information Sets . . . . . . . . . . . . . . . . 16
3.2.4 Serialization Support . . . . . . . . . . . . . . . . . . 18 3.2.4. Serialization Support . . . . . . . . . . . . . 17
3.2.5 Result Set Limits . . . . . . . . . . . . . . . . . . . . 18 3.2.5. Result Set Limits . . . . . . . . . . . . . . . 17
3.2.6 DNS Delegation Referencing . . . . . . . . . . . . . . . . 19 3.2.6. DNS Delegation Referencing . . . . . . . . . . . 17
3.2.7 Distribution for Domain Registry Types . . . . . . . . . . 19 3.2.7. Distribution for Domain Registry Types . . . . . 18
3.2.8 Data Omission . . . . . . . . . . . . . . . . . . . . . . 19 3.2.8. Data Omission . . . . . . . . . . . . . . . . . 18
3.2.9 Internationalization . . . . . . . . . . . . . . . . . . . 20 3.2.9. Internationalization . . . . . . . . . . . . . . 19
4. Feature Requirements . . . . . . . . . . . . . . . . . . . 21 4. Feature Requirements . . . . . . . . . . . . . . . . . . . . . 19
4.1 Client Authentication . . . . . . . . . . . . . . . . . . 21 4.1. Client Authentication . . . . . . . . . . . . . . . . . 19
4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 21 4.3. Common Referral Mechanism . . . . . . . . . . . . . . . 20
4.4 Structured Queries and Responses . . . . . . . . . . . . . 21 4.4. Structured Queries and Responses . . . . . . . . . . . . 20
4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 21 4.5. Existing Schema Language . . . . . . . . . . . . . . . . 20
4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 21 4.6. Defined Schemas . . . . . . . . . . . . . . . . . . . . 20
5. Internationalization Considerations . . . . . . . . . . . 22 5. Internationalization Considerations . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . 26 Informative References . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . 26 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 27 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 28 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 28 B.1. Forums. . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 28 B.2. Working Group . . . . . . . . . . . . . . . . . . . . . . 24
B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 29 B.3. Contributions . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . 30 Intellectual Property Statement. . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
1.1 Background 1.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 registries. functionally disparate, and globally distributed Internet registries.
With the broadening number of Internet registries, the uses of their With the broadening number of Internet registries, the uses of their
administrative directory services have expanded from the original and administrative directory services have expanded from the original and
traditional use of the whois [6] protocol to include the use of whois traditional use of the whois [6] protocol to include the use of whois
outside the scope of its specification, formal and informal outside the scope of its specification, formal and informal
definitions of syntax, undocumented security mechanisms, the use of definitions of syntax, undocumented security mechanisms, the use of
other protocols, such as rwhois [5], to fulfill other needs, and other protocols, such as rwhois [5], to fulfill other needs, and
proposals for the use of other technologies such as LDAP [4] and XML. proposals for the use of other technologies such as LDAP [4] and XML.
1.2 Requirements Scope 1.2. Requirements Scope
The scope of the requirements captured in this document relate to the The scope of the requirements captured in this document relate to 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
specifically targets the requirements of domain name registries scoping specifically targets the requirements of domain name
(Section 2.1). The requirements for other registry types will be made registries (Section 2.1). The requirements for other registry types
available in other memos. The requirements are of both the current will be made available in other memos. The requirements are of both
use of these directory services and the desired functionality based the current use of these directory services and the desired
on input from relevant forums (Appendix B.1). These requirements are functionality based on input from relevant forums (Appendix B.1).
not specific to any protocol. Terms used in the definition of These requirements are not specific to any protocol. Terms used in
requirements in this document may be found in the glossary (Appendix the definition of requirements in this document may be found in the
A). glossary (Appendix A).
The scope of the requirements in this document are also restricted to 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 the scope of this document.
1.3 Requirements Specification 1.3. Requirements Specification
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 [3] do not reference or specify policy for compliance with RFC2119 [3] do not reference or specify policy
and speak only to the capabilities in the derived technology. For and speak only to the capabilities in the derived technology. For
instance, this document may say that the protocol "MUST" support instance, this document may say that the protocol "MUST" support
certain features. An actual service operator is always free to certain features. An actual service operator is always free to
disable it (and then to return an error such as "permission denied".) disable it (and then to return an error such as "permission denied".)
Requirements in this document specifying the capabilities of the Requirements in this document specifying the capabilities of the
protocol required for proper interaction between a client and a protocol required for proper interaction between a client and a
server will be specified with the "MUST/SHOULD" language of RFC2119 server will be specified with the "MUST/SHOULD" language of RFC2119
[3]. This document also contains language relating to the [3]. This document also contains language relating to the
interaction of a client with multiple servers to form a coherent, interaction of a client with multiple servers to form a coherent,
cross-network service. Such service requirements will not be cross-network service. Such service requirements will not be
described using RFC2119 language. described using RFC2119 language.
While individual servers/service operators may not support all While individual servers/service operators may not support all
features that the protocol can support, they must respect the features that the protocol can support, they must respect the
skipping to change at page 6, line 12 skipping to change at page 4, line 24
semantics of the protocol queries and responses. For example, a semantics of the protocol queries and responses. For example, a
server should not return referrals if it does not have referent data. server should not return referrals if it does not have referent data.
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 for Domain registries are responsible for the registration of domains for
use with DNS [1] and forward lookups (i.e. does not include the .ARPA use with DNS [1] and forward lookups (i.e., does not include the
domain). These registries have typically served two main domain .ARPA domain). These registries have typically served two main
functions: as the registry for a gTLD or as a registry for a ccTLD. domain functions: as the registry for a gTLD or as a registry for a
In some instances, one entity will operate multiple TLD's, both of ccTLD. In some instances, one entity will operate multiple TLD's,
the gTLD and ccTLD type. A gTLD or ccTLD domain registry operator may both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry
be a governmental entity, non-governmental, non-commercial entity, or operator may be a governmental entity, non-governmental,
a commercial entity. non-commercial entity, or a commercial entity.
Some ccTLD's have second-level domain registrations similar in nature Some ccTLD's have second-level domain registrations similar in nature
to gTLD's or have distinctly separate entities operating second-level to gTLD's or have distinctly separate entities operating second-level
domain registries similar in nature to gTLD's within the ccTLD. domain registries similar in nature to gTLD's within 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 data (Appendix A) for operational data for the domain and the contact data (Appendix A) for
the domain. In this model, the registry is typically the interface to the domain. In this model, the registry is typically the interface
the domain registrant but may also interface with the domain to the domain registrant but may also interface with the domain
registrant through domain registrars. The "thin" model domain registrant through domain registrars. The "thin" model domain
registry contains only operational data for domains. In the "thin" registry contains only operational data for domains. In the "thin"
model, contact data for the domain are maintained by a domain model, contact data for the domain are maintained by a domain
registrar. registrar.
Domain registries not described in this section (Section 2.1.1) are Domain registries not described in this section (Section 2.1.1) are
not the subject of this document and may have requirements that are not the subject of this document and may have requirements that are
out of scope for this subject matter. out of scope for this subject matter.
2.1.2 Domain Registrars 2.1.2. Domain Registrars
Domain registrars accept domain registrations from registrants on Domain registrars accept domain registrations from registrants on
behalf of domain registries, both "thick" and "thin". In a "thin" behalf of domain registries, both "thick" and "thin". In a "thin"
model registry/registrar system, a domain registrar maintains the model registry/registrar system, a domain registrar maintains the
contact data of a domain while the registry maintains the operational contact data of a domain while the registry maintains the operational
data of a domain. In a "thick" model registry/registrar system, a data of a domain. In a "thick" model registry/registrar system, a
domain registrar passes both the operational data and contact data to domain registrar passes both the operational data and contact data to
the registry. Domain registrars may register a domain on behalf of a the registry. Domain registrars may register a domain on behalf of a
registrant in more than one domain registry. registrant in more than one domain registry.
2.2 Other Registries 2.2. Other Registries
This section describes Internet registries other than those listed in This section describes Internet registries other than those listed in
Section 2.1. These descriptions are not definitive and this list is Section 2.1. These descriptions are not definitive and this list is
not absolute. They are provided in this document for informational not absolute. They are provided in this document for informational
purposes only. purposes only.
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 the that facilitates and implements global addressing policy based on 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 functions (NIR's) are sub-registries of RIR's and coordinate the same functions
of the RIR's for smaller, more specific geographic regions, sovereign of the RIR's for smaller, more specific geographic 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 [7]. routers. Frequently, the syntax and contents are defined by RPSL
[7].
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 providing services to register contact information for the purpose of providing
a means of incident notification. Using this type of registry, an a means of incident notification. Using this type of registry, an
operators of network resources are provided information for operator of network resources are provided information for contacting
contacting the operator of another network resource from which an the operator of another network resource from which an incident may
incident may be occurring. be occurring.
2.3 Implementers 2.3. Implementers
Implementers of client software are often either affiliated with Implementers of client software are often either affiliated with
large network operators, registry operators, or commercial entities large network operators, registry operators, or commercial entities
offering value-added services, or are general citizens of the offering value-added services, or are general citizens of the
Internet. Much of the client software for use with the directory Internet. Much of the client software for use with the directory
services of Internet registries is either freely available, open services of Internet registries is either freely available, open
source, or both, or available as a service. Implementers of server source, or both, or available as a service. Implementers of server
software are often affiliated with operators or commercial entities software are often affiliated with operators or commercial entities
specializing in the out-sourcing of development for Internet specializing in the out-sourcing of development for Internet
registries. registries.
2.4 End Users 2.4. End Users
This section describes the many type of end-users. Individuals and This section describes the many types of end-users. Individuals and
organizations may have multiple roles and may concurrently occupy organizations may have multiple roles and may concurrently occupy
many of the categories. many of the categories.
2.4.1 Internet Resource Registrants 2.4.1. Internet Resource Registrants
Entities given authority over an Internet resource via purchase, Entities given authority over an Internet resource via purchase,
lease, or grant from an Internet registry, either directly or via the lease, or grant from an Internet registry, either directly or via the
services of a registrar. services of a registrar.
2.4.2 Service Providers and Network Operators 2.4.2. 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 this interact with all of the Internet registry operators outlined in this
document on a frequent and consistent basis. For example, network document on a frequent and consistent basis. For example, network
operators use the directory services of Internet registries to operators use the directory services of Internet registries to
determine contact information for network resources that have determine contact information for network resources that have
technical problems. technical problems.
2.4.3 Intellectual Property Holders 2.4.3. Intellectual Property Holders
A number of parties, such as trademark, service mark and intellectual A number of parties, such as trademark, service mark and intellectual
property holders, individuals, governments and other geopolitical property holders, individuals, governments and other geopolitical
entities, have some legal rights on certain alphanumeric strings. entities, have some legal rights on certain alphanumeric strings.
They use the directory services of Internet registries, mostly domain They use the directory services of Internet registries, mostly domain
registries and registrars, for purposes of maintaining and defending registries and registrars, for purposes of maintaining and defending
claims to domain names consistent with applicable laws and claims to domain names consistent with applicable laws and
regulations. regulations.
2.4.4 Law Enforcement 2.4.4. 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.5 Certificate Authorities 2.4.5. 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.6 DNS Users 2.4.6. DNS Users
Users of the Internet have client software that resolves domain names Users of the Internet have client software that resolves domain names
to IP addresses and IP addresses to domain names. Often when trouble to IP addresses and IP addresses to domain names. Often when trouble
occurs in the resolution process of DNS, these users trouble shoot occurs in the resolution process of DNS, these users trouble shoot
system problems with the aid of information from the directory system problems with the aid of information from the directory
services of Internet registries. services of Internet registries.
2.4.7 Abusive Users 2.4.7. Abusive Users
The administrative directory services of Internet registries are The administrative directory services of Internet registries are
often the target of practices by abusive users. Using information often the target of practices by abusive users. Using information
obtained from Internet registries, abusive users undertake certain obtained from Internet registries, abusive users undertake certain
activities that are counter to the acceptable use of the information activities that are counter to the acceptable use of the information
as intended by a registry, registrar, or registrant. Many times, as intended by a registry, registrar, or registrant. Many times,
these practices violate law in the jurisdiction of the user, these practices violate law in the jurisdiction of the user,
registry, registrar, or registrant. One example is the use of registry, registrar, or registrant. One example is the use of
Internet registry information for the use of sending unsolicited bulk Internet registry information for the use of sending unsolicited bulk
or commercial email. or commercial email.
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. These actors on the use of Internet registry directory services. These
actors include governments, non-governmental policy-setting bodies, actors include governments, non-governmental policy-setting bodies,
and other non-governmental organizations. and other non-governmental organizations.
3. Functional Requirements 3. Functional Requirements
Functional requirements describe an overall need or process for which Functional requirements describe an overall need or process for which
the directory service is used by an Internet registry to fulfill its the directory service is used by an Internet registry to fulfill its
obligations to provide access to its respective customers, members, obligations to provide access to its respective customers, members,
or other constituents. This section describes requirements in the or other constituents. This section describes requirements in the
manner specified in Section 1.3. manner specified in Section 1.3.
3.1 Base Functions 3.1. Base Functions
This section describes basic directory service protocol requirements This section describes basic directory service protocol requirements
for Internet registries. Additional requirements, specific to domain for Internet registries. Additional requirements, specific to domain
registries, are described in Domain Specific Functions (Section 3.2). registries, are described in Domain Specific Functions (Section 3.2).
3.1.1 Mining Prevention 3.1.1. Mining Prevention
In order to prevent the inappropriate acquisition of data from an In order to prevent the inappropriate acquisition of data from an
Internet registry's directory service, many servers will limit the Internet registry's directory service, many servers will limit the
amount of data that may be returned in a fixed time period from a amount of data that may be returned in a fixed time period from a
server to a client. This will most likely be especially true for server to a client. This will most likely be especially true for
anonymous access uses (see Section 3.1.4). anonymous access uses (see Section 3.1.4).
The limits placed on differing types of data or applied depending The limits placed on differing types of data or applied depending
upon access status will most likely differ from server to server upon access status will most likely differ from server to server
based on policy and need. Support for varying service models in the based on policy and need. Support for varying service models in the
effort to limit data and prevent data mining may or may not have a effort to limit data and prevent data mining may or may not have a
direct impact on the client-to-server protocol. direct impact on the client-to-server protocol.
3.1.2 Minimal Technical Reinvention 3.1.2. Minimal Technical Reinvention
The protocol MUST NOT employ unique technology solutions for all The protocol MUST NOT employ unique technology solutions for all
aspects and layers above the network and transport layers and SHOULD aspects and layers above the network and transport layers. The
make use of existing technology standards where applicable. The protocol SHOULD make use of existing technology standards where
protocol MUST employ the use of network and transport layer standards applicable. The protocol MUST employ the use of network and
as defined by the Internet Engineering Task Force. The protocol MUST transport layer standards as defined by the Internet Engineering Task
define one or more congestion-aware transport mechanisms for Force. The protocol MUST define one or more congestion-aware
mandatory implementation. transport mechanisms for mandatory implementation.
3.1.3 Standard and Extensible Schemas 3.1.3. Standard and Extensible Schemas
3.1.3.1 Protocol Requirement 3.1.3.1. Protocol Requirement
The protocol MUST contain standard schemas for the exchange of data The protocol MUST contain standard schemas for the exchange of data
needed to implement the functionality in this document. In addition, needed to implement the functionality in this document. In addition,
there MUST be a means to allow the use of schemas not defined by the there MUST be a means to allow the use of schemas not defined by the
needs of this document. Both types of schemas MUST use the same needs of this document. Both types of schemas MUST use the same
schema language. The schemas MUST be able to express data elements schema language. The schemas MUST be able to express data elements
with identifying tags for the purpose of localization of the meaning with identifying tags for the purpose of localization of the meaning
of the identifying tags. of the identifying tags.
3.1.3.2 Service Description 3.1.3.2. Service Description
The client-to-server protocol must define a standard set of data The client-to-server protocol must define a standard set of data
structures or schemas to be used when exchanging information. It must structures or schemas to be used when exchanging information. It
also poses the ability to allow for the use of newer data structures must also poses the ability to allow for the use of newer data
that are currently nor foreseen by this specification. In both cases, structures that are currently not foreseen by this specification. In
the description and specification of both types of data structures or both cases, the description and specification of both types of data
schemas must be done in the same way (i.e. the same schema language). structures or schemas must be done in the same way (i.e., the same
schema language).
The schemas must also be capable of "tagging" data with a unique The schemas must also be capable of "tagging" data with a unique
identifier. This identifier can then be used to localize the name of identifier. This identifier can then be used to localize the name of
that type of data. For instance, a piece of data may have the value that type of data. For instance, a piece of data may have the value
"Bob" and its type identified with the number "5.1". Client software "Bob" and its type identified with the number "5.1". Client software
could use this to display "Name: Bob" in an English locale or could use this to display "Name: Bob" in an English locale or
"Nombre: Bob" in a Spanish locale. "Nombre: Bob" in a Spanish locale.
3.1.4 Level of Access 3.1.4. Level of Access
3.1.4.1 Protocol Requirement 3.1.4.1. Protocol Requirement
The protocol MUST NOT prohibit an operator from granularly assigning The protocol MUST NOT prohibit an operator from granularly assigning
multiple types of access to data according to the policies of the multiple types of access to data according to the policies of the
operator. The protocol MUST provide an authentication mechanism and operator. The protocol MUST provide an authentication mechanism and
MUST NOT prohibit an operator from granting types of access based on MUST NOT prohibit an operator from granting types of access based on
authentication. authentication.
The protocol MUST provide an anonymous access mechanism that may be The protocol MUST provide an anonymous access mechanism that may be
turned on or off based on the policy of an operator. turned on or off based on the policy of an operator.
3.1.4.2 Service Description 3.1.4.2. Service Description
Server operators will offer varying degrees of access depending on Server operators will offer varying degrees of access depending on
policy and need. The following are some examples: policy and need. The following are some examples:
o users will be allowed access only to data for which they have a o users will be allowed access only to data for which they have a
relationship relationship
o unauthenticated or anonymous access status may not yield any o unauthenticated or anonymous access status may not yield any
contact information contact information
o full access may be granted to a special group of authenticated o full access may be granted to a special group of authenticated
users users
The types of access allowed by a server will most likely vary from The types of access allowed by a server will most likely vary from
one operator to the next. one operator to the next.
3.1.5 Client Processing 3.1.5. Client Processing
The protocol MUST be capable of allowing machine parsable requests The protocol MUST be capable of allowing machine parsable requests
and responses. and 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
3.1.7.1 Protocol Requirement 3.1.7.1. Protocol Requirement
The protocol MUST NOT require the aggregation of data to a central The protocol MUST NOT require the aggregation of data to a central
repository, server, or entity. The protocol MUST NOT require repository, server, or entity. The protocol MUST NOT require
aggregation of data indexes or hints to a central repository, server, aggregation of data indexes or hints to a central repository, server,
or entity. or entity.
3.1.7.2 Service Description 3.1.7.2. Service Description
Some server operators may have a need to coordinate service in a mesh Some server operators may have a need to coordinate service in a mesh
or some other framework with other server operators. However, the or some other framework with other server operators. However, the
ability to operate a CRISP compliant server must not require this. ability to operate a CRISP compliant server must not require this.
3.1.8 Query of Access Permission 3.1.8. Query of Access Permission
3.1.8.1 Protocol Requirement 3.1.8.1. Protocol Requirement
The protocol MUST provide a mechanism allowing a client to determine The protocol MUST provide a mechanism allowing a client to determine
if a query will be denied before the query is submitted according to if a query will be denied before the query is submitted according to
the appropriate policies of the operator. the appropriate policies of the operator.
3.1.8.2 Service Description 3.1.8.2. Service Description
Because usage scenarios will differ depending on both policy and type Because usage scenarios will differ depending on both policy and type
of service, some server operators may want to provide the ability for of service, some server operators may want to provide the ability for
a client to predetermine its ability to retrieve data from a query. a client to predetermine its ability to retrieve data from a query.
However, some operators will not allow this for security reasons, However, some operators will not allow this for security reasons,
policy restrictions, or other matters. policy restrictions, or other matters.
3.1.9 Authentication Distribution 3.1.9. Authentication Distribution
3.1.9.1 Protocol Requirement 3.1.9.1. Protocol Requirement
The protocol MUST NOT require any Internet registry to participate in The protocol MUST NOT require any Internet registry to participate in
any authentication system. The protocol MUST NOT prohibit the any authentication system. The protocol MUST NOT prohibit the
participation by an Internet registry in federated, distributed participation by an Internet registry in federated, distributed
authentication systems. authentication systems.
3.1.9.2 Service Description 3.1.9.2. Service Description
Some server operators may have a need to delegate authentication to Some server operators may have a need to delegate authentication to
another party or participate in a system where authentication another party or participate in a system where authentication
information is distributed. However, the ability to operate a CRISP information is distributed. However, the ability to operate a CRISP
compliant server must not require this. compliant server must not require this.
3.1.10 Base Error Responses 3.1.10. Base Error Responses
The protocol MUST be capable of returning the following types of The protocol MUST be capable of returning the following types of
non-result or error responses to all lookups and searches: non-result or error responses to all lookups and searches:
o permission denied - a response indicating that the search or o permission denied - a response indicating that the search or
lookup has failed due to insufficient authorization. lookup has failed due to insufficient authorization.
o not found - the desired results do not exist. o not found - the desired results do not exist.
o insufficient resources - the search or lookup requires resources o insufficient resources - the search or lookup requires resources
that cannot be allocated. that cannot be allocated.
3.1.11 Query Distribution 3.1.11. Query Distribution
3.1.11.1 Protocol Requirement 3.1.11.1. Protocol Requirement
The protocol MUST NOT prohibit a server from participating in a query The protocol MUST NOT prohibit a server from participating in a query
distribution system. distribution system.
3.1.11.2 Service Description 3.1.11.2. Service Description
For lookups and searches requiring distribution of queries, the For lookups and searches requiring distribution of queries, the
client must be allowed to distribute these queries among the client must be allowed to distribute these queries among the
participants in an established mesh of server operators. It is not a participants in an established mesh of server operators. It is not a
requirement that the protocol enable the discovery of servers, but requirement that the protocol enable the discovery of servers, but
cooperating servers should be able to intelligently handle cooperating servers should be able to intelligently handle
distribution with its established mesh. Individual server operators distribution with its established mesh. Individual server operators
will respond to all queries received according to their policies for will respond to all queries received according to their policies for
authentication, privacy, and performance. authentication, privacy, and performance.
However, the ability to operate a CRISP compliant server must not However, the ability to operate a CRISP compliant server must not
require the participation in any query distribution system. require the participation in any query distribution system.
3.1.12 Protocol and Schema Versioning 3.1.12. Protocol and Schema Versioning
3.1.12.1 Protocol Requirements 3.1.12.1. Protocol Requirements
The protocol MUST provide a means by which the end-systems can either The protocol MUST provide a means by which the end-systems can either
identify or negotiate over the protocol version to be used for any identify or negotiate over the protocol version to be used for any
query or set of queries. query or set of queries.
All resource-specific schema MUST provide a version identifier All resource-specific schema MUST provide a version identifier
attribute which uniquely and unambiguously identifies the version of attribute which uniquely and unambiguously identifies the version of
the schema being returned in the answer set to a query. the schema being returned in the answer set to a query.
3.1.12.2 Service Description 3.1.12.2. Service Description
The service should allow end-systems using different protocol The service should allow end-systems using different protocol
versions to fallback to a mutually supported protocol version. If versions to fallback to a mutually supported protocol version. If
this is not possible, the service must provide a meaningful error this is not possible, the service must provide a meaningful error
which indicates that this is the specific case. which indicates that this is the specific case.
The service must suggest negotiation and/or recovery mechanisms for The service must suggest negotiation and/or recovery mechanisms for
clients to use when an unknown schema version is received. clients to use when an unknown schema version is received.
3.1.13 Relay Bag 3.1.13. Relay Bag
The term "bag" in this section describes a flexible container which The term "bag" in this section describes a flexible container which
may contain unspecified data. may contain unspecified data.
3.1.13.1 Protocol Requirement 3.1.13.1. Protocol Requirement
When issuing a referral, the protocol MUST be capable of supplying a When issuing a referral, the protocol MUST be capable of supplying a
relay bag from the server to the client, and the protocol MUST be relay bag from the server to the client, and the protocol MUST be
capable of allowing the client to submit this relay bag with a query capable of allowing the client to submit this relay bag with a query
to the referred server. The use of the relay bag MUST be OPTIONAL. to the referred server. The use of the relay bag MUST be OPTIONAL.
The protocol MUST NOT make any assumptions regarding the contents of The protocol MUST NOT make any assumptions regarding the contents of
the relay bag, but the relay bag MUST be described using the schema the relay bag, but the relay bag MUST be described using the schema
language of the protocol. language of the protocol.
The protocol MUST provide different error messages to indicate The protocol MUST provide different error messages to indicate
skipping to change at page 15, line 5 skipping to change at page 13, line 33
data that means processing is refused at this time (transient data that means processing is refused at this time (transient
failure). failure).
There MUST be no more than one bag per referral. The protocol MUST There MUST be no more than one bag per referral. The protocol MUST
NOT make an association or linkage between successive bags in a NOT make an association or linkage between successive bags in a
referral chain. referral chain.
The client MUST pass the bag as part of any query made to a referrant The client MUST pass the bag as part of any query made to a referrant
server as a result of a referral. server as a result of a referral.
3.1.13.2 Service Description 3.1.13.2. Service Description
In some models where service coordination among participating server In some models where service coordination among participating server
operators is utilized, there might be needs to allow a referring operators is utilized, there might be needs to allow a referring
server to pass operator-to-operator coordination data along with the server to pass operator-to-operator coordination data along with the
referral to the referent server. Such needs might be auditing or referral to the referent server. Such needs might be auditing or
tracking. This feature requirement allows a server to pass to the tracking. This feature requirement allows a server to pass to the
client a flexible container of unspecified data ("bag") that the client a flexible container of unspecified data ("bag") that the
client should pass to the referent server. The bag has no meaning to client should pass to the referent server. The bag has no meaning to
the client. the client.
3.1.14 Privacy Labels 3.1.14. Privacy Labels
3.1.14.1 Protocol Requirement 3.1.14.1. Protocol Requirement
When a value in an answer to a query is given, the protocol MUST be When a value in an answer to a query is given, the protocol MUST be
capable of tagging the value with the following labels: capable of tagging the value with the following labels:
1. do not redistribute 1. do not redistribute
2. special access granted 2. special access granted
The protocol MAY define other values for this purpose, but MUST The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum. The protocol MUST be define values defined above at a minimum. The protocol MUST be
capable of attaching these labels concurrently. capable of attaching these labels concurrently.
3.1.14.2 Service Description 3.1.14.2. Service Description
Internet registries will have varying policies regarding the access Internet registries will have varying policies regarding the access
to their data. Some registries may grant certain classes of users to their data. Some registries may grant certain classes of users
with access to data that would not normally be given to most users. with access to data that would not normally be given to most users.
In these cases, registries may want to tag the values in these In these cases, registries may want to tag the values in these
entries with labels specifying the responsibilities accompanying entries with labels specifying the responsibilities accompanying
these special user rights. these special user rights.
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 server operator is required to specified separately. No compliant server operator is required to
support the functions required by every registry type. support the functions required by every registry type.
3.2.1 Lookups 3.2.1. Lookups
3.2.1.1 Protocol Requirement 3.2.1.1. Protocol Requirement
The protocol MUST contain the following lookup functions: The protocol MUST contain the following lookup functions:
1. Contact lookup given a unique reference to a contact of a 1. Contact lookup given a unique reference to a contact of a
resource. resource.
2. Nameserver lookup given a fully-qualified host name or IP address 2. Nameserver lookup given a fully-qualified host name or IP address
of a nameserver. of a nameserver.
3. Domain lookup given a fully-qualified domain name. 3. Domain lookup given a fully-qualified domain name.
See Section 3.2.3 for the requirements regarding the expected return See Section 3.2.3 for the requirements regarding the expected return
values. values.
3.2.1.2 Service Description 3.2.1.2. Service Description
These lookups are all single index queries and should produce zero or These lookups are all single index queries and should produce zero or
only one entity. only one entity.
Depending on the policy and need of an Internet registry, a server Depending on the policy and need of an Internet registry, a server
operator may not allow all or any of these lookups to return part or operator may not allow all or any of these lookups to return part or
all of the information. See Section 3.2.3. all of the information. See Section 3.2.3.
3.2.2 Searches 3.2.2. Searches
3.2.2.1 Protocol Requirement 3.2.2.1. Protocol Requirement
The protocol MUST contain the following search functions: The protocol MUST contain the following search functions:
1. Domain name search given an exact match or reasonable subset of a 1. Domain name search given an exact match or reasonable subset of a
name. This search SHOULD allow for parameters and qualifiers name. This search SHOULD allow for parameters and qualifiers
designed to allow better matching of internationalized domain designed to allow better matching of internationalized domain
names and SHOULD allow for both exact and partial matching within names and SHOULD allow for both exact and partial matching within
the limits of internationalized domain names. This search SHOULD the limits of internationalized domain names. This search SHOULD
NOT require special transformations of internationalized domain NOT require special transformations of internationalized domain
names to accommodate this search. This search MUST provide a names to accommodate this search. This search MUST provide a
means to narrow the search by names delegated under a particular means to narrow the search by names delegated under a particular
TLD. TLD.
2. Domain registrant search by either exact name or partial name 2. Domain registrant search by either exact name or partial name
match with the ability to narrow the search to registrants of a match with the ability to narrow the search to registrants of a
particular TLD. particular TLD.
3. Domains hosted by a nameserver given the fully-qualified host 3. Domains hosted by a nameserver given the fully-qualified host name
name or IP address of a nameserver. or IP address of a nameserver.
See Section 3.2.3 for the requirements regarding the expected return See Section 3.2.3 for the requirements regarding the expected return
values. values.
3.2.2.2 Service Description 3.2.2.2. Service Description
Depending on the policy and need of an Internet registry, a server Depending on the policy and need of an Internet registry, a server
operator may not allow all or any of these searches to return part or operator may not allow all or any of these searches to return part or
all of the information. See Section 3.1.4. Access to information all of the information. See Section 3.1.4. Access to information
resulting from these searches may also be limited, depending on resulting from these searches may also be limited, depending on
policy, by quantity. Section 3.2.5 describes these types of policy, by quantity. Section 3.2.5 describes these types of
restrictions. restrictions.
Some Internet registries may also be participating in a query Some Internet registries may also be participating in a query
distribution system. See Section 3.1.11. distribution system. See Section 3.1.11.
3.2.3 Information Sets 3.2.3. Information Sets
3.2.3.1 Protocol Requirements 3.2.3.1. Protocol Requirements
The data sets for contacts, nameservers, and domains MUST be able to The data sets for contacts, nameservers, and domains MUST be able to
express and represent the attributes and allowable values of express and represent the attributes and allowable values of
registration requests in domain registration and provisioning registration requests in domain registration and provisioning
protocols. protocols.
The schema MUST be capable of expressing the following information The schema MUST be capable of expressing the following information
for domains: for domains:
o activation status o activation status
skipping to change at page 17, line 44 skipping to change at page 16, line 35
o registry delegating the domain o registry delegating the domain
o registrar for the domain o registrar for the domain
The data set for domains MUST be able to express arbitrary textual The data set for domains MUST be able to express arbitrary textual
information for extensions on an individual operator basis. Examples information for extensions on an individual operator basis. Examples
of such information are license agreements, authorized use policies, of such information are license agreements, authorized use policies,
extended status notifications, marketing/for sale notices, and URI extended status notifications, marketing/for sale notices, and URI
references to other sources. references to other sources.
3.2.3.2 Service Description 3.2.3.2. Service Description
It is not expected that every Internet registry supply all of the It is not expected that every Internet registry supply all of the
information spelled out above, however the schemas employed by the information spelled out above, however the schemas employed by the
protocol must be capable of expressing this information should a protocol must be capable of expressing this information should a
registry need to provide it. registry need to provide it.
The following sections describe requirements relative to the use of The following sections describe requirements relative to the use of
schemas with respect to individual registry need and policy: schemas with respect to individual registry need and policy:
o Section 3.2.8 o Section 3.2.8
o Section 3.2.5 o Section 3.2.5
o Section 3.1.4 o Section 3.1.4
o Section 3.1.1 o Section 3.1.1
3.2.4 Serialization Support 3.2.4. Serialization Support
The schemas used by the protocol SHOULD be capable of off-line The schemas used by the protocol SHOULD be capable of off-line
serialization serialization
Off-line serialization allows for implementation independent Off-line serialization allows for implementation independent
operations such as backup and recovery, load-balancing, etc. This operations such as backup and recovery, load-balancing, etc. This
MAY also make possible, in whole or in part, data escrow capabilities MAY also make possible, in whole or in part, data escrow capabilities
and other usages, however such usages are out of the scope of this and other usages, however such usages are out of the scope of this
document. document.
3.2.5 Result Set Limits 3.2.5. Result Set Limits
3.2.5.1 Protocol Requirement 3.2.5.1. Protocol Requirement
The protocol MUST contain a feature, used at the discretion of a The protocol MUST contain a feature, used at the discretion of a
server operator, to allow a server to express to a client a limit on server operator, to allow a server to express to a client a limit on
the number of results from searches and lookups. When returning the number of results from searches and lookups. When returning
result sets, the protocol MUST be able to make the following result sets, the protocol MUST be able to make the following
distinctions: distinctions:
1. an empty result set. 1. an empty result set.
2. a result set truncated for the purpose of improving performance 2. a result set truncated for the purpose of improving performance
bottlenecks. bottlenecks.
3. a result set truncated to comply with Section 3.1.1 3. a result set truncated to comply with Section 3.1.1
3.2.5.2 Service Description 3.2.5.2. Service Description
Client software will operate more usefully if it can understand Client software will operate more usefully if it can understand
reasons for the truncation of result sets. Of course, some Internet reasons for the truncation of result sets. Of course, some Internet
registries may not be able to expose their policies for the limiting registries may not be able to expose their policies for the limiting
of result sets, but, when it is possible, clients will have a better of result sets, but, when it is possible, clients will have a better
operational view. This may eliminate re-queries and other repeated operational view. This may eliminate re-queries and other repeated
actions that are not desirable. actions that are not desirable.
3.2.6 DNS Delegation Referencing 3.2.6. DNS Delegation Referencing
3.2.6.1 Protocol Requirement 3.2.6.1. Protocol Requirement
The protocol MUST use the delegation authority model available in DNS The protocol MUST use the delegation authority model available in DNS
[1] as the primary means for determining the authoritative source for [1] as the primary means for determining the authoritative source for
information regarding domains or any other objects when applicable. information regarding domains or any other objects when applicable.
3.2.6.2 Service Description 3.2.6.2. Service Description
The intent of this requirement is to have clients use the DNS The intent of this requirement is to have clients use the DNS
delegation model to find servers authoritative for resources instead delegation model to find servers authoritative for resources instead
of using a master or central server containing pointer information. of using a master or central server containing pointer information.
In other words, when a resource is naturally mapped by DNS, the In other words, when a resource is naturally mapped by DNS, the
desired behavior is to consult the DNS to find an authoritative desired behavior is to consult the DNS to find an authoritative
server containing information about that resource. Using server containing information about that resource. Using
'example.com', the authoritative server for information about 'example.com', the authoritative server for information about
example.com according to the registrant of that domain may be found example.com according to the registrant of that domain may be found
by querying the DNS zone for example.com. To find the registry by querying the DNS zone for example.com. To find the registry
information for example.com, the DNS zone for com should be queried. information for example.com, the DNS zone for .com should be queried.
There are cases where resources will not naturally map into the DNS There are cases where resources will not naturally map into the DNS
delegation hierarchy. This requirement is not meant to force such a delegation hierarchy. This requirement is not meant to force such a
mapping. mapping.
3.2.7 Distribution for Domain Registry Types 3.2.7. Distribution for Domain Registry Types
3.2.7.1 Protocol Requirement 3.2.7.1. Protocol Requirement
The protocol MUST NOT prohibit the distribution of data to exclude The protocol MUST NOT prohibit the distribution of data to exclude
any of the registry/registrar models stated in Section 2.1.1. The any of the registry/registrar models stated in Section 2.1.1. The
protocol MUST be capable of expressing referrals and entity protocol MUST be capable of expressing referrals and entity
references between the various models described in Section 2.1.1. references between the various models described in Section 2.1.1.
3.2.7.2 Service Description 3.2.7.2. Service Description
Depending on the domain registry/registrar model in use, technical Depending on the domain registry/registrar model in use, technical
data for a domain may only reside in one server while contact data data for a domain may only reside in one server while contact data
for the same domain may only reside in a server operated by a for the same domain may only reside in a server operated by a
separate entity. However, in many uses, this is not the situation. separate entity. However, in many uses, this is not the situation.
Therefore, the service must accommodate for the various registration Therefore, the service must accommodate for the various registration
distribution models of domain registry types described in Section distribution models of domain registry types described in Section
2.1.1 while complying with Section 3.1.7. 2.1.1 while complying with Section 3.1.7.
3.2.8 Data Omission 3.2.8. Data Omission
3.2.8.1 Protocol Requirement 3.2.8.1. Protocol Requirement
When a value in an answer to a query cannot be given due to policy When a value in an answer to a query cannot be given due to policy
constraints, the protocol MUST be capable of expressing the value in constraints, the protocol MUST be capable of expressing the value in
one of three ways: one of three ways:
1. complete omission of the value without explanation 1. complete omission of the value without explanation
2. an indication that the value cannot be given due to insufficient 2. an indication that the value cannot be given due to insufficient
authorization authorization
3. an indication that the value cannot be given due to privacy 3. an indication that the value cannot be given due to privacy
constraints regardless of authorization status constraints regardless of authorization status
The protocol MAY define other values for this purpose, but MUST The protocol MAY define other values for this purpose, but MUST
define values defined above at a minimum. define values defined above at a minimum.
3.2.8.2 Service Description 3.2.8.2. Service Description
Internet registries will have varying constraints regarding their Internet registries will have varying constraints regarding their
ability to expose certain types of data, usually social information. ability to expose certain types of data, usually social information.
Server operators must have the ability to accommodate this need while Server operators must have the ability to accommodate this need while
client software will be more useful when provided with proper client software will be more useful when provided with proper
explanations. Therefore, depending on policy, a server operator has a explanations. Therefore, depending on policy, a server operator has
choice between not returning the data at all, signaling a permission a choice between not returning the data at all, signaling a
error, or indicating a privacy constraint. permission error, or indicating a privacy constraint.
3.2.9 Internationalization 3.2.9. Internationalization
The schema defining domain related resources MUST conform to RFC 2277 The schema defining domain related resources MUST conform to RFC 2277
[2] regarding textual data. In particular, the schema MUST be able [2] regarding textual data. In particular, the schema MUST be able
to indicate the charset and language in use with unstructured textual to indicate the charset and language in use with unstructured textual
data. data.
The protocol MUST be able to support multiple representations of The protocol MUST be able to support multiple representations of
contact data, with these representations complying with the contact data, with these representations complying with the
requirements in Section 3.2.3. The protocol MUST be able to provide requirements in Section 3.2.3. The protocol MUST be able to provide
contact data in UTF-8 and SHOULD be able to provide contact data in contact data in UTF-8 and SHOULD be able to provide contact data in
US-ASCII, other character sets, and capable of specifying the US-ASCII, other character sets, and capable of specifying the
language of the data. language of the data.
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 describes requirements in the manner directory service. This section describes requirements in the manner
specified in Section 1.3. specified in Section 1.3.
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 protocol MUST provide a mechanism capable of authentication. The protocol 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 protocol MUST provide a referral mechanism. references, the protocol MUST provide a referral mechanism.
4.3 Common Referral Mechanism 4.3. Common Referral Mechanism
To distribute queries for search continuations and to issue entity To distribute queries for search continuations and to issue entity
references, the protocol MUST define a common referral scheme and references, the protocol 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
protocol MUST employ structured queries and responses. protocol MUST employ structured queries and responses.
4.5 Existing Schema Language 4.5. Existing Schema Language
To provide structured queries and responses and allow for minimal To provide structured queries and responses and allow for minimal
technological reinvention, the protocol MUST employ a pre-existing technological reinvention, the protocol MUST employ a pre-existing
schema language. schema language.
4.6 Defined Schemas 4.6. Defined Schemas
To provide for machine consumption as well as human consumption, the To provide for machine consumption as well as human consumption, the
protocol MUST define schemas for use by the structured queries and protocol MUST define schemas for use by the structured queries and
responses. responses.
5. Internationalization Considerations 5. Internationalization Considerations
Requirements defined in this document MUST consider the best Requirements defined in this document MUST consider the best
practices spelled out in [2]. practices spelled out in [2].
6. IANA Considerations 6. IANA Considerations
IANA consideration for any service meeting these requirements will IANA consideration for any service meeting these requirements will
depend upon the technologies chosen and MUST be specified by any depend upon the technologies chosen and MUST be specified by any
document describing such a service. document describing such a service.
7. Security Considerations 7. Security Considerations
This document contains requirements for the validation of This document contains requirements for the validation of
authenticated entities and the access of authenticated entities authenticated entities and the access of authenticated entities
compared with the access of non-authenticated entities. This document compared with the access of non-authenticated entities. This
does not define the mechanism for validation of authenticated document does not define the mechanism for validation of
entities. Requirements defined in this document MUST allow for the authenticated entities. Requirements defined in this document MUST
implementation of this mechanism according best common practices. allow for the implementation of this mechanism according best common
practices.
The requirement in Section 3.1.4 must be weighed against other The requirement in Section 3.1.4 must be weighed against other
requirements specifying search or lookup capabilities. requirements specifying search or lookup capabilities.
This document contains requirements for referrals and entity This document contains requirements for referrals and entity
references. Client implementations based on these requirements SHOULD references. Client implementations based on these requirements
take proper care in the safe-guarding of credential information when SHOULD take proper care in the safe-guarding of credential
resolving referrals or entity references according to best common information when resolving referrals or entity references according
practices. to best common practices.
This document contains requirements for the distribution of queries This document contains requirements for the distribution of queries
among a mesh of participating service providers. Protocols proposed among a mesh of participating service providers. Protocols proposed
to meet these requirements must be able to protect against the use of to meet these requirements must be able to protect against the use of
that distribution system as a vector of distributed denial of service that distribution system as a vector of distributed denial of service
attacks or unauthorized data mining. attacks or unauthorized data mining.
Normative References Normative References
[1] Mockapetris, P., "Domain names - implementation and [1] Mockapetris, P., "Domain names - implementation and
skipping to change at page 27, line 10 skipping to change at page 22, line 4
[7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [7] 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.
URIs URIs
[8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm> [8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[9] <http://www.ietf.org/proceedings/01aug/51-40.htm> [9] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[10] <http://www.uwho.verisignlabs.com/ [10] <http://www.uwho.verisignlabs.com/
Final-WhoIsPanel-Aug15-Resume.pdf> Final-WhoIsPanel-Aug15-Resume.pdf>
[11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/ [11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
min_database.html> min_database.html>
[12] <http://www.nanog.org/mtg-0110/lookup.html> [12] <http://www.nanog.org/mtg-0110/lookup.html>
Author's Address
Andrew L. Newton
VeriSign, Inc.
21355 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Appendix A. Glossary Appendix A. Glossary
o TLD: Initials for "top level domain." Referes to domains in DNS o TLD: Initials for "top level domain." Referes to domains in DNS
[1]that are hierarchically at the level just beneath the root. [1]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 contact data: Data containing names and contact information (i.e. o contact 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.
o operational data: Data necessary to the operation of networks and o operational data: Data necessary to the operation of networks and
network related services and items. network related services and items.
o RIR: Initials for "regional Internet registry." o RIR: Initials for "regional Internet registry."
o IRR: Initials for "Internet routing registry." o IRR: Initials for "Internet routing registry."
skipping to change at page 29, line 7 skipping to change at page 24, line 7
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 to of directory service, usually as much as possible, not relevant to
any immediate need. Data mining is often not a practice welcomed any immediate need. Data mining is often not a practice 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 [8]; December 10-15, 2000; San Diego, o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego,
CA, USA CA, USA
o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London,
England England
skipping to change at page 29, line 44 skipping to change at page 24, line 44
o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
Netherlands Netherlands
o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
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://lists.verisignlabs.com/pipermail/ietf-not43/. http://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 Kerr, been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George
Michaelson, and Tim Christensen. Michaelson, and Tim Christensen.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
skipping to change at page 31, line 27 skipping to change at page 25, line 35
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Author's Address
Andrew L. Newton
VeriSign, Inc.
21355 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 are kind, provided that the above copyright notice and this paragraph 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
 End of changes. 

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