draft-ietf-crisp-firs-arch-00.txt   draft-ietf-crisp-firs-arch-01.txt 
INTERNET-DRAFT Eric A. Hall INTERNET-DRAFT Eric A. Hall
Document: draft-ietf-crisp-firs-arch-00.txt May 2003 Document: draft-ietf-crisp-firs-arch-01.txt May 2003
Expires: December, 2003 Expires: December, 2003
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 45 skipping to change at line 45
Abstract Abstract
This document describes the architectural framework for the This document describes the architectural framework for the
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..............................................2 1. Introduction...............................................2
1.1. Background.............................................3 1.1. Background..............................................3
1.2. Overview...............................................4 1.2. Overview................................................4
2. Prerequisites and Terminology.............................5 2. Prerequisites and Terminology..............................5
2.1. Reference Example......................................6 3. Reference Example..........................................6
3. The FIRS Namespace........................................8 4. The FIRS Namespace.........................................8
3.1. The domainComponent Hierarchy..........................8 4.1. The domainComponent Hierarchy...........................8
3.2. The inetResources Container............................9 4.2. The inetResources Container.............................9
3.3. Resource-Specific Entries..............................9 4.3. Resource-Specific Entries..............................10
3.4. Namespace Aliases.....................................10 4.4. Namespace Aliases......................................10
4. FIRS Schema Definitions..................................11 4.5. Partition Replicas.....................................11
4.1. Global Schema Definitions.............................11 5. FIRS Schema Definitions...................................12
4.2. Resource-Specific Schema Definitions..................12 5.1. Global Schema..........................................12
5. Query Processing Behaviors...............................13 5.1.1. The inetResources schema.........................13
5.1. Query Pre-Processing..................................13 5.1.2. The inetAssociatedResources schema...............14
5.2. Bootstrap Processing..................................15 5.1.3. The referral schema..............................14
5.3. Query Processing......................................16 5.2. Resource-Specific Schema...............................14
5.4. Query Post-Processing.................................16 6. Query Processing Behaviors................................15
5.4.1. Referrals.......................................17 6.1. Query Pre-Processing...................................16
5.4.2. Internationalization and localization...........18 6.2. Bootstrap Processing...................................17
6. Transition Issues........................................19 6.3. Query Processing.......................................18
6.1. NIC Handles...........................................20 6.4. Query Post-Processing..................................19
6.2. Change-Logs...........................................20 6.4.1. Referrals........................................19
7. Security Considerations..................................20 6.4.2. Internationalization and localization............20
8. IANA Considerations......................................23 7. Transition Issues.........................................22
9. Author's Address.........................................23 7.1. NIC Handles............................................22
10. Normative References.....................................23 7.2. Change-Logs............................................23
11. Informational References.................................26 8. Security Considerations...................................23
12. Acknowledgments..........................................26 9. IANA Considerations.......................................26
13. Changes from Previous Versions...........................26 10. Author's Address..........................................26
14. Full Copyright Statement.................................28 11. Normative References......................................26
12. Informational References..................................28
13. Acknowledgments...........................................28
14. Changes from Previous Versions............................29
15. Full Copyright Statement..................................30
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.
Hall I-D Expires: December 2003 [page 2]
More specifically, the principle objective behind FIRS is to offer More specifically, the principle objective behind FIRS is to offer
structured information about distributed Internet resources in a structured information about distributed Internet resources in a
model which reflects the federated delegations of those resources. model which reflects the federated delegations of those resources.
This specifically includes centralized delegations from authorized This specifically includes centralized delegations from authorized
governance bodies (such as DNS domains within the "com" zone), but governance bodies (such as DNS domains within the "com" zone), but
Hall I-D Expires: December 2003 [page 2]
also includes delegations from authorized bodies further down the also includes delegations from authorized bodies further down the
delegation path (such as leaf-node DNS domain names within the delegation path (such as leaf-node DNS domain names within the
"example.com" zone). "example.com" zone).
Furthermore, the FIRS service is intended to be used with a wide Furthermore, the FIRS service is intended to be used with a wide
variety of resources. The core set of specifications define rules variety of resources. The core set of specifications define rules
for handling the most-common resources (DNS domains, IP addresses, for handling the most-common resources (DNS domains, IP addresses,
contact information, and so forth), but other types of resources contact information, and so forth), but other types of resources
may be grafted onto the architecture as needed. By extension, FIRS may be grafted onto the architecture as needed. By extension, FIRS
should be capable of providing the necessary support structure for should be capable of providing the necessary support structure for
skipping to change at line 123 skipping to change at line 127
the CRISP Working Group requirements, as specified in draft-ietf- the CRISP Working Group requirements, as specified in draft-ietf-
crisp-requirements-05, "Cross Registry Internet Service Protocol crisp-requirements-05, "Cross Registry Internet Service Protocol
(CRISP) Requirements" [CRISP-REQ]. (CRISP) Requirements" [CRISP-REQ].
In order to achieve these objectives, the FIRS specifications In order to achieve these 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, queries, behavioral rules, and more. syntaxes, queries, behavioral rules, and more.
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
time, hundreds of WHOIS servers have been deployed across the time, hundreds of WHOIS servers have been deployed across the
public Internet, with each server providing general information public Internet, with each server providing general information
about the particular network resources under the control of a about the particular network resources under the control of a
specific organization. specific organization.
Hall I-D Expires: December 2003 [page 3]
Unfortunately, neither [RFC812] nor any of its successors define a Unfortunately, neither [RFC812] nor any of its successors define a
strict set of data-typing or formatting requirements, and as a strict set of data-typing or formatting requirements, and as a
result, each of the different implementations provide different result, each of the different implementations provide different
kinds of information in slightly different ways. Furthermore, each kinds of information in slightly different ways. Furthermore, each
Hall I-D Expires: December 2003 [page 3]
WHOIS server operates as a self-contained entity, with no WHOIS server operates as a self-contained entity, with no
standardized mechanisms to infer knowledge of any other servers, standardized mechanisms to infer knowledge of any other servers,
meaning that WHOIS servers cannot redirect clients to other meaning that WHOIS servers cannot redirect clients to other
servers for additional information. Another concern is that the servers for additional information. Another concern is that the
WHOIS services which are being operated today offer no means of WHOIS services which are being operated today offer no means of
client authentication, requiring that server operators essentially client authentication, requiring that server operators essentially
publish all data with a single "world-readable" permission. publish all data with a single "world-readable" permission.
However, this single permission conflicts with the privacy and However, this single permission conflicts with the privacy and
security policies of specific jurisdictions. security policies of specific jurisdictions.
skipping to change at line 177 skipping to change at line 182
whole or for the different resource-types. whole or for the different 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.
Hall I-D Expires: December 2003 [page 4]
* 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.
Hall I-D Expires: December 2003 [page 4] * Query-Processing Rules. The FIRS specifications also reuse
* The FIRS specifications also reuse some existing processing some existing processing rules, and define several
rules, and define several additional rules as needed. Among additional rules as needed. Among these rules are
these rules are requirements for normalizing data, locating requirements for normalizing data, locating servers,
servers, processing referrals, and more. processing referrals, and more.
Some of these rules apply to the architecture as a whole, while Some of these rules apply to the architecture as a whole, while
other rules apply to specific kinds of Internet resources. other rules apply to specific kinds of Internet resources.
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 the complete set of specification should be read in the context of the complete set of
specifications, which currently include the following: specifications, which currently include the following:
draft-ietf-crisp-firs-arch-00, "The Federated Internet draft-ietf-crisp-firs-arch-01, "The Federated Internet
Registry Service: Architecture and Implementation" (this Registry Service: Architecture and Implementation" (this
document) [FIRS-ARCH] document) [FIRS-ARCH]
draft-ietf-crisp-firs-core-00, "The Federated Internet draft-ietf-crisp-firs-core-01, "The Federated Internet
Registry Service: Core Elements" [FIRS-CORE] Registry Service: Core Elements" [FIRS-CORE]
draft-ietf-crisp-firs-dns-00, "Defining and Locating DNS draft-ietf-crisp-firs-dns-01, "Defining and Locating DNS
Domains in the Federated Internet Registry Service" Domains in the Federated Internet Registry Service"
[FIRS-DNS] [FIRS-DNS]
draft-ietf-crisp-firs-dnsrr-00, "Defining and Locating DNS draft-ietf-crisp-firs-dnsrr-01, "Defining and Locating DNS
Resource Records in the Federated Internet Registry Resource Records in the Federated Internet Registry
Service" [FIRS-DNSRR] Service" [FIRS-DNSRR]
draft-ietf-crisp-firs-contact-00, "Defining and Locating draft-ietf-crisp-firs-contact-01, "Defining and Locating
Contact Persons in the Federated Internet Registry Service" Contact Persons in the Federated Internet Registry Service"
[FIRS-CONTCT] [FIRS-CONTCT]
draft-ietf-crisp-firs-asn-00, "Defining and Locating draft-ietf-crisp-firs-asn-01, "Defining and Locating
Autonomous System Numbers in the Federated Internet Autonomous System Numbers in the Federated Internet
Registry Service" [FIRS-ASN] Registry Service" [FIRS-ASN]
draft-ietf-crisp-firs-ipv4-00, "Defining and Locating IPv4 Hall I-D Expires: December 2003 [page 5]
draft-ietf-crisp-firs-ipv4-01, "Defining and Locating IPv4
Address Blocks in the Federated Internet Registry Service" Address Blocks in the Federated Internet Registry Service"
[FIRS-IPV4] [FIRS-IPV4]
draft-ietf-crisp-firs-ipv6-00, "Defining and Locating IPv6 draft-ietf-crisp-firs-ipv6-01, "Defining and Locating IPv6
Address Blocks in the Federated Internet Registry Service" Address Blocks in the Federated Internet Registry Service"
[FIRS-IPV6] [FIRS-IPV6]
Hall I-D Expires: December 2003 [page 5]
The FIRS service reuses, unites and clarifies several pre-existing The FIRS service reuses, unites and clarifies several pre-existing
technologies. In order to fully understand FIRS, readers should be technologies. In order to fully understand FIRS, readers should be
familiar with the following technologies and specifications: familiar with the following technologies and specifications:
RFC 2247, "Using Domains in LDAP/X.500 DNs" [RFC2247] RFC 2247, "Using Domains in LDAP/X.500 DNs" [RFC2247]
RFC 2251, "Lightweight Directory Access Protocol (v3)" RFC 2251, "Lightweight Directory Access Protocol (v3)"
[RFC2251] [RFC2251]
RFC 2252, "Lightweight Directory Access Protocol (v3): RFC 2252, "Lightweight Directory Access Protocol (v3):
skipping to change at line 260 skipping to change at line 267
RFC 3296, "Named Subordinate References in Lightweight RFC 3296, "Named Subordinate References in Lightweight
Directory Access Protocol (LDAP) Directories" [RFC3296] Directory Access Protocol (LDAP) Directories" [RFC3296]
RFC 3377, "Lightweight Directory Access Protocol (v3): RFC 3377, "Lightweight Directory Access Protocol (v3):
Technical Specification" [RFC3377] Technical Specification" [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.
2.1. Reference Example 3. Reference Example
Figure 1 below shows an example of a FIRS-specific data-set. This Figure 1 below shows an example of a FIRS-specific data-set. This
example is referenced throughout this specification. example is referenced throughout this specification.
Hall I-D Expires: December 2003 [page 6] Hall I-D Expires: December 2003 [page 6]
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]
| |
skipping to change at line 306 skipping to change at line 314
+-attribute: inetTechContacts +-attribute: inetTechContacts
| value: "admins@example.com" | value: "admins@example.com"
| |
+-attribute: ref +-attribute: ref
value: "ldap://firs.example.net/cn=inetResources, value: "ldap://firs.example.net/cn=inetResources,
dc=example,dc=net"??? dc=example,dc=net"???
(1.3.6.1.4.1.7161.1.1.8:=host.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.
As can be seen in Figure 1, the entries use a FIRS-specific As can be seen in Figure 1, entries use a FIRS-specific namespace
namespace in conjunction with FIRS-specific schema, which clients in conjunction with FIRS-specific schema. Meanwhile, clients use
can use to generate FIRS-specific queries. FIRS-specific queries to locate and retrieve this information.
Hall I-D Expires: December 2003 [page 7] Hall I-D Expires: December 2003 [page 7]
3. 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. namespace which is imposed on all FIRS-based resources.
The FIRS namespace rules facilitate the programmatic creation of The FIRS namespace rules facilitate the programmatic creation of
lookups and searches, and ensure predictable results. The use of a searches, and help to ensure predictable results. The use of a
private namespace also help to segregate FIRS-related data from private namespace also acts to segregate FIRS-related data from
other kinds of data which may reside on any participating server. other kinds of data which may reside on a participating server,
thereby giving the operator greater control over the security and
replication considerations for all of the data.
The FIRS namespace consists of three "layers", which are: 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
cumulatively identify a specific partition of the global cumulatively identify a specific partition of the global
directory tree. directory tree.
* A FIRS-specific entry which acts as a container for all of * A FIRS-specific entry which acts as a container for all of
the FIRS-related resource-specific child entries. the FIRS-related resource-specific child entries.
* The resource-specific child entries which collectively * The resource-specific entries which describe the resources
contain detailed information about the resources under the under the control of the selected partition.
control of the selected partition.
The namespace follows a right-to-left order. The namespace follows a right-to-left order.
As an example, Figure 1 shows an DNS domain resource entry named As an example, Figure 1 shows a DNS domain resource entry named
"cn=example.com,cn=inetResources,dc=example,dc=com", which refers "cn=example.com,cn=inetResources,dc=example,dc=com", which refers
to the "example.com" domain resource within the "cn=inetResources" to the "example.com" domain resource within the "cn=inetResources"
container under the "dc=example,dc=com" directory partition. container under the "dc=example,dc=com" directory partition.
3.1. The domainComponent Hierarchy 4.1. The domainComponent Hierarchy
The top-level of the namespace uses the domainComponent naming and The top-level of the namespace uses the domainComponent naming and
mapping rules specified in RFC 2247 [RFC2247], which maps DNS mapping rules specified in RFC 2247 [RFC2247], which maps DNS
domain names to domainComponent ("dc=") relative distinguished domain names to domainComponent ("dc=") relative distinguished
names (RDNs). The full sequence of domainComponent RDNs map to an names (RDNs). The full sequence of domainComponent RDNs map to an
equivalent scope of authority in the DNS namespace, and equivalent scope of authority in the DNS namespace, with the full
cumulatively represent the root of a partition of the global LDAP sequence of RDNs cumulatively representing the root of a partition
directory space. For example, Figure 1 shows the directory in the LDAP directory tree.
partition of "dc=example,dc=com" which maps to the "example.com"
scope of authority from the DNS hierarchy. In this model, a sequence of domainComponent RDNs map to a domain
name in the global DNS hierarchy, with the FIRS partitions
providing scopes of authority in the global FIRS database of
distributed partitions. Furthermore, the SRV resource records
associated with those DNS domains also provide a useful mechanism
Hall I-D Expires: December 2003 [page 8] Hall I-D Expires: December 2003 [page 8]
3.2. The inetResources Container for locating the authoritative LDAP servers associated with any
particular resource in the global FIRS directory database.
Since the partition roots determine the scope of control over a
set of resources, partitions which overlap also have overlapping
scopes of control. For example, the "dc=com" and
"dc=example,dc=com" partitions can both provide information about
the "www.example.com" domain name resource. In order to reduce the
amount of ambiguity which is naturally present in this kind of
model, FIRS defines multiple bootstrapping models and also defines
the default model which should be used for any given resource. For
example, queries for centrally-delegated resources are supposed to
ask the top-level partition for information about those resources,
while queries for user-managed resources are supposed to ask the
leaf-node partition for information about those resources.
For example, Figure 1 shows the directory partition of
"dc=example,dc=com" which maps to the "example.com" scope of
authority from the DNS hierarchy, with the "dc=example,dc=com"
sequence representing the root of a partition in the globally
distributed directory database.
4.2. The inetResources Container
This specification requires the use of a mandatory LDAP container This specification requires the use of a mandatory LDAP container
entry with the RDN of "cn=inetResources", which MUST exist at the entry with the RDN of "cn=inetResources", which MUST exist at the
root of every directory database that provides FIRS services. All root of every directory partition that provides FIRS services. All
publically-accessible resource-specific entries MUST be stored in publically-accessible resource-specific entries MUST be stored in
the cn=inetResources container entry. 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 Internet resources allows that branch of the organization's FIRS-related resources allows that branch of the
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
also allows for the outsourcing of a FIRS container through the replication controls.
use a single referral.
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.
3.3. Resource-Specific Entries Hall I-D Expires: December 2003 [page 9]
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.
For example, Figure 1 shows an entry for the "www.example.com" For example, Figure 1 shows an entry for the "www.example.com"
domain name resource stored in the "dc=example,dc=com" directory domain name resource in the "cn=inetResources" container of the
context, with a fully-qualified distinguished name (FQDN) of "dc=example,dc=com" partition, and also shows an entry for the
"cn=www.example.com,cn=inetResources,dc=example,dc=com", and also "admins@example.com" contact resource in that same container and
shows an entry for the "admins@example.com" contact resource with partition. Although the naming syntax is different for each
the FQDN "admins@example.com,cn=inetResources,dc=example,dc=com". resource type, the naming rules are consistent and facilitate
Although the relative naming syntax is different for each resource predictable usage.
type, the syntax is consistent and predictable.
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.
Hall I-D Expires: December 2003 [page 9] 4.4. Namespace Aliases
3.4. 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. In this model, an entry exists which will match against referrals. In this model, an entry exists which will match against
searches for the queried data, but the attributes associated with searches for the queried data, but the attributes associated with
that entry indicate that some other entry should also be queried. that entry indicate that some other entry should also be queried.
Referrals represent one of the strongest capabilities of the FIRS Referrals represent one of the strongest capabilities of the FIRS
architecture, in that they allow for a significant variety of architecture, in that they allow for a significant variety of
cross-referencing among entries. For example, referrals can be cross-referencing among entries. For example, referrals can be
used to point an inetResources container entry in one partition to used to point an inetResources container entry in one partition to
another inetResources container entry in another partition, another inetResources container entry in another partition,
skipping to change at line 418 skipping to change at line 456
entries for specific resources (such as a web server) which only entries for specific resources (such as a web server) which only
exist as referrals for resources which are managed in other exist as referrals for resources which are managed in other
partitions (such as a web-hosting server at an ISP), with both partitions (such as a web-hosting server at an ISP), with both
entries providing information about that resource. entries providing information about that resource.
This latter example can be seen in Figure 1, which shows an entry This latter example can be seen in Figure 1, which shows an entry
for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which for "cn=www.example.com,cn=inetResources,dc=example,dc=com" which
provides a referral to the "cn=host.example.net" entry at provides a referral to the "cn=host.example.net" entry at
"cn=inetResources,dc=example,dc=net". Queries for the local entry "cn=inetResources,dc=example,dc=net". Queries for the local entry
would be answered with the locally-available information and then would be answered with the locally-available information and then
Hall I-D Expires: December 2003 [page 10]
redirected to the referral target where additional information redirected to the referral target where additional information
could be retrieved. could be retrieved.
FIRS supports two different kinds of referrals, which are FIRS supports two different kinds of 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 5.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.
Hall I-D Expires: December 2003 [page 10] 4.5. Partition Replicas
4. FIRS Schema Definitions
All directory partitions which provide data for global Internet
resources SHOULD be replicated across two or more servers. Each of
the authoritative LDAP servers for the managed resource MUST be
specified with a unique DNS SRV resource record for the domain
name associated with the top-level resource assignment space.
Directory partitions which serve multiple organizations SHOULD
also be replicated. For example, an ISP which provides FIRS
services for their customers SHOULD also follow these same rules,
since outages of those servers will affect multiple parties. Leaf-
node directory partitions associated with an user-managed resource
MAY be replicated, and are encouraged to do so.
Similarly, any referral URLs which include host identifier
elements SHOULD provide multiple URLs, each of which identify
different hosts. For leaf-node referrals and labeledURI
references, this behavior MAY be relaxed, although it is still
encouraged.
Note that the most effective replication strategy will be for
entities to replicate their directory partitions with the
delegation parents, as this will allow queries for those resources
to be processed by the parent servers (thereby eliminating the
need for referral queries). In many cases, this will not be
feasible (the servers for the "dc=com" directory partition cannot
Hall I-D Expires: December 2003 [page 11]
be expected to host replicas of every subordinate directory
partition), but it is encouraged where practical.
It is also expected that certain servers will be configured to
serve as multi-replica masters, effectively acting as large-scale
caching servers for many different resources. When used in
conjunction with the targeted bootstrap model described in section
6.4.1, this will allow clients to retrieve a significant amount of
information without having to pursue a large number of referrals
or redirects. This usage is expected and endorsed.
Finally, it is important to recognize that the LDAP specifications
do not currently provide cache timers or any other mechanisms
which can indicate how accurate or timely any replicas may be.
5. FIRS Schema Definitions
Another critical aspect of FIRS is the use of well-known schema, 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- service and are usable by all entries (including resource-specific
specific entries), while others are specific to particular entries), while others are specific to particular resource-types.
resource-types. Where suitable pre-existing schema definitions are
available, they are reused to facilitate integration with other Wherever any suitable pre-existing schema definitions are
LDAP applications. available they should be reused, since reuse facilitates
integration with other LDAP applications.
5.1. Global Schema
4.1. Global Schema Definitions
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 the FIRS database. 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
object class defines a variety of optional general-purpose object class defines a variety of general-purpose
attributes which are useful for describing an organization attributes which are useful for general information about
or the resources under its control. 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 entries which may be of interest
Hall I-D Expires: December 2003 [page 12]
entry to reference other resources which may be of interest
to the user. to the user.
* Referral pointers. All FIRS-related entries MAY use the * Referral pointers. All FIRS-related entries MAY use the
"referral" object class and schema definitions defined in "referral" object class and schema definitions defined in
[RFC3296]. This object class allows an entry to exist as a [RFC3296]. This object class allows an entry to exist as a
referral source, with queries for that resource being referral source, with queries for that resource being
redirected to the referral target. Refer to section 5.4.1 redirected to the referral target. Refer to section 4.4 for
for a discussion on the different kinds of referral and a discussion on the different kinds of referral mechanisms
reference mechanisms offered by FIRS. offered by FIRS, and section 6.4.1 for a discussion on the
FIRS referral-processing mechanisms.
Figure 1 shows that all of the entries within and including the Figure 1 shows that all of the entries within and including the
"cn=inetResources" container entry have the inetResources object "cn=inetResources" container entry have the inetResources object
class defined, and that the "cn=www.example.com" resource-specific class defined. Meanwhile, each of the resource-specific entries in
entry also has the referral object class defined. Each of the that example also have their own resource-specific object classes,
resource-specific entries in that example also have their own while the "cn=www.example.com" resource-specific entry also has
resource-specific object classes. the referral object class defined.
5.1.1. The inetResources schema
The inetResources object class is intended to provide summary
information about a collection of resources under the control of a
single organization or management body. Since this object class is
also inherited by the resource-specific object classes, these
attributes can be defined at each of the subordinate entries if a
global set of attribute values is undesirable or unfeasible.
Since multiple directory partitions can use subordinate reference
referrals to share a single common inetResources entry, it is
important for the data to be applicable to all of the entries
which refer to it. For example, it would be effective for a small
private company to use a shared set of inetResources attributes
for their DNS domain names and IP network blocks, but it would
probably be counter-productive for a global ISP to share contact
data across all of their hosted domains and routed networks. If
separate contacts are required for each resource, the contact data
should be specified within each entry, rather than being linked to
the inetResources entry.
The inetResources object class provides several multi-valued
contact-related attributes for a variety of well-known
administrative roles. This model allows the inetResources entry
and each of the subordinate managed resources to share a common
set of administrative roles, or to have unique roles for each
resource, as seen fit by the managing entity.
Hall I-D Expires: December 2003 [page 13]
5.1.2. The inetAssociatedResources schema
The inetAssociatedResources object class defines attributes which
are useful for providing general-purpose cross-referencing
information with other resources. For example, a contact entry can
list IPv4 networks or DNS domains as associated resources, thereby
providing a simplistic cross-reference mechanism between an
administrator and the resource he manages. In short, any resource
can be associated with any other resource through the use of this
object class.
5.1.3. The referral schema
The referral object class is used to redirect queries to other
entries programmatically. This object class and its associated
schema and rules provide the backbone of the aliasing mechanisms
discussed in section 4.4.
5.2. Resource-Specific Schema
Hall I-D Expires: December 2003 [page 11]
4.2. Resource-Specific Schema Definitions
In addition to the global schema definitions, each of the In addition to the global schema definitions, each of the
resource-specific entry 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
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 sub-domain in [FIRS-DNS]. These entries can refer to zone delegations,
delegations, host-specific entries, reverse-lookup entries, host-specific entries, reverse-lookup pointer entries, or
or any other domain name resource, as needed. 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
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 network block entry 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 network defined in [FIRS-IPV4]. Entries can refer to entire
blocks or single hosts, as needed. networks or to single hosts, as needed.
* IPv6 address blocks. Every IPv6 network block entry 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
defined in [FIRS-IPV6]. Entries can refer to entire network
blocks or single hosts, as needed. Hall I-D Expires: December 2003 [page 14]
defined in [FIRS-IPV6]. Entries can refer to entire
networks or to single hosts, as needed.
* Autonomous system numbers. Every autonomous system number * Autonomous system numbers. Every autonomous system number
entry MUST use the inetAsNumber object class and schema resource MUST use the inetAsNumber object class and schema
definitions defined in [FIRS-ASN]. definitions defined in [FIRS-ASN].
* Contacts. Every contact entry MUST use the inetOrgPerson * Contacts. Every contact entry MUST use the inetOrgPerson
object class defined in [RFC2798], as well as the schema object class defined in [RFC2798], but MUST also use the
definitions defined in [FIRS-CONTCT]. additional schema definitions defined in [FIRS-CONTCT].
As was discussed in section 4.1, each resource-specific entry MAY As was discussed in section 5.1, each resource-specific entry MAY
exist as a referral source, or MAY have attributes which refer to exist as a referral source, or MAY have attributes which refer to
additional (related) entries. additional (related) resources.
Hall I-D Expires: December 2003 [page 12] 6. Query Processing Behaviors
5. Query Processing Behaviors
Another critical aspect to FIRS is the query-processing behavior.
These rules govern the ways in which a client parses a query,
locates a server which is authoritative for the resource being
queried, generates LDAPv3 queries, and processes any resulting
referrals. More specifically:
* Query pre-processing. The first step is for the client to Another critical aspect to FIRS is the query-processing behavioral
prepare the query. Portions of this process require the rules which govern the ways in which a client parses an input
string, locates a server which is authoritative for the resource
being queried, generates LDAPv3 queries, and processes the
resulting answer data. More specifically:
* Query pre-processing. Portions of this process require the
client to determine the type of resource being queried for, 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 partition has been determined, * Bootstrap processing. Once a resource-type and partition
the client must locate the LDAP servers which are have been determined, the client must locate the LDAP
authoritative for the resource in question. [FIRS-CORE] servers which are authoritative for that partition. [FIRS-
defines three different bootstrap models that clients can CORE] defines three different bootstrap models that clients
use as part of this process, while each of the resource- can use as part of this process, while each of the
specific specifications define which of the models are to resource-specific specifications define which of the models
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 may also with, while the resource-specific specifications define
define additional parameters. resource-specific matching rules.
* Query post-processing. FIRS explicitly supports several Hall I-D Expires: December 2003 [page 15]
different types of LDAP referral and redirection * Query post-processing. Response data frequently needs to be
mechanisms, any of which may result in the client further processed. For example, referrals may need to be
application restarting the query or initiating a brand-new processed, or some kinds of data may need to be localized.
query. These mechanisms and their behavioral rules are These mechanisms and their behavioral rules are defined in
defined in [FIRS-CORE]. [FIRS-CORE], while the resource-specific specifications may
also describe supplemental rules.
Each of these phases are discussed in more detail below. Each of these phases are discussed in more detail below.
5.1. Query Pre-Processing 6.1. Query Pre-Processing
Client input is generally provided as a single well-formed unit of
data, such as a domain name ("example.com") or an email address
("admins@example.com"). Since this information is typically all
Hall I-D Expires: December 2003 [page 13] Client input is generally limited to a single well-formed unit of
that's provided, it must be used to subsequently build a fully- data, such as a domain name ("example.com") or an email address
formed LDAPv3 query, including the assertion value, the search ("admins@example.com"), and this single piece of information must
base, the matching filter, and so forth. All of these steps are be used to subsequently build a fully-formed LDAPv3 query,
part of the pre-processing phase. including the assertion value, the search base, the matching
filter, and so forth. All of these steps are part of the pre-
processing phase.
Although the exact sequence of steps will vary according to the 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:
* 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 normalized into a internationalized domain names must be validated and
UTF-8 form before any other steps can be taken, with the normalized into a canonical UTF-8 [RFC2279] form before any
domain name being validated as part of the normalization other steps can be taken. Similarly, IPv6 addresses are
process. Similarly, IPv6 addresses are required to conform required to conform to specific syntax rules, and input
to specific syntax rules, and input address may need to be address may need to be expanded or compressed in order to
expanded or compressed in order to comply these syntax comply with the syntax requirements.
requirements.
* Determine the appropriate directory partition for the * Determine the authoritative directory partition for the
query. Different kinds of resources have different default named resource. In most cases, the authoritative partition
choices. In most cases, the appropriate partition will be a will be a variation of the input query string, but this is
variation of the input query string, but this is not always not always the case. For example, the default partition for
the case. For example, the default partition for an email an email address will be extrapolated from the domain
address will be the domain component of the email address component of the email address itself, while the
itself, while the default partition for an ASN is a
reserved (special-purpose) domain name. In some cases, the
selected partition may change as a result of errors or
referrals encountered during later phases of the process.
* Determine the search base for the query. In most cases, the Hall I-D Expires: December 2003 [page 16]
search base will refer to the inetResources container entry authoritative partition for an ASN uses a reserved
within the partition which was determined in the prior (special-purpose) domain name. In some cases, the
step, with these elements being combined into an FQDN. In authoritative partition may change during the subsequent
some cases, the search base may need to be changed as a query-processing steps.
result of referrals encountered during later phases of the
process. * Determine the search base for the query. Each resource type
has resource-specific query-processing rules which will
dictate how the authoritative partitions are mapped to the
search base. In some cases, the cn=inetResources container
entry in the authoritative partition will be used "as-is",
while in other cases, the cn=inetResources container entry
in a delegation parent of the authoritative partition will
be used instead. In some cases, the search base may change
during subsequent query-processing steps.
Hall I-D Expires: December 2003 [page 14]
* 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 need to be query. In some cases, the assertion value may change during
changed as a result of referrals encountered during later subsequent query-processing steps.
phases of the process.
* Determine the matching filter. Each resource-type has its * Determine the matching filter. Each resource-type has its
own matching filter rules. In some cases, the matching own matching filter rules. For example, contact entries are
filter will be a simple equalityMatch comparison, while in matched with a simple equalityMatch comparison, while in
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 must attempt to locate an LDAPv3 server completed, the client will have to locate an LDAPv3 server which
which is authoritative for that resource. This process is is authoritative for the search base before it can submit the
described in section 5.2 below. query. This process is described in section 6.2 below.
5.2. Bootstrap Processing 6.2. Bootstrap Processing
The bootstrap process uses DNS queries for SRV resource records
associated with the selected directory partition. However, since The bootstrap process uses DNS queries to locate the LDAP servers
different kinds of resources are managed through different which should be used for a query. However, since different kinds
delegation models, there are also different bootstrap models which of resources are managed through different delegation models,
have to be used to perform this process. there are also different bootstrap models which have to be used to
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
absolute 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,
the client exits the query. the client exits the query.
Hall I-D Expires: December 2003 [page 17]
* Top-down. The "top-down" bootstrap model has the client * Top-down. The "top-down" bootstrap model has the client
attempting to locate the LDAP servers associated with a attempting to locate the LDAP servers associated with a
top-level domain (such as trying to locate the LDAP servers top-level partition in the delegation path to the
associated with the "com" domain for an original query of authoritative partition. If no servers can be found for the
"www.example.com"). If no servers can be found for the top- top-level domain, the client exits the query.
level domain, the client exits the query.
* Bottom-up. The "bottom-up" bootstrap model has the client * Bottom-up. The "bottom-up" bootstrap model has the client
attempting to locate the LDAP servers associated with the attempting to locate the LDAP servers associated with the
leaf-node domain (such as trying to locate any LDAP servers authoritative partition itself. If no servers can be found
associated with the "www.example.com" domain specifically). for that partition, the authoritative partition is reset to
If no servers can be found for that domain name, the the immediate parent in the delegation hierarchy and new
directory partition is reset to its immediate parent and DNS queries are issued, with this process repeating until
some servers are found or there are no more partitions in
Hall I-D Expires: December 2003 [page 15] the delegation path which can be queried.
the DNS query is resubmitted with that new scope. This
process continues until no more domains can be trimmed.
Each of the models are appropriate to different usages. For Each of the models are appropriate to different usages. For
example, The targeted model is most useful with pointer data example, The targeted model is most useful when a particular piece
gleaned through URLs and other fixed sources, where the data is of data is presumed to exist at a pre-determined location.
presumed to exist at a pre-determined location. Meanwhile, the Meanwhile, the top-down model is best suited for searches about
top-down model is best suited for searches about global resources global resources which are centrally managed and delegated (such
which are centrally managed and delegated (such as IP addresses as IP addresses and DNS domains), and where centrally-managed
and DNS domains), and where centrally-managed delegation delegation information is critical. Finally, the bottom-up model
information is critical. Finally, the bottom-up model is most is most appropriate for resources which are not centrally
appropriate for those resources which are managed by the end-users delegated and managed (such as contact information).
directly (such as contact information, DNS resource records, and
so forth), and which are not typically managed from a centralized
delegation authority.
Once the bootstrap process has resulted in an authoritative LDAP 6.3. Query Processing
server being located for the partition in question, the remainder
of the query process is consistent.
5.3. Query Processing
Once an LDAP server has been located, the LDAPv3 query is 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 all queries in order to maximum time limit of 60 seconds for all queries in order to
prevent runaway searches which match all entries. prevent runaway searches which 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 the information that they provide to a specific client based on a
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. These process is protocol and schema versioning considerations. These
mechanisms are already existent in the LDAPv3 specifications, and mechanisms are already existent in the LDAPv3 specifications, and
their usage is encouraged by [FIRS-CORE]. their usage is encouraged by [FIRS-CORE].
5.4. Query Post-Processing Hall I-D Expires: December 2003 [page 18]
6.4. Query Post-Processing
Once a query has been submitted and processed, the server should Once a query has been submitted and processed, the server should
return answer data or some kind of referral, or possibly both. In return answer data or some kind of referral, or possibly both. In
Hall I-D Expires: December 2003 [page 16]
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.
5.4.1. Referrals 6.4.1. Referrals
As was discussed in section 3.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
condition means that the current search operation cannot condition means that the current search operation cannot
proceed, and that the search MUST be restarted. Any of the proceed, and that the search MUST be restarted using the
FIRS-specific entries MAY be defined as subordinate search base specified in the referral message.
reference referrals, although they are typically only used
when the inetResources container entry in a partition is an Any of the FIRS-specific entries MAY be defined as
alias for an inetResources container entry in another subordinate reference referrals, although they are
partition. Subordinate reference referrals and their schema typically only used when the inetResources container entry
are defined in RFC 3296 [RFC3296] although there are in a partition is an alias for an inetResources container
additional restrictions placed on their usage as described entry in another partition. Subordinate reference referrals
in [FIRS-CORE]. and their schema are defined in [RFC3296] although there
are additional restrictions placed on their usage as
described in [FIRS-CORE].
* Continuation reference referrals. Continuation reference * Continuation reference referrals. Continuation reference
referrals are returned when a search operation has been referrals are returned when a search operation has been
successfully processed by the queried server, but the successfully processed by the queried server, but the
answer data also includes referrals to other entries. These answer data also includes referrals to other entries. This
referrals are often provided as supplemental data to an condition means that the current search operation has
answer set, although this is not required (a continuation
reference referral can be the only response, but it won't
be the only response in the common case). This condition
means that the current search operation has partially
succeeded, but that additional searches SHOULD be started succeeded, but that additional searches SHOULD be started
in order for all of the answer data to be. Continuation for all of the known answer data to be retrieved.
reference referrals and their schema are also defined in
[RFC3296], with additional restrictions placed on their These referrals are often provided as supplemental data to
usage as described in [FIRS-CORE]. an answer set, although this is not required (a
continuation reference referral can be the only response,
Hall I-D Expires: December 2003 [page 19]
but it won't be the only response in the common case).
Continuation reference referrals and their schema are also
defined in [RFC3296], with additional restrictions placed
on their usage as described in [FIRS-CORE].
Whenever a referral is received in response to a query, the client Whenever a referral is received in response to a query, the client
MUST display any answer data which has been received and then is required to display any answer data which has also been
process the referral. As part of this process, the client MUST received and then process the referral.
Hall I-D Expires: December 2003 [page 17] LDAP referrals can use any kind of URL, although FIRS specifically
parse the URL for the host identifier, port number, search base, requires the use of LDAP URLs. The client is required to parse the
and assertion value (if these are provided), and then construct resulting URL for a host identifier, port number, search base, and
and issue new queries using these values. assertion value elements, and then use these elements to construct
and issue new queries.
Note that RFC 2251 [RFC2251] defines a superior reference referral Note that [RFC2251] defines a superior reference referral which is
which is used as a "default referral" for out-of-scope searches. used as a "default referral" for out-of-scope searches. However,
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.
5.4.2. Internationalization and localization 6.4.2. Internationalization and localization
The FIRS model uses the internationalization and localization The FIRS model uses the internationalization and localization
services provided by LDAPv3. In this regard, FIRS clients do not services which are inherent in LDAPv3. In many cases, this native
need to implement any special services in order to process and support is sufficient to accommodate internationalization and
display internationalized attribute data if those attribute types localization considerations. However, there are several cases
already provide direct support for internationalized data. where additional and explicit support is required.
However, there are several instances where this is not the case.
The areas where specific considerations have been made to fully For example, the domainComponent attribute is specifically
accommodate internationalization and localization concerns are restricted to seven-bit character codes, and is traditionally
described below. interpreted as simple [US-ASCII]. This is problematic with
internationalized domain names and the domainComponent attributes
derived from them, since these attribute sequences are used in
partition identifiers, search bases, and numerous other areas. In
order to ensure interoperability, all DNS domain names which are
mapped to domainComponent attributes MUST be reduced to their
ASCII-compatible form using the ToASCII process defined in
[RFC3490] before they are used for domainComponent sequences.
* The domainComponent attribute is restricted to [US-ASCII]. Similarly, although DNS is technically capable of storing eight-
This is problematic with internationalized domain names and bit code-point values, the operational rules which govern DNS do
their use in directory information trees, search bases, and not support this usage for domain names which are used as host
so forth. In order to ensure interoperability, this identifiers (and this includes zone delegations). As a result,
specification requires all DNS domain names which are internationalized domain names which are to be used for SRV or A
mapped to domainComponent attributes to be normalized and resource record lookups MUST be reduced to their ASCII-compatible
reduced to their ASCII-compatible form using the "ToASCII"
process defined in [RFC3490] before these sequences are
stored in the directory or used in LDAPv3 messages.
* DNS is technically capable of storing eight-bit codepoint Hall I-D Expires: December 2003 [page 20]
values, although the operational rules which govern DNS do form using the ToASCII process defined in [RFC3490] before these
not support this usage. As a result, internationalized DNS queries are issued.
domain names which are used for SRV or A resource record
lookups MUST be normalized and reduced to their ASCII-
compatible form using the "ToASCII" process defined in
[RFC3490] before these queries are issued.
* Some URLs may need to be escaped in order to accommodate In those cases where entries or attributes use normalized UTF-8
internationalized strings (the rules and requirements for sequences inside of FIRS (specifically domain names and email
this process are defined in the specifications which govern addresses), FIRS clients SHOULD offer ASCII-compatible versions of
each kind of URL). those sequences, using the ToASCII process defined in [RFC3490].
This will ensure that clients are able to use these sequences with
legacy (pre-IDNA) applications directly. For example, if an entry
displays an inetAssociatedDomains attribute, the domain names in
that attribute should be displayed in their default UTF-8 form
(assuming that the client's operating system and application
allows it), but should also be made available in their ASCII-
compatible form (either as a clipboard option, command-line
option, or some other user-selectable switch) in order to allow
the data to be passed to a legacy application in a form which is
understandable by that application.
Hall I-D Expires: December 2003 [page 18] Attribute names are fixed, and can therefore be localized easily.
* RFC 2277 [RFC2277] requires that free-text data must be As such, clients MAY choose to convert attribute names into a
accompanied with language tags. RFC 2596 [RFC2596] defines language appropriate to the local user for display purposes if
a mechanism for storing language tags and language-specific this is desirable. However, clients MUST NOT localize attribute
attribute values, and these mechanisms SHOULD be supported names which are used for query input. For example, clients MUST
by FIRS clients and servers. For example, an organization NOT convert "cn=" or "dc=" relative distinguished labels into a
name could be provided in English and Arabic, with the language-specific mapping and then use the mapped versions of
language tags allowing the client application to view the these labels for assertion values in a subsequent query.
appropriate attribute value instance, if both the client
and the server support the mechanisms defined in RFC 2596.
Note that attribute values which contain structured data
(even if there is no structure in LDAP) do not necessarily
benefit from language tags. Examples of the latter include
the labeledURI and mail attributes, which do not typically
have multiple linguistic representations.
* Time and date strings usually use the generalizedTime RFC 2277 [RFC2277] requires free-text data to be tagged with
syntax, making them predictable. Dates MAY be localized for language tags. RFC 2596 [RFC2596] defines a mechanism for storing
display purposes by client applications as necessary. language tags and language-specific attribute values, and these
mechanisms SHOULD be supported by FIRS clients and servers. For
example, an organization name could be provided in English and
Arabic, with the language tags allowing the client to display the
appropriate attribute value instance based on the locale settings
of the user.
* Attribute names are static and well-known, and are International postal regulations generally require that the
therefore easily localized. As such, clients MAY choose to recipient address on an envelope be provided in a language and
convert attribute names in a language appropriate to the charset which is native to the recipient's country, with the
local user for display purposes where it is safe to do so. exception of the destination country name which should be provided
However, clients MUST NOT localize attribute names which in a language and charset that is native to the sender's country.
are used for query input. Specific examples of the latter This model ensures that the sender's post office will be able to
would be converting "cn=" or "dc=" relative distinguished route the mail to the recipient's country, while also ensuring
labels into some other language. that the destination country's post office will be able to perform
local delivery. In order to facilitate this usage, the country
attribute value MAY (encouraged) be localized to the local user's
* International postal regulations generally require that the Hall I-D Expires: December 2003 [page 21]
recipient address be provided in a language and charset nomenclature for a country, but other postal address information
which is native to the recipient's country, with the SHOULD NOT be localized.
exception of the destination country code which should be
provided in a language and charset that is native to the
sender's country (this allows the sender's post office to
route the mail to the recipient's country, while allowing
the destination country to perform local delivery). In
order to facilitate this usage, the country attribute value
MAY (encouraged) be localized to the local user's
nomenclature for a country, but other postal address
information SHOULD NOT be localized.
6. Transition Issues Notwithstanding the above, it is ENCOURAGED that contact names be
There are a handful of areas where the proposed service does not provided in English forms in order to facilitate inter-party
fully match with all of the existing WHOIS service offerings. communications, using the mechanisms offered by [RFC2596]. For
These areas are discussed in more detail below. example, the default contact entry for a person in Japan SHOULD be
provided in the native form for that person, but an English form
is also ENCOURAGED in order to allow non-Japanese users to
properly address that person in subsequent communications. As
stated in the preceding paragraph however, any postal
communications for that person SHOULD use the native-language
representation (at least on the envelope) in order to facilitate
the delivery of postal mail.
Time and date strings in LDAP use the generalizedTime syntax,
making them predictable and easily convertible if necessary. As
such, dates MAY be localized for display purposes by client
applications as necessary.
Finally, clients must recognize that some URL data is likely to be
escaped, using at least one of the multiple rules which affect
URLs and resource-specific data. For example, a URL which contains
a domain name resource could theoretically have been escaped with
three or four different syntax rules, and clients MUST be prepared
to decode these URLs appropriately.
7. Transition Issues
There are a handful of areas where FIRS does not fully compare
with all of the existing WHOIS service offerings. These areas are
discussed in more detail below.
7.1. NIC Handles
Hall I-D Expires: December 2003 [page 19]
6.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. This option with email addresses for the contacts. This option
facilitates faster coalescence around the FIRS system. facilitates faster coalescence around the FIRS system.
* NIC handles can be converted into locally-scoped email * NIC handles can be converted into locally-scoped email
addresses. For example, the NIC handle of EH26 on Network addresses. For example, the NIC handle of EH26 on Network
Solutions' WHOIS server could be replaced with the locally- Solutions' WHOIS server could be replaced with the locally-
Hall I-D Expires: December 2003 [page 22]
scoped email address of "ehall@whois.netsol.com" or some scoped email address of "ehall@whois.netsol.com" or some
variation thereof. variation thereof.
Of the two mechanisms described above, the former is preferred. Of the two mechanisms described above, the former is preferred.
6.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
its member ccTLDs provide WHOIS output which includes a series of its member 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.
Organizations are certainly free to maintain this information on Organizations are certainly free to maintain this information on
their internal systems (and are even encouraged to do so). their internal systems (and are even encouraged to do so).
However, this information is not necessary for public view of the However, this information is not necessary for public view of the
data in the FIRS service. Where the auditing information will be data in the FIRS service. Where the auditing information will be
required, a format which is more suitable to legal review will required, a format which is more suitable to legal review will
also be required. also be required.
Organizations who wish to publish change-log information should Organizations who wish to make change-log information available to
develop a common schema for this purpose. An initial demonstration the public should use an LDAP schema for this purpose. An initial
schema has been developed by the author and is available at schema has been developed for this purpose and is available at
http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt http://www.ehsco.com/misc/draft-hall-ldap-audit-00.txt. However,
this schema has not yet been proposed as a standards-track effort,
and should only be used as a starting point for other development.
8. Security Considerations
7. 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
Hall I-D Expires: December 2003 [page 20]
considerations associated with LDAPv3, as described in section 7 considerations associated with LDAPv3, as described in section 7
of [RFC2251]. of [RFC2251].
By nature, LDAP is a read-write protocol, while the legacy WHOIS By nature, LDAP is a read-write protocol, while the legacy WHOIS
service has always been a read-only service. As such, there are service has always been a read-only service. As such, there are
significant risks associated with allowing unintended updates by significant risks associated with allowing unintended updates by
unauthorized third-parties. Moreover, allowing the FIRS service to unauthorized third-parties. Moreover, allowing the FIRS service to
update the underlying delegation databases could result in network update the underlying delegation databases could result in network
resources being stolen from their lawful operators. For example, resources being stolen from their lawful operators. For example,
if the LDAP front-end had update access to a domain delegation if the LDAP front-end had update access to a domain delegation
database, a malicious third-party could theoretically take database, a malicious third-party could theoretically take
ownership of that domain by exploiting an authentication weakness, ownership of that domain by exploiting an authentication weakness,
thereby causing ownership of the domain to be changed to another thereby causing ownership of the domain to be changed to another
Hall I-D Expires: December 2003 [page 23]
party. For this reason, it is imperative that the FIRS service not party. For this reason, it is imperative that the FIRS service not
be allowed to make critical modifications to delegated resources be allowed to make critical modifications to delegated resources
without ensuring that all possible precautions have been taken. without ensuring that all possible precautions have been taken.
The query processing models described in this document make use of The query processing models described in this document make use of
DNS lookups in order to locate the LDAP servers associated with a DNS lookups in order to locate the LDAP servers associated with a
particular resource. DNS is susceptible to certain attacks and 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.
skipping to change at line 940 skipping to change at line 1110
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
unknown or untrusted information to routine purposes. unknown or untrusted information to routine purposes.
Hall I-D Expires: December 2003 [page 21]
Despite these disclaimers, however, it is very likely that the Despite these disclaimers, however, it is very likely that the
information presented through the FIRS service will be used for information presented through the FIRS service will be used for
many operational and problem-resolution purposes. In order to many operational and problem-resolution purposes. In order to
ensure the veracity of the information, a minimal set of ensure the veracity of the information, a minimal set of
operational guidelines are provided herein. For the most part, operational guidelines are provided herein. For the most part,
these rules are designed to prevent unauthorized modifications to these rules are designed to prevent unauthorized modifications to
the data. the data.
Note that these rules only apply to data which is willingly Note that these rules only apply to data which is willingly
provided; no data is required to be entered, but where the data is provided; no data is required to be entered, but where the data is
provided, it SHOULD be validated as accurate on entry, and it MUST provided, it SHOULD be validated as accurate on entry, and it MUST
be secured against unauthorized modifications. be secured against unauthorized modifications.
Hall I-D Expires: December 2003 [page 24]
* The inetResources container entry and all of the resource- * The inetResources container entry and all of the resource-
specific subordinate entries within every public DIT that specific subordinate entries within every public DIT that
provides FIRS resources SHOULD have anonymous read-only provides FIRS resources SHOULD have anonymous read-only
access permissions, and SHOULD NOT have anonymous add, access permissions, and SHOULD NOT have anonymous add,
delete or modify permissions. delete 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
skipping to change at line 985 skipping to change at line 1155
Note that contact pointers are entirely optional and are Note that contact pointers are entirely optional and are
not required to exist. However, where they exist, they MUST not required to exist. However, where they exist, they MUST
comply with the above requirements. comply with the above requirements.
* 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 information. is useful for determining the age of the information.
Hall I-D Expires: December 2003 [page 22]
* Server administrators MAY define additional add, delete or * Server administrators 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
of delegated resources (such as assigning modification of delegated resources (such as assigning modification
privileges to the managers of a particular delegated domain privileges to the managers of a particular delegated domain
or address block), although this is entirely optional, and or address block), although this is entirely optional, and
is within the sole discretion of the delegation body. is within the sole discretion of the delegation body.
Finally, there are physical security issues associated with any Finally, there are physical security issues associated with any
service which provides physical addressing and delivery service which provides physical addressing and delivery
information. Although organizations are generally encouraged to information. Although organizations are generally encouraged to
provide as much information as they feel comfortable with, no provide as much information as they feel comfortable with, no
information is required. information is required.
8. IANA Considerations Hall I-D Expires: December 2003 [page 25]
9. IANA Considerations
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,
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 data (including SRV resource records and LDAPv3 referrals). LDAP servers and data. It is expected that IANA will see to the
It is expected that IANA will see to the establishment and establishment and maintenance of these servers and data.
maintenance of these servers and data.
10. Author's Address
9. Author's Address
Eric A. Hall Eric A. Hall
ehall@ehsco.com ehall@ehsco.com
10. Normative References 11. Normative References
[CRISP-REQ] Newton, A. "Cross Registry Internet Service
Protocol (CRISP) Requirements", draft-ietf-
crisp-requirements-05, May 2003.
[FIRS-ARCH] Hall, E. "The Federated Internet Registry
Service: Architecture and Implementation
Guide", draft-ietf-crisp-firs-arch-01, May
2003.
[FIRS-ASN] Hall, E. "Defining and Locating Autonomous
System Numbers in the Federated Internet
Registry Service", draft-ietf-crisp-firs-asn-
01, May 2003.
[FIRS-CONTCT] Hall, E. "Defining and Locating Contact
Persons in the Federated Internet Registry
Service", draft-ietf-crisp-firs-contact-01,
May 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp-
firs-core-01, May 2003.
Hall I-D Expires: December 2003 [page 26]
[FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in
the Federated Internet Registry Service",
draft-ietf-crisp-firs-dns-01, May 2003.
[FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource
Records in the Federated Internet Registry
Service", draft-ietf-crisp-firs-dnsrr-01, May
2003.
[FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address
Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv4-01, May
2003.
[FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address
Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv6-01, May
2003.
[RFC1274] Barker, P., and Kille, S. "The COSINE and [RFC1274] Barker, P., and Kille, S. "The COSINE and
Internet X.500 Schema", RFC 1274, November Internet X.500 Schema", RFC 1274, November
1991. 1991.
Hall I-D Expires: December 2003 [page 23]
[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.
[RFC2279] Yergeau, F. "UTF-8, a transformation format of
ISO 10646", RFC 2279, January 1998.
[RFC2251] Wahl, M., Howes, T., and Kille, S. [RFC2251] Wahl, M., Howes, T., and Kille, S.
"Lightweight Directory Access Protocol (v3)", "Lightweight Directory Access Protocol (v3)",
RFC 2251, December 1997. RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille, [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and Kille,
S. "Lightweight Directory Access Protocol S. "Lightweight Directory Access Protocol
(v3): Attribute Syntax Definitions", RFC 2252, (v3): Attribute Syntax Definitions", RFC 2252,
December 1997. December 1997.
[RFC2253] Wahl, M., Kille, S., and Howes, T. [RFC2253] Wahl, M., Kille, S., and Howes, T.
"Lightweight Directory Access Protocol (v3): "Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of DNs", RFC 2253, UTF-8 String Representation of DNs", RFC 2253,
December 1997. December 1997.
Hall I-D Expires: December 2003 [page 27]
[RFC2254] Howes, T. "The String Representation of LDAP [RFC2254] Howes, T. "The String Representation of LDAP
Search Filters", RFC 2254, December 1997. Search Filters", RFC 2254, December 1997.
[RFC2255] Howes, T., and Smith, M. "The LDAP URL [RFC2255] Howes, T., and Smith, M. "The LDAP URL
Format", RFC 2255, December 1997. Format", RFC 2255, December 1997.
[RFC2256] Wahl, M. "A Summary of the X.500(96) User [RFC2256] Wahl, M. "A Summary of the X.500(96) User
Schema for use with LDAPv3", RFC 2256, Schema for use with LDAPv3", RFC 2256,
December 1997. December 1997.
skipping to change at line 1079 skipping to change at line 1297
[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.
[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: December 2003 [page 24]
[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
Applications (IDNA)", RFC 3490, March 2003. Applications (IDNA)", RFC 3490, March 2003.
[CRISP-REQ] Newton, A. "Cross Registry Internet Service
Protocol (CRISP) Requirements", draft-ietf-
crisp-requirements-05, May 2003.
[FIRS-ARCH] Hall, E. "The Federated Internet Registry
Service: Architecture and Implementation
Guide", draft-ietf-crisp-firs-arch-00, May
2003.
[FIRS-ASN] Hall, E. "Defining and Locating Autonomous
System Numbers in the Federated Internet
Registry Service", draft-ietf-crisp-firs-asn-
00, May 2003.
[FIRS-CONTCT] Hall, E. "Defining and Locating Contact
Persons in the Federated Internet Registry
Service", draft-ietf-crisp-firs-contact-00,
May 2003.
[FIRS-CORE] Hall, E. "The Federated Internet Registry
Service: Core Elements", draft-ietf-crisp-
firs-core-00, May 2003.
[FIRS-DNS] Hall, E. "Defining and Locating DNS Domains in
the Federated Internet Registry Service",
draft-ietf-crisp-firs-dns-00, May 2003.
[FIRS-DNSRR] Hall, E. "Defining and Locating DNS Resource
Records in the Federated Internet Registry
Service", draft-ietf-crisp-firs-dnsrr-00, May
2003.
[FIRS-IPV4] Hall, E. "Defining and Locating IPv4 Address
Blocks in the Federated Internet Registry
Service", draft-ietf-crisp-firs-ipv4-00, May
2003.
[FIRS-IPV6] Hall, E. "Defining and Locating IPv6 Address
Blocks in the Federated Internet Registry
Hall I-D Expires: December 2003 [page 25]
Service", draft-ietf-crisp-firs-ipv6-00, May
2003.
[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 12. 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. Acknowledgments 13. Acknowledgments
Hall I-D Expires: December 2003 [page 28]
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.
Portions of this document were funded by Verisign Labs. Portions of this document were funded by Verisign Labs.
The first version of this specification was co-authored by Andrew The first version of this specification was co-authored by Andrew
Newton of Verisign Labs, and subsequent versions continue to be Newton of Verisign Labs, and subsequent versions continue to be
developed with his active participation. developed with his active participation.
13. Changes from Previous Versions 14. Changes from Previous Versions
draft-ietf-crisp-fir-arch-00:
draft-ietf-crisp-firs-arch-01:
* Several clarifications and corrections have been made.
draft-ietf-crisp-firs-arch-00:
* Restructured document set, separating the architectural * Restructured document set, separating the architectural
discussion from the technical descriptions. discussion from the technical descriptions.
* 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.
* An acknowledgements section was added. * An acknowledgements section was added.
Hall I-D Expires: December 2003 [page 26] draft-hall-ldap-whois-01:
draft-hall-FIRS-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.
Hall I-D Expires: December 2003 [page 29]
* Figures changed to show complete sets of object classes, to * Figures changed to show complete sets of object classes, to
improve inheritance visibility. improve inheritance visibility.
* Clarified the handling of reverse-lookup domains (zones * Clarified the handling of reverse-lookup domains (zones
within the in-addr.arpa portion of the DNS hierarchy) in within the in-addr.arpa portion of the DNS hierarchy) in
the inetDnsDomain object class reference text. the inetDnsDomain object class reference text.
* Referrals now use regular LDAP URLs (multiple responses * Referrals now use regular LDAP URLs (multiple responses
with explicit hostnames and port numbers). Prior editions with explicit hostnames and port numbers). Prior editions
of this specification used LDAP SRV resource records for of this specification used LDAP SRV resource records for
skipping to change at line 1219 skipping to change at line 1400
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: December 2003 [page 27] 15. Full Copyright Statement
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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
Hall I-D Expires: December 2003 [page 30]
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
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: December 2003 [page 28] Hall I-D Expires: December 2003 [page 31]
 End of changes. 

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