Network Working Group A. Newton Internet-Draft VeriSign, Inc. Expires: August 30, 2002 S. Kerr RIPE NCC March 1, 2002 Internet Registry Directory Requirements draft-newton-ir-dir-requirements-01 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 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 August 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Internet registries expose administrative and operational data via varying directory services. This document defines the common requirements for the directory services of these Internet registries. Newton & Kerr Expires August 30, 2002 [Page 1] Internet-Draft ir-dir-requirements March 2002 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Internet Registry Communities . . . . . . . . . . . . . . 5 2.1 Registries . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1 Regional Internet Registries . . . . . . . . . . . . . . . 5 2.1.2 Local Internet Registries . . . . . . . . . . . . . . . . 5 2.1.3 Internet Routing Registries . . . . . . . . . . . . . . . 5 2.1.4 Domain Registries . . . . . . . . . . . . . . . . . . . . 6 2.1.5 Domain Registrars . . . . . . . . . . . . . . . . . . . . 6 2.2 Implementers . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 End Users . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Service Providers and Network Operators . . . . . . . . . 7 2.3.2 Intellectual Property Holders . . . . . . . . . . . . . . 7 2.3.3 Law Enforcement . . . . . . . . . . . . . . . . . . . . . 7 2.3.4 Certificate Authorities . . . . . . . . . . . . . . . . . 7 2.4 Other Actors . . . . . . . . . . . . . . . . . . . . . . . 7 3. Functional Requirements . . . . . . . . . . . . . . . . . 8 3.1 Common Functions . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 Mining Prevention . . . . . . . . . . . . . . . . . . . . 8 3.1.2 Minimal Technical Reinvention . . . . . . . . . . . . . . 8 3.1.3 Standard and Extensible Schemas . . . . . . . . . . . . . 8 3.1.4 Level of Access . . . . . . . . . . . . . . . . . . . . . 8 3.1.5 Client Processing . . . . . . . . . . . . . . . . . . . . 9 3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . 9 3.1.7 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . 9 3.1.8 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . 9 3.1.9 Decentralization . . . . . . . . . . . . . . . . . . . . . 9 3.1.10 Query of Access Levels . . . . . . . . . . . . . . . . . . 9 3.2 RIR Functions . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Network Lookup . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Autonomous System Lookup . . . . . . . . . . . . . . . . . 10 3.2.3 DNS Referencing . . . . . . . . . . . . . . . . . . . . . 10 3.2.4 Network Search by Contact . . . . . . . . . . . . . . . . 10 3.3 IRR Functions . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1 Mirroring . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.2 Router Lookup . . . . . . . . . . . . . . . . . . . . . . 10 3.3.3 Route Lookup . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.4 Route set Lookup . . . . . . . . . . . . . . . . . . . . . 10 3.4 Domain Functions . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Domain Status Lookup . . . . . . . . . . . . . . . . . . . 10 3.4.2 Domain Registrant Search . . . . . . . . . . . . . . . . . 11 3.4.3 Domain Information Lookup . . . . . . . . . . . . . . . . 11 3.4.4 Nameserver Search . . . . . . . . . . . . . . . . . . . . 11 3.4.5 Escrow Support . . . . . . . . . . . . . . . . . . . . . . 11 3.4.6 Authentication Distribution . . . . . . . . . . . . . . . 11 3.4.7 Domain Name Search . . . . . . . . . . . . . . . . . . . . 11 3.4.8 DNS Referencing . . . . . . . . . . . . . . . . . . . . . 12 4. Feature Requirements . . . . . . . . . . . . . . . . . . . 13 Newton & Kerr Expires August 30, 2002 [Page 2] Internet-Draft ir-dir-requirements March 2002 4.1 Client Authentication . . . . . . . . . . . . . . . . . . 13 4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Common Referral Mechanism . . . . . . . . . . . . . . . . 13 4.4 Structured Queries and Responses . . . . . . . . . . . . . 13 4.5 Existing Schema Language . . . . . . . . . . . . . . . . . 13 4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . 13 4.7 Serialization Definition . . . . . . . . . . . . . . . . . 13 5. Internationalization Considerations . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 17 A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 19 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . 20 B.2 Contributions . . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 Newton & Kerr Expires August 30, 2002 [Page 3] Internet-Draft ir-dir-requirements March 2002 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[4] 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[3], to fulfill other needs, and proposals for the use of other technologies such as LDAP[1] and XML. The scope of the requirements captured in this document relate to the directory services of the specified Internet registries (Section 2.1) and their related communities (Section 2.2,Section 2.3, and Section 2.4). 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. The requirements captured in this document are for the purpose of designing technical specifications. The words used in this document for compliance with RFC2119[8] do not reference or specify policy and speak only to the capabilities in the derived technology. 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. Newton & Kerr Expires August 30, 2002 [Page 4] Internet-Draft ir-dir-requirements March 2002 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, implementers, end-users, and other actors. 2.1 Registries 2.1.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.1.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. The scope of requirements about address registries in this document relate to the communications between an end-user and an address registry (RIR, LIR, NIR). Inter-registry communication, or communication between RIR's, LIR's, and NIR's, is out of scope. 2.1.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[5]. 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. Newton & Kerr Expires August 30, 2002 [Page 5] Internet-Draft ir-dir-requirements March 2002 2.1.4 Domain Registries Domain registries are responsible for the registration of domains for use with DNS[2] and forward lookups (i.e. does not include the IN-ADDR.ARPA or IP6.ARPA domains). These registries have typically served two main domain functions: as the registry for a gTLD or as a 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 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 are not the subject of this document and may have requirements that are out of scope for this subject matter. 2.1.5 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 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 Newton & Kerr Expires August 30, 2002 [Page 6] Internet-Draft ir-dir-requirements March 2002 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.3 End Users 2.3.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. 2.3.2 Intellectual Property Holders Intellectual Property Holders have legal rights to the use of domain names based on copyright and trademark laws of various governments. 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.3.3 Law Enforcement Law enforcement agencies use the directory services of Internet registries in the enforcement of laws within their jurisdictions. 2.3.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 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-setting bodies, and other non-governmental organizations. Newton & Kerr Expires August 30, 2002 [Page 7] Internet-Draft ir-dir-requirements March 2002 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 protocol or protocols derived from these requirements. 3.1 Common Functions 3.1.1 Mining Prevention The service MUST have a mechanism to limit the amount of data that may be accessed. The service MAY have different limits for different types of data, as well as for authenticated and non-authenticated entities. The service SHOULD be capable of expressing to the client these access limitations based on queries per session per unit of time, queries per source IP address per unit of time, and total queries from all client sessions per unit of time. The service SHOULD be able to limit the amount of data based on the above types of limitations. 3.1.2 Minimal Technical Reinvention The service MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers of the total service solution and SHOULD make use of existing technology standards where applicable. The service MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force. The service MUST define one or more transport mechanisms for mandatory implementation. 3.1.3 Standard and Extensible Schemas The service MUST define 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. 3.1.4 Level of Access The service MUST be capable of authenticating priviledged entities and MUST be capable of restricting access of priviledged data to only priviledged entities. In addition, the service MUST be capable of serving both priviledged data and non-priviledged data and MUST allow for the classification of data, be it social or operational Newton & Kerr Expires August 30, 2002 [Page 8] Internet-Draft ir-dir-requirements March 2002 data, as priviledged data or non-priviledged data for the purpose of restricting its access. Note, this requirement makes no assumption about whether or not data should be priviledged but merely provides the ability. 3.1.5 Client Processing The service 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 Contact Lookup The service SHOULD allow access to social data of contact entities given a unique reference to the contact entity. 3.1.8 Nameserver Lookup The service SHOULD allow access to operational and social data of a nameserver given the fully-qualified host name or IP address of a nameserver. 3.1.9 Decentralization The service MUST be decentralized in design and principle and 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 service MUST NOT require aggregation of data indexes or hints. 3.1.10 Query of Access Levels The service SHOULD allow a client to submit a query about the various access levels for which a client may authenticate to the service. 3.2 RIR Functions 3.2.1 Network Lookup The service MUST provide access to operational and social data of a network given an IP address contained within the network. The service SHOULD provide access to address-to-name mapping information (IN-ADDR.ARPA or IP6.ARPA) of a network given an IP address contained within the network. Newton & Kerr Expires August 30, 2002 [Page 9] Internet-Draft ir-dir-requirements March 2002 3.2.2 Autonomous System Lookup The service MUST provide access to operational and social data of a network given the Autonomous System Number of a network. 3.2.3 DNS Referencing The service MUST use DNS[2] to determine the authoritative source of information about address-to-name mapping (IN-ADDR.ARPA or IP6.ARPA). The service SHOULD use DNSSEC[7] when available for this purpose. 3.2.4 Network Search by Contact The service SHOULD provide access to a list of networks given a contact name or a subset of a contact name associated with the networks. 3.3 IRR Functions 3.3.1 Mirroring The service SHOULD provide near real-time mirroring of operational routing data. The service MAY provide this capability via a mechanism separate from that which the service provides for other data access means. 3.3.2 Router Lookup The service MUST provide access to operational and social data of an Internet router given the fully-qualified domain name of the Internet router. 3.3.3 Route Lookup The service MUST provide access to operational and social data of a network route given the network number of a route. 3.3.4 Route set Lookup The service MUST provide access to operational and social data of a network route set given the name of the network route set. 3.4 Domain Functions 3.4.1 Domain Status Lookup The service MUST provide access to the status of a domain given the domain's fully qualified name. This status MUST indicate the Newton & Kerr Expires August 30, 2002 [Page 10] Internet-Draft ir-dir-requirements March 2002 activation status of the domain. The activation status is the same as would be available in Section 3.4.3. 3.4.2 Domain Registrant Search The service MUST provide the capability of searching for registrants by name or a reasonable name subset. 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.4.3 Domain Information Lookup The service MUST provide access to operational and social data specific to a domain given the domain's fully qualified name (FQDN). This information SHOULD include the activation status, registrant name and contact data, hosting nameservers, and the technical, billing, or other entity types associated with the domain and their relevant contact data. 3.4.4 Nameserver Search The service MAY allow the ability to list all domains hosted by a specific nameserver given the fully-qualified host name or IP address, if applicable, of the nameserver. The service MAY provide a mechanism to distribute this search across all applicable domain registries and registrars. 3.4.5 Escrow Support The service MUST provide a means to escrow data of domain registrars to an escrow entity using a common schema. This escrow capability SHOULD be "off-line" and "out-of-band" from the normal operations of the service. 3.4.6 Authentication Distribution The service MUST be capable of allowing a centralized authority entity the means to distribute authentication information of entities accessing the service. The service MUST not require all Internet registries to participate in distributed authentication and SHOULD allow the participation by an Internet registry in distributed authentication by many centralized authority entities. 3.4.7 Domain Name Search The service MUST allow searching for domains given a reasonable Newton & Kerr Expires August 30, 2002 [Page 11] Internet-Draft ir-dir-requirements March 2002 subset of a domain name. The service MUST provide a mechanism to distribute this search across all applicable domain registries and registrars. There should be a means to narrow this search based on a TLD. The search mechanism SHOULD provide for differences in domain names between the native representation and the canonical form existing in the registry. 3.4.8 DNS Referencing The service MUST use DNS[2] to determine the authoritative source of information about domain names. Newton & Kerr Expires August 30, 2002 [Page 12] Internet-Draft ir-dir-requirements March 2002 4. Feature Requirements Feature requirements describe the perceived need derived from the functional requirements for specific technical criteria of the directory service. This section makes references to terms and definitions declared in Appendix A . This section makes use of the term "service" to denote the protocol or protocols derived from these requirements. 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. 4.2 Referrals To distribute queries for search continuations and to issue entity references, the service MUST provide a referral mechanism. 4.3 Common Referral Mechanism To distribute queries for search continuation and to issue entity references, the service 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 service MUST employ structured queries and responses. 4.5 Existing Schema Language To provide structured queries and responses and allow for minimal technological reinvention, the service MUST employ a pre-existing schema language. 4.6 Defined Schemas To provide for machine consumption as well as human consumption, the service MUST define schemas for use 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. Newton & Kerr Expires August 30, 2002 [Page 13] Internet-Draft ir-dir-requirements March 2002 5. Internationalization Considerations Requirements defined in this document MUST consider the best practices spelled out in [6]. Newton & Kerr Expires August 30, 2002 [Page 14] Internet-Draft ir-dir-requirements March 2002 6. IANA Considerations There are no IANA considerations. Newton & Kerr Expires August 30, 2002 [Page 15] Internet-Draft ir-dir-requirements March 2002 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, 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. Newton & Kerr Expires August 30, 2002 [Page 16] Internet-Draft ir-dir-requirements March 2002 References [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167, June 1997. [4] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC 954, October 1985. [5] 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. [6] Alvestrand, H.T., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [7] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] [10] [11] [12] [13] Newton & Kerr Expires August 30, 2002 [Page 17] Internet-Draft ir-dir-requirements March 2002 Authors' Addresses Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA Phone: +1 703 948 3382 EMail: anewton@research.netsol.com URI: http://www.verisignlabs.com/ Shane Kerr RIPE NCC Singel 258 Amsterdam 1016 AB The Netherlands Phone: +31 20 535 4427 EMail: shane@ripe.net Newton & Kerr Expires August 30, 2002 [Page 18] Internet-Draft ir-dir-requirements March 2002 Appendix A. Glossary o TLD: Initials for "top level domain." Referes to domains in DNS[2]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 priviledged entity: A person, or person acting on behalf of an organization, with authorization to access data. o non-priviledged entity: A person, or person acting on behalf on an organization, with no authorization to access data. o priviledged data: Data accessible by a priviledged entities. o non-priviledged data: Data accessible by priviledged entities and non-priviledged entities. 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. Newton & Kerr Expires August 30, 2002 [Page 19] Internet-Draft ir-dir-requirements March 2002 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[9]; December 10-15, 2000; San Diego, CA, USA o whoisfix BOF of the 51st IETF[10]; August 5-10, 2001; London, England o First UWho Consultation[11]; 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[12]; October 1-5, 2001; Praque, Czech Republic o General Session of NANOG 23[13]; 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 B.2 Contributions Comments, suggestions, and feedback of significant substance have been provided by Leslie Daigle, Mark Kosters, and Cathy Murphy. Newton & Kerr Expires August 30, 2002 [Page 20] Internet-Draft ir-dir-requirements March 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. 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 & Kerr Expires August 30, 2002 [Page 21]