Network Working Group M. Nottingham
Internet-Draft Rackspace
Intended status: BCP March 1, 2012
Expires: September 2, 2012
Happy IANA: Making Large-Scale Registries More User-Friendly
draft-nottingham-appsawg-happiana-00
Abstract
Suggestions for IANA registries that have a broad audience,
particularly a non-IETF one.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 2, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Nottingham Expires September 2, 2012 [Page 1]
Internet-Draft happiana March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommendations for Registration Procedures . . . . . . . . . . 3
2.1. Use the lowest barrier-to-entry registration procedure
possible . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Explain the expert reviewer function . . . . . . . . . . . 3
2.3. Clearly identify points of contact . . . . . . . . . . . . 3
2.4. Allow reservation . . . . . . . . . . . . . . . . . . . . . 4
2.5. Allow third-party registration . . . . . . . . . . . . . . 4
2.6. Have a 'status' field . . . . . . . . . . . . . . . . . . . 4
2.7. Have a simple procedure for updating contacts . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Informative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Nottingham Expires September 2, 2012 [Page 2]
Internet-Draft happiana March 2012
1. Introduction
While the audience for many IANA registries is fairly narrow (often
being limited to those active in the IETF), there are some which are
used by broader groups.
These registries often see requests from third parties who aren't as
familiar with the operating procedures of the IETF nor IANA, and
therefore sometimes find the registration process frustrating.
This document makes recommendations for making such registries
friendlier to their users. They are not intended to be applied to
all registries.
2. Recommendations for Registration Procedures
2.1. Use the lowest barrier-to-entry registration procedure possible
Registries are most useful when they reflect the protocol elements
actually in use. However, some see them as having more of a
"gatekeeper" function, where they only reflect "approved" values that
are "good" (by some metric).
See also [I-D.leiba-iana-policy-update].
2.2. Explain the expert reviewer function
Further to the above, registries that use expert reviewers are
encouraged to carefully define how that role works. Generally, it
should be seen as a shepherding function, rather than a filtering
one; the goal of the expert should be to facilitate registrations as
quickly as possible.
This may involve, for example, registering a protocol element that
isn't yet completely specified, in anticipation of updating it with
more accurate or complete information later.
2.3. Clearly identify points of contact
Registrants often multiple parties; e.g.,the IESG, the IANA and
sometimes an expert reviewer, depending on the registration process
chosen.
When this is the case, the point of contact for initial registration
should always be defined as IANA, and responsibility at each stage of
the registration process should be carefully identified.
Nottingham Expires September 2, 2012 [Page 3]
Internet-Draft happiana March 2012
Likewise, the document defining a new registry should provide a URL
[RFC3986] to the registry at IANA (coordinating allocation of the URL
with IANA as necessary).
2.4. Allow reservation
Protocols and their extensions are usually the product of a long
process. Authors often want to "hold" a value until they complete
their specification. To accommodate these cases, registries should
allow a value to be reserved for future use, and the registry should
reflect this as soon as possible (e.g, with a value of "reserved",
along with a note about the reservation).
2.5. Allow third-party registration
Unregistered values sometimes become commonly used. To maintain the
usefulness of the registry -- both as a reference as well as a
mechanism to avoid conflicts -- registration procedures SHOULD allow
registration of already deployed protocol elements by those other
than their creators.
When this happens, every effort should be made to properly attribute
the source, common use, and (if applicable) appropriate change
controller.
2.6. Have a 'status' field
Context is important in registries; it's important, for example, to
differentiate between reserved entries (as per above) and those that
have completed the process.
It is recommended that registries that require some level of
consensus (e.g., IETF Review) have the following potential statuses:
o Standard (registered through a consensus process)
o Reserved (held for future use)
o Obsoleted (mapping to the 'obsoleted' and 'historic' states in
[RFC2026])
It is recommended that registries with lower requirements for
consensus (e.g., First Come First Served, Specification Required) use
the following:
o Registered (has been registered)
o Reserved (held for future use)
o Deprecated (has been withdrawn)
Note that these are only recommended defaults; registries may wish to
Nottingham Expires September 2, 2012 [Page 4]
Internet-Draft happiana March 2012
use additional or different statuses.
2.7. Have a simple procedure for updating contacts
Registrants' contact details should be able to be updated by
contacting IANA, even for registries which require a higher level of
consensus.
Likewise, non-disputed changes in control for a registration should
be defined as being handled exclusively by IANA.
3. Security Considerations
This document does not specify a protocol, and does not have direct
security impact.
4. IANA Considerations
This document does not directly impact IANA.
5. Informative References
[I-D.leiba-iana-policy-update]
Leiba, B., "Update of and Clarification to IANA Policy
Definitions in BCP 26", draft-leiba-iana-policy-update-01
(work in progress), October 2011.
Author's Address
Mark Nottingham
Rackspace
Email: mnot@mnot.net
URI: http://www.mnot.net/
Nottingham Expires September 2, 2012 [Page 5]