Network Working Group C. Malamud Internet-Draft R. Malamud Expires: November 13, 2002 Internet Multicasting Service M. Rose Dover Beach Consulting May 15, 2002 Overview of Assigned Name and Number Allocation (ANANA) draft-anana-overview-00 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 Malamud, et al. Expires November 13, 2002 [Page 1] Internet-Draft ANANA May 2002 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 . . . . . . . . . . . . . . . . . . . . 3 2. Examples of Namespaces . . . . . . . . . . . . . . . . . . . . 5 2.1 RFC-Based Namespaces . . . . . . . . . . . . . . . . . . . . . 5 2.2 Moderately Dynamic Namespaces . . . . . . . . . . . . . . . . 6 2.3 Working Document Namespaces . . . . . . . . . . . . . . . . . 7 2.4 Archival Document Namespaces . . . . . . . . . . . . . . . . . 8 3. Common Aspects of These Examples . . . . . . . . . . . . . . . 10 4. Assigned Names and Numbers Allocation (ANANA) . . . . . . . . 12 5. An Example: IANA Access Types . . . . . . . . . . . . . . . . 13 5.1 The Fore Part . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 The Namespace Part . . . . . . . . . . . . . . . . . . . . . . 15 5.3 The Aft Part . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Operation of the Namespace . . . . . . . . . . . . . . . . . . 20 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 A. Security Considerations . . . . . . . . . . . . . . . . . . . 26 B. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 C. Further Information . . . . . . . . . . . . . . . . . . . . . 28 D. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 E. IANA Access Types (access-types.xml) . . . . . . . . . . . . . 30 F. registry.dtd . . . . . . . . . . . . . . . . . . . . . . . . . 33 G. access-types.legacy.xslt . . . . . . . . . . . . . . . . . . . 36 H. access-types.xslt.xml . . . . . . . . . . . . . . . . . . . . 39 I. Public Keys for the IETF . . . . . . . . . . . . . . . . . . . 40 I.1 SSL Certificate for www.ietf.org. . . . . . . . . . . . . . . 40 I.2 PGP Key for ietf-registrar@ietf.org. . . . . . . . . . . . . . 41 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42 Malamud, et al. Expires November 13, 2002 [Page 2] Internet-Draft ANANA May 2002 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: o The delegation of a unique range of IP address space to an assignee.[1] o The assignment of the right amount of address space to conserve a limited resource.[2] o The assignment by the right authority in order to minimize router table sizes.[3] o 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 Malamud, et al. Expires November 13, 2002 [Page 3] Internet-Draft ANANA May 2002 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. Malamud, et al. Expires November 13, 2002 [Page 4] Internet-Draft ANANA May 2002 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: Number Description Reference ------ ------------------------------------------------- --------- 1 Request [RFC1058] 2 Response [RFC1058] 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 Malamud, et al. Expires November 13, 2002 [Page 5] Internet-Draft ANANA May 2002 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: http 80/tcp World Wide Web HTTP http 80/udp World Wide Web HTTP www 80/tcp World Wide Web HTTP www 80/udp World Wide Web HTTP www-http 80/tcp World Wide Web HTTP www-http 80/udp World Wide Web HTTP # Tim Berners-Lee 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 Malamud, et al. Expires November 13, 2002 [Page 6] Internet-Draft ANANA May 2002 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: o An application form[21] and published registry [22] for MIME Media Types. o 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: o An application form is filled out. o An application form is checked for correctness. o A manual approval process is activated, temporarily deferring a decision on approval. o Approval is granted. o The new assignment is added to the namespace. o 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: Malamud, et al. Expires November 13, 2002 [Page 7] Internet-Draft ANANA May 2002 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 "" 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] Malamud, et al. Expires November 13, 2002 [Page 8] Internet-Draft ANANA May 2002 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] Malamud, et al. Expires November 13, 2002 [Page 9] Internet-Draft ANANA May 2002 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: o 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. o 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: o A policy process, where a naming authority is formed, claims authority over a namespace, and develops policies for the allocation of that name space. o 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. o 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. Malamud, et al. Expires November 13, 2002 [Page 10] Internet-Draft ANANA May 2002 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: o 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. o The upper limit is based on technology. There are limits to current technology used to manage document models and services based on XML. Malamud, et al. Expires November 13, 2002 [Page 11] Internet-Draft ANANA May 2002 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: o 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. o 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. Malamud, et al. Expires November 13, 2002 [Page 12] Internet-Draft ANANA May 2002 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: ACCESS TYPES The RFC "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures" [RFC2048] establishs a list of "Access Type" names. The IANA registry of these codes is listed here. Access Type Name Reference ---- ----------------------------------------------------- --------- (1) ftp [RFC2048] (2) anon-ftp [RFC2048] (3) tftp [RFC2048] (4) local-file [RFC2048] (5) mail-server [RFC2048] REFERENCES [RFC2048] Freed, N., J. Klensin, and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996. (last updated Apr 30 2001) [] This document is typical of IANA registries. There are a few variations in format when compared to other IANA namespaces, including: o Some documents contain several namespaces. o Some namespaces are broken up into blocks with different purposes and sometimes with special instructions for each block. o References include people as well as RFCs. o Some namespaces have unique ID's that are composed of two columns, or use an alphanumeric name. o Some namespaces have unique ID's that are ambiguous (e.g., in this case, there is no name for the unique ID). Malamud, et al. Expires November 13, 2002 [Page 13] Internet-Draft ANANA May 2002 We model the registry in three sections, which are named "", "", and "." 5.1 The Fore Part We start with a simple XML document that refers to a Document Type Definition, registry.dtd (see Appendix F). First, we construct the "" part of our XML document: The RFC "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures" [RFC2048] establishs a list of "Access Type" names. The IANA registry of these codes is listed here. The "" element contains the following sections: o 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. o The "" element contains the title of this registry and an ANANA URI by which it can be accessed. o The "" 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. o The descriptive text in the original ASCII document is contained in a "" element. o The date the document was last updated by the IANA is contained in Malamud, et al. Expires November 13, 2002 [Page 14] Internet-Draft ANANA May 2002 a "" 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 "" section of the document: