draft-ietf-crisp-firs-arch-02.txt   draft-ietf-crisp-firs-arch-03.txt 
INTERNET-DRAFT Eric A. Hall INTERNET-DRAFT Eric A. Hall
Document: draft-ietf-crisp-firs-arch-02.txt July 2003 Document: draft-ietf-crisp-firs-arch-03.txt August 2003
Expires: February, 2004 Expires: March, 2004
Category: Standards-Track Category: Standards-Track
The Federated Internet Registry Service: The Federated Internet Registry Service:
Architecture and Implementation Guide Architecture and Implementation Guide
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
skipping to change at line 49 skipping to change at line 49
Federated Internet Registry Service (FIRS), a distributed service Federated Internet Registry Service (FIRS), a distributed service
for storing, locating and transferring information about Internet for storing, locating and transferring information about Internet
resources using LDAPv3. resources using LDAPv3.
Table of Contents Table of Contents
1. Introduction...............................................3 1. Introduction...............................................3
1.1. Background..............................................3 1.1. Background..............................................3
1.2. Objectives..............................................4 1.2. Objectives..............................................4
1.3. Overview................................................4 1.3. Overview................................................4
2. Prerequisites and Terminology..............................5 2. Prerequisites and Terminology..............................6
3. Reference Example..........................................6 3. Reference Example..........................................6
4. The FIRS Namespace.........................................7 4. The FIRS Namespace.........................................8
4.1. The domainComponent Hierarchy...........................7 4.1. The domainComponent Hierarchy...........................8
4.2. The inetResources Container.............................8 4.2. The inetResources Container.............................9
4.3. Resource-Specific Entries...............................9 4.3. Resource-Specific Entries..............................10
4.4. Namespace Aliases.......................................9 4.4. Attribute References...................................10
4.5. Partition Replicas.....................................10 4.5. Namespace Aliases......................................10
5. FIRS Schema Definitions...................................11 4.6. Partition Replicas.....................................11
5.1. Global Schema..........................................11 5. FIRS Schema Definitions...................................12
5.1.1. The inetResources schema.........................12 5.1. Global Schema..........................................13
5.1.2. The inetAssociatedResources schema...............13 5.1.1. The inetResources schema.........................13
5.1.3. The referral schema..............................13 5.1.2. The inetAssociatedResources schema...............14
5.2. Resource-Specific Schema...............................13 5.1.3. The referral schema..............................14
6. Query Processing Behaviors................................14 5.2. Resource-Specific Schema...............................14
6.1. Query Pre-Processing...................................15 6. Query Processing Behaviors................................15
6.2. Bootstrap Processing...................................16 6.1. Query Pre-Processing...................................16
6.3. Query Processing.......................................17 6.2. Bootstrap Processing...................................18
6.4. Query Post-Processing..................................18 6.3. Query Processing.......................................19
6.4.1. Referrals........................................19 6.4. Query Post-Processing..................................20
6.4.2. Internationalization and localization............20 6.4.1. Referrals........................................20
7. Transition Issues.........................................22 6.4.2. Internationalization and localization............21
7.1. NIC Handles............................................22 6.5. Query Restriction Mechanisms...........................23
7.2. Change-Logs............................................23 7. Transition Issues.........................................24
7.3. Legacy System Support..................................23 7.1. NIC Handles............................................24
8. Security Considerations...................................24 7.2. Change-Logs............................................25
9. IANA Considerations.......................................26 7.3. Legacy System Support..................................25
10. Normative References......................................27 8. Security Considerations...................................26
11. Informational References..................................29 9. IANA Considerations.......................................28
12. Changes from Previous Versions............................29 10. Normative References......................................29
13. Author's Address..........................................31 11. Informational References..................................31
14. Acknowledgments...........................................31 12. Changes from Previous Versions............................31
15. Full Copyright Statement..................................31 13. Author's Address..........................................33
14. Acknowledgments...........................................33
15. Full Copyright Statement..................................33
Hall I-D Expires: February 2004 [page 2] Hall I-D Expires: March 2004 [page 2]
1. Introduction 1. Introduction
FIRS is intended to provide a distributed WHOIS-like information FIRS is intended to provide a distributed WHOIS-like information
service, using the LDAPv3 specifications [RFC3377] for the data- service, using the LDAPv3 specifications [RFC3377] for the data-
formatting and query-transport functions. formatting and query-transport functions.
1.1. Background 1.1. Background
The original WHOIS service [RFC812] was provided as a front-end to The original WHOIS service [RFC812] was provided as a front-end to
a centralized repository of ARPANET resources and users. Over a centralized repository of ARPANET resources and users. Over
skipping to change at line 127 skipping to change at line 129
described in the preceding text. described in the preceding text.
FIRS attempts to address these issues by defining guidelines for FIRS attempts to address these issues by defining guidelines for
the operation of a distributed and highly-structured WHOIS-like the operation of a distributed and highly-structured WHOIS-like
service, using LDAPv3 for the query/response transfer service, and service, using LDAPv3 for the query/response transfer service, and
using LDAP schema for the search inputs, answer data, and using LDAP schema for the search inputs, answer data, and
redirection mechanisms. In short, the intention of this approach redirection mechanisms. In short, the intention of this approach
is to provide an extensible and scalable WHOIS-like service by is to provide an extensible and scalable WHOIS-like service by
leveraging the inherent capabilities of LDAPv3. leveraging the inherent capabilities of LDAPv3.
Hall I-D Expires: February 2004 [page 3] Hall I-D Expires: March 2004 [page 3]
1.2. Objectives 1.2. Objectives
The principle objective behind FIRS is to offer structured The principle objective behind FIRS is to offer structured
information about distributed Internet resources in a model which information about distributed Internet resources in a model which
reflects the federated delegations of those resources. This reflects the federated delegations of those resources. This
specifically includes centralized delegations from authorized specifically includes centralized delegations from authorized
governance bodies (such as DNS domains under top-level domains), governance bodies (such as DNS domains under top-level domains),
but also includes delegations from authorized bodies further down but also includes delegations from authorized bodies further down
the delegation path (such as leaf-node DNS domain names within the the delegation path (such as leaf-node DNS domain names within the
"corp.example.com" zone). "corp.example.com" zone).
skipping to change at line 173 skipping to change at line 175
1.3. Overview 1.3. Overview
In order to achieve the stated objectives, the FIRS specifications In order to achieve the stated objectives, the FIRS specifications
collectively define an LDAP-specific application, including collectively define an LDAP-specific application, including
application-specific namespaces, object classes, attributes, application-specific namespaces, object classes, attributes,
syntaxes, matching filters, behavioral rules, and more. The syntaxes, matching filters, behavioral rules, and more. The
framework defined in this document is intended to accommodate the framework defined in this document is intended to accommodate the
specific resource-types and usages, while the other specifications specific resource-types and usages, while the other specifications
Hall I-D Expires: February 2004 [page 4] Hall I-D Expires: March 2004 [page 4]
define the technical details for the service as a whole or for the define the technical details for the service as a whole or for the
unique resource-types. unique resource-types.
Cumulatively, the FIRS collection of specifications define the Cumulatively, the FIRS collection of specifications define the
following service elements: following service elements:
* Namespace Rules. The FIRS specifications define a layered * Namespace Rules. The FIRS specifications define a layered
namespace consisting of DNS-based delegation hierarchies, a namespace consisting of DNS-based delegation hierarchies, a
FIRS-specific container entry, and resource-specific FIRS-specific container entry, and resource-specific
subordinate entries. subordinate entries.
skipping to change at line 195 skipping to change at line 197
* Schema Definitions. The FIRS specifications reuse some * Schema Definitions. The FIRS specifications reuse some
existing LDAP schema definitions, and also define several existing LDAP schema definitions, and also define several
FIRS-specific definitions, as needed. FIRS-specific definitions, as needed.
* Query-Processing Rules. The FIRS specifications also reuse * Query-Processing Rules. The FIRS specifications also reuse
some existing processing rules, and define several some existing processing rules, and define several
additional rules as needed. Among these rules are additional rules as needed. Among these rules are
requirements for normalizing data, locating servers, requirements for normalizing data, locating servers,
processing referrals, and more. processing referrals, and more.
Some of these rules apply to the architecture as a whole, while Meanwhile, the core collection of FIRS specifications define these
other rules apply to specific kinds of Internet resources. naming, schema and processing rules for the following kinds of
Internet resources:
* Partition Data. Each partition in the globally distributed
database provides information about the partition itself,
allowing users to get a sense of who is providing the data.
* Domain Name Resources. Any DNS domain name (including zone
delegations and host-specific resources) can be tracked in
the FIRS directory, with information about the domain
resource being provided by registries, registrars, or
operators, individually or collectively.
* Network Block Resources. Any IP address block (including v4
or v6 networks or host-specific addresses) or Autonomous
System can be tracked in the FIRS directory, with
information about the network resource being provided by
regional registries, registrars, or operators, individually
or collectively.
* Contacts. Each partition and network resource has multiple
role-specific contact definitions, any of which can refer
to generic role accounts or to actual persons, according to
Hall I-D Expires: March 2004 [page 5]
policy and/or desire. Any partition can provide any degree
of data about the contact entries under their control.
* Cross-Partition Pointers. Entries can act as aliases to
other entries, or can point to other entries as sources of
additional data. Meanwhile, attribute values for well-known
resources can provide pointers to related data, such as
providing a contact identifier that refers to a contact in
another partition.
Cumulatively, this architecture provides a substrate of well-
formed data which is highly-distributed across independent
partitions and servers, while providing multiple "stovepipe"
applications of that data.
2. Prerequisites and Terminology 2. Prerequisites and Terminology
The complete set of specifications in the FIRS collection The complete set of specifications in the FIRS collection
cumulative define a structured and distributed information service cumulative define a structured and distributed information service
using LDAPv3 for the data-formatting and transport functions. This using LDAPv3 for the data-formatting and transport functions. This
specification should be read in the context of that set, which specification should be read in the context of that set, which
currently includes [FIRS-CORE], [FIRS-DNS], [FIRS-DNSRR], currently includes [FIRS-CORE], [FIRS-DNS], [FIRS-DNSRR],
[FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6]. [FIRS-CONTCT], [FIRS-ASN], [FIRS-IPV4] and [FIRS-IPV6].
In order to fully understand FIRS, readers should be familiar with In order to fully understand FIRS, readers should be familiar with
[RFC2247], [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2256], [RFC2247], [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2256],
[RFC2798], [RFC3296]and [RFC3377]. [RFC2798], [RFC3296]and [RFC3377].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119. in this document are to be interpreted as described in RFC 2119.
Hall I-D Expires: February 2004 [page 5]
3. Reference Example 3. Reference Example
Figure 1 below shows an example of a FIRS-specific data-set. This For the purpose of subsequent discussion, a visual example of a
example is referenced throughout this specification. typical partition is provided below. This data-set is not intended
to provide a complete demonstration of all the capabilities in
FIRS, but instead is only intended for illustration purposes. Each
of the resource-specific specifications provide additional
examples and illustrations which provide more detail.
Hall I-D Expires: March 2004 [page 6]
Figure 1 below shows an example of a FIRS-specific data-set.
dc=example,dc=com dc=example,dc=com
| |
+-cn=inetResources,dc=example,dc=com +-cn=inetResources,dc=example,dc=com
[top object class] [top object class]
[inetResources object class] [inetResources object class]
| |
+-attribute: inetGeneralContacts +-attribute: inetGeneralContacts
| value: "admins@example.com" | value: "admins@example.com"
| |
skipping to change at line 242 skipping to change at line 288
| [inetResources object class] | [inetResources object class]
| [inetOrgPerson object class] | [inetOrgPerson object class]
| | | |
| +-attribute: mail | +-attribute: mail
| value: "admins@example.com" | value: "admins@example.com"
| |
+-cn=example.com,cn=inetResources,dc=example,dc=com +-cn=example.com,cn=inetResources,dc=example,dc=com
| [top object class] | [top object class]
| [inetResources object class] | [inetResources object class]
| [inetDnsDomain object class] | [inetDnsDomain object class]
| [inetDnsRR object class]
| | | |
| +-attribute: inetDnsAuthServers | +-attribute: inetDnsRRData
| value: "ns1.example.net" | value: "NS 86400 864000 ns1.example.net"
| |
+-cn=www.example.com,cn=inetResources,dc=example,dc=com +-cn=www.example.com,cn=inetResources,dc=example,dc=com
[top object class] [top object class]
[inetResources object class] [inetResources object class]
[inetDnsDomain object class] [inetDnsDomain object class]
[referral object class] [referral object class]
| |
+-attribute: inetTechContacts
| value: "admins@example.com"
|
+-attribute: ref +-attribute: ref
value: "ldap://firs.example.net/cn=inetResources, value: "ldap:///???(1.3.6.1.4.1.7161.1.3.0.1:=
dc=example,dc=net"??? www-1.example.net)"
(1.3.6.1.4.1.7161.1.1.8:=host.example.net)"
Figure 1: The FIRS-specific data for Example Widgets. Figure 1: The FIRS-specific data for Example Widgets.
Hall I-D Expires: February 2004 [page 6]
As can be seen in Figure 1, entries use a FIRS-specific namespace As can be seen in Figure 1, entries use a FIRS-specific namespace
in conjunction with FIRS-specific schema. FIRS clients use FIRS- in conjunction with FIRS-specific schema. FIRS clients use FIRS-
specific queries to navigate and retrieve the data, as needed. specific queries to navigate and retrieve the data, as needed.
Hall I-D Expires: March 2004 [page 7]
4. The FIRS Namespace 4. The FIRS Namespace
A critical aspect of FIRS is the use of an application-specific A critical aspect of FIRS is the use of an application-specific
namespace which is imposed on all FIRS-based resources. The FIRS namespace which is imposed on all FIRS-based resources. The FIRS
namespace rules facilitate the programmatic creation of searches, namespace rules facilitate the programmatic creation of searches,
and help to ensure predictable results. and help to ensure predictable results.
The FIRS namespace consists of three "layers", which are: The FIRS namespace consists of three "layers", which are:
* A set of domainComponent relative distinguished names which * A set of domainComponent relative distinguished names which
skipping to change at line 309 skipping to change at line 352
cumulatively represents a partition in the LDAP directory tree. cumulatively represents a partition in the LDAP directory tree.
In this model, a sequence of domainComponent RDNs map to a domain In this model, a sequence of domainComponent RDNs map to a domain
name in the global DNS hierarchy, with a FIRS partition having an name in the global DNS hierarchy, with a FIRS partition having an
identical scope of authority as its domain name counterpart. identical scope of authority as its domain name counterpart.
Furthermore, the SRV resource records associated with those DNS Furthermore, the SRV resource records associated with those DNS
domains also provide a mechanism for locating the authoritative domains also provide a mechanism for locating the authoritative
LDAP servers associated with any particular resource in the global LDAP servers associated with any particular resource in the global
FIRS directory database. FIRS directory database.
Hall I-D Expires: February 2004 [page 7]
Since the partition roots determine the scope of control over a Since the partition roots determine the scope of control over a
set of resources, partitions which overlap also have overlapping set of resources, partitions which overlap also have overlapping
scopes of control. For example, the "dc=com" and scopes of control. For example, the "dc=com" and
"dc=example,dc=com" partitions can both provide information about "dc=example,dc=com" partitions can both provide information about
Hall I-D Expires: March 2004 [page 8]
the "www.example.com" domain name resource. In order to reduce the the "www.example.com" domain name resource. In order to reduce the
amount of ambiguity which is naturally present in this kind of amount of ambiguity which is naturally present in this kind of
model, FIRS defines multiple bootstrapping models and also defines model, FIRS defines multiple bootstrapping models and also defines
the default model which should be used for any given resource. For the default model which should be used for any given resource. For
example, queries for centrally-delegated resources are supposed to example, queries for centrally-delegated resources are supposed to
ask the top-level partition for information about those resources, ask the top-level partition for information about those resources,
while queries for user-managed resources are supposed to ask the while queries for user-managed resources are supposed to ask the
leaf-node partition for information about those resources. leaf-node partition for information about those resources.
Figure 1 shows the directory partition of "dc=example,dc=com" Figure 1 shows the directory partition of "dc=example,dc=com"
skipping to change at line 355 skipping to change at line 399
root of every directory partition that provides FIRS services. All root of every directory partition that provides FIRS services. All
publicly-accessible resource-specific FIRS-related entries MUST be publicly-accessible resource-specific FIRS-related entries MUST be
stored in the "cn=inetResources" container entry. stored in the "cn=inetResources" container entry.
The primary motivation for this naming rule is for predictability, The primary motivation for this naming rule is for predictability,
in that it allows searches to be formed programmatically (a search in that it allows searches to be formed programmatically (a search
base for resources in "dc=example,dc=com" can be programmatically base for resources in "dc=example,dc=com" can be programmatically
formed as "cn=inetResources,dc=example,dc=com", for example). formed as "cn=inetResources,dc=example,dc=com", for example).
Furthermore, the use of a single container entry for all of an Furthermore, the use of a single container entry for all of an
organization's FIRS-related resources allows that branch of the organization's FIRS-related resources allows that branch of the
Hall I-D Expires: February 2004 [page 8]
directory database to be managed independently of other entries on directory database to be managed independently of other entries on
the server, which facilitates better operational security and the server, which facilitates better operational security and
replication controls. replication controls.
Hall I-D Expires: March 2004 [page 9]
All told, the use of the inetResources container is important All told, the use of the inetResources container is important
enough to justify the MANDATORY usage of this naming syntax. enough to justify the MANDATORY usage of this naming syntax.
4.3. Resource-Specific Entries 4.3. Resource-Specific Entries
The FIRS collection of specifications define several Internet The FIRS collection of specifications define several Internet
resource types, each of which have their own naming rules. resource types, each of which have their own naming rules.
However, each resource type follows a consistent naming principle, However, each resource type follows a consistent naming principle,
in that each specific resource has an RDN which uniquely in that each specific resource has an RDN which uniquely
identifies that resource within the inetResources container entry. identifies that resource within the inetResources container entry.
skipping to change at line 383 skipping to change at line 426
domain name resource in the "cn=inetResources" container of the domain name resource in the "cn=inetResources" container of the
"dc=example,dc=com" partition, and also shows an entry for the "dc=example,dc=com" partition, and also shows an entry for the
"admins@example.com" contact resource in that same container and "admins@example.com" contact resource in that same container and
partition. Although the naming syntax is different for each partition. Although the naming syntax is different for each
resource type, the naming rules are consistent and facilitate resource type, the naming rules are consistent and facilitate
predictable usage. predictable usage.
The naming rules for each of the distinct resource type are The naming rules for each of the distinct resource type are
provided in the documents which govern those resource types. provided in the documents which govern those resource types.
4.4. Namespace Aliases 4.4. Attribute References
Most of the core attributes that refer to one of the other core
attributes provide entry names as data values. In this model, an
attribute which needs to identify a particular resource provides
the name of the target resource as the attribute value, with the
client using this data to instantiate any new queries which may be
requested by the user.
For example, many of the object classes provide "contact"
attributes, each of which provide one or more contact identifiers
as attribute values (such as providing "account@registry" or
"user@domain", or both of these identifiers). If the user wishes
to obtain more information about any of the listed contacts, they
would use the identifier value to start a new query (in turn,
these queries may further reference additional entries in the
global system, either through the use of referrals or with
additional attribute pointers).
4.5. Namespace Aliases
FIRS allows entries to alias for other entries through the use of FIRS allows entries to alias for other entries through the use of
referrals. Referrals represent one of the strongest capabilities referrals. Referrals represent one of the strongest capabilities
Hall I-D Expires: March 2004 [page 10]
of the FIRS architecture, in that they allow for a significant of the FIRS architecture, in that they allow for a significant
variety of cross-referencing among entries. For example, referrals variety of cross-referencing among entries.
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), with that entry only existing as a referral for a
resource which is managed in another partition (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 example, a referral can be used to create a placeholder entry
for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which for specific resources (such as a web server), with that entry
only existing as a referral for a resource which is managed in
another partition (such as a web-hosting server at an ISP). This
concept is illustrated in Figure 1, which shows an entry for
"cn=www.example.com,cn=inetResources,dc=example,dc=com" that
provides a referral with the inetDnsDomainMatch matching filter
value of "cn=www-1.example.net", which would result in an entirely
new query for that intDnsDomain entry being started (including new
lookups for the authoritative partition, and so forth).
Hall I-D Expires: February 2004 [page 9] Referrals can also be created as subordinate entries underneath a
provides a referral to the "cn=host.example.net" entry at canonical entry. In that model, any data for the local resource
"cn=inetResources,dc=example,dc=net". Queries for the local entry would be returned, and would also be accompanied by a referral to
would be answered with the locally-available information and then another entry on another server, where additional information
redirected to the referral target where additional information about the named resource could be retrieved.
could be retrieved.
FIRS supports two different kinds of referrals, which are FIRS supports two different kinds of LDAP referrals, which are
subordinate reference referrals and continuation reference subordinate reference referrals and continuation reference
referrals. Subordinate reference referrals indicate that the referrals. Subordinate reference referrals indicate that the
search base used in the query only exists as an alias to another search base used in the query only exists as an alias to another
partition or entry, meaning that the entire query must be partition or entry, meaning that the entire query must be
restarted in order for any answer data to be retrieved. Meanwhile, restarted in order for any answer data to be retrieved. Meanwhile,
continuation reference referrals indicate that some answer data is continuation reference referrals indicate that some answer data is
available, but that more information is available at some other available, but that more information is available at some other
location, and that the client should start new queries in order to location, and that the client should start new queries in order to
retrieve all of the information. retrieve all of the information.
Referrals are provided as URLs. FIRS specifically requires the use Referrals are provided as URLs. FIRS specifically requires the use
of LDAP URLs in order to ensure predictable automated processing. of LDAP URLs in order to ensure predictable automated processing.
Refer to section 6.4.1 for a brief discussion on how these URLs Refer to section 6.4.1 for a brief discussion on how these URLs
are processed by FIRS clients. are processed by FIRS clients.
4.5. Partition Replicas 4.6. Partition Replicas
All directory partitions which provide data for global Internet All directory partitions which provide data for global Internet
resources SHOULD be replicated across two or more servers. Each of resources SHOULD be replicated across two or more servers. Each of
the authoritative LDAP servers for the managed resource MUST be the authoritative LDAP servers for the managed resource MUST be
specified with a unique DNS SRV resource record. specified with a unique DNS SRV resource record.
Directory partitions which serve multiple organizations SHOULD Directory partitions which serve multiple organizations SHOULD
also be replicated. For example, an ISP which provides FIRS also be replicated. For example, an ISP which provides FIRS
services for their customers SHOULD also follow these same rules, services for their customers SHOULD also follow these same rules,
Hall I-D Expires: March 2004 [page 11]
since outages of those servers will affect multiple parties. Leaf- since outages of those servers will affect multiple parties. Leaf-
node directory partitions associated with user-managed resources node directory partitions associated with user-managed resources
MAY replicate their partitions, but are not required to do so. MAY replicate their partitions, but are not required to do so.
Note that the most effective replication strategy will be for Note that the most effective replication strategy will be for
entities to replicate their directory partitions with their entities to replicate their directory partitions with their
delegation parents, as this will allow queries for those resources delegation parents, as this will allow queries for those resources
to be processed by the parent servers (thereby eliminating the to be processed by the parent servers (thereby eliminating the
need for an immediate referral). In many cases, this will not be need for an immediate referral). In many cases, this will not be
feasible (the servers for the "dc=com" directory partition cannot feasible (the servers for the "dc=com" directory partition cannot
be expected to host replicas of every subordinate directory be expected to host replicas of every subordinate directory
partition), but it is encouraged where practical. partition), but it is encouraged where practical.
Hall I-D Expires: February 2004 [page 10]
It is also expected that certain servers will be configured to It is also expected that certain servers will be configured to
serve as multi-replica masters, effectively acting as large-scale serve as multi-replica masters, effectively acting as large-scale
caching servers for many different resources. When used in caching servers for many different resources. When used in
conjunction with the targeted bootstrap model described in section conjunction with the targeted bootstrap model described in section
6.4.1, this will allow clients to retrieve a significant amount of 6.4.1, this will allow clients to retrieve a significant amount of
information without having to pursue a large number of referrals information without having to pursue a large number of referrals
or redirects. This usage is expected and endorsed. or redirects. This usage is expected and endorsed.
Note that the LDAP specifications do not currently provide cache Note that the LDAP specifications do not currently provide cache
timers or any other mechanisms which can indicate how accurate or timers or any other mechanisms which can indicate how accurate or
skipping to change at line 483 skipping to change at line 544
unreachable. unreachable.
5. FIRS Schema Definitions 5. FIRS Schema Definitions
Another critical aspect of FIRS is the use of well-known schema, Another critical aspect of FIRS is the use of well-known schema,
including object classes, attributes, syntaxes and matching including object classes, attributes, syntaxes and matching
filters. Some of the schema definitions are for the global FIRS filters. Some of the schema definitions are for the global FIRS
service and are usable by all entries (including resource-specific service and are usable by all entries (including resource-specific
entries), while others are specific to particular resource-types. entries), while others are specific to particular resource-types.
Hall I-D Expires: March 2004 [page 12]
For new services, pre-existing schema definitions SHOULD be reused For new services, pre-existing schema definitions SHOULD be reused
if they are suitable, since this facilitates integration with if they are suitable, since this facilitates integration with
other LDAP applications. other LDAP applications.
5.1. Global Schema 5.1. Global Schema
There are three global schema definitions which can be used by any There are three global schema definitions which can be used by any
of the entries within FIRS. These include: of the entries within FIRS. These include:
* The "inetResources" master schema. All FIRS-related entries * The "inetResources" master schema. All FIRS-related entries
(including the inetResources container entry and all of the (including the inetResources container entry and all of the
resource-specific subordinate entries) MUST use the resource-specific subordinate entries) MUST use the
inetResources structural object class and schema inetResources structural object class and schema
definitions defined in [FIRS-CORE]. The inetResources definitions defined in [FIRS-CORE]. The inetResources
Hall I-D Expires: February 2004 [page 11]
object class defines a variety of general-purpose object class defines a variety of general-purpose
attributes which are useful for general information about attributes which are useful for general information about
an organization and its resources. an organization and its resources.
* Associated resources. All FIRS-related entries MAY use the * Associated resources. All FIRS-related entries MAY use the
"inetAssociatedResources" auxiliary object class and schema "inetAssociatedResources" auxiliary object class and schema
definitions defined in [FIRS-CORE]. This object class definitions defined in [FIRS-CORE]. This object class
provides cross-reference pointer attributes which allow an provides cross-reference pointer attributes which allow an
entry to reference other resources which may be of interest entry to reference other resources which may be of interest
to other users or applications. to other users or applications.
skipping to change at line 531 skipping to change at line 591
class defined. Meanwhile, each of the resource-specific entries in class defined. Meanwhile, each of the resource-specific entries in
that example also have their own resource-specific object classes, that example also have their own resource-specific object classes,
while the "cn=www.example.com" resource-specific entry also has while the "cn=www.example.com" resource-specific entry also has
the referral object class defined. the referral object class defined.
5.1.1. The inetResources schema 5.1.1. The inetResources schema
The inetResources object class is intended to provide summary The inetResources object class is intended to provide summary
information about a collection of resources under the control of a information about a collection of resources under the control of a
single organization or management body. Since this object class is single organization or management body. Since this object class is
Hall I-D Expires: March 2004 [page 13]
also inherited by the resource-specific object classes, these also inherited by the resource-specific object classes, these
attributes can be defined at each of the subordinate entries if a attributes can be defined at each of the subordinate entries if a
global set of attribute values is undesirable or unfeasible. global set of attribute values is undesirable or unfeasible.
Since multiple directory partitions can use subordinate reference Since multiple directory partitions can use subordinate reference
referrals to share a single common inetResources entry, it is referrals to share a single common inetResources entry, it is
important for the data to be applicable to all of the entries 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 which refer to it. For example, it would be effective for a small
private company to use a shared set of inetResources attributes private company to use a shared set of inetResources attributes
for their DNS domain names and IP network blocks, but it would for their DNS domain names and IP network blocks, but it would
probably be counter-productive for a global ISP to share contact probably be counter-productive for a global ISP to share contact
data across all of their hosted domains and routed networks. If data across all of their hosted domains and routed networks. If
separate contacts are required for each resource, the contact data separate contacts are required for each resource, the contact data
Hall I-D Expires: February 2004 [page 12]
should be specified within each entry, rather than being linked to should be specified within each entry, rather than being linked to
the inetResources entry. the inetResources entry.
The inetResources object class provides several multi-valued The inetResources object class provides several multi-valued
contact-related attributes for a variety of well-known contact-related attributes for a variety of well-known
administrative roles. This model allows the inetResources entry administrative roles. This model allows the inetResources entry
and each of the subordinate managed resources to share a common and each of the subordinate managed resources to share a common
set of administrative roles, or to have unique roles for each set of administrative roles, or to have unique roles for each
resource, as seen fit by the managing entity. resource, as seen fit by the managing entity.
skipping to change at line 579 skipping to change at line 639
The referral object class is used to redirect queries to other The referral object class is used to redirect queries to other
entries programmatically. This object class and its associated entries programmatically. This object class and its associated
schema and rules provide the backbone of the aliasing mechanisms schema and rules provide the backbone of the aliasing mechanisms
discussed in section 4.4. discussed in section 4.4.
5.2. Resource-Specific Schema 5.2. Resource-Specific Schema
In addition to the global schema definitions, each of the In addition to the global schema definitions, each of the
resource-specific entries in FIRS MUST use the resource-specific resource-specific entries in FIRS MUST use the resource-specific
schema definitions defined for use with that specific resource schema definitions defined for use with that specific resource
Hall I-D Expires: March 2004 [page 14]
type. These object classes are defined in the specifications which type. These object classes are defined in the specifications which
govern the different resource-types. These include: govern the different resource-types. These include:
* DNS domains. Every domain name resource entry MUST use the * DNS domains. Every domain name resource entry MUST use the
inetDnsDomain object class and schema definitions defined inetDnsDomain object class and schema definitions defined
in [FIRS-DNS]. These entries can refer to zone delegations, in [FIRS-DNS]. These entries can refer to zone delegations,
host-specific entries, reverse-lookup pointer entries, or host-specific entries, reverse-lookup pointer entries, or
any other domain name. any other domain name.
* DNS resource-records. Any domain name resource MAY use the * DNS resource-records. Any domain name resource MAY use the
inetDnsRR object class and schema definitions defined in inetDnsRR object class and schema definitions defined in
[FIRS-DNSRR]. The inetDnsRR object class defines a single [FIRS-DNSRR]. The inetDnsRR object class defines a single
Hall I-D Expires: February 2004 [page 13]
optional attribute for storing multiple DNS resource optional attribute for storing multiple DNS resource
records as supplemental data to a domain name entry. records as supplemental data to a domain name entry.
* IPv4 address blocks. Every IPv4 address block resource MUST * IPv4 address blocks. Every IPv4 address block resource MUST
use the inetIpv4Network object class and schema definitions use the inetIpv4Network object class and schema definitions
defined in [FIRS-IPV4]. Entries can refer to entire defined in [FIRS-IPV4]. Entries can refer to entire
networks or to single hosts, as needed. networks or to single hosts, as needed.
* IPv6 address blocks. Every IPv6 address block resource MUST * IPv6 address blocks. Every IPv6 address block resource MUST
use the inetIpv6Network object class and schema definitions use the inetIpv6Network object class and schema definitions
skipping to change at line 626 skipping to change at line 686
additional (related) resources. additional (related) resources.
6. Query Processing Behaviors 6. Query Processing Behaviors
Another critical aspect to FIRS is the query-processing behavioral Another critical aspect to FIRS is the query-processing behavioral
rules which govern the ways in which a client parses an input rules which govern the ways in which a client parses an input
string, locates a server which is authoritative for the resource string, locates a server which is authoritative for the resource
being queried, generates LDAPv3 queries, and processes the being queried, generates LDAPv3 queries, and processes the
resulting answer data. More specifically: resulting answer data. More specifically:
Hall I-D Expires: March 2004 [page 15]
* Query pre-processing. Portions of this process require the * Query pre-processing. Portions of this process require the
client to determine the type of resource being queried for, client to determine the type of resource being queried for,
and to determine the initial partition which should be used and to determine the initial partition which should be used
for the query. Since this process is different for each for the query. Since this process is different for each
particular resource-type, the rules which govern this particular resource-type, the rules which govern this
behavior are defined in each of the resource-specific behavior are defined in each of the resource-specific
specifications. specifications.
* Bootstrap processing. Once a resource-type and partition * Bootstrap processing. Once a resource-type and partition
have been determined, the client must locate the LDAP have been determined, the client must locate the LDAP
servers which are authoritative for that partition. [FIRS- servers which are authoritative for that partition. [FIRS-
CORE] defines three different bootstrap models that clients CORE] defines three different bootstrap models that clients
can use as part of this process, while each of the can use as part of this process, while each of the
Hall I-D Expires: February 2004 [page 14]
resource-specific specifications define which of the models resource-specific specifications define which of the models
are to be used for each particular resource-type. are to be used for each particular resource-type.
* Query processing. Once a server has been located, the * Query processing. Once a server has been located, the
client must submit the LDAP query which was formed during client must submit the LDAP query which was formed during
the pre-preprocessing phase. [FIRS-CORE] defines certain the pre-preprocessing phase. [FIRS-CORE] defines certain
LDAPv3 query parameters which all FIRS clients MUST conform LDAPv3 query parameters which all FIRS clients MUST conform
with, while the resource-specific specifications define with, while the resource-specific specifications define
resource-specific matching rules. resource-specific matching rules.
skipping to change at line 674 skipping to change at line 733
("admins@example.com"), and this single piece of information must ("admins@example.com"), and this single piece of information must
be used to subsequently build a fully-formed LDAPv3 query, be used to subsequently build a fully-formed LDAPv3 query,
including the assertion value, the search base, the matching including the assertion value, the search base, the matching
filter, and so forth. All of these steps are part of the pre- filter, and so forth. All of these steps are part of the pre-
processing phase. processing phase.
Although the exact sequence of steps will vary according to the Although the exact sequence of steps will vary according to the
resource-type being queried, there are some commonalities between resource-type being queried, there are some commonalities between
each of them. Among these steps: each of them. Among these steps:
Hall I-D Expires: March 2004 [page 16]
* Determine the resource type. Different kinds of resources * Determine the resource type. Different kinds of resources
have different processing steps, validation mechanisms, and have different processing steps, validation mechanisms, and
so forth, each of which require that the resource-type be so forth, each of which require that the resource-type be
appropriately identified. Clients MAY use any mechanisms appropriately identified. Clients MAY use any mechanisms
necessary to force this determination. necessary to force this determination.
* Validate and normalize the data. In all cases, the input * Validate and normalize the data. In all cases, the input
data MUST be validated and normalized according to the data MUST be validated and normalized according to the
syntax rules defined in the specification which governs the syntax rules defined in the specification which governs the
resource-type. As an example of this step, queries for resource-type. As an example of this step, queries for
internationalized domain names must be validated and internationalized domain names must be validated and
normalized into a canonical UTF-8 [RFC2279] form before any normalized into a canonical UTF-8 [RFC2279] form before any
other steps can be taken. Similarly, IP addresses are other steps can be taken. Similarly, IP addresses are
Hall I-D Expires: February 2004 [page 15]
required to conform to specific syntax rules, with the required to conform to specific syntax rules, with the
input address possibly being expanded or compressed so as input address possibly being expanded or compressed so as
to comply with the syntax requirements. to comply with the syntax requirements.
* Determine the authoritative directory partition for the * Determine the authoritative directory partition for the
named resource. In most cases, the authoritative partition named resource. In most cases, the authoritative partition
will be a variation of the input query string, but this is will be a variation of the input query string, but this is
not always the case. For example, the default partition for not always the case. For example, the default partition for
an email address will be extrapolated from the domain an email address will be extrapolated from the domain
component of the email address itself, while the component of the email address itself, while the
skipping to change at line 722 skipping to change at line 780
during subsequent query-processing steps. during subsequent query-processing steps.
* Determine the assertion value for the query. The assertion * Determine the assertion value for the query. The assertion
value will usually be the normalized form of the input value will usually be the normalized form of the input
query. In some cases, the assertion value may change during query. In some cases, the assertion value may change during
subsequent query-processing steps. subsequent query-processing steps.
* Determine the matching filter. Each resource-type has its * Determine the matching filter. Each resource-type has its
own matching filter rules. For example, contact entries are own matching filter rules. For example, contact entries are
matched with a simple equalityMatch comparison, while in matched with a simple equalityMatch comparison, while in
Hall I-D Expires: March 2004 [page 17]
other cases the matching filter will be an extensibleMatch other cases the matching filter will be an extensibleMatch
which is peculiar to the resource-type in use. which is peculiar to the resource-type in use.
Once all of the pre-processing steps have been successfully Once all of the pre-processing steps have been successfully
completed, the client will have to locate an LDAPv3 server which completed, the client will have to locate an LDAPv3 server which
is authoritative for the search base before it can submit the is authoritative for the search base before it can submit the
query. This process is described in section 6.2 below. query. This process is described in section 6.2 below.
6.2. Bootstrap Processing 6.2. Bootstrap Processing
The bootstrap process uses DNS queries to locate the LDAP servers The bootstrap process uses DNS queries to locate the LDAP servers
which should be used for a query. However, since different kinds which should be used for a query. However, since different kinds
of resources are managed through different delegation models, of resources are managed through different delegation models,
Hall I-D Expires: February 2004 [page 16]
there are also different bootstrap models which have to be used to there are also different bootstrap models which have to be used to
perform this process. perform this process.
FIRS supports three different bootstrap models, which are: FIRS supports three different bootstrap models, which are:
* Targeted. The "targeted" bootstrap model has the client * Targeted. The "targeted" bootstrap model has the client
attempting to locate the LDAP servers associated with a attempting to locate the LDAP servers associated with a
specific domain name, such as a domain name which may be specific domain name, such as a domain name which may be
returned as referrals or URLs. If no servers can be found returned as referrals or URLs. If no servers can be found
at that domain name, the client exits the query. at that domain name, the client exits the query.
skipping to change at line 770 skipping to change at line 828
DNS queries are issued, with this process repeating until a DNS queries are issued, with this process repeating until a
server is found or there are no more domains in the server is found or there are no more domains in the
delegation path which can be queried. delegation path which can be queried.
Each of the models are appropriate to different usages. For Each of the models are appropriate to different usages. For
example, The targeted model is most useful when a particular piece example, The targeted model is most useful when a particular piece
of data is presumed to exist at a pre-determined location. of data is presumed to exist at a pre-determined location.
Meanwhile, the top-down model is best suited for searches about Meanwhile, the top-down model is best suited for searches about
global resources which are centrally managed and delegated (such global resources which are centrally managed and delegated (such
as IP addresses and DNS domains), and where centrally-managed as IP addresses and DNS domains), and where centrally-managed
Hall I-D Expires: March 2004 [page 18]
delegation information is critical. Finally, the bottom-up model delegation information is critical. Finally, the bottom-up model
is most appropriate for resources which are managed at a leaf-node is most appropriate for resources which are managed at a leaf-node
(such as contact information). (such as contact information).
6.3. Query Processing 6.3. Query Processing
Once an LDAP server has been located, the LDAPv3 query is Once an LDAP server has been located, the LDAPv3 query is
submitted to that server. submitted to that server.
Most of the values for the query will have been collected during Most of the values for the query will have been collected during
the pre-processing phase, although [FIRS-CORE] defines some rules the pre-processing phase, although [FIRS-CORE] defines some rules
which govern all queries. For example, [FIRS-CORE] specifies a which govern all queries. For example, [FIRS-CORE] specifies a
maximum time limit of 60 seconds for queries (among other similar maximum time limit of 60 seconds for queries (among other similar
Hall I-D Expires: February 2004 [page 17]
kinds of restrictions) in order to prevent runaway searches which kinds of restrictions) in order to prevent runaway searches which
would otherwise match all entries. would otherwise match all entries.
[FIRS-CORE] also allows for authentication and access controls, in [FIRS-CORE] also allows for authentication and access controls, in
that FIRS servers are allowed to limit the depth and breadth of that FIRS servers are allowed to limit the depth and breadth of
information that they provide to a specific client based on a information that they provide to a specific client based on a
variety of factors, including the level of authenticated access. variety of factors, including the level of authenticated access.
Another consideration which can arise during this phase of the Another consideration which can arise during this phase of the
process is protocol and schema versioning considerations. The process is protocol and schema versioning considerations. The
skipping to change at line 818 skipping to change at line 876
The client MAY also use this information to determine whether or The client MAY also use this information to determine whether or
not it will need to construct its own queries. Since it is not it will need to construct its own queries. Since it is
somewhat likely that a particular server will not support all of somewhat likely that a particular server will not support all of
the mechanisms required by the complete FIRS model (especially the mechanisms required by the complete FIRS model (especially
including all of the extended matching filters), then the client including all of the extended matching filters), then the client
can use this information to determine if it needs to construct its can use this information to determine if it needs to construct its
own extended queries locally. Refer to the resource-specific own extended queries locally. Refer to the resource-specific
documents for more information on this process. documents for more information on this process.
Hall I-D Expires: March 2004 [page 19]
6.4. Query Post-Processing 6.4. Query Post-Processing
Once a query has been submitted and processed, the server will Once a query has been submitted and processed, the server will
return answer data or some kind of referral, or possibly both. In return answer data or some kind of referral, or possibly both. In
general, FIRS clients are expected to display all of the answer general, FIRS clients are expected to display all of the answer
data and process all of the referrals, although there are specific data and process all of the referrals, although there are specific
considerations which must be taken into account. In particular, considerations which must be taken into account. In particular,
there are considerations for handling the different kinds of there are considerations for handling the different kinds of
referrals, and there are localizations issues for specific kinds referrals, and there are localizations issues for specific kinds
of attribute data. of attribute data.
Hall I-D Expires: February 2004 [page 18]
6.4.1. Referrals 6.4.1. Referrals
As was discussed in section 4.4, there are two kinds of referral As was discussed in section 4.4, there are two kinds of referral
mechanisms which are used with FIRS, which are subordinate mechanisms which are used with FIRS, which are subordinate
reference referrals and continuation reference referrals. More reference referrals and continuation reference referrals. More
specifically: specifically:
* Subordinate reference referrals. Subordinate reference * Subordinate reference referrals. Subordinate reference
referrals are returned when the search base specified in a referrals are returned when the search base specified in a
query exists as a referral to some other entry. This query exists as a referral to some other entry. This
skipping to change at line 865 skipping to change at line 923
successfully processed by the queried server, but the successfully processed by the queried server, but the
answer data also includes referrals to other entries. This answer data also includes referrals to other entries. This
condition means that the current search operation has condition means that the current search operation has
succeeded, but that additional searches SHOULD be started succeeded, but that additional searches SHOULD be started
in order for all of the answer data to be retrieved. in order for all of the answer data to be retrieved.
These referrals are often provided as supplemental data to These referrals are often provided as supplemental data to
an answer set, although this is not required (a an answer set, although this is not required (a
continuation reference referral can be the only response, continuation reference referral can be the only response,
but it won't be the only response in the common case). but it won't be the only response in the common case).
Hall I-D Expires: March 2004 [page 20]
Continuation reference referrals and their schema are also Continuation reference referrals and their schema are also
defined in [RFC3296], with additional restrictions placed defined in [RFC3296], with additional restrictions placed
on their usage as described in [FIRS-CORE]. on their usage as described in [FIRS-CORE].
Whenever a referral is received in response to a query, the client Whenever a referral is received in response to a query, the client
is required to display any answer data which has also been is required to display any answer data which has also been
received and then process the referral. received and then process the referral.
LDAP referrals can use any kind of URL, although FIRS specifically LDAP referrals can use any kind of URL, although FIRS specifically
requires the use of LDAP URLs. The client is required to parse the requires the use of LDAP URLs. The client is required to parse the
Hall I-D Expires: February 2004 [page 19]
resulting URL for a host identifier, port number, search base, and resulting URL for a host identifier, port number, search base, and
assertion value elements, and then use these elements to construct assertion value elements, and then use these elements to construct
and issue new queries. and issue new queries.
Note that [RFC2251] defines a superior reference referral which is Note that [RFC2251] defines a superior reference referral which is
used as a "default referral" for out-of-scope searches. However, used as a "default referral" for out-of-scope searches. However,
FIRS specifically excludes support for superior reference FIRS specifically excludes support for superior reference
referrals. Any superior reference referrals which are encountered referrals. Any superior reference referrals which are encountered
as part of this service are to be treated as errors. as part of this service are to be treated as errors.
skipping to change at line 912 skipping to change at line 970
mapped to domainComponent attributes MUST be reduced to their mapped to domainComponent attributes MUST be reduced to their
ASCII-compatible form using the ToASCII process defined in ASCII-compatible form using the ToASCII process defined in
[RFC3490] before they are used for domainComponent sequences. [RFC3490] before they are used for domainComponent sequences.
Similarly, although DNS is technically capable of storing eight- Similarly, although DNS is technically capable of storing eight-
bit code-point values, the operational rules which govern DNS do bit code-point values, the operational rules which govern DNS do
not support this usage for domain names which are used as host not support this usage for domain names which are used as host
identifiers (and this includes zone delegations). As a result, identifiers (and this includes zone delegations). As a result,
internationalized domain names which are to be used for DNS internationalized domain names which are to be used for DNS
lookups (such as queries for SRV resource records) MUST be reduced lookups (such as queries for SRV resource records) MUST be reduced
Hall I-D Expires: March 2004 [page 21]
to their ASCII-compatible form using the ToASCII process defined to their ASCII-compatible form using the ToASCII process defined
in [RFC3490] before these queries are issued. in [RFC3490] before these queries are issued.
In those cases where entries or attributes use normalized UTF-8 In those cases where entries or attributes use normalized UTF-8
sequences inside of FIRS (specifically domain names and email sequences inside of FIRS (specifically domain names and email
addresses), FIRS clients SHOULD offer ASCII-compatible versions of addresses), FIRS clients SHOULD offer ASCII-compatible versions of
those sequences, using the ToASCII process defined in [RFC3490]. those sequences, using the ToASCII process defined in [RFC3490].
This will ensure that clients are able to use these sequences with This will ensure that clients are able to use these sequences with
legacy (pre-IDNA) applications directly. For example, if an entry legacy (pre-IDNA) applications directly. For example, if an entry
displays an inetAssociatedDomains attribute, the domain names in displays an inetAssociatedDomains attribute, the domain names in
that attribute should be displayed in their default UTF-8 form that attribute should be displayed in their default UTF-8 form
Hall I-D Expires: February 2004 [page 20]
(assuming that the client's operating system and application (assuming that the client's operating system and application
allows it), but should also be made available in their ASCII- allows it), but should also be made available in their ASCII-
compatible form (either as a clipboard option, command-line compatible form (either as a clipboard option, command-line
option, or some other user-selectable switch) in order to allow 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 the data to be passed to a legacy application in a form which is
understandable by the legacy application. understandable by the legacy application.
Attribute names are fixed, and can therefore be localized easily. Attribute names are fixed, and can therefore be localized easily.
As such, clients MAY choose to convert attribute names into a As such, clients MAY choose to convert attribute names into a
language appropriate to the local user for display purposes if language appropriate to the local user for display purposes if
skipping to change at line 960 skipping to change at line 1018
International postal regulations generally require that the International postal regulations generally require that the
recipient address on an envelope be provided in a language and recipient address on an envelope be provided in a language and
charset which is native to the recipient's country, with the charset which is native to the recipient's country, with the
exception of the destination country name which should be provided exception of the destination country name which should be provided
in a language and charset that is native to the sender's country. 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 This model ensures that the sender's post office will be able to
route the mail to the recipient's country, while also ensuring route the mail to the recipient's country, while also ensuring
that the destination country's post office will be able to perform that the destination country's post office will be able to perform
local delivery. In order to facilitate this usage, the country local delivery. In order to facilitate this usage, the country
attribute value SHOULD be localized to the local user's attribute value SHOULD be localized to the local user's
Hall I-D Expires: March 2004 [page 22]
nomenclature for that country, but other postal address data nomenclature for that country, but other postal address data
SHOULD NOT be localized. SHOULD NOT be localized.
Notwithstanding the above, contact names SHOULD be provided in Notwithstanding the above, contact names SHOULD be provided in
English in order to facilitate inter-party communications, using English in order to facilitate inter-party communications, using
the mechanisms offered by [RFC2596]. For example, the default the mechanisms offered by [RFC2596]. For example, the default
contact entry for a person in Japan SHOULD be provided in the contact entry for a person in Japan SHOULD be provided in the
native form for that person, but an English form SHOULD also be native form for that person, but an English form SHOULD also be
provided in order to allow non-Japanese users to properly address provided in order to allow non-Japanese users to properly address
that person in subsequent communications. As stated in the that person in subsequent communications. As stated in the
preceding paragraph however, any postal communications for that preceding paragraph however, any postal communications for that
Hall I-D Expires: February 2004 [page 21]
person SHOULD use the native-language representation (at least on person SHOULD use the native-language representation (at least on
the envelope) in order to facilitate delivery. the envelope) in order to facilitate delivery.
Time and date strings in LDAP use the generalizedTime syntax, Time and date strings in LDAP use the generalizedTime syntax,
making them predictable and easily convertible if necessary. As making them predictable and easily convertible if necessary. As
such, dates MAY be localized for display purposes by client such, dates MAY be localized for display purposes by client
applications as necessary. applications as necessary.
Finally, clients must recognize that some URL data is likely to be Finally, clients must recognize that some URL data is likely to be
escaped, using at least one of the multiple rules which affect escaped, using at least one of the multiple rules which affect
URLs and resource-specific data. For example, a URL which contains URLs and resource-specific data. For example, a URL which contains
a domain name resource could theoretically have been escaped with a domain name resource could theoretically have been escaped with
three or four different syntax rules, and clients MUST be prepared three or four different syntax rules, and clients MUST be prepared
to decode these URLs appropriately. to decode these URLs appropriately.
6.5. Query Restriction Mechanisms
[FIRS-CORE] defines several discrete rules that can be employed by
server operators to limit the queries received from any particular
client. Some of these restrictions include:
* Servers MAY refuse service to any client (5.3.3).
* Servers MAY impose arbitrary maximum limits on the number
of queries issued by any particular client for any given
time period, such as limiting clients to 50 queries-per-day
or five queries-per-hour (5.3.3).
* Servers MAY impose arbitrary wait intervals between
successive queries from any particular client, such as
requiring clients to wait five minutes between queries
(5.3.3).
* Servers MAY impose arbitrary limits on the maximum number
of answers that they will return to a client over any given
Hall I-D Expires: March 2004 [page 23]
time period (such as limiting clients to 100 answers-per-
day), and MAY base this restriction on any type of answer
data (5.3.3).
* Servers MAY restrict the resource-types that any particular
client can query for, and MAY restrict the matching filters
that any particular client can use for any of the resource-
types that they are allowed to query (5.3.1).
* Servers MAY restrict the maximum length of time they spend
processing any particular query (5.3.2).
* Servers MAY restrict the maximum number of matches that
will be returned to any particular query (5.3.2).
* Server operators MAY define ACLs on entries and attributes
in the database that restrict the data that is matched for
any particular client (5.3.4).
Any of these restrictions MAY be defined by the operators of the
server in question, according to the policies deemed necessary by
the operators of that server. For example, operators MAY apply
different restrictions on ranges of client addresses, or
authenticated identity, or any other necessary metric, or any
combination thereof.
7. Transition Issues 7. Transition Issues
There are a handful of areas where FIRS does not fully compare There are a handful of areas where FIRS does not fully compare
with all of the existing WHOIS service offerings. These areas are with all of the existing WHOIS service offerings. These areas are
discussed in more detail below. discussed in more detail below.
7.1. NIC Handles 7.1. NIC Handles
Legacy NIC handles in existing databases can be accommodated using Legacy NIC handles in existing databases can be accommodated using
two possible mechanisms: two possible mechanisms:
* NIC handle output in legacy WHOIS systems may be replaced * NIC handle output in legacy WHOIS systems may be replaced
with email addresses for the contacts, using mail domain with contact identifier addresses, using domain elements
elements which refer to the operator's domain. For example, which refer to the operator's domain. For example, the NIC
the NIC handle of EH26 on Network Solutions' WHOIS server handle of EH26 on Network Solutions' WHOIS server could be
could be replaced with "eh26@firs.netsol.com" or similar. replaced with "eh26@firs.netsol.com" or something similar.
This approach causes lookups for that email address to be This approach causes lookups for that email address to be
directed towards the operator's FIRS servers, and directed towards the operator's FIRS servers, and
facilitates fast coalescence around the FIRS system. facilitates fast coalescence around the FIRS system.
* Use the inetPrivateIdentifier attribute defined in [FIRS- Hall I-D Expires: March 2004 [page 24]
CORE]. This option provides a simple text string which can * Use the inetLocalIdentifier attribute defined in
be used for private identifiers, but provides no [FIRS-CORE]. This option provides a simple text string
which can be used for private identifiers, but provides no
integration with FIRS, other than allowing for attribute integration with FIRS, other than allowing for attribute
value searches. value searches.
Of the two mechanisms described above, the former is preferred. Although both options can be used simultaneously, the former
mechanism is especially preferred.
Hall I-D Expires: February 2004 [page 22]
7.2. Change-Logs 7.2. Change-Logs
Several WHOIS services provide pseudo change-logs in their Several WHOIS services provide pseudo change-logs in their
response data, listing each unique modification event which has response data, listing each unique modification event which has
occurred for a particular resource. For example, RIPE and some of occurred for a particular resource. For example, RIPE and some of
the ccTLDs provide WHOIS output which includes a series of the ccTLDs provide WHOIS output which includes a series of
"changed" fields that itemize every modification event ("updated", "changed" fields that itemize every modification event ("updated",
"added", etc.), the modifier, and the modification date, which "added", etc.), the modifier, and the modification date, which
cumulatively act as a change-log for the resource in question. cumulatively act as a change-log for the resource in question.
skipping to change at line 1054 skipping to change at line 1161
organizations can continue to use and support those systems as-is, organizations can continue to use and support those systems as-is,
without any modifications. However, other organizations may choose without any modifications. However, other organizations may choose
to implement a FIRS client in a text-based application (such as a to implement a FIRS client in a text-based application (such as a
Perl script), with that application accepting typical queries over Perl script), with that application accepting typical queries over
the legacy TCP/43 port, processing those queries through FIRS, and the legacy TCP/43 port, processing those queries through FIRS, and
returning answer data back to the legacy WHOIS client. Another returning answer data back to the legacy WHOIS client. Another
approach is described in draft-newton-whois-crisp-cohabitation- approach is described in draft-newton-whois-crisp-cohabitation-
00.txt, which advocates the use of NAPTR and SRV resource records 00.txt, which advocates the use of NAPTR and SRV resource records
to redirect legacy clients to FIRS servers. to redirect legacy clients to FIRS servers.
Hall I-D Expires: March 2004 [page 25]
A similar range of options are available for back-end database A similar range of options are available for back-end database
integration. Organizations who do not wish to align their back-end integration. Organizations who do not wish to align their back-end
databases to the LDAP/FIRS model can use basic scripts to generate databases to the LDAP/FIRS model can use basic scripts to generate
LDIF files on a suitable schedule, and then populate their LDAP LDIF files on a suitable schedule, and then populate their LDAP
servers with this data. Meanwhile, other organizations may choose servers with this data. Meanwhile, other organizations may choose
to provide an LDAP front-end to an existing database, while other to provide an LDAP front-end to an existing database, while other
organizations may choose to use a single LDAP repository for all organizations may choose to use a single LDAP repository for all
of their applications. of their applications.
Hall I-D Expires: February 2004 [page 23]
In general terms, FIRS does not require or endorse any of these In general terms, FIRS does not require or endorse any of these
mechanisms, and they are only presented here so that operators are mechanisms, and they are only presented here so that operators are
aware of the options. aware of the options.
8. Security Considerations 8. Security Considerations
The FIRS collection of specifications describe an application of The FIRS collection of specifications describe an application of
the LDAPv3 protocol, and as such it inherits the security the LDAPv3 protocol, and as such it inherits the security
considerations associated with LDAPv3, as described in section 7 considerations associated with LDAPv3, as described in section 7
of [RFC2251]. of [RFC2251].
skipping to change at line 1100 skipping to change at line 1207
The query processing models described in these documents make use The query processing models described in these documents make use
of DNS lookups in order to locate the LDAP servers associated with of DNS lookups in order to locate the LDAP servers associated with
a particular resource. DNS is susceptible to certain attacks and a particular resource. DNS is susceptible to certain attacks and
forgeries which may be used to redirect clients to LDAP servers forgeries which may be used to redirect clients to LDAP servers
which are not authoritative for the resource in question. which are not authoritative for the resource in question.
This document provides multiple query models which will cause the This document provides multiple query models which will cause the
same query to be answered by different servers (one would be same query to be answered by different servers (one would be
processed by a delegation entity, while another would be processed processed by a delegation entity, while another would be processed
by an operational entity). As a result, each of the servers may by an operational entity). As a result, each of the servers may
Hall I-D Expires: March 2004 [page 26]
provide different information, depending upon the query type that provide different information, depending upon the query type that
was originally selected. was originally selected.
Some operators may choose to purposefully provide misleading or Some operators may choose to purposefully provide misleading or
erroneous information in an effort to avoid responsibility for bad erroneous information in an effort to avoid responsibility for bad
behavior. In addition, there are likely to be sporadic operator behavior. In addition, there are likely to be sporadic operator
errors which will result in confusing or erroneous answers. errors which will result in confusing or erroneous answers.
Hall I-D Expires: February 2004 [page 24]
Neither this specification nor the LDAPv3 protocol currently Neither this specification nor the LDAPv3 protocol currently
provide cache timers or any other mechanisms which can indicate provide cache timers or any other mechanisms which can indicate
how accurate or timely any replicas may be. As a result, it is how accurate or timely any replicas may be. As a result, it is
possible for a replica to become significantly outdated, even to possible for a replica to become significantly outdated, even to
the point of containing wholesale errors. the point of containing wholesale errors.
For all of the reasons listed above, it is essential that For all of the reasons listed above, it is essential that
applications and end-users not make critical decisions based on applications and end-users not make critical decisions based on
the information provided by the FIRS service without having reason the information provided by the FIRS service without having reason
to believe the veracity of the information. Users should limit to believe the veracity of the information. Users should limit
skipping to change at line 1147 skipping to change at line 1255
access permissions, and MUST NOT have anonymous add, delete access permissions, and MUST NOT have anonymous add, delete
or modify permissions. or modify permissions.
* With the exception of contact-related attributes from the * With the exception of contact-related attributes from the
inetOrgPerson object class, each attribute MAY have inetOrgPerson object class, each attribute MAY have
whatever restrictions are necessary in order to suit local whatever restrictions are necessary in order to suit local
security policies, government regulations or personal security policies, government regulations or personal
privacy concerns. When the inetOrgPerson object class is privacy concerns. When the inetOrgPerson object class is
used to provide contact details, the mail attribute MUST be used to provide contact details, the mail attribute MUST be
defined, SHOULD be valid, SHOULD have anonymous read-only defined, SHOULD be valid, SHOULD have anonymous read-only
Hall I-D Expires: March 2004 [page 27]
access, and MUST NOT have anonymous add, delete or modify access, and MUST NOT have anonymous add, delete or modify
permissions. permissions.
By using the inetOrgPerson object class, it is expected By using the inetOrgPerson object class, it is expected
that existing contact-related entries can be reused. If that existing contact-related entries can be reused. If
reusing these entries is undesirable or unfeasible, entries reusing these entries is undesirable or unfeasible, entries
with the necessary access SHOULD be made available. with the necessary access SHOULD be made available.
Hall I-D Expires: February 2004 [page 25]
* End-users and implementers SHOULD provide anonymous access * End-users and implementers SHOULD provide anonymous access
to the creatorsName, createTimestamp, modifiersName and to the creatorsName, createTimestamp, modifiersName and
modifyTimestamp operational attributes associated with each modifyTimestamp operational attributes associated with each
entry in the inetResources branch, since this information entry in the inetResources branch, since this information
is useful for determining the age of the underlying data. is useful for determining the age of the underlying data.
* Server operators MAY define additional add, delete or * Server operators MAY define additional add, delete or
modify permissions for authenticated users, using any modify permissions for authenticated users, using any
LDAPv3 authentication mechanisms they wish. In particular, LDAPv3 authentication mechanisms they wish. In particular,
delegation entities MAY provide for the remote management delegation entities MAY provide for the remote management
skipping to change at line 1193 skipping to change at line 1302
The FIRS collection of specifications define an application of the The FIRS collection of specifications define an application of the
LDAPv3 protocol rather than a new Internet application protocol. LDAPv3 protocol rather than a new Internet application protocol.
As such, there are no protocol-related IANA considerations. As such, there are no protocol-related IANA considerations.
However, the FIRS collection of specifications do define several However, the FIRS collection of specifications do define several
LDAP schema elements, including object classes, attributes, LDAP schema elements, including object classes, attributes,
syntaxes and extensibleMatch filters, and these elements should be syntaxes and extensibleMatch filters, and these elements should be
assigned OID values from the IANA branch. Furthermore, some of the assigned OID values from the IANA branch. Furthermore, some of the
specifications define their own status codes as attribute values, specifications define their own status codes as attribute values,
Hall I-D Expires: March 2004 [page 28]
and IANA is expected to maintain the code-point mapping values and IANA is expected to maintain the code-point mapping values
associated with these attributes. associated with these attributes.
Finally, some of the specifications also describe public DNS and Finally, some of the specifications also describe public DNS and
LDAP servers and data. It is expected that IANA will see to the LDAP servers and data. It is expected that IANA will see to the
establishment and maintenance of these servers and data. establishment and maintenance of these servers and data.
Hall I-D Expires: February 2004 [page 26]
10. Normative References 10. Normative References
[CRISP-REQ] Newton, A. "Cross Registry Internet Service [CRISP-REQ] Newton, A. "Cross Registry Internet Service
Protocol (CRISP) Requirements", draft-ietf- Protocol (CRISP) Requirements", draft-ietf-
crisp-requirements-05, July 2003. crisp-requirements-05, July 2003.
[FIRS-ARCH] Hall, E. "The Federated Internet Registry
Service: Architecture and Implementation
Guide", draft-ietf-crisp-firs-arch-02, July
2003.
[FIRS-ASN] Hall, E. "Defining and Locating Autonomous [FIRS-ASN] Hall, E. "Defining and Locating Autonomous
System Numbers in the Federated Internet System Numbers in the Federated Internet
Registry Service", draft-ietf-crisp-firs-asn- Registry Service", draft-ietf-crisp-firs-asn-
02, July 2003. 03, August 2003.
[FIRS-CONTCT] Hall, E. "Defining and Locating Contact [FIRS-CONTCT] Hall, E. "Defining and Locating Contact
Persons in the Federated Internet Registry Persons in the Federated Internet Registry
Service", draft-ietf-crisp-firs-contact-02, Service", draft-ietf-crisp-firs-contact-03,
July 2003. August 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry [FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp- Service: Core Elements", draft-ietf-crisp-
firs-core-02, July 2003. firs-core-03, August 2003.
[FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in [FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in
the Federated Internet Registry Service", the Federated Internet Registry Service",
draft-ietf-crisp-firs-dns-02, July 2003. draft-ietf-crisp-firs-dns-03, August 2003.
[FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource [FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource
Records in the Federated Internet Registry Records in the Federated Internet Registry
Service", draft-ietf-crisp-firs-dnsrr-02, July Service", draft-ietf-crisp-firs-dnsrr-02, July
2003. 2003.
[FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address [FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address
Blocks in the Federated Internet Registry Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv4-02, July Service", draft-ietf-crisp-firs-ipv4-02,
2003. August 2003.
[FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address [FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address
Blocks in the Federated Internet Registry Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv6-02, July Service", draft-ietf-crisp-firs-ipv6-02,
2003. August 2003.
[ISO10646] "ISO/IEC 10646-1:2000. International Standard [ISO10646] "ISO/IEC 10646-1:2000. International Standard
-- Information technology -- Universal -- Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Multiple-Octet Coded Character Set (UCS) --
Hall I-D Expires: March 2004 [page 29]
Part 1: Architecture and Basic Multilingual Part 1: Architecture and Basic Multilingual
Plane" Plane"
Hall I-D Expires: February 2004 [page 27]
[RFC2079] Smith, M. "Definition of an X.500 Attribute [RFC2079] Smith, M. "Definition of an X.500 Attribute
Type and an Object Class to Hold Uniform Type and an Object Class to Hold Uniform
Resource Identifiers (URIs)", RFC 2079, Resource Identifiers (URIs)", RFC 2079,
January 1997. January 1997.
[RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R.,
and Sataluri, S. "Using Domains in LDAP/X.500 and Sataluri, S. "Using Domains in LDAP/X.500
DNs", RFC 2247, January 1998. DNs", RFC 2247, January 1998.
[RFC2251] Wahl, M., Howes, T., and Kille, S. [RFC2251] Wahl, M., Howes, T., and Kille, S.
skipping to change at line 1299 skipping to change at line 1405
[RFC2279] Yergeau, F. "UTF-8, a transformation format of [RFC2279] Yergeau, F. "UTF-8, a transformation format of
ISO 10646", RFC 2279, January 1998. ISO 10646", RFC 2279, January 1998.
[RFC2596] Wahl, M., and Howes, T. "Use of Language Codes [RFC2596] Wahl, M., and Howes, T. "Use of Language Codes
in LDAP", RFC 2596, May 1999. in LDAP", RFC 2596, May 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A [RFC2782] Gulbrandsen, A., Vixie, P., and Esibov, L. "A
DNS RR for specifying the location of services DNS RR for specifying the location of services
(DNS SRV)", RFC 2782, February 2000. (DNS SRV)", RFC 2782, February 2000.
Hall I-D Expires: March 2004 [page 30]
[RFC2798] Smith, M. "Definition of the inetOrgPerson [RFC2798] Smith, M. "Definition of the inetOrgPerson
LDAP Object Class", RFC 2798, April 2000. LDAP Object Class", RFC 2798, April 2000.
Hall I-D Expires: February 2004 [page 28]
[RFC3296] Zeilenga, K. "Named Subordinate References in [RFC3296] Zeilenga, K. "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP) Lightweight Directory Access Protocol (LDAP)
Directories", RFC 3296, July 2002. Directories", RFC 3296, July 2002.
[RFC3377] Hodges, J., and Morgan, R. "Lightweight [RFC3377] Hodges, J., and Morgan, R. "Lightweight
Directory Access Protocol (v3): Technical Directory Access Protocol (v3): Technical
Specification", RFC 3377, September 2002. Specification", RFC 3377, September 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and Costello, A. [RFC3490] Faltstrom, P., Hoffman, P., and Costello, A.
"Internationalizing Domain Names in "Internationalizing Domain Names in
skipping to change at line 1325 skipping to change at line 1431
[US-ASCII] Cerf, V. "ASCII format for Network [US-ASCII] Cerf, V. "ASCII format for Network
Interchange", RFC 20, October 1969. Interchange", RFC 20, October 1969.
11. Informational References 11. Informational References
[RFC812] Harrenstien, K., and White, V. [RFC812] Harrenstien, K., and White, V.
"NICNAME/WHOIS", RFC 812, March 1982. "NICNAME/WHOIS", RFC 812, March 1982.
12. Changes from Previous Versions 12. Changes from Previous Versions
draft-ietf-crisp-firs-arch-03:
* Several clarifications and corrections have been made.
* Added a discussion on the various query-restriction
mechanisms that are available in the system as a whole.
* Clarified the use of referrals and added a discussion on
attribute references.
draft-ietf-crisp-firs-arch-02: draft-ietf-crisp-firs-arch-02:
* Several clarifications and corrections have been made. * Several clarifications and corrections have been made.
draft-ietf-crisp-firs-arch-01: draft-ietf-crisp-firs-arch-01:
* Several clarifications and corrections have been made. * Several clarifications and corrections have been made.
draft-ietf-crisp-firs-arch-00: draft-ietf-crisp-firs-arch-00:
* Restructured document set, separating the architectural * Restructured document set, separating the architectural
discussion from the technical descriptions. discussion from the technical descriptions.
Hall I-D Expires: March 2004 [page 31]
* Consolidated the security discussions. * Consolidated the security discussions.
draft-ietf-crisp-lw-core-00: draft-ietf-crisp-lw-core-00:
* As a result of the formation of the CRISP working group, * As a result of the formation of the CRISP working group,
the original monolithic document has been broken into the original monolithic document has been broken into
multiple documents, with draft-ietf-crisp-lw-core multiple documents, with draft-ietf-crisp-lw-core
describing the core service, while related documents describing the core service, while related documents
describe the per-resource schema and access mechanisms. describe the per-resource schema and access mechanisms.
* References to the ldaps: URL scheme have been removed, * References to the ldaps: URL scheme have been removed,
since there is no standards-track specification for the since there is no standards-track specification for the
ldaps: scheme. ldaps: scheme.
Hall I-D Expires: February 2004 [page 29]
* An acknowledgements section was added. * An acknowledgements section was added.
draft-hall-ldap-whois-01: draft-hall-ldap-whois-01:
* The "Objectives" section has been removed. [ir-dir-req] is * The "Objectives" section has been removed. [ir-dir-req] is
now being used as the guiding document for this service. now being used as the guiding document for this service.
* Several typographical errors have been fixed. * Several typographical errors have been fixed.
* Some unnecessary text has been removed. * Some unnecessary text has been removed.
skipping to change at line 1384 skipping to change at line 1500
all referrals. all referrals.
* The delegation status codes used by the * The delegation status codes used by the
inetDnsDelegationStatus, inetIpv4DelegationStatus, inetDnsDelegationStatus, inetIpv4DelegationStatus,
inetIpv6DelegationStatus and inetAsnDelegationStatus inetIpv6DelegationStatus and inetAsnDelegationStatus
attributes have been condensed to a more logical set. attributes have been condensed to a more logical set.
* Added an inetDnsAuthServers attribute for publishing the * Added an inetDnsAuthServers attribute for publishing the
authoritative DNS servers associated with a domain. NOTE authoritative DNS servers associated with a domain. NOTE
THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE THAT THIS IS A TEMPORARY ATTRIBUTE THAT WILL EVENTUALLY BE
Hall I-D Expires: March 2004 [page 32]
REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND REPLACED BY GENERALIZED RESOURCE-RECORD ENTRIES AND
ATTRIBUTES. ATTRIBUTES.
* Added an inetGeneralDisclaimer attribute for publishing * Added an inetGeneralDisclaimer attribute for publishing
generalized disclaimers. generalized disclaimers.
* Added the inetAssociatedResources auxiliary object class * Added the inetAssociatedResources auxiliary object class
for defining associated resources, and moved some of the IP for defining associated resources, and moved some of the IP
addressing and ASN attributes to the new object class. addressing and ASN attributes to the new object class.
* Several attributes had their OIDs changed. NOTE THAT THIS * Several attributes had their OIDs changed. NOTE THAT THIS
IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO IS AN INTERNET DRAFT, AND THAT THE OIDS ARE SUBJECT TO
ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED. ADDITIONAL CHANGES AS THIS DOCUMENT IS EDITED.
Hall I-D Expires: February 2004 [page 30]
13. Author's Address 13. Author's Address
Eric A. Hall Eric A. Hall
ehall@ehsco.com ehall@ehsco.com
14. Acknowledgments 14. Acknowledgments
Funding for the RFC editor function is currently provided by the Funding for the RFC editor function is currently provided by the
Internet Society. Internet Society.
skipping to change at line 1431 skipping to change at line 1548
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the for the purpose of developing Internet standards in which case the
Hall I-D Expires: March 2004 [page 33]
procedures for copyrights defined in the Internet Standards procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into process must be followed, or as required to translate it into
languages other than English. languages other than English.
The limited permissions granted above are perpetual and will not The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns. be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hall I-D Expires: February 2004 [page 31] Hall I-D Expires: March 2004 [page 34]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/