summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3707.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3707.txt')
-rw-r--r--doc/rfc/rfc3707.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc3707.txt b/doc/rfc/rfc3707.txt
new file mode 100644
index 0000000..26cc5e3
--- /dev/null
+++ b/doc/rfc/rfc3707.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group A. Newton
+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
+
+
+
+Newton Informational [Page 1]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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
+
+
+
+
+
+Newton Informational [Page 2]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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".)
+
+
+
+Newton Informational [Page 3]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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.
+
+
+
+
+Newton Informational [Page 4]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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
+
+
+
+Newton Informational [Page 5]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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
+
+
+
+Newton Informational [Page 6]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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,
+
+
+
+Newton Informational [Page 7]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 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.
+
+
+
+Newton Informational [Page 8]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 9]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 10]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+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.1. Protocol Requirement
+
+ The protocol MUST NOT require any Internet registry to participate in
+ 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
+
+ The protocol MUST be capable of returning the following types of
+ non-result or error responses to all lookups and searches:
+
+ o permission denied - a response indicating that the search or
+ lookup has failed due to insufficient authorization.
+
+ o not found - the desired results do not exist.
+
+ o insufficient resources - the search or lookup requires resources
+ that cannot be allocated.
+
+
+
+
+
+
+
+Newton Informational [Page 11]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+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
+ client must be allowed to distribute these queries among the
+ participants in an established mesh of server operators. It is not a
+ requirement that the protocol enable the discovery of servers, but
+ cooperating servers should be able to intelligently handle
+ distribution with its established mesh. Individual server operators
+ will respond to all queries received according to their policies for
+ authentication, privacy, and performance.
+
+ However, the ability to operate a CRISP compliant server must not
+ require the participation in any query distribution system.
+
+3.1.12. Protocol and Schema Versioning
+
+3.1.12.1. Protocol Requirements
+
+ 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
+ query or set of queries.
+
+ All resource-specific schema MUST provide a version identifier
+ attribute which uniquely and unambiguously identifies the version of
+ the schema being returned in the answer set to a query.
+
+3.1.12.2. Service Description
+
+ The service should allow end-systems using different protocol
+ versions to fallback to a mutually supported protocol version. If
+ this is not possible, the service must provide a meaningful error
+ which indicates that this is the specific case.
+
+ The service must suggest negotiation and/or recovery mechanisms for
+ clients to use when an unknown schema version is received.
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 12]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.1.13. Relay Bag
+
+ The term "bag" in this section describes a flexible container which
+ may contain unspecified data.
+
+3.1.13.1. Protocol Requirement
+
+ 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
+ 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.
+ The protocol MUST NOT make any assumptions regarding the contents of
+ the relay bag, but the relay bag MUST be described using the schema
+ language of the protocol.
+
+ The protocol MUST provide different error messages to indicate
+ whether the bag is of unrecognized format (permanent failure), if it
+ contains unacceptable data (permanent failure), or if it contains
+ data that means processing is refused at this time (transient
+ failure).
+
+ There MUST be no more than one bag per referral. The protocol MUST
+ NOT make an association or linkage between successive bags in a
+ referral chain.
+
+ The client MUST pass the bag as part of any query made to a referrant
+ server as a result of a referral.
+
+3.1.13.2. Service Description
+
+ In some models where service coordination among participating server
+ operators is utilized, there might be needs to allow a referring
+ server to pass operator-to-operator coordination data along with the
+ referral to the referent server. Such needs might be auditing or
+ tracking. This feature requirement allows a server to pass to the
+ client a flexible container of unspecified data ("bag") that the
+ client should pass to the referent server. The bag has no meaning to
+ the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 13]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.1.14. Privacy Labels
+
+3.1.14.1. Protocol Requirement
+
+ When a value in an answer to a query is given, the protocol MUST be
+ capable of tagging the value with the following labels:
+
+ 1. do not redistribute
+
+ 2. special access granted
+
+ The protocol MAY define other values for this purpose, but MUST
+ define values defined above at a minimum. The protocol MUST be
+ capable of attaching these labels concurrently.
+
+3.1.14.2. Service Description
+
+ Internet registries will have varying policies regarding the access
+ to their data. Some registries may grant certain classes of 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
+ entries with labels specifying the responsibilities accompanying
+ these special user rights.
+
+3.2. Domain Specific Functions
+
+ These functions describe requirements specifically needed by domain
+ registries (Section 2.1.1) and domain registrars (Section 2.1.2).
+ Requirements specific to other registries (Section 2.2) MUST be
+ specified separately. No compliant server operator is required to
+ support the functions required by every registry type.
+
+3.2.1. Lookups
+
+3.2.1.1. Protocol Requirement
+
+ The protocol MUST contain the following lookup functions:
+
+ 1. Contact lookup given a unique reference to a contact of a
+ resource.
+
+ 2. Nameserver lookup given a fully-qualified host name or IP address
+ of a nameserver.
+
+ 3. Domain lookup given a fully-qualified domain name.
+
+ See Section 3.2.3 for the requirements regarding the expected return
+ values.
+
+
+
+Newton Informational [Page 14]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.2.1.2. Service Description
+
+ These lookups are all single index queries and should produce zero or
+ only one entity.
+
+ 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
+ all of the information. See Section 3.2.3.
+
+3.2.2. Searches
+
+3.2.2.1. Protocol Requirement
+
+ The protocol MUST contain the following search functions:
+
+ 1. Domain name search given an exact match or reasonable subset of a
+ name. This search SHOULD allow for parameters and qualifiers
+ designed to allow better matching of internationalized domain
+ names and SHOULD allow for both exact and partial matching within
+ the limits of internationalized domain names. This search SHOULD
+ NOT require special transformations of internationalized domain
+ names to accommodate this search. This search MUST provide a
+ means to narrow the search by names delegated under a particular
+ TLD.
+
+ 2. Domain registrant search by either exact name or partial name
+ match with the ability to narrow the search to registrants of a
+ particular TLD.
+
+ 3. Domains hosted by a nameserver given the fully-qualified host name
+ or IP address of a nameserver.
+
+ See Section 3.2.3 for the requirements regarding the expected return
+ values.
+
+3.2.2.2. Service Description
+
+ 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.5 describes these types of
+ restrictions.
+
+ Some Internet registries may also be participating in a query
+ distribution system. See Section 3.1.11.
+
+
+
+
+
+Newton Informational [Page 15]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.2.3. Information Sets
+
+3.2.3.1. Protocol Requirements
+
+ 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 schema MUST be capable of expressing the following information
+ for domains:
+
+ o activation status
+
+ o registrant
+
+ o nameservers
+
+ o technical, billing or other contacts
+
+ o registry delegating the domain
+
+ o registrar for the domain
+
+ The data set for domains 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.
+
+3.2.3.2. Service Description
+
+ It is not expected that every Internet registry supply all of the
+ information spelled out above, however the schemas employed by the
+ protocol must be capable of expressing this information should a
+ registry need to provide it.
+
+ The following sections describe requirements relative to the use of
+ schemas with respect to individual registry need and policy:
+
+ o Section 3.2.8
+
+ o Section 3.2.5
+
+ o Section 3.1.4
+
+ o Section 3.1.1
+
+
+
+
+Newton Informational [Page 16]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.2.4. Serialization Support
+
+ The schemas used by the protocol SHOULD be capable of off-line
+ serialization
+
+ 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.5. Result Set Limits
+
+3.2.5.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.5.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.6. DNS Delegation Referencing
+
+3.2.6.1. Protocol Requirement
+
+ The protocol MUST use the delegation authority model available in DNS
+ [1] as the primary means for determining the authoritative source for
+ information regarding domains or any other objects when applicable.
+
+
+
+
+
+
+
+Newton Informational [Page 17]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+3.2.6.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.7. Distribution for Domain Registry Types
+
+3.2.7.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.7.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 many 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.8. Data Omission
+
+3.2.8.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
+ 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
+
+
+
+Newton Informational [Page 18]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ 3. an indication that the value cannot be given due to privacy
+ constraints regardless of authorization status
+
+ The protocol MAY define other values for this purpose, but MUST
+ define values defined above at a minimum.
+
+3.2.8.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.
+
+3.2.9. Internationalization
+
+ The schema defining domain related resources MUST conform to RFC 2277
+ [2] regarding textual data. In particular, the schema MUST be able
+ to indicate the charset and language in use with unstructured textual
+ data.
+
+ The protocol MUST be able to support multiple representations of
+ contact data, with these representations complying with the
+ 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
+ US-ASCII, other character sets, and capable of specifying the
+ language of the data.
+
+4. Feature Requirements
+
+ Feature requirements describe the perceived need derived from the
+ functional requirements for specific technical criteria of the
+ directory service. This section describes requirements in the manner
+ specified in Section 1.3.
+
+4.1. Client Authentication
+
+ Entities accessing the service (users) MUST be provided a mechanism
+ for passing credentials to a server for the purpose of
+ authentication. The protocol MUST provide a mechanism capable of
+ employing many authentication types and capable of extension for
+ future authentication types.
+
+
+
+
+
+
+
+Newton Informational [Page 19]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+4.2. Referrals
+
+ To distribute queries for search continuations and to issue entity
+ references, the protocol MUST provide a referral mechanism.
+
+4.3. Common Referral Mechanism
+
+ To distribute queries for search continuations and to issue entity
+ references, the protocol MUST define a common referral scheme and
+ syntax.
+
+4.4. Structured Queries and Responses
+
+ To provide for machine consumption as well as human consumption, the
+ protocol MUST employ structured queries and responses.
+
+4.5. Existing Schema Language
+
+ To provide structured queries and responses and allow for minimal
+ technological reinvention, the protocol MUST employ a pre-existing
+ schema language.
+
+4.6. Defined Schemas
+
+ To provide for machine consumption as well as human consumption, the
+ protocol MUST define schemas for use by the structured queries and
+ responses.
+
+5. Internationalization Considerations
+
+ Requirements defined in this document MUST consider the best
+ practices spelled out in [2].
+
+6. IANA Considerations
+
+ IANA consideration for any service meeting these requirements will
+ depend upon the technologies chosen and MUST be specified by any
+ document describing such a service.
+
+7. Security Considerations
+
+ This document contains requirements for the validation of
+ authenticated entities and the access of authenticated entities
+ compared with the access of non-authenticated entities. This
+ document does not define the mechanism for validation of
+ authenticated entities. Requirements defined in this document MUST
+ allow for the implementation of this mechanism according best common
+ practices.
+
+
+
+Newton Informational [Page 20]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ The requirement in Section 3.1.4 must be weighed against other
+ requirements specifying search or lookup capabilities.
+
+ This document contains requirements for referrals and entity
+ references. Client implementations based on these requirements
+ SHOULD take proper care in the safe-guarding of credential
+ information when resolving referrals or entity references according
+ 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.
+
+Normative References
+
+ [1] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [2] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+ BCP 18, RFC 2277, January 1998.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+Informative References
+
+ [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
+ Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
+ June 1997.
+
+ [6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
+ 954, October 1985.
+
+ [7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
+ Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
+ Policy Specification Language (RPSL)", RFC 2622, June 1999.
+
+URIs
+
+ [8] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
+
+ [9] <http://www.ietf.org/proceedings/01aug/51-40.htm>
+
+
+
+
+Newton Informational [Page 21]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+ [10] <http://www.uwho.verisignlabs.com/
+ Final-WhoIsPanel-Aug15-Resume.pdf>
+
+ [11] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/
+ min_database.html>
+
+ [12] <http://www.nanog.org/mtg-0110/lookup.html>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 22]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+Appendix A. Glossary
+
+ o TLD: Initials for "top level domain." Referes to domains in DNS
+ [1] that are hierarchically at the level just beneath the root.
+
+ o ccTLD: Initials for "country code top level domain." TLD's which
+ use one of the two character country codes defined by ISO.
+
+ o gTLD: Initials for "generic top level domain." TLD's that do not
+ use one of the two character country codes defined by ISO.
+
+ o contact data: Data containing names and contact information (i.e.,
+ postal addresses, phone numbers, e-mail addresses) of humans or
+ legal entities.
+
+ o operational data: Data necessary to the operation of networks and
+ network related services and items.
+
+ o RIR: Initials for "regional Internet registry."
+
+ o IRR: Initials for "Internet routing registry."
+
+ o forward lookup: a DNS lookup where a domain name is resolved to an
+ IP address.
+
+ o reverse lookup: a DNS lookup where an IP address is resolved to a
+ domain name.
+
+ o mining: In the context of this document, this term is specific to
+ data mining. This is a methodical process to obtain the contents
+ of directory service, usually as much as possible, not relevant to
+ any immediate need. Data mining is often not a practice welcomed
+ by registry operators.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 23]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+Appendix B. Acknowledgements
+
+B.1. Forums
+
+ The proceedings of the following public forums were used as input to
+ the scope and requirements for this document:
+
+ o whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego,
+ CA, USA
+
+ o whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London,
+ England
+
+ o First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
+
+ o Second UWho Consultation; November 15, 2001; Marina del Rey, CA,
+ USA
+
+ o Third UWho Consultation; November 19, 2001; Washington, DC, USA
+
+ o DNR WG of RIPE 40, October 1-5, 2001; Praque, Czech Republic
+
+ o Database WG of RIPE 40 [11]; October 1-5, 2001; Praque, Czech
+ Republic
+
+ o General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
+
+ o DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
+
+ o Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The
+ Netherlands
+
+ o NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
+
+ o CENTR General Assembly, February 21-22, 2002; Rambouillet, France
+
+ o CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis,
+ Minnesota, USA
+
+B.2. Working Group
+
+ This document is a work item of the Cross-Registry Internet Service
+ Protocol (CRISP) Working Group in the Applications Area of the IETF.
+ Discussions for this working group are held on the email list ietf-
+ not43@lists.verisignlabs.com. To subscribe to this email list, send
+ email to ietf-not43-request@lists.verisignlabs.com with a subject
+ line of "subscribe". Archives of this list may be found out
+ http://lists.verisignlabs.com/pipermail/ietf-not43/.
+
+
+
+Newton Informational [Page 24]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+B.3. Contributions
+
+ Comments, suggestions, and feedback of significant substance have
+ been provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr,
+ Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric
+ Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George
+ Michaelson, and Tim Christensen.
+
+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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 25]
+
+RFC 3707 CRISP Requirements February 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Informational [Page 26]
+