Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 13, 2002.

Copyright Notice

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

Abstract

A service is described that separates policy from process for the allocation and distribution of names and numbers in a coordinated fashion (a "namespace") according to procedures and policies set by an individual, institutional body, or group (a "naming authority"). These namespaces are populated and changed through requests to allocate a name by an individual, institutional body, or group (an "assignee") and the contents of the namespace is distributed to the public (the "public"). The service specifies a mechanism for the creation of namespaces, allocation rules, and distribution paths and is available in batch and interactive modes. An implementation of the service on some test data is described.

Table of Contents

1.  Scope of Problem Space
2.  Examples of Namespaces
2.1  RFC-Based Namespaces
2.2  Moderately Dynamic Namespaces
2.3  Working Document Namespaces
2.4  Archival Document Namespaces
3.  Common Aspects of These Examples
4.  Assigned Names and Numbers Allocation (ANANA)
5.  An Example: IANA Access Types
5.1  The Fore Part
5.2  The Namespace Part
5.3  The Aft Part
6.  Operation of the Namespace
7.  Summary
§  References
§  Authors' Addresses
A.  Security Considerations
B.  IANA Considerations
C.  Further Information
D.  Acknowledgements
E.  IANA Access Types (access-types.xml)
F.  registry.dtd
G.  access-types.legacy.xslt
H.  access-types.xslt.xml
I.  Public Keys for the IETF
I.1  SSL Certificate for www.ietf.org.
I.2  PGP Key for ietf-registrar@ietf.org.
§  Full Copyright Statement

1. Scope of Problem Space

Coordinated names and numbers are crucial to the operation of the Internet. IP numbers, for example, must be allocated to meet several goals:

• The delegation of a unique range of IP address space to an assignee.[1]
• The assignment of the right amount of address space to conserve a limited resource.[2]
• The assignment by the right authority in order to minimize router table sizes.[3]
• The identification of private address space for use in applications such as NATS.[4]

The assignment of IP numbers operates at four different levels:

1. The IETF created the namespace and the initial allocations are managed by ICANN, which delegates blocks of addresses to certified regional registries[5] and publishes the resulting allocations.[6]
2. Regional registries (which currently include RIPE[7], APNIC[8], and ARIN[9]) delegate blocks of addresses to Internet Service Providers.
3. The ISPs delegate space to individual networks.
4. Networks manage and delegate their space to end-users.

Most of the heavy lifting in this process occurs at levels 2 and 3 and a great deal of intricate infrastructure has built up to properly allocate these addresses. At level 4, the process ranges from ad hoc to automatic.

At level 1, where the initial allocations are made, the namespace is fairly simple. The bulk of the allocations are done between the IANA and three regional registries. Additional allocations are for multicast addresses, which is handled directly by the IANA,[10] and a few neutral address allocation groups such as EP.NET,[11] which operates as a neutral body for managing address space at exchange points.

These top-level assignments of IP address space have interesting commonalities with a large class of other namespaces. These namespaces are global, public, of moderate size, and the mechanics of allocation and distribution are conceptually similar. The determination of naming policies can be cleanly separated from the mechanics of allocation and distribution.

We next examine in more detail four types of namespaces to illustrate these commonalities.

2. Examples of Namespaces

2.1 RFC-Based Namespaces

A large number of namespaces are produced as the result of an RFC. The RFC specifies a series of parameters, which are then gathered by the IANA into a registry and published as a series of ASCII files.[12] For example, the IANA "RIP Types" document[13] is a handy encapsulation of information extracted from RFCs 1058[14] and 2091[15].

While a great deal of work goes into reaching consensus and review on the contents of an RFC, the registries themselves are all fairly similar. The format of these documents is semi-regular. For example, RIP Types consists of a title line, a short description, a table with columns for the type number, a description, and the referencing RFC. The document concludes with a list of references, a last updated date stamp, and a null field. By contrast, the namespace adjacent to RIP Types is Radius Types[16], which has the date references at the head, followed by a series of lists.

The main part of each namespace is a series of lists formatted as a table. In RIP Types, for example, the namespace consists of:

