


Network Working Group                                      M. Nottingham
Internet-Draft                                                 Rackspace
Intended status: BCP                                       March 2, 2012
Expires: September 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 2012               [Page 5]

