Skip to main content

Managing IANA Registries with Custodians
draft-nottingham-registry-custodian-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Mark Nottingham
Last updated 2012-07-04
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-nottingham-registry-custodian-00
Network Working Group                                      M. Nottingham
Internet-Draft                                              July 5, 2012
Intended status: Standards Track
Expires: January 6, 2013

                Managing IANA Registries with Custodians
                 draft-nottingham-registry-custodian-00

Abstract

   This document specifies an opt-in augmentation to the Well-Known IANA
   Policy Definitions; appointing a "Custodian".

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 January 6, 2013.

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 January 6, 2013                [Page 1]
Internet-Draft             Registry Custodians                 July 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . . . 3
   2.  The Custodian's Role  . . . . . . . . . . . . . . . . . . . . . 3
   3.  Specifying Custodial Registries . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

Nottingham               Expires January 6, 2013                [Page 2]
Internet-Draft             Registry Custodians                 July 2012

1.  Introduction

   This document specifies an opt-in augmentation to the Well-Known IANA
   Policy Definitions [RFC5226]; appointing a "Custodian".

   The custodial process is designed to be used when a registry is
   likely to have a large number of entries from outside the standards
   community, because it gives an individual limited powers to maintain
   the registry's contents, while still having a low bar to entry.

   The goal of a custodial registry is to reflect deployment experience
   as closely as possible; in other words, if a protocol element is in
   use on the Internet, it ought to appear in the registry.

   It is a non-goal to use the registry as a measure of quality (e.g.,
   allowing only "good" registrations, imposing architectural
   constraints onto registrations).

   Usually, a registry defined as Expert Review or Specification
   Required will define the Expert as a Custodian.  However, registries
   with more stringent requirements can also use this process.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119, BCP 14
   [RFC2119] and indicate requirement levels for compliant CoAP
   implementations.

2.  The Custodian's Role

   The Custodian's primary duty is to maintain the registry's contents
   by assisting new registrations, updating existing entries, and making
   new registrations when a protocol element is widely deployed but
   unregistered.

   As such, they have considerable power, in that they can make material
   changes to the registry content without oversight, beyond that
   offered by the community at large.

   However, in practice this power is quite limited.  The Custodian is
   not charged with acting as a gatekeeper, nor imposing requirements on
   new registrations.  Rather, they are responsible for assuring that
   the registry is kept up-to-date, reflecting the reality of
   deployment.

Nottingham               Expires January 6, 2013                [Page 3]
Internet-Draft             Registry Custodians                 July 2012

   In particular, a Custodian:

   o  MAY make suggestions to new registrations (e.g., "have you
      considered...?")
   o  MUST NOT act as a "gatekeeper" to the registry (e.g., refusing
      registrations based upon perceived or actual architectural or
      aesthetic issues)
   o  SHOULD consult with the community (using a nominated mailing list)
      when there are disputes or questions about pending or existing
      registrations
   o  MAY proactively document values in common use (usually, reflected
      in the registration status, e.g., "provisional")
   o  MAY update contact details and specification references, in
      consultation with the registrants
   o  MAY update change control for a registration, with appropriate
      consent or community consensus, as appropriate
   o  MAY annotate registrations (e.g., with implementation notes,
      additional context)
   o  MAY update the status of a registration (e.g., to "deprecated",
      "obsoleted") as appropriate
   o  SHOULD announce significant changes to the mailing list, for
      community review

   Members of the community who disagree with a Custodian's actions MAY
   appeal to the Area Director(s) identified by the registry.  However,
   such appeals will be judged upon the criteria above, along with any
   criteria specific to the registry and/or its chosen registration
   policy.

3.  Specifying Custodial Registries

   Registries established with a [RFC5226] policy can refer to this
   specification if they wish to use a custodial process.

   Such registries still need to specify a base policy for
   registrations; suitable policies in [RFC5226] include Expert Review
   and Specification Required (in both cases, the Designated Expert
   would be the Custodian, and this specification would fulfil the
   requirement to define review criteria).

   It is also possible to specify a custodial process for registries
   with more stringent policies; e.g., IETF Review.  In these cases, the
   Custodian can still register new protocol elements to reflect non-
   standard protocol elements in common use, but MUST identify them with
   an appropriate status (e.g., "non-standard").

   Registries using the custodial process:

Nottingham               Expires January 6, 2013                [Page 4]
Internet-Draft             Registry Custodians                 July 2012

   o  SHOULD define a 'status' (or functionally similar) field that
      indicates registration disposition, and SHOULD enumerate possible
      values.
   o  SHOULD nominate a mailing list for discussion of registrations;
      usually, this will be a pre-existing list (rather than a dedicated
      one).
   o  MUST nominated the area whose Area Directors are responsible for
      appointing Custodians and handling appeals.
   o  SHOULD identify the URL of the registry in their specification
   o  SHOULD give IANA as the point of contact for new registrations

4.  IANA Considerations

   For custodial registries, IANA:

   o  MUST send requests for registrations to the Custodian
   o  SHOULD respond to requests from the Custodian promptly
   o  SHOULD notify the responsible Area Directors if the Custodian is
      unresponsive
   o  MUST provide an easily editable Web page about the registry to the
      Custodian (e.g., a "wiki"), and link to it from the registry page
   o  MUST provide the capacity for the Custodian to annotate individual
      registry entries (e.g., a "wiki" page for each entry)

5.  Security Considerations

   TBD.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2.  Informative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

Nottingham               Expires January 6, 2013                [Page 5]
Internet-Draft             Registry Custodians                 July 2012

Author's Address

   Mark Nottingham

   Email: mnot@mnot.net
   URI:   http://www.mnot.net/

Nottingham               Expires January 6, 2013                [Page 6]