The columns in this table consist of the number being assigned, some descriptive text, and an internal reference to an RFC. In some other IANA-maintained lists, the namespace consists of two numbers, or an alphanumeric name. The "Description" field sometimes has other names (e.g., "Comment" or "Operation"), and references include people as well as RFCs.

The creation of the RFCs requires a great deal of thought, experience, implementation and consensus. However, once a decision is made to publish the RFC, the corresponding publication of a namespace registry is conceptually simple. In essence, the IETF leadership (e.g., IESG, working group chairs, authors of drafts), in cooperation with the RFC Editor are the naming authority, and limited naming authority has been delegated to the IETF/IANA/ICANN/ISOC secretariats to modify the spaces according to a set of rules.

All of these namespaces are maintained as semi-structured ASCII documents and published in a single well-known directory. No mirroring system is in place for the data. No announcements are made of changes to namespaces or the creation of new namespaces. The documents are formatted in a way that mixes content and presentation and thus makes further processing of the information (e.g., the creation of a field-based search engine) difficult.

2.2 Moderately Dynamic Namespaces

There are a series of namespaces that start life in the same way as the relatively static documents described in the previous section, but change more rapidly because the assignees are more numerous. Typical are port number assignments [17], which are crucial to the operation of any computer connected to the Internet. The linking of applications to incoming Internet traffic, the configuration of security, and many other operations depend on the systematic administration of this namespace.

The authority for the assignment of port numbers is the IETF, which has contracted with ICANN for the administration of that naming authority through its administration of the IANA. [18]

A port assignment consists of a few pieces of information. Here is an example for port 80:

Port assignments are split into three classes, and the workflow for a new port assignment varies depending on the class:

1. Well-known ports are carefully administered under the stern guidance of the IESG and the RFC Editor, which is supported by the IETF/IANA/ICANN/ISOC secretariats.
2. Registered ports, on the other hand, are made available on a more routine basis. The secretariat at the ICANN IANA has a set of procedures to follow. The prospective assignee fills out a form and the form is queued for approval by the secretariat. They validate fields on the forms, look for obvious anomalies (e.g., mass registrations by one entity) and then approve the port assignment.
3. Finally, Dynamic and Private Ports are not allocated, but rather are used through the rules defined in RFCs. They are part of the namespace but are not available for assignment.

The policy aspects of the port assignment process are thus fairly simple, consisting of an application form,[20] a secretariat function for approving routine assignments, and a naming authority consisting of the IESG to which exceptions are routed. When assignments are made, they are reflected in the ASCII-based document "Port Numbers" which is updated roughly every month.[19]

In addition to port numbers, some other examples of moderately dynamic namespaces include:

• An application form[21] and published registry [22] for MIME Media Types.
• A list of root zone administrators for the DNS for country code TLDs[23] and lists of registry operators and registrars for generic TLDs maintained by ICANN.

In each case, the namespaces share a set of common steps:

• An application form is filled out.
• An application form is checked for correctness.
• A manual approval process is activated, temporarily deferring a decision on approval.
• Approval is granted.
• The new assignment is added to the namespace.
• The namespace is published as an ASCII document.

2.3 Working Document Namespaces

Internet-Drafts, are a registry of working documents. After 6 months, an Internet-Draft expires. I-Ds are accepted by the IETF secretariat using email, are checked for validity[24], and then are issued with an email announcement and by placing the document in the repository. A large number of sites mirror the repository using a variety of techniques including email-based responders and ftp-based mirroring. A few sites maintain a mirror over time of this repository.

Internet-Drafts thus consists of three namespaces:

1. A list of official mirror sites.
2. A list of unique names for current documents.
3. A list of unique names for documents that are no longer current.

While the list of official mirror sites is presently administratively maintained, there is presumably no reason why this list could not be automated. If a prospective mirror site presents itself, a simple check to see if the proposed site is current, followed by periodic checks, would provide an easy way of managing this list.

