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:
1
RFC2048
RFC2048
ftp
2
RFC2048
anon-ftp
3
RFC2048
tftp
4
RFC2048
local-file
Malamud, et al. Expires November 13, 2002 [Page 15]
Internet-Draft ANANA May 2002
5
RFC2048
mail-server
This section of the document contains the list of unique values that
make up a namespace. It contains the following sections:
o A "" element has a unique id within this registry and
a descriptive title.
o The "" 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.
o Next is a "" element containing a series of ""
elements. This is the actual data in this namespace.
o Within the "" elements, a "" element contains
another ANANA URI, this one pointing to a citation library of
RFCs.
5.3 The Aft Part
Finally, we add the "" element to the document:
Malamud, et al. Expires November 13, 2002 [Page 16]
Internet-Draft ANANA May 2002
The "" 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 "" element is used to define access control lists on
portions of the namespace. In this example, three "" elements
are defined.
o The first gives permission to perform any operations on any part
of the name space to the remote user authenticated as ietf.org.
o The second gives read permission over the entire namespace to the
remote user authenticated as iana.org.
o The third gives read and write permission over the entries to any
Malamud, et al. Expires November 13, 2002 [Page 17]
Internet-Draft ANANA May 2002
remote user present in a registry of IETF namespace to any other
users identified in the identities registry.
The "" 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 "" elements are passed to a simple gateway
program. The program performs the following steps:
o The ANANA service passes the proposed updates to the program.
o The program tells the ANANA service to defer the changes for now.
ANANA passes the information to the prospective assignee.
o 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.
o The electronic mail contains a reply-to address which will address
a reply to the ANANA service.
o 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 "" 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:
o The program gets the entire namespace from the ANANA service.
o An XSLT style sheet (see Appendix G is applied to the namespace to
transform it into the current ASCII format (see Appendix H).
o 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:
o subject='/' applies a rule to the entire namespace.
o 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
Malamud, et al. Expires November 13, 2002 [Page 18]
Internet-Draft ANANA May 2002
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.
Malamud, et al. Expires November 13, 2002 [Page 19]
Internet-Draft ANANA May 2002
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:
o 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.
o 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 Appendix I) 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.
Malamud, et al. Expires November 13, 2002 [Page 20]
Internet-Draft ANANA May 2002
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.
Malamud, et al. Expires November 13, 2002 [Page 21]
Internet-Draft ANANA May 2002
References
[1] Hinden, R., "Proposed TLA and NLA Assignment Rules", RFC 2450,
December 1998.
[2] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12,
RFC 2050, November 1996.
[3] Rekhter, Y. and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[4] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[5] ICANN, "Criteria for Establishment of New Regional Internet
Registries", ICP 2, June 2001, .
[6] IANA, "Internet Protocol Version 4 Address Space", December
2001, .
[7] RIPE NCC, "European Internet Registry Policies and Procedures",
RIPE 180, October 1998, .
[8] APNIC, "Policies for IPv4 address space management in the Asia
Pacific region", APNIC 086, December 2001, .
[9] ARIN, "Guidelines - IPv4 ISP Initial Request for IP Address
Space", April 2002, .
[10] IANA, "Application for Multicast Address", August 2000, .
[11] EP.NET, "Exchange Point Information", April 2002, .
[12] IANA, "Protocol Numbers and Assignment Services", April 2002,
.
[13] IANA, "RIP Type Assignments", May 2001, .
[14] Hedrick, C., "Routing Information Protocol", RFC 1058, June
1988.
Malamud, et al. Expires November 13, 2002 [Page 22]
Internet-Draft ANANA May 2002
[15] Meyer, G. and S. Sherry, "Triggered Extensions to RIP to
Support Demand Circuits", RFC 2091, January 1997.
[16] IANA, "Radius Type Assignments", March 2002, .
[17] IANA, "Port Number Assignments", April 2002, .
[18] ICANN, "IETF/ICANN Memorandum of Understanding Concerning the
Technical Work of the IANA", March 2000, .
[19] Internet Web Archive, "Wayback Search For http://www.iana.org/
assignment/port-numbers", April 2002, .
[20] IANA, "Application for Protocol Number", August 2000, .
[21] IANA, "Application for MIME Media Types", January 2002, .
[22] IANA, "MIME Media Types", January 2002, .
[23] IANA, "Root-Zone Whois Index", November 2001, .
[24] IETF, "Guidelines to Authors of Internet-Drafts", November
2001, .
[25] Rose, M. and D. Crocker, "Toward a Quantitative Analysis of
IETF Productivity", draft-etal-ietf-analysis-00 (work in
progress), March 2002.
[26] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
[27] RFC Editor, "RFC Queue", May 2002, .
[28] RFC Editor, "RFC Database", March 2002, .
[29] RFC Editor, "RFC Repositories", January 2002, .
Malamud, et al. Expires November 13, 2002 [Page 23]
Internet-Draft ANANA May 2002
[30] RFC Editor, "RFC Errata", April 2002, .
[31] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[32] Braden, B. and J. Reynolds, "Instructions to Request for
Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-01 (work
in progress), April 2002.
[33] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982.
[34] Google, "Search for 'RFC 822'", May 2002, .
[35] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M. and
J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", RFC 2382, August 1998.
[36] Hollenbeck, S., "Extensible Provisioning Protocol", draft-ietf-
provreg-epp-06 (work in progress), January 2002.
[37] Tucows, "OpenSRS API v2.53 Documentation", April 2002, .
[38] Rose, M., "The ANANA Datastore", draft-anana-datastore-00 (work
in progress), April 2002, .
[39] IMS, "Implementation of ANANA on Namespaces at Anana.Org",
draft-anana-iana-00 (work in progress), April 2002.
[40] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
October 2000, .
[41] IANA, "Access Types", April 2001, .
[42] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", W3C REC-xpath, November 1999, .
[43] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC-
xslt, November 1999, .
Malamud, et al. Expires November 13, 2002 [Page 24]
Internet-Draft ANANA May 2002
Authors' Addresses
Carl Malamud
Internet Multicasting Service
P.O. Box 217
Stewarts Point, CA 95450
US
EMail: carl@media.org
URI: http://not.invisible.net
Rebecca Malamud
Internet Multicasting Service
P.O. Box 217
Stewarts Point, CA 95450
US
EMail: webchick@media.org
URI: http://not.invisible.net/
Marshall T. Rose
Dover Beach Consulting
P.O. 255268
Sacramento, CA 95865-5268
Phone: +1 916 483 8878
EMail: mrose@dbc.mtview.ca.us
Malamud, et al. Expires November 13, 2002 [Page 25]
Internet-Draft ANANA May 2002
Appendix A. Security Considerations
Security and stability are an integral part of the ANANA process and
are discussed in [38] and [39].
Malamud, et al. Expires November 13, 2002 [Page 26]
Internet-Draft ANANA May 2002
Appendix B. IANA Considerations
Technical considerations for the IANA are discussed in [38].
Additional considerations are discussed in [39].
Malamud, et al. Expires November 13, 2002 [Page 27]
Internet-Draft ANANA May 2002
Appendix C. Further Information
A mailing list on the topic of the ANANA is available. To join, use
one of the following URIs:
o mailto:anana-discuss-request@anana.org
o anana://anana.org/distribute/anana/discuss
o http://anana.org/distribute/anana/discuss
Malamud, et al. Expires November 13, 2002 [Page 28]
Internet-Draft ANANA May 2002
Appendix D. Acknowledgements
The authors gratefully acknowledge the comments of:
Malamud, et al. Expires November 13, 2002 [Page 29]
Internet-Draft ANANA May 2002
Appendix E. IANA Access Types (access-types.xml)
This is an example of using the Appendix F to create the IANA Access
Types[41] namespace.
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.
1
RFC2048
RFC2048
ftp
2
RFC2048
anon-ftp
Malamud, et al. Expires November 13, 2002 [Page 30]
Internet-Draft ANANA May 2002
3
RFC2048
tftp
4
RFC2048
local-file
5
RFC2048
mail-server
Malamud, et al. Expires November 13, 2002 [Page 31]
Internet-Draft ANANA May 2002
Malamud, et al. Expires November 13, 2002 [Page 32]
Internet-Draft ANANA May 2002
Appendix F. registry.dtd
This is the Document Type Declaration used to produce Appendix E.
%rfc2629.dtd;
Malamud, et al. Expires November 13, 2002 [Page 33]
Internet-Draft ANANA May 2002
Malamud, et al. Expires November 13, 2002 [Page 34]
Internet-Draft ANANA May 2002
Malamud, et al. Expires November 13, 2002 [Page 35]
Internet-Draft ANANA May 2002
Appendix G. access-types.legacy.xslt
The following XSLT style sheet was used as part of a reporting
trigger on Appendix E:
|
|
Reference |
----- |
----------------------------------------------------- |
--------- |
(last updated
)
[]
Malamud, et al. Expires November 13, 2002 [Page 36]
Internet-Draft ANANA May 2002
|
|
|
|
[] |
,
,
and
, "
,
",
Malamud, et al. Expires November 13, 2002 [Page 37]
Internet-Draft ANANA May 2002
,
,
.
|
Malamud, et al. Expires November 13, 2002 [Page 38]
Internet-Draft ANANA May 2002
Appendix H. access-types.xslt.xml
This is the result of applying the transformation specified in
Appendix G to Appendix E:
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
[RFC2048] Freed, N., J. Klensin, and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
RFC 2048, Innosoft International, Inc., MCI, USC/Information
Sciences Institute, November 1996.
(last updated April 30 2001)
[]
Malamud, et al. Expires November 13, 2002 [Page 39]
Internet-Draft ANANA May 2002
Appendix I. Public Keys for the IETF
I.1 SSL Certificate for www.ietf.org.
bulk% curl -v --egd-file /var/run/egd-pool --head https://www.ietf.org/
* SSL connection using EDH-RSA-DES-CBC3-SHA
* Server certificate:
* subject: /C=US/ST=Virginia/L=Reston/O=Foretec Seminars Inc.
/OU=IETF/CN=www.ietf.org
* start date: 2001-09-19 14:46:45 GMT
* expire date: 2002-09-19 14:46:45 GMT
* common name: www.ietf.org (matched)
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc
/OU=Certification Services Division/CN=Thawte Server CA
/Email=server-certs@thawte.com
* Connected to www.ietf.org (132.151.6.21)
> HEAD / HTTP/1.1
User-Agent: curl/7.9.4 (solaris2.8) libcurl 7.9.4 (OpenSSL 0.9.6c)
Host: www.ietf.org
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
HTTP/1.1 200 OK
Date: Fri, 03 May 2002 16:04:54 GMT
Server: Apache/1.3.22 (Unix) mod_ssl/2.8.5 OpenSSL/0.9.6b
Last-Modified: Mon, 15 Apr 2002 18:15:00 GMT
ETag: "5a85c-c59-3cbb18a4"
Accept-Ranges: bytes
Content-Length: 3161
Content-Type: text/html
X-Pad: avoid browser bug
* Connection #0 left intact
* Closing connection #0
Malamud, et al. Expires November 13, 2002 [Page 40]
Internet-Draft ANANA May 2002
I.2 PGP Key for ietf-registrar@ietf.org.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCPAzF+LtIAAAEEAOR6J+TD0InYcfH5R40F4/+t0dZt02vljKi1ymMJqyVpUyWe
U4I6t/rFxkZntupxKOIJgNEC93W41XKSn4q9fUuviAduTzXR9ppBAxa1evJPSlnz
4OSzIoxC6k+VmtAyAbkEwDvgA9nyXTkK3weC4T8IMjle0ItEfwIhmzn+kqSBABEB
AAG0I0lFVEYgUmVnaXN0cmFyIDxpZXRmLXJzdnBAaWV0Zi5vcmc+iQCVAwUQMrAx
bvvCP42xMxQ5AQGUcwQAiBOv037y978B8cR0USMuQUvdnX7IXsLc+TogBf1HsDQP
Na/oYuzjD1qXtbQo/HKyj2rItWpcg4KrD6hJ9x2nYzZTOhjoFa8FI567PdUg7TfN
J4wjspCykAO0Egk0FXh9rMCRk14ac4qVdYY69Aii/p/i8thLb+ps8xDioRQAtiGJ
AHUDBRAyJMfkDHlcePGjdhEBASM7Av4yaX4eSIceiZnwpBepL0toiWpywUzm2P+u
9PFQ23ws/Crk1CvFfSL4MSg+wNj3jVeC52MZOep0E2m5PgFH590xTqqfRg4AxGnz
H5AHTCyjwD14ClXFhX2rYQ6xvE1GaRe0KGlldGYgcmVnaXN0cmFyIDxpZXRmLXJl
Z2lzdHJhckBpZXRmLm9yZz6JAJUDBRAzzfcRAiGbOf6SpIEBAXdsBADFu/qsRB7z
D//tDoDult1tOImS6WGecBDGmtyqURhtFuowPJrrn+WtBLTHI3hRLWOOob/gscfR
YJxCY+MaSUjvs3iwPIkUXjqUe3sZXFUINjcT9ELzpOPX15NIcGrWmQzHRlDrwQm+
zjcW7NmsDTQ+m0bYiiiXQZGtd1ANC5HfCokAlQMFEDPOJeOHG8BZjxsZpQEB3dsE
AKHdY4awpqPbbqG8lB93vOzGnveQSI9AafpYbVkIXypoGvnRnnM70AP9zRaI8rur
YVwOzIk8jxCETgPziVHNEeEkRk9TAC3lbB985re5UH9i33Gajs/jc1n6dG25xj6C
PZSLcFLB7VhPFxXumUJuIf2/pYIXqvzioOebMCPO1DaY
=CbD3
-----END PGP PUBLIC KEY BLOCK-----
Malamud, et al. Expires November 13, 2002 [Page 41]
Internet-Draft ANANA May 2002
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.
Malamud, et al. Expires November 13, 2002 [Page 42]