<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4846 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4846.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ise-iana-policy-03" ipr="trust200902">
     docName="draft-ise-iana-policy-04" number="8726" ipr="trust200902"
     obsoletes="" updates="" submissionType="independent" xml:lang="en"
     tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="IANA and the Independent Stream">How Requests for IANA Action Will be Be Handled on the Independent Stream</title>
    <seriesInfo name="RFC" value="8726"/>
    <author fullname="Adrian Farrel" initials="A." surname="Farrel">
      <organization>Independent Submissions Editor</organization>
      <address>
        <email>rfc-ise@rfc-editor.org</email>
      </address>
    </author>
    <date month="" year="2019"/>

    <area></area>

    <workgroup></workgroup> month="November" year="2020"/>
    <area/>
    <workgroup/>
    <keyword>IANA</keyword>
    <keyword>Independent Submissions Submission Stream</keyword>
    <keyword>ISE</keyword>
    <abstract>
      <t>The Internet Assigned Numbers Authority (IANA) maintains registries
      to track codepoints code points used
         by protocols such as those defined by the IETF and documented in RFCs developed on the IETF
         Stream.</t>
      <t>The Independent Submissions Submission Stream is another source of documents that can be published as
         RFCs.  This stream is under the care of the Independent Submissions Editor (ISE).</t>
      <t>This document complements RFC 4846 by providing a description of how the ISE currently
         handles documents in the Independent Submissions Submission Stream that request actions from the IANA.
         Nothing in this document changes existing IANA registries or their allocation policies, nor
         does it change any previously documented processes.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Internet Assigned Numbers Authority (IANA) maintains registries
      to track codepoints code points used
         by protocols such as those defined by the IETF and documented in RFCs developed on the IETF Stream.
         A full list of registries and code points can be found at
         <eref target="https://www.iana.org/protocols" />.</t> target="https://www.iana.org/protocols"/>.</t>
      <t>Requests may be made to IANA for actions to create registries or to allocate code points from
         existing registries.  Procedures for these operations are described in <xref target="RFC8126" />.</t> format="default"/>.</t>
      <t>Many requests for IANA action are included in documents that are progressed for publication as RFCs.
         RFCs may be sourced from within the IETF (on the IETF Stream), Stream) but may also be sourced from other
         streams
         streams, including the Independent Submissions Submission Stream (the Independent Stream) Stream), as described in
         <xref target="RFC4846" />. format="default"/>.  The Independent Stream is under the care of the Independent Submissions Editor
         (ISE).</t>
      <t>This document complements <xref target="RFC4846" /> format="default"/> by providing a description of how the ISE
         currently handles documents in the Independent Stream that request actions from the IANA.  Nothing
         in this document changes existing IANA registries or their allocation policies, nor does it change
         any previously documented processes.</t>

      <t>In the event that
      <t>If a case arises that is not precisely covered by this document, the ISE may discuss
         a solution with the interested parties, including IANA, the IESG, the stream managers for other streams,
         and the authors of an Independent Submission that requests IANA action.</t>
    </section>
    <section anchor="exist" title="Allocations numbered="true" toc="default">
      <name>Allocations from Existing Registries"> Registries</name>
      <t>Each IANA registry is governed by an allocation policy: policy -- the rules that IANA applies to determine
         which code points can be allocated and under what circumstances.  These policies are described in
         <xref target="RFC8126" />.</t> format="default"/>.</t>
      <t>Documents proceeding from the Independent Stream will always follow the assignment policies defined
         for the registries from which they request allocations.  Similarly, all code point assignments are
         subject to the oversight of any Designated Expert designated expert (DE) appointed for the registry.</t>
      <t>It should be noted that documents on the Independent Stream can never result in Standards Track
         RFCs and Independent Stream documents are never subject to IETF review.  Thus  Thus, a registry whose
         policy is "IETF Review" or "Standards Action" [RFC8126] <xref target="RFC8126" format="default"/> is not available to Independent Stream
         documents.</t>
    </section>
    <section anchor="change" title="Changing numbered="true" toc="default">
      <name>Changing Policies of Existing Registries"> Registries</name>
      <t>From time to time time, a decision is made to change the allocation policy for a registry.  Such changes
          are normally only made using the allocation policy of the registry itself, itself and usually require documentation
          from the same stream as that created the registry.</t>
      <t>Independent Stream RFCs will not seek to change the allocation policies of any registries except
          those created by documents from the Independent Stream.  The list of such registries is, itself, is itself
          very limited (see <xref target="new" />).</t> format="default"/>).</t>
    </section>
    <section anchor="new" title="Creating numbered="true" toc="default">
      <name>Creating New IANA Registries"> Registries</name>
<t>Sometimes new registries are needed to track a new set of codepoints code points for a new protocol or an extension to an existing protocol.  In protocol.</t>
<t>In general, documents on the Independent Stream cannot request the
   creation of a new IANA registry.</t>

<t>The only exception to this rule is the creation of when a sub-registry that is specifically tied document to be published in
   the Independent Submission Stream requests the allocation of a code
   point allocated for the same document from an existing registry where with the allocation policy for that document is Specification
   Required, Expert Review, RFC Required, or First Come First Served.  Furthermore,
   Then the document to be published may also need to create a registry
   that is tied to that specific code point and is used for
   interpreting a sub-code.</t>

<t>Consider, for example, the "Uniform Resource Identifier (URI)
   Schemes" registry <xref target="URL-URIschemes"/>.  From time to time, a URI scheme
   may need a registry of associated parameters; for example, consider
   the tel URI scheme that has a register of parameters called the "tel
   URI Parameters" <xref target="URL-telURI"/>.</t>

