draft-ietf-crisp-requirements-02.txt   draft-ietf-crisp-requirements-03.txt 
Network Working Group A. Newton Network Working Group A. Newton
Internet-Draft VeriSign, Inc. Internet-Draft VeriSign, Inc.
Expires: April 30, 2003 October 30, 2002 Expires: August 5, 2003 February 4, 2003
Cross Registry Internet Service Protocol (CRISP) Requirements Cross Registry Internet Service Protocol (CRISP) Requirements
draft-ietf-crisp-requirements-02 draft-ietf-crisp-requirements-03
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 Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents 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 http:// The list of current Internet-Drafts can be accessed at 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 30, 2003. This Internet-Draft will expire on August 5, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. Internet Registry Communities . . . . . . . . . . . . . . 5 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Domain Name System Registries . . . . . . . . . . . . . . 5 1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 5 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4
2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 5 2. Internet Registry Communities . . . . . . . . . . . . . . 6
2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 6 2.1 Domain Name System Registries . . . . . . . . . . . . . . 6
2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 6 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 6 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 6 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Incident Coordination Contact Registries . . . . . . . . . 6 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 7
2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 7 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 7
2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 7
2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 7
2.4.1 Service Providers and Network Operators . . . . . . . . . 7 2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 8
2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 7 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 8 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 8 2.4.1 Service Providers and Network Operators . . . . . . . . . 8
2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 8
2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 8 2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 9
2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 9
3. Functional Requirements . . . . . . . . . . . . . . . . . 9 2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 9 2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 9 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 9 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 9
3. Functional Requirements . . . . . . . . . . . . . . . . . 10
3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 10
3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10
3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 11
3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 10 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 11
3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 10 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 11
3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 10 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 11
3.1.8 Query of Access Levels . . . . . . . . . . . . . . . . . . 11 3.1.8 Query of Access Permission . . . . . . . . . . . . . . . . 12
3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 11 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 12
3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 11 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 12
3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 11 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 13
3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 12 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 13
3.2.1 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . 12 3.2.1 Lookups . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Searches . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Domain Registrant Search . . . . . . . . . . . . . . . . . 12 3.2.3 Serialization Support . . . . . . . . . . . . . . . . . . 15
3.2.4 Domain Information Lookup . . . . . . . . . . . . . . . . 12 3.2.4 Result Set Limits . . . . . . . . . . . . . . . . . . . . 15
3.2.5 Nameserver Search . . . . . . . . . . . . . . . . . . . . 13 3.2.5 DNS Delegation Referencing . . . . . . . . . . . . . . . . 16
3.2.6 Escrow Support . . . . . . . . . . . . . . . . . . . . . . 13 3.2.6 Distribution for Domain Registry Types . . . . . . . . . . 17
3.2.7 Domain Name Search . . . . . . . . . . . . . . . . . . . . 13 3.2.7 Data Omission . . . . . . . . . . . . . . . . . . . . . . 17
3.2.8 Result Set Limits . . . . . . . . . . . . . . . . . . . . 14 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 18
3.2.9 DNS Label Referencing . . . . . . . . . . . . . . . . . . 14 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 18
3.2.10 Distribution for Domain Registry Types . . . . . . . . . . 14 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Feature Requirements . . . . . . . . . . . . . . . . . . . 15 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 18
4.1 Client Authentication . . . . . . . . . . . . . . . . . . 15 4.4 Structured Queries and Responses . . . . . . . . . . . . . 18
4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 18
4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 15 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 18
4.4 Structured Queries and Responses . . . . . . . . . . . . . 15 5. Internationalization Considerations . . . . . . . . . . . 19
4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 20
4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . 21
4.7 Serialization Definition . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Internationalization Considerations . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . 19 B. Outstanding Issues . . . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . 20 C. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . 20 C.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 21 C.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 25
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23 C.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 26
B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . 27
B.2 Working Group . . . . . . . . . . . . . . . . . . . . . . 23
B.3 Contributions . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . 25
1. Background 1. Introduction
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 [4] protocol to include the use of whois traditional use of the whois [4] 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 [3], to fulfill other needs, and other protocols, such as rwhois [3], to fulfill other needs, and
proposals for the use of other technologies such as LDAP [1] and XML. proposals for the use of other technologies such as LDAP [1] and XML.
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 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 C.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 scope of the requirements in this document are also restricted to
access of data from Internet registries. Requirements for
modification, addition, or provisioning of data in Internet
registries are out of scope.
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 [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. For and speak only to the capabilities in the derived technology. For
instance, this document may say that the service "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".)
The scope of the requirements in this document are also restricted to Requirements in this document specifying the capabilities of the
access of data from Internet registries. Requirements for protocol required for proper interaction between a client and a
modification, addition, or provisioning of data in Internet server will be specified with the "MUST/SHOULD" language of RFC2119
registries are out of scope. [8]. This document also contains language relating to the
interaction of a client with multiple servers to form a coherent,
cross-network service. Such service requirements will not be
described using RFC2119 language.
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 [2] and forward lookups (i.e. does not include the IN- use with DNS [2] and forward lookups (i.e. does not include the
ADDR.ARPA or IP6.ARPA domains). These registries have typically IN-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, non- domain registry operator may be a governmental entity,
governmental, non-commercial entity, or a commercial entity. non-governmental, 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 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
skipping to change at page 7, line 44 skipping to change at page 8, line 44
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.2 Intellectual Property Holders 2.4.2 Intellectual Property Holders
Intellectual Property Holders have legal rights to the use of domain A number of parties, such as trademark, service mark and intellectual
names based on copyright and trademark laws of various governments. property holders, individuals, governments and other geopolitical
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.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.
skipping to change at page 8, line 30 skipping to change at page 9, line 30
to IP addresses. Often when trouble occurs in the resolution process to IP addresses. Often when trouble occurs in the resolution process
of DNS, these users trouble shoot system problems with the aid of of DNS, these users trouble shoot system problems with the aid of
information from the directory services of Internet registries. information from the directory services of Internet 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.4.7 Abusive Users
The administrative directory services of Internet registries are
often the target of practices by abusive users. Using information
obtained from Internet registries, abusive users undertake certain
activities that are counter to the acceptable use of the information
as intended by a registry, registrar, or registrant. Many times,
these practices violate law in the jurisdiction of the user,
registry, registrar, or registrant. One example is the use of
Internet registry information for the use of sending unsolicited bulk
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 by other actors on the use of Internet registry directory services by other
actors. These actors include governments, non-governmental policy- actors. These actors include governments, non-governmental
setting bodies, and other non-governmental organizations. policy-setting bodies, 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 makes reference to terms and or other constituents. This section describes requirements in the
definitions declared in Appendix A. This section makes use of the manner specified in Section 1.3.
term "service" to denote the set of functions to be provided by, and
the expected behavior of, software built to meet these requirements
in one or more protocols.
These requirements are for the purpose of designing a technical
specification. The words used in this section are for compliance
with RFC2119 [8], do not reference or specify policy, and speak only
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 directory service protocol requirements
registry service for any of the registries (domain name registries for domain name (Section 2.1) and other (Section 2.2) registries.
(Section 2.1) and other registries (Section 2.2)). Additional Additional requirements, specific to domain registries, are described
requirements, specific to domain registries, are described in Domain in Domain Specific Functions (Section 3.2).
Specific Functions (Section 3.2).
3.1.1 Mining Prevention 3.1.1 Mining Prevention
The service MUST have a mechanism to limit the amount of data that In order to prevent the inappropriate acquisition of data from an
may be accessed. The service MAY have different limits for different Internet registry's directory service, many servers will limit the
types of data, as well as for authenticated and non-authenticated amount of data that may be returned in a fixed time period from a
entities. The service SHOULD be capable of expressing to the client server to a client. This will most likely be especially true for
these access limitations based on queries per session per unit of anonymous access uses (see Section 3.1.4).
time, queries per source IP address per unit of time, and total
queries from all client sessions per unit of time. The service The limits placed on differing types of data or applied depending
SHOULD be able to limit the amount of data based on the above types upon access status will most likely differ from server to server
of limitations. 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
direct impact on the client-to-server protocol.
Section 3.2.4 also contains protocol requirements which are relevant
to client/server interaction in certain domain registry service
models.
3.1.2 Minimal Technical Reinvention 3.1.2 Minimal Technical Reinvention
The service 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 of the aspects and layers above the network and transport layers and SHOULD
total service solution and SHOULD make use of existing technology make use of existing technology standards where applicable. The
standards where applicable. The service MUST employ the use of protocol MUST employ the use of network and transport layer standards
network and transport layer standards as defined by the Internet as defined by the Internet Engineering Task Force. The protocol MUST
Engineering Task Force. The service MUST define one or more define one or more transport mechanisms for mandatory implementation.
transport mechanisms for mandatory implementation.
3.1.3 Standard and Extensible Schemas 3.1.3 Standard and Extensible Schemas
The service MUST define 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 with identifying tags for the purpose of localization of the meaning
internationalized data element labels of the identifying tags.
3.1.4 Level of Access 3.1.4 Level of Access
The service MUST allow the classification of data as being either 3.1.4.1 Protocol Requirement
privileged or non-privileged, for the purpose of restricting access
to privileged data. Note that this requirement makes no assumption
or prescription as to what data (social or operational) might be
considered privileged, but merely provides the ability to make the
classification as necessary.
The service MUST be capable of serving both privileged and non- The protocol MUST NOT prohibit an operator from granularly assigning
privileged data. multiple types of access to data according to the policies of the
operator. The protocol MUST provide an authentication mechanism and
MUST NOT prohibit an operator from granting types of access based on
authentication.
The service MUST be capable of authenticating privileged entities and The protocol MUST provide an anonymous access mechanism that may be
ensuring that only those entities have access to both privileged and turned on or off based on the policy of an operator.
non-privileged data.
The service MUST be capable of providing access to non-privileged 3.1.4.2 Service Description
data without requiring authentication of any type (i.e. anonymous
access). Server operators will offer varying degrees of access depending on
policy and need. The following are some examples:
o users will be allowed access only to data for which they have a
relationship
o unauthenticated or anonymous access status may not yield any
contact information
o full access may be granted to a special group of authenticated
users
The types of access allowed by a server will most likely vary from
one operator to the next.
3.1.5 Client Processing 3.1.5 Client Processing
The service MUST be capable of allowing machine parsable requests and The protocol MUST be capable of allowing machine parsable requests
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
The service MUST be decentralized in design and principle and MUST 3.1.7.1 Protocol Requirement
NOT require the aggregation of data to a central repository, server,
or entity. The service MAY allow for the optional aggregation of
data indexes or hints. The service MUST NOT require aggregation of
data indexes or hints.
3.1.8 Query of Access Levels The protocol MUST NOT require the aggregation of data to a central
repository, server, or entity. The protocol MUST NOT require
aggregation of data indexes or hints to a central repository, server,
or entity.
If a query cannot yield a valid response due to insufficient 3.1.7.2 Service Description
permissions, the service MUST provide the client with an error
response indicating this condition. The service SHOULD NOT provide a
mechanism allowing a client to determine if a query will be denied
before the query is submitted.
It is the intent of this requirement for clients to learn of Some server operators may have a need to coordinate service in a mesh
inadequate permission status for a query only after the query has or some other framework with other server operators. However, the
been submitted. Operating modes allowing a client to predetermine ability to operate a CRISP compliant server must not require this.
the queries that will or will not be denied are not encouraged for
security considerations. 3.1.8 Query of Access Permission
3.1.8.1 Protocol Requirement
The protocol MUST provide a mechanism allowing a client to determine
if a query will be denied before the query is submitted according to
the appropriate policies of the operator.
3.1.8.2 Service Description
Because usage scenarios will differ depending on both policy and type
of service, some server operators may want to provide the ability for
a client to predetermine its ability to retrieve data from a query.
However, some operators will not allow this for security reasons,
policy restrictions, or other matters.
3.1.9 Authentication Distribution 3.1.9 Authentication Distribution
The service MUST NOT require any Internet registries to participate 3.1.9.1 Protocol Requirement
in any particular distributed authentication system. The service
SHOULD allow the participation by an Internet registry in distributed The protocol MUST NOT require any Internet registry to participate in
authentication by many centralized authorities. any authentication system. The protocol MUST NOT prohibit the
participation by an Internet registry in federated, distributed
authentication systems.
3.1.9.2 Service Description
Some server operators may have a need to delegate authentication to
another party or participate in a system where authentication
information is distributed. However, the ability to operate a CRISP
compliant server must not require this.
3.1.10 Base Error Responses 3.1.10 Base Error Responses
The service MUST be capable of returning the following types of non- The protocol MUST be capable of returning the following types of
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
The protocol MUST NOT prohibit a server from participating in a query
distribution system.
3.1.11.2 Service Description
For lookups and searches requiring distribution of queries, the For lookups and searches requiring distribution of queries, the
service MUST be capable of distributing these queries among the client must be allowed to distribute these queries among the
participants in an established mesh of service operators. It is not participants in an established mesh of server operators. It is not a
a requirement that the service enable the discovery of service requirement that the protocol enable the discovery of servers, but
operators, but the service should be able to intelligently handle cooperating servers should be able to intelligently handle
distribution with its established mesh. Individual service 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
require the participation in any query distribution system.
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 server operator 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 Lookups
The service MUST allow access to social data of contact entities 3.2.1.1 Protocol Requirement
given a unique reference to the contact entity. The contact
information set MUST be able to express and represent the attributes
and allowable values of contact registration requests in domain
registration and provisioning protocols.
3.2.2 Nameserver Lookup The protocol MUST contain the following lookup functions:
The service MUST allow access to operational and social data of a 1. Contact lookup given a unique reference to a contact of a
nameserver given the fully-qualified host name or IP address of a resource.
nameserver. The host information set MUST be able to express and
represent the attributes and allowable values of nameservers in
domain registration and provisioning protocols.
3.2.3 Domain Registrant Search 2. Nameserver lookup given a fully-qualified host name or IP address
of a nameserver.
The service MUST provide the capability of searching for registrants 3. Domain lookup given a fully-qualified domain name. The protocol
by exact name match or a reasonable name subset. This search must MUST be capable of supplying the following information relevant
comply with Section 3.2.8. to the domain for this lookup:
The service MUST provide a mechanism to distribute this search across * activation status
all applicable domain registries and registrars. The service SHOULD
have a means to narrow the scope of a search to a specific TLD. The
service MUST be able to specify to the client an empty result set
should the search yield no results.
3.2.4 Domain Information Lookup * registrant
The service MUST provide access to operational and social data * nameservers
specific to a domain given the domain's fully qualified name (FQDN).
The service MUST be capable of supplying the following information
for this lookup:
o activation status * technical, billing or other contacts
o registrant name and contact data * registry delegating the domain
o hosting nameservers * registrar for the domain
o technical, billing or other entity types associated with the
domain and their relevant contact data, if any exist
o the name of or a reference to the registry delegating the domain The data set for the domain MUST be able to express arbitrary
textual information for extensions on an individual operator
basis. Examples of such information are license agreements,
authorized use policies, extended status notifications,
marketing/for sale notices, and URI references to other sources.
o the name of or a reference to the registrar for the domain, if one The data sets for contacts, nameservers, and domains MUST be able to
exists express and represent the attributes and allowable values of
registration requests in domain registration and provisioning
protocols.
The domain information set MUST be able to express and represent the 3.2.1.2 Service Description
attributes and allowable values of domain registration requests in
domain registration and provisioning protocols.
3.2.5 Nameserver Search These lookups are all single index queries and should produce zero or
only one result.
The service MAY allow the ability to list all domains hosted by a Depending on the policy and need of an Internet registry, a server
specific nameserver given the fully-qualified host name or IP operator may not allow all or any of these lookups to return part or
address, if applicable, of the nameserver. The service MAY provide a all of the information. See Section 3.1.4.
mechanism to distribute this search across all applicable domain
registries and registrars.
3.2.6 Escrow Support 3.2.2 Searches
The service MUST provide a means to escrow data of domain registrars 3.2.2.1 Protocol Requirement
to an escrow entity using a common schema. This escrow capability
SHOULD be "off-line" and "out-of-band" from the normal operations of
the service.
3.2.7 Domain Name Search The protocol MUST contain the following search functions:
The service MUST allow searching for domains by exact name match or a 1. Domain name search given an exact match or reasonable subset of a
reasonable subset of a domain name. This search SHOULD allow for name. This search SHOULD allow for parameters and qualifiers
parameters and qualifiers designed to allow better matching of designed to allow better matching of internationalized domain
internationalized domain names and SHOULD allow for both exact and names and SHOULD allow for both exact and partial matching within
partial matching within the limits of internationalized domain names. the limits of internationalized domain names. This search SHOULD
The service SHOULD NOT require special transformations of NOT require special transformations of internationalized domain
internationalized domain names to accommodate this search. This names to accommodate this search. This search MUST provide a
search MUST comply with Section 3.2.8. means to narrow the search by names delegated under a particular
TLD.
The service MUST provide a mechanism to distribute this search across 2. Domain registrant search by either exact name or partial name
all applicable domain registries and registrars. There should be a match with the ability to narrow the search to registrants of a
means to narrow this search based on a TLD. particular TLD.
The search mechanism SHOULD provide for differences in domain names 3. Domains hosted by a nameserver given the fully-qualified host
between the native representation and the canonical form existing in name or IP address of a nameserver.
the registry.
3.2.8 Result Set Limits The data sets for contacts, nameservers, and domains MUST be able to
express and represent the attributes and allowable values of
registration requests in domain registration and provisioning
protocols. The data set for domains MUST be capable of supplying the
values specified in Section 3.2.1.
The service MAY provide limits to the number of results from searches 3.2.2.2 Service Description
and lookups to improve performance bottlenecks or comply with Section
3.1.1. The service MUST be capable of providing to the client an
indication that a result set has been truncated or limited. The
service MUST be capable of distinguishing the cause of this condition
as either a mechanism to improve performance bottlenecks, as
specified above, or a means of compliance with Section 3.1.1.
3.2.9 DNS Label Referencing 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
all of the information. See Section 3.1.4. Access to information
resulting from these searches may also be limited, depending on
policy, by quantity. Section 3.2.4 describes these types of
restrictions.
The service MUST use DNS [2] to determine the authoritative source of Some Internet registries may also be participating in a query
information about domain names. It is the intention of this distribution system. See Section 3.1.11.
requirement that a client be able to determine via DNS and query the
servers or set of servers of the domain registry delegating the
domain name, the domain registrar responsible for registering the
domain name if one is applicable, and the domain registrant of the
domain name. The service SHOULD provide procedures or mechanisms to
allow this determination if it cannot be done using DNS. This allows
the service to operate when an operator chooses not to take advantage
of DNS label referencing and during periods of transient or erroneous
state of DNS configuration.
3.2.10 Distribution for Domain Registry Types 3.2.3 Serialization Support
The service MUST allow for the various registration distribution The schemas used by the protocol SHOULD be capable of off-line
models of domain registry types described in Section 2.1.1 while serialization
complying with Section 3.1.7.
Off-line serialization allows for implementation independent
operations such as backup and recovery, load-balancing, etc. This
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
document.
3.2.4 Result Set Limits
3.2.4.1 Protocol Requirement
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
the number of results from searches and lookups. When returning
result sets, the protocol MUST be able to make the following
distinctions:
1. an empty result set.
2. a result set truncated for the purpose of improving performance
bottlenecks.
3. a result set truncated to comply with Section 3.1.1
3.2.4.2 Service Description
Client software will operate more usefully if it can understand
reasons for the truncation of result sets. Of course, some Internet
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
operational view. This may eliminate re-queries and other repeated
actions that are not desirable.
3.2.5 DNS Delegation Referencing
3.2.5.1 Protocol Requirement
The protocol MUST use the delegation authority model available in DNS
[2] as the primary means for determining the authoritative source for
information regarding domains or any other objects when applicable.
3.2.5.2 Service Description
The intent of this requirement is to have clients use the DNS
delegation model to find servers authoritative for resources instead
of using a master or central server containing pointer information.
In other words, when a resource is naturally mapped by DNS, the
desired behavior is to consult the DNS to find an authoritative
server containing information about that resource. Using
'example.com', the authoritative server for information about
example.com according to the registrant of that domain may be found
by querying the DNS zone for example.com. To find the registry
information for example.com, the DNS zone for com should be queried.
There are cases where resources will not naturally map into the DNS
delegation hierarchy. This requirement is not meant to force such a
mapping.
3.2.6 Distribution for Domain Registry Types
3.2.6.1 Protocol Requirement
The protocol MUST NOT prohibit the distribution of data to exclude
any of the registry/registrar models stated in Section 2.1.1. The
protocol MUST be capable of expressing referrals and entity
references between the various models described in Section 2.1.1.
3.2.6.2 Service Description
Depending on the domain registry/registrar model in use, technical
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
separate entity. However, in manmy uses, this is not the situation.
Therefore, the service must accommodate for the various registration
distribution models of domain registry types described in Section
2.1.1 while complying with Section 3.1.7.
3.2.7 Data Omission
3.2.7.1 Protocol Requirement
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
no less than one of three ways:
1. complete omission of the value without explanation
2. an indication that the value cannot be given due to insufficient
authorization
3. an indication that the value cannot be given due to privacy
constraints regardless of authorization status
3.2.7.2 Service Description
Internet registries will have varying constraints regarding their
ability to expose certain types of data, usually social information.
Server operators must have the ability to accommodate this need while
client software will be more useful when provided with proper
explanations. Therefore, depending on policy, a server operator has
a choice between not returning the data at all, signaling a
permission error, or indicating a privacy constraint.
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 describes requirements in the manner
definitions declared in Appendix A . This section uses the term specified in Section 1.3.
"service" to denote the set of features to be provided by, and the
expected behavior of, software built to meet these requirements in
one or more protocols.
These requirements are for the purpose of designing a technical
specification. The words used in this section are for compliance
with RFC2119 [8], do not reference or specify policy, and speak only
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 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 service 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 service 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
service 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 service 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
service MUST define schemas for use by the structured queries and protocol MUST define schemas for use by the structured queries and
responses. responses.
4.7 Serialization Definition
To provide for data escrow and allow for minimal technological
reinvention, the service MUST employ a pre-existing serialization
specification.
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 [6]. practices spelled out in [6].
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.
skipping to change at page 19, line 18 skipping to change at page 21, line 18
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 compared with the access of non-authenticated entities. This
document does not define the mechanism for validation of document does not define the mechanism for validation of
authenticated entities. Requirements defined in this document MUST authenticated entities. Requirements defined in this document MUST
allow for the implementation of this mechanism according best common allow for the implementation of this mechanism according best common
practices. 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.
In addition, this document contains requirements for referrals and This document contains requirements for referrals and entity
entity references. Client implementations based on these references. Client implementations based on these requirements
requirements SHOULD take proper care in the safe-guarding of SHOULD take proper care in the safe-guarding of credential
credential information when resolving referrals or entity references information when resolving referrals or entity references according
according to best common practices. to best common practices.
This document contains requirements for the distribution of queries
among a mesh of participating service providers. Protocols proposed
to meet these requirements must be able to protect against the use of
that distribution system as a vector of distributed denial of service
attacks or unauthorized data mining.
References References
[1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997. Protocol (v3)", RFC 2251, December 1997.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
skipping to change at page 20, line 37 skipping to change at page 22, line 37
[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- [11] <http://www.uwho.verisignlabs.com/
Resume.pdf> Final-WhoIsPanel-Aug15-Resume.pdf>
[12] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/ [12] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
min_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.
21355 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@ecotroph.net EMail: anewton@ecotroph.net
URI: http://www.verisignlabs.com/ URI: http://zak.ecotroph.net/pea
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
[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
skipping to change at page 22, line 27 skipping to change at page 24, line 27
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."
o authenticated entity: A person, or person acting on behalf of an
organization, who has provided validatable credentials of
identification via client software to the directory service of an
Internet registry.
o non-authenticated entity: A person, or person acting on behalf of
an organization, who has not provided validatable credentials of
identification via client software to the directory service of an
Internet registry.
o privileged entity: A person, or person acting on behalf of an
organization, with authorization to access data.
o non-privileged entity: A person, or person acting on behalf on an
organization, with no authorization to access data.
o privileged data: Data accessible by a privileged entities.
o non-privileged data: Data accessible by privileged entities and
non-privileged entities.
o forward lookup: a DNS lookup where a domain name is resolved to an o forward lookup: a DNS lookup where a domain name is resolved to 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 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. Outstanding Issues
B.1 Forums The following outstanding issues have been discussed and have been
assigned contributors to put forward proposed text.
o Query Distribution and Non-generic Query Referrals - The working
group has discussed issues surrounding query referrals and their
impact on certain classes of servers in a query referral mesh.
Proposals have been suggested for a robust referral mechanism and
a separate transaction token-passing system to provide a means to
solving this class of problems.
o Internationalization - Because of Internationalized Domain Names
(IDN's), it has been suggested that the requirements surrounding
the support for them be further defined and more specific.
Appendix C. Acknowledgements
C.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
o whoisfix BOF of the 51st IETF [10]; August 5-10, 2001; London, o whoisfix BOF of the 51st IETF [10]; August 5-10, 2001; London,
England England
skipping to change at page 24, line 44 skipping to change at page 26, 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 C.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 ietf- Discussions for this working group are held on the email list
not43@lists.verisignlabs.com. To subscribe to this email list, send ietf-not43@lists.verisignlabs.com. To subscribe to this email list,
email to ietf-not43-request@lists.verisignlabs.com with a subject send email to ietf-not43-request@lists.verisignlabs.com with a
line of "subscribe". Archives of this list may be found out http:// subject line of "subscribe". Archives of this list may be found out
lists.verisignlabs.com/pipermail/ietf-not43/. http://lists.verisignlabs.com/pipermail/ietf-not43/.
B.3 Contributions C.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, and Patrick Mevzek. Hall, Patrick Mevzek, Marcos Sanz, and Vittorio Bertola.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
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 assignees.
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
 End of changes. 

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