One document matched: draft-nottingham-registry-custodian-00.xml

<?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-00" 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">Managing IANA Registries with Custodians</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>Internet-Draft</keyword>

    <abstract>


<t>This document specifies an opt-in augmentation to the Well-Known IANA Policy
Definitions; appointing a “Custodian”.</t>



    </abstract>


  </front>

  <middle>


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

<t>This document specifies an opt-in augmentation to the Well-Known IANA Policy
Definitions <xref target="RFC5226"/>; appointing a “Custodian”.</t>

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

<t>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.</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>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.</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 RFC 2119, BCP 14
<xref target="RFC2119"/> and indicate requirement levels for compliant CoAP
implementations.</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>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>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"/> policy can refer to this specification
if they wish to use a custodial process.</t>

<t>Such registries still need to specify a base policy for registrations;
suitable policies in <xref target="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).</t>

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