One document matched: draft-nottingham-appsawg-happiana-00.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "../xml2rfc/rfc2629.dtd" [
   <!ENTITY barry SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.leiba-iana-policy-update.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc ipr="trust200902" docName="draft-nottingham-appsawg-happiana-00"
     category="bcp">

	<front>
		<title abbrev="happiana">Happy IANA: Making Large-Scale Registries More User-Friendly</title>
		<author initials="M." surname="Nottingham" fullname="Mark Nottingham">
			<organization>Rackspace</organization>
			<address>       
				<email>mnot@mnot.net</email> 
				<uri>http://www.mnot.net/</uri>
			</address>
		</author>
		<date year="2012" month="March"/>
		<abstract>

			<t>Suggestions for IANA registries that have a broad audience,
			   particularly a non-IETF one.</t>

		</abstract>
	</front>

	<middle>

		<section title="Introduction">

         <t> While the audience for many IANA registries is fairly narrow
         (often being limited to those active in the IETF), there are some
         which are used by broader groups.</t>
         
         <t>These registries often see requests from third parties who aren't
         as familiar with the operating procedures of the IETF nor IANA, and
         therefore sometimes find the registration process frustrating.</t>
         
         <t>This document makes recommendations for making such registries
         friendlier to their users. They are not intended to be applied to all
         registries.</t>

		</section>

      <section title="Recommendations for Registration Procedures">
         
         <section title="Use the lowest barrier-to-entry registration procedure possible">

            <t>Registries are most useful when they reflect the protocol
            elements actually in use. However, some see them as having more of
            a "gatekeeper" function, where they only reflect "approved" values
            that are "good" (by some metric).</t>
            
            <t>See also <xref target="I-D.leiba-iana-policy-update"/>.</t>
         
         </section>


         <section title="Explain the expert reviewer function">

            <t>Further to the above, registries that use expert reviewers are
            encouraged to carefully define how that role works. Generally, it
            should be seen as a shepherding function, rather than a filtering
            one; the goal of the expert should be to facilitate registrations
            as quickly as possible.</t>
            
            <t>This may involve, for example, registering a protocol element
            that isn't yet completely specified, in anticipation of updating
            it with more accurate or complete information later.</t>

         </section>


         <section title="Clearly identify points of contact">

            <t>Registrants often multiple parties; e.g.,the IESG, the IANA and
            sometimes an expert reviewer, depending on the registration
            process chosen.</t>

            <t>When this is the case, the point of contact for initial
            registration should always be defined as IANA, and responsibility
            at each stage of the registration process should be carefully
            identified.</t>

            <t>Likewise, the document defining a new registry should provide a
            URL [RFC3986] to the registry at IANA (coordinating allocation of
            the URL with IANA as necessary).</t>

         </section>


         <section title="Allow reservation">

            <t>Protocols and their extensions are usually the product of a
            long process. Authors often want to "hold" a value until they
            complete their specification. To accommodate these cases,
            registries should allow a value to be reserved for future use, and
            the registry should reflect this as soon as possible (e.g, with a
            value of "reserved", along with a note about the reservation).</t>

<!-- [Abuse]  -->

         </section>


         <section title="Allow third-party registration">

            <t>Unregistered values sometimes become commonly used. To maintain
            the usefulness of the registry -- both as a reference as well as a
            mechanism to avoid conflicts -- registration procedures SHOULD
            allow registration of already deployed protocol elements by those
            other than their creators.</t>
            
            <t>When this happens, every effort should be made to properly
            attribute the source, common use, and (if applicable) appropriate
            change controller.</t>

         </section>


         <section title="Have a 'status' field">

            <t>Context is important in registries; it's important, for
            example, to differentiate between reserved entries (as per above)
            and those that have completed the process.</t>

            <t>It is recommended that registries that require some level of
            consensus (e.g., IETF Review) have the following potential
            statuses:</t>

            <t><list style="symbols">
               <t>Standard (registered through a consensus process)</t>
               <t>Reserved (held for future use)</t>
               <t>Obsoleted (mapping to the 'obsoleted' and 'historic' states 
                  in [RFC2026])</t>
            </list></t>
  
            <t>It is recommended that registries with lower requirements for
            consensus (e.g., First Come First Served, Specification Required)
            use the following:</t>

            <t><list style="symbols">
               <t>Registered (has been registered)</t>
               <t>Reserved (held for future use)</t>
               <t>Deprecated (has been withdrawn)</t>
            </list></t>

            <t>Note that these are only recommended defaults; registries may
            wish to use additional or different statuses.</t>

         </section>


         <section title="Have a simple procedure for updating
         contacts">

            <t>Registrants' contact details should be able to be updated by
            contacting IANA, even for registries which require a higher level
            of consensus.</t>
            
            <t>Likewise, non-disputed changes in control for a registration
            should be defined as being handled exclusively by IANA.</t>
            
         </section>

<!--
SHOULD specify how technical updates occur

MAY allow community annotations

Often, there are implementation-specific
-->

      </section>
            
		<section title="Security Considerations">

			<t>This document does not specify a protocol, and does not have
			   direct security impact.</t>

		</section>

		<section title="IANA Considerations">

			<t>This document does not directly impact IANA.</t>

		</section>
      
	</middle>

	<back>
		<references title="Informative References">
         &barry;
		</references>
		<!--   <section title="Acknowledgements">
			<t>Thanks to 

			  for their suggestions and feedback.           
			 </t>
			<t>The author takes all responsibility for errors and
			omissions.</t>
		</section>      -->
	</back>
</rfc>