rfc8722xml2.original.xml   rfc8722.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" cons
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ensus="true" docName="draft-ietf-iasa2-rfc6220bis-04" indexInclude="true" ipr="t
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="info rust200902" number="8722" obsoletes="6220" prepTime="2020-02-26T17:11:27" script
" docName="draft-ietf-iasa2-rfc6220bis-04" obsoletes="6220" updates="" submissio s="Common,Latin" sortRefs="true" submissionType="IAB" symRefs="true" tocDepth="3
nType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" vers " tocInclude="true" xml:lang="en">
ion="3"> <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc6220bis-04" r
el="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8722" rel="alternate"/>
<link href="urn:issn:2070-1721" rel="alternate"/>
<front> <front>
<title abbrev="Role of Registry Operators">Defining the Role and <title abbrev="Role of Registry Operators">Defining the Role and Function of
Function of IETF Protocol Parameter Registry Operators</title> IETF Protocol Parameter Registry Operators</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-iasa2-rfc6220bis-04"/> <seriesInfo name="RFC" value="8722" stream="IAB"/>
<author initials="D." surname="McPherson" fullname="Danny McPherson" role="e ditor"> <author initials="D." surname="McPherson" fullname="Danny McPherson" role="e ditor">
<organization abbrev="ISOC">Verisign, Inc.</organization> <organization showOnFrontPage="true">Verisign, Inc.</organization>
<address> <address>
<email>dmcpherson@verisign.com</email> <email>dmcpherson@verisign.com</email>
</address> </address>
</author> </author>
<author initials="O." surname="Kolkman" fullname="Olaf Kolkman" role="editor "> <author initials="O." surname="Kolkman" fullname="Olaf Kolkman" role="editor ">
<organization abbrev="ISOC">Inter <organization abbrev="ISOC" showOnFrontPage="true">Internet Society</organ
net Society</organization> ization>
<address> <address>
<email>kolkman@isoc.org</email> <email>kolkman@isoc.org</email>
</address> </address>
</author> </author>
<author initials="J.C." surname="Klensin" fullname="John C Klensin" role="ed itor"> <author initials="J." surname="Klensin" fullname="John C Klensin" role="edit or">
<address> <address>
<email>john+ietf@jck.com</email> <email>john-ietf@jck.com</email>
</address> </address>
</author> </author>
<author initials="G." surname="Huston" fullname="Geoff Huston" role="editor" > <author initials="G." surname="Huston" fullname="Geoff Huston" role="editor" >
<organization>APNIC</organization> <organization showOnFrontPage="true">APNIC</organization>
<address> <address>
<email>gih@apnic.net</email> <email>gih@apnic.net</email>
</address> </address>
</author> </author>
<author surname="-"> <date month="02" year="2020"/>
<organization>Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email>
</address>
</author>
<date/>
<area>General</area> <area>General</area>
<workgroup>Internet Architecture Board(IAB)</workgroup> <workgroup>Internet Architecture Board (IAB)</workgroup>
<keyword>IANA</keyword> <keyword>IANA</keyword>
<keyword>Governance</keyword> <keyword>Governance</keyword>
<abstract> <keyword>IASA</keyword>
<t> <abstract pn="section-abstract">
<t pn="section-abstract-1">
Many Internet Engineering Task Force (IETF) protocols make use Many Internet Engineering Task Force (IETF) protocols make use
of commonly defined values that are passed in messages or of commonly defined values that are passed in messages or
packets. To ensure consistent interpretation of these values packets. To ensure consistent interpretation of these values
between independent implementations, there is a need to ensure between independent implementations, there is a need to ensure
that the values and associated semantic intent are uniquely that the values and associated semantic intent are uniquely
defined. The IETF uses registry functions to record assigned defined. The IETF uses registry functions to record assigned
protocol parameter values and their associated semantic protocol parameter values and their associated semantic
intentions. For each IETF protocol parameter, it is current intentions. For each IETF protocol parameter, it is current
practice for the IETF to delegate the role of Protocol practice for the IETF to delegate the role of Protocol
Parameter Registry Operator to a nominated entity. This Parameter Registry Operator to a nominated entity. This
document provides a description of, and the requirements for, document provides a description of, and the requirements for,
these delegated functions. This document obsoletes RFC 6220 to these delegated functions. This document obsoletes RFC 6220 to
replace all references to the IASA and related structures with replace all references to the IETF Administrative Support Activity
those defined by the IASA 2.0 Model. (IASA) and related structures with those defined by the IASA 2.0 Model.
</t> </t>
</abstract> </abstract>
<note> <boilerplate>
<name>[Cover Note]</name> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t> "exclude" pn="section-boilerplate.1">
[The IASA2 WG asks the IAB to publish this replacement for RFC 6220. <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
This document is changed for alignment with the new structure for the >
IETF Administrative Support Activity (IASA). ] <t pn="section-boilerplate.1-1">
</t> This document is not an Internet Standards Track specification; it i
</note> s
published for informational purposes.
</t>
<t pn="section-boilerplate.1-2">
This document is a product of the Internet Architecture Board
(IAB) and represents information that the IAB has deemed valuable
to provide for permanent record. It represents the consensus of the
Internet
Architecture Board (IAB). Documents approved for publication
by the IAB are not candidates for any level of Internet Standard; se
e
Section 2 of RFC 7841.
</t>
<t pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8722" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent
="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-overview">Overview</xref>
</t>
</li>
<li pn="section-toc.1-1.2">
<t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent
="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-roles-and-responsibilitie
s-">Roles and Responsibilities Concerning IETF Protocol Parameter Registries</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derive
dContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-protocol-para
meter-registry">Protocol Parameter Registry Operator Role</xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derive
dContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-iab-role">IAB
Role</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t keepWithNext="true" pn="section-toc.1-1.2.2.3.1"><xref derive
dContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-iesg-role">IE
SG Role</xref></t>
</li>
<li pn="section-toc.1-1.2.2.4">
<t keepWithNext="true" pn="section-toc.1-1.2.2.4.1"><xref derive
dContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-role-of-the-i
etf-trust">Role of the IETF Trust</xref></t>
</li>
<li pn="section-toc.1-1.2.2.5">
<t keepWithNext="true" pn="section-toc.1-1.2.2.5.1"><xref derive
dContent="2.5" format="counter" sectionFormat="of" target="section-2.5"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-role-of-the-i
etf-administra">Role of the IETF Administration Limited Liability Compan
y</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent
="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-miscellaneous-considerati
on">Miscellaneous Considerations</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent
="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-security-considerations">
Security Considerations</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent
="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent
="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedCon
tent="" format="title" sectionFormat="of" target="name-informative-references">I
nformative References</xref></t>
</li>
<li pn="section-toc.1-1.7">
<t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-iab-members-at-the-time
-of-">IAB Members at the Time of Approval</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-acknowledgements">Ackno
wledgements</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent
="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedC
ontent="" format="title" sectionFormat="of" target="name-authors-addresses">Auth
ors' Addresses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<!--
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-->
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name>Overview</name> <name slugifiedName="name-overview">Overview</name>
<t> <t pn="section-1-1">
Many IETF protocols make use of commonly defined values that Many IETF protocols make use of commonly defined values that
are passed within messages or packets. To ensure consistent are passed within messages or packets. To ensure consistent
interpretation of these values between independent interpretation of these values between independent
implementations, there is a need to ensure that the values implementations, there is a need to ensure that the values
and associated semantic intent are uniquely defined. The and associated semantic intent are uniquely defined. The
IETF uses registries to record each of the possible values IETF uses registries to record each of the possible values
of a protocol parameter and their associated semantic of a protocol parameter and their associated semantic
intent. These registries, their registration policy, and intent. These registries, their registration policy, and
the layout of their content are defined in the so-called the layout of their content are defined in the so-called
"IANA Considerations" sections of IETF documents. "IANA Considerations" sections of IETF documents.
</t> </t>
<t> <t pn="section-1-2">
The organizational separation between the IETF and its The organizational separation between the IETF and its
Registry Operators parallels ones that are fairly common among Protocol Parameter Registry Operators parallels ones that are fairly comm on among
standards development organizations (SDOs) although less standards development organizations (SDOs) although less
common among technology consortia and similar bodies. These common among technology consortia and similar bodies. These
functions have been separated into different organizations for functions have been separated into different organizations for
several reasons. They include dealing with administrative several reasons. They include dealing with administrative
issues, addressing concerns about maintaining an adequate issues, addressing concerns about maintaining an adequate
distance between basic policy and specific allocations, and distance between basic policy and specific allocations, and
avoiding any potential conflicts of interest that might arise avoiding any potential conflicts of interest that might arise
from commercial or organizational relationships. For example, from commercial or organizational relationships. For example,
most ISO and ISO/IEC JTC1 standards that require registration most ISO and ISO/IEC JTC1 standards that require registration
activities specify a Registration Authority (RA) or activities specify a Registration Authority (RA) or
Maintenance Agency (MA) that, in turn, control the actual Maintenance Agency (MA) that, in turn, control the actual
registration decisions. The databases of what is registered registration decisions. The databases of what is registered
for each standard may then be maintained by a secretariat or for each standard may then be maintained by a secretariat or
database function associated with the RA or MA or, less database function associated with the RA or MA or, less
frequently, by the secretariat of the body that created and frequently, by the secretariat of the body that created and
maintains the standard itself. maintains the standard itself.
</t> </t>
<t> <t pn="section-1-3">
This structural separation of roles exists within several This structural separation of roles exists within several
places in the IETF framework (e.g., the RFC Editor places in the IETF framework (e.g., the RFC Editor
function). The Internet Architecture Board (IAB), on behalf function). The Internet Architecture Board (IAB), on behalf
of the IETF, has the responsibility to define and manage the of the IETF, has the responsibility to define and manage the
relationship with the Protocol Registry Operator role. This relationship with the Protocol Parameter Registry Operator role. This
responsibility includes the selection and management of the responsibility includes the selection and management of the
Protocol Parameter Registry Operator, as well as management Protocol Parameter Registry Operator, as well as management
of the parameter registration process and the guidelines for of the parameter registration process and the guidelines for
parameter allocation. parameter allocation.
</t> </t>
<t> <t pn="section-1-4">
As with other SDOs, although it may delegate authority for As with other SDOs, although it may delegate authority for
some specific decisions, the IETF asserts authority and some specific decisions, the IETF asserts authority and
responsibility for the management of all of its protocol responsibility for the management of all of its protocol
parameters and their registries, even while it generally parameters and their registries, even while it generally
remains isolated from the selection of particular values once remains isolated from the selection of particular values once
a registration is approved. This document describes the a registration is approved. This document describes the
function of these registries as they apply to individual function of these registries as they apply to individual
protocol parameters defined by the IETF Internet Standards protocol parameters defined by the IETF Internet Standards
Process <xref target="RFC6410" format="default"/> to allow for an orderly implementation by Process (see RFC 6410 <xref target="BCP9" format="default" sectionFormat= "of" derivedContent="BCP9"/>) to allow for an orderly implementation by
the IETF Administration Limited Liability Company (IETF LLC), the IETF Administration Limited Liability Company (IETF LLC),
and others as needed, under guidance from the IAB. This and others as needed, under guidance from the IAB. This
document obsoletes RFC 6220 to replace all references to the document obsoletes RFC 6220 to replace all references to the
IASA and related structures with those defined by the IASA 2.0 IASA and related structures with those defined by the IASA 2.0
Model <xref target="I-D.ietf-iasa2-rfc4071bis" format="default"/>. Model <xref target="RFC8711" format="default" sectionFormat="of" derivedC ontent="RFC8711"/>.
</t> </t>
<t> <t pn="section-1-5">
Below we provide a description of the requirements for these Below we provide a description of the requirements for these
delegated functions, which the IETF traditionally refers to as delegated functions, which the IETF traditionally refers to as
the Internet Assigned Numbers Authority (IANA) function. the Internet Assigned Numbers Authority (IANA) function.
</t> </t>
</section> </section>
<!-- Introduction --> <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section numbered="true" toc="default"> <name slugifiedName="name-roles-and-responsibilities-">Roles and Responsib
<name>Roles and Responsibilities Concerning IETF Protocol Parameter ilities Concerning IETF Protocol Parameter Registries</name>
Registries</name> <t pn="section-2-1">
<t>
The IETF's longstanding practice is to outsource the The IETF's longstanding practice is to outsource the
management and implementation of some important functions management and implementation of some important functions
(e.g., <xref target="I-D.ietf-iasa2-rfc6635bis" format="default"/>). The protocol parameter (e.g., <xref target="RFC8728" format="default" sectionFormat="of" derived Content="RFC8728"/>). The protocol parameter
registry function falls into this category of outsourced registry function falls into this category of outsourced
functions, and what follows here is the description of the functions, and what follows here is the description of the
roles and responsibilities with respect to the registration of roles and responsibilities with respect to the registration of
IETF protocol parameters. IETF protocol parameters.
</t> </t>
<t> <t pn="section-2-2">
Specifically, this document describes the operation and role Specifically, this document describes the operation and role
of a delegated IETF Protocol Parameter Registry Operator, to of a delegated IETF Protocol Parameter Registry Operator, to
be selected and administered by the IETF Administrative be selected and administered by the IETF Administrative
Support Activity (IASA) <xref target="I-D.ietf-iasa2-rfc4071bis" format=" default"/>. While there is generally a Support Activity (IASA) <xref target="RFC8711" format="default" sectionFo rmat="of" derivedContent="RFC8711"/>. While there is generally a
single Protocol Parameter Registry Operator, additional single Protocol Parameter Registry Operator, additional
Operators may be selected to implement specific registries, Operators may be selected to implement specific registries,
and that has been done occasionally. Having a single Operator and that has been done occasionally. Having a single Protocol Parameter Registry Operator
facilitates coordination among registries, even those that are facilitates coordination among registries, even those that are
not obviously related, and also makes it easier to have not obviously related, and also makes it easier to have
consistency of formats and registry structure, which aids consistency of formats and registry structure, which aids
users of the registries and assists with quality control. users of the registries and assists with quality control.
</t> </t>
<t> <t pn="section-2-3">
Many protocols make use of identifiers consisting of constants Many protocols make use of identifiers consisting of constants
and other well-known values. Even after a protocol has been and other well-known values. Even after a protocol has been
defined and deployment has begun, new values may need to be defined and deployment has begun, new values may need to be
assigned (e.g., for a new option type in DHCP, or a new assigned (e.g., for a new option type in DHCP, or a new
encryption or authentication algorithm for IPsec). To ensure encryption or authentication algorithm for IPsec). To ensure
that such quantities have consistent values and that such quantities have consistent values and
interpretations in different implementations, their assignment interpretations in different implementations, their assignment
must be administered by a central authority. For IETF must be administered by a central authority. For IETF
protocols, that role is provided by a delegated Protocol protocols, that role is provided by a delegated Protocol
Parameter Registry Operator. For any particular protocol Parameter Registry Operator. For any particular protocol
parameter there is a single delegated Registry Operator. parameter there is a single delegated Registry Operator.
</t> </t>
<section numbered="true" toc="default" anchor="protocolparamreg"> <section numbered="true" toc="include" anchor="protocolparamreg" removeInR
<name>Protocol Parameter Registry Operator Role</name> FC="false" pn="section-2.1">
<t> <name slugifiedName="name-protocol-parameter-registry">Protocol Paramete
r Registry Operator Role</name>
<t pn="section-2.1-1">
The IETF Protocol Parameter Registry function is undertaken The IETF Protocol Parameter Registry function is undertaken
under the auspices of the Internet Architecture Board. under the auspices of the Internet Architecture Board.
</t> </t>
<t> <t pn="section-2.1-2">
The roles of the Protocol Parameter Registry Operator are as The roles of the Protocol Parameter Registry Operator (Registry Operato
r) are as
follows: follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3">
<li> <li pn="section-2.1-3.1">
<t>Review and Advise <t pn="section-2.1-3.1.1">Review and Advise
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.1.
<li> 2">
<li pn="section-2.1-3.1.2.1">
A Registry Operator may be requested to review A Registry Operator may be requested to review
Internet-Drafts that are being considered by the Internet-Drafts that are being considered by the
Internet Engineering Steering Group (IESG), with the Internet Engineering Steering Group (IESG), with the
objective of offering advice to the IESG regarding the objective of offering advice to the IESG regarding the
contents of the "IANA Considerations" section, whether contents of the "IANA Considerations" section, whether
such a section, when required, is clear in terms of such a section, when required, is clear in terms of
direction to the Registry Operator, and whether the direction to the Registry Operator, and whether the
section is consistent with the current published section is consistent with the current published
Registry Operator guidelines. Registry Operator guidelines.
</li> </li>
</ul> </ul>
</li> </li>
<!-- Review and Advice --> <li pn="section-2.1-3.2">
<li> <t pn="section-2.1-3.2.1">Registry
<t>Registry
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.2.
<li> 2">
<li pn="section-2.1-3.2.2.1">
To operate a registry of protocol parameter To operate a registry of protocol parameter
assignments. assignments.
</li> </li>
<li> <li pn="section-2.1-3.2.2.2">
<t> <t pn="section-2.1-3.2.2.2.1">
The delegated Registry Operator registers values for The delegated Registry Operator registers values for
Internet protocol parameters only as directed by the Internet protocol parameters only as directed by the
criteria and procedures specified in RFCs, including criteria and procedures specified in RFCs, including
Standard Track Documents <xref target="BCP9" format="default"/>, Be st Standards Track documents <xref target="BCP9" format="default" sect ionFormat="of" derivedContent="BCP9"/>, Best
Current Practice documents, and other RFCs that Current Practice documents, and other RFCs that
require protocol parameter assignment. require protocol parameter assignment.
</t> </t>
<t> <t pn="section-2.1-3.2.2.2.2">
If values for Internet protocol parameters were not If values for Internet protocol parameters were not
specified, or in case of ambiguity, the Registry specified, or in case of ambiguity, the Registry
Operator will continue to assign and register only Operator will continue to assign and register only
those protocol parameters that have already been those protocol parameters that have already been
delegated to the Operator, following past and current delegated to the Registry Operator, following past and current
practice for such assignments, unless otherwise practice for such assignments, unless otherwise
directed in terms of operating practice by the IESG. directed in terms of operating practice by the IESG.
In the case of ambiguity, the Registry Operator is In the case of ambiguity, the Registry Operator is
expected to identify the ambiguity to the IAB or IESG expected to identify the ambiguity to the IAB or IESG
as appropriate and either suggest better text or ask as appropriate and either suggest better text or ask
the appropriate parties for clarification. the appropriate parties for clarification.
</t> </t>
</li> </li>
</ul> </ul>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.2.
<li> 3">
<t> <li pn="section-2.1-3.2.3.1">
<t pn="section-2.1-3.2.3.1.1">
For each protocol parameter, the associated registry includes: For each protocol parameter, the associated registry includes:
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-
<li> 3.2.3.1.2">
<li pn="section-2.1-3.2.3.1.2.1">
a reference to the RFC document that describes the parameter a reference to the RFC document that describes the parameter
and the associated "IANA Considerations" concerning the and the associated "IANA Considerations" concerning the
parameter, and parameter, and
</li> </li>
<li> for each registration of a protocol parameter value, the source <li pn="section-2.1-3.2.3.1.2.2"> for each registration of a p rotocol parameter value, the source
of the registration and the date of the registration, if the of the registration and the date of the registration, if the
date of registration is known, and date of registration is known, and
</li> </li>
<li> any other information specified as being included in the <li pn="section-2.1-3.2.3.1.2.3"> any other information specif ied as being included in the
registration data in the RFC document that describes the registration data in the RFC document that describes the
parameter. parameter.
</li> </li>
<li> <li pn="section-2.1-3.2.3.1.2.4">
If in doubt or in case of a technical dispute, the If in doubt or in case of a technical dispute, the
Registry Operator will seek and follow technical Registry Operator will seek and follow technical
guidance exclusively from the IESG. Where guidance exclusively from the IESG. Where
appropriate, the IESG will appoint an expert to appropriate, the IESG will appoint an expert to
advise the Registry Operator. advise the Registry Operator.
</li> </li>
</ul> </ul>
</li> </li>
<li> <li pn="section-2.1-3.2.3.2">
The Registry Operator will work with the IETF to develop The Registry Operator will work with the IETF to develop
any missing criteria and procedures over time, which the any missing criteria and procedures over time, which the
Registry Operator will adopt when so instructed by the Registry Operator will adopt when so instructed by the
IESG. IESG.
</li> </li>
<li> <li pn="section-2.1-3.2.3.3">
Unless special circumstances apply to subsets of the Unless special circumstances apply to subsets of the
data and specific rules are established by IETF data and specific rules are established by IETF
consensus, each protocol parameter registry operates as consensus, each protocol parameter registry operates as
a public registry, and the contents of the registry are a public registry, and the contents of the registry are
openly available to the public, on-line and free of openly available to the public, on-line and free of
charge. charge.
</li> </li>
<li> <li pn="section-2.1-3.2.3.4">
The Registry Operator assigns protocol parameter values in The Registry Operator assigns protocol parameter values in
accordance with the policy associated with the protocol accordance with the policy associated with the protocol
parameter, such as "First Come First Served" or "Expert Review" parameter, such as "First Come First Served" or "Expert Review"
<xref target="RFC8126" format="default"/>. <xref target="RFC8126" format="default" sectionFormat="of" derivedC ontent="RFC8126"/>.
</li> </li>
</ul> </ul>
</li> </li>
<!-- Registry--> <li pn="section-2.1-3.3">
<li> <t pn="section-2.1-3.3.1">
<t>
Mailing Lists Mailing Lists
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.3.
<li> 2">
<li pn="section-2.1-3.3.2.1">
The Registry Operator maintains public mailing lists as The Registry Operator maintains public mailing lists as
specified in IANA Considerations <xref target="RFC8126" format="def ault"/>. Such lists are designated for the specified in IANA Considerations <xref target="RFC8126" format="def ault" sectionFormat="of" derivedContent="RFC8126"/>. Such lists are designated for the
purpose of review of assignment proposals in conjunction purpose of review of assignment proposals in conjunction
with a designated expert review function. In addition, with a designated expert review function. In addition,
each Protocol Parameter Registry Operator should each Registry Operator should
maintain a mailing list that enables the registry staff maintain a mailing list that enables the registry staff
of the Registry Operator to be contacted by email. of the Registry Operator to be contacted by email.
</li> </li>
</ul> </ul>
</li> </li>
<!-- Mailing Lists --> <li pn="section-2.1-3.4">
<li> <t pn="section-2.1-3.4.1">
<t>
Liaison Activity Liaison Activity
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.4.
<li> 2">
<li pn="section-2.1-3.4.2.1">
The Registry Operator will nominate a liaison point The Registry Operator will nominate a liaison point
of contact. The Registry Operator, through this of contact. The Registry Operator, through this
liaison, may be requested to provide advice to the liaison, may be requested to provide advice to the
IESG on IETF protocol parameters as well as the IESG on IETF protocol parameters as well as the
"IANA Considerations" section of each Internet-Draft "IANA Considerations" section of each Internet-Draft
that is being reviewed for publication as an RFC. that is being reviewed for publication as an RFC.
Where appropriate the IESG will appoint an expert to Where appropriate the IESG will appoint an expert to
advise the Registry Operator. advise the Registry Operator.
</li> </li>
</ul> </ul>
</li> </li>
<!--Liason Activity --> <li pn="section-2.1-3.5">
<li> <t pn="section-2.1-3.5.1">
<t>
Reporting Reporting
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.5.
<li> 2">
<li pn="section-2.1-3.5.2.1">
The Registry Operator will submit periodic reports to The Registry Operator will submit periodic reports to
the IAB concerning the operational performance of the the IAB concerning the operational performance of the
registry function. As an example of the requirements registry function. As an example of the requirements
for such reports, the reader is referred to a supplement for such reports, the reader is referred to a supplement
<xref target="MoU_SUPP2019" format="default"/> to the "Memorandum o f Understanding <xref target="MoU_SUPP2019" format="default" sectionFormat="of" der ivedContent="MoU_SUPP2019"/> to the "Memorandum of Understanding
Concerning the Technical Work of the Internet Assigned Concerning the Technical Work of the Internet Assigned
Numbers Authority" <xref target="RFC2860" format="default"/> that p rovides service level agreement Numbers Authority" <xref target="RFC2860" format="default" sectionF ormat="of" derivedContent="RFC2860"/> that provides service level agreement
(SLA) guidelines under which ICANN, the current protocol (SLA) guidelines under which ICANN, the current protocol
parameter registry, must operate. parameter registry, must operate.
</li> </li>
<li> <li pn="section-2.1-3.5.2.2">
At the request of the chair of the IETF or IAB, or the At the request of the chair of the IETF or IAB, or the
IETF Executive Director <xref target="I-D.ietf-iasa2-rfc4071bis" fo IETF Executive Director <xref target="RFC8711" format="default" sec
rmat="default"/>, the Registry Operator will undertake tionFormat="of" derivedContent="RFC8711"/>, the Registry Operator will undertake
periodic reports to IETF Plenary meetings, or elsewhere periodic reports to IETF Plenary meetings or elsewhere
as they may direct, concerning the status of the as directed, concerning the status of the
registry function. registry function.
</li> </li>
<li> <li pn="section-2.1-3.5.2.3">
The Registry Operator will publish an annual report The Registry Operator will publish an annual report
describing the status of the function and a summary of describing the status of the function and a summary of
performance indicators. performance indicators.
</li> </li>
</ul> </ul>
</li> </li>
<!-- Reporting --> <li pn="section-2.1-3.6">
<li> <t pn="section-2.1-3.6.1"> Intellectual Property Rights and the Regi
<t> Intellectual Property Rights and the Registry Operator stry Operator
</t> </t>
<t> <t pn="section-2.1-3.6.2">
Unless special circumstances apply (see above): Unless special circumstances apply (see above):
</t> </t>
<ul spacing="normal"> <ul spacing="normal" bare="false" empty="false" pn="section-2.1-3.6.
<li>All assigned values are to be published and made 3">
<li pn="section-2.1-3.6.3.1">All assigned values are to be publish
ed and made
available free of any charges. available free of any charges.
</li> </li>
<li> <li pn="section-2.1-3.6.3.2">
The assignment values may be redistributed without The assignment values may be redistributed without
modification. modification.
</li> </li>
</ul> </ul>
<t>In any case,</t> <t pn="section-2.1-3.6.4">In any case,</t>
<ul> <ul bare="false" empty="false" spacing="normal" pn="section-2.1-3.6.
<li> 5">
<li pn="section-2.1-3.6.5.1">
any intellectual property rights of the IETF protocol any intellectual property rights of the IETF protocol
parameter assignment information, including the IETF parameter assignment information, including the IETF
protocol parameter registry and its contents, are to be protocol parameter registry and its contents, are to be
held by the IETF Trust <xref target="BCP101" format="default"/>. held by the IETF Trust <xref target="RFC8711" format="default" sect
ionFormat="of" derivedContent="RFC8711"/>
<xref target="RFC8714" format="default" sectionFormat="of" deriv
edContent="RFC8714"/>.
</li> </li>
</ul> </ul>
</li> </li>
<!-- IPR -->
</ul> </ul>
</section> </section>
<!-- Section 2.1 --> <section numbered="true" toc="include" anchor="IABrole" removeInRFC="false
<section numbered="true" toc="default" anchor="IABrole"> " pn="section-2.2">
<name>IAB Role</name> <name slugifiedName="name-iab-role">IAB Role</name>
<t> <t pn="section-2.2-1">
An Operator of an IETF protocol parameter registry An Operator of an IETF protocol parameter registry
undertakes the role as a delegated function under the undertakes the role as a delegated function under the
authority of the IAB. authority of the IAB.
</t> </t>
<t> <t pn="section-2.2-2">
The IAB has the responsibility to review the current The IAB has the responsibility to review the current
description of the registry function from time to time and description of the registry function from time to time and
direct the Registry Operator to adopt amendments relating to direct the Registry Operator to adopt amendments relating to
its role and mode of operation according to the best its role and mode of operation according to the best
interests of the IETF and the Internet community in general. interests of the IETF and the Internet community in general.
</t> </t>
<t> <t pn="section-2.2-3">
The IAB has the responsibility to appoint an organization to The IAB has the responsibility to appoint an organization to
undertake the delegated functions of the Protocol Parameter undertake the delegated functions of the
Registry Operator for each IETF protocol parameter. Registry Operator for each IETF protocol parameter.
Specifically, the IAB defines the role and requirements for Specifically, the IAB defines the role and requirements for
the desired functions. The IETF LLC is responsible for the desired functions. The IETF LLC is responsible for
identifying a potential vendor, and once under agreement, identifying a potential vendor, and once under agreement,
managing the various aspects of the relationships with that managing the various aspects of the relationships with that
vendor. To be clear, the IAB is in the deciding role (e.g., vendor. To be clear, the IAB is in the deciding role (e.g.,
for appointment and termination), but must work in close for appointment and termination), but must work in close
consultation with the IETF LLC. consultation with the IETF LLC.
</t> </t>
<t> <t pn="section-2.2-4">
The IAB has the responsibility to determine the terms and The IAB has the responsibility to determine the terms and
conditions of this delegated role. Such terms and conditions of this delegated role. Such terms and
conditions should ensure that the registry operates in a conditions should ensure that the registry operates in a
manner that is fully conformant to the functions described manner that is fully conformant to the functions described
in this document. In addition, such terms and conditions in this document. In addition, such terms and conditions
must not restrict the rights and interests of the IETF with must not restrict the rights and interests of the IETF with
respect to the registry contents and maintenance. respect to the registry contents and maintenance.
</t> </t>
</section> </section>
<!--section 2.2--> <section numbered="true" toc="include" removeInRFC="false" pn="section-2.3
<section numbered="true" toc="default"> ">
<name>IESG Role</name> <name slugifiedName="name-iesg-role">IESG Role</name>
<t> <t pn="section-2.3-1">
The IESG is responsible for the technical direction The IESG is responsible for the technical direction
regarding entries into IETF protocol parameter registries regarding entries into IETF protocol parameter registries
and maintaining the policies by which such technical and maintaining the policies by which such technical
directions are given. Technical direction itself is directions are given. Technical direction itself is
provided through the adoption of directives within the "IANA provided through the adoption of directives within the "IANA
Considerations" section of IETF Stream RFCs or through Considerations" section of IETF Stream RFCs or through
stand- alone "IANA Considerations" RFCs. stand-alone "IANA Considerations" RFCs.
</t> </t>
<t> <t pn="section-2.3-2">
The IESG shall verify that Internet-Drafts that are offered The IESG shall verify that Internet-Drafts that are offered
for publication as IETF Stream RFCs <xref target="RFC4844" format="defa ult"/> include "IANA for publication as IETF Stream RFCs <xref target="RFC8729" format="defa ult" sectionFormat="of" derivedContent="RFC8729"/> include "IANA
Considerations" sections when needed, and that "IANA Considerations" sections when needed, and that "IANA
Considerations" sections conform to the current published Considerations" sections conform to the current published
guidelines. guidelines.
</t> </t>
<t> <t pn="section-2.3-3">
Since technical assessment is not generally a responsibility Since technical assessment is not generally a responsibility
of the Registry Operator, as part of providing the technical of the Registry Operator, as part of providing the technical
direction the IESG is responsible for identifying the direction the IESG is responsible for identifying the
technical experts that are required to, where appropriate, technical experts that are required to, where appropriate,
review registration requests or resolve open technical review registration requests or resolve open technical
questions that relate to the registration of parameters. questions that relate to the registration of parameters.
</t> </t>
<t> At its discretion, the IESG will organize the liaison <t pn="section-2.3-4"> At its discretion, the IESG will organize the lia ison
activities with the Registry Operator's liaison point of activities with the Registry Operator's liaison point of
contact so as to facilitate clear communications and effective contact so as to facilitate clear communications and effective
operation of the registry function. operation of the registry function.
</t> </t>
</section> </section>
<!--section 2.3--> <section numbered="true" toc="include" removeInRFC="false" pn="section-2.4
<section numbered="true" toc="default"> ">
<name>Role of the IETF Trust</name> <name slugifiedName="name-role-of-the-ietf-trust">Role of the IETF Trust
<t> </name>
The IETF Trust <xref target="RFC4371" format="default"/> was formed to <t pn="section-2.4-1">
act as the The IETF Trust <xref target="RFC4371" format="default" sectionFormat="o
f" derivedContent="RFC4371"/> was formed to act as the
administrative custodian of all copyrights and other administrative custodian of all copyrights and other
intellectual property rights relating to the IETF Standards intellectual property rights relating to the IETF Standards
Process, a function that had previously been performed by the Process, a function that had previously been performed by the
Internet Society (ISOC) and the Corporation for National Internet Society (ISOC) and the Corporation for National
Research Initiatives (CNRI). Research Initiatives (CNRI).
</t> </t>
<t> <t pn="section-2.4-2">
Any intellectual property rights of IETF protocol parameter Any intellectual property rights of IETF protocol parameter
assignment information, including the registry and its assignment information, including the registry and its
contents, and all registry publications, are to be held by contents, and all registry publications, are to be held by
the IETF Trust on behalf of the IETF. the IETF Trust on behalf of the IETF.
</t> </t>
<t> <t pn="section-2.4-3">
The IETF Trust may make such regulations as appropriate for The IETF Trust may make such regulations as appropriate for
the redistribution of assignment values and registry the redistribution of assignment values and registry
publications. publications.
</t> </t>
</section> </section>
<!--section 2.4--> <section numbered="true" toc="include" removeInRFC="false" pn="section-2.5
<section numbered="true" toc="default"> ">
<name>Role of the IETF Administration Limited Liability Company< <name slugifiedName="name-role-of-the-ietf-administra">Role of the IETF
/name> Administration Limited Liability Company</name>
<t> <t pn="section-2.5-1">
The IETF Administration Limited Liability Company (IETF LLC) The IETF Administration Limited Liability Company (IETF LLC)
<xref target="I-D.ietf-iasa2-rfc4071bis" format="default"/> <xref target="RFC8711" format="default" sectionFormat="of" derivedConte nt="RFC8711"/>
is responsible for identifying a potential vendor in a is responsible for identifying a potential vendor in a
manner of its choosing, based on IAB consultation, and for manner of its choosing, based on IAB consultation, and for
managing the various aspects of the relationships with that managing the various aspects of the relationships with that
vendor. vendor.
</t> </t>
<t> <t pn="section-2.5-2">
In addition, the IETF LLC has the responsibility to ensure In addition, the IETF LLC has the responsibility to ensure
long-term access, stability, and uniqueness across all such long-term access, stability, and uniqueness across all such
registries. This responsibility is of particular registries. This responsibility is of particular
significance in the event that a relation with a Protocol significance in the event that a relation with a Protocol
Parameter Registry Operator is terminated. Parameter Registry Operator is terminated.
</t> </t>
</section> </section>
<!--section 2.5-->
</section> </section>
<!-- Section 2 --> <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<section numbered="true" toc="default"> <name slugifiedName="name-miscellaneous-consideration">Miscellaneous Consi
<name>Miscellaneous Considerations</name> derations</name>
<t> <t pn="section-3-1">
While this document has focused on the creation of protocols by While this document has focused on the creation of protocols by
the IETF, the requirements provided are generically applicable to the IETF, the requirements provided are generically applicable to
the extended IETF community as well (e.g., Internet Research Task the extended IETF community as well (e.g., Internet Research Task
Force (IRTF)). Force (IRTF)).
</t> </t>
<t> <t pn="section-3-2">
The IESG is responsible for the technical direction of the The IESG is responsible for the technical direction of the
IETF Protocol Parameter registries and maintaining the IETF protocol parameter registries and maintaining the
policies by which such technical directions are given. The policies by which such technical directions are given. The
IESG is responsible, as part of the document approval process IESG is responsible, as part of the document approval process
associated with the IETF Stream RFCs <xref target="RFC4844" format="defau lt"/>, for "IANA Considerations" associated with the IETF Stream RFCs <xref target="RFC8729" format="defau lt" sectionFormat="of" derivedContent="RFC8729"/>, for "IANA Considerations"
verification. For the other RFC streams, the approval bodies verification. For the other RFC streams, the approval bodies
are responsible for verifying that the documents include "IANA are responsible for verifying that the documents include "IANA
Considerations" sections when needed, and that "IANA Considerations" sections when needed, and that "IANA
Considerations" sections conform to the current published Considerations" sections conform to the current published
guidelines. In the case that IANA considerations in non-IETF guidelines. In the case that IANA considerations in non-IETF
document streams lead to a dispute, the IAB makes the final document streams lead to a dispute, the IAB makes the final
decision. decision.
</t> </t>
<t> <t pn="section-3-3">
This document talks about "Registry Operator" (singular), and This document talks about "Registry Operator" (singular), and
while there are stability and economy-of-scale advantages for while there are stability and economy-of-scale advantages for
one single Operator, this document does not exclude having one single Registry Operator, this document does not exclude having
different Operators for different protocol registries when different Registry Operators for different protocol registries when
justified by the circumstances. justified by the circumstances.
</t> </t>
</section> </section>
<!-- Section 3--> <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<section numbered="true" toc="default"> <name slugifiedName="name-security-considerations">Security Considerations
<name>Security Considerations</name> </name>
<t> <t pn="section-4-1">
This document does not propose any new protocols and does not This document does not propose any new protocols and does not
introduce any new security considerations. introduce any new security considerations.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<name>IANA Considerations</name> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t> This document requires no direct IANA actions in terms of <t pn="section-5-1"> This document requires no direct IANA actions in term
s of
the creation or operation of a protocol parameter registry. the creation or operation of a protocol parameter registry.
However, this document does define the roles and However, this document does define the roles and
responsibilities of various bodies who are responsible for, and responsibilities of various bodies who are responsible for, and
associated with, the operation of protocol parameter associated with, the operation of protocol parameter
registration functions for the IETF. registration functions for the IETF.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references pn="section-6">
<name>Informative References</name> <name slugifiedName="name-informative-references">Informative References</
<referencegroup anchor="BCP9"> name>
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2 <referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bcp9
026"> " derivedAnchor="BCP9">
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2
026" quoteTitle="true">
<front> <front>
<title>The Internet Standards Process -- Revision 3</title> <title>The Internet Standards Process -- Revision 3</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="1996" month="October"/> <date year="1996" month="October"/>
<abstract> <abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in t he standardization process, the requirements for moving a document between stage s and the types of documents used during this process. This document specifies a n Internet Best Current Practices for the Internet Community, and requests discu ssion and suggestions for improvements.</t> <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in t he standardization process, the requirements for moving a document between stage s and the types of documents used during this process. This document specifies a n Internet Best Current Practices for the Internet Community, and requests discu ssion and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="2026"/> <seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference> </reference>
<reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rfc5 657"> <reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rfc5 657" quoteTitle="true">
<front> <front>
<title>Guidance on Interoperation and Implementation Reports for Adv ancement to Draft Standard</title> <title>Guidance on Interoperation and Implementation Reports for Adv ancement to Draft Standard</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault"> <author initials="L." surname="Dusseault" fullname="L. Dusseault">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="R." surname="Sparks" fullname="R. Sparks"> <author initials="R." surname="Sparks" fullname="R. Sparks">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2009" month="September"/> <date year="2009" month="September"/>
<abstract> <abstract>
<t>Advancing a protocol to Draft Standard requires documentation o f the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance availabl e to new report preparers. This document updates the existing processes and pro vides more detail on what is appropriate in an interoperability and implementati on report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t > <t>Advancing a protocol to Draft Standard requires documentation o f the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance availabl e to new report preparers. This document updates the existing processes and pro vides more detail on what is appropriate in an interoperability and implementati on report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t >
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="5657"/> <seriesInfo name="RFC" value="5657"/>
<seriesInfo name="DOI" value="10.17487/RFC5657"/> <seriesInfo name="DOI" value="10.17487/RFC5657"/>
</reference> </reference>
<reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc6 410"> <reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc6 410" quoteTitle="true">
<front> <front>
<title>Reducing the Standards Track to Two Maturity Levels</title> <title>Reducing the Standards Track to Two Maturity Levels</title>
<author initials="R." surname="Housley" fullname="R. Housley"> <author initials="R." surname="Housley" fullname="R. Housley">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="D." surname="Crocker" fullname="D. Crocker"> <author initials="D." surname="Crocker" fullname="D. Crocker">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="E." surname="Burger" fullname="E. Burger"> <author initials="E." surname="Burger" fullname="E. Burger">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2011" month="October"/> <date year="2011" month="October"/>
<abstract> <abstract>
<t>This document updates the Internet Engineering Task Force (IETF ) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Pr ocess from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.</t> <t>This document updates the Internet Engineering Task Force (IETF ) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Pr ocess from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="6410"/> <seriesInfo name="RFC" value="6410"/>
<seriesInfo name="DOI" value="10.17487/RFC6410"/> <seriesInfo name="DOI" value="10.17487/RFC6410"/>
</reference> </reference>
<reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rfc7 100"> <reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rfc7 100" quoteTitle="true">
<front> <front>
<title>Retirement of the "Internet Official Protocol Standards" Summ ary Document</title> <title>Retirement of the "Internet Official Protocol Standards" Summ ary Document</title>
<author initials="P." surname="Resnick" fullname="P. Resnick"> <author initials="P." surname="Resnick" fullname="P. Resnick">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2013" month="December"/> <date year="2013" month="December"/>
<abstract> <abstract>
<t>This document updates RFC 2026 to no longer use STD 1 as a summ ary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and reques ts the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t> <t>This document updates RFC 2026 to no longer use STD 1 as a summ ary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and reques ts the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7100"/> <seriesInfo name="RFC" value="7100"/>
<seriesInfo name="DOI" value="10.17487/RFC7100"/> <seriesInfo name="DOI" value="10.17487/RFC7100"/>
</reference> </reference>
<reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rfc7 127"> <reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rfc7 127" quoteTitle="true">
<front> <front>
<title>Characterization of Proposed Standards</title> <title>Characterization of Proposed Standards</title>
<author initials="O." surname="Kolkman" fullname="O. Kolkman"> <author initials="O." surname="Kolkman" fullname="O. Kolkman">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="S." surname="Turner" fullname="S. Turner"> <author initials="S." surname="Turner" fullname="S. Turner">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2014" month="January"/> <date year="2014" month="January"/>
<abstract> <abstract>
<t>RFC 2026 describes the review performed by the Internet Enginee ring Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.</t> <t>RFC 2026 describes the review performed by the Internet Enginee ring Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7127"/> <seriesInfo name="RFC" value="7127"/>
<seriesInfo name="DOI" value="10.17487/RFC7127"/> <seriesInfo name="DOI" value="10.17487/RFC7127"/>
</reference> </reference>
<reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rfc7 475"> <reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rfc7 475" quoteTitle="true">
<front> <front>
<title>Increasing the Number of Area Directors in an IETF Area</titl e> <title>Increasing the Number of Area Directors in an IETF Area</titl e>
<author initials="S." surname="Dawkins" fullname="S. Dawkins"> <author initials="S." surname="Dawkins" fullname="S. Dawkins">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2015" month="March"/> <date year="2015" month="March"/>
<abstract> <abstract>
<t>This document removes a limit on the number of Area Directors w ho manage an Area in the definition of "IETF Area". This document updates RFC 2 026 (BCP 9) and RFC 2418 (BCP 25).</t> <t>This document removes a limit on the number of Area Directors w ho manage an Area in the definition of "IETF Area". This document updates RFC 2 026 (BCP 9) and RFC 2418 (BCP 25).</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="9"/> <seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7475"/> <seriesInfo name="RFC" value="7475"/>
<seriesInfo name="DOI" value="10.17487/RFC7475"/> <seriesInfo name="DOI" value="10.17487/RFC7475"/>
</reference> </reference>
</referencegroup> </referencegroup>
<reference anchor="RFC2860" target="https://www.rfc-editor.org/info/rfc286 <reference anchor="MoU_SUPP2019" target="https://www.ietf.org/media/docume
0"> nts/FINAL_2019-IETF_MoU_Supplemental_Agreement_Signed_31July19.pdf" quoteTitle="
true" derivedAnchor="MoU_SUPP2019">
<front>
<title>2019 ICANN-IETF MoU Supplemental Agreement</title>
<author>
<organization showOnFrontPage="true">IETF Administration LLC</organi
zation>
</author>
<date year="2019" month="July" day="31"/>
</front>
</reference>
<reference anchor="RFC2860" target="https://www.rfc-editor.org/info/rfc286
0" quoteTitle="true" derivedAnchor="RFC2860">
<front> <front>
<title>Memorandum of Understanding Concerning the Technical Work of th e Internet Assigned Numbers Authority</title> <title>Memorandum of Understanding Concerning the Technical Work of th e Internet Assigned Numbers Authority</title>
<author initials="B." surname="Carpenter" fullname="B. Carpenter"> <author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="F." surname="Baker" fullname="F. Baker"> <author initials="F." surname="Baker" fullname="F. Baker">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="M." surname="Roberts" fullname="M. Roberts"> <author initials="M." surname="Roberts" fullname="M. Roberts">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2000" month="June"/> <date year="2000" month="June"/>
<abstract> <abstract>
<t>This document places on record the text of the Memorandum of Unde rstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 20 00. This memo provides information for the Internet community.</t> <t>This document places on record the text of the Memorandum of Unde rstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 20 00. This memo provides information for the Internet community.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="2860"/> <seriesInfo name="RFC" value="2860"/>
<seriesInfo name="DOI" value="10.17487/RFC2860"/> <seriesInfo name="DOI" value="10.17487/RFC2860"/>
</reference> </reference>
<reference anchor="I-D.ietf-iasa2-rfc4071bis"> <reference anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc437
<front> 1" quoteTitle="true" derivedAnchor="RFC4371">
<title>Structure of the IETF Administrative Support Activity, Version
2.0</title>
<author initials="B" surname="Haberman" fullname="Brian Haberman">
<organization/>
</author>
<author initials="J" surname="Hall" fullname="Joseph Hall">
<organization/>
</author>
<author initials="J" surname="Livingood" fullname="Jason Livingood">
<organization/>
</author>
<date month="April" day="12" year="2019"/>
<abstract>
<t>The IETF Administrative Support Activity (IASA) was originally es
tablished in 2005. In the years since then, the needs of the IETF evolved in wa
ys that required changes to its administrative structure. The purpose of this d
ocument is to document and describe the IETF Administrative Support Activity, ve
rsion 2 (IASA 2.0). It defines the roles and responsibilities of the IETF Admin
istration LLC Board, the IETF Executive Director, and the Internet Society in th
e fiscal and administrative support of the IETF standards process. It also defi
nes the membership and selection rules for the IETF Administration LLC Board. T
his document obsoletes RFC 4071, RFC 4333, and RFC 7691.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-iasa2-rfc4071bis-11"
/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-iasa2-rfc4071bis-11.txt"/>
</reference>
<referencegroup anchor="BCP101">
<reference anchor="RFC4071" target="https://www.rfc-editor.org/info/rfc4
071">
<front>
<title>Structure of the IETF Administrative Support Activity (IASA)<
/title>
<author initials="R." surname="Austein" fullname="R. Austein" role="
editor">
<organization/>
</author>
<author initials="B." surname="Wijnen" fullname="B. Wijnen" role="ed
itor">
<organization/>
</author>
<date year="2005" month="April"/>
<abstract>
<t>This document describes the structure of the IETF Administrativ
e Support Activity (IASA) as an activity housed within the Internet Society (ISO
C). It defines the roles and responsibilities of the IETF Administrative Oversi
ght Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in the fi
scal and administrative support of the IETF standards process. It also defines
the membership and selection rules for the IAOC. This document specifies an Int
ernet Best Current Practices for the Internet Community, and requests discussion
and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="4071"/>
<seriesInfo name="DOI" value="10.17487/RFC4071"/>
</reference>
<reference anchor="RFC4371" target="https://www.rfc-editor.org/info/rfc4
371">
<front>
<title>BCP 101 Update for IPR Trust</title>
<author initials="B." surname="Carpenter" fullname="B. Carpenter" ro
le="editor">
<organization/>
</author>
<author initials="L." surname="Lynch" fullname="L. Lynch" role="edit
or">
<organization/>
</author>
<date year="2006" month="January"/>
<abstract>
<t>This document updates BCP 101 to take account of the new IETF I
ntellectual Property Trust. This document specifies an Internet Best Current Pr
actices for the Internet Community, and requests discussion and suggestions for
improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="4371"/>
<seriesInfo name="DOI" value="10.17487/RFC4371"/>
</reference>
</referencegroup>
<reference anchor="RFC4844" target="https://www.rfc-editor.org/info/rfc484
4">
<front> <front>
<title>The RFC Series and RFC Editor</title> <title>BCP 101 Update for IPR Trust</title>
<author initials="L." surname="Daigle" fullname="L. Daigle" role="edit <author initials="B." surname="Carpenter" fullname="B. Carpenter" role
or"> ="editor">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author> <author initials="L." surname="Lynch" fullname="L. Lynch" role="editor
<organization>Internet Architecture Board</organization> ">
<organization showOnFrontPage="true"/>
</author> </author>
<date year="2007" month="July"/> <date year="2006" month="January"/>
<abstract> <abstract>
<t>This document describes the framework for an RFC Series and an RF C Editor function that incorporate the principles of organized community involve ment and accountability that has become necessary as the Internet technical comm unity has grown, thereby enabling the RFC Series to continue to fulfill its mand ate. This memo provides information for the Internet community.</t> <t>This document updates BCP 101 to take account of the new IETF Int ellectual Property Trust. This document specifies an Internet Best Current Prac tices for the Internet Community, and requests discussion and suggestions for im provements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="4844"/> <seriesInfo name="BCP" value="101"/>
<seriesInfo name="DOI" value="10.17487/RFC4844"/> <seriesInfo name="RFC" value="4371"/>
<seriesInfo name="DOI" value="10.17487/RFC4371"/>
</reference> </reference>
<reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc522 6"> <reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc522 6" quoteTitle="true" derivedAnchor="RFC5226">
<front> <front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</ title> <title>Guidelines for Writing an IANA Considerations Section in RFCs</ title>
<author initials="T." surname="Narten" fullname="T. Narten"> <author initials="T." surname="Narten" fullname="T. Narten">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2008" month="May"/> <date year="2008" month="May"/>
<abstract> <abstract>
<t>Many protocols make use of identifiers consisting of constants an d other well-known values. Even after a protocol has been defined and deploymen t 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 tha t such quantities have consistent values and interpretations across all implemen tations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IA NA).</t> <t>Many protocols make use of identifiers consisting of constants an d other well-known values. Even after a protocol has been defined and deploymen t 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 tha t such quantities have consistent values and interpretations across all implemen tations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IA NA).</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 in structions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provi des guidelines for authors on the specific text that must be included in documen ts that place demands on 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 in structions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provi des guidelines for authors on the specific text that must be included in documen ts that place demands on IANA.</t>
<t>This document obsoletes RFC 2434. This document specifies an Int ernet Best Current Practices for the Internet Community, and requests discussio n and suggestions for improvements.</t> <t>This document obsoletes RFC 2434. This document specifies an Int ernet Best Current Practices for the Internet Community, and requests discussio n and suggestions for improvements.</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="RFC" value="5226"/> <seriesInfo name="RFC" value="5226"/>
<seriesInfo name="DOI" value="10.17487/RFC5226"/> <seriesInfo name="DOI" value="10.17487/RFC5226"/>
</reference> </reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc812 6"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc812 6" quoteTitle="true" derivedAnchor="RFC8126">
<front> <front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</ title> <title>Guidelines for Writing an IANA Considerations Section in RFCs</ title>
<author initials="M." surname="Cotton" fullname="M. Cotton"> <author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="B." surname="Leiba" fullname="B. Leiba"> <author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<author initials="T." surname="Narten" fullname="T. Narten"> <author initials="T." surname="Narten" fullname="T. Narten">
<organization/> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2017" month="June"/> <date year="2017" month="June"/>
<abstract> <abstract>
<t>Many protocols make use of points of extensibility that use const ants to identify various protocol parameters. To ensure that the values in thes e fields do not have conflicting uses and to promote interoperability, their all ocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>Many protocols make use of points of extensibility that use const ants to identify various protocol parameters. To ensure that the values in thes e fields do not have conflicting uses and to promote interoperability, their all ocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance descr ibing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification a uthors, in order to assure that the provided guidance for the IANA Consideration s is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>To make assignments in a given registry prudently, guidance descr ibing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification a uthors, in order to assure that the provided guidance for the IANA Consideration s is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226 .</t> <t>This is the third edition of this document; it obsoletes RFC 5226 .</t>
</abstract> </abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/> <seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/> <seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference> </reference>
<reference anchor="I-D.ietf-iasa2-rfc6635bis"> <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc871
1" quoteTitle="true" derivedAnchor="RFC8711">
<front>
<title>Structure of the IETF Administrative Support Activity, Version
2.0</title>
<author initials="B." surname="Haberman">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Hall">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Livingood">
<organization showOnFrontPage="true"/>
</author>
<date year="2020" month="February"/>
</front>
<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="8711"/>
<seriesInfo name="DOI" value="10.17487/RFC8711"/>
</reference>
<reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc871
4" quoteTitle="true" derivedAnchor="RFC8714">
<front>
<title>Update to the Process for Selection of Trustees for the IETF Tr
ust</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization showOnFrontPage="true"/>
</author>
<author initials="T" surname="Hardie" fullname="Ted Hardie">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2020"/>
</front>
<seriesInfo name="BCP" value="101"/>
<seriesInfo name="RFC" value="8714"/>
<seriesInfo name="DOI" value="10.17487/RFC8714"/>
</reference>
<reference anchor="RFC8728" target="https://www.rfc-editor.org/info/rfc872
9" quoteTitle="true" derivedAnchor="RFC8728">
<front> <front>
<title>RFC Editor Model (Version 2)</title> <title>RFC Editor Model (Version 2)</title>
<author initials="O" surname="Kolkman" fullname="Olaf Kolkman"> <author initials="O" surname="Kolkman" fullname="Olaf Kolkman" role="e
<organization/> ditor">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="J" surname="Halpern" fullname="Joel Halpern"> <author initials="J" surname="Halpern" fullname="Joel Halpern" role="e
<organization/> ditor">
<organization showOnFrontPage="true"/>
</author> </author>
<author initials="R" surname="Hinden" fullname="Robert Hinden"> <author initials="R" surname="Hinden" fullname="Robert Hinden" role="e
<organization/> ditor">
<organization showOnFrontPage="true"/>
</author> </author>
<date month="October" day="4" year="2019"/> <date month="February" year="2020"/>
<abstract>
<t>The RFC Editor model described in this document divides the respo
nsibilities for the RFC Series into three functions: the RFC Series Editor, the
RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB)
oversight via the RFC Series Oversight Committee (RSOC) is described, as is the
relationship between the IETF Administration Limited Liability Company and the R
SOC. This document reflects the experience gained with "RFC Editor Model (Versi
on 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references
to the IASA and related structures with those defined by the IASA 2.0 Model. [
RFC Editor: Please remove the following paragraph prior to publication.] The IA
SA2 WG requests that the IAB publish this replacement for RFC 6635.</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-iasa2-rfc6635bis-04" <seriesInfo name="RFC" value="8728"/>
/> <seriesInfo name="DOI" value="10.17487/RFC8728"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-iet
f-iasa2-rfc6635bis-04.txt"/>
</reference> </reference>
<reference anchor="MoU_SUPP2019"> <reference anchor="RFC8729" target="https://www.rfc-editor.org/info/rfc872 9" quoteTitle="true" derivedAnchor="RFC8729">
<front> <front>
<title> ICANN/IANA-IETF MoU Supplemental Agreement, 2019</title> <title>The RFC Series and RFC Editor</title>
<author/> <author initials="R." surname="Housley" role="editor">
<date/> <organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Daigle" role="editor">
<organization showOnFrontPage="true"/>
</author>
<date month="February" year="2020"/>
</front> </front>
<annotation><eref target="https://www.ietf.org/media/documents/FINAL_201 <seriesInfo name="RFC" value="8729"/>
9-IETF_MoU_Supplemental_Agreement_Signed_31July19.pdf"/>. <seriesInfo name="DOI" value="10.17487/RFC8729"/>
</annotation>
</reference> </reference>
</references> </references>
<section numbered="true" toc="default" anchor="Acknowledgement"> <section numbered="false" toc="include" removeInRFC="false" pn="section-appe
<name>Acknowledgements</name> ndix.a">
<t> <name slugifiedName="name-iab-members-at-the-time-of-">IAB Members at the
Time of Approval</name>
<t pn="section-appendix.a-1">
Internet Architecture Board Members at the time this document
was approved for publication were:
</t>
<ul empty="true" spacing="compact" bare="false" pn="section-appendix.a-2">
<li pn="section-appendix.a-2.1">
<t pn="section-appendix.a-2.1.1"><contact fullname="Jari Arkko"/></t>
</li>
<li pn="section-appendix.a-2.2">
<t pn="section-appendix.a-2.2.1"><contact fullname="Alissa Cooper"/></
t>
</li>
<li pn="section-appendix.a-2.3">
<t pn="section-appendix.a-2.3.1"><contact fullname="Stephen Farrell"/>
</t>
</li>
<li pn="section-appendix.a-2.4">
<t pn="section-appendix.a-2.4.1"><contact fullname="Wes Hardaker"/></t
>
</li>
<li pn="section-appendix.a-2.5">
<t pn="section-appendix.a-2.5.1"><contact fullname="Ted Hardie"/></t>
</li>
<li pn="section-appendix.a-2.6">
<t pn="section-appendix.a-2.6.1"><contact fullname="Christian Huitema"
/></t>
</li>
<li pn="section-appendix.a-2.7">
<t pn="section-appendix.a-2.7.1"><contact fullname="Zhenbin Li"/></t>
</li>
<li pn="section-appendix.a-2.8">
<t pn="section-appendix.a-2.8.1"><contact fullname="Erik Nordmark"/></
t>
</li>
<li pn="section-appendix.a-2.9">
<t pn="section-appendix.a-2.9.1"><contact fullname="Mark Nottingham"/>
</t>
</li>
<li pn="section-appendix.a-2.10">
<t pn="section-appendix.a-2.10.1"><contact fullname="Melinda Shore"/><
/t>
</li>
<li pn="section-appendix.a-2.11">
<t pn="section-appendix.a-2.11.1"><contact fullname="Jeff Tantsura"/><
/t>
</li>
<li pn="section-appendix.a-2.12">
<t pn="section-appendix.a-2.12.1"><contact fullname="Martin Thomson"/>
</t>
</li>
<li pn="section-appendix.a-2.13">
<t pn="section-appendix.a-2.13.1"><contact fullname="Brian Trammell"/>
</t>
</li>
</ul>
</section>
<section numbered="false" toc="include" anchor="Acknowledgement" removeInRFC
="false" pn="section-appendix.b">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.b-1">
This document was originally adapted from "Guidelines for Writing an IANA This document was originally adapted from "Guidelines for Writing an IANA
Considerations Section in RFCs" <xref target="RFC5226" format="default"/> , and has been modified to Considerations Section in RFCs" <xref target="RFC5226" format="default" s ectionFormat="of" derivedContent="RFC5226"/>, and has been modified to
include explicit reference to Intellectual Property Rights and include explicit reference to Intellectual Property Rights and
the roles of the IAB and IESG in relation to the IETF Protocol the roles of the IAB and IESG in relation to the IETF Protocol
Parameter Registry function. Parameter Registry function.
</t> </t>
<t> <t pn="section-appendix.b-2">
The document was updated under auspicies of the The document was updated under auspices of the
IASA2.0 working group to reflect the reorganization IASA2 working group to reflect the reorganization
of IETF Administrative Support Activity. of IETF Administrative Support Activity.
</t> </t>
<t> <t pn="section-appendix.b-3">
The Internet Architecture Board acknowledges the assistance The Internet Architecture Board acknowledges the assistance
provided by reviewers of drafts of this document, including provided by reviewers of drafts of this document, including
Scott Bradner, Brian Carpenter, Leslie Daigle, Adrian Farrel, <contact fullname="Scott Bradner"/>, <contact fullname="Brian Carpenter"/
Bob Hinden, >,
Alfred Hoenes, Paul Hoffman, Benjamin Kaduk, Alexey Melnikov, Thomas Nart <contact fullname="Leslie Daigle"/>, <contact fullname="Adrian Farrel"/
en, >,
and Ray Pelletier. <contact fullname="Bob Hinden"/>,
<contact fullname="Alfred Hoenes"/>, <contact fullname="Paul Hoffman"/>,
<contact fullname="Benjamin Kaduk"/>, <contact fullname="Alexey Me
lnikov"/>, <contact fullname="Thomas Narten"/>,
and <contact fullname="Ray Pelletier"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<name>IAB members</name> ="include" pn="section-appendix.c">
<t> <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
Internet Architecture Board Members at the time this document <author initials="D." surname="McPherson" fullname="Danny McPherson" role=
was approved for publication were [To Be Confirmed]: "editor">
<organization showOnFrontPage="true">Verisign, Inc.</organization>
</t> <address>
<ul empty="true" spacing="compact"> <email>dmcpherson@verisign.com</email>
<li>Jari Arkko,</li> </address>
<li>Alissa Cooper,</li> </author>
<li>Stephen Farrell</li> <author initials="O." surname="Kolkman" fullname="Olaf Kolkman" role="edit
<li>Wes Hardaker</li> or">
<li>Ted Hardie,</li> <organization abbrev="ISOC" showOnFrontPage="true">Internet Society</org
<li>Christian Huitema,</li> anization>
<li>Zhenbin Li</li> <address>
<li>Erik Nordmark,</li> <email>kolkman@isoc.org</email>
<li>Mark Nottingham,</li> </address>
<li>Jeff Tantsura,</li> </author>
<li>Martin Thomson,</li> <author initials="J." surname="Klensin" fullname="John C Klensin" role="ed
<li>Brian Trammell, and</li> itor">
</ul> <address>
</section> <email>john-ietf@jck.com</email>
<section anchor="DED" numbered="true" toc="default"> </address>
<name>Document Editing Details</name> </author>
<t> <author initials="G." surname="Huston" fullname="Geoff Huston" role="edito
[Text between square brackets starting with initials are r">
editor notes. Any other text between square brackets assumes <organization showOnFrontPage="true">APNIC</organization>
an action by the RFC editor prior to publication as an RFC. In <address>
most cases this will be removal, sometimes a stylistic or <email>gih@apnic.net</email>
editorial choices ore question is indicated] </address>
</t> </author>
<t>
[This section and
its subsections should be removed at publication as RFC, so
should the Cover Note]
</t>
<t>
Some notes for the RFC Editor.
</t>
<ul>
<li>
<t>
There are a few places where I've added a reference to <xref target=
"I-D.ietf-iasa2-rfc4071bis" format="default"/> mainly in places where I am not s
ure
if we should assume prior knowledge from the
reader. E.g. whether the Executive Director can be
presumed to be a known term in the context of this
document. Guidance is accepted.
</t>
<t>
Editorial Issue: By using a referencegroup for
BCP9 and BCP101 I seem to have lost to refer to specific
RFCs within the reference group i.e. I have references
to RFC6410 and RFC4371 specifically that I can't
resolve because these are inside a reference
group. I would like to retain the specific reference in the
places where I use the RFC reference and the generic
reference where I use the BCP reference. I presume the RFC
editor can and will resolve this.
</t>
<t>
There is a remaining '-' in order to get the
organizational name (Internet Architecture Board) printed
without any attributes in the author tag.
</t>
</li>
</ul>
<section numbered="true" toc="default">
<name>Version Information</name>
<section numbered="true" toc="default">
<name>draft-iab-iasa2-rfc6220-00</name>
<ul empty="true" spacing="compact">
<li>Original RFC text back ported into XML. With only
Editor affiliation changed and IAB members section emptied
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>draft-iab-iasa2-rfc6220-01</name>
<ul spacing="compact">
<li>Changed references to IAOC to LLC
</li>
<li>While reviewing the section on the Trust: Modified
reference to RFC 4748 to reference to RFC4371, as that
document establishes the Trust while 4748 is technically
an update of RFC 3978 (now obsoleted).
</li>
<li>Updated reference to ICANN-IETF MoU to most recent
version (2018) <xref target="MoU_SUPP2019" format="default"/> .
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>draft-iab-iasa2-rfc6220-02</name>
<ul spacing="compact">
<li>
Standardized on "IETF LLC" as the sort version for the
entity (per RFC style guide).
</li>
<li>
Changed "At the request of the chair of the IETF, IAB,
or LLC," to "At the request of the chair of the IETF
or IAB, or the IETF Executive Director", in the same
paragraph: The reporting of the registry operator does
not necessarily need to take place in IETF Plenary, it
may happen elsewhere. Text changed to reflect as much.
</li>
<li>
BCP101 is a better reference than exclusively
referring to RFC4371. The way the reference is
provided needs RFC Editor attention.
</li>
<li>
IDnits complained about
rfc5226 being obsoleted. One of the rfc5226
references is used for historical context in the
acknowledgement section, in other places it was
replaced by 8126.
</li>
<li>
IDnits complained about rfc5620 being obsoleted. The
reference to 5620 is replaced by rfc6635bis-rfc
editor model (not
including rfc6548bis-independent rfc editor, as it just serves
as an
example and does not intend to describe the full RFC
Editor universe).
</li>
<li>
Updated the Acknowledgement section
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>draft-iab-iasa2-rfc6220-03</name>
<ul spacing="compact">
<li>
Changed reference for IASA2 structure to <xref target="I-D.ietf-i
asa2-rfc4071bis" format="default"/>
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>draft-iab-iasa2-rfc6220-04</name>
<ul spacing="compact">
<li>
Migrated source from XML2RFC v2 to v3, which caused some
changes in layout.
</li>
<li>
Added obsoletion of 6220 sentence to Abstract and Introduction.
</li>
<li>
<t>
Changed reference in introduction from <xref target="RFC2026" for
mat="default"/> to <xref target="BCP9" format="default"/>, cleaned up the refere
nce
to <xref target="BCP101" format="default"/>
</t>
</li>
<li>
In <xref target="protocolparamreg"/> changed: "Proposed,
Draft, and full Internet Standards" to "Standard Track
Documents <xref target="RFC6410" format="default"/>”
</li>
<li> upgraded reference to ICANN MOU to the 2019 version
<xref target="MoU_SUPP2019" format="default"/>.
</li>
<li> In the paragraphs on IPR, just before
<xref target="IABrole" format="default"/>, I clarifed that
there may be circumstances where the vallues are not
public. This to make the text consistent.
</li>
<li>
Updated IAB membership.
</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>RCS information</name>
<t>
$Id: rfc6220bis.xml,v 1.10 2019/10/18 13:29:40 olaf Exp $
</t>
</section>
</section> </section>
<!--Version info-->
</back> </back>
</rfc> </rfc>
 End of changes. 143 change blocks. 
541 lines changed or deleted 552 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/