<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-nottingham-registry-custodian-01" category="std">

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

  <front>
    <title abbrev="Registry Custodians">Custodial Review Criteria for Designated Experts</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>http://www.mnot.net/</uri>
      </address>
    </author>

    <date year="2012"/>

    <area>General</area>
    
	<keyword>IANA</keyword>
	<keyword>registry</keyword>
	<keyword>custodian</keyword>
	<keyword>designated expert</keyword>

    <abstract>

      <t>This document specifies a set of review criteria for IANA registry
      Designated Experts.</t>

    </abstract>

  </front>

  <middle>


<section anchor="introduction" title="Introduction">

   <t>This document specifies a set of review criteria for IANA registry
   Designated Experts <xref target="RFC5226"/>.</t>

   <t>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.</t>

   <t>Colloquially, such a Designated Expert is known as a "Custodian."</t>

   <t>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.</t>

   <t>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).</t>

   <t>As such, these review criteria are not appropriate for all
   registries.</t>

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

<section anchor="notational-conventions" title="Notational Conventions">

   <t>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 <xref
   target="RFC2119"/>.</t>

</section>
</section>
<section anchor="the-custodians-role" title="The Custodian’s Role">

   <t>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.</t>

   <t>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.</t>

   <t>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.</t>

   <t>In particular, a Custodian:</t>

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

   <t>Additionally, for Specification Required registries, a Custodian:</t>

   <t><list style="symbols">
     <t>MAY approve registrations when it is, in their judgement, apparent
	 that a specification will be published</t>
	 <t>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.</t>
   </list></t>

   <t>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.</t>

</section>
<section anchor="specifying-custodial-registries" title="Specifying Custodial Registries">

   <t>Registries established with a <xref target="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).</t>

   <t>Registries using the custodial process:</t>

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

</section>
<section anchor="iana-considerations" title="IANA Considerations">

   <t>For custodial registries, IANA:</t>

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

</section>
<section anchor="security-considerations" title="Security Considerations">

   <t>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.</t>

</section>
  </middle>

  <back>

    <references title='Normative References'>

<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

    </references>

    <references title='Informative References'>

<reference anchor='RFC5226'>

<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).&lt;/t>&lt;t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.&lt;/t>&lt;t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>

<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>

    </references>



  </back>
</rfc>

