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]