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

Versions: 00 01 02 03

  INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-ietf-crisp-firs-arch-00.txt                    May 2003
  Expires: December, 2003
  Category: Standards-Track
  
  
                  The Federated Internet Registry Service:
                    Architecture and Implementation Guide
  
  
     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 architectural framework for the
     Federated Internet Registry Service (FIRS), a distributed service
     for storing, locating and transferring information about Internet
     resources using LDAPv3.
  
  
  
  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
     Table of Contents
  
     1.   Introduction..............................................2
       1.1.  Background.............................................3
       1.2.  Overview...............................................4
     2.   Prerequisites and Terminology.............................5
       2.1.  Reference Example......................................6
     3.   The FIRS Namespace........................................8
       3.1.  The domainComponent Hierarchy..........................8
       3.2.  The inetResources Container............................9
       3.3.  Resource-Specific Entries..............................9
       3.4.  Namespace Aliases.....................................10
     4.   FIRS Schema Definitions..................................11
       4.1.  Global Schema Definitions.............................11
       4.2.  Resource-Specific Schema Definitions..................12
     5.   Query Processing Behaviors...............................13
       5.1.  Query Pre-Processing..................................13
       5.2.  Bootstrap Processing..................................15
       5.3.  Query Processing......................................16
       5.4.  Query Post-Processing.................................16
           5.4.1.  Referrals.......................................17
           5.4.2.  Internationalization and localization...........18
     6.   Transition Issues........................................19
       6.1.  NIC Handles...........................................20
       6.2.  Change-Logs...........................................20
     7.   Security Considerations..................................20
     8.   IANA Considerations......................................23
     9.   Author's Address.........................................23
     10.  Normative References.....................................23
     11.  Informational References.................................26
     12.  Acknowledgments..........................................26
     13.  Changes from Previous Versions...........................26
     14.  Full Copyright Statement.................................28
  
  1.      Introduction
     FIRS is intended to provide a distributed WHOIS-like information
     service, using the LDAPv3 specifications [RFC3377] for the data-
     formatting and query-transport functions.
  
     More specifically, the principle objective behind FIRS is to offer
     structured information about distributed Internet resources in a
     model which reflects the federated delegations of those resources.
     This specifically includes centralized delegations from authorized
     governance bodies (such as DNS domains within the "com" zone), but
  
  Hall                  I-D Expires: December 2003             [page 2]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     also includes delegations from authorized bodies further down the
     delegation path (such as leaf-node DNS domain names within the
     "example.com" zone).
  
     Furthermore, the FIRS service is intended to be used with a wide
     variety of resources. The core set of specifications define rules
     for handling the most-common resources (DNS domains, IP addresses,
     contact information, and so forth), but other types of resources
     may be grafted onto the architecture as needed. By extension, FIRS
     should be capable of providing the necessary support structure for
     any kind of information to be stored in a global mesh of FIRS-
     centric LDAP directories, and for the FIRS-specific clients and
     servers to be easily extended to accommodate that data.
  
     Another critical objective can be described as predictability, in
     that FIRS-specific data should be easily accessible to a wide
     number of applications. For example, if a network manager wants to
     retrieve information about a particular host or network, it should
     be easy for the management application to be extended so that the
     FIRS data can be fetched by that application, rather than always
     requiring the use of a FIRS-specific application.
  
     Finally, the collection of specifications which define the
     Federated Internet Registry Service (FIRS) are intended to satisfy
     the CRISP Working Group requirements, as specified in draft-ietf-
     crisp-requirements-05, "Cross Registry Internet Service Protocol
     (CRISP) Requirements" [CRISP-REQ].
  
     In order to achieve these objectives, the FIRS specifications
     collectively define an LDAP-specific application, including
     application-specific namespaces, object classes, attributes,
     syntaxes, queries, behavioral rules, and more.
  
  1.1.    Background
     The original WHOIS service [RFC812] was provided as a front-end to
     a centralized repository of ARPANET resources and users. Over
     time, hundreds of WHOIS servers have been deployed across the
     public Internet, with each server providing general information
     about the particular network resources under the control of a
     specific organization.
  
     Unfortunately, neither [RFC812] nor any of its successors define a
     strict set of data-typing or formatting requirements, and as a
     result, each of the different implementations provide different
     kinds of information in slightly different ways. Furthermore, each
  
  Hall                  I-D Expires: December 2003             [page 3]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     WHOIS server operates as a self-contained entity, with no
     standardized mechanisms to infer knowledge of any other servers,
     meaning that WHOIS servers cannot redirect clients to other
     servers for additional information. Another concern is that the
     WHOIS services which are being operated today offer no means of
     client authentication, requiring that server operators essentially
     publish all data with a single "world-readable" permission.
     However, this single permission conflicts with the privacy and
     security policies of specific jurisdictions.
  
     There are many other secondary issues with the WHOIS service as it
     exists in current form. However, the largest problems are a lack
     of standardized data formats, a lack of widely-supported referral
     mechanisms, and a lack of privacy and security controls, as
     described in the preceding text.
  
     FIRS attempts to address these issues by defining guidelines for
     the operation of a distributed and highly-structured WHOIS-like
     service, using LDAPv3 for the query/response transfer service, and
     using LDAP schema for the search inputs, answer data, and
     redirection mechanisms. In short, the intention of this approach
     is to provide an extensible and scalable WHOIS-like service, by
     leveraging the inherent capabilities of LDAPv3.
  
  1.2.    Overview
     The FIRS collection of specifications cumulatively define a
     structured and distributed information service, including an
     extensible framework and resource-specific definitions. The
     framework defined in this document is intended to accommodate a
     variety of different resource-types and usages, while the other
     specifications define the technical details for the service as a
     whole or for the different resource-types.
  
     Cumulatively, the FIRS collection of specifications define the
     following service elements:
  
        *   Namespace Rules. The FIRS specifications define a layered
            namespace consisting of DNS-based delegation hierarchies, a
            FIRS-specific container entry, and resource-specific
            subordinate entries.
  
        *   Schema Definitions. The FIRS specifications reuse some
            existing LDAP schema definitions, and also define several
            FIRS-specific definitions, as needed.
  
  
  Hall                  I-D Expires: December 2003             [page 4]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
        *   The FIRS specifications also reuse some existing processing
            rules, and define several additional rules as needed. Among
            these rules are requirements for normalizing data, locating
            servers, processing referrals, and more.
  
     Some of these rules apply to the architecture as a whole, while
     other rules apply to specific kinds of Internet resources.
  
  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, "The Federated Internet
            Registry Service: Architecture and Implementation" (this
            document) [FIRS-ARCH]
  
            draft-ietf-crisp-firs-core-00, "The Federated Internet
            Registry Service: Core Elements" [FIRS-CORE]
  
            draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS
            Domains in the Federated Internet Registry Service"
            [FIRS-DNS]
  
            draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS
            Resource Records in the Federated Internet Registry
            Service" [FIRS-DNSRR]
  
            draft-ietf-crisp-firs-contact-00, "Defining and Locating
            Contact Persons in the Federated Internet Registry Service"
            [FIRS-CONTCT]
  
            draft-ietf-crisp-firs-asn-00, "Defining and Locating
            Autonomous System Numbers in the Federated Internet
            Registry Service" [FIRS-ASN]
  
            draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4
            Address Blocks in the Federated Internet Registry Service"
            [FIRS-IPV4]
  
            draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6
            Address Blocks in the Federated Internet Registry Service"
            [FIRS-IPV6]
  
  Hall                  I-D Expires: December 2003             [page 5]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
     The FIRS service reuses, unites and clarifies several pre-existing
     technologies. In order to fully understand FIRS, readers should be
     familiar with the following technologies and specifications:
  
            RFC 2247, "Using Domains in LDAP/X.500 DNs" [RFC2247]
  
            RFC 2251, "Lightweight Directory Access Protocol (v3)"
            [RFC2251]
  
            RFC 2252, "Lightweight Directory Access Protocol (v3):
            Attribute Syntax Definitions" [RFC2252]
  
            RFC 2254, "The String Representation of LDAP Search
            Filters" [RFC2254]
  
            RFC 2256, "A Summary of the X.500(96) User Schema for use
            with LDAPv3" [RFC2256]
  
            RFC 2798, "Definition of the inetOrgPerson LDAP Object
            Class" [RFC2798]
  
            RFC 3296, "Named Subordinate References in Lightweight
            Directory Access Protocol (LDAP) Directories" [RFC3296]
  
            RFC 3377, "Lightweight Directory Access Protocol (v3):
            Technical Specification" [RFC3377]
  
     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.
  
  2.1.    Reference Example
     Figure 1 below shows an example of a FIRS-specific data-set. This
     example is referenced throughout this specification.
  
  
  Hall                  I-D Expires: December 2003             [page 6]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
          dc=example,dc=com
          |
          +-cn=inetResources,dc=example,dc=com
            [top object class]
            [inetResources object class]
            |
            +-attribute: inetGeneralContacts
            | value: "admins@example.com"
            |
            +-cn=admins@example.com,cn=inetResources,dc=example,dc=com
            | [top object class]
            | [inetResources object class]
            | [inetOrgPerson object class]
            | |
            | +-attribute: mail
            |   value: "admins@example.com"
            |
            +-cn=example.com,cn=inetResources,dc=example,dc=com
            | [top object class]
            | [inetResources object class]
            | [inetDnsDomain object class]
            | |
            | +-attribute: inetDnsAuthServers
            |   value: "ns1.example.net"
            |
            +-cn=www.example.com,cn=inetResources,dc=example,dc=com
              [top object class]
              [inetResources object class]
              [inetDnsDomain object class]
              [referral object class]
              |
              +-attribute: inetTechContacts
              | value: "admins@example.com"
              |
              +-attribute: ref
                value: "ldap://firs.example.net/cn=inetResources,
                          dc=example,dc=net"???
                          (1.3.6.1.4.1.7161.1.1.8:=host.example.net)"
  
     Figure 1: The FIRS-specific data for Example Widgets.
  
     As can be seen in Figure 1, the entries use a FIRS-specific
     namespace in conjunction with FIRS-specific schema, which clients
     can use to generate FIRS-specific queries.
  
  
  Hall                  I-D Expires: December 2003             [page 7]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  3.      The FIRS Namespace
     A critical aspect of FIRS is the use of an application-specific
     namespace which is imposed on all FIRS-based resources.
  
     The FIRS namespace rules facilitate the programmatic creation of
     lookups and searches, and ensure predictable results. The use of a
     private namespace also help to segregate FIRS-related data from
     other kinds of data which may reside on any participating server.
  
     The FIRS namespace consists of three "layers", which are:
  
        *   A set of domainComponent relative distinguished names which
            cumulatively identify a specific partition of the global
            directory tree.
  
        *   A FIRS-specific entry which acts as a container for all of
            the FIRS-related resource-specific child entries.
  
        *   The resource-specific child entries which collectively
            contain detailed information about the resources under the
            control of the selected partition.
  
     The namespace follows a right-to-left order.
  
     As an example, Figure 1 shows an DNS domain resource entry named
     "cn=example.com,cn=inetResources,dc=example,dc=com", which refers
     to the "example.com" domain resource within the "cn=inetResources"
     container under the "dc=example,dc=com" directory partition.
  
  3.1.    The domainComponent Hierarchy
     The top-level of the namespace uses the domainComponent naming and
     mapping rules specified in RFC 2247 [RFC2247], which maps DNS
     domain names to domainComponent ("dc=") relative distinguished
     names (RDNs). The full sequence of domainComponent RDNs map to an
     equivalent scope of authority in the DNS namespace, and
     cumulatively represent the root of a partition of the global LDAP
     directory space. For example, Figure 1 shows the directory
     partition of "dc=example,dc=com" which maps to the "example.com"
     scope of authority from the DNS hierarchy.
  
  
  Hall                  I-D Expires: December 2003             [page 8]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  3.2.    The inetResources Container
     This specification requires the use of a mandatory LDAP container
     entry with the RDN of "cn=inetResources", which MUST exist at the
     root of every directory database that provides FIRS services. All
     publically-accessible resource-specific entries MUST be stored in
     the cn=inetResources container entry.
  
     The primary motivation for this naming rule is for predictability,
     in that it allows searches to be formed programmatically (a search
     base for resources in "dc=example,dc=com" can be programmatically
     formed as "cn=inetResources,dc=example,dc=com", for example).
     Furthermore, the use of a single container entry for all of an
     organization's Internet resources allows that branch of the
     directory database to be managed independently of other entries on
     the server, which facilitates better operational security, and
     also allows for the outsourcing of a FIRS container through the
     use a single referral.
  
     All told, the use of the inetResources container is important
     enough to justify the MANDATORY usage of this naming syntax.
  
  3.3.    Resource-Specific Entries
     The FIRS collection of specifications define several Internet
     resource types, each of which have their own naming rules.
     However, each resource type follows a consistent naming principle,
     in that each specific resource has an RDN which uniquely
     identifies that resource within the inetResources container entry.
  
     For example, Figure 1 shows an entry for the "www.example.com"
     domain name resource stored in the "dc=example,dc=com" directory
     context, with a fully-qualified distinguished name (FQDN) of
     "cn=www.example.com,cn=inetResources,dc=example,dc=com", and also
     shows an entry for the "admins@example.com" contact resource with
     the FQDN "admins@example.com,cn=inetResources,dc=example,dc=com".
     Although the relative naming syntax is different for each resource
     type, the syntax is consistent and predictable.
  
     The naming rules for each of the distinct resource type are
     provided in the documents which govern those resource types.
  
  
  Hall                  I-D Expires: December 2003             [page 9]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  3.4.    Namespace Aliases
     FIRS allows entries to alias for other entries through the use of
     referrals. In this model, an entry exists which will match against
     searches for the queried data, but the attributes associated with
     that entry indicate that some other entry should also be queried.
  
     Referrals represent one of the strongest capabilities of the FIRS
     architecture, in that they allow for a significant variety of
     cross-referencing among entries. For example, referrals can be
     used to point an inetResources container entry in one partition to
     another inetResources container entry in another partition,
     allowing multiple partitions to effectively share a single
     partition (this is useful when organizations manage multiple
     networks or domains, and wish to consolidate their management). As
     another example, referrals can also be used to create placeholder
     entries for specific resources (such as a web server) which only
     exist as referrals for resources which are managed in other
     partitions (such as a web-hosting server at an ISP), with both
     entries providing information about that resource.
  
     This latter example can be seen in Figure 1, which shows an entry
     for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which
     provides a referral to the "cn=host.example.net" entry at
     "cn=inetResources,dc=example,dc=net". Queries for the local entry
     would be answered with the locally-available information and then
     redirected to the referral target where additional information
     could be retrieved.
  
     FIRS supports two different kinds of referrals, which are
     subordinate reference referrals and continuation reference
     referrals. Subordinate reference referrals indicate that the
     search base used in the query only exists as an alias to another
     partition or entry, meaning that the entire query must be
     restarted in order for any answer data to be retrieved. Meanwhile,
     continuation reference referrals indicate that some answer data is
     available, but that more information is available at some other
     location, and that the client should start new queries in order to
     retrieve all of the information.
  
     Referrals are provided as URLs. FIRS specifically requires the use
     of LDAP URLs in order to ensure predictable automated processing.
     Refer to section 5.4.1 for a brief discussion on how these URLs
     are processed by FIRS clients.
  
  
  Hall                  I-D Expires: December 2003            [page 10]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  4.      FIRS Schema Definitions
     Another critical aspect of FIRS is the use of well-known schema,
     including object classes, attributes, syntaxes and matching
     filters. Some of the schema definitions are for the global FIRS
     service (and are usable by all entries, including resource-
     specific entries), while others are specific to particular
     resource-types. Where suitable pre-existing schema definitions are
     available, they are reused to facilitate integration with other
     LDAP applications.
  
  4.1.    Global Schema Definitions
     There are three global schema definitions which can be used by any
     of the entries within the FIRS database. These include:
  
        *   The "inetResources" master schema. All FIRS-related entries
            (including the inetResources container entry and all of the
            resource-specific subordinate entries) MUST use the
            inetResources structural object class and schema
            definitions defined in [FIRS-CORE]. The inetResources
            object class defines a variety of optional general-purpose
            attributes which are useful for describing an organization
            or the resources under its control.
  
        *   Associated resources. All FIRS-related entries MAY use the
            "inetAssociatedResources" auxiliary object class and schema
            definitions defined in [FIRS-CORE]. This object class
            provides cross-reference pointer attributes which allow an
            entry to reference other entries which may be of interest
            to the user.
  
        *   Referral pointers. All FIRS-related entries MAY use the
            "referral" object class and schema definitions defined in
            [RFC3296]. This object class allows an entry to exist as a
            referral source, with queries for that resource being
            redirected to the referral target. Refer to section 5.4.1
            for a discussion on the different kinds of referral and
            reference mechanisms offered by FIRS.
  
     Figure 1 shows that all of the entries within and including the
     "cn=inetResources" container entry have the inetResources object
     class defined, and that the "cn=www.example.com" resource-specific
     entry also has the referral object class defined. Each of the
     resource-specific entries in that example also have their own
     resource-specific object classes.
  
  Hall                  I-D Expires: December 2003            [page 11]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
  4.2.    Resource-Specific Schema Definitions
     In addition to the global schema definitions, each of the
     resource-specific entry in FIRS MUST use the resource-specific
     schema definitions defined for use with that specific resource
     type. These object classes are defined in the specifications which
     govern the different resource-types. These include:
  
        *   DNS domains. Every domain name resource entry MUST use the
            inetDnsDomain object class and schema definitions defined
            in [FIRS-DNS]. These entries can refer to sub-domain
            delegations, host-specific entries, reverse-lookup entries,
            or any other domain name resource, as needed.
  
        *   DNS resource-records. Any domain name resource MAY use the
            inetDnsRR object class and schema definitions defined in
            [FIRS-DNSRR]. The inetDnsRR object class defines a single
            optional attribute for storing multiple DNS resource
            records as supplemental data to a domain name entry.
  
        *   IPv4 address blocks. Every IPv4 network block entry MUST
            use the inetIpv4Network object class and schema definitions
            defined in [FIRS-IPV4]. Entries can refer to entire network
            blocks or single hosts, as needed.
  
        *   IPv6 address blocks. Every IPv6 network block entry MUST
            use the inetIpv6Network object class and schema definitions
            defined in [FIRS-IPV6]. Entries can refer to entire network
            blocks or single hosts, as needed.
  
        *   Autonomous system numbers. Every autonomous system number
            entry MUST use the inetAsNumber object class and schema
            definitions defined in [FIRS-ASN].
  
        *   Contacts. Every contact entry MUST use the inetOrgPerson
            object class defined in [RFC2798], as well as the schema
            definitions defined in [FIRS-CONTCT].
  
     As was discussed in section 4.1, each resource-specific entry MAY
     exist as a referral source, or MAY have attributes which refer to
     additional (related) entries.
  
  
  Hall                  I-D Expires: December 2003            [page 12]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  5.      Query Processing Behaviors
     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
            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. [FIRS-CORE]
            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.
  
        *   Query processing. Once a server has been located, the
            client must submit the LDAP query which was formed during
            the pre-preprocessing phase. [FIRS-CORE] defines certain
            LDAPv3 query parameters which all FIRS clients MUST conform
            with, while the resource-specific specifications may also
            define additional parameters.
  
        *   Query post-processing. FIRS explicitly supports several
            different types of LDAP referral and redirection
            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 [FIRS-CORE].
  
     Each of these phases are discussed in more detail below.
  
  5.1.    Query Pre-Processing
     Client input is generally provided as a single well-formed unit of
     data, such as a domain name ("example.com") or an email address
     ("admins@example.com"). Since this information is typically all
  
  Hall                  I-D Expires: December 2003            [page 13]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     that's provided, it must be used to subsequently build a 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 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
            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 normalized into a
            UTF-8 form before any other steps can be taken, with the
            domain name being validated as part of the normalization
            process. 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 syntax
            requirements.
  
        *   Determine the appropriate directory partition for the
            query. Different kinds of resources have different default
            choices. In most cases, the appropriate 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 the domain component of the email address
            itself, while the default partition for an ASN is a
            reserved (special-purpose) domain name. In some cases, the
            selected partition may change as a result of errors or
            referrals encountered during later phases of the process.
  
        *   Determine the search base for the query. In most cases, the
            search base will refer to the inetResources container entry
            within the partition which was determined in the prior
            step, with these elements being combined into an FQDN. In
            some cases, the search base may need to be changed as a
            result of referrals encountered during later phases of the
            process.
  
  
  Hall                  I-D Expires: December 2003            [page 14]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
        *   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 during later
            phases of the process.
  
        *   Determine the matching filter. Each resource-type has its
            own matching filter rules. In some cases, the matching
            filter will be a simple equalityMatch comparison, while in
            other cases the matching filter will be an extensibleMatch
            which is peculiar to the resource-type in use.
  
     Once all of the pre-processing steps have been successfully
     completed, the client must attempt to locate an LDAPv3 server
     which is authoritative for that resource. This process is
     described in section 5.2 below.
  
  5.2.    Bootstrap Processing
     The bootstrap process uses DNS queries for SRV resource records
     associated with the selected directory partition. However, since
     different kinds of resources are managed through different
     delegation models, there are also different bootstrap models which
     have to be used to perform this process.
  
     FIRS supports three different bootstrap models, which are:
  
        *   Targeted. The "targeted" bootstrap model has the client
            attempting to locate the LDAP servers associated with a
            absolute domain name, such as a domain name which may be
            returned as referrals or URLs. If no servers can be found,
            the client exits the query.
  
        *   Top-down. The "top-down" bootstrap model has the client
            attempting to locate the LDAP servers associated with a
            top-level domain (such as trying to locate the LDAP servers
            associated with the "com" domain for an original query of
            "www.example.com"). If no servers can be found for the top-
            level domain, the client exits the query.
  
        *   Bottom-up. The "bottom-up" bootstrap model has the client
            attempting to locate the LDAP servers associated with the
            leaf-node domain (such as trying to locate any LDAP servers
            associated with the "www.example.com" domain specifically).
            If no servers can be found for that domain name, the
            directory partition is reset to its immediate parent and
  
  Hall                  I-D Expires: December 2003            [page 15]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
            the DNS query is resubmitted with that new scope. This
            process continues until no more domains can be trimmed.
  
     Each of the models are appropriate to different usages. For
     example, The targeted model is most useful with pointer data
     gleaned through URLs and other fixed sources, where the data is
     presumed to exist at a pre-determined location. Meanwhile, the
     top-down model is best suited for searches about global resources
     which are centrally managed and delegated (such as IP addresses
     and DNS domains), and where centrally-managed delegation
     information is critical. Finally, the bottom-up model is most
     appropriate for those resources which are managed by the end-users
     directly (such as contact information, DNS resource records, and
     so forth), and which are not typically managed from a centralized
     delegation authority.
  
     Once the bootstrap process has resulted in an authoritative LDAP
     server being located for the partition in question, the remainder
     of the query process is consistent.
  
  5.3.    Query Processing
     Once an LDAP server has been located, the LDAPv3 query is
     submitted to that server.
  
     Most of the values for the query will have been collected during
     the pre-processing phase, although [FIRS-CORE] defines some rules
     which govern all queries. For example, [FIRS-CORE] specifies a
     maximum time limit of 60 seconds for all queries in order to
     prevent runaway searches which match all entries.
  
     [FIRS-CORE] also allows for authentication and access controls, in
     that FIRS servers are allowed to limit the depth and breadth of
     information that they provide to a specific client based on the
     level of authenticated access.
  
     Another consideration which can arise during this phase of the
     process is protocol and schema versioning considerations. These
     mechanisms are already existent in the LDAPv3 specifications, and
     their usage is encouraged by [FIRS-CORE].
  
  5.4.    Query Post-Processing
     Once a query has been submitted and processed, the server should
     return answer data or some kind of referral, or possibly both. In
  
  Hall                  I-D Expires: December 2003            [page 16]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     general, FIRS clients are expected to display all of the answer
     data and process all of the referrals, although there are specific
     considerations which must be taken into account. In particular,
     there are considerations for handling the different kinds of
     referrals, and there are localizations issues for specific kinds
     of attribute data.
  
  5.4.1.  Referrals
     As was discussed in section 3.4, there are two kinds of referral
     mechanisms which are used with FIRS, which are subordinate
     reference referrals and continuation reference referrals. More
     specifically:
  
        *   Subordinate reference referrals. Subordinate reference
            referrals are returned when the search base specified in a
            query exists as a referral to some other entry. This
            condition means that the current search operation cannot
            proceed, and that the search MUST be restarted. Any of the
            FIRS-specific entries MAY be defined as subordinate
            reference referrals, although they are typically only used
            when the inetResources container entry in a partition is an
            alias for an inetResources container entry in another
            partition. Subordinate reference referrals and their schema
            are defined in RFC 3296 [RFC3296] although there are
            additional restrictions placed on their usage as described
            in [FIRS-CORE].
  
        *   Continuation reference referrals. Continuation reference
            referrals are returned when a search operation has been
            successfully processed by the queried server, but the
            answer data also includes referrals to other entries. These
            referrals are often provided as supplemental data to an
            answer set, although this is not required (a continuation
            reference referral can be the only response, but it won't
            be the only response in the common case). 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. Continuation
            reference referrals and their schema are also defined in
            [RFC3296], with additional restrictions placed on their
            usage as described in [FIRS-CORE].
  
     Whenever a referral is received in response to a query, the client
     MUST display any answer data which has been received and then
     process the referral. As part of this process, the client MUST
  
  Hall                  I-D Expires: December 2003            [page 17]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     parse the URL for the host identifier, port number, search base,
     and assertion value (if these are provided), and then construct
     and issue new queries using these values.
  
     Note that RFC 2251 [RFC2251] defines a superior reference referral
     which is used as a "default referral" for out-of-scope searches.
     However, FIRS specifically excludes support for superior reference
     referrals. Any superior reference referrals which are encountered
     as part of this service are to be treated as errors.
  
  5.4.2.  Internationalization and localization
     The FIRS model uses the internationalization and localization
     services provided by LDAPv3. In this regard, FIRS clients do not
     need to implement any special services in order to process and
     display internationalized attribute data if those attribute types
     already provide direct support for internationalized data.
     However, there are several instances where this is not the case.
  
     The areas where specific considerations have been made to fully
     accommodate internationalization and localization concerns are
     described below.
  
        *   The domainComponent attribute is restricted to [US-ASCII].
            This is problematic with internationalized domain names and
            their use in directory information trees, search bases, and
            so forth. In order to ensure interoperability, this
            specification requires all DNS domain names which are
            mapped to domainComponent attributes to be normalized and
            reduced to their ASCII-compatible form using the "ToASCII"
            process defined in [RFC3490] before these sequences are
            stored in the directory or used in LDAPv3 messages.
  
        *   DNS is technically capable of storing eight-bit codepoint
            values, although the operational rules which govern DNS do
            not support this usage. As a result, internationalized
            domain names which are used for SRV or A resource record
            lookups MUST be normalized and reduced to their ASCII-
            compatible form using the "ToASCII" process defined in
            [RFC3490] before these queries are issued.
  
        *   Some URLs may need to be escaped in order to accommodate
            internationalized strings (the rules and requirements for
            this process are defined in the specifications which govern
            each kind of URL).
  
  
  Hall                  I-D Expires: December 2003            [page 18]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
        *   RFC 2277 [RFC2277] requires that free-text data must be
            accompanied with language tags. RFC 2596 [RFC2596] defines
            a mechanism for storing language tags and language-specific
            attribute values, and these mechanisms SHOULD be supported
            by FIRS clients and servers. For example, an organization
            name could be provided in English and Arabic, with the
            language tags allowing the client application to view the
            appropriate attribute value instance, if both the client
            and the server support the mechanisms defined in RFC 2596.
            Note that attribute values which contain structured data
            (even if there is no structure in LDAP) do not necessarily
            benefit from language tags. Examples of the latter include
            the labeledURI and mail attributes, which do not typically
            have multiple linguistic representations.
  
        *   Time and date strings usually use the generalizedTime
            syntax, making them predictable. Dates MAY be localized for
            display purposes by client applications as necessary.
  
        *   Attribute names are static and well-known, and are
            therefore easily localized. As such, clients MAY choose to
            convert attribute names in a language appropriate to the
            local user for display purposes where it is safe to do so.
            However, clients MUST NOT localize attribute names which
            are used for query input. Specific examples of the latter
            would be converting "cn=" or "dc=" relative distinguished
            labels into some other language.
  
        *   International postal regulations generally require that the
            recipient address be provided in a language and charset
            which is native to the recipient's country, with the
            exception of the destination country code which should be
            provided in a language and charset that is native to the
            sender's country (this allows the sender's post office to
            route the mail to the recipient's country, while allowing
            the destination country to perform local delivery). In
            order to facilitate this usage, the country attribute value
            MAY (encouraged) be localized to the local user's
            nomenclature for a country, but other postal address
            information SHOULD NOT be localized.
  
  6.      Transition Issues
     There are a handful of areas where the proposed service does not
     fully match with all of the existing WHOIS service offerings.
     These areas are discussed in more detail below.
  
  Hall                  I-D Expires: December 2003            [page 19]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
  6.1.    NIC Handles
     Legacy NIC handles in existing databases can be accommodated using
     two possible mechanisms:
  
        *   NIC handle output in legacy WHOIS systems may be replaced
            with email addresses for the contacts. This option
            facilitates faster coalescence around the FIRS system.
  
        *   NIC handles can be converted into locally-scoped email
            addresses. For example, the NIC handle of EH26 on Network
            Solutions' WHOIS server could be replaced with the locally-
            scoped email address of "ehall@whois.netsol.com" or some
            variation thereof.
  
     Of the two mechanisms described above, the former is preferred.
  
  6.2.    Change-Logs
     Several WHOIS services provide pseudo change-logs in their
     response data, listing each unique modification event which has
     occurred for a particular resource. For example, RIPE and some of
     its member ccTLDs provide WHOIS output which includes a series of
     "changed" fields that itemize every modification event ("updated",
     "added", etc.), the modifier, and the modification date, which
     cumulatively act as a change-log for the resource in question.
  
     Organizations are certainly free to maintain this information on
     their internal systems (and are even encouraged to do so).
     However, this information is not necessary for public view of the
     data in the FIRS service. Where the auditing information will be
     required, a format which is more suitable to legal review will
     also be required.
  
     Organizations who wish to publish change-log information should
     develop a common schema for this purpose. An initial demonstration
     schema has been developed by the author and is available at
     http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt
  
  7.      Security Considerations
     The FIRS collection of specifications describe an application of
     the LDAPv3 protocol, and as such it inherits the security
  
  Hall                  I-D Expires: December 2003            [page 20]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
     considerations associated with LDAPv3, as described in section 7
     of [RFC2251].
  
     By nature, LDAP is a read-write protocol, while the legacy WHOIS
     service has always been a read-only service. As such, there are
     significant risks associated with allowing unintended updates by
     unauthorized third-parties. Moreover, allowing the FIRS service to
     update the underlying delegation databases could result in network
     resources being stolen from their lawful operators. For example,
     if the LDAP front-end had update access to a domain delegation
     database, a malicious third-party could theoretically take
     ownership of that domain by exploiting an authentication weakness,
     thereby causing ownership of the domain to be changed to another
     party. For this reason, it is imperative that the FIRS service not
     be allowed to make critical modifications to delegated resources
     without ensuring that all possible precautions have been taken.
  
     The query processing models described in this document make use of
     DNS lookups in order to locate the LDAP servers associated with a
     particular resource. DNS is susceptible to certain attacks and
     forgeries which may be used to redirect clients to LDAP servers
     which are not authoritative for the resource in question.
  
     This document provides multiple query models which will cause the
     same query to be answered by different servers (one would be
     processed by a delegation entity, while another would be processed
     by an operational entity). As a result, each of the servers may
     provide different information, depending upon the query type that
     was originally selected.
  
     Some operators may choose to purposefully provide misleading or
     erroneous information in an effort to avoid responsibility for bad
     behavior. In addition, there are likely to be sporadic operator
     errors which will result in confusing or erroneous answers.
  
     Neither this specification nor the LDAPv3 protocol currently
     provide cache timers or any other mechanisms which can indicate
     how accurate or timely any replicas may be. As a result, it is
     possible for a replica to become significantly outdated, even to
     the point of containing wholesale errors.
  
     For all of the reasons listed above, it is essential that
     applications and end-users not make critical decisions based on
     the information provided by the FIRS service without having reason
     to believe the veracity of the information. Users should limit
     unknown or untrusted information to routine purposes.
  
  Hall                  I-D Expires: December 2003            [page 21]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
     Despite these disclaimers, however, it is very likely that the
     information presented through the FIRS service will be used for
     many operational and problem-resolution purposes. In order to
     ensure the veracity of the information, a minimal set of
     operational guidelines are provided herein. For the most part,
     these rules are designed to prevent unauthorized modifications to
     the data.
  
     Note that these rules only apply to data which is willingly
     provided; no data is required to be entered, but where the data is
     provided, it SHOULD be validated as accurate on entry, and it MUST
     be secured against unauthorized modifications.
  
        *   The inetResources container entry and all of the resource-
            specific subordinate entries within every public DIT that
            provides FIRS resources SHOULD have anonymous read-only
            access permissions, and SHOULD NOT have anonymous add,
            delete or modify permissions.
  
        *   With the exception of contact-related attributes from the
            inetOrgPerson object class, each attribute MAY have
            whatever restrictions are necessary in order to suit local
            security policies, government regulations or personal
            privacy concerns. When the inetOrgPerson object class is
            used to provide contact details, the mail attribute MUST be
            defined, SHOULD be valid, SHOULD have read-only anonymous
            access, and SHOULD NOT have anonymous add, delete or modify
            permissions.
  
            By using the inetOrgPerson object class, it is expected
            that existing contact-related entries can be reused. If
            reusing these entries is undesirable or unfeasible, entries
            with the necessary access SHOULD be made available.
  
            Note that contact pointers are entirely optional and are
            not required to exist. However, where they exist, they MUST
            comply with the above requirements.
  
        *   End-users and implementers SHOULD provide anonymous access
            to the creatorsName, createTimestamp, modifiersName and
            modifyTimestamp operational attributes associated with each
            entry in the inetResources branch, since this information
            is useful for determining the age of the information.
  
  
  Hall                  I-D Expires: December 2003            [page 22]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
        *   Server administrators MAY define additional add, delete or
            modify permissions for authenticated users, using any
            LDAPv3 authentication mechanisms they wish. In particular,
            delegation entities MAY provide for the remote management
            of delegated resources (such as assigning modification
            privileges to the managers of a particular delegated domain
            or address block), although this is entirely optional, and
            is within the sole discretion of the delegation body.
  
     Finally, there are physical security issues associated with any
     service which provides physical addressing and delivery
     information. Although organizations are generally encouraged to
     provide as much information as they feel comfortable with, no
     information is required.
  
  8.      IANA Considerations
     The FIRS collection of specifications define an application of the
     LDAPv3 protocol rather than a new Internet application protocol.
     As such, there are no protocol-related IANA considerations.
  
     However, the FIRS collection of specifications do define several
     LDAP schema elements, including object classes, attributes,
     syntaxes and extensibleMatch filters, and these elements should be
     assigned OID values from the IANA branch. Furthermore, some of the
     specifications define their own status codes as attribute values,
     and IANA is expected to maintain the code-point mapping values
     associated with these attributes.
  
     Finally, some of the specifications also describe public DNS and
     LDAP data (including SRV resource records and LDAPv3 referrals).
     It is expected that IANA will see to the establishment and
     maintenance of these servers and data.
  
  9.      Author's Address
     Eric A. Hall
     ehall@ehsco.com
  
  10.     Normative References
          [RFC1274]     Barker, P., and Kille, S. "The COSINE and
                         Internet X.500 Schema", RFC 1274, November
                         1991.
  
  Hall                  I-D Expires: December 2003            [page 23]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
          [RFC2079]     Smith, M. "Definition of an X.500 Attribute
                         Type and an Object Class to Hold Uniform
                         Resource Identifiers (URIs)", RFC 2079,
                         January 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.
  
          [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.
  
          [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.
  
  
  Hall                  I-D Expires: December 2003            [page 24]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
          [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.
  
          [CRISP-REQ]   Newton, A. "Cross Registry Internet Service
                         Protocol (CRISP) Requirements", draft-ietf-
                         crisp-requirements-05, May 2003.
  
          [FIRS-ARCH]   Hall, E. "The Federated Internet Registry
                         Service: Architecture and Implementation
                         Guide", draft-ietf-crisp-firs-arch-00, May
                         2003.
  
          [FIRS-ASN]    Hall, E. "Defining and Locating Autonomous
                         System Numbers in the Federated Internet
                         Registry Service", draft-ietf-crisp-firs-asn-
                         00, May 2003.
  
          [FIRS-CONTCT] Hall, E. "Defining and Locating Contact
                         Persons in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-contact-00,
                         May 2003.
  
          [FIRS-CORE]   Hall, E. "The Federated Internet Registry
                         Service: Core Elements", draft-ietf-crisp-
                         firs-core-00, May 2003.
  
          [FIRS-DNS]    Hall, E. "Defining and Locating DNS Domains in
                         the Federated Internet Registry Service",
                         draft-ietf-crisp-firs-dns-00, May 2003.
  
          [FIRS-DNSRR]  Hall, E. "Defining and Locating DNS Resource
                         Records in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-dnsrr-00, May
                         2003.
  
          [FIRS-IPV4]   Hall, E. "Defining and Locating IPv4 Address
                         Blocks in the Federated Internet Registry
                         Service", draft-ietf-crisp-firs-ipv4-00, May
                         2003.
  
          [FIRS-IPV6]   Hall, E. "Defining and Locating IPv6 Address
                         Blocks in the Federated Internet Registry
  
  Hall                  I-D Expires: December 2003            [page 25]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
                         Service", draft-ietf-crisp-firs-ipv6-00, May
                         2003.
  
          [US-ASCII]    Cerf, V. "ASCII format for Network
                         Interchange", RFC 20, October 1969.
  
  11.     Informational References
          [RFC812]      Harrenstien, K., and White, V.
                         "NICNAME/WHOIS", RFC 812, March 1982.
  
  12.     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.
  
  13.     Changes from Previous Versions
     draft-ietf-crisp-fir-arch-00:
  
        *   Restructured document set, separating the architectural
            discussion from the technical descriptions.
  
        *   Consolidated the security discussions.
  
  
     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.
  
  Hall                  I-D Expires: December 2003            [page 26]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  
  
     draft-hall-FIRS-01:
  
        *   The ôObjectivesö section has been removed. [ir-dir-req] is
            now being used as the guiding document for this service.
  
        *   Several typographical errors have been fixed.
  
        *   Some unnecessary text has been removed.
  
        *   Figures changed to show complete sets of object classes, to
            improve inheritance visibility.
  
        *   Clarified the handling of reverse-lookup domains (zones
            within the in-addr.arpa portion of the DNS hierarchy) in
            the inetDnsDomain object class reference text.
  
        *   Referrals now use regular LDAP URLs (multiple responses
            with explicit hostnames and port numbers). Prior editions
            of this specification used LDAP SRV resource records for
            all referrals.
  
        *   The delegation status codes used by the
            inetDnsDelegationStatus, inetIpv4DelegationStatus,
            inetIpv6DelegationStatus and inetAsnDelegationStatus
            attributes have been condensed to a more logical set.
  
        *   Added an inetDnsAuthServers attribute for publishing the
            authoritative DNS servers associated with a domain. NOTE
            THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE
            REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND
            ATTRIBUTES.
  
        *   Added an inetGeneralDisclaimer attribute for publishing
            generalized disclaimers.
  
        *   Added the inetAssociatedResources auxiliary object class
            for defining associated resources, and moved some of the IP
            addressing and ASN attributes to the new object class.
  
        *   Several attributes had their OIDs changed. NOTE THAT THIS
            IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
            ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
  
  
  Hall                  I-D Expires: December 2003            [page 27]


  Internet Draft    draft-ietf-crisp-firs-arch-00.txt         May 2003
  
  
  14.     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
     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 28]
  

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