<t>Such examples are rare and only exist to support the allocation from
   the base registry.  In such cases, where there is an appointed DE for
   the parent existing base registry, that DE must
          approve the assignment of the individual code
   point from the existing base registry and the creation of the sub-registry.  Additionally, new
   registry can only happen if the DE approves both actions.</t>

<t>There are several further constraints on the new registry:</t>
<ul>
<li>The allocation policy for the new
          sub-registry registry may only be First Come
      First Served, RFC Required, Experimental, or Private Use.  In
      particular, no sub-registry registry may be created that would require IETF
      action to achieve a future
          codepoint code point allocation.  See <xref target="de" />
      target="de"/> for an explanation of why the application of Specification
      Required and Expert Review are not acceptable policies for any sub-registry
      registry created from a document in the Independent Stream.</t> Stream.</li>
<li>If the allocation policy for the new registry is First Come First Served,
the document must contain a brief statement and explanation of the expected arrival rate of new registrations over time.</li>
<li>The new registry must contain a clear statement of the escalation
      process for any issues that arise with the registry.  A model for
      this statement is as follows:</li></ul>
<blockquote>
This registry was created by [RFCXXXX], which was published on
         the Independent Submission Stream.  Any issues that arise with
         the management of this registry will be resolved by IANA in
         consultation with the Independent Submissions Editor.</blockquote>
<ul>
<li>The IESG will be invited to provide its opinions about the
      advisability of the creation of any new registries during its
      conflict review of the document <xref target="RFC5742"/>, and the ISE will give
      full consideration to such opinions.</li></ul>
<t>
   Authors of Independent Submission Stream documents should consider
   the most appropriate venue to host such registries, taking into
   account where the expertise for managing and reviewing registry
   assignments may be found.  In some cases, this may mean that
   registries are hosted by organizations other than IANA.</t>
    </section>
    <section anchor="de" title="Assigning numbered="true" toc="default">
      <name>Assigning Designated Experts"> Experts</name>
      <t>Some IANA allocation policies (specifically, Specification Required and Expert Review) utilize
          the review of a DE.  The procedures applicable to the appointment and actions of a DE are
          described in section 5 of <xref target="RFC8126" />.</t> sectionFormat="of" section="5"/>.</t>
      <t>When a DE is appointed, the position must be maintained and supported by whoever designated the
          DE in the first place.  That is, someone must appoint replacement DEs if necessary, and someone
          must provide a backstop in case the appointed DEs are unresponsive.</t>
      <t>The ISE will not appoint a DE.  That means that no sub-registry subregistry created for Independent Stream
          documents will require the review of a DE.  That means that no new sub-registry subregistry can be
          created that uses the Specification Required or Expert Review policies.</t>
    </section>
    <section anchor="tx" title="Transfer numbered="true" toc="default">
      <name>Transfer of Control"> Control</name>
      <t>Very rarely, it may be desirable to transfer "ownership" of an IANA registry from the Independent
          Stream to the IETF Stream.  This might happen, for example, if a protocol was originally
          documented in the Independent Stream, Stream but has been adopted for work and standardization
          in the IETF.  Such a transfer may require an IETF Stream RFC to act as the base reference for the
          registry,
          registry and will require discussion and agreement with the ISE.</t>
      <t>Ownership of a registry will not be transferred from the IETF Stream to the Independent Stream.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document is all about IANA actions, actions but makes no request for IANA action.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>There are no direct security considerations arising from this document.  It may be noted that some IANA
         registries relate to security protocols, and the stability and proper management of those registries
         contributes
         contribute to the stability of the protocols themselves.  That is a benefit for the security of the
         Internet and the users of the Internet.</t>
    </section>
  </middle>
  <back>
    <references>
<name>References</name>
<references>
      <name>Normative References</name>
      <xi:include
	  href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4846.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5742.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
    </references>
<references>
      <name>Informative References</name>
  <reference anchor="URL-URIschemes" target="https://www.iana.org/assignments/uri-schemes">
        <front>
          <title>Uniform Resource Identifier (URI) Schemes</title>
          <author>
            <organization></organization>
          </author>
          <date />
        </front>
  </reference>

      <reference anchor="URL-telURI"
		 target="https://www.iana.org/assignments/tel-uri-parameters">
        <front>
          <title>tel URI Parameters</title>
          <author>
            <organization></organization>
          </author>
          <date />
        </front>
      </reference>
</references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to Brian Carpenter, Subramanian Moonesamy, Craig Partridge, Michelle Cotton, Andrew Malis,
         Warren Kumari, Ned Freed, Rich Salz, Michael Richardson, Colin Perkins, Brian Carpenter, Stephen Farrell,
         Barry Leiba, and Benjamin Kaduk <contact fullname="Brian Carpenter" />, <contact
      fullname="Subramanian Moonesamy" />, <contact fullname="Craig Partridge"
      />, <contact fullname="Michelle Cotton" />, <contact fullname="Andrew
      Malis" />, <contact fullname="Warren Kumari" />, <contact fullname="Ned
      Freed" />, <contact fullname="Rich Salz" />, <contact fullname="Michael
      Richardson" />, <contact fullname="Colin Perkins" />, <contact fullname="Stephen Farrell" />,
        <contact fullname="Barry Leiba" />, and <contact fullname="Benjamin
	Kaduk" /> for suggestions and advice.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
      &RFC4846;
      &RFC8126;
    </references>
  </back>
</rfc>