INTERNET-DRAFT Eric A. Hall Document: draft-ietf-crisp-firs-arch-01.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-01.txt May 2003 Table of Contents 1. Introduction...............................................2 1.1. Background..............................................3 1.2. Overview................................................4 2. Prerequisites and Terminology..............................5 3. Reference Example..........................................6 4. The FIRS Namespace.........................................8 4.1. The domainComponent Hierarchy...........................8 4.2. The inetResources Container.............................9 4.3. Resource-Specific Entries..............................10 4.4. Namespace Aliases......................................10 4.5. Partition Replicas.....................................11 5. FIRS Schema Definitions...................................12 5.1. Global Schema..........................................12 5.1.1. The inetResources schema.........................13 5.1.2. The inetAssociatedResources schema...............14 5.1.3. The referral schema..............................14 5.2. Resource-Specific Schema...............................14 6. Query Processing Behaviors................................15 6.1. Query Pre-Processing...................................16 6.2. Bootstrap Processing...................................17 6.3. Query Processing.......................................18 6.4. Query Post-Processing..................................19 6.4.1. Referrals........................................19 6.4.2. Internationalization and localization............20 7. Transition Issues.........................................22 7.1. NIC Handles............................................22 7.2. Change-Logs............................................23 8. Security Considerations...................................23 9. IANA Considerations.......................................26 10. Author's Address..........................................26 11. Normative References......................................26 12. Informational References..................................28 13. Acknowledgments...........................................28 14. Changes from Previous Versions............................29 15. Full Copyright Statement..................................30 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. Hall I-D Expires: December 2003 [page 2]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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 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. Hall I-D Expires: December 2003 [page 3]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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 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. Hall I-D Expires: December 2003 [page 4]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 * Schema Definitions. The FIRS specifications reuse some existing LDAP schema definitions, and also define several FIRS-specific definitions, as needed. * Query-Processing Rules. 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-01, "The Federated Internet Registry Service: Architecture and Implementation" (this document) [FIRS-ARCH] draft-ietf-crisp-firs-core-01, "The Federated Internet Registry Service: Core Elements" [FIRS-CORE] draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS Domains in the Federated Internet Registry Service" [FIRS-DNS] 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-01, "Defining and Locating Contact Persons in the Federated Internet Registry Service" [FIRS-CONTCT] 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 5]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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-01, "Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service" [FIRS-IPV6] 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. 3. 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-01.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, entries use a FIRS-specific namespace in conjunction with FIRS-specific schema. Meanwhile, clients use FIRS-specific queries to locate and retrieve this information. Hall I-D Expires: December 2003 [page 7]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 4. 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 searches, and help to ensure predictable results. The use of a private namespace also acts to segregate FIRS-related data from other kinds of data which may reside on a participating server, thereby giving the operator greater control over the security and replication considerations for all of the data. 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 entries which describe the resources under the control of the selected partition. The namespace follows a right-to-left order. As an example, Figure 1 shows a 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. 4.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, with the full sequence of RDNs cumulatively representing the root of a partition in the LDAP directory tree. In this model, a sequence of domainComponent RDNs map to a domain name in the global DNS hierarchy, with the FIRS partitions providing scopes of authority in the global FIRS database of distributed partitions. Furthermore, the SRV resource records associated with those DNS domains also provide a useful mechanism Hall I-D Expires: December 2003 [page 8]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 for locating the authoritative LDAP servers associated with 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 the amount of ambiguity which is naturally present in this kind of model, 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. 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, with the "dc=example,dc=com" sequence representing the root of a partition in the globally distributed directory database. 4.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 partition 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 FIRS-related resources allows that branch of the directory database to be managed independently of other entries on the server, which facilitates better operational security and replication controls. All told, the use of the inetResources container is important enough to justify the MANDATORY usage of this naming syntax. Hall I-D Expires: December 2003 [page 9]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 4.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 in the "cn=inetResources" container of the "dc=example,dc=com" partition, and also shows an entry for the "admins@example.com" contact resource in that same container and partition. Although the naming syntax is different for each resource type, the naming rules are consistent and facilitate predictable usage. The naming rules for each of the distinct resource type are provided in the documents which govern those resource types. 4.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 Hall I-D Expires: December 2003 [page 10]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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 6.4.1 for a brief discussion on how these URLs are processed by FIRS clients. 4.5. Partition Replicas All directory partitions which provide data for global Internet resources SHOULD be replicated across two or more servers. Each of the authoritative LDAP servers for the managed resource MUST be specified with a unique DNS SRV resource record for the domain name associated with the top-level resource assignment space. Directory partitions which serve multiple organizations SHOULD also be replicated. For example, an ISP 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 associated with an user-managed resource MAY be replicated, and are encouraged to do so. Similarly, any referral URLs which include host identifier elements SHOULD provide multiple URLs, each of which identify different hosts. For leaf-node referrals 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 directory partitions with the delegation parents, as this will allow queries for those resources to be processed by the parent servers (thereby eliminating the need for referral queries). In many cases, this will not be feasible (the servers for the "dc=com" directory partition cannot Hall I-D Expires: December 2003 [page 11]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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 6.4.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 important to recognize that the LDAP specifications do not currently provide cache timers or any other mechanisms which can indicate how accurate or timely any replicas may be. 5. 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. Wherever any suitable pre-existing schema definitions are available they should be reused, since reuse facilitates integration with other LDAP applications. 5.1. Global Schema There are three global schema definitions which can be used by any of the entries within FIRS. 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 general-purpose attributes which are useful for general information about an organization and its resources. * 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 Hall I-D Expires: December 2003 [page 12]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 entry to reference other resources 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 4.4 for a discussion on the different kinds of referral mechanisms offered by FIRS, and section 6.4.1 for a discussion on the FIRS referral-processing mechanisms. Figure 1 shows that all of the entries within and including the "cn=inetResources" container entry have the inetResources object class defined. Meanwhile, each of the resource-specific entries in that example also have their own resource-specific object classes, while the "cn=www.example.com" resource-specific entry also has the referral object class defined. 5.1.1. The inetResources schema 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 data across all of their hosted domains and routed networks. If separate contacts are required for each resource, the contact data should be specified within each entry, rather than being linked to the inetResources entry. The inetResources object class provides several multi-valued contact-related attributes for a variety of well-known administrative roles. This model allows the inetResources entry and each of the subordinate managed resources to share a common set of administrative roles, or to have unique roles for each resource, as seen fit by the managing entity. Hall I-D Expires: December 2003 [page 13]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 5.1.2. The inetAssociatedResources schema The inetAssociatedResources object class defines attributes which are useful for providing general-purpose cross-referencing information with other resources. For example, a contact entry can list IPv4 networks or DNS domains as associated resources, thereby providing a simplistic cross-reference mechanism between an administrator and the resource he manages. In short, any resource can be associated with any other resource through the use of this object class. 5.1.3. The referral schema The referral object class is used to redirect queries to other entries programmatically. This object class and its associated schema and rules provide the backbone of the aliasing mechanisms discussed in section 4.4. 5.2. Resource-Specific Schema In addition to the global schema definitions, each of the resource-specific entries 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 zone delegations, host-specific entries, reverse-lookup pointer entries, or any other domain name. * 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 address block resource MUST use the inetIpv4Network object class and schema definitions defined in [FIRS-IPV4]. Entries can refer to entire networks or to single hosts, as needed. * IPv6 address blocks. Every IPv6 address block resource MUST use the inetIpv6Network object class and schema definitions Hall I-D Expires: December 2003 [page 14]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 defined in [FIRS-IPV6]. Entries can refer to entire networks or to single hosts, as needed. * Autonomous system numbers. Every autonomous system number resource 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], but MUST also use the additional schema definitions defined in [FIRS-CONTCT]. As was discussed in section 5.1, each resource-specific entry MAY exist as a referral source, or MAY have attributes which refer to additional (related) resources. 6. Query Processing Behaviors Another critical aspect to FIRS is the query-processing behavioral rules which govern the ways in which a client parses an input string, locates a server which is authoritative for the resource being queried, generates LDAPv3 queries, and processes the resulting answer data. More specifically: * Query pre-processing. 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 resource-type and partition have been determined, the client must locate the LDAP servers which are authoritative for that partition. [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 define resource-specific matching rules. Hall I-D Expires: December 2003 [page 15]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 * Query post-processing. Response data frequently needs to be further processed. For example, referrals may need to be processed, or some kinds of data may need to be localized. These mechanisms and their behavioral rules are defined in [FIRS-CORE], while the resource-specific specifications may also describe supplemental rules. Each of these phases are discussed in more detail below. 6.1. Query Pre-Processing Client input is generally limited to a single well-formed unit of data, such as a domain name ("example.com") or an email address ("admins@example.com"), and this single piece of information 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 validated and normalized into a canonical UTF-8 [RFC2279] form before any other steps can be 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 with the syntax requirements. * Determine the authoritative directory partition for the named resource. In most cases, the 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 Hall I-D Expires: December 2003 [page 16]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 authoritative partition for an ASN uses a reserved (special-purpose) domain name. In some cases, the authoritative partition may change during the subsequent query-processing steps. * Determine the search base for the query. Each resource type has resource-specific query-processing rules which will dictate how the authoritative partitions are mapped to the search base. In some cases, the cn=inetResources container entry in the authoritative partition will be used "as-is", while in other cases, the cn=inetResources container entry in a delegation parent of the authoritative partition will be used instead. In some cases, the search base may change during 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 change during subsequent query-processing steps. * Determine the matching filter. Each resource-type has its own matching filter rules. 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. Once all of the pre-processing steps have been successfully completed, the client will have to locate an LDAPv3 server which is authoritative for the search base before it can submit the query. This process is described in section 6.2 below. 6.2. Bootstrap Processing The bootstrap process uses DNS queries to locate the LDAP servers which should be used for a query. 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 specific 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. Hall I-D Expires: December 2003 [page 17]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 * Top-down. The "top-down" bootstrap model has the client attempting to locate the LDAP servers associated with a top-level partition in the delegation path to the authoritative partition. 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 authoritative partition itself. If no servers can be found for that partition, the authoritative partition is reset to the immediate parent in the delegation hierarchy and new DNS queries are issued, with this process repeating until some servers are found or there are no more partitions in the delegation path which can be queried. Each of the models are appropriate to different usages. For example, The targeted model is most useful when a particular piece of 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 resources which are not centrally delegated and managed (such as contact information). 6.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 a variety of factors, including 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]. Hall I-D Expires: December 2003 [page 18]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 6.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 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. 6.4.1. Referrals As was discussed in section 4.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 using the search base specified in the referral message. 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 [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. This condition means that the current search operation has succeeded, but that additional searches SHOULD be started for all of the known answer data to be retrieved. 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, Hall I-D Expires: December 2003 [page 19]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 but it won't be the only response in the common case). 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 is required to display any answer data which has also been received and then process the referral. LDAP referrals can use any kind of URL, although FIRS specifically requires the use of LDAP URLs. The client is required to parse the resulting URL for a host identifier, port number, search base, and assertion value elements, and then use these elements to construct and issue new queries. Note that [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. 6.4.2. Internationalization and localization The FIRS model uses the internationalization and localization services which are inherent in LDAPv3. In many cases, this native support is sufficient to accommodate internationalization and localization considerations. However, there are several cases where additional and explicit support is required. For example, the domainComponent attribute is specifically restricted to seven-bit character codes, and is traditionally interpreted as simple [US-ASCII]. This is problematic with internationalized domain names and the domainComponent attributes derived from them, since these attribute sequences are used in partition identifiers, search bases, and numerous other areas. In order to ensure interoperability, all DNS domain names which are mapped to domainComponent attributes MUST be reduced to their ASCII-compatible form using the ToASCII process defined in [RFC3490] before they are used for domainComponent sequences. Similarly, although DNS is technically capable of storing eight- bit code-point values, the operational rules which govern DNS do not support this usage for domain names which are used as host identifiers (and this includes zone delegations). As a result, internationalized domain names which are to be used for SRV or A resource record lookups MUST be reduced to their ASCII-compatible Hall I-D Expires: December 2003 [page 20]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 form using the ToASCII process defined in [RFC3490] before these DNS queries are issued. In those cases where entries or attributes use normalized UTF-8 sequences inside of FIRS (specifically domain names and email addresses), FIRS clients SHOULD offer ASCII-compatible versions of those sequences, using the ToASCII process defined in [RFC3490]. This will ensure that clients are able to use these sequences with legacy (pre-IDNA) applications directly. For example, if an entry displays an inetAssociatedDomains attribute, the domain names in that attribute should be displayed in their default UTF-8 form (assuming that the client's operating system and application allows it), but should also be made available in their ASCII- compatible form (either as a clipboard option, command-line option, or some other user-selectable switch) in order to allow the data to be passed to a legacy application in a form which is understandable by that application. Attribute names are fixed, and can therefore be localized easily. As such, clients MAY choose to convert attribute names into a language appropriate to the local user for display purposes if this is desirable. However, clients MUST NOT localize attribute names which are used for query input. For example, clients MUST NOT convert "cn=" or "dc=" relative distinguished labels into a language-specific mapping and then use the mapped versions of these labels for assertion values in a subsequent query. RFC 2277 [RFC2277] requires free-text data to be tagged 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 to display the appropriate attribute value instance based on the locale settings of the user. International postal regulations generally require that the recipient address on an envelope be provided in a language and charset which is native to the recipient's country, with the exception of the destination country name which should be provided in a language and charset that is native to the sender's country. This model ensures that the sender's post office will be able to route the mail to the recipient's country, while also ensuring that the destination country's post office will be able to perform local delivery. In order to facilitate this usage, the country attribute value MAY (encouraged) be localized to the local user's Hall I-D Expires: December 2003 [page 21]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 nomenclature for a country, but other postal address information SHOULD NOT be localized. Notwithstanding the above, it is ENCOURAGED that contact names be provided in English forms in order to facilitate inter-party communications, using the mechanisms offered by [RFC2596]. For example, the default contact entry for a person in Japan SHOULD be provided in the native form for that person, but an English form is also ENCOURAGED in order to allow non-Japanese users to properly address that person in subsequent communications. As stated in the preceding paragraph however, any postal communications for that person SHOULD use the native-language representation (at least on the envelope) in order to facilitate the delivery of postal mail. Time and date strings in LDAP use the generalizedTime syntax, making them predictable and easily convertible if necessary. As such, dates MAY be localized for display purposes by client applications as necessary. Finally, clients must recognize that some URL data is likely to be escaped, using at least one of the multiple rules which affect URLs and resource-specific data. For example, a URL which contains a domain name resource could theoretically have been escaped with three or four different syntax rules, and clients MUST be prepared to decode these URLs appropriately. 7. Transition Issues There are a handful of areas where FIRS does not fully compare with all of the existing WHOIS service offerings. These areas are discussed in more detail below. 7.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- Hall I-D Expires: December 2003 [page 22]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 scoped email address of "ehall@whois.netsol.com" or some variation thereof. Of the two mechanisms described above, the former is preferred. 7.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 make change-log information available to the public should use an LDAP schema for this purpose. An initial schema has been developed for this purpose and is available at http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt. However, this schema has not yet been proposed as a standards-track effort, and should only be used as a starting point for other development. 8. Security Considerations The FIRS collection of specifications describe an application of the LDAPv3 protocol, and as such it inherits the security 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 Hall I-D Expires: December 2003 [page 23]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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. 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. Hall I-D Expires: December 2003 [page 24]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 * 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. * 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. Hall I-D Expires: December 2003 [page 25]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 9. 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 servers and data. It is expected that IANA will see to the establishment and maintenance of these servers and data. 10. Author's Address Eric A. Hall ehall@ehsco.com 11. Normative References [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-01, May 2003. [FIRS-ASN] Hall, E. "Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service", draft-ietf-crisp-firs-asn- 01, May 2003. [FIRS-CONTCT] Hall, E. "Defining and Locating Contact Persons in the Federated Internet Registry Service", draft-ietf-crisp-firs-contact-01, May 2003. [FIRS-CORE] Hall, E. "The Federated Internet Registry Service: Core Elements", draft-ietf-crisp- firs-core-01, May 2003. Hall I-D Expires: December 2003 [page 26]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in the Federated Internet Registry Service", draft-ietf-crisp-firs-dns-01, May 2003. [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource Records in the Federated Internet Registry Service", 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-01, May 2003. [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service", draft-ietf-crisp-firs-ipv6-01, May 2003. [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. [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and Sataluri, S. "Using Domains in LDAP/X.500 DNs", RFC 2247, January 1998. [RFC2279] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 2279, 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 27]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 [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. [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. [US-ASCII] Cerf, V. "ASCII format for Network Interchange", RFC 20, October 1969. 12. Informational References [RFC812] Harrenstien, K., and White, V. "NICNAME/WHOIS", RFC 812, March 1982. 13. Acknowledgments Hall I-D Expires: December 2003 [page 28]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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. 14. Changes from Previous Versions draft-ietf-crisp-firs-arch-01: * Several clarifications and corrections have been made. draft-ietf-crisp-firs-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. draft-hall-ldap-whois-01: * The "Objectives" section has been removed. [ir-dir-req] is now being used as the guiding document for this service. * Several typographical errors have been fixed. * Some unnecessary text has been removed. Hall I-D Expires: December 2003 [page 29]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 * 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. 15. 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 Hall I-D Expires: December 2003 [page 30]
Internet Draft draft-ietf-crisp-firs-arch-01.txt May 2003 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 31]
