Managing IANA Registries with Custodians
draft-nottingham-registry-custodian-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Mark Nottingham | ||
| Last updated | 2012-07-04 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| 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]