<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7437 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7437.xml">
<!ENTITY I-D.ietf-iasa2-rfc4071bis SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-iasa2-rfc4071bis-00.xml">
<!ENTITY RFC2850 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2850.xml">
<!ENTITY RFC2860 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2860.xml">
<!ENTITY RFC5226 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC6220 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6220.xml">
<!ENTITY RFC7020 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7020.xml">
<!ENTITY RFC7249 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7249.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IAB" category="info" consensus="yes" number="0000" number="8720" docName="draft-iab-rfc7500-bis-00" obsoletes="7500" ipr="trust200902"> ipr="trust200902" updates="" xml:lang="en" sortRefs="true" symRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.32.0 -->
  <link href="https://datatracker.ietf.org/doc/draft-iab-rfc7500-bis-00" rel="prev"/>
  <!-- Generated by id2xml 1.5.0 on 2019-10-03T18:02:21Z -->
	<?rfc compact="yes"?>
	<?rfc text-list-symbols="o*+-"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
   draft-iab-rfc7500-bis-00-manual.txt(2): Warning: The input document is named
   'draft-iab-rfc7500-bis-00-manual.txt' but has an RFC stream type:
  'Internet Architecture Board (IAB)'
   draft-iab-rfc7500-bis-00-manual.txt(10): Warning: Expected an expires indication
   top left, found none
   --><?rfc toc="yes"?>

    <title abbrev="Principles for Operation of Internet Ass">Principles IANA Registries">Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries</title>
    <seriesInfo name="RFC" value="8720"/>
    <author fullname="Russ Housley" initials="R." role="editor"
      <organization showOnFrontPage="false" abbrev="Vigil Security">Vigil Security, LLC</organization>
          <street>918 Spring Knoll Drive</street>
	<street>Herndon, VA 20170</street>
          <country>United States of America</country>
    <author fullname="Olaf Kolkman" initials="O." role="editor" surname="Kolkman">
      <organization showOnFrontPage="false">Internet Society</organization>
          <street>Science Park 400</street>
	<street>Amsterdam  1098 XH</street>
	<street>The Netherlands</street>
          <city>Amsterdam</city><code>1098 XH</code>
    <date month="October" year="2019"/>
	<abstract><t> month="January" year="2020"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


   This document provides principles for the operation of Internet
   Assigned Numbers Authority (IANA) registries.</t>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
   The Internet Engineering Task Force (IETF) and its predecessors have
   traditionally separated the publication of protocol specifications in
   immutable Request for Comments (RFCs) and the registries containing
   protocol parameters.  Traditionally, the registries are maintained by
   a set of functions known collectively as the Internet Assigned
   Numbers Authority (IANA).  Dating back to the earliest days of the
   Internet, specification publication and the registry operations were
   tightly coupled: Jon Postel of the Information Sciences Institute
   (ISI) of the University of Southern California (USC) was responsible
   for both RFC publication and IANA registry operation.  This tight
   coupling had advantages, but it was never a requirement.  Indeed,
   today, the RFC Editor and IANA registry operation are provided by
   different entities.</t>
   Internet registries are critical to the operation of the Internet, Internet
   because they provide a definitive record of the value and meaning of
   identifiers that protocols use when communicating with each other.
   Almost every Internet protocol makes use of registries in some form.
   At the time of writing, the IANA maintains more than two thousand
   protocol parameter registries.</t>
   Internet registries hold protocol identifiers consisting of constants
   and other well-known values used by Internet protocols.  These values
   can be numbers, strings, addresses, and so on.  They are uniquely
   assigned for one particular purpose or use.  Identifiers can be
   maintained in a central list (such as a list of cryptographic
   algorithms), or they can be hierarchically allocated and assigned by
   separate entities at different points in the hierarchy (such as IP
   addresses and domain names).  To maximize trust and usefulness of the
   IANA registries, the principles in this document should be taken into
   consideration for centralized registries as well as hierarchically
   delegated registries.  In hierarchically delegated registries,
   entries nearest to top level have broad scope, but lower-level
   entries have narrow scope.  The Internet Architecture Board (IAB)
   will encourage support for these principles in all delegations of
   Internet identifiers.</t>
   The registry system is built on trust and mutual cooperation.  The
   use of the registries is voluntary and is not enforced by mandates or
   certification policies.  While the use of registries is voluntary, it
   is noted that the success of the Internet creates enormous pressure
   to use Internet protocols and the identifier registries associated
   with them.</t>
   This document provides principles for the operation of IANA
   registries, ensuring that protocol identifiers have consistent
   meanings and interpretations across all implementations and
   deployments, and thus providing the necessary trust in the IANA
    <section title="Principles anchor="sect-2" numbered="true" toc="default">
      <name>Principles for the Operation of IANA Registries" anchor="sect-2"><t> Registries</name>
   The following key principles underscore the successful functioning of
   the IANA registries, and they provide a foundation for trust in those

	<t><list style="hanging" hangIndent="6">
   <t hangText="Ensure Uniqueness:">
      <dl newline="true" spacing="normal">
        <dt>Ensure Uniqueness:</dt>
        <dd> The same protocol identifier must not be
   used for more than one purpose.</t>

	<t hangText="Stable:">Protocol purpose.</dd>
        <dd>Protocol identifier assignment must be lasting.</t>

	<t hangText="Predictable:">The lasting.</dd>
        <dd>The process for making assignments must not
	include unexpected steps. </t>

	<t hangText="Public:"> </dd>
        <dd> The protocol identifiers must be made available
	in well-known locations in a manner that makes them freely available
	to everyone. </t>

	<t hangText="Open:">The </dd>
        <dd>The process that sets the policy for protocol
	identifier assignment and registration must be open to all interested

	<t hangText="Transparent:">The
        <dd>The protocol registries and their
	associated policies should be developed in a transparent manner.</t>

	<t hangText="Accountable:">Registry manner.</dd>
        <dd>Registry policy development and registry
	operations need to be accountable to the affected community.</t>

	</t> community.</dd>
    <section title="Discussion" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
   The principles discussed in <xref target="sect-2"/> target="sect-2" format="default"/> provide trust and confidence in
   the IANA registries.  This section expands on these principles.</t>
      <section title="Ensuring anchor="sect-3.1" numbered="true" toc="default">
        <name>Ensuring Uniqueness, Stability, and Predictability" anchor="sect-3.1"><t> Predictability</name>
   Protocol identifier assignment and registration must be unique,
   stable, and predictable.  Developers, vendors, customers, and users
   depend on the registries for unique protocol identifiers that are
   assigned in a stable and predictable manner.</t>
   A protocol identifier may only be reassigned for a different purpose
   after due consideration of the impact of such a reassignment, and reassignment and, if
   possible, with the consent of the original assignee.</t>
   Recognizing that some assignments involve judgment, such as those
   involving a designated expert <xref target="RFC5226"/>, target="RFC8126" format="default"/>, a predictable process does
   not require completion in a predetermined number of days.  Rather, it
   means that no unexpected steps are introduced in the process of
   making an assignment.</t>
      <section title="Public" anchor="sect-3.2"><t> anchor="sect-3.2" numbered="true" toc="default">
   Once assigned, the protocol identifiers must be made available in a
   manner that makes them freely available to everyone without
   restrictions.  The use of a consistent publication location builds
   confidence in the registry.  This does not mean that the publication
   location can never change, but it does mean that it must change
   infrequently and only after adequate prior notice.</t>
      <section title="Open anchor="sect-3.3" numbered="true" toc="default">
        <name>Open and Transparent" anchor="sect-3.3"><t> Transparent</name>
   The process that sets the policy for protocol identifier assignment
   and registration must be open to all interested parties and must operate
   in a transparent manner.</t>
   When a registry is established, a policy is set for the addition of
   new entries and the updating of existing entries.  While making
   additions and modifications, the registry operator may expose
   instances where policies lack clarity.  When this occurs, the
   registry operator should provide helpful feedback to allow those
   policies to be improved.  In addition, the registry operator not
   being involved in establishing registry policy avoids the risks
   associated with (perceptions of) favoritism and unfairness.</t>
   Recognizing that some assignments involve judgment, such as those
   involving a designated expert <xref target="RFC5226"/>, target="RFC8126" format="default"/>, the recommendations by
   designated experts must be visible to the public to the maximum
   extent possible and subject to challenge or appeal.</t>
      <section title="Accountable" anchor="sect-3.4"><t> anchor="sect-3.4" numbered="true" toc="default">
   The process that sets the policy for IANA registries and the
   operation of the registries must be accountable to the parties that
   rely on the protocol identifiers.  Oversight is needed to ensure
   these are properly serving the affected community.</t>
   In practice, accountability mechanisms for the registry operator may
   be defined by a contract, memoranda of understanding, or service level
   agreements (SLAs).  An oversight body uses these mechanisms to ensure
   that the registry operator is meeting the needs of the affected
   community.  The oversight body is held accountable to the affected
   community by vastly different mechanisms, mechanisms -- for instance instance, recall and
   appeal processes.</t>
   For protocol parameters <xref target="RFC6220"/>, target="RFC6220" format="default"/>, the general oversight of the IANA
   function is performed by the IAB as a chartered responsibility from
   <xref target="RFC2850"/>. target="RFC2850" format="default"/>.  In addition, the IETF Administration Limited Liability
   Company (IETF LLC), as part of the IETF Administrative Support
   Activity (IASA), is responsible for IETF administrative and financial
   matters <xref target="I-D.ietf-iasa2-rfc4071bis"/>, and in target="RFC8711" format="default"/>. In that role, the IETF LLC
   maintains a an SLA with the current registry operator, the Internet
   Corporation for Assigned names Names and Numbers (ICANN), thereby
   specifying the operational requirements with respect to the
   coordination, maintenance, and publication of the protocol parameter
   registries.  Both the IAB and the Board of the IETF LLC are
   accountable to the larger Internet community and are being held
   accountable through the IETF NomCom process <xref target="BCP10"/>.</t> target="RFC8713"

   For the Internet Number Registries <xref target="RFC7249"/>, target="RFC7249" format="default"/>, oversight is performed
   by the Regional Internet Registries (RIRs) as described RFC 7020
   <xref target="RFC7020"/>. target="RFC7020" format="default"/>.  The RIRs are member-based organizations, and they are
   accountable to the affected community by elected governance boards.
   Furthermore, per agreement between the RIRs and ICANN, the policy
   development for the global IANA number registries is coordinated by a
   community-elected number council and subject to process review before
   ratification by the ICANN Board of Trustees <xref target="ASOMOU"/>.</t> target="ASOMOU" format="default"/>.</t>
    <section title="Security Considerations" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>Security Considerations</name>
   Internet Registries registries are critical to elements of Internet security.
   The principles described in this document are necessary for the
   Internet community to place trust in the IANA registries.</t>
    <section title="Changes Since anchor="sect-5" numbered="true" toc="default">
      <name>Changes since RFC 7500" anchor="sect-5"><t> 7500</name>
   <xref target="sect-3.4"/> target="sect-3.4" format="default"/> has been updated to align with the restructuring of the
   IETF Administrative Support Activity (IASA).  Under the new
   structure, the IETF LLC maintains a an SLA with the protocol parameter
   registry operator.  Under the old structure, the SLA was maintained
   by the IETF Administrative Oversight Committee (IAOC).</t>
	<references title="Informative References">

      <name>Informative References</name>

      <reference anchor="ASOMOU" target="http://archive.icann.org/en/aso/aso-mou-29oct04.htm"><front>
	<title>ICANN Address target="https://archive.icann.org/en/aso/aso-mou-29oct04.htm">
          <title>Address Supporting Organization (ASO) MoU</title>
          <date month="October" year="2004"/>

