[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

  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]
  

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/