Request for Comments: 3707 VeriSign, Inc.
Category: Informational February 2004
Cross Registry Internet Service Protocol (CRISP) Requirements
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Internet registries expose administrative and operational data via
varying directory services. This document defines functional
requirements for the directory services of domain registries and the
common base requirements for extending the use of these services for
other types of Internet registries.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Scope . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Specification . . . . . . . . . . . . . . . 3
2. Internet Registry Communities . . . . . . . . . . . . . . . . 4
2.1. Domain Name System Registries . . . . . . . . . . . . . 4
2.1.1. Domain Registries . . . . . . . . . . . . . . . 4
2.1.2. Domain Registrars . . . . . . . . . . . . . . . 5
2.2. Other Registries . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Regional Internet Registries . . . . . . . . . . 5
2.2.2. Local Internet Registries . . . . . . . . . . . 5
2.2.3. Internet Routing Registries . . . . . . . . . . 5
2.2.4. Incident Coordination Contact Registries . . . . 6
2.3. Implementers . . . . . . . . . . . . . . . . . . . . . . 6
2.4. End Users . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Internet Resource Registrants . . . . . . . . . 6
2.4.2. Service Providers and Network Operators . . . . 6
2.4.3. Intellectual Property Holders . . . . . . . . . 7
2.4.4. Law Enforcement . . . . . . . . . . . . . . . . 7
2.4.5. Certificate Authorities . . . . . . . . . . . . 7
2.4.6. DNS Users . . . . . . . . . . . . . . . . . . . 7
2.4.7. Abusive Users . . . . . . . . . . . . . . . . . 7
2.5. Other Actors . . . . . . . . . . . . . . . . . . . . . . 8
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 8
3.1. Base Functions . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Mining Prevention . . . . . . . . . . . . . . . 8
3.1.2. Minimal Technical Reinvention . . . . . . . . . 8
3.1.3. Standard and Extensible Schemas . . . . . . . . 9
3.1.4. Level of Access . . . . . . . . . . . . . . . . 9
3.1.5. Client Processing . . . . . . . . . . . . . . . 10
3.1.6. Entity Referencing . . . . . . . . . . . . . . . 10
3.1.7. Decentralization . . . . . . . . . . . . . . . . 10
3.1.8. Query of Access Permission . . . . . . . . . . . 11
3.1.9. Authentication Distribution . . . . . . . . . . 11
3.1.10. Base Error Responses . . . . . . . . . . . . . . 11
3.1.11. Query Distribution . . . . . . . . . . . . . . . 12
3.1.12. Protocol and Schema Versioning . . . . . . . . . 12
3.1.13. Relay Bag . . . . . . . . . . . . . . . . . . . 13
3.1.14. Privacy Labels . . . . . . . . . . . . . . . . . 14
3.2. Domain Specific Functions . . . . . . . . . . . . . . . 14
3.2.1. Lookups . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Searches . . . . . . . . . . . . . . . . . . . . 15
3.2.3. Information Sets . . . . . . . . . . . . . . . . 16
3.2.4. Serialization Support . . . . . . . . . . . . . 17
3.2.5. Result Set Limits . . . . . . . . . . . . . . . 17
3.2.6. DNS Delegation Referencing . . . . . . . . . . . 17
3.2.7. Distribution for Domain Registry Types . . . . . 18
3.2.8. Data Omission . . . . . . . . . . . . . . . . . 18
3.2.9. Internationalization . . . . . . . . . . . . . . 19
4. Feature Requirements . . . . . . . . . . . . . . . . . . . . . 19
4.1. Client Authentication . . . . . . . . . . . . . . . . . 19
4.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Common Referral Mechanism . . . . . . . . . . . . . . . 20
4.4. Structured Queries and Responses . . . . . . . . . . . . 20
4.5. Existing Schema Language . . . . . . . . . . . . . . . . 20
4.6. Defined Schemas . . . . . . . . . . . . . . . . . . . . 20
5. Internationalization Considerations . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 21
URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Forums. . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2. Working Group . . . . . . . . . . . . . . . . . . . . . . 24
B.3. Contributions . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 25
Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
1.1. Background
The expansion and growth of the Internet has seen the registry
function of a traditionally centralized and managed Network
Information Center become the responsibility of various autonomous,
functionally disparate, and globally distributed Internet registries.
With the broadening number of Internet registries, the uses of their
administrative directory services have expanded from the original and
traditional use of the whois [6] protocol to include the use of whois
outside the scope of its specification, formal and informal
definitions of syntax, undocumented security mechanisms, the use of
other protocols, such as rwhois [5], to fulfill other needs, and
proposals for the use of other technologies such as LDAP [4] and XML.
1.2. Requirements Scope
The scope of the requirements captured in this document relate to the
directory services of Internet registries and their related
communities (Section 2.3, Section 2.4, and Section 2.5). This
scoping specifically targets the requirements of domain name
registries (Section 2.1). The requirements for other registry types
will be made available in other memos. The requirements are of both
the current use of these directory services and the desired
functionality based on input from relevant forums (Appendix B.1).
These requirements are not specific to any protocol. Terms used in
the definition of requirements in 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 the scope of this document.
1.3. Requirements Specification
The requirements captured in this document are for the purpose of
designing technical specifications. The words used in this document
for compliance with RFC 2119 [3] do not reference or specify policy
and speak only to the capabilities in the derived technology. For
instance, this document may say that the protocol "MUST" support
certain features. An actual service operator is always free to
disable it (and then to return an error such as "permission denied".)
Requirements in this document specifying the capabilities of the
protocol required for proper interaction between a client and a
server will be specified with the "MUST/SHOULD" language of RFC 2119
[3]. 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 RFC 2119 language.
While individual servers/service operators may not support all
features that the protocol can support, they must respect the
semantics of the protocol queries and responses. For example, a
server should not return referrals if it does not have referent data.
2. Internet Registry Communities
The Internet registries are composed of various communities which
provide scope for the requirements in this document. These
communities can be generalized into the following categories:
registries, registrars, implementers, end-users, and other actors.
2.1. Domain Name System Registries
2.1.1. Domain Registries
Domain registries are responsible for the registration of domains for
use with DNS [1] and forward lookups (i.e., does not include the
.ARPA domain). These registries have typically 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 multiple TLD’s,
both of the gTLD and ccTLD type. A gTLD or ccTLD domain registry
operator may be a governmental entity, non-governmental,
non-commercial entity, or a commercial entity.
Some ccTLD’s have second-level domain registrations similar in nature
to gTLD’s or have distinctly separate entities operating second-level
domain registries similar in nature to gTLD’s within the ccTLD.
Domain registries usually follow one of two models for conducting
registrations of domains. The "thick" model is the more traditional
model. In a "thick" domain registry, the registry contains both the
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 registrant but may also interface with the domain
registrant through domain registrars. The "thin" model domain
registry contains only operational data for domains. In the "thin"
model, contact data for the domain are maintained by a domain
registrar.
Domain registries not described in this section (Section 2.1.1) are
not the subject of this document and may have requirements that are
out of scope for this subject matter.
2.1.2. Domain Registrars
Domain registrars accept domain registrations from registrants on
behalf of domain registries, both "thick" and "thin". In a "thin"
model registry/registrar system, a domain registrar maintains the
contact data of a domain while the registry maintains the operational
data of a domain. In a "thick" model registry/registrar system, a
domain registrar passes both the operational data and contact data to
the registry. Domain registrars may register a domain on behalf of a
registrant in more than one domain registry.
2.2. Other Registries
This section describes Internet registries other than those listed in
Section 2.1. These descriptions are not definitive and this list is
not absolute. They are provided in this document for informational
purposes only.
2.2.1. Regional Internet Registries
Regional Internet Registries (RIR’s) administer the allocation of IP
address space and autonomous system numbers. Each RIR serves a
specific geographic region, and collectively they service the entire
Internet. Each RIR is a membership-based, non-profit organization
that facilitates and implements global addressing policy based on the
direction of their regional community.
2.2.2. Local Internet Registries
Local Internet Registries (LIR’s) and National Internet Registries
(NIR’s) are sub-registries of RIR’s and coordinate the same functions
of the RIR’s for smaller, more specific geographic regions, sovereign
nations, and localities.
2.2.3. Internet Routing Registries
Internet Routing Registries are routing policy databases. Their
purpose is to provide information helpful in administering Internet
routers. Frequently, the syntax and contents are defined by RPSL
[7].
IRR’s are operated by academic, commercial, governmental, and other
types of organizations, including several of the RIR’s. The contents
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
customers, to decide whether to accept specific route advertisements
they receive).
Unlike RIR and domain registry data, IRR data is often duplicated
between separate organizations. The IRR data has the unique
characteristics of being largely available through other sources
(i.e., it is advertised by the Internet routing protocols) and most
often having a common data format, RPSL.
2.2.4. Incident Coordination Contact Registries
Incident coordination contact registries allow operators of network
resources such as network infrastructure, network names, or network
services to register contact information for the purpose of providing
a means of incident notification. Using this type of registry, an
operator of network resources are provided information for contacting
the operator of another network resource from which an incident may
be occurring.
2.3. Implementers
Implementers of client software are often either affiliated with
large network operators, registry operators, or commercial entities
offering value-added services, or are general citizens of the
Internet. Much of the client software for use with the directory
services of Internet registries is either freely available, open
source, or both, or available as a service. Implementers of server
software are often affiliated with operators or commercial entities
specializing in the out-sourcing of development for Internet
registries.
2.4. End Users
This section describes the many types of end-users. Individuals and
organizations may have multiple roles and may concurrently occupy
many of the categories.
2.4.1. Internet Resource Registrants
Entities given authority over an Internet resource via purchase,
lease, or grant from an Internet registry, either directly or via the
services of a registrar.
2.4.2. Service Providers and Network Operators
Service providers and network operators provide connectivity,
routing, and naming services to many other entities, some commercial
and some non-commercial, both large and small. Their operational and
administrative staff often interact with Internet registries on
behalf of other end-users. Service providers and network operators
interact with all of the Internet registry operators outlined in this
document on a frequent and consistent basis. For example, network
operators use the directory services of Internet registries to
determine contact information for network resources that have
technical problems.
2.4.3. Intellectual Property Holders
A number of parties, such as trademark, service mark and intellectual
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
registries and registrars, for purposes of maintaining and defending
claims to domain names consistent with applicable laws and
regulations.
2.4.4. Law Enforcement
Law enforcement agencies use the directory services of Internet
registries to find information used to carry out the enforcement of
laws within their jurisdictions.
2.4.5. Certificate Authorities
Certificate authorities use the directory services of Internet
registries as part of their verification process when issuing
certificates for Internet named hosts.
2.4.6. DNS Users
Users of the Internet have client software that resolves domain names
to IP addresses and IP addresses to domain names. Often when trouble
occurs in the resolution process of DNS, these users trouble shoot
system problems with the aid of information from the directory
services of Internet registries.
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
Requirements must also consider the positions and policies of other
actors on the use of Internet registry directory services. These
actors include governments, non-governmental policy-setting bodies,
and other non-governmental organizations.
3. Functional Requirements
Functional requirements describe an overall need or process for which
the directory service is used by an Internet registry to fulfill its
obligations to provide access to its respective customers, members,
or other constituents. This section describes requirements in the
manner specified in Section 1.3.
3.1. Base Functions
This section describes basic directory service protocol requirements
for Internet registries. Additional requirements, specific to domain
registries, are described in Domain Specific Functions (Section 3.2).
3.1.1. Mining Prevention
In order to prevent the inappropriate acquisition of data from an
Internet registry’s directory service, many servers will limit the
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
anonymous access uses (see Section 3.1.4).
The limits placed on differing types of data or applied depending
upon access status will most likely differ from server to server
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.
3.1.2. Minimal Technical Reinvention
The protocol MUST NOT employ unique technology solutions for all
aspects and layers above the network and transport layers. The
protocol SHOULD make use of existing technology standards where
applicable. The protocol MUST employ the use of network and
transport layer standards as defined by the Internet Engineering Task
Force. The protocol MUST define one or more congestion-aware
transport mechanisms for mandatory implementation.
3.1.3. Standard and Extensible Schemas
3.1.3.1. Protocol Requirement
The protocol MUST contain standard schemas for the exchange of data
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
needs of this document. Both types of schemas MUST use the same
schema language. The schemas MUST be able to express data elements
with identifying tags for the purpose of localization of the meaning
of the identifying tags.
3.1.3.2. Service Description
The client-to-server protocol must define a standard set of data
structures or schemas to be used when exchanging information. It
must also poses the ability to allow for the use of newer data
structures that are currently not foreseen by this specification. In
both cases, the description and specification of both types of data
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
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
"Bob" and its type identified with the number "5.1". Client software
could use this to display "Name: Bob" in an English locale or
"Nombre: Bob" in a Spanish locale.
3.1.4. Level of Access
3.1.4.1. Protocol Requirement
The protocol MUST NOT prohibit an operator from granularly assigning
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 protocol MUST provide an anonymous access mechanism that may be
turned on or off based on the policy of an operator.
3.1.4.2. Service Description
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
The protocol MUST be capable of allowing machine parsable requests
and responses.
3.1.6. Entity Referencing
There MUST be a mechanism for an entity contained within a server to
be referenced uniquely by an entry in another server.
3.1.7. Decentralization
3.1.7.1. Protocol Requirement
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.
3.1.7.2. Service Description
Some server operators may have a need to coordinate service in a mesh
or some other framework with other server operators. However, the
ability to operate a CRISP compliant server must not require this.
3.1.8. Query of Access Permission
3.1.8.1. Protocol Requirement
The protocol MUST provide a mechanism allowing a client to determine