<!-- I-D.draft-ietf-iasa2-rfc4071bis-00.xml; companion document RFC 8711 -->

<reference anchor='RFC8711'>
<title>Structure of the IETF Administrative Support Activity, Version 2.0</title>

<author initials='B' surname='Haberman' fullname='Brian Haberman'>
    <organization />

<author initials='J' surname='Hall' fullname='Joseph Hall'>
    <organization />

<author initials='J' surname='Livingood' fullname='Jason Livingood'>
    <organization />

<date month='January' year='2020' />

<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="8711"/>
<seriesInfo name="DOI" value="10.17487/RFC8711"/>

        <!-- draft-ietf-iasa2-rfc7437bis [RFC8713] -->
        <reference anchor="BCP10" target="http://www.rfc-editor.org/info/bcp10"><front> anchor="RFC8713" target="https://rfc-editor.org/info/rfc8713">
            <title>IAB, IESG, and IAOC IETF LLC Selection, Confirmation, and
                         Recall Process: Operation of the IETF Nominating and
                         Recall Committees</title>
            <author fullname="M. Kucherawy" initials="M." surname="Kucherawy" role="editor">
            <author initials="R." surname="Hinden" role="editor">
            <author initials="J." surname="Livingood" role="editor">
            <date month="January" year="2015"/> year="2020"/>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="7437"/> value="8713"/>
          <seriesInfo name="DOI" value="10.17487/RFC8713"/>


      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6220.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7020.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7249.xml"/>
    <section title="Members anchor="sect-iab" numbered="false" toc="default">
      <name>IAB Members at the Time of Approval" anchor="sect-iab"><figure><artwork><![CDATA[
{{ RFC Editor: Fill in the current membership. }}
	</figure> Approval</name>
