INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-ietf-crisp-firs-core-00.txt draft-ietf-crisp-firs-core-01.txt                    May 2003
  Expires: December, 2003
  Category: Standards-Track

                  The Federated Internet Registry Service:
                                Core Elements

     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.

     Copyright Notice

     Copyright (C) The Internet Society (2003).  All Rights Reserved.

     Abstract

     This document describes the core technical elements of the
     Federated Internet Registry Service (FIRS), a distributed service
     for storing, locating and transferring information about Internet
     resources using LDAPv3.

     Table of Contents

     1.   Introduction..............................................3   Introduction...............................................3
     2.   Prerequisites and Terminology.............................3 Terminology..............................3
     3.   The FIRS Namespace........................................4 Namespace.........................................4
       3.1.  The domainComponent (dc=) Namespace Component..........4 Component...........4
       3.2.  The inetResources Namespace Component..................5 Component...................5
       3.3.  The Resource-Specific Namespace Component..............6 Component...............5
       3.4.  Referrals..............................................6  Referrals...............................................6
           3.4.1.  Subordinate reference referrals..................9 referrals...................8
           3.4.2.  Continuation reference referrals.................9
       3.5.  Partition Replicas....................................10 referrals..................9
     4.   Global FIRS Object Classes and Attributes................11 Attributes..................9
       4.1.  The inetResources Object Class........................11 Class..........................9
           4.1.1.  Naming syntax...................................11 syntax.....................................9
           4.1.2.  Schema definition...............................11 definition................................10
           4.1.3.  Example.........................................14  Example..........................................12
       4.2.  The inetAssociatedResources Object Class..............15 Class...............12
           4.2.1.  Naming syntax...................................15 syntax....................................13
           4.2.2.  Schema definition...............................16 definition................................13
           4.2.3.  Example.........................................17  Example..........................................14
       4.3.  The referral Object Class.............................18 Class..............................15
     5.   Global Query Processing Rules............................18 Rules.............................15
       5.1.  Query Pre-Processing..................................19 Pre-Processing...................................16
       5.2.  Query Bootstrap Models................................20 Models.................................18
           5.2.1.  Targeted Query Processing.......................21 query processing........................18
           5.2.2.  Top-Down Processing.............................22  Top-down processing..............................19
           5.2.3.  Bottom-Up Processing............................25  Bottom-up processing.............................22
           5.2.4.  SRV processing..................................28 processing...................................25
       5.3.  Query Processing......................................29 Processing.......................................26
           5.3.1.  Search Filters..................................29  Matching filters.................................26
           5.3.2.  Authentication and access controls..............31  Query-volume restrictions........................28
           5.3.3.  Authentication restrictions......................29
           5.3.4.  Protocol and schema version controls............32 controls.............29
       5.4.  Post-Query Processing.................................32  Referral Processing....................................30
     6.   Security Considerations..................................35 Considerations...................................33
     7.   IANA Considerations......................................35 Considerations.......................................33
     8.   Author's Addresses.......................................35 Addresses........................................34
     9.   Normative References.....................................35 References......................................34
     10.  Acknowledgments..........................................37  Acknowledgments...........................................36
     11.  Changes from Previous Versions...........................37 Versions............................36
     12.  Full Copyright Statement.................................39 Statement..................................38

  Hall                  I-D Expires: December 2003             [page 2] 
  1.      Introduction

     This specification defines the core object classes, attributes,
     syntax rules, extensibleMatch matching filters, and operational behaviors for the
     FIRS service as a whole. Refer to [FIRS-ARCH] for information on
     the FIRS architecture, and the resource-specific specifications
     for definitions and rules which govern each of the different
     resource-types.

     The definitions in this specification are intended to be used with
     FIRS. Their usage outside of FIRS is not prohibited, but any such
     usage is beyond this specification's scope of authority.

  2.      Prerequisites and Terminology

     The complete set of specifications in the FIRS collection
     cumulative define a structured and distributed information service
     using LDAPv3 for the data-formatting and transport functions. This
     specification should be read in the context of the complete set of
     specifications, which currently include the following:

            draft-ietf-crisp-firs-arch-00,

            draft-ietf-crisp-firs-arch-01, "The Federated Internet
            Registry Service: Architecture and Implementation"
            [FIRS-ARCH]

            draft-ietf-crisp-firs-core-00,

            draft-ietf-crisp-firs-core-01, "The Federated Internet
            Registry Service: Core Elements" (this document)
            [FIRS-CORE]

            draft-ietf-crisp-firs-dns-00,

            draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS
            Domains in the Federated Internet Registry Service"
            [FIRS-DNS]

            draft-ietf-crisp-firs-dnsrr-00,

            draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS
            Resource Records in the Federated Internet Registry
            Service" [FIRS-DNSRR]

            draft-ietf-crisp-firs-contact-00,

            draft-ietf-crisp-firs-contact-01, "Defining and Locating
            Contact Persons in the Federated Internet Registry Service"
            [FIRS-CONTCT]

            draft-ietf-crisp-firs-asn-00,

            draft-ietf-crisp-firs-asn-01, "Defining and Locating
            Autonomous System Numbers in the Federated Internet
            Registry Service" [FIRS-ASN]

  Hall                  I-D Expires: December 2003             [page 3] 
            draft-ietf-crisp-firs-ipv4-00, 
            draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4
            Address Blocks in the Federated Internet Registry Service"
            [FIRS-IPV4]

            draft-ietf-crisp-firs-ipv6-00,

            draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6
            Address Blocks in the Federated Internet Registry Service"
            [FIRS-IPV6]

     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.      The FIRS Namespace

     The FIRS namespace acts as an index to the federated partition
     structure of the globally-distributed database of FIRS servers.
     There are three major components to this namespace, which are:

        *   The domainComponent entries. Each partition of the globally
            distributed FIRS directory database is represented by a
            sequence of domainComponent distinguished names. These
            sequences effectively identify the root scope of authority
            for each partition in the global directory database.

        *   An inetResources entry. All of the FIRS-related resource-
            specific entries in the global database are required to be
            stored within a well-known "cn=inetResources" container
            entry at the root of each directory partition. These well-
            known entries act as application-specific access points
            within the globally distributed directory database.

        *   The resource-specific entries. Each of the resource-
            specific entries within the inetResources container entries
            have their own unique naming rules, as defined in the
            governing specifications for those resources.

     These naming rules are discussed in more detail below.

  3.1.    The domainComponent (dc=) Namespace Component

     The global FIRS directory database is divided into administrative
     partitions, each of which represent a scope-of-authority for a
     certain portion of the global database. The root of these
     partitions each partition
     is formally defined as represented by a sequence of domainComponent relative
     distinguished names (RDNs), as defined in RFC 2247 [RFC2247]. In
     this model, the scope-of-authority for a FIRS partition is derived

  Hall                  I-D Expires: December 2003             [page 4] 
     In this model, a sequence of domainComponent RDNs map to 
     from a
     sequence of domain names in the global DNS hierarchy, with the
     FIRS partitions mapping to the zones which are managed by the
     governing organization. As such, the DNS namespace delegations act
     as FIRS partition delegation, providing natural scopes of
     administrative control name in the global FIRS namespace. Furthermore,
     the SRV resource records associated with those DNS domains also
     provide a useful mechanism for locating the authoritative LDAP
     servers associated with directory, meaning that
     whoever has authority over any particular resource in the global FIRS
     directory database.

     Since the partition roots determine the scope of control over a
     set of resources, partitions which overlap also have overlapping
     scopes of control. For example, the "dc=com" and
     "dc=example,dc=com" partitions can both provide information about
     the "www.example.com" domain name resource. In order to reduce effectively
     has authority over the
     amount of ambiguity which is naturally present in this kind of
     model, related FIRS defines multiple bootstrapping models and also defines
     the default model which should be used for any given resource. For
     example, queries for centrally-delegated resources are supposed to
     ask the top-level partition for information about those resources,
     while queries for user-managed resources are supposed to ask the
     leaf-node partition for information about those resources. partition.

     Note that the domainComponent attribute is restricted to seven-bit
     character codes, and is therefore effectively limited to using
     character codes from US-ASCII [US-ASCII]. Due to this limitation,
     internationalized domain names MUST be converted into their ASCII-
     compatible forms using the "ToASCII" process defined in RFC 3490
     [RFC3490] before the domainComponent RDNs are stored used in the
     directory database, and before any searches which reference those
     partitions are formed. database or LDAP messages.

  3.2.    The inetResources Namespace Component

     The FIRS FIRS-specific directory database is further separated entries are segregated from the
     directory partition structure other
     application-specific entries by the use of a well-known container entry with
     the MANDATORY name of "cn=inetResources". Any entry which is to be
     located and retrieved through FIRS MUST refer to this container entry.

     Note that these rules this rule specifically apply applies to entries which are to
     be locatable located by FIRS clients. The entries themselves MAY use be
     referrals to which reference entries in other namespace locations if this is
     necessary or desirable (see section 3.4), although it is

  Hall                  I-D Expires: December 2003             [page 5] important
     for administrators to recognize that those the referral targets will not
     be locatable through FIRS.

  3.3.    The Resource-Specific Namespace Component

     Every resource-specific entry also has a RDN which identifies that
     resource within the context of the inetResources container of any
     given partition. Examples of these resource-specific entries can
     be seen in Figure 1 of [FIRS-ARCH], and include "cn=example.com"
     which refers to the "example.com" DNS domain name resource, and
     "cn=admins@example.com" which refers to the "admins@example.com"
     contact resource.

     Each of the FIRS resource-types have their own specific naming
     rules which govern those resources. Refer to the resource-specific
     specifications for information on those rules.

     Note that these the rules specifically apply to entries which are to be locatable
     located by FIRS clients. The entries themselves MAY use be referrals to
     which reference entries in other namespace locations if this is necessary or
     desirable (see section 3.4), although it is important for
     administrators to recognize that those the referral targets will not be
     locatable through FIRS.

  Hall                  I-D Expires: December 2003             [page 5] 
  3.4.    Referrals

     FIRS allows entries in the namespace to refer to other entries, as
     necessary or desirable. This model allows certain entries to be
     created as "placeholders" for other canonical entries which
     contain the actual data. In turn, this allows organizations to
     collectively publish shared entries as discrete objects (such as
     allowing a user's leaf-node directory partition to publish an
     entry for an ISP's web server as if it were their own entry),
     allows partitions to reuse common data, and provides numerous
     other benefits.

     FIRS allows two methods for generating and processing these
     referrals: subordinate reference referrals, and continuation
     reference referrals, both of which are defined in RFC 3296
     [RFC3296]. Note that the "superior reference referral" defined in
     RFC 2251 [RFC2251] used as a "default referral" for out-of-scope
     searches is explicitly unsupported in FIRS; any superior reference
     referrals which are encountered as a part of this service are to
     be treated as errors.

  Hall                  I-D Expires: December 2003             [page 6] referrals.

     Subordinate reference referrals indicate that the queried entry search base in
     the original query is an alias for some other entry, and that the
     query has to be restarted with a new search base in order for the current
     search operation to be completed. processed. Meanwhile, continuation references
     reference referrals indicate that the search was successfully
     initiated and that some data has been found, but that additional
     queries for additional resources are required for the original query to be
     completely exhausted.

     Subordinate references and continuation references reference referrals use the ref
     attribute and referral object class defined in RFC 3296 [RFC3296].
     Each of these mechanisms use LDAP URLs as defined in RFC 2255
     [RFC2255],
     [RFC2255] to carry referral data, with some additional FIRS-specific FIRS-
     specific restrictions.

     Among these restrictions:

        *   Referral source entries MUST comply with all of the
            applicable namespace and schema rules.

        *   Referral targets MUST use the domainComponent ("dc=")
            naming syntax for their directory partitions. Although
            other naming syntaxes are implicitly allowed by [RFC3296],
            those syntaxes are only guaranteed to be resolvable if they
            use domainComponent sequences.

        *   Referral targets are encouraged to reside in an
            inetResources container entry, although this is not
            required. For example, a general-purpose administrative
            contact entry may need to refer to a user-specific contact
            entry in another container if this is necessary, and this
            kind of usage is allowed.

  Hall                  I-D Expires: December 2003             [page 6] 
        *   Referral sources and targets MUST have the same resource-
            specific object class 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.

        *   Referral targets MAY exist as referrals to other entries,
            but recursive referrals are discouraged. Clients MAY
            discontinue referral processing after a reasonable amount
            of effort (eight referrals is a suggested default value).

        *   The protocol identifier of a URL MUST specify the LDAP
            service type. Although general-purpose LDAP referrals are
            allowed to specify any kind of protocol, FIRS referrals are

  Hall                  I-D Expires: December 2003             [page 7]
            intended to be used for automated queries, and the use of
            other protocols is forbidden in the default case.

        *   URLs MAY specify host identifiers and port numbers, but
            none of these elements are required.

        *   The distinguished name element of an LDAP URL MUST specify
            the search base of the referral target.

        *   If a matching filter and/or assertion value needs to be
            specified,
            specified in the referral, they MUST be specified in the
            filter element of
            an the referral's LDAP URL. New matching Matching filters
            and/or assertion values MUST NOT be specified unless the
            referral source needs to explicitly refer to reference a specific
            target entry in a specific partition. This should only be
            necessary in those cases where the referral target entry is
            would not normally be located (most likely due to a leaf-node with no
            additional referrals, and where the target is substantially
            and significantly
            radically different from the referral source. entry name).

        *   The attribute, scope and extension elements of LDAP URLs
            will be ignored by the client, and SHOULD NOT be provided.

        *   URLs MUST be provided and stored in use 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, Similarly, some domain names and email
            addresses contain UTF-8 character data, and some of the matching rules described in this
            document require that the URLs also those
            character codes will need to be stored in this
            format escaped in order for the searches to succeed. be
            passed as URL data.

        *   Implementations MUST NOT restrict URL values to verifiable
            entries from local partitions. Implementations MAY validate

  Hall                  I-D Expires: December 2003             [page 7] 
            referral targets in URLs, but a lack of knowledge regarding
            a target MUST NOT be treated as sufficient cause to prevent
            the referral target from being specified.

     Clients MAY implement additional support

     The rules for non-LDAP processing referral URLs which are provided in conflict with the requirements above. However,
     clients MUST NOT violate any other mandates given in this document while
     doing so (in particular, clients MUST NOT break section 5.4.

     Note that the query-
     processing procedures "superior reference referral" defined in section 5.1 RFC 2251
     [RFC2251] used as a "default referral" for out-of-scope searches
     is explicitly unsupported in FIRS; any superior reference
     referrals which are encountered as a part of this document). service are to
     be treated as errors.

     Each of the supported redirection referral mechanisms are discussed in more
     detail below.

  Hall                  I-D Expires: December 2003             [page 8]

  3.4.1.  Subordinate reference referrals

     Subordinate reference referrals are defined in [RFC3296], and are
     returned when whenever the search base specified in a query exists as a
     referral to some other entry. This means that the entire query MUST be
     restarted, using the referral target as the new search base.

     Any entries 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 directory branch. partition.

     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

  Hall                  I-D Expires: December 2003             [page 8] 
     appropriate for the resource in question, and MAY also be
     referrals to other entries.

     Client rules for processing subordinate reference referrals are
     given in section 5.2.3.h.

  3.4.2.  Continuation reference referrals

     Continuation reference referrals are defined in RFC 2251
     [RFC2251], and 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

  Hall                  I-D Expires: December 2003             [page 9] reference referral can be the only response, but
     it won't be the only response in the common case).

     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,

  4.      Global FIRS Object Classes and have specific Attributes

     Each of the schema definitions provided in this document include
     attribute definitions, naming
     requirements rules, and other definitions which
     are necessary for the matching functions designed to
     work properly. These considerations are described in Error!
     Reference source not found..

     Client rules for processing continuation reference referrals are
     also given in section Error! Reference source not found..

  3.5.    Partition Replicas
     All directory partitions which provide data for global Internet
     resources SHOULD be replicated across two or more servers. Each of facilitate the authoritative LDAP servers for consistent storage and retrieval of
     information within the managed resource MUST be
     specified with FIRS service.

  4.1.    The inetResources Object Class

     The inetResources object class is a unique DNS SRV resource record for structural object class which
     defines the domain
     name attributes associated with the top-level resource assignment space.

     Directory partitions which serve multiple organizations SHOULD
     also be replicated. For example, an ISP "cn=inetResources"
     container entry, and which provides FIRS
     services for their customers SHOULD also follow these same rules,
     since outages of those servers will affect multiple parties. Leaf-
     node directory partitions general information about the
     network resources 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 current directory partitions with partition.

  4.1.1.  Naming syntax

     This document requires the
     delegation parents, as this will allow queries for those resources presence of an entry named
     "cn=inetResources" in the root of every directory partition which
     provides FIRS services.

  Hall                  I-D Expires: December 2003             [page 10] 
     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" directory partition cannot
     be expected to host replicas of every subordinate directory
     partition), but it is encouraged where practical.

     It is also expected that certain servers will be configured to
     serve as multi-replica masters, effectively acting as large-scale
     caching servers for many different resources. When used in
     conjunction with the targeted bootstrap model described in section
     5.2.1, this will allow clients to retrieve a significant amount of
     information without having to pursue a large number of referrals
     or redirects. This usage is expected and endorsed.

     Finally, it is also important to note that neither this
     specification nor the LDAP protocol currently provide cache timers
     or any other mechanisms which can indicate how accurate or timely
     any replicas may be.

  4.      Global FIRS Object Classes and Attributes
     Each of the schema definitions provided in this document include
     attribute definitions, naming rules, and other definitions which
     are designed to facilitate the consistent storage and retrieval of
     information within the FIRS service.

  4.1.    The inetResources Object Class
     The inetResources object class is a structural object class which
     defines the attributes associated with the "cn=inetResources"
     container entry, and which provides general information about the
     network resources associated with the current directory partition.

  4.1.1.  Naming syntax
     This document requires the presence of an entry named
     "cn=inetResources" in the root of every directory partition which
     provides FIRS services.

  4.1.2.  Schema definition
     Every 9] 
  4.1.2.  Schema definition

     Every directory partition which provides public FIRS data MUST
     have a "cn=inetResources" entry in the root of the directory

  Hall                  I-D Expires: December 2003            [page 11] 
     partition. The inetResources entry MUST exist with the top and
     inetResources object classes defined. If the entry exists as a
     referral source, 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.

     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. Since 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 attribute values is undesirable or unfeasible.

     Since multiple directory partitions can use subordinate reference
     referrals to share a single common inetResources entry, it is
     important for the data to be applicable to all of the entries
     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 FIRS data across all MUST
     have a "cn=inetResources" entry in the root of their hosted domains the directory
     partition. The inetResources entry MUST exist with the top and routed networks.
     inetResources object classes defined. If
     separate contacts are required for each resource, the contact data
     should entry exists as a
     referral source, the entry MUST also be specified within each entry, rather than being linked defined with the referral
     object class, in addition to the inetResources entry. above requirements.

     The inetResources object class provides several multi-valued
     contact-related attributes for is a variety of well-known
     administrative roles. This model allows the inetResources entry
     and each of the structural object class which
     is subordinate managed resources to share the top abstract class, and which MUST be
     treated as a common
     set container class capable of administrative roles, or to have unique roles for each
     resource, as seen fit by the managing entity. 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 contact-
     related attributes use the inetContactSyntax syntax rules other object classes
     defined
     in [FIRS-CONTACT] for their values. use with FIRS are subordinate to the inetResources
     object class and inherit its attributes.

     The schema definition for the inetResources object class is as
     follows:

  Hall                  I-D Expires: December 2003            [page 12]

          inetResources
          ( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The
            inetResources container for the FIRS service' SUP top
            STRUCTURAL MUST cn MAY ( o $ ou $ description $
            inetResourceComments $ businessCategory $ telephoneNumber $
            facsimileTelephoneNumber $ labeledURI $
            preferredDeliveryMethod $ physicalDeliveryOfficeName $
            postOfficeBox $ postalAddress $ postalCode $ street $ l $
            st $ c $ inetAbuseContacts $ inetGeneralContacts $
            inetSecurityContacts $ inetTechContacts $
            inetGeneralDisclaimer ) )

     The attributes from the inetResources object class are described
     below:

          businessCategory, see RFC 2256 [RFC2256], section 5.16

          c (country), see [RFC2256], section 5.7

          cn (commonName), see [RFC2256], section 5.4

          description, see [RFC2256], section 5.14

  Hall                  I-D Expires: December 2003            [page 10] 
          facsimileTelephoneNumber, see [RFC2256], section 5.24

          inetAbuseContacts
          ( 1.3.6.1.4.1.7161.1.0.2 NAME 'inetAbuseContacts' DESC
            'Contacts for reporting abusive behavior or acceptable-use
            policy violations.' EQUALITY caseIgnoreMatch SYNTAX
            inetContactSyntax )

          inetGeneralContacts
          ( 1.3.6.1.4.1.7161.1.0.3 NAME 'inetGeneralContacts' DESC
            'Contacts for general administrative issues.' EQUALITY
            caseIgnoreMatch SYNTAX inetContactSyntax )

          inetGeneralDisclaimer
          ( 1.3.6.1.4.1.7161.1.0.4 NAME 'inetResourceComments' DESC
            'General disclaimer text regarding this data' EQUALITY
            caseIgnoreMatch SYNTAX DirectoryString{1024} )

          inetResourceComments
          ( 1.3.6.1.4.1.7161.1.0.5 NAME 'inetResourceComments' DESC
            'General comments about this entry' EQUALITY
            caseIgnoreMatch SYNTAX DirectoryString{1024} )

  Hall                  I-D Expires: December 2003            [page 13]

          inetSecurityContacts
          ( 1.3.6.1.4.1.7161.1.0.6 NAME 'inetSecurityContacts' DESC
            'Contacts for general security issues.' EQUALITY
            caseIgnoreMatch SYNTAX inetContactSyntax )

          inetTechContacts
          ( 1.3.6.1.4.1.7161.1.0.7 NAME 'inetTechContacts' DESC
            'Contacts for general technical issues.' EQUALITY
            caseIgnoreMatch SYNTAX inetContactSyntax )

          l (locality), see [RFC2256], section 5.8

          labeledURI, see RFC 2079 [RFC2079]

          o (organization), see [RFC2256], section 5.11

          ou (organizational unit), see [RFC2256], section 5.12

          physicalDeliveryOfficeName, see [RFC2256], section 5.20

          postalAddress, see [RFC2256], section 5.17

  Hall                  I-D Expires: December 2003            [page 11] 
          postalCode, see [RFC2256], section 5.18

          postOfficeBox, see [RFC2256], section 5.19

          preferredDeliveryMethod, see [RFC2256], section 5.29

          st (stateOrProvinceName), see [RFC2256], section 5.9

          street (streetAddress), see [RFC2256], section 5.10

          telephoneNumber, see [RFC2256], section 5.21

  4.1.3.  Example

     An example of the inetResources object class in use is shown in
     Figure 1 below.

  Hall                  I-D Expires: December 2003            [page 14]

          cn=inetResources,dc=example,dc=com
          [top object class]
          [inetResources object class]
          |
          +-attribute: o
          | value: "Example Widgets' network resources"
          |
          +-attribute: inetGeneralContacts
          | value: "admins@example.com"
          |
          +-attribute: telephoneNumber
          | value: "1-800-555-1212"
          |
          +-attribute: inetResourceComments
            value: "Please don't send complaints to the
                    postmaster@example.com mailbox."

     Figure 1: The Example Widgets inetResources container entry.

  4.2.    The inetAssociatedResources Object Class

     The inetAssociatedResources object class defines attributes which
     are useful for cross-referencing entries with other resources. For
     example, it allows inetOrgPerson entries to be associated with
     IPv4 networks or DNS domains, providing generic cross-reference
     pointer attributes (this information may be useful if a single
     organization has multiple DNS domains registered). 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.

  Hall                  I-D Expires: December 2003            [page 12] 
  4.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 defined under the rules associated
     with the structural object class that defines the Internet
     resource in question. As such, the naming rules associated with
     that entry take precedence, and the inetAssociatedResources object
     class does not define an independent naming syntax.

  Hall                  I-D Expires: December 2003            [page 15]

  4.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,
     and only has optional attributes.

     Although the inetAssociatedResources object class is subordinate
     to the top object class, it is intended to be used with the
     resource-specific structural object classes defined for use with
     FIRS. 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
     entry, particularly if the referenced person (or role) is
     responsible for the management of multiple resources.

     The inetAssociatedResources object class MUST NOT be associated
     with an entry that only exists as a referral source.

     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 multiple associated DNS domain name resources
     using a multi-valued array, with each domain name using the
     inetDnsDomainSyntax naming rules defined in [FIRS-DNS].

     The schema definition for the inetAssociatedResources object class
     is as follows:

  Hall                  I-D Expires: December 2003            [page 13] 
          inetAssociatedResources
          ( 1.3.6.1.4.1.7161.1.5.0 NAME 'inetAssociatedResources' DESC
            'Internet resources associated with this resource.' SUP top
            AUXILIARY MAY ( inetAssociatedContacts $
            inetAssociatedDnsDomains $ inetAssociatedIpv4Networks $
            inetAssociatedIpv6Networks $ inetAssociatedAsNumbers ) )

     The attributes from the inetAssociatedResources object class are
     described below:

          inetAssociatedAsNumbers
          ( 1.3.6.1.4.1.7161.1.5.2 NAME 'inetAssociatedAsNumbers' DESC
            'Autonomous system numbers associated with this Internet
            resource.' EQUALITY caseIgnoreMatch SYNTAX
            inetAsNumberSyntax )

  Hall                  I-D Expires: December 2003            [page 16]

          inetAssociatedContacts
          ( 1.3.6.1.4.1.7161.1.5.3 NAME 'inetAssociatedContacts' DESC
            'Other contacts associated with this Internet resource.'
            EQUALITY caseIgnoreMatch SYNTAX inetContactSyntax )

          inetAssociatedDnsDomains
          ( 1.3.6.1.4.1.7161.1.5.4 NAME 'inetAssociatedDnsDomains' DESC
            'DNS domains associated with this Internet resource.'
            EQUALITY caseIgnoreMatch SYNTAX inetDnsDomainSyntax )

          inetAssociatedIpv4Networks
          ( 1.3.6.1.4.1.7161.1.5.5 NAME 'inetAssociatedIpv4Networks'
            DESC 'IPv4 networks associated with this Internet
            resource.' EQUALITY caseIgnoreMatch SYNTAX
            inetIpv4NetworkSyntax )

          inetAssociatedIpv6Networks
          ( 1.3.6.1.4.1.7161.1.5.6 NAME 'inetAssociatedIpv6Networks'
            DESC 'IPv6 networks associated with this entry.' EQUALITY
            caseIgnoreMatch SYNTAX inetIpv6NetworkSyntax )

  4.2.3.  Example

     An example of the inetAssociatedResources object class is shown in
     Figure 2 below.

  Hall                  I-D Expires: December 2003            [page 14] 
          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 Example Widgets network"
          |
          +-attribute: inetAssociatedAsNumbers
          | value: "65535"
          |
          +-attribute: inetAssociatedDnsDomains
            value: "example.com" "2.0.192.in-addr.arpa"

     Figure 2: The inetAssociatedResources attributes associated with
     the 192.0.2.0/24 IPv4 network entry.

  Hall                  I-D Expires: December 2003            [page 17]

  4.3.    The referral Object Class
     This document allows the inetResources container entries and the
     subordinate resource-specific entries to

     Entries use the referral object class to define subordinate
     reference referrals and continuation reference referrals. referrals, thereby
     facilitating the programmatic redirection of queries in support of
     the referral mechanisms defined in section 3.4.

     Referral entries MUST conform to the schema specification defined
     in [RFC3296]. In particular, referral entries

     Referral sources MUST NOT contain any user-definable attributes
     (other than the mandatory naming
     attribute). Referral entries MUST be leaf nodes, attribute), and MUST NOT have any
     subordinate entries defined at child entries.

     Refer to section 3.4 for the rules that govern referral source.

     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 directory partition which uses the domainComponent object class
     syntax ("dc="), and MUST specify the LDAP protocol-type.
     FIRS. Refer to section 3.4 5.4 for more information on the use of referrals processing referral
     URLs in FIRS.

  5.      Global Query Processing Rules

     Another critical aspect to FIRS is the query-processing behavior.
     These rules govern the ways in which a client parses a query,
     locates a server which is authoritative for the resource being
     queried, generates LDAPv3 queries, and processes any resulting
     referrals. More specifically:

        *   Query pre-processing. The first step is for the client to
            prepare the query. Portions of this process require the

  Hall                  I-D Expires: December 2003            [page 15] 
            client to determine the type of resource being queried for,
            and to determine the initial partition which should be used
            for the query. Since this process is different for each
            particular resource-type, the rules which govern this
            behavior are defined in each of the resource-specific
            specifications.

        *   Bootstrap processing. Once a partition has been determined,
            the client must locate the LDAP servers which are
            authoritative for the resource in question. Section 5.2 0
            defines three different bootstrap models that clients can
            use as part of this process, while each of the resource-
            specific specifications define which of the models are to
            be used for each particular resource-type.

  Hall                  I-D Expires: December 2003            [page 18]

        *   Query processing. Once a server has been located, the
            client must submit the LDAP query which was formed during
            the pre-preprocessing phase. Section 5.3 defines the global
            considerations for all FIRS queries, while the resource-
            specific specifications also define additional parameters.

        *   Query post-processing. FIRS explicitly supports different
            types of LDAP referral mechanisms, any of which may result
            in the client application restarting the query or
            initiating a brand-new query. These mechanisms and their
            behavioral rules are defined in section 5.4.

     Each of these phases are discussed in more detail below.

  5.1.    Query Pre-Processing

     Client input is generally provided as limited to a single well-formed unit of
     data, such as a domain name ("example.com") or an email address
     ("admins@example.com"). Since
     ("admins@example.com"), and this single piece of information is typically all
     that's provided, it must
     be used to subsequently build a fully-
     formed fully-formed LDAPv3 query,
     including the assertion value, the search base, the matching
     filter, and so forth. All of these steps are part of the pre-processing pre-
     processing phase.

     Although the exact sequence of steps will vary according to the
     resource-type being queried, there are some commonalities between
     each of them. Among these steps:

        *   Determine the resource type. Different kinds of resources
            have different processing steps, validation mechanisms, and
            so forth, each of which require that the resource-type be

  Hall                  I-D Expires: December 2003            [page 16] 
            appropriately identified. Clients MAY use any mechanisms
            necessary to force this determination.

        *   Validate and normalize the data. In all cases, the input
            data MUST be validated and normalized according to the
            syntax rules defined in the specification which governs the
            resource-type. As an example of this step, queries for
            internationalized domain names must be validated and
            normalized into a canonical UTF-8 form before any other
            steps can be taken, with the
            domain name being validated as part of the normalization
            process. taken. Similarly, IPv6 addresses are required
            to conform to specific syntax rules, and input address may
            need to be expanded or compressed in order to comply these with
            the syntax requirements.

  Hall                  I-D Expires: December 2003            [page 19]

        *   Determine the appropriate authoritative directory partition for the
            query. Different kinds of resources have different default
            choices.
            named resource. In most cases, the appropriate authoritative partition
            will be a variation of the input query string, but this is
            not always the case. For example, the default partition for
            an email address will be extrapolated from the domain
            component of the email address itself, while the default
            authoritative partition for an ASN is uses a reserved
            (special-purpose) domain name. In some cases, the
            selected
            authoritative partition may change as a result of errors or
            referrals encountered during later phases of the process. subsequent
            query-processing steps.

        *   Determine the search base for the query. In most cases, Each resource type
            has resource-specific query-processing rules which will
            dictate how the authoritative partitions are mapped to the
            search base will refer to base. In some cases, the inetResources cn=inetResources container
            entry
            within in the authoritative partition which was determined will be used "as-is",
            while in other cases, the prior
            step, with these elements being combined into an FQDN. cn=inetResources container entry
            in a delegation parent of the authoritative partition will
            be used instead. In some cases, the search base may need to be changed as a
            result of referrals encountered change
            during later phases of the
            process. subsequent query-processing steps.

        *   Determine the assertion value for the query. The assertion
            value will usually be the normalized form of the input
            query. In some cases, the assertion value may need to be
            changed as a result of referrals encountered change during later
            phases of the process.
            subsequent query-processing steps.

        *   Determine the matching filter. Each resource-type has its
            own matching filter rules. In some cases, the matching
            filter will be For example, contact entries are
            matched with a simple equalityMatch comparison, while in
            other cases the matching filter will be an extensibleMatch
            which is peculiar to the resource-type in use.

  Hall                  I-D Expires: December 2003            [page 17] 
     Once all of the pre-processing steps have been successfully
     completed, the client must attempt will have to locate an LDAPv3 server which
     is authoritative for that resource. the search base before it can submit the
     query. This process is described in section 5.2 below.

  5.2.    Query Bootstrap Models

     Once a client has determined which partition should be queried for
     the specified resource, the client must determine which LDAP
     servers are authoritative for that partition.

     The FIRS service supports three different bootstrap models for
     this process, although these models only differ in relatively
     minor ways. Once ways; once a server has been located, the rest of the query

  Hall                  I-D Expires: December 2003            [page 20]
     process follows the same common basic path (issuing the LDAPv3 query,
     following any referrals which may be returned, referrals, and so forth).

     The three bootstrapping models defined for use with this service
     are the "targeted " model which is functionally identical to
     traditional lookups for LDAP servers, the "top-down" model which
     causes a client to submit a query to the root of a delegation
     hierarchy, and a "bottom-up" model which causes a client to work
     up through a delegation hierarchy until a server has been located.

  5.2.1.  Targeted Query Processing query processing

     The "targeted" model is similar to the traditional model of LDAP
     lookups, in that a client queries a previously specified LDAP
     server for a particular resource under the assumption that the
     resource exists on that server. If the server or resource does not
     exist (notwithstanding any referrals which may be returned), the
     entire query fails.

     The targeted model can be used when a fixed resource has been
     specified (such as may occur with a URL), but can also be used if
     the client prefers to use a "default" server for all operations.
     The latter may occur when clients use proxy servers, caching
     servers, or other fixed servers, in lieu of navigating the global
     directory database with every query. In all of these cases,
     however, failed lookups are considered to be fatal.

     The steps for processing targeted queries are described below:

        a.  Determine the IP address and port number to be used (this
            information may be determined from user input, a
            configuration file, a URL, or from any other source).

  Hall                  I-D Expires: December 2003            [page 18] 
            1.   If a non-ASCII domain name has been specified for this
                 purpose, convert the domain name into its ASCII-
                 compatible form using the "ToASCII" process defined in
                 [RFC3490] before performing any lookups.

            2.   Locate the LDAP servers associated with the domain
                 name through the SRV query steps provided in section
                 5.2.4. If this step fails, use DNS lookups for A
                 resource records instead. If no resource records are
                 available, report the error to the user and exit.

        b.  Once a server has been determined, submit the search
            operation. If the search operation fails, report the error

  Hall                  I-D Expires: December 2003            [page 21]
            to the user and exit. Otherwise, display any answer data
            which is returned.

        c.  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 Error!
            Reference source not found. 5.4 and restart
            the query process at step 5.2.1.a. For each continuation
            reference referral, display the answer data received so
            far, process the LDAP URLs according to the rules described
            in section Error!
            Reference source not found. 5.4 and start new query processes for each
            referral at step 5.2.1.a, 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.

        d.  Exit the query operation.

  5.2.2.  Top-Down Processing  Top-down processing

     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, a query is issued
     to the specified servers. This query may be subsequently
     redirected to other servers through the use of LDAP referrals.

  Hall                  I-D Expires: December 2003            [page 19] 
     The top-down model is primarily suited for locating Internet
     resources which are centrally managed and delegated, and where
     information about the delegation is desired. In particular, this
     includes resources such as DNS domain names, IP address blocks,
     and AS numbers.

     Note that the top-down model does not use incrementally larger
     domain names for the bootstrap process. Instead, it is assumed
     that the root partition in the delegation tree will be able to
     provide any necessary redirection services. For example, if the
     domain name of "www.example.co.uk" is used in a query, the query
     will be sent to the "dc=uk" partition, which should provide a

  Hall                  I-D Expires: December 2003            [page 22]
     referral for the "dc=co,dc=uk" partition, which in turn should
     provide a referral for the "dc=example,dc=co,dc=uk" partition.

     The steps for processing top-down queries are described below:

        a.  Determine the directory partition 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",
                 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.

        b.  Form the LDAP search base for the query.

            1.   If the client application allows non-ASCII input,
                 convert the domain name formed in step 5.2.2.a above
                 into its ASCII-compatible form using the "ToASCII"
                 process defined in RFC 3490.

  Hall                  I-D Expires: December 2003            [page 20] 
            2.   Convert the right-most element from the domain name
                 formed in step 5.2.2.b.1 into a domainComponent DN
                 (such as "dc=com" or "dc=arpa"). This represents the
                 directory partition for the current query.

            3.   Append "cn=inetResources" to the front of the
                 domainComponent syntax ("cn=inetResources,dc=com").
                 This will form the fully-qualified search base for the
                 LDAP query.

        c.  Locate the LDAP servers associated with the resource by
            processing the domain name formed in step 5.2.2.a above
            through the SRV query steps provided in section 5.2.4.

  Hall                  I-D Expires: December 2003            [page 23]

        d.  If the SRV lookup succeeds:

            1.   Choose the best LDAP server, using the weighting
                 formula described in [RFC2782].

            2.   Formulate the LDAP search using the search base and
                 search filter constructed earlier. 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
                 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".

            3.   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.

            4.   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 Error!
                 Reference source not found. 5.4 and
                 restart the query process at step 5.2.2.b. For each
                 continuation reference referral, display the answer
                 data received so far, process the LDAP URLs according

  Hall                  I-D Expires: December 2003            [page 21] 
                 to the rules described in section Error! Reference source not
                 found. 5.4 and start new
                 query processes for each referral at step 5.2.2.b,
                 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.

  Hall                  I-D Expires: December 2003            [page 24]

        e.  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.

        f.  Exit the query operation.

  5.2.3.  Bottom-Up Processing  Bottom-up processing

     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.
     If no servers are available for that partition, the parent
     partition in the delegation hierarchy is used instead, with this
     process repeating until a server has been located.

     The bottom-up model is best used when a leaf-node partition needs
     to be queried directly, either because there is no direct
     delegation path for the resource in question, or because the user-
     managed partition is preferable to the centralized delegation
     information. For example, there is no global delegation body which
     assigns and manages contact identifiers, so these identifiers need
     to be directed towards the leaf-node partitions directly. The
     bottom-up model can also be used for other kinds of resources if
     desirable, although in most cases the bottom-down model will be
     more useful for those resources.

     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.

            1.   Separate the input string into discrete elements where
                 this is possible. For a DNS domain name of

  Hall                  I-D Expires: December 2003            [page 22] 
                 "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

  Hall                  I-D Expires: December 2003            [page 25]
                 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.   If the client application allows non-ASCII input,
                 convert the domain name formed in step 5.2.3.b above
                 into its ASCII-compatible form using the "ToASCII"
                 process defined in RFC 3490.

            2.   Convert the domain name formed in step 5.2.3.c.1 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 directory
                 partition for the current query.

            3.   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 5.2.3.b above
            through the SRV query steps provided in section 5.2.4.

        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 used instead. 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,

  Hall                  I-D Expires: December 2003            [page 23] 
            with this process repeating until a search base can be
            located, or until a critical failure forces an exit.

            1.   Remove the left-most label from the domain name formed
                 in step 5.2.3.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).

  Hall                  I-D Expires: December 2003            [page 26]

            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 5.2.2.b, 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.   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".
                 If the SRV lookups had failed (resulting in "com"
                 being used as the authoritative directory partition),
                 then the search base for the query would also be
                 trimmed accordingly ("cn=inetResources,dc=com").

  Hall                  I-D Expires: December 2003            [page 24] 
            3.   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.

            4.   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 Error!

  Hall                  I-D Expires: December 2003            [page 27] 
                 Reference source not found.
                 according to the rules described in section 5.4 and
                 restart the query process at step 5.2.3.d. For each
                 continuation reference referral, display the answer
                 data received so far, process the LDAP URLs according
                 to the rules described in section Error! Reference source not
                 found. 5.4 and start new
                 query processes for each referral at step 5.2.3.d,
                 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).

        h.  Exit the query operation.

  5.2.4.  SRV processing

     The bootstrapping models described in this document make use of
     DNS SRV resource records to locate the LDAP servers associated
     with the resource provided in the query input.

     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".

  Hall                  I-D Expires: December 2003            [page 25] 
        b.  If the client allows non-ASCII characters to be input, then
            convert the domain name input into its ASCII-compatible
            form by using the "ToASCII" process described in [RFC3490].

        c.  Append the SRV label pair to the left of the input domain
            name from step 5.2.4.b. In the case of a query for the
            "example.com" domain, this would result in an SRV-specific
            domain name of "_ldap._tcp.example.com".

  Hall                  I-D Expires: December 2003            [page 28]

        d.  Issue a DNS query for the SRV resource records associated
            with the domain name formed in step 5.2.4.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 [RFC2782] for a detailed explanation of SRV resource
     records and their handling.

  5.3.    Query Processing

     Once an authoritative server for the partition in question has
     been located, the LDAP query can be submitted. In order to ensure
     interoperability, this specification defines several behavioral
     rules which clients and servers are encouraged to conform with.
     These guidelines are discussed in the following sections.

  5.3.1.  Search Filters  Matching 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 ensure
     interoperability, default values are defined here for many of
     these elements.

     Section 4.5.1 of

     [RFC2251] 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

  Hall                  I-D Expires: December 2003            [page 26] 
     FIRS clients and servers, this document defines some recommended
     and mandatory values for searches within the FIRS service.

            NOTE: These rules ONLY apply to the FIRS search operations
            in particular. Any queries for other resources (such as
            requests for inetOrgPerson contact entries) SHOULD NOT
            impose these restrictions. Also note that other documents

  Hall                  I-D Expires: December 2003            [page 29]
            which define additional resource types can also define
            different restrictions, and those definitions will take
            precedence over the global defaults.

     Servers MUST be prepared to enforce these rules independently of
     the client settings, and clients MUST be prepared to receive
     truncated search results accordingly.

     The default values of an LDAPv3 search filter in FIRS are:

        *   Search base. The directory partition 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 5.1,
            although FIRS searches are normally constrained to the
            "cn=inetResources" container of a particular directory
            partition.

        *   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 FIRS
            searches. Servers MUST NOT arbitrarily limit the scope of
            search operations.

        *   Dereference aliases. Although the FIRS service does not
            make direct use of alias entries, they are not prohibited.
            Clients SHOULD set the Dereference Aliases option to
            "Always" for FIRS searches. Servers SHOULD dereference any
            aliases which are encountered, where this is feasible (in
            particular, where the alias refers to another directory
            partition on the same server).

        *   Size limit. The size limit field specifies the maximum
            number of entries that a server should return. For the FIRS
            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

  Hall                  I-D Expires: December 2003            [page 27] 
            "cn=inetResources,dc=com" container). Servers MAY truncate
            answer sets to 100 responses if the client specifies a
            larger value.

        *   Time limit. The time limit field specifies the maximum
            number of seconds that a server should process the search.

  Hall                  I-D Expires: December 2003            [page 30]
            For the FIRS 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 FIRS queries, the filter MUST use
            the matching rules defined for the relevant resource type.

        *   Attribute list. Clients MAY restrict the list of attributes
            which are returned in searches, but are discouraged from
            doing so without cause.

  5.3.2.  Authentication and access controls  Query-volume restrictions

     The restrictions listed in section 5.3.1 represent suggested
     defaults, although server operators MAY impose any kinds of usage
     limits they deem necessary or desirable. For example,

     Specifically, server operators MAY restrict the number amount of queries that they will accept
     from a particular client
     information provided to specific clients and/or user users over a given
     amount of time.

     Server operators time, within reason. For example, servers MAY choose to restrict the amount
     clients to an arbitrary number of information
     provided queries per hour, per day, and
     so forth. Servers which refuse to specific clients process a query due volume
     policy SHOULD reject the connection and/or users. For example, query using the
     "unwillingToPerform" response code ("53").

     Clients MUST be prepared for connection requests and queries to be
     denied for any reason, and MUST treat these conditions as non-
     permanent failures. Clients MAY retry the operations if a known

  Hall                  I-D Expires: December 2003            [page 28] 
     error condition is corrected (such as authentication errors), but
     SHOULD NOT automatically generate retry attempts.

  5.3.3.  Authentication restrictions

     Servers operators SHOULD allow anonymous authentication for read-
     only access to public delegation data. Clients SHOULD use
     anonymous authentication by default.

     Wherever a server operator requires or desires clients to
     authenticate for access, servers MUST support the simple
     authentication mechanism defined in RFC 2222 [RFC2222], although
     server operators MAY choose require the use of any authentication
     mechanisms in addition to or instead of the simple mechanism.

     Server operators SHOULD NOT impose unreasonable requirements for
     proprietary authentication mechanisms for routine purposes.

     Server operators MAY withhold detailed contact privileged information from
     anonymous users or non-privileged clients, as necessary non-
     privileged clients or
     desirable. users, as necessary.

     Clients SHOULD NOT equate the absence of any attributes with the
     absence of data, and SHOULD assume that the user is not authorized
     to view any data which has not been provided.

     Servers SHOULD allow anonymous authentication for read-only access
     to public delegation data. Clients SHOULD use anonymous
     authentication by default. Server operators MAY require any kind
     of authentication mechanisms they wish for any other data,
     although operators are encouraged to use one of the well-known
     mechanisms commonly used with LDAPv3.

  Hall                  I-D Expires: December 2003            [page 31] 
     Clients MUST be prepared for connection requests and queries to be
     denied for any reason, and MUST treat these conditions as non-
     permanent failures. Clients MAY retry the operations if the error
     condition is corrected (such as having the user authenticate to
     the server), but SHOULD NOT automatically generate retry attempts
     for the failing partition (including any replicas).

  5.3.3.

  5.3.4.  Protocol and schema version controls

     The FIRS collection of specifications are explicitly bound to the
     LDAPv3 protocol, as defined by [RFC2251]. [RFC3377] and its subordinate
     specifications. If a new version of the LDAP protocol emerges, it
     is expected that some type of mechanism will be included for end-points end-
     points to use when negotiating over the version in use. Lacking
     such a mechanism, FIRS is explicitly restricted to LDAPv3.

     LDAP attributes, object classes, syntaxes and matching filters
     have OIDs which uniquely identify the format of the data they
     provide, and which act as simple schema-version identifiers in the
     generic case. [RFC2251] defines standardized mechanisms for
     retrieving and reading the OIDs associated with object classes and
     attributes (among other resource types). These mechanisms MAY be
     used whenever a FIRS client reads an entry, and MUST be used
     whenever a FIRS client modifies or creates an entry (even though
     FIRS does not define mechanisms for updating entries, it is
     assumed that some clients will allow this behavior).

  Hall                  I-D Expires: December 2003            [page 29] 
     Modifications to existing schema definitions MUST be accompanied
     by OID changes.

  5.4.    Post-Query    Referral Processing

     As was discussed in section 3.4, FIRS supports two types of
     referrals, which are subordinate reference referrals and
     continuation reference referrals. Both referral types use URLs for
     the purpose of providing referral targets, using the rules
     described in section 3.4 of this document.

     Non-compliance with the requirements provided in section 3.4
     amounts to an error, and is sufficient cause for a client to stop
     processing a query.

     As was discussed in section 3.4, subordinate reference referrals
     are defined in [RFC3296], and use the SearchResultDone response
     with a Referral result code as defined in [RFC2251]. Subordinate

  Hall                  I-D Expires: December 2003            [page 32]
     reference referrals use a subset of the labeledURI syntax as
     defined in [RFC2079], and use the syntax definitions from
     [RFC2255] when LDAP URLs in particular are provided, although
     section 3.4 of this document also defines additional restrictions
     on the allowable URL syntax. 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 partition has been redirected to another
     directory partition.

     Meanwhile, continuation reference referrals use the
     SearchResultReference response, which is defined and described in
     section 4.5.3 of [RFC2251]. Continuation reference referrals use a
     subset of the labeledURI syntax as defined in [RFC2079], and use
     the syntax definitions from [RFC2255] when LDAP URLs in particular
     are to be provided, although section 3.4 of this document also
     defines additional restrictions on the allowable URL syntax. 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 directory partition, and
     can occur with any of the search operations described in this
     document.

     The procedure for processing referral URLs is as follows:

  Hall                  I-D Expires: December 2003            [page 30] 
        a.  [RFC2251] 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 next step in
            the process.

        b.  Validate the protocol label. FIRS only supports the use of
            the LDAP service type. URLs with other protocol identifiers
            are to be treated as malformed.

        c.  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 port
            number discovered through any subsequent SRV lookups (as
            described below), or as a last resort use the default port
            number associated with the protocol identifier.

        d.  Determine the authoritative partition and search base
            specified in the referral URL.

            1.   If no distinguished name element was provided, reuse
                 the existing authoritative partition and search base.

            2.   Otherwise, use the distinguished name element for the process.

        b.  Validate
                 search base of the protocol label. FIRS only supports subsequent search operation.

            3.   Extract the use sequence of domainComponent distinguished
                 names from the LDAP service type. URLs with other protocol identifiers
            are to be treated search base, and use them as malformed.

        c.  Extract the
                 authoritative partition.

        e.  Determine the server address and port number provided with specified in
            the URL, referral URL.

            1.   If a host identifier was not provided, map the
                 domainComponent elements determined in step 5.4.d to a
                 DNS domain name and set it
            aside submit a DNS lookup for use with the subsequent connection attempt. SRV
                 resource records associated with that domain name. If no
            port number has been provided in
                 this step fails, report the URL, use error to the default user and exit
                 the query.

            2.   If the host identifier is an IP address, extract it
                 and skip to step 5.4.f.

  Hall                  I-D Expires: December 2003            [page 33] 31] 
            3.   If no port numbers number was provided in the URL, submit a
                 DNS lookup for the SRV resource records associated
                 with the protocol, domain name, as discovered described in section 5.2.4.
                 If this lookup succeeds, skip to step 5.4.b as 5.4.f.

            4.   If the SRV lookup from the previous step fails, or if
                 no port number was specified, submit a default DNS lookup for
                 the A resource records.

        f.  Determine the new assertion value and/or matching filter
            specified in the referral URL.

            1.   If the URL's path element does not contain a filter
                 element, reuse the current matching filter and
                 assertion value.

            2.   If the URL's path element contains a filter element,
                 use it to form the new matching filter and/or
                 assertion value.

        d.  Determine

        g.  Discard the authoritative partition and search base
            specified in remainder of the referral URL.

            1.   If no distinguished name element was provided, report

        h.  Use the failure discovered parameter values to start a new query.

     For example, imagine that a referral has been received with the user and exit.

            2.   Otherwise, use the distinguished name element
     URL value of "ldap:///cn=inetResources,dc=example,dc=com". The
     processing rules for this URL would be as follows:

        *   Use "cn=inetResources,dc=example,dc=com" as the new search
            base of for the subsequent search operation.

            3.   Extract query.

        *   Use the right-most domainComponent sequence of domainComponent
                 distinguished names from the search base, and use them "dc=example,dc=com" as
            the new authoritative partition.

        e.  Determine the server address and port number specified in
            the referral URL.

            1.   If the

        *   No host identifier is an IP address, extract it
                 and skip to step 5.4.f.

            2.   If no port number was provided specified in the URL, submit so the
            "dc=example,dc=com" partition must be used to seed a server
            identifier of "example.com".

        *   Issue DNS lookup lookups for the SRV resource records associated
            with "_ldap._tcp.example.com" to determine the domain name, as described in section 5.2.4.

            3.   If a server and
            port number was provided or if for the SRV lookup
                 fails, submit subsequent query.

        *   Reuse the existing assertion value and matching filter.

  Hall                  I-D Expires: December 2003            [page 32] 
     As another example, imagine a DNS lookup referral with the URL value of
     "ldap://example.com/cn=inetResources,dc=example,dc=com". The
     processing rules for this URL would be as follows:

        *   Use "cn=inetResources,dc=example,dc=com" as the A resource records.

            4.   If a host identifier was not provided, map new search
            base for the subsequent query.

        *   Use the domainComponent elements determined in step 5.4.d to a
                 DNS domain name and submit an SRV sequence of "dc=example,dc=com" as
            the new authoritative partition.

        *   Use the host identifier of "example.com" as specified in
            the URL.

        *   Issue DNS lookup lookups for the
                 LDAP servers SRV resource records associated
            with that domain name. If this
                 final step fails, report the error "_ldap._tcp.example.com" to determine the user server and
                 exit
            port number for the subsequent query.

        f.  Determine

        *   Reuse the new existing assertion value and/or and matching filter
            specified in the filter.

     As another example, imagine a referral URL.

            1.   If with the URL's path element does not contain a filter
                 element, reuse URL value of
     "ldap:////???(cn:dn:www.example.com). The processing rules for
     this URL would be as follows:

        *   Reuse the current matching filter existing search base and
                 assertion value.

            2.   If authoritative partition
            information.

        *   Reuse the URL's path element contains a filter element,
                 use it to form existing server and port number.

        *   Use "(cn:dn:www.example.com)" as the new matching filter and/or
            and assertion value.

  Hall                  I-D Expires: December 2003            [page 34] 
        g.  Discard

     Note that step 5.4.g requires the client to discard the remainder
     of the URL.

        h.  Use URL, although this step may be changed in subsequent
     versions of this specification. In particular, [CRISP-REQ]
     requires the discovered parameter values ability to start a new query. pass an inter-server "referral bag", and
     this mechanism may be implemented through the use of extensions in
     the LDAP URL.

  6.      Security Considerations

     Security considerations are discussed in [FIRS-ARCH].

  7.      IANA Considerations

     IANA considerations are discussed in [FIRS-ARCH].

  Hall                  I-D Expires: December 2003            [page 33] 
  8.      Author's Addresses

     Eric A. Hall
     ehall@ehsco.com

  9.      Normative References

          [RFC1274]     Barker, P., and Kille, S. "The COSINE and
                         Internet X.500 Schema", RFC 1274, November
                         1991.

          [RFC2079]     Smith, M. "Definition of an X.500 Attribute
                         Type and an Object Class to Hold Uniform
                         Resource Identifiers (URIs)", RFC 2079,
                         January 1997.

          [RFC2222]     Myers, J. "Simple Authentication and Security
                         Layer (SASL)", RFC 2222, October 1997.

          [RFC2247]     Kille, S., Wahl, M., Grimstad, A., Huber, R.,
                         and Sataluri, S. "Using Domains in LDAP/X.500
                         DNs", RFC 2247, January 1998.

          [RFC2251]     Wahl, M., Howes, T., and Kille, S.
                         "Lightweight Directory Access Protocol (v3)",
                         RFC 2251, December 1997.

          [RFC2252]     Wahl, M., Coulbeck, A., Howes, T., and Kille,
                         S. "Lightweight Directory Access Protocol
                         (v3): Attribute Syntax Definitions", RFC 2252,
                         December 1997.

          [RFC2253]     Wahl, M., Kille, S., and Howes, T.
                         "Lightweight Directory Access Protocol (v3):
                         UTF-8 String Representation of DNs", RFC 2253,
                         December 1997.

  Hall                  I-D Expires: December 2003            [page 35]

          [RFC2254]     Howes, T. "The String Representation of LDAP
                         Search Filters", RFC 2254, December 1997.

          [RFC2255]     Howes, T., and Smith, M. "The LDAP URL
                         Format", RFC 2255, December 1997.

          [RFC2256]     Wahl, M. "A Summary of the X.500(96) User
                         Schema for use with LDAPv3", RFC 2256,
                         December 1997.

          [RFC2277]     Alvestrand, H. "IETF Policy on Character Sets
                         and Languages", BCP 18, RFC 2277, January
                         1998.

  Hall                  I-D Expires: December 2003            [page 34] 
          [RFC2308]     Andrews, M. "Negative Caching of DNS Queries
                         (DNS NCACHE)", RFC 2308, March 1998.

          [RFC2596]     Wahl, M., and Howes, T. "Use of Language Codes
                         in LDAP", RFC 2596, May 1999.

          [RFC2782]     Gulbrandsen, A., Vixie, P., and Esibov, L. "A
                         DNS RR for specifying the location of services
                         (DNS SRV)", RFC 2782, February 2000.

          [RFC2798]     Smith, M. "Definition of the inetOrgPerson
                         LDAP Object Class", RFC 2798, April 2000.

          [RFC3296]     Zeilenga, K. "Named Subordinate References in
                         Lightweight Directory Access Protocol (LDAP)
                         Directories", RFC 3296, July 2002.

          [RFC3377]     Hodges, J., and Morgan, R. "Lightweight
                         Directory Access Protocol (v3): Technical
                         Specification", RFC 3377, September 2002.

          [RFC3490]     Faltstrom, P., Hoffman, P., and Costello, A.
                         "Internationalizing Domain Names in
                         Applications (IDNA)", RFC 3490, March 2003.

          [FIRS-ARCH]   Hall, E. "The Federated Internet Registry
                         Service: Architecture and Implementation
                         Guide", draft-ietf-crisp-firs-arch-00, draft-ietf-crisp-firs-arch-01, May
                         2003.

          [FIRS-ASN]    Hall, E. "Defining and Locating Autonomous
                         System Numbers in the Federated Internet
                         Registry Service", draft-ietf-crisp-firs-asn-
                         00,
                         01, May 2003.

  Hall                  I-D Expires: December 2003            [page 36]

          [FIRS-CONTCT] Hall, E. "Defining and Locating Contact
                         Persons in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-contact-00, draft-ietf-crisp-firs-contact-01,
                         May 2003.

          [FIRS-CORE]   Hall, E. "The Federated Internet Registry
                         Service: Core Elements", draft-ietf-crisp-
                         firs-core-00,
                         firs-core-01, May 2003.

          [FIRS-DNS]    Hall, E. "Defining and Locating DNS Domains in
                         the Federated Internet Registry Service",
                         draft-ietf-crisp-firs-dns-00,
                         draft-ietf-crisp-firs-dns-01, May 2003.

          [FIRS-DNSRR]  Hall, E. "Defining and Locating DNS Resource
                         Records in the Federated Internet Registry

  Hall                  I-D Expires: December 2003            [page 35] 
                         Service", draft-ietf-crisp-firs-dnsrr-00, draft-ietf-crisp-firs-dnsrr-01, May
                         2003.

          [FIRS-IPV4]   Hall, E. "Defining and Locating IPv4 Address
                         Blocks in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-ipv4-00, draft-ietf-crisp-firs-ipv4-01, May
                         2003.

          [FIRS-IPV6]   Hall, E. "Defining and Locating IPv6 Address
                         Blocks in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-ipv6-00, draft-ietf-crisp-firs-ipv6-01, May
                         2003.

          [US-ASCII]    Cerf, V. "ASCII format for Network
                         Interchange", RFC 20, October 1969.

  10.     Acknowledgments

     Funding for the RFC editor function is currently provided by the
     Internet Society.

     Portions of this document were funded by Verisign Labs.

     The first version of this specification was co-authored by Andrew
     Newton of Verisign Labs, and subsequent versions continue to be
     developed with his active participation.

  11.     Changes from Previous Versions
     draft-ietf-crisp-fir-core-00:

     draft-ietf-crisp-firs-core-01:

        *   Several clarifications and corrections have been made.

        *   Significant portions of text were moved to [FIRS-ARCH].

     draft-ietf-crisp-firs-core-00:

        *   Restructured document set, separating the architectural
            discussion from the technical descriptions. Several

  Hall                  I-D Expires: December 2003            [page 37]
            sections were relocated to [FIRS-ARCH] as a result of this
            change.

        *   "Attribute references" have been eliminated from the
            specification. All referential attributes now provide
            actual data instead of URL pointers to data. Clients that
            wish to retrieve these values will need to start new
            queries using the data values instead of URLs.

  Hall                  I-D Expires: December 2003            [page 36] 
        *   The various modified* operational attributes in the core
            schema have been eliminated as unnecessary.

        *   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.

     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ö “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.

  Hall                  I-D Expires: December 2003            [page 38]

        *   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
            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.

  Hall                  I-D Expires: December 2003            [page 37] 
        *   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.

  12.     Full Copyright Statement

     Copyright (C) The Internet Society (2003). All Rights Reserved.

     This document and translations of it may be copied and furnished
     to others, and derivative works that comment on or otherwise
     explain it or assist in its implementation may be prepared,
     copied, published and distributed, in whole or in part, without
     restriction of any kind, provided that the above copyright notice
     and this paragraph are included on all such copies and derivative
     works. However, this document itself may not be modified in any
     way, such as by removing the copyright notice or references to the
     Internet Society or other Internet organizations, except as needed
     for the purpose of developing Internet standards in which case the
     procedures for copyrights defined in the Internet Standards

  Hall                  I-D Expires: December 2003            [page 39]
     process must be followed, or as required to translate it into
     languages other than English.

     The limited permissions granted above are perpetual and will not
     be revoked by the Internet Society or its successors or assigns.

     This document and the information contained herein is provided on
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

  Hall                  I-D Expires: December 2003            [page 40] 38]