Custodial Review Criteria for Designated Experts
draft-nottingham-registry-custodian-01

Abstract

This document specifies a set of review criteria for IANA registry Designated Experts.

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 February 06, 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.

Table of Contents

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

1. Introduction

This document specifies a set of review criteria for IANA registry Designated Experts [RFC5226].

They are designed to be used when a registry is likely to have a large number of registrations from outside the IETF community, because they give the Designated Expert(s) limited powers to maintain the registry’s contents, while still having a low bar to entry.

Colloquially, such a Designated Expert is known as a "Custodian."

The goal of a registry using them is to reflect deployment with the registry 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).

As such, these review criteria are not appropriate for all registries.

A registry defined as Expert Review or Specification Required can define the Expert's role as that of a Custodian by referencing this document.

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 [RFC2119].

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.

In particular, a Custodian:

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

Additionally, for Specification Required registries, a Custodian:

• MAY approve registrations when it is, in their judgement, apparent that a specification will be published
• MAY consider specifications other than standards as meeting "Specification Required". References are encouraged to be reasonably stable, but references stability on its own SHOULD NOT be an impediment to registration, because the Custodian(s) MAY update it as necessary.

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] Expert Review or Specification Required policy can refer to this specification if they wish to nominate the guidelines described here as review criteria for Designated Expert(s).

Registries using the custodial process:

• SHOULD define a ‘status’ (or functionally similar) field that indicates registration disposition, and SHOULD enumerate possible values.
• SHOULD nominate a mailing list for discussion of registrations; usually, this will be a pre-existing list (rather than a dedicated one).
• MUST nominate the area whose Area Directors are responsible for appointing Custodians and handling appeals.
• SHOULD identify the URL of the registry in their specification.
• SHOULD give IANA as the point of contact for new registrations.
• MAY place additional requirements upon registrations (e.g., syntactic constraints, clear guidelines for appropriate use)

4. IANA Considerations

For custodial registries, IANA:

• MUST send requests for registrations to the Custodian
• SHOULD respond to requests from the Custodian promptly
• SHOULD notify the responsible Area Directors if the Custodian is unresponsive
• 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
• MUST provide the capacity for the Custodian to annotate individual registry entries (e.g., a “wiki” page for each entry)

5. Security Considerations

A Custodian has a considerable amount of leeway regarding the contents of the registry, because they can effect a change in it merely by asking IANA to do so. Therefore, registries that contain security-sensitive information are advised to consider whether this could form the basis of an attack; e.g., if an implementation retrieves and utilises the contents of the registry automatically.

6. References

6.1. Normative References

6.2. Informative References

Author's Address