The current documents are assigned using a simple naming mechanism, such as "draft-anana-datastore-01." In the current Internet-Draft system, there are two types of drafts issued, each with their own unique prefix. "Official" IETF drafts (e.g., the product of a working group) are named as draft-ietf-{wgname}-{label1}-{label2}-{revision}. "Individual" submissions are named as draft-{authorname}-{label1}-{label2}-{revision}.

Naming of Internet-Drafts thus follows a simple delegation procedure. For official documents, the IETF delegates naming authority to a working group, which in turn assigns unique labels to each document. Once a document is assigned a label, the author is able to revise the document (with possible approval required by the working group chair).

The list of documents that are expired are considered obsolete and thus useful only for historical or quantitative analysis[25], but presumably the archive is needed by the naming authority to maintain uniqueness of names over time.

2.4 Archival Document Namespaces

The Request for Comments series is a permanent registry of documents that are approved by the RFC Editor in conjunction with the IETF and the IESG. Entries in this registry consist of an RFC number, author name, and a variety of other fields as documented in the <front /> element of [26]. The only information that is deleted by the registry maintainer is pointers to the actual document when parts of the permanent archive are lost as in the case of some of the older RFCs. A large number of sites around the net mirror the repository for further processing.

The RFC namespace has four components:

1. A list of documents that have been submitted for approval.[27]
2. A list of documents that have been approved.[28]
3. A list of alternative repositories.[29]
4. A list of errata in published documents.[30]

While Internet-Drafts require documents to be in the proper format ("well-formed"), there are few concerns over the contents of those documents. In the case of RFCs, however, considerable effort is put into making sure the documents published meet a variety of presentation and content criteria.[31][32]

Once published, however, the namespace becomes a crucial part of the Internet infrastructure, as RFCs are often cited in Internet-Drafts, other RFCs, technical literature, and software modules. For example, RFC 822[33] is cited in over 70,000 pages on the Internet.[34]

3. Common Aspects of These Examples

The examples in the previous section are all illustrations of name and number registries. The authority differs among the namespaces, but the policy aspect consists of the creation of the registry, the determination of policies for approval, and the delegation of naming authority to one or more institutions or individuals.

The similarities break down when we stretch the problem space to include very small or very large registries. Two examples illustrate problems outside the scope of this document:

• The list of root servers differs from the name spaces discussed above because it is very small, very stable, and hard-wired into millions of pieces of code. As such, this small list is more a well-known constant than a registry that changes over time.
• Delegation of IP addresses or domain names beyond the top-level allocation to registries and the process of certifying new registries.

In particular, large-scale registries such as 2nd-level domain registries are the purview of other protocols such as RRP[35] EPP[36], and OpenSRS.[37]

However, for small and medium-sized registries, the namespaces all have three processes:

• A policy process, where a naming authority is formed, claims authority over a namespace, and develops policies for the allocation of that name space.
• An allocation process, consisting in a series of interactions between an assignee and the naming authority, possibly resulting in a delegation or allocation of a namespace. This is often carried out by a secretariat under the direction of policies set by a naming authority.
• A distribution process, where the allocations in the namespace are made known to the public.

As with building new applications in general, namespace applications share many core functions and have reinvented those same functions many times. In addition to providing support for many common core functions, separating policy from allocation and distribution makes it easier for an organization to create a namespace or to change the delegation of naming authority.

The problem space encompasses a class of registries in the range of a few dozen to a few million names and an update speed that is relatively slow. The boundaries of this class are based on two limits:

• The lower limit is based on time. Since there is human overhead in creating a namespace, this investment in time only makes sense if there are enough names to manage.
• The upper limit is based on technology. There are limits to current technology used to manage document models and services based on XML.

4. Assigned Names and Numbers Allocation (ANANA)

The Assigned Names and Numbers Allocation (ANANA) protocol specifies a method of modeling a namespace as an XML document containing one or more lists of repeating elements and provides a service specification to perform operations on those documents. Note that the modeling of the namespace as an XML document does not presume that the implementation of the service uses XML for the data repository or keeps each namespace or registry as a single file.

The service is described in a series of three Internet-Drafts. This document provides an overview of the service and how it is being implemented. The other two documents are:

• The ANANA Datastore[38] defines how a namespace is defined, including allocation rules, distribution paths, and service definitions of the system in interactive and batch modes.
• The Implementation of ANANA on Namespaces at Anana.Org[39] describes a mirroring process whereby a series of existing namespaces are transformed into ANANA-based namespaces and run in parallel with the existing namespaces and installed on a set of coordinated ANANA servers provisioned in key Internet exchange points.

5. An Example: IANA Access Types

We use a very simple example of a namespace, in this case the namespace of Access Types[41] maintained by the IANA:

This document is typical of IANA registries. There are a few variations in format when compared to other IANA namespaces, including:

• Some documents contain several namespaces.
• Some namespaces are broken up into blocks with different purposes and sometimes with special instructions for each block.
• References include people as well as RFCs.
• Some namespaces have unique ID's that are composed of two columns, or use an alphanumeric name.
• Some namespaces have unique ID's that are ambiguous (e.g., in this case, there is no name for the unique ID).

We model the registry in three sections, which are named <fore />, <namespace />, and <aft />.

5.1 The Fore Part

We start with a simple XML document that refers to a Document Type Definition, registry.dtd (see registry.dtd). First, we construct the <fore /> part of our XML document:

The <fore /> element contains the following sections:

• At the top is a declaration that this is an XML document and thus must be well-formed and a DTD declaration that this document must meet to be considered valid.
• The <registry /> element contains the title of this registry and an ANANA URI by which it can be accessed.
• The <registrar /> element contains the identity of the creator, in this case as an ANANA URI accessible on a host called anana.org in a registry called identity.
• The descriptive text in the original ASCII document is contained in a <comment /> element.
• The date the document was last updated by the IANA is contained in a <date /> element.

The use of an ANANA URI in a registry is a common one. The ANANA service manages namespaces by enforcing an access control mechanism on allocation and distribution mechanisms, usually by equating identity with an authenticated namespace entry. We will revisit the topic shortly.

5.2 The Namespace Part

Next, we add the <namespace /> section of the document:

This section of the document contains the list of unique values that make up a namespace. It contains the following sections:

• A <namespace /> element has a unique id within this registry and a descriptive title.
• The <template /> defines the method used for generating unique ids for this namespace. It contains information that can be used to give columns titles in a pretty-print application as well as information that the ANANA service uses to allocate unique names and numbers.
• Next is a <block /> element containing a series of <entry /> elements. This is the actual data in this namespace.
• Within the <entry /> elements, a <citation /> element contains another ANANA URI, this one pointing to a citation library of RFCs.

5.3 The Aft Part

Finally, we add the <aft /> element to the document:

The <aft /> element contains the definitions of how this data is to managed by the ANANA service. It contains three kinds of rules which govern access to the namespace, and which actions are triggered before and after changes to the namespace occur.

The <acl /> element is used to define access control lists on portions of the namespace. In this example, three <ac /> elements are defined.

• The first gives permission to perform any operations on any part of the name space to the remote user authenticated as ietf.org.
• The second gives read permission over the entire namespace to the remote user authenticated as iana.org.
• The third gives read and write permission over the entries to any remote user present in a registry of IETF namespace to any other users identified in the identities registry.

The <conformance /> element is used when a change to the namespace is attempted by a remote user. In this example, any changes to the entries in the <entry /> elements are passed to a simple gateway program. The program performs the following steps:

• The ANANA service passes the proposed updates to the program.
• The program tells the ANANA service to defer the changes for now. ANANA passes the information to the prospective assignee.
• The program formats the updates as a simple ASCII message and sends it via electronic mail to a list of users who have naming authority over the document, in this case IETF working group chairs and IESG members.
• The electronic mail contains a reply-to address which will address a reply to the ANANA service.
• If one of the remote users replies to the message with appropriate authentication provided, the change is resubmitted and committed. (Q: who is responsible for informing the user user who submitted the change?)

The <reporting /> element is used to pass any changes in the namespace to an external resource for further processing. In this case, the external program performs the following steps:

• The program gets the entire namespace from the ANANA service.
• An XSLT style sheet (see access-types.legacy.xslt is applied to the namespace to transform it into the current ASCII format (see access-types.xslt.xml).
• The transformed document is sent by electronic mail to a distribution list.

The subject attribute, which is used in three sections, uses XPath[42] to specify a portion of the namespace to which an action applies. XPath gives considerable flexibility in applying a rule to a portion of a document. Two typical examples are:

• subject='/' applies a rule to the entire namespace.
• subject='/registry/middle/namespace/block' applies a rule to all namespaces in the document, but excludes front matter (such as the identities of registrars and description of the namespace) and back matter (such as the specification of access control or conformance and reporting triggers).

Triggers use external resources to provide a clean split between policy and the mechanics of allocation and distribution. Manual approval, validation checks on applications, and other aspects of allocation policy reside external to the ANANA service, but the enforcement of those policies can be specified in the namespace.

ANANA URIs are used frequently in the definition of this namespace. The registrar, the identity of assignees, the subjects of access control lists, and citations all use ANANA references. This allows a registry to rely on other namespaces for identity and citation.

6. Operation of the Namespace

The ANANA Access Types namespace is a mirror of the "real" namespace operated by the IANA. Two methods are available to keep the namespace in synchronization with the IANA namespace:

• The remote user ietf.org has change control over the document, and access to the ANANA datastore in either batch or interactive modes can make changes to entries or delegate change control to another body, such as iana.org.
• Failing assertion of naming authority within the ANANA scheme, a simple program on anana.org uses FTP to periodically monitor the original file at iana.org. A diff is performed if the file has changed. If the change is the addition of a new entry, the update is automatically processed and a distribution trigger logs the operation. If the change is the deletion of an entry or any other change to the namespace, the diff is logged and system administrators are notified.

Because anonymous access is allowed for read operations on this namespace, it is a simple matter for other systems to mirror the namespace, either through distribution triggers or by a simple datastore read using ANANA or HTTP URIs.

A more systematic mirroring process for this namespace is also provided through a registry of "Core ANANA Servers" maintained at anana.org. This registry contains a manually-approved list of other ANANA servers that maintain full mirrors of core namespaces.

Another ANANA registry is used to bootstrap authentication for this namespace. The public keys for the IETF (see Public Keys for the IETF) were compared by two parties, and then entered into the anana.org identity registry. Public keys were not available for iana.org, icann.org, or rfc-editor.org.

7. Summary

Assigned Name and Number Allocation (ANANA) is a policy-neutral service for managing namespaces. It can be accessed in batch and interactive modes and includes mechanisms for defining the namespace and specifying access control, conformance triggers for allocation, and distribution triggers for publication.

References

Authors' Addresses

Appendix A. Security Considerations

Security and stability are an integral part of the ANANA process and are discussed in [38] and [39].

Appendix B. IANA Considerations

Technical considerations for the IANA are discussed in [38]. Additional considerations are discussed in [39].

Appendix C. Further Information

A mailing list on the topic of the ANANA is available. To join, use one of the following URIs:

• mailto:anana-discuss-request@anana.org
• anana://anana.org/distribute/anana/discuss
• http://anana.org/distribute/anana/discuss

Appendix D. Acknowledgements

The authors gratefully acknowledge the comments of:

Appendix E. IANA Access Types (access-types.xml)

This is an example of using the registry.dtd to create the IANA Access Types[41] namespace.

Appendix F. registry.dtd

This is the Document Type Declaration used to produce IANA Access Types (access-types.xml).

Appendix G. access-types.legacy.xslt

The following XSLT style sheet was used as part of a reporting trigger on IANA Access Types (access-types.xml):

Appendix H. access-types.xslt.xml

This is the result of applying the transformation specified in access-types.legacy.xslt to IANA Access Types (access-types.xml):

Appendix I. Public Keys for the IETF

I.1 SSL Certificate for www.ietf.org.

I.2 PGP Key for ietf-registrar@ietf.org.

Full Copyright Statement

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

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

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

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

Acknowledgement

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