INTERNET-DRAFT Eric A. Hall Document: draft-ietf-crisp-lw-core-00.txt July 2002 Expires: January, 2003 Category: Standards-Track The Internet Resource Query Service and the Internet Resource Schema Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 1. Abstract This document describes an architectural framework for locating and retrieving information about network resources, using LDAPv3 for the data-formatting and query-processing services. This document also defines LDAP schema and searching rules for four Internet resource types: DNS domains, IPv4 addresses, IPv6 address, and AS numbers. The framework specified in this document also allows additional documents to define additional Internet resource types and their handling rules. Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 Table of Contents 1. Abstract..................................................1 2. Definitions and Terminology...............................3 3. Background, Objectives and Overview.......................4 3.1. Background.............................................4 3.2. Overview...............................................5 4. The LDAP-WHOIS Namespace..................................7 4.1. Namespace Example......................................7 4.2. The domainComponent LDAP Hierarchy....................10 4.3. The inetResources Container...........................11 4.4. Resource-Specific Entries.............................12 4.5. Redirects and Referrals...............................13 5. The LDAP-WHOIS Object Classes and Attributes.............18 5.1. The inetResources Object Class........................19 5.2. The inetAssociatedResources Object Class..............25 5.3. The referral Object Class.............................29 5.4. Object Class and Attribute Permissions................30 6. Search and Match Filters.................................31 6.1. Search Filter Expressions.............................31 6.2. Matching Filter Definitions...........................33 7. Query Processing Models..................................35 7.1. Top-Down Processing...................................35 7.2. Bottom-Up Processing..................................39 7.3. Targeted Search Processing............................44 7.4. Supplemental Query Processing Mechanisms..............46 8. Internationalization and Localization....................53 9. DIT Replication..........................................53 10. Transition Issues........................................54 10.1. NIC Handles...........................................54 10.2. Change-Logs...........................................55 10.3. Open Issues...........................................56 11. Security Considerations..................................56 12. IANA Considerations......................................57 13. Author's Addresses.......................................58 14. References...............................................58 15. Acknowledgments..........................................60 16. Changes from Previous Versions...........................60 Hall & Newton I-D Expires: August 2002 [page 2]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 2. Definitions and Terminology This document unites, enhances and clarifies several pre-existing technologies. Readers are expected to be familiar with the following specifications: RFC 2247 - Using Domains in LDAP/X.500 DNs RFC 2251 - Lightweight Directory Access Protocol (v3) RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. RFC 2254 - The String Representation of LDAP Search Filters RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2798 - Definition of the inetOrgPerson LDAP Object Class [namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named Subordinate References in LDAP Directories [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> - Internet Registry Directory Requirements The following abbreviations are used throughout this document: DIT (Directory Information Tree) - A DIT is a contained branch of the LDAP namespace, having a root of a particular distinguished name. "dc=example,dc=com" is used throughout this document as one DIT, with many example entries being stored in this DIT. DN (Distinguished Name) - A distinguished name provides a unique identifier for an entry, through the use of a multi- level naming syntax. Entries are named according to their location relevant to the root of their containing DIT. For example, "cn=inetResources,dc=example,dc=com" is a DN which uniquely identifies the "inetResources" entry within the "dc=example,dc=com" DIT. RDN (Relative DN) - An RDN provides a locally-scoped unique identifier for an entry. A complete, globally-unique DN is Hall & Newton I-D Expires: August 2002 [page 3]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 formed by concatenating the RDNs of an entry together. For example, "cn=admins,cn=inetResources,dc=example,dc=com" consists of two RDNs ("cn=admins" and "cn=inetResources") within the "dc=example,dc=com" DIT. RDNs are typically only referenced within their local scope. OID (Object Identifier) - An OID is a globally-unique, concatenated set of integers which provide a kind of "serial number" to attributes, object classes, syntaxes and other schema elements. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Background, Objectives and Overview 3.1. Background The WHOIS service was originally provided as a front-end to a centralized repository of ARPANET resources and users. Over time, multiple WHOIS information servers have been deployed which provide other kinds of information for various types of Internet resources. For example, there are scores of WHOIS servers which serve one or more of the top-level domains ("com", "jp", etc.), with each server providing information about the sub-domains that have been delegated beneath each of the managed TLDs, and which also provide information about the human operators of those domains, among other details. Similarly, there are WHOIS servers which provide information about different portions of the IPv4 address space. Similarly, there are WHOIS servers which are operated by service providers which provide information about the resources in use by that organization and its customers. All told, there are hundreds of WHOIS servers available on the public Internet, with each server providing general information about the particular network resources under the control of each organization. Unfortunately, the WHOIS specification does not define a strict set of data-typing or formatting requirements, and as a result, each of the different implementations provide information in slightly different ways. Some servers provide limited amounts of unstructured information, while others provide information in a highly-detailed and highly-structured form. Similarly, some Hall & Newton I-D Expires: August 2002 [page 4]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 servers provide information in only one language and charset, while others support multiple languages and charsets, and use input switches to control the output format. Essentially, every WHOIS server has its own data formats and syntaxes, with little consistency between them, which has made programmatic processing of the data difficult. Furthermore, each WHOIS server operates as a self-contained entity, with no knowledge or linkage between the different servers, meaning that WHOIS servers cannot redirect clients to other servers for additional information. Another concern is that the WHOIS services which are being operated today offer no means of client authentication, requiring that server operators essentially publish all data with a single "world-readable" permission. However, this single permission conflicts with the privacy and security policies of specific jurisdictions. A more flexible mechanism for controlling the release of physical and personal information is required in order to meet the requirements of the varying constituencies. There are many other secondary issues with the WHOIS service as it exists in current form. However, the largest problems are a lack of standardized data formats, a lack of widely-supported referral mechanisms, and lack of privacy and security controls, as described in the preceding text. This document attempts to address these issues by defining operational and protocol guidelines for a distributed and highly- structured WHOIS-like service, using the LDAP protocol for the query/response transfer service, and using LDAP schema for the search inputs, answer data, and redirection mechanisms. In short, the intention of this approach is to provide an extensible and scalable WHOIS service, leveraging the capabilities of LDAP. 3.2. Overview This document defines four basic service components and their interaction as part of a distributed resource-locator service. Each of these components work together to provide a structured and distributed resource-locator service. Specifically, this document only defines the elements which govern the core service. Separate documents define the individual resource types, their schema and matching filters, and so forth. Hall & Newton I-D Expires: August 2002 [page 5]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 As such, the architecture and protocols defined in this specification are purposefully designed to be capable of accommodating a variety of different data-types and usage models, including future uses which are not defined here. The four components of the core service model are: * Structured Namespace. This document makes use of an LDAP namespace which is built upon the existing DNS delegation hierarchy, and which is supplemented by a layered namespace consisting of service-specific containers and resource- specific entries. This namespace and the associated naming rules facilitate the programmatic formation of queries, structured data, and referrals. * Schema Definitions. This document reuses many existing LDAP schema definitions, but also introduces several new object classes, attributes, syntaxes and matching filters. Some of these definitions apply to the overall architecture, while others are concerned with specific resource types. * Searching Rules. This document defines several rules for forming queries which are designed to facilitate consistent answer sets, and to improve interoperability between compliant clients and servers. * Query Processing Models. This document defines three distinct query-processing models which may be used for locating the authoritative servers associated with a named resource. These include a "top-down" model which is designed for querying centrally-managed Internet resources, a "bottom-up" model which is designed for querying user- managed resources, and a "targeted search" model which is designed for querying known servers for information about known resources. This document also specifies protocol behavior for following subordinate reference referrals, continuation reference referrals, and attribute references. As stated above, this document defines core schema and matching rules, while external (related) documents define schema and matching rules for specific resource types. Among the resource types already defined (and partially reused herein) are: * [ldap-whois-dns] - <draft-ietf-crisp-lw-dns-00.txt> - Defining and Locating DNS Domains using the Internet Resource Query Service Hall & Newton I-D Expires: August 2002 [page 6]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 * [ldap-whois-ipv4] - <draft-ietf-crisp-lw-ipv4-00.txt> - Defining and Locating IPv4 Address Blocks using the Internet Resource Query Service * [ldap-whois-ipv6] - <draft-ietf-crisp-lw-ipv6-00.txt> - Defining and Locating IPv6 Address Blocks using the Internet Resource Query Service * [ldap-whois-asn] - <draft-ietf-crisp-lw-asn-00.txt> - Defining and Locating Autonomous System Numbers using the Internet Resource Query Service * [ldap-whois-user] - <draft-ietf-crisp-lw-user-00.txt> - Defining and Locating Contact Persons using the Internet Resource Query Service It is the intention of the author that additional resource types will be added to this framework over time. 4. The LDAP-WHOIS Namespace A critical aspect of this service is the use of a predictable naming syntax, both for the automatic creation of programmatic searches for data, and for publishing structured data and referrals. In order to ensure this predictability, this document defines a multi-layered syntax which MUST be used by all compliant implementations. The LDAP-WHOIS service also makes provisions for the use of multiple referral services for the purpose of redirecting LDAP clients to foreign directory information trees (DITs). This allows organizations to redirect queries to external service providers, consolidate DITs within a single server, maintain foreign objects within a private DIT (such as allowing a third-party router to exist as a separately managed resource within an end-user DIT), and allows answer sets to contain responses from multiple servers. 4.1. Namespace Example Figure 1 below shows a subset example of the LDAP-WHOIS namespace. This namespace will be used throughout this document to illustrate many of the concepts from this specification. Hall & Newton I-D Expires: August 2002 [page 7]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 DIT: dc=example,dc=com | +-cn=inetResources,dc=example,dc=com [top object class] [inetResources object class] | +-attribute: o | value: "Example Widgets, Inc. public network resources" | +-cn=example.com,cn=inetResources,dc=example,dc=com | [top object class] | [inetResources object class] | [inetDnsDomain object class] | | | +-attribute: inetDnsContacts | value: "ldap://ldap.example.com/cn=hostmaster, | ou=admins,dc=example,dc=com" | +-cn=2.0.192.in-addr.arpa, cn=inetResources,dc=example,dc=com | [top object class] | [inetResources object class] | [inetDnsDomain object class] | | | +-attribute: description | | value: "Example Widgets' reverse-lookup domain" | | Hall & Newton I-D Expires: August 2002 [page 8]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 | +-cn=cref1,cn=2.0.192.in-addr.arpa, | cn=inetResources,dc=example,dc=com | [top object class] | [inetResources object class] | [inetDnsDomain object class] | [referral object class] | | | +-attribute: ref | value: "ldap://ldap.example.com/cn=example.com, | cn=inetResources,dc=example,dc=com" | +-cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com [inetResources object class] [inetIpv4Network object class] | +-attribute: inetIpv4Contacts value: "ldap://ldap.example.com/cn=hostmaster, ou=admins,dc=example,dc=com" DIT: dc=2,dc=0,dc=192,dc=in-addr,dc=arpa | +-cn=inetResources [top object class] [inetResources object class] [referral object class] | +-attribute: ref value: "ldap://ldap.example.com/cn=inetResources, dc=example,dc=com" Figure 1: Namespace for Example Widgets' domain and network. Figure 1 shows different DITs, both of which are managed by the Example Widgets company. The "dc=example,dc=com" DIT is authoritative for the DNS domain of "example.com", while the "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for the reverse-lookup DNS domain of 2.0.192.in-addr.arpa and the IPv4 network of "192.0.2.0/24". Both DITs have container entries called "cn=inetResources". This container entry is responsible for holding all of the entries which are associated with the Internet resources that are being managed by the LDAP-WHOIS service. For example, the "cn=inetResources,dc=example,dc=com" entry contains a subordinate entry for "cn=example.com", which is a DNS domain that is being managed through the LDAP-WHOIS service, and also contains entries Hall & Newton I-D Expires: August 2002 [page 9]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 for the 2.0.192.in-addr.arpa reverse-lookup DNS domain and the 192.0.2.0/24 IPv4 network. The "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" entry only exists as a referral which will cause queries to be redirected to the "cn=inetResources,dc=example,dc=com" hierarchy. The naming syntax and rules are described throughout the remainder of this section 4.1. Figure 1 is only provided as an example a relatively complete namespace, for illustration and subsequent discussion purposes. 4.2. The domainComponent LDAP Hierarchy The top-level of the namespace defined for use with this service uses the domainComponent naming syntax specified in RFC 2247, which maps DNS domain names to domainComponent ("dc=") labels to form a DIT. Each DIT represents a primary identifier for the management body that is offering an LDAP server, and as such, provides a primary identifier for the Internet resources under the control of that organization. The DITs will be used to build LDAP queries for specific resources, and will also be used to locate the LDAP servers associated with the controlling organization. Examples of the RFC 2247 syntax are shown in Figure 2 below. Figure 2: The LDAP-WHOIS domainComponent Namespace. dc=. | +----------------+---------------+ / | \ dc=arpa dc=com dc=[...] | | +--+--+ dc=example / \ dc=in-addr dc=ip6 A complete sequence of domainComponent DNs represents the scope of the DIT. For example, a DIT with the distinguished name (DN) of "dc=com" is authoritative for all of the LDAP resources within the "com" DNS domain (for many LDAP-WHOIS queries, this will also include any sub-domains under the "com" domain). Meanwhile, a DIT with the DN of "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" DIT is authoritative for domain name resources within the reverse-lookup Hall & Newton I-D Expires: August 2002 [page 10]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 "2.0.192.in-addr.arpa" DNS domain, as well as the IPv4 network addresses within the 192.0.2.0/24 network. At the other extreme, the dc="." DIT is responsible for all Internet resources (although this DIT is rarely used). Since the DIT determines the scope of control over a set of resources, DITs that overlap also have overlapping scopes of control. For example, the "dc=com" and "dc=example,dc=com" DITs can both provide information about the "www.example.com" domain name resource. In order to allow end-users to specify which scope they wish to work with for any given query, this document defines three different query models (these are described in section 7). When the LDAP servers associated with the chosen DIT need to be located, the domainComponent DNs from the DIT are mapped to a DNS domain name, and a query is issued for the LDAP servers associated with that domain name (this process is also described in section 7). This means that the authority to process LDAP searches for a DIT comes directly from the portion of the DNS namespace already under the control of that management body. For example, the LDAP servers which are used to process queries for the "dc=com" DIT will be located by querying the DNS zone responsible for the "com" portion of the DNS namespace, and so forth. 4.3. The inetResources Container This specification requires the use of a mandatory LDAP container entry with the well-known relative distinguished name (RDN) of "cn=inetResources", which MUST exist in the root of every DIT that provides LDAP-WHOIS services. All resource-specific entries which are provided on public LDAP-WHOIS servers MUST be stored in the cn=inetResources container entry. The primary motivation for this naming is for predictability, in that it allows searches to be formed programmatically (a search base for resources in the "dc=example,dc=com" DIT can be programmatically formed as "cn=inetResources,dc=example,dc=com", for example). However, there are several other motivating factors for this naming syntax. For example, it is easier to apply a single anonymous read-only permission to the inetResources container than it is to apply the same permission to multiple discrete entries, which in turn means that it is more likely that the appropriate restrictions will be defined. Furthermore, the use of a single container entry for all Hall & Newton I-D Expires: August 2002 [page 11]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 of an organization's Internet resources allows that branch of the DIT to be redirected to another DIT through the use of a single referral operation (this will be particularly important when the LDAP servers that are located by DNS lookups are not the same servers that provide LDAP-WHOIS services). Another reason to use this naming syntax is that it shelters clients from server-side vagaries with DIT entries (where different vendors use different object classes to define the DITs). All told, the use of the "cn=inetResources" RDN facilitates smooth operations, and is important enough to justify the MANDATORY usage of this naming syntax. 4.4. Resource-Specific Entries This document defines four Internet resource types, each of which have their own naming rules. However, each resource type has a consistent naming principle, in that the specific managed resource has an RDN which uniquely identifies that resource, with the RDN residing within the inetResources container entry. For example, an entry for the "www.example.com" domain name resource stored in the "dc=example,dc=com" DIT would have a DN of "cn=www.example.com,cn=inetResources,dc=example,dc=com", while an entry for the "192.0.2.0/24" IPv4 network resource would have a DN of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com". Although the relative naming syntax is different for each resource type, the resource naming is consistent for each type, and the position of the RDN within the DN is also predictable. Most resource types cannot be located through simple LDAP browsing and equality matches. Instead, resource-specific entries use structured naming rules in order to facilitate the extensible match search operations which are specific to each of the defined resource types. For example, there is not likely to be a specific entry for every possible IPv4 address. In order to allow the appropriate entry to be located, however, the client can use the inetIpv4NetworkMatch extensible matching search operation, which locates the appropriate entry based on the search input. The naming rules associated with each resource type are provided in section 5, along with the schema definitions for each of the resource types. The extensible matching filters associated with each resource type are described in section 6. Hall & Newton I-D Expires: August 2002 [page 12]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 4.5. Redirects and Referrals A critical objective behind this service is for servers to be able to redirect clients to other servers, entries, or DITs, when this is necessary or desirable. Towards this end, this document specifies three methods for generating and processing redirects and referrals: subordinate reference referrals, continuation reference referrals, and attribute references. Subordinate reference referrals indicate that the queried entry is an alias for some other entry, and that the query has to be restarted in order for the current operation to be completed. Meanwhile, continuation references indicate that the search was successfully initiated, but that additional queries are required for the original query to be completely exhausted. Finally, attribute references simply indicate that supplemental data is available at some other location, but that no additional queries are required to satisfy the current operation. NOTE: RFC 2251 defines a superior reference referral which is used as a "default referral" for out-of-scope searches. However, this application specifically excludes support for superior reference referrals. Any superior reference referrals which are encountered as a part of this service are to be treated as errors. Subordinate references and continuation references use the ref attribute and referral object class defined in [namedref]. Attribute references use a superset of the formatting rules associated with the labeledURI attribute, as defined in RFC 2079. All of these mechanisms use LDAP URLs as their input data, although these URLs have service-specific restrictions that are somewhat tighter than the source specifications allow. Among these rules: * All referenced entries MUST comply with the naming syntax rules specified in this document. This means that all entries MUST use the domainComponent ("dc=") naming syntax for their DITs, resource-specific entries MUST reside in the inetResources container entry, and resource-specific entries MUST comply with the naming rules for the resource type in question. Hall & Newton I-D Expires: August 2002 [page 13]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 * Referral sources and targets MUST have the same resource- specific object classes defined (for example, the referral source and target for a DNS domain resource would both have the inetDnsDomain object class defined). This is a prerequisite for the proper handling of the search filters specified in this document. Attribute references are not referrals, so they are exempt from this requirement. * Referenced entries MAY exist as referrals to other entries, but recursive referrals are discouraged. * Except where otherwise noted, the protocol identifier of a URL MUST specify the LDAP service type. Although general- purpose LDAP referrals are allowed to specify any URL, LDAP-WHOIS referrals and references are intended to be used for automated queries, so the use of other protocols or services is expressly forbidden. * The host identifier of a URL MUST specify either an IP address or a domain name. URLs which do not provide host identifiers are invalid in all cases. * URLs MUST be provided and stored in a URL-safe format. For example, the IPv4 and IPv6 network address syntaxes defined in this document make use of the forward-slash ("/") character to indicate a subnet prefix, and if this character needs to be provided in a URL, it must be provided in the escaped form ("%2F" in this example). Furthermore, some of the matching rules described in this document require that the URLs also be stored in this format in order for the searches to succeed. * Implementations MUST NOT restrict URL values to verifiable entries from local partitions. Implementations MAY validate targets when the partition is known and accessible, but a lack of knowledge regarding a target MUST NOT be cause to prevent the entry from being specified. Clients MAY implement support for additional protocol identifiers if they wish to act upon URLs which are provided in conflict with the requirements above. However, clients MUST NOT violate any other mandates in this document while doing so (in particular, clients MUST NOT break the query-processing procedures defined in section 7 of this document). Hall & Newton I-D Expires: August 2002 [page 14]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 Each of the supported redirection mechanisms are discussed in more detail below. 4.5.1. Subordinate reference referrals Subordinate reference referrals are returned when the search base specified in a query names an entry which exists as a referral object class that points to some other entry. Any of the named entries specified in section 4 of this document MAY be defined as subordinate reference referrals which point to other entries. However, almost all of the search functions defined for use by this service use the inetResources container entry as the search base (the exceptions to this rule are targeted searches for explicit entries), so subordinate reference referrals will most commonly be seen when an inetResources container entry has been redirected to an inetResources container in another DIT. For example, the namespace shown in Figure 1 has an entry of "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" defined with the referral object class, with the ref attribute value pointing to the LDAP server of "ldap.example.com" and the DN of "cn=inetResources,dc=example,dc=com". Any queries for resources within "cn=inetResources,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" would be answered with that subordinate reference referral, and these queries would have to be restarted using the specified search base and server before they would be processed. Servers MUST support the use of subordinate reference referrals for this purpose, and clients MUST be prepared to accept and process any subordinate reference referrals in answer sets. When subordinate reference referrals are used for this purpose, the referral source MUST be defined with the referral object class, and MUST also be defined with the appropriate object class for that resource type. For example, a "cn=inetResources" entry which provided a subordinate reference referral would need to have both the referral and inetResources object classes defined, while a DNS domain resource such as "dc=example.com" would need to have both the referral and inetDnsDomain object classes defined (among the other object class definitions which were required for that entry). Referral targets need to use whatever object classes are appropriate for the resource in question, and MAY also be referrals to other entries. Hall & Newton I-D Expires: August 2002 [page 15]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 Client rules for processing subordinate reference referrals are given in section 7.4.1. 4.5.2. Continuation reference referrals Continuation reference referrals are returned when a search operation has been successfully processed by the queried server, but the answer data also includes referrals to other entries. These referrals are often provided as supplemental data to an answer set, although this is not required (a continuation reference referral can be the only response, but it won't be the only response in the common case). For example, the namespace shown in Figure 1 has an entry of "cn=cref1,cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example, dc=com" defined with the referral object class, with the ref attribute value pointing to the LDAP server of "ldap.example.com" and the DN of "cn=example.com,cn=inetResources,dc=example,dc=com". Any answers to any queries about "cn=2.0.192.in-addr.arpa" would also include the continuation reference referral, and new queries for the referral target would have to be issued before the original queries were completely processed. Servers MUST support the use of continuation reference referrals for this purpose, and clients MUST be prepared to accept and process any subordinate reference referrals in answer sets. When continuation reference referrals are used for this purpose, entries MAY exist for the queried resource, but one or more entries MUST exist with the referral object class defined, and which provide LDAP URLs that point to other entries which have additional information about the resource in question. Continuation reference referrals are returned in response to specific extensible match queries, and have specific naming requirements which are necessary for the matching functions to work properly. These considerations are described in 7.4.3. Client rules for processing continuation reference referrals are also given in section 7.4.3. Hall & Newton I-D Expires: August 2002 [page 16]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 4.5.3. Attribute references This document defines attribute references as attribute values which provide LDAP URLs, for the purpose of providing pointers to contextually-related information regarding the entry currently being viewed. Attribute references use the same basic syntax as the labeledURI attribute defined in RFC 2079, although there are additional restrictions, as described above. The contact attributes defined in this document use the attribute reference rules and formats to provide role-specific pointers to inetOrgPerson entries. Whenever one of these attributes is encountered, it is up to the client to deconstruct the provided URLs in order to locate and read the inetOrgPerson entries, although such actions are secondary to the original query process, and will typically only be performed at the user's request. For example, the namespace shown in Figure 1 has an entry of "cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com" defined with the inetIpv4Network object class, with the inetIpv4Contacts attribute value pointing to the LDAP server of "ldap.example.com" and the DN of "cn=hostmaster,ou=admins,dc=example,dc=com". When this attribute is provided as part of an answer to a query, a client MAY choose to follow this URL for information about that contact, although this would be considered a new and separate query, and would not be required to satisfy the original query. Note that the attribute reference URLs are similar to the URLs defined in RFC 2079, and use a two-part notation of "url://any.host:port/any/path description", with the "description" string providing a free-text description of the target specified by the URL. When the descriptive text is provided in an attribute reference, it SHOULD be displayed to the user as potentially informative data. Client rules for processing attribute references are given in section 7.4.4. 4.5.4. labeledURI references Some of the object classes defined in this document make use of the labeledURI attribute, as defined by RFC 2079. These attributes (and their values) are not governed by this document, but instead are governed by RFC 2079. As such, the rules set forth in RFC 2079 Hall & Newton I-D Expires: August 2002 [page 17]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 always apply to those attributes. In particular, this means that those attribute values may reference any protocol (such as http://) and are not restricted to LDAP protocol targets. 5. The LDAP-WHOIS Object Classes and Attributes This document defines a general framework for locating information about public network resources in a distributed environment, and a critical element of this definition are schema definitions for the object classes and attributes that provide this information. Towards that end, this document defines a schema for the global inetResources object class which is inherited by all of the resource-specific types, defines four resource-specific object classes, and defines a generalized object class for cross- referencing resources. This document also takes advantage of some pre-existing schema definitions (in particular, the inetOrgPerson object class), where suitable schema were available. Each of the schema definitions provided in this document include attribute definitions, naming rules, and other definitions which are designed to facilitate searching and browsing Internet resources. The following resource definitions are provided in this section: * Organizational and summary data. The inetResources object class defines a variety of general-purpose attributes for describing an organization and its resources. For example, there is a free-text attribute which may be used to provide general comments about the organization or the resources under its control, attributes for providing general-use postal and email addresses, and so forth. The inetResources object class also defines several attributes which may be used to provide attribute references for a variety of administrative roles. * Associated objects. Internet resources are typically assigned by independent entities, although there is often an extensive amount of cross-pollination. For example, AS Numbers are typically associated with IPv4 and IPv6 address blocks, with this association being considered as a mandatory linkage. However, less-formal associations also often exist, such as a private organization associating an IP address block with a specific DNS domain, or where a regional authority is responsible for all domain name and IP address delegations. Due to this flexibility, the LDAP- Hall & Newton I-D Expires: August 2002 [page 18]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 WHOIS service provides an auxiliary object class for associated objects which may be used with any of the resource-specific object classes defined in this document. Each of the attributes and object classes listed above represent the Internet-wide network resources which MAY be offered by an LDAP-WHOIS server. It is expected that additional network resource definitions will be provided by other documents. 5.1. The inetResources Object Class The inetResources object class is a structural object class which defines the attributes associated with a "cn=inetResources" container entry, and which provides general information about the network resources associated with the current DIT. 5.1.1. Naming syntax This document requires the presence of an entry named "cn=inetResources" in the root of every DIT which provides LDAP- WHOIS services. 5.1.2. Schema definition Every DIT which provides public LDAP-WHOIS data MUST have a "cn=inetResources" entry in the root of the DIT. The inetResources entry MUST exist with the top and inetResources object classes defined. If the entry exists as a referral, the entry MUST also be defined with the referral object class, in addition to the above requirements. The inetResources object class is a structural object class which is subordinate to the top abstract class, and which MUST be treated as a container class capable of holding additional subordinate entries. The inetResources object class has one mandatory attribute which is "cn" (the naming attribute), and also has several optional attributes. Each of the other object classes defined by this document are subordinate to the inetResources object class and inherit the attributes defined for the inetResources object class. Hall & Newton I-D Expires: August 2002 [page 19]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 The inetResources object class is intended to provide summary information about a collection of resources under the control of a single organization or management body. For example, the mail attribute is intended to be used as a general-purpose email address for the organization as a whole (such as "info@example.com"), rather than being used as an email address for a particular administrative role. Because this object class is also inherited by the resource-specific object classes, these attributes can be defined at each of the subordinate entries if a global set of values is undesirable or unfeasible. The inetResources object class provides several multi-valued contact-related attributes for a variety of well-known administrative roles. This model allows the inetResources entry and each of the subordinate managed resources to share a common set of administrative roles, or to have unique roles for each resource, as seen fit by the managing entity. The contact attribute values follow the same rules as the labeledURI attribute defined in RFC 2079, with additional restrictions as described in section 4.5 of this document. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. Since multiple directory trees can share a single inetResources entry (through the use of subordinate reference referrals), it is important for the associated data to be applicable for all of the objects which refer to it. For example, it would be effective for a small private company to use a shared set of inetResources attributes for their DNS domain names and IP network blocks, but it would probably be counter-productive for a global ISP to share contact data across all of their hosted domains and routed networks. If separate contacts are required for each resource, the contact data should be specified within each entry, rather than being linked to the inetResources entry. The schema definition for the inetResources object class is as follows: Hall & Newton I-D Expires: August 2002 [page 20]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 inetResources ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The inetResources container for the LDAP-WHOIS service' SUP top STRUCTURAL MUST cn MAY ( o $ ou $ description $ inetResourceComments $ businessCategory $ telephoneNumber $ facsimileTelephoneNumber $ mail $ labeledURI $ preferredDeliveryMethod $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ street $ l $ st $ c $ inetAbuseContacts $ inetAbuseContactsModifiedBy $ inetAbuseContactsModifiedDate $ inetGeneralContacts $ inetGeneralContactsModifiedBy $ inetGeneralContactsModifiedDate $ inetSecurityContacts $ inetSecurityContactsModifiedBy $ inetSecurityContactsModifiedDate $ inetTechContacts $ inetTechContactsModifiedBy $ inetTechContactsModifiedDate $ inetGeneralDisclaimer ) ) The attributes from the inetResources object class are described below: businessCategory, see RFC 2256, section 5.16 c (country), see RFC 2256, section 5.7 cn (commonName), see RFC 2256, section 5.4 description, see RFC 2256, section 5.14 facsimileTelephoneNumber, see RFC 2256, section 5.24 inetAbuseContacts ( 1.3.6.1.4.1.7161.1.0.1 NAME 'inetAbuseContacts' DESC 'Contacts for reporting abusive behavior or acceptable-use policy violations.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetAbuseContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContactsModifiedBy' DESC 'Person who last modified the inetAbuseContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: August 2002 [page 21]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 inetAbuseContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetAbuseContactsModifiedDate' DESC 'Last modification date of the inetAbuseContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetGeneralContacts ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetGeneralContacts' DESC 'Contacts for general administrative issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetGeneralContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetGeneralContactsModifiedBy' DESC 'Person who last modified the inetGeneralContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetGeneralContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetGeneralContactsModifiedDate' DESC 'Last modification date of the inetGeneralContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetGeneralDisclaimer ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetResourceComments' DESC 'General disclaimer text regarding this data' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) inetResourceComments ( 1.3.6.1.4.1.7161.1.0.8 NAME 'inetResourceComments' DESC 'General comments about this entry' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) inetSecurityContacts ( 1.3.6.1.4.1.7161.1.0.9 NAME 'inetSecurityContacts' DESC 'Contacts for general security issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Hall & Newton I-D Expires: August 2002 [page 22]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 inetSecurityContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.10 NAME 'inetSecurityContactsModifiedBy' DESC 'Person who last modified the inetSecurityContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetSecurityContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.11 NAME 'inetSecurityContactsModifiedDate' DESC 'Last modification date of the inetSecurityContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetTechContacts ( 1.3.6.1.4.1.7161.1.0.12 NAME 'inetTechContacts' DESC 'Contacts for general technical issues.' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) inetTechContactsModifiedBy ( 1.3.6.1.4.1.7161.1.0.13 NAME 'inetTechContactsModifiedBy' DESC 'Person who last modified the inetTechContacts attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetTechContactsModifiedDate ( 1.3.6.1.4.1.7161.1.0.14 NAME 'inetTechContactsModifiedDate' DESC 'Last modification date of the inetTechContacts attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) l (locality), see RFC 2256, section 5.8 labeledURI, see RFC 2079 mail, see RFC 2798, section 9.1.3 o (organization), see RFC 2256, section 5.11 ou (organizational unit), see RFC 2256, section 5.12 Hall & Newton I-D Expires: August 2002 [page 23]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 physicalDeliveryOfficeName, see RFC 2256, section 5.20 postalAddress, see RFC 2256, section 5.17 postalCode, see RFC 2256, section 5.18 postOfficeBox, see RFC 2256, section 5.19 preferredDeliveryMethod, see RFC 2256, section 5.29 st (stateOrProvinceName), see RFC 2256, section 5.9 street (streetAddress), see RFC 2256, section 5.10 telephoneNumber, see RFC 2256, section 5.21 5.1.3. Example An example of the inetResources object class in use is shown in Figure 3 below. cn=inetResources,dc=example,dc=com [top object class] [inetResources object class] | +-attribute: o | value: "Example Widgets' network resources" | +-attribute: inetGeneralContacts | value: "ldap://ldap.example.com/cn=admins,ou=admins, | dc=example,dc=com" | +-attribute: telephoneNumber | value: "1-800-555-1212" | +-attribute: mail | value: "info@example.com" | +-attribute: inetResourceComments value: "Please don't send complaints to the postmaster@example.com mailbox." Figure 3: The Example Widgets inetResources container entry. Hall & Newton I-D Expires: August 2002 [page 24]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 5.2. The inetAssociatedResources Object Class The inetAssociatedResources object class defines cross-reference attributes which may be used with any of the object classes defined in this document. For example, it allows inetDnsDomain object class entries to be associated with IPv4 networks, or even to other DNS domains, if that information is known (this information may be useful if a single organization has multiple DNS domains registered). Furthermore, it allows inetOrgPerson object classes to be associated with managed resources such as IP networks or DNS domains. In short, any resource can be associated with any other resource through the use of this object class. The inetAssociatedResources object class MUST NOT be associated with an entry that only exists as a referral source. 5.2.1. Naming syntax The inetAssociatedResources object class is an auxiliary object class, and not a structural object class. Entries which use this object class definition are primarily defined under the rules associated with the structural object class that defines the Internet resource in question. As such, the naming rules associated with the structural object class in use with that entry take precedence. Therefore, the inetAssociatedResources object class does not define a naming syntax. 5.2.2. Schema definition The inetAssociatedResources object class is an auxiliary object class which is subordinate to the top object class. The inetAssociatedResources object class has no mandatory attributes, although it does have several optional attributes. Although the inetAssociatedResources object class is subordinate to the top object class, it is intended to only be associated with the resource-specific structural object classes defined in this document. For example, the inetAssociatedResources object class is not likely to provide much value when it is associated with the inetResources object class, since the inetResources object class does not specifically define any resources (and since it does not define resources, it cannot define any associated resources). On the other hand, it is reasonable for the inetAssociatedResources object class to be associated with an inetOrgPerson object class Hall & Newton I-D Expires: August 2002 [page 25]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 entry, particularly if the referenced person (or role) is responsible for the management of multiple resources. Each of the associated resource attributes provide multi-valued data, using the syntax notations which are specific to the resource in question. For example, the inetAssociatedDnsDomain attribute provides associated DNS domain name resources using a multi-valued array, with each DNS domain name using the inetDnsDomainSyntax naming rules. The various ModifiedBy and ModifiedDate attributes SHOULD be treated as operational attributes. Their values SHOULD be filled in automatically by the database management application, and SHOULD NOT be returned except when explicitly requested. The schema definition for the inetAssociatedResources object class is as follows: inetAssociatedResources ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC 'Network resources associated with this entry.' SUP top AUXILIARY MAY ( inetAssociatedDnsDomains $ inetAssociatedDnsDomainsModifiedBy $ inetAssociatedDnsDomainsModifiedDate $ inetAssociatedIpv4Networks $ inetAssociatedIpv4NetworksModifiedBy $ inetAssociatedIpv4NetworksModifiedDate $ inetAssociatedIpv6Networks $ inetAssociatedIpv6NetworksModifiedBy $ inetAssociatedIpv6NetworksModifiedDate $ inetAssociatedAsNumbers $ inetAssociatedAsNumbersModifiedBy $ inetAssociatedAsNumbersModifiedDate ) ) The attributes from the inetAssociatedResources object class are described below: inetAssociatedAsNumbers ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC 'The autonomous system numbers associated with this entry.' EQUALITY caseIgnoreMatch SYNTAX inetAsNumberSyntax ) Hall & Newton I-D Expires: August 2002 [page 26]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 inetAssociatedAsNumbersModifiedBy ( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedAsNumbersModifiedBy' DESC 'Person who last modified the inetAssociatedAsNumbers attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedAsNumbersModifiedDate ( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedAsNumbersModifiedBy' DESC 'Last modification date of the inetAssociatedAsNumbers attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedDnsDomains ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedDnsDomains' DESC 'The DNS domains associated with this entry.' EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax ) inetAssociatedDnsDomainsModifiedBy ( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedDnsDomainsModifiedBy' DESC 'Person who last modified the inetAssociatedDnsDomains attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedDnsDomainsModifiedDate ( 1.3.6.1.4.1.7161.1.5.7 NAME 'inetAssociatedDnsDomainsModifiedBy' DESC 'Last modification date of the inetAssociatedDnsDomains attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedIpv4Networks ( 1.3.6.1.4.1.7161.1.5.8 NAME 'inetAssociatedIpv4Networks' DESC 'The IPv4 networks associated with this entry.' EQUALITY caseIgnoreMatch SYNTAX inetIpv4NetworkSyntax ) Hall & Newton I-D Expires: August 2002 [page 27]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 inetAssociatedIpv4NetworksModifiedBy ( 1.3.6.1.4.1.7161.1.5.9 NAME 'inetAssociatedIpv4NetworksModifiedBy' DESC 'Person who last modified the inetAssociatedIpv4Networks attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedIpv4NetworksModifiedDate ( 1.3.6.1.4.1.7161.1.5.10 NAME 'inetAssociatedIpv4NetworksModifiedDate' DESC 'Last modification date of the inetAssociatedIpv4Networks attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedIpv6Networks ( 1.3.6.1.4.1.7161.1.5.11 NAME 'inetAssociatedIpv6Networks' DESC 'The IPv6 networks associated with this entry.' EQUALITY caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax ) inetAssociatedIpv6NetworksModifiedBy ( 1.3.6.1.4.1.7161.1.5.12 NAME 'inetAssociatedIpv6NetworksModifiedBy' DESC 'Person who last modified the inetAssociatedIpv6Networks attribute.' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE distributedOperation ) inetAssociatedIpv6NetworksModifiedDate ( 1.3.6.1.4.1.7161.1.5.13 NAME 'inetAssociatedIpv6NetworksModifiedDate' DESC 'Last modification date of the inetAssociatedIpv6Networks attribute.' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE distributedOperation ) Hall & Newton I-D Expires: August 2002 [page 28]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 5.2.3. Example An example of the inetAssociatedResources object class is shown in Figure 4 below. cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com [top object class] [inetResources object class] [inetIpv4Network object class] [inetAssociatedResources object class] | +-attribute: description | value: "The example.com network" | +-attribute: inetAssociatedAsNumbers | value: "65535" | +-attribute: inetAssociatedDnsDomains value: "example.com" Figure 4: The inetAssociatedResources attributes associated with the 192.0.2.0/24 IPv4 network entry. 5.3. The referral Object Class This document allows the use of the referral object class to define subordinate reference referrals and continuation reference referrals for inetResources container entries and all of the resource-specific entries. Referral entries MUST conform to the schema specification defined in [namedref]. In particular, referral entries MUST NOT contain any user-definable attributes other than the mandatory "cn" naming attribute and the mandatory "ref" operational attribute. By extension, referral entries MUST be leaf nodes, and MUST NOT have any subordinate entries defined at the referral source. Furthermore, in order to facilitate programmatic access to this data, LDAP URLs provided in ref attributes MUST refer to entries which use the same object classes as the source entry, MUST refer to an entry in a DIT which uses the domainComponent object class syntax ("dc="), and MUST specify the LDAP protocol-type. Hall & Newton I-D Expires: August 2002 [page 29]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 5.4. Object Class and Attribute Permissions The information presented through the LDAP-WHOIS service will be used for many operational and problem-resolution purposes. In order for this information to be suitable for this purpose, it must be accurate. In order to ensure the veracity of the information, a minimal set of operational guidelines are provided in this section. For the most part, these rules are designed to prevent unauthorized modifications to the data. Note that these rules only apply to data which is willingly provided; no data is required to be entered, but where the data is provided, it MUST be accurate, and it MUST be secured against unauthorized modifications. * The inetResources container entry and all of the resource- specific subordinate entries within every public DIT that provides LDAP-WHOIS resources SHOULD have anonymous read- only access permissions, and SHOULD NOT have anonymous add, delete or modify permissions. * With the exception of contact-related attributes from the inetOrgPerson object class, each attribute MAY have whatever restrictions are necessary in order to suit local security policies, government regulations or personal privacy concerns. When the inetOrgPerson object class is used to provide contact details, the mail attribute MUST be defined, SHOULD be valid, SHOULD have read-only anonymous access, and SHOULD NOT have anonymous add, delete or modify permissions. By using the inetOrgPerson object class, it is expected that existing contact-related entries can be reused. If reusing these entries is undesirable or unfeasible, entries with the necessary access SHOULD be made available. Note that contact pointers are entirely optional and are not required to exist. However, where they exist, they MUST comply with the above requirements. * End-users and implementers SHOULD provide anonymous access to the creatorsName, createTimestamp, modifiersName and modifyTimestamp operational attributes associated with each entry in the inetResources branch, since this information is useful for determining the age of the information. Hall & Newton I-D Expires: August 2002 [page 30]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 * Server administrators MAY define additional add, delete or modify permissions for authenticated users, using any LDAPv3 authentication mechanisms they wish. In particular, delegation entities MAY provide for the remote management of delegated resources (such as assigning modification privileges to the managers of a particular delegated domain or address block), although this is entirely optional, and is within the sole discretion of the delegation body. External applications SHOULD NOT make critical decisions based on the information provided through this service without having reason to trust the veracity of the information. Clients and users SHOULD limit the use of unknown or untrusted information to routine purposes. 6. Search and Match Filters LDAP search filters are fairly flexible, in that they allow for a wide variety of configurable elements, such as the maximum number of entries which are returned, the type of comparison operation that needs to be performed, and other details. In order to promote interoperability, default values are defined here for many of these elements, although these defaults are only applicable when they are used with the LDAP-WHOIS service. In particular, this document defines several suggested and mandatory search filter qualifiers, which are described in detail in section 6.1. This document also defines extensibleMatch filter definitions which MUST be implemented whenever the associated resource types defined in this document are implemented by an LDAP-WHOIS client or server. These filter definitions are provided in section 6.2 below. 6.1. Search Filter Expressions Section 4.5.1 of RFC 2251 defines the LDAP search request specification, although it does not provide guidelines or recommended values for the filter settings. In an effort to promote interoperability among LDAP-WHOIS clients and servers, this document defines some recommended and mandatory values for searches within the LDAP-WHOIS service. NOTE: These rules ONLY apply to the LDAP-WHOIS search operations in particular. Any queries for other resources Hall & Newton I-D Expires: August 2002 [page 31]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 (such as requests for inetOrgPerson contact entries) MUST NOT impose these restrictions. Also note that other documents which define additional resource types can also define different restrictions, and those definitions will take preference over these guidelines. Generic LDAP clients may be used to browse and search for data, and in those cases, these rules are not likely to be followed. As such, servers MUST be prepared to enforce these rules independently of the client settings. The values of an LDAP search filter should be as follows: * Search base. The DIT to be used in a search will vary for each query operation. The methodology for determining the current search base for a query is defined by the query- processing protocols described in section 7, although LDAP- WHOIS searches are normally constrained to the "cn=inetResources" container of a particular DIT. * Scope. In order to support continuation reference referrals (which are defined as referral entries beneath a resource- specific entry), clients MUST use a sub-tree scope for LDAP-WHOIS searches. Servers MUST NOT arbitrarily limit the scope of search operations. * Dereference aliases. Although the LDAP-WHOIS service does not make direct use of alias entries, they are not prohibited. Clients SHOULD set the Dereference Aliases option to "Always" for LDAP-WHOIS searches. Servers SHOULD dereference any aliases which are encountered, where this is feasible (in particular, where the alias refers to another DIT on the same server). * Size limit. The size limit field specifies the maximum number of entries that a server should return. For the LDAP-WHOIS service, this setting SHOULD be set to a value between 25 and 100. This range ensures that the client is capable of receiving a sufficient number of entries and continuation references in a single response, but also works to prevent runaway queries that match everything (such as searches for "com", which can match every inetDnsDomain entry in the "cn=inetResources,dc=com" container). Servers MAY truncate answer sets to 100 responses if the client specifies a larger value. Hall & Newton I-D Expires: August 2002 [page 32]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 * Time limit. The time limit field specifies the maximum number of seconds that a server should process the search. For the LDAP-WHOIS service, this setting SHOULD be set to a value between 10 and 60 seconds. This range ensures that the server is able to process a sufficient number of entries, but also works to prevent runaway queries that match everything. Servers MAY stop processing queries after 60 seconds if the client specifies a larger value. * Types-only. The types-only setting is a Boolean flag which controls whether or not attribute values are returned in the answer sets. Since excessive queries are likely to be more burdensome than larger answer sets, this setting SHOULD be set to FALSE. Resource-constrained clients (such as PDAs) MAY set this value to TRUE, but these clients MUST be prepared to issue the necessary subsequent queries. * Filter. The search operation will depend on the type of data being queried. For LDAP-WHOIS queries, the filter MUST use the matching rules defined in section 6.2 for the relevant resource type. Other resource-specific documents may define their own handling rules. Note that the extensible match filters defined in this document MUST be supported by LDAP-WHOIS clients and servers. LDAP-WHOIS servers MAY also support additional sub-string filters, soundex filters, or any other filters they wish (these may be required for generic LDAP clients), although LDAP-WHOIS clients MUST NOT expect any additional filters to be available. * Attribute list. Clients MAY restrict the list of attributes which are returned in searches, but are discouraged from doing so without cause. 6.2. Matching Filter Definitions Each of the object classes defined in this document have their own search criteria which MUST be used whenever a collection of resource pools need to be searched. In this model, resource types are specified during the search operation, and most of the resource types have extensibleMatch definition which are used whenever the available resources need to be searched. Hall & Newton I-D Expires: August 2002 [page 33]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 For example, if a user wishes to find the inetIPv4network object class entry associated with a specific IPv4 address, then the inetIpv4NetworkMatch extensibleMatch filter MUST be specified by the client, and MUST be used by the server when attempting to locate the relevant inetIpv4Network entry. The inetResources object class can be searched with simple equalityMatch filters, and do not require dedicated extensibleMatch filters, although they do have specific handling rules. In order to ensure that all of the relevant entries (including any referrals) are found, the search filters for these resources MUST specify two distinct elements: the object class of the resource being queried, and the naming element of the resource specified as a distinguished name attribute. For example, using the notation format described in RFC 2254, the search filter expression for the inetOrgPerson entry associated with "cn=admins,ou=admins,dc=example,dc=com" would be structured as "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", using "ou=admins,dc=example,dc=com" as the search base. This would find all entries with the object class of inetOrgPerson (including all of the referral entries for inetOrgPerson entries) where the distinguished name contained the "cn" attribute of "admins". The input source and search base for these matches will vary according to the query being processed, but whenever an equalityMatch is called for during query processing, the above methods MUST be used in order to ensure that all of the related entries are located. Response entries MAY be fully-developed entries, or MAY be referrals generated from entries which have the referral object class defined. Any attribute values which are received MUST be displayed by the client. If a subordinate reference referral is received, the client MUST restart the query, using the provided data as the new search base. If any continuation reference referrals are received, the client SHOULD start new queries for each reference, and append the output of those queries to the original query's output. Hall & Newton I-D Expires: August 2002 [page 34]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 7. Query Processing Models The LDAP-WHOIS service uses three different query-processing models. These are the "top-down" model which initiates the query process at the top-level of a DNS delegation hierarchy, a "bottom- up" model which directs queries to user-managed servers, and a "targeted" search model which is functionally identical to traditional LDAP searches. Furthermore, any of these mechanisms may be redirected to other servers, either through simple DNS query processing, or by way of LDAP redirections (including subordinate reference referrals, continuation reference referrals, attribute references, or labeledURI attributes). Each of the three query models are appropriate to different usage environments. For example, the top-down model is best suited for searches about global resources which are centrally managed and delegated (such as IP addresses and DNS domains), and where delegation information is a critical element of the resource data. Meanwhile, the bottom-up model is most appropriate for those resources which are managed by the end-users directly, and which are not managed from a centralized delegation authority (this includes information such as private keys, mail servers, and other leaf-node resources). Finally, the targeted model is best suited for explicit queries where a particular resource is supposed to exist with a known DN (such as with contact pointers). LDAP-WHOIS clients and servers MUST implement all three models. Clients MUST default to using the top-down model, but clients MUST also provide a user-selectable option for the disposition of individual queries. 7.1. Top-Down Processing The top-down model is primarily suited for locating Internet resources which are centrally managed and delegated. The top-down model is similar to other distributed WHOIS protocols in this regard, with the principle difference being the use of LDAP for standardized syntaxes, data and referrals, rather than using a specialized protocol specifically for this application. The top-down model uses an input string to construct an LDAP assertion value and search base, with DNS queries being used to locate the LDAP servers associated with the appropriate top-level delegation entity. Once this process completes, an extensible Hall & Newton I-D Expires: August 2002 [page 35]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 match query is issued to the specified servers. The query may also be redirected through the use of LDAP referrals, if additional data is known to exist elsewhere. For example, a top-down search for the domain name of "www.example.com" would result in the client building an inetDnsDomainMatch extensible match query with the search base of "cn=inetResources,dc=com", and with the client issuing a DNS query for the LDAP servers associated with "com" domain. If the queried server had information about the "www.example.com" resource, it would be returned as answer data. If the server knew of other sources of information about the resource (such as the registrar for the domain, or the entity operating the domain, or both), continuation reference referrals could be returned. Any of the subsequent queries could return additional answers and/or referrals, according to the data they had. IP address blocks and AS numbers are processed in a similar fashion. If a client needed to locate information about the "192.0.2.14/32" IPv4 address, it would begin the process by building a reverse-lookup DNS domain name from the input string, and then issuing a DNS query for the LDAP servers associated with the "arpa" top-level domain. Once a server had been located, an LDAP query with the assertion value of "192.0.2.14/32" would be submitted with a search base of "cn=inetResources,dc=arpa". The server would return data and/or referrals, with this process repeating until the query string had been completely processed. Note that entries for the inetResources and inetOrgPerson object classes are not searchable with this model, since they do not have centralized delegation authorities. One of the other search models MUST be used for those resource types. 7.1.1. Processing steps The steps for processing top-down queries are described below: a. Determine the input type (DNS Domain, IPv4 Address, etc.) b. Determine the authoritative domain name for the query. 1. Separate the input string into discrete elements where this is possible. For a DNS domain name of "www.example.com", this would be "www", "example" and "com". For the IPv4 network number of "192.0.2.14", Hall & Newton I-D Expires: August 2002 [page 36]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 this would be "192", "0", "2" and "14". AS numbers only have a single value and require no separation. Do not discard the original query string. 2. IP addresses and AS numbers require additional conversion. For IPv4 addresses, strip off the prefix and convert the input string into a reverse-lookup DNS domain name by reversing the order of the octets and appending "in-addr.arpa" to the right of the domain name. For IPv6 addresses, strip off the prefix and reverse the nibble order of the address (where each nibble is represented by a single hexadecimal character), and append "ip6.arpa". For AS numbers, append only the "arpa" domain name. c. Form the LDAP search base for the query. 1. Convert the right-most element from the domain name formed in step 7.1.1.b above into a domainComponent DN (such as "dc=com" or "dc=arpa"). This represents the DIT for the current query. 2. Append the "cn=inetResources" RDN to the front of the domainComponent syntax ("cn=inetResources,dc=com"). This will form the fully-qualified search base for the LDAP query. d. Locate the LDAP servers associated with the resource by processing the domain name formed in step 7.1.1.b above through the SRV query steps provided in section 7.4.5. e. If the SRV lookup succeeds: 1. Choose the best LDAP server, using the weighting formula described in RFC 2782. 2. Construct the LDAP search filter according to the rules specified in section 6.1, using the appropriate matching rule from section 6.2. 3. Formulate the LDAP search using the search base and search filter constructed above. For example, if the input query string was for "www.example.com", then the client would begin the process by submitting an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", and with a Hall & Newton I-D Expires: August 2002 [page 37]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 search base of "dc=inetResources,dc=com". Similarly, if the input query string was "192.0.2.14", then the client would begin the process by submitting an inetIpv4NetworkMatch extensibleMatch search with the assertion value of "192.0.2.14/32", and with the search base of "cn=inetResources,dc=arpa". 4. Submit the search operation to the chosen server and port number. If the operation fails, report the failure to the user and exit. Otherwise, display any answer data which is returned. 5. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.1.1.e.2. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.1.1.e.2, appending the output from these searches to the current output. Any additional subordinate reference referrals or continuation reference referrals which are encountered from any subsequent searches will need to be processed in the same manner as specified above, until no additional referrals are received. f. If the SRV lookup fails (where failure is defined as any DNS response message other than an answer), report the failure to the user and exit the current search operation. 7.1.2. Top-Down example In the example below, the user has entered a search string of "www.example.com" and has indicated that the query is for a DNS domain name. a. The input string is broken into the discrete label components ("www", "example" and "com"). Hall & Newton I-D Expires: August 2002 [page 38]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 b. The right-most label ("com") is used to form the DNS SRV lookup ("_ldap._tcp.com"), in order to find the LDAP servers authoritative for the delegation hierarchy. c. One of the LDAP servers is contacted, and an inetDnsDomainMatch search filter is submitted with the assertion value of "www.example.com" and a search base of "cn=inetResources,dc=com". d. The server responds with a continuation reference referral URL of "ldap://ldap.netsol.com/cn=example.com, cn=inetResources,dc=netsol,dc=com", indicating that the domain delegation is managed under the "dc=netsol,dc=com" DIT, and is hosted at the "ldap.netsol.com" server. The client uses this information to start a new query. No additional data was provided for the client to display. e. An inetDnsDomainMatch extensibleMatch search is submitted to "ldap.netsol.com", using the search base of "cn=example.com,cn=inetResources,dc=netsol,dc=com". f. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. 7.2. Bottom-Up Processing The bottom-up model is best used when a leaf-node resource needs to be queried, and where an LDAP-WHOIS server is expected to be able to answer the query. In this case, navigating down through a delegation hierarchy would be either fruitless or inefficient. For example, information about a mail domain would be more efficient in the bottom-up model, since there is no global delegation body for Internet mail (the DNS domains are delegated, but the message routing is specific to the operational entities responsible for the domain name). The bottom-up model can also be used for DNS domain names, IPv4 addresses, and IPv6 addresses, although this will generally prove to be less useful than top-down queries, given the limited number of user-managed servers deployed. The bottom-up model uses an input string to construct an LDAP assertion value and search base, with DNS queries being used to locate the LDAP servers which are associated with the management entity that is directly responsible for the resource in question. Once this process completes, an extensible match query is issued Hall & Newton I-D Expires: August 2002 [page 39]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 to the specified servers. The query may also be redirected through the use of LDAP referrals, if additional data is known to exist elsewhere. For example, a bottom-up search for the domain name of "www.example.com" would result in the client building an inetDnsDomainMatch extensible match query with the search base of "cn=inetResources,dc=www,dc=example,dc=com", and with the client issuing a DNS query for the LDAP servers associated with "www.example.com" domain. If the DNS lookup failed, the client would issue a subsequent query for the LDAP servers associated with the "example.com" domain, and so forth, until a server had been located. If the queried server had information about the "www.example.com" resource, it would be returned as answer data. If the server knew of other sources of information about the resource (such as the registrar for the domain, or the entity operating the domain, or both), continuation reference referrals could be returned. Any of the subsequent queries could return additional answers and/or referrals, according to the data they had. IP address blocks are processed in a similar fashion. If a client needed to locate information about the "192.0.2.14" IPv4 address, it would begin by issuing a DNS query for the LDAP servers responsible for the "14.2.0.192.in-addr.arpa" domain name, with the left-most labels being truncated as the search for an authoritative server was broadened. Once a server had been located, an inetIpv4NetworkMatch extensibleMatch search with the assertion value of "192.0.2.14/32" would be submitted. If the server knew of any information about that resource, it would return data or a referral, with this process repeating until the query string had been processed as completely as possible. Note that entries for inetAsNumber and inetOrgPerson object classes are not searchable with this model, since they are not represented in the DNS delegation hierarchy. One of the other search models MUST be used for those resource types. 7.2.1. Processing steps The steps for processing bottom-up queries are described below: a. Determine the input type (DNS Domain, IPv4 Address, etc.) b. Determine the authoritative DNS domain for the resource. Hall & Newton I-D Expires: August 2002 [page 40]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 1. Separate the input string into discrete elements where this is possible. For a DNS domain name of "www.example.com", this would be "www", "example" and "com". For the IPv4 network number of "192.0.2.14", this would be "192", "0", "2" and "14". Do not discard the original query string. 2. IP addresses require additional conversion. For IPv4 addresses, strip off the prefix and convert the input string into a reverse-lookup DNS domain name by reversing the order of the octets and appending "in-addr.arpa" to the right of the resulting sequence. For IPv6 addresses, strip off the prefix and reverse the nibble order of the address (where each nibble is represented by a single hexadecimal character), and append "ip6.arpa" to the right of the resulting sequence. c. Form the LDAP search base for the query. 1. Convert the domain name formed in step 7.2.1.b above into a domainComponent DN (such as "dc=www,dc=example,dc=com" or "dc=0,dc=2,dc=0,dc=192, dc=in-addr,dc=arpa"). This represents the DIT for the current query. 2. Append the "cn=inetResources" RDN to the left of the domainComponent syntax (perhaps resulting in "cn=inetResources,dc=www,dc=example,dc=com"). This will become the search base for the LDAP query. d. Locate the LDAP servers associated with the resource by processing the domain name formed in step 7.2.1.b above through the SRV query steps provided in section 7.4.5. e. If the SRV lookup fails with an NXDOMAIN response code (as described in RFC 2308), then the domain name used for the SRV lookup does not exist, and a substitute LDAP server and search base must be identified. This process involves determining the parent zone for the domain name in question, issuing an SRV lookup for that zone, and using the domain name of the zone as the new LDAP search base, with this process repeating until a search base can be located, or until a critical failure forces an exit. Hall & Newton I-D Expires: August 2002 [page 41]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 1. Remove the left-most label from the domain name formed in step 7.2.1.b. 2. If this process has already resulted in a query domain name at a top-level domain such as "com" or "arpa", convert the query domain name to "." (to signify the root domain). 3. If the queried domain name is already set to ".", the query can go no higher (this most likely indicates a malformed DNS configuration, a connectivity problem, or a typo in the query). Exit and report the failure to the user. 4. Restart the process at step 7.1.1.c, using the domain name formed above. Repeat until a server is located or a critical failure forces an exit. For example, if the original input string of "www.example.com" resulted in a failed SRV lookup for "_ldap._tcp.www.example.com", then the first fallback SRV query would be for "_ldap._tcp.example.com", and the next fallback query would be for "_ldap._tcp.com", possibly being followed by "_ldap._tcp.", and possibly resulting in failure after that. f. If the SRV lookup succeeds: 1. Choose the best LDAP server, using the weighting formula described in RFC 2782. 2. Construct the LDAP search filter according to the rules specified in section 6.1, and choose the appropriate matching rule from section 6.2. 3. Formulate the LDAP search using the search base and search filter constructed above. For example, if the input query string was for "www.example.com", then the client would begin the process by submitting an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", with the search base of "cn=inetResources,dc=www,dc=example,dc=com". 4. Submit the search operation to the chosen server and port number. If the operation fails, report the Hall & Newton I-D Expires: August 2002 [page 42]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 failure to the user and exit. Otherwise, display any answer data which is returned. 5. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.2.1.f.2. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.2.1.f.2, appending the output from these searches to the current output. Any additional subordinate reference referrals or continuation reference referrals which are encountered from any subsequent queries will need to be processed in the same manner as specified above, until no additional referrals are received. g. If a fatal DNS error condition occurs, report the error to the user and stop processing the current query. A fatal DNS error is any response message with an RCODE of FORMERR, SERVFAIL, NOTIMPL, or REFUSED, or where a query results in NODATA (implying that an "_ldap._tcp" domain name exists but it doesn't have an SRV resource record associated with it, which is most likely a configuration error). 7.2.2. Bottom-Up example In the example below, the user has entered a search string of "www.example.com" and has indicated that the query is for a DNS Domain Name. a. The query string is used to form the DNS SRV lookup ("_ldap._tcp.www.example.com"), in order to find the LDAP servers authoritative for that domain name. b. The SRV lookup fails with NXDOMAIN, indicating that the queried domain name does not exist. Hall & Newton I-D Expires: August 2002 [page 43]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 c. The client creates a new query for the parent domain ("_ldap._tcp.example.com"), which succeeds. d. The client contacts one of the servers, and issues an inetDnsDomainMatch extensibleMatch search with the assertion value of "www.example.com", and with the search base of "cn=inetResources,dc=example,dc=com". e. The server returns a continuation reference referral of "ldap://ldap.example.net/cn=server1.example.net, cn=inetResources,dc=example,dc=net", indicating that the queried resource is a referral for a web hosting server at Example Networks. The client uses this information to start a new query. No additional data was provided for the client to display. f. An inetDnsDomainMatch extensibleMatch search is submitted to the "ldap.example.net" server, using the search base of "cn=server1.example.net,cn=inetResources,dc=example,dc=net" g. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. 7.3. Targeted Search Processing The targeted search model is similar to the bottom-up query model described in the preceding section, except that it does not provide fallback processing of DNS domain names. In this regard, the targeted search model is closely similar to the traditional LDAP searching model, in that a client queries a specified LDAP server for a specific entry, under the assumption that the resource exists at that location. If the server or resource does not exist, the entire query fails. For this reason, the targeted search model is not suitable for search operations against generic Internet resources, but instead is mostly suitable for searches against known entries which are presumed to exist at a known location. In terms of the LDAP-WHOIS service in particular, this includes inetOrgPerson entries which are provided in contact-related attributes. However, the targeted search model can be used for any resource type, and it can be useful for diagnosing problems with resource types. For this reason, clients SHOULD support this model for use with all known resource types. Hall & Newton I-D Expires: August 2002 [page 44]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 The targeted search takes an LDAP URL as the query input (along with the resource-type identifier), and uses the URL to determine the query server, the search base, and the assertion value. 7.3.1. Processing steps The steps for processing targeted search queries are described below: a. Process the LDAP URLs according to the continuation reference referral handling rules described in section 7.4.3. This process will determine the servers, search base and assertion value of the query. b. If this process succeeds: 1. Construct the LDAP search filter according to the rules specified in section 6.1, and choose the appropriate matching rule from section 6.2. 2. Submit the search operation to the chosen server and port number. If the operation fails, report the failure to the user and exit. Otherwise, display any answer data which is returned. 3. If the answer data contains a subordinate reference referral or a continuation reference referral, new query processes MUST be spawned. For subordinate reference referrals, process the URLs according to the rules described in section 7.4.1 and restart the query process at step 7.3.1.b. For each continuation reference referral, display the answer data received so far, process the LDAP URLs according to the rules described in section 7.4.3 and start new query processes for each referral at step 7.3.1.b. Any additional subordinate reference referrals or continuation reference referrals which are encountered from any subsequent queries will need to be processed in the same manner as specified above, until no additional referrals are received. Hall & Newton I-D Expires: August 2002 [page 45]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 c. If this process fails, report the failure to the user and exit the current search operation. 7.3.2. Targeted search example In the example below, the user has provided an LDAP URL of "ldap://ldap.example.com/cn=admins,ou=admins,dc=example,dc=com", and has indicated that the query is for an inetOrgPerson entry. a. The query string is used to form a DNS lookup of the specified server ("ldap.example.com"). b. The client contacts the servers, and issues a search for "(&(objectclass=inetOrgPerson)(cn:dn:=admins))", with a search base of "ou=admins,dc=example,dc=com". c. The queried server returns the information that it has. No additional referrals are provided. The client displays the data and exits the query. 7.4. Supplemental Query Processing Mechanisms During the course of normal query processing, an LDAP-WHOIS client may need to use additional mechanisms to complete an operation, such as processing a URL received from a redirect operation, or issuing DNS SRV lookups against a provided domain name. 7.4.1. URL processing URL processing in this specification is a function of both content and context. Different attributes and result codes provide different types of URLs, and the disposition of these URLs will depend on the query-resolution process currently being executed. On the content front, this specification allows three different forms of URLs to appear throughout this service: labeledURI attribute values, attribute references, and referral messages. Each of these usage scenarios have slightly different restrictions and formats. * The labeledURI attribute is included with the inetResources object class for the purpose of informing end-users of a generic resource associated with an entry (such as an Hall & Newton I-D Expires: August 2002 [page 46]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 organization's home page). The labeledURI attribute is defined in RFC 2079 for the purpose of storing generic URLs as attribute values, and uses a two-part syntax of "url://any.host:port/any/path description", with the "description" string providing a free-text description of the target specified by the URL. * Attribute references also use the two-part format of the labeledURI attribute, but with some additional restrictions as described in section 4.5 of this document. * Subordinate and continuation reference referrals use URLs for the purpose of providing referral targets. The URL format specified in [namedref] is also an explicit subset of the labeledURI format, but without the "description" free-text block. When used with the LDAP-WHOIS service, subordinate and continuation referrals are subject to some additional rules as described in section 4.5 of this document. Non-compliance with the requirements provided in section 4.5 amounts to an error, and is sufficient cause for a client to stop processing a query. 7.4.2. Subordinate reference referrals Subordinate reference referrals and their schema are defined in [namedref]. Subordinate reference referrals use the SearchResultDone response with a Referral result code, which is defined and described in section 4.1.11 of RFC 2251. Subordinate reference referrals use a subset of the labeledURI syntax as defined in RFC 2079, and use the syntax definitions from RFC 2255 when LDAP URLs in particular are provided, although section 4.5 of this document also defines additional restrictions on the allowable URL syntax. In the context of the LDAP-WHOIS service, subordinate reference referrals are returned when the search base specified in a search operation exists as a referral object class with the ref attribute pointing to some other entry, resulting in queries with that search base being answered with a SearchResultDone referral response. This condition means that the current search operation cannot proceed past this point, and the search MUST be restarted. This will most often occur when the inetResources entry for a DIT has been redirected to another DIT, but it can also happen after Hall & Newton I-D Expires: August 2002 [page 47]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 continuation reference referrals have been followed or after targeted searches have been issued, and where the queried entry exists as a referral to some other entry. The procedure for processing URLs returned in a subordinate reference referral is as follows: a. RFC 2251 allows multiple URLs to be provided, although the URLs are not provided with any "preference" or "weighting" values. If a set of URLs are provided, only one of the URLs need to be tried (implementations MAY perform additional queries in an attempt to recover from temporary failures, although this is not required). Select one of the URLs at random ("round-robin"), and continue to the next step in the process. b. Extract and discard any description text which may have been provided with the URL. c. Validate the protocol label. This specification only supports the use of the LDAP service type. URLs with other protocol identifiers are to be treated as malformed. d. Extract the host identifier element and perform any DNS lookups which may be required. URLs without host identifiers are to be treated as malformed. e. Extract the port number provided with the URL, and set it aside for use with the subsequent connection attempt. If no port number has been provided in the URL, use the default port numbers associated with the protocol, as discovered in step 7.4.2.c. f. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. g. Restart the current search operation, using the LDAP server from step 7.4.2.d, the port number from step 7.4.2.e, and the search base formed in step 7.4.2.f. 7.4.3. Continuation reference referrals Continuation reference referrals and their schema are defined in [namedref]. Continuation reference referrals use the Hall & Newton I-D Expires: August 2002 [page 48]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 SearchResultReference response, which is defined and described in section 4.5.3 of RFC 2251. Continuation reference referrals use a subset of the labeledURI syntax as defined in RFC 2079, and use the syntax definitions from RFC 2255 when LDAP URLs in particular are to be provided, although section 4.5 of this document also defines additional restrictions on the allowable URL syntax. For this service, continuation reference referrals are returned when the search base specified in a search operation exists, but one or more of the answer elements exist as referral object classes, resulting in one or more SearchResultReference responses. This condition means that the current search operation has partially succeeded, but that additional searches SHOULD be started in order for all of the answer data to be retrieved (in many cases, no answer data will be provided, and in those situations, new queries will be required for any data to be retrieved). This will occur whenever the assertion value of a search has matched a resource entry which is being managed by another DIT, and can occur with any of the search operations described in this document. Multiple continuation reference referrals MAY be returned in response to a search, and each of them MUST be processed in order for all of the answer data to be retrieved. The procedure for processing the URLs returned in a continuation reference referral is as follows: a. RFC 2251 allows multiple URLs to be provided, although the URLs are not provided with any "preference" or "weighting" values. If a set of URLs are provided, only one of the URLs need to be tried (implementations MAY perform additional queries in an attempt to recover from temporary failures, although this is not required). Select one of the URLs at random ("round-robin"), and continue to the next step in the process. b. Extract and discard any description text which may have been provided with the URL. c. Validate the protocol label. This specification only supports the use of the LDAP service types. URLs with other protocol identifiers are to be treated as malformed. Hall & Newton I-D Expires: August 2002 [page 49]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 d. Extract the host identifier element and perform any DNS lookups which may be required. URLs without host identifiers are to be treated as malformed. e. Extract the port number provided with the URL, and set it aside for use with the subsequent connection attempt. If no port number has been provided in the URL, use the default port numbers associated with the protocol, as discovered in step 7.4.3.c. f. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. g. Extract the left-most RDN from the search base constructed in step 7.4.3.e, and delete the naming attribute label. The resulting string will be used as the assertion value for the subsequent search operation. For example, if the path element from a URL provided a distinguished name of "cn=example.com,cn=inetResources,dc=example,dc=com", then the "cn=example.com" RDN would be used to form an assertion value of "example.com". h. Start a new search operation, using the LDAP server from step 7.4.3.d, the port number from step 7.4.3.e, the search base formed in step 7.4.3.f, and the assertion value formed in step 7.4.3.g. 7.4.4. Attribute references Attribute references are defined in this document as attributes which provide URLs as pointers to contextually related information. These are not referrals, but instead are simple URLs returned as attribute values. In particular, this document defines multiple contact-related attributes which provide these URLs. Other documents may also define attributes which reuse the URL format defined here, or may define their own URL rules, as needed. For this service, attribute reference URLs are returned when an entry has an attribute defined which uses them. Attribute references are not referrals, and do not require additional processing. Clients MAY automatically start new search operations when an attribute reference is encountered, or they MAY delay processing until a user requests the action. Hall & Newton I-D Expires: August 2002 [page 50]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 The procedure for processing the URLs returned in an attribute reference is as follows: a. RFC 2251 allows multiple URLs to be provided, although the URLs are not provided with any "preference" or "weighting" values. If a set of URLs are provided, only one of the URLs need to be tried (implementations MAY perform additional queries in an attempt to recover from temporary failures, although this is not required). Select one of the URLs at random ("round-robin"), and continue to the next step in the process. b. Extract and discard any description text which may have been provided with the URL. c. Validate the protocol label. This specification only supports the use of LDAP service types. URLs with other protocol identifiers are to be treated as malformed. d. Extract the host identifier element and perform any DNS lookups which may be required. URLs without host identifiers are to be treated as malformed. e. Extract the port number provided with the URL, and set it aside for use with the subsequent connection attempt. If no port number has been provided in the URL, use the default port numbers associated with the protocol, as discovered in step 7.4.4.c. f. Extract the path element from the URL for use as the search base of the subsequent search operation. URLs without path elements are to be treated as malformed. g. Extract the left-most RDN from the search base constructed in step 7.4.4.e, and delete the naming attribute label. The resulting string will be used as the assertion value for the subsequent search operation. For example, if the path element from a URL provided a distinguished name of "cn=example.com,cn=inetResources,dc=example,dc=com", then the "cn=example.com" RDN would be used to form an assertion value of "example.com". h. Determine the object class filter to be used with the assertion value. This will depend on the attribute which provided the attribute reference. The contact-related Hall & Newton I-D Expires: August 2002 [page 51]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 attributes defined in this document refer to inetOrgPerson object class entries. i. Start a new search operation, using the LDAP server from step 7.4.4.d, the port number from step 7.4.4.e, the search base formed in step 7.4.4.f, the assertion value formed in step 7.4.4.g, and the new object class filter formed in step 7.4.4.h. 7.4.5. SRV processing The query models described in this document make use of DNS SRV resource records whenever a new query process is started, as a way to locate the LDAP servers associated with a DIT. The procedure for constructing this SRV lookup is as follows: a. Construct an SRV-specific label pair for the service type. For LDAP queries, this will be "_ldap._tcp". b. Append the SRV label pair to the left of the input domain name. In the case of an LDAP query for "example.com", this would result in an SRV-specific domain name of "_ldap._tcp.example.com". c. Issue a DNS query for the SRV resource records associated with the domain name formed in step 7.4.5.b. Multiple SRV resource records may be returned in response to a query. Each resource record identifies a different connection target, including the domain name of a server, and a port number for that server. The port number specified in a SRV resource record MUST be used for any subsequent bind and search operations. SRV resource records provide "priority" and "weight" values which MUST be used to determine the preferred server. If a server is unavailable or unreachable, a connection attempt must be made to the next-best server in the answer set. Refer to RFC 2782 for a detailed explanation of SRV resource records and their handling. Hall & Newton I-D Expires: August 2002 [page 52]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 8. Internationalization and Localization The LDAP-WHOIS model uses the internationalization and localization services provided by LDAPv3. In this regard, LDAP- WHOIS clients do not need to implement any special services in order to process and display internationalized attribute data, since the attribute types already provide direct support for internationalized data. LDAP-WHOIS clients may have some localization or language-specific presentation issues with regards to attribute names, in that the names of the attributes may need to be localized for specific markets. However, these services are outside the scope of the protocol operations. Any such requirements must be dealt with according to the services available on the client platform. In the case of legacy WHOIS servers which gateway requests between TCP port 43 and the LDAP-WHOIS service, the input and output language and/or locale codes MAY be specified by server-specific options, although these mechanisms must be defined as part of the WHOIS protocol for any widespread consistency to be possible, and are therefore beyond the scope of this document. 9. DIT Replication All DITs which provide data for global Internet resources SHOULD be replicated across two or more servers. Each of the authoritative LDAP servers for the managed resource MUST be specified with a unique DNS SRV resource record for the domain name associated with the top-level resource assignment space. For example, the top-level "com" delegation space SHOULD have two or more SRV resource records associated with the "_ldap._tcp.com" domain name, with each entry referring to separate LDAP servers, and with each of those servers maintaining accurate copies of the "dc=com" DIT (within reasonable timeliness). Similarly, the top- level " arpa" domain which is used by the IPv4 and IPv6 delegation trees SHOULD provide two or more SRV resource records for the "_ldap._tcp.arpa" domain name, as should the "in-addr.arpa" and "ip6.arpa" domain hierarchies. DITs which serve multiple organizations SHOULD also be replicated. For example, an ISP which provides LDAP-WHOIS services for their customers SHOULD also follow these same rules, since outages of Hall & Newton I-D Expires: August 2002 [page 53]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 those servers will affect multiple parties. Leaf-node DITs associated with an user-managed resource MAY be replicated, and are encouraged to do so. Similarly, any referrals which present URLs as answer data SHOULD provide multiple URLs, each of which reference different hosts on different networks. For leaf-node referrals, attribute references, and labeledURI references, this behavior MAY be relaxed, although it is still encouraged. Note that the most effective replication strategy will be for entities to replicate their DITs with the delegation parents, as this will allow queries for those resources to be processed by the parent servers (thereby eliminating the need for referral queries). In many cases, this will not be feasible (the servers for the "dc=com" DIT cannot be expected to host replicas of every subordinate DIT), but it is encouraged where practical. 10. Transition Issues There are a handful of areas where the proposed service does not fully match with all of the existing WHOIS service offerings. These areas are discussed in more detail below. 10.1. NIC Handles NIC handles represent a historical method of WHOIS lookups, tying unique identifiers to a specific record in a specific database. Given that the model proposed in this document uses a distributed lookup system rather than isolated databases, the NIC handle model is no longer necessary. Furthermore, given the limited global usability of NIC handles, they should be deprecated. However, NIC handles are an important part of the legacy service, and their continued usage is likely to be desired in at least some instances. There are two possible workarounds for this problem: * NIC handle output in legacy WHOIS systems SHOULD be replaced with an LDAP URL for the contact entries. This option facilitates faster coalescence around the LDAP-WHOIS system. * Referral entries MAY be defined for each existing NIC handle if the explicit NIC handle is still required for an application or usage, and queries for NIC handles MAY be Hall & Newton I-D Expires: August 2002 [page 54]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 processed through these referral entries. For example, the NIC handle of EH26 on Network Solutions' WHOIS server can be represented as "cn=EH26,cn=inetResources,dc=netsol,dc=com", with the inetOrgPerson and referral object classes defined, and with the ref attribute value pointing to an entry named "cn=Eric A. Hall,cn=inetResources,dc=ntrg,dc=com". Of the two mechanisms described above, the former is preferred. 10.2. Change-Logs Several WHOIS services provide pseudo change-logs in their response data, listing each unique modification event which has occurred for a particular resource. For example, RIPE and some of its member ccTLDs provide WHOIS output which includes a series of "changed" fields that itemize every modification event ("updated", "added", etc.), the modifier, and the modification date, which cumulatively act as a change-log for the resource in question. While this service is useful and informative to the delegating bodies, this information is not as useful to external entities. Furthermore, the principle use of this information is for the purpose of internal audits, rather than external information. Finally, a subset of this kind of information is already provided in the *modified* operational attributes, which are always available for public review. Organizations are certainly free to maintain this information on their internal systems (and are even encouraged to do so). However, this information is not necessary for public view of the data in the LDAP-WHOIS service. Where the auditing information will be required, a format which is more suitable to legal review will be required and more appropriate. For these reasons, this service is not supported in the LDAP-WHOIS service. However, if this information is absolutely required, implementers MAY provide it as additional unstructured data via the inetGeneralComments attribute (perhaps using an "event:modifier:date" format). Hall & Newton I-D Expires: August 2002 [page 55]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 10.3. Open Issues The following issues require additional analysis: * inetIpv6Network and other entries will likely benefit from certificate-related data, although the extent and nature of this information (minimum requirements, preferred attributes, pre-existing schema, etcetera) is currently unknown. * The RIPE database v3 has several additional attributes: domain: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] zone-c: [mandatory] [multiple] [inverse key] nserver: [optional] [multiple] [inverse key] sub-dom: [optional] [multiple] [inverse key] dom-net: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] refer: [optional] [single] [ ] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] see http://www.ripe.net/ripe/docs/databaseref-manual.html 11. Security Considerations This document describes an application of the LDAPv3 protocol, and as such it inherits the security considerations associated with LDAPv3, as described in section 7 of RFC 2251. By nature, LDAP is a read-write protocol, while the legacy WHOIS service has always been a read-only service. As such, there are significant risks associated with allowing unintended updates by unauthorized third-parties. Moreover, allowing the LDAP-WHOIS service to update the underlying delegation databases could result in network resources being stolen from their lawful operators. For example, if the LDAP front-end had update access to a domain delegation database, a malicious third-party could theoretically take ownership of that domain by exploiting an authentication weakness, thereby causing ownership of the domain to be changed to Hall & Newton I-D Expires: August 2002 [page 56]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 another party. For this reason, it is imperative that the LDAP- WHOIS service not be allowed to make critical modifications to delegated resources without ensuring that all possible precautions have been taken. The query processing models described in this document make use of DNS lookups in order to locate the LDAP servers associated with a particular resource. DNS is susceptible to certain attacks and forgeries which may be used to redirect clients to LDAP servers which are not authoritative for the resource in question. Some operators may choose to purposefully provide misleading or erroneous information in an effort to avoid responsibility for bad behavior. In addition, there are likely to be sporadic operator errors which will result in confusing or erroneous answers. This document provides multiple query models which will cause the same query to be answered by different servers (one would be processed by a delegation entity, while another would be processed by an operational entity). As a result, each of the servers may provide different information, depending upon the query type that was originally selected. For all of the reasons listed above, it is essential that applications and end-users not make critical decisions based on the information provided by the LDAP-WHOIS service without having reason to believe the veracity of the information. Users should limit unknown or untrusted information to routine purposes. Finally, there are physical security issues associated with any service which provides physical addressing and delivery information. Although organizations are generally encouraged to provide as much information as they feel comfortable with, no information is required. 12. IANA Considerations This document defines an application of the LDAPv3 protocol rather than a new Internet application protocol. As such, there are no protocol-related IANA considerations. However, this document does define several LDAP schema elements, including object classes, attributes, syntaxes and extensibleMatch filters, and these elements should be assigned OID values from the Hall & Newton I-D Expires: August 2002 [page 57]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 IANA branch, rather than being assigned from a particular enterprise branch. Furthermore, this document defines delegation status codes for four of the resource types described herein, and IANA is expected to maintain the code-point mapping values associated with these attribute values. Each resource type may develop its own peculiar status codes, so each of the mapping tables will need to be maintained independently. Finally, this document also describes several instances where public DNS and LDAP servers are queried. It is expected that IANA will establish and maintain these LDAP servers (and the necessary DNS SRV domain names and resource records) required for this service to operate. This includes providing SRV resource records in the generic TLDs and the root domain, and also includes administering the referenced LDAP servers. 13. Author's Addresses Eric A. Hall ehall@ehsco.com 14. References RFC 1274 - The COSINE and Internet X.500 Schema RFC 2079 - Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) RFC 2247 - Using Domains in LDAP/X.500 DNs RFC 2251 - Lightweight Directory Access Protocol (v3) RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions. RFC 2253 - Lightweight Directory Access Protocol (v3): UTF-8 String Representation of DNs RFC 2254 - The String Representation of LDAP Search Filters RFC 2255 - The LDAP URL Format Hall & Newton I-D Expires: August 2002 [page 58]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 RFC 2256 - A Summary of the X.500(96) User Schema for use with LDAPv3 RFC 2308 - Negative Caching of DNS Queries (DNS NCACHE) RFC 2782 - A DNS RR for specifying the location of services (DNS SRV) RFC 2798 - Definition of the inetOrgPerson LDAP Object Class RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification [namedref] - <draft-zeilenga-ldap-namedref-04.txt> - Named Subordinate References in LDAP Directories [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> - Internet Registry Directory Requirements [ldap-whois-dns] - <draft-ietf-crisp-lw-dns-00.txt> - Defining and Locating DNS Domains using the Internet Resource Query Service [ldap-whois-ipv4] - <draft-ietf-crisp-lw-ipv4-00.txt> - Defining and Locating IPv4 Address Blocks using the Internet Resource Query Service [ldap-whois-ipv6] - <draft-ietf-crisp-lw-ipv6-00.txt> - Defining and Locating IPv6 Address Blocks using the Internet Resource Query Service [ldap-whois-asn] - <draft-ietf-crisp-lw-asn-00.txt> - Defining and Locating Autonomous System Numbers using the Internet Resource Query Service [ldap-whois-user] - <draft-ietf-crisp-lw-user-00.txt> - Defining and Locating Contact Persons using the Internet Resource Query Service On a related note, VeriSign has been working on an RLDAP project [described in draft-newton-ldap-whois-00.txt (Whois Domain Data in LDAP)] that uses a query model very similar to the one described in this document, and which illustrates many of the points described in this document. The current RLDAP implementation has three client implementations, multiple distributed servers, and Hall & Newton I-D Expires: August 2002 [page 59]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 contains more than 32 million DNS domain entries, and 115 million resource-specific entries. In many regards, this document is an extension of RLDAP. 15. Acknowledgments Portions of this work were funded by Network Solutions, Inc. 16. Changes from Previous Versions draft-ietf-crisp-lw-core-00: * As a result of the formation of the CRISP working group, the original monolithic document has been broken into multiple documents, with draft-ietf-crisp-lw-core describing the core service, while related documents describe the per-resource schema and access mechanisms. * References to the ldaps: URL scheme have been removed, since there is no standards-track specification for the ldaps: scheme. * An acknowledgements section was added. draft-hall-ldap-whois-01: * The ôObjectivesö section has been removed. [ir-dir-req] is now being used as the guiding document for this service. * Several typographical errors have been fixed. * Some unnecessary text has been removed. * Figures changed to show complete sets of object classes, to improve inheritance visibility. * Clarified the handling of reverse-lookup domains (zones within the in-addr.arpa portion of the DNS hierarchy) in the inetDnsDomain object class reference text. * Referrals now use regular LDAP URLs (multiple responses with explicit hostnames and port numbers). Prior editions Hall & Newton I-D Expires: August 2002 [page 60]
Internet Draft draft-ietf-crisp-lw-core-00.txt July 2002 of this specification used LDAP SRV resource records for all referrals. * The delegation status codes used by the inetDnsDelegationStatus, inetIpv4DelegationStatus, inetIpv6DelegationStatus and inetAsnDelegationStatus attributes have been condensed to a more logical set. * Added an inetDnsAuthServers attribute for publishing the authoritative DNS servers associated with a domain. NOTE THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND ATTRIBUTES. * Added an inetGeneralDisclaimer attribute for publishing generalized disclaimers. * Added the inetAssociatedResources auxiliary object class for defining associated resources, and moved some of the IP addressing and ASN attributes to the new object class. * Several attributes had their OIDs changed. NOTE THAT THIS IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. Hall & Newton I-D Expires: August 2002 [page 61]