<ul spacing="compact" empty="true">
<li><t><contact fullname="Jari Arkko"/></t></li>
<li><t><contact fullname="Alissa Cooper"/></t></li>
<li><t><contact fullname="Stephen Farrell"/></t></li>
<li><t><contact fullname="Wes Hardaker"/></t></li>
<li><t><contact fullname="Ted Hardie"/></t></li>
<li><t><contact fullname="Christian Huitema"/></t></li>
<li><t><contact fullname="Zhenbin Li"/></t></li>
<li><t><contact fullname="Erik Nordmark"/></t></li>
<li><t><contact fullname="Mark Nottingham"/></t></li>
<li><t><contact fullname="Melinda Shore"/></t></li>
<li><t><contact fullname="Jeff Tantsura"/></t></li>
<li><t><contact fullname="Martin Thomson"/></t></li>
<li><t><contact fullname="Brian Trammell"/></t></li>
    <section title="Contributors and Acknowledgements" numbered="no" anchor="contributors-and-acknowledgements"><t> numbered="false" anchor="acknowledgements"
   This text has been developed within the IAB IANA Evolution Program.
   The ideas and many text fragments, fragments and corrections came from or were
   inspired on by comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
   Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve
   Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich,
   John Klensin, Bertrand
<contact fullname="Bernard Aboba" />,
<contact fullname="Jaap Akkerhuis" />,
<contact fullname="Jari Arkko" />,
<contact fullname="Marcelo Bagnulo" />,
<contact fullname="Mark Blanchet" />,
<contact fullname="Brian Carpenter" />,
<contact fullname="David Conrad" />,
<contact fullname="Alissa Cooper" />,
<contact fullname="Steve Crocker" />,
<contact fullname="John Curran" />,
<contact fullname="Leslie Daigle" />,
<contact fullname="Elise Gerich" />,
<contact fullname="John Klensin" />,
<contact fullname="Bertrand de La Chapelle, Eliot Lear, Danny McPherson,
   George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew
   Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Chapelle" />,
<contact fullname="Eliot Lear" />,
<contact fullname="Danny McPherson" />,
<contact fullname="George Michaelson" />,
<contact fullname="Thomas Narten" />,
<contact fullname="Andrei Robachevsky" />,
<contact fullname="Andrew Sullivan" />,
<contact fullname="Dave Thaler" />,
<contact fullname="Brian Trammell" />,
and <contact fullname="Greg Wood" />.

   Further inspiration and input
   was drawn from various meetings with IETF and
   other the leadership of the Internet community (RIRs,
   community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB) leadership.</t> IAB.
   Please do not assume those acknowledged endorse the resulting text.</t>