From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3707.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1459 insertions(+) create mode 100644 doc/rfc/rfc3707.txt (limited to 'doc/rfc/rfc3707.txt') 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] + + [9] + + + + +Newton Informational [Page 21] + +RFC 3707 CRISP Requirements February 2004 + + + [10] + + [11] + + [12] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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] + -- cgit v1.2.3