Network Working Group A. Newton
Internet-Draft VeriSign, Inc.
Expires: August 8, 2002 S. Kerr
RIPE NCC
February 7, 2002
Internet Registry Directory Requirements
draft-newton-ir-dir-requirements-00
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 8, 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 8, 2002 [Page 1]
Internet-Draft ir-dir-requirements-00 February 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 . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 8
3.1.6 Entity Referencing . . . . . . . . . . . . . . . . . . . . . 9
3.1.7 Contact Lookup . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.8 Nameserver Lookup . . . . . . . . . . . . . . . . . . . . . 9
3.1.9 Decentralization . . . . . . . . . . . . . . . . . . . . . . 9
3.2 RIR Functions . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Network Lookup . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Autonomous System Lookup . . . . . . . . . . . . . . . . . . 9
3.2.3 DNS Referencing . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 11
4. Feature Requirements . . . . . . . . . . . . . . . . . . . . 12
4.1 Client Authentication . . . . . . . . . . . . . . . . . . . 12
Newton & Kerr Expires August 8, 2002 [Page 2]
Internet-Draft ir-dir-requirements-00 February 2002
4.2 Referrals . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Structured Queries and Responses . . . . . . . . . . . . . . 12
4.5 Existing Schema Language . . . . . . . . . . . . . . . . . . 12
4.6 Defined Schemas . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Serialization Definition . . . . . . . . . . . . . . . . . . 12
5. Internationalization Considerations . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 18
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
B.1 Forums . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
B.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement . . . . . . . . . . . . . . . . . . 20
Newton & Kerr Expires August 8, 2002 [Page 3]
Internet-Draft ir-dir-requirements-00 February 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 8, 2002 [Page 4]
Internet-Draft ir-dir-requirements-00 February 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.
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.
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
Newton & Kerr Expires August 8, 2002 [Page 5]
Internet-Draft ir-dir-requirements-00 February 2002
served two main domain functions: as the registry for a gTLD or as a
registry for a ccTLD. In many 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 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
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.
Newton & Kerr Expires August 8, 2002 [Page 6]
Internet-Draft ir-dir-requirements-00 February 2002
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 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 influence and regulations placed
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 8, 2002 [Page 7]
Internet-Draft ir-dir-requirements-00 February 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 authenticated and non-authenticated
entities.
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.
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 for 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
data, as priviledged data or non-priviledged data for the purpose of
restricting its access.
3.1.5 Client Processing
The service MUST be capable of allowing machine parsable requests
Newton & Kerr Expires August 8, 2002 [Page 8]
Internet-Draft ir-dir-requirements-00 February 2002
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 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.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.
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.
Newton & Kerr Expires August 8, 2002 [Page 9]
Internet-Draft ir-dir-requirements-00 February 2002
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
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.
Newton & Kerr Expires August 8, 2002 [Page 10]
Internet-Draft ir-dir-requirements-00 February 2002
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
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. The service SHOULD use DNSSEC[7]
when available for this purpose.
Newton & Kerr Expires August 8, 2002 [Page 11]
Internet-Draft ir-dir-requirements-00 February 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 URIs
To distribute queries for search continuation and to issue entity
references, the service MUST define a URI 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 8, 2002 [Page 12]
Internet-Draft ir-dir-requirements-00 February 2002
5. Internationalization Considerations
Requirements defined in this document MUST consider the best
practices spelled out in [6].
Newton & Kerr Expires August 8, 2002 [Page 13]
Internet-Draft ir-dir-requirements-00 February 2002
6. IANA Considerations
There are no IANA considerations.
Newton & Kerr Expires August 8, 2002 [Page 14]
Internet-Draft ir-dir-requirements-00 February 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.
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 8, 2002 [Page 15]
Internet-Draft ir-dir-requirements-00 February 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] <http://www.ietf.org/proceedings/00dec/00dec-41.htm>
[10] <http://www.ietf.org/proceedings/01aug/51-40.htm>
[11] <http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-Resume
.pdf>
[12] <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/min_
database.html>
[13] <http://www.nanog.org/mtg-0110/lookup.html>
Newton & Kerr Expires August 8, 2002 [Page 16]
Internet-Draft ir-dir-requirements-00 February 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 8, 2002 [Page 17]
Internet-Draft ir-dir-requirements-00 February 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 8, 2002 [Page 18]
Internet-Draft ir-dir-requirements-00 February 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
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 8, 2002 [Page 19]
Internet-Draft ir-dir-requirements-00 February 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 8, 2002 [Page 20]