Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires:
April 30,August 5, 2003 February 4, 2003 October 30, 2002Cross Registry Internet Service Protocol (CRISP) Requirements draft-ietf-crisp-requirements-02draft-ietf-crisp-requirements-03 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts.Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30,August 5, 2003. Copyright Notice Copyright (C) The Internet Society (2002).(2003). 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Requirements Scope . . . . . . . . . . . . . . . . . . . . 4 1.3 Requirements Specification . . . . . . . . . . . . . . . . 4 2. Internet Registry Communities . . . . . . . . . . . . . . 56 2.1 Domain Name System Registries . . . . . . . . . . . . . . 56 2.1.1 Domain Registries . . . . . . . . . . . . . . . . . . . . 56 2.1.2 Domain Registrars . . . . . . . . . . . . . . . . . . . . 56 2.2 Other Registries . . . . . . . . . . . . . . . . . . . . . 67 2.2.1 Regional Internet Registries . . . . . . . . . . . . . . . 67 2.2.2 Local Internet Registries . . . . . . . . . . . . . . . . 67 2.2.3 Internet Routing Registries . . . . . . . . . . . . . . . 67 2.2.4 Incident Coordination Contact Registries . . . . . . . . . 67 2.2.5 Network Edge Resource Registries . . . . . . . . . . . . . 78 2.3 Implementers . . . . . . . . . . . . . . . . . . . . . . . 78 2.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . 78 2.4.1 Service Providers and Network Operators . . . . . . . . . 78 2.4.2 Intellectual Property Holders . . . . . . . . . . . . . . 78 2.4.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 89 2.4.4 Certificate Authorities . . . . . . . . . . . . . . . . . 89 2.4.5 DNS Users . . . . . . . . . . . . . . . . . . . . . . . . 89 2.4.6 Domain Registrants . . . . . . . . . . . . . . . . . . . . 89 2.4.7 Abusive Users . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 89 3. Functional Requirements . . . . . . . . . . . . . . . . . 910 3.1 Base Functions . . . . . . . . . . . . . . . . . . . . . . 910 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 910 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 910 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 10 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 1011 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 1011 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 1011 3.1.7 Decentralization . . . . . . . . . . . . . . . . . . . . . 1011 3.1.8 Query of Access LevelsPermission . . . . . . . . . . . . . . . . . . 1112 3.1.9 Authentication Distribution . . . . . . . . . . . . . . . 1112 3.1.10 Base Error Responses . . . . . . . . . . . . . . . . . . . 1112 3.1.11 Query Distribution . . . . . . . . . . . . . . . . . . . . 1113 3.2 Domain Specific Functions . . . . . . . . . . . . . . . . 1213 3.2.1 Contact Lookup . . .Lookups . . . . . . . . . . . . . . . . . . . 12 3.2.2 Nameserver Lookup. . . . . . 13 3.2.2 Searches . . . . . . . . . . . . . . 12 3.2.3 Domain Registrant Search. . . . . . . . . . . 14 3.2.3 Serialization Support . . . . . . 12 3.2.4 Domain Information Lookup. . . . . . . . . . . . 15 3.2.4 Result Set Limits . . . . 12 3.2.5 Nameserver Search. . . . . . . . . . . . . . . . 15 3.2.5 DNS Delegation Referencing . . . . 13 3.2.6 Escrow Support. . . . . . . . . . . . 16 3.2.6 Distribution for Domain Registry Types . . . . . . . . . . 1317 3.2.7 Domain Name SearchData Omission . . . . . . . . . . . . . . . . . . . . 13 3.2.8 Result Set Limits. . 17 4. Feature Requirements . . . . . . . . . . . . . . . . . . 14 3.2.9 DNS Label Referencing. 18 4.1 Client Authentication . . . . . . . . . . . . . . . . . 14 3.2.10 Distribution for Domain Registry Types. 18 4.2 Referrals . . . . . . . . . 14 4. Feature Requirements. . . . . . . . . . . . . . . 18 4.3 Common Referral Mechanism . . . . 15 4.1 Client Authentication. . . . . . . . . . . . 18 4.4 Structured Queries and Responses . . . . . . 15 4.2 Referrals. . . . . . . 18 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 15 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 15 4.4 Structured Queries and Responses . . . . . . . . . . . . . 15 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 1518 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 16 4.7 Serialization Definition . . . . . . . . . . . . . . . . . 1618 5. Internationalization Considerations . . . . . . . . . . . 1719 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 1820 7. Security Considerations . . . . . . . . . . . . . . . . . 1921 References . . . . . . . . . . . . . . . . . . . . . . . . 2022 Author's Address . . . . . . . . . . . . . . . . . . . . . 2022 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 2123 B. AcknowledgementsOutstanding Issues . . . . . . . . . . . . . . . . . . . . 24 C. Acknowledgements . . . 23 B.1 Forums. . . . . . . . . . . . . . . . . . 25 C.1 Forums . . . . . . . . . 23 B.2 Working Group. . . . . . . . . . . . . . . . . 25 C.2 Working Group . . . . . . 23 B.3 Contributions. . . . . . . . . . . . . . . . 25 C.3 Contributions . . . . . . . . 24 Full Copyright Statement. . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . 25. . . 27 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  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 , to fulfill other needs, and proposals for the use of other technologies such as LDAP  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) while acknowledging extensibility needs for possible future support of the requirements for other registry (Section 2.2) types. 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).C.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 scope. 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 RFC2119  do not reference or specify policy and speak only to the capabilities in the derived technology. For instance, this document may say that the serviceprotocol "MUST" support certain features. An actual service operator is always free to disable it (and then to return an error such as "permission denied".) The scope of the requirementsRequirements in this document are also restricted to accessspecifying the capabilities of data from Internet registries. Requirementsthe protocol required for modification, addition, or provisioningproper interaction between a client and a server will be specified with the "MUST/SHOULD" language of data in Internet registries are outRFC2119 . This document also contains language relating to the interaction of scope.a client with multiple servers to form a coherent, cross-network service. Such service requirements will not be described using RFC2119 language. 2. Internet Registry Communities 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  and forward lookups (i.e. does not include the IN- ADDR.ARPAIN-ADDR.ARPA or IP6.ARPA domains). 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-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 or social 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 or social data for the domain are maintained by a domain registrar. Domain registries not described in this section (Section 2.1.1) are not the subject of this document and may have requirements that are out of scope for this subject matter. 2.1.2 Domain Registrars Domain registrars accept domain registrations from registrants on behalf of domain registries, both "thick" and "thin". In a "thin" model registry/registrar system, a domain registrar maintains the contact and social 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 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 . IRR's are operated by academic, commercial, governmental, and other types of organizations, including several of the RIR's. The contents of the databases vary and reflect the needs of the users directly served (e.g. an ISP may look up route entries added by their customers to decide whether to accept specific route advertisements they receive). Unlike RIR and domain registry data, IRR data is often duplicated between separate organizations. The IRR data has the unique characteristics of being largely available through other sources (i.e. it is advertised by the Internet routing protocols) and most often having a common data format, RPSL. 2.2.4 Incident Coordination Contact Registries Incident coordination contact registries allow operators of network resources such as network infrastructure, network names, or network services to register contact information for the purpose of providing a means of incident notification. Using this type of registry, an operators of network resources are provided information for contacting the operator of another network resource from which an incident may be occurring. 2.2.5 Network Edge Resource Registries Network edge resource registries provide specific information about "edge" resources. They are administered by the operators of the resources. Examples of such registries are rwhois  servers operated by networks to describe the assignment of address space allocated by RIR's or LIR's and whois  servers operated by networks to specifically announce routing policy of that network. 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 2.4.1 Service Providers and Network Operators Service providers and network operators provide connectivity, routing, and naming services to many other entities, some commercial and some non-commercial, both large and small. Their operational and administrative staff often interact with Internet registries on behalf of other end-users. Service providers and network operators interact with all of the Internet registry operators outlined in this document on a frequent and consistent basis. For example, network operators use the directory services of Internet registries to determine contact information for network resources that have technical problems. 2.4.2 Intellectual Property Holders Intellectual Property HoldersA number of parties, such as trademark, service mark and intellectual property holders, individuals, governments and other geopolitical entities, have some legal rights to the use of domain names based on copyright and trademark laws of various governments. Theyon 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.3 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.4 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.5 DNS Users Users of the Internet have client software that resolves domain names to IP addresses. 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.6 Domain Registrants Entities given authority over a domain via purchase, lease, or grant from a domain registry, either directly or via the services of a domain registrar. 2.4.7 Abusive Users The administrative directory services of Internet registries are often the target of practices by abusive users. Using information obtained from Internet registries, abusive users undertake certain activities that are counter to the acceptable use of the information as intended by a registry, registrar, or registrant. Many times, these practices violate law in the jurisdiction of the user, registry, registrar, or registrant. One example is the use of Internet registry information for the use of sending unsolicited bulk or commercial email. 2.5 Other Actors Requirements must also consider the positions and policies of other actors on the use of Internet registry directory services by other actors. These actors include governments, non-governmental policy- settingpolicy-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 makes reference to terms and definitions declared in Appendix A. This section makes use of the term "service" to denote the set of functions to be provided by, and the expected behavior of, software built to meet these requirements in one or more protocols. Thesedescribes requirements are for the purpose of designing a technical specification. The words usedin this section are for compliance with RFC2119 , do not reference or specify policy, and speak only tothe capabilitiesmanner specified in the derived technology. For instance, this document may say that the service "MUST" support search features. An actual service operator is always free to disable it (and the to return an error such as "permission denied").Section 1.3. 3.1 Base Functions This section describes basic directory service protocol requirements for an Internet registry service for any of the registries (domaindomain name registries(Section 2.1) and other registries(Section 2.2)).2.2) registries. Additional requirements, specific to domain registries, are described in Domain Specific Functions (Section 3.2). 3.1.1 Mining Prevention The service MUST have a mechanismIn 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 accessed.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 service MAY have differentlimits for differentplaced on differing types of data, as well as for authenticated and non-authenticated entities. The service SHOULD be capable of expressing to the client thesedata or applied depending upon access limitationsstatus will most likely differ from server to server based on queries per session per unit of time, queries per source IP address per unit of time,policy and total queries from all client sessions per unit of time. Theneed. Support for varying service SHOULD be ablemodels in the effort to limit the amount ofdata basedand prevent data mining may or may not have a direct impact on the above types of limitations.client-to-server protocol. Section 3.2.4 also contains protocol requirements which are relevant to client/server interaction in certain domain registry service models. 3.1.2 Minimal Technical Reinvention The serviceprotocol MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers of the total service solutionand SHOULD make use of existing technology standards where applicable. The serviceprotocol MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force. The serviceprotocol MUST define one or more transport mechanisms for mandatory implementation. 3.1.3 Standard and Extensible Schemas The serviceprotocol MUST definecontain 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 internationalized data element labelsthe meaning of the identifying tags. 3.1.4 Level of Access 126.96.36.199 Protocol Requirement The serviceprotocol MUST allow the classification of data as being either privileged or non-privileged, for the purposeNOT prohibit an operator from granularly assigning multiple types of restrictingaccess to privileged data. Note that this requirement makes no assumption or prescription as to whatdata (social or operational) might be considered privileged, but merely provides the abilityaccording to makethe classification as necessary.policies of the operator. The serviceprotocol MUST be capable of serving both privilegedprovide an authentication mechanism and non- privileged data.MUST NOT prohibit an operator from granting types of access based on authentication. The serviceprotocol MUST provide an anonymous access mechanism that may be capableturned on or off based on the policy of authenticating privileged entitiesan operator. 188.8.131.52 Service Description Server operators will offer varying degrees of access depending on policy and ensuring thatneed. The following are some examples: o users will be allowed access only those entitiesto 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 both privileged and non-privileged data.a special group of authenticated users The service MUST be capabletypes of providingaccess allowed by a server will most likely vary from one operator to non-privileged data without requiring authentication of any type (i.e. anonymous access).the next. 3.1.5 Client Processing The serviceprotocol 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 184.108.40.206 Protocol Requirement The service MUST be decentralized in design and principle andprotocol MUST NOT require the aggregation of data to a central repository, server, or entity. The service MAY allow for the optional aggregation of data indexes or hints. The serviceprotocol MUST NOT require aggregation of data indexes or hints. 3.1.8 Query of Access Levels Ifhints to a query cannot yieldcentral repository, server, or entity. 220.127.116.11 Service Description Some server operators may have a valid response dueneed to insufficient permissions, thecoordinate service MUST provide the clientin a mesh or some other framework with an error response indicating this condition.other server operators. However, the ability to operate a CRISP compliant server must not require this. 3.1.8 Query of Access Permission 18.104.22.168 Protocol Requirement The service SHOULD NOTprotocol MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted. It issubmitted according to the intentappropriate policies of this requirement for clients to learnthe operator. 22.214.171.124 Service Description Because usage scenarios will differ depending on both policy and type of inadequate permission status for a query only afterservice, some server operators may want to provide the query has been submitted. Operating modes allowingability for a client to predetermine the queries that will orits ability to retrieve data from a query. However, some operators will not be denied are not encouragedallow this for security considerations.reasons, policy restrictions, or other matters. 3.1.9 Authentication Distribution 126.96.36.199 Protocol Requirement The serviceprotocol MUST NOT require any Internet registriesregistry to participate in any particular distributedauthentication system. The service SHOULD allowprotocol MUST NOT prohibit the participation by an Internet registry in federated, distributed authentication by many centralized authorities.systems. 188.8.131.52 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 serviceprotocol MUST be capable of returning the following types of non- resultnon-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. 3.1.11 Query Distribution 184.108.40.206 Protocol Requirement The protocol MUST NOT prohibit a server from participating in a query distribution system. 220.127.116.11 Service Description For lookups and searches requiring distribution of queries, the service MUSTclient must be capable of distributingallowed to distribute these queries among the participants in an established mesh of serviceserver operators. It is not a requirement that the serviceprotocol enable the discovery of service operators,servers, but the servicecooperating servers should be able to intelligently handle distribution with its established mesh. Individual serviceserver 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.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 service entityserver operator is required to support the functions required by every registry type. 3.2.1 Contact LookupLookups 18.104.22.168 Protocol Requirement The serviceprotocol MUST allow access to social data of contact entitiescontain the following lookup functions: 1. Contact lookup given a unique reference to the contact entity. The contact information set MUST be able to express and represent the attributes and allowable values ofa contact registration requests in domain registration and provisioning protocols. 3.2.2 Nameserver Lookup The service MUST allow access to operational and social dataof a nameserverresource. 2. Nameserver lookup given thea fully-qualified host name or IP address of a nameserver. The host information set MUST be able to express and represent the attributes and allowable values of nameservers in domain registration and provisioning protocols. 3.2.3 Domain Registrant Search The service MUST provide the capability of searching for registrants by exact name match or a reasonable name subset. This search must comply with Section 3.2.8. The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. The service SHOULD have a means to narrow the scope of a search to a specific TLD. The service MUST be able to specify to the client an empty result set should the search yield no results. 3.2.43. Domain Information Lookup The service MUST provide access to operational and social data specific tolookup given a fully-qualified domain given the domain's fully qualified name (FQDN).name. The serviceprotocol MUST be capable of supplying the following information relevant to the domain for this lookup: o* activation status o* registrant name and contact data o hosting* nameservers o* technical, billing or other entity types associated with the domain and their relevant contact data, if any exist o the name of or a reference to thecontacts * registry delegating the domain o the name of or a reference to the* registrar for the domain, if one existsdomain The data set for the domain MUST be able to express arbitrary textual information setfor 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. The data sets for contacts, nameservers, and domains MUST be able to express and represent the attributes and allowable values of domainregistration requests in domain registration and provisioning protocols. 3.2.5 Nameserver Search The service MAY allow the ability to list22.214.171.124 Service Description These lookups are all domains hosted by a specific nameserver given the fully-qualified host namesingle index queries and should produce zero or IP address, if applicable, ofonly one result. Depending on the nameserver. The service MAY provide a mechanism to distribute this search across all applicable domain registriespolicy and registrars. 3.2.6 Escrow Support The service MUST provide a means to escrow dataneed of domain registrars toan escrow entity usingInternet registry, a common schema. This escrow capability SHOULD be "off-line" and "out-of-band" from the normal operationsserver operator may not allow all or any of these lookups to return part or all of the service. 3.2.7 Domain Name Searchinformation. See Section 3.1.4. 3.2.2 Searches 126.96.36.199 Protocol Requirement The serviceprotocol MUST allow searching for domains by exactcontain the following search functions: 1. Domain name search given an exact match or areasonable subset of a domainname. 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. The serviceThis search SHOULD NOT require special transformations of internationalized domain names to accommodate this search. This search MUST comply with Section 3.2.8. The service MUSTprovide a mechanism to distribute this search across all applicable domain registries and registrars. There should be ameans to narrow thisthe search based onby names delegated under a particular TLD. The2. Domain registrant search mechanism SHOULD provide for differences in domain names betweenby either exact name or partial name match with the native representation andability to narrow the canonical form existing insearch to registrants of a particular TLD. 3. Domains hosted by a nameserver given the registry. 3.2.8 Result Set Limitsfully-qualified host name or IP address of a nameserver. The service MAY provide limitsdata sets for contacts, nameservers, and domains MUST be able to express and represent the numberattributes and allowable values of results from searchesregistration requests in domain registration and lookups to improve performance bottlenecks or comply with Section 3.1.1.provisioning protocols. The servicedata set for domains MUST be capable of providing tosupplying the clientvalues specified in Section 3.2.1. 188.8.131.52 Service Description Depending on the policy and need of an indication thatInternet registry, a result set has been truncatedserver operator may not allow all or any of these searches to return part or limited.all of the information. See Section 3.1.4. Access to information resulting from these searches may also be limited, depending on policy, by quantity. Section 3.2.4 describes these types of restrictions. Some Internet registries may also be participating in a query distribution system. See Section 3.1.11. 3.2.3 Serialization Support The service MUSTschemas used by the protocol SHOULD be capable of distinguishingoff-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 causescope of this condition as eitherdocument. 3.2.4 Result Set Limits 184.108.40.206 Protocol Requirement The protocol MUST contain a mechanismfeature, used at the discretion of a server operator, to improve performance bottlenecks, as specified above, orallow a meansserver to express to a client a limit on the number of complianceresults 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. 220.127.116.11.1 18.104.22.168 Service Description Client software will operate more usefully if it can understand reasons for the truncation of result sets. Of course, some Internet registries may not be able to expose their policies for the limiting of result sets, but, when it is possible, clients will have a better operational view. This may eliminate re-queries and other repeated actions that are not desirable. 3.2.5 DNS LabelDelegation Referencing 22.214.171.124 Protocol Requirement The serviceprotocol MUST use the delegation authority model available in DNS  to determineas the primary means for determining the authoritative source offor information about domain names. It is the intentionregarding domains or any other objects when applicable. 126.96.36.199 Service Description The intent of this requirement that a client be ableis to determine via DNS and queryhave clients use the DNS delegation model to find servers or set of serversauthoritative 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 delegatinginformation for example.com, the domain name,DNS zone for com should be queried. There are cases where resources will not naturally map into the domain registrar responsibleDNS delegation hierarchy. This requirement is not meant to force such a mapping. 3.2.6 Distribution for registeringDomain Registry Types 188.8.131.52 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. 184.108.40.206 Service Description Depending on the domain name if one is applicable, and theregistry/registrar model in use, technical data for a domain registrant ofmay only reside in one server while contact data for the same domain name. The service SHOULD provide procedures or mechanisms to allowmay only reside in a server operated by a separate entity. However, in manmy uses, this determination if it cannot be done using DNS. This allows the service to operate when an operator choosesis not to take advantage of DNS label referencing and during periods of transient or erroneous state of DNS configuration. 3.2.10 Distribution for Domain Registry Types Thethe situation. Therefore, the service MUST allowmust accommodate for the various registration distribution models of domain registry types described in Section 2.1.1 while complying with Section 3.1.7. 4. Feature Requirements Feature requirements describe the perceived need derived from3.2.7 Data Omission 220.127.116.11 Protocol Requirement When a value in an answer to a query cannot be given due to policy constraints, the functional requirements for specific technical criteriaprotocol MUST be capable of expressing the directory service. This section makes references to terms and definitions declaredvalue in Appendix A . This section usesno less than one of three ways: 1. complete omission of the term "service"value without explanation 2. an indication that the value cannot be given due to denoteinsufficient authorization 3. an indication that the setvalue cannot be given due to privacy constraints regardless of featuresauthorization status 18.104.22.168 Service Description Internet registries will have varying constraints regarding their ability to be provided by, andexpose certain types of data, usually social information. Server operators must have the expected behavior of, software builtability to meet these requirements in one or more protocols. These requirements are for the purpose of designing a technical specification. The words used inaccommodate this section are for complianceneed while client software will be more useful when provided with RFC2119 , do not reference or specifyproper explanations. Therefore, depending on policy, and speak only toa server operator has a choice between not returning the capabilities indata at all, signaling a permission error, or indicating a privacy constraint. 4. Feature Requirements Feature requirements describe the perceived need derived technology. For instance, this document may say thatfrom the service "MUST" support certain features. An actual service operator is always free to disable it (and then to return an error such as "permission denied").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 serviceprotocol MUST provide a mechanism capable of employing many authentication types and capable of extension for future authentication types. 4.2 Referrals To distribute queries for search continuations and to issue entity references, the serviceprotocol MUST provide a referral mechanism. 4.3 Common Referral Mechanism To distribute queries for search continuations and to issue entity references, the serviceprotocol 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 serviceprotocol MUST employ structured queries and responses. 4.5 Existing Schema Language To provide structured queries and responses and allow for minimal technological reinvention, the serviceprotocol MUST employ a pre-existing schema language. 4.6 Defined Schemas To provide for machine consumption as well as human consumption, the serviceprotocol MUST define schemas for use by the structured queries and responses. 4.7 Serialization Definition To provide for data escrow and allow for minimal technological reinvention, the service MUST employ a pre-existing serialization specification.5. Internationalization Considerations Requirements defined in this document MUST consider the best practices spelled out in . 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. The requirement in Section 3.1.4 must be weighed against other requirements specifying search or lookup capabilities. In addition, thisThis 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. References  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.  Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.  Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997.  Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985.  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.  Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.  Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  <http://www.ietf.org/proceedings/00dec/00dec-41.htm>  <http://www.ietf.org/proceedings/01aug/51-40.htm>  <http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15- Resume.pdf><http://www.uwho.verisignlabs.com/ Final-WhoIsPanel-Aug15-Resume.pdf>  <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/ min_database.html>  <http://www.nanog.org/mtg-0110/lookup.html> Author's Address Andrew L. Newton VeriSign, Inc. 21355 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: email@example.com URI: http://www.verisignlabs.com/http://zak.ecotroph.net/pea Appendix A. Glossary o TLD: Initials for "top level domain." Referes to domains in DNS 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 social 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 authenticated entity: A person, or person acting on behalf of an organization, who has provided validatable credentials of identification via client software to the directory service of an Internet registry. o non-authenticated entity: A person, or person acting on behalf of an organization, who has not provided validatable credentials of identification via client software to the directory service of an Internet registry. o privileged entity: A person, or person acting on behalf of an organization, with authorization to access data. o non-privileged entity: A person, or person acting on behalf on an organization, with no authorization to access data.defined by ISO. o privilegedsocial data: Data accessible by a privilegedcontaining names and contact information (i.e. postal addresses, phone numbers, e-mail addresses) of humans or legal entities. o non-privilegedoperational data: Data accessible by privileged entitiesnecessary to the operation of networks and non-privileged entities.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. Appendix B. Outstanding Issues The following outstanding issues have been discussed and have been assigned contributors to put forward proposed text. o Query Distribution and Non-generic Query Referrals - The working group has discussed issues surrounding query referrals and their impact on certain classes of servers in a query referral mesh. Proposals have been suggested for a robust referral mechanism and a separate transaction token-passing system to provide a means to solving this class of problems. o Internationalization - Because of Internationalized Domain Names (IDN's), it has been suggested that the requirements surrounding the support for them be further defined and more specific. Appendix C. Acknowledgements B.1C.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 ; December 10-15, 2000; San Diego, CA, USA o whoisfix BOF of the 51st IETF ; August 5-10, 2001; London, England o First UWho Consultation ; 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 ; October 1-5, 2001; Praque, Czech Republic o General Session of NANOG 23 ; 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.2C.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- firstname.lastname@example.org@lists.verisignlabs.com. To subscribe to this email list, send email to email@example.com with a subject line of "subscribe". Archives of this list may be found out http:// lists.verisignlabs.com/pipermail/ietf-not43/. B.3http://lists.verisignlabs.com/pipermail/ietf-not43/. C.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, andPatrick Mevzek.Mevzek, Marcos Sanz, and Vittorio Bertola. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2002).(2003). 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 assigns.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.