<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version="1.0" encoding="UTF-8"?>

<!-- draft submitted in xml v3 -->

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rsalz-2028bis-07" number="9281" submissionType="IETF" category="bcp" consensus="true" obsoletes="2028" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>Entities
    <title abbrev="Entities in IETF Standards Process">Entities Involved in the IETF Standards Process</title>
    <seriesInfo name="Internet-Draft" value="draft-rsalz-2028bis-07"/> name="RFC" value="9281"/>
    <seriesInfo name="BCP" value="11"/>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <date year="2022" month="March" day="14"/>
    <workgroup>???</workgroup> month="June"/>
    <keyword>IESG</keyword>
    <keyword>RFC Editor</keyword>
    <keyword>IRTF</keyword>
    <keyword>IETF LLC</keyword>
    <keyword>ISOC</keyword>
    <keyword>registries</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>This document describes the individuals and organizations involved in
the IETF standards process, as described in IETF BCP 9.
It includes brief descriptions of the entities involved, involved
and the role they play in the standards process.</t>
      <t>The IETF and its structure have undergone many changes since 1996, when RFC
2028 was published. published in 1996.  This document reflects the changed organizational
structure of the IETF and obsoletes RFC 2028.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the GENDISPATCH
    mailing list (gendispatch@ietf.org)], which is archived at
    <eref target="https://mailarchive.ietf.org/arch/browse/gendispatch/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/richsalz/draft-ietf-rfc2028bis"/>.
      </t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>The process used by the IETF community for the standardization of
protocols and procedures is described in BCP 9 <xref target="IETFPROCS" format="default"/>.
That document
BCP 9 defines
the stages in the standardization process, the requirements for
moving a document between stages, and the types of documents used
during this process.
This document identifies some of the key individual roles and organizations
in that process.</t>
      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology</name>
        <t>This document refers to individual roles in the singular,
such as "a Document Editor." document editor."
In reality, many roles are filled by more than one person at the same
time.
For clarity, this document does not use phrases like "Chair "chair (or co-chair)."</t>
      </section>
      <section anchor="changes-since-rfc-2028" numbered="true" toc="default">
        <name>Changes since RFC 2028</name>
        <t>The following changes have been made, in no particular order:</t>
        <ul spacing="normal">
          <li>Added the role of Responsible Area Director responsible area director (AD) and
re-ordered
reordered <xref target="individuals" format="default"/> to follow the typical workflow.</li>
          <li>Added the IETF Administration LLC and the IETF Trust to <xref target="organizations" format="default"/>.</li>
          <li>Changed RFC Editor "RFC Editor" to RFC "RFC Production Center, Center" to reflect the changes
made by <xref target="RFCEDMODEL" target="RFC9280" format="default"/>.</li>
<li>Added <xref target="acknowledgements" format="default"/> and the <xref target="terminology" format="default"/> format="title"/> and cleaned <xref target="acknowledgements" format="title"></xref> sections.</li>
<li>Cleaned up some wording
throughout the document.</li>
        </ul>
      </section>
    </section>
    <section anchor="individuals" numbered="true" toc="default">
      <name>Key Individuals in the Process</name>
      <t>This section describes the individual roles involved in the process.
It attempts to list the roles in the order in which they are involved
in the process, without otherwise expressing significance.</t>
      <section anchor="doceditor" numbered="true" toc="default">
        <name>The Document
        <name>Document Editor or Author</name>
        <t>Most Working Groups working groups (WGs) focus their efforts on one or more documents
that capture their work results.  The Working
Group Chair WG chair designates one or more people
to serve as the Editor(s) editor(s)
for a particular document.  They are  The editor is responsible for
ensuring that the contents of the document accurately reflect the
decisions that have been made by the Working Group.</t> WG.</t>
        <t>When a document is composed and edited mainly by one or more individuals,
they may be referred to as Document Authors. "document authors". The distinction is
not significant for the standards process.
This document uses the term Document Editor.</t> "document editor".</t>
        <t>When a Document Editor document editor is a Chair chair of the same Working Group, WG, another
Chair
chair should manage the process around the document. If another Chair chair is not
available, the WG and AD must monitor the process especially carefully to ensure that the
resulting documents accurately reflect the consensus of the Working Group WG and
that all processes are followed. This is the collective obligation
of all parties involved in the document.</t>
      </section>
      <section anchor="wgchair" numbered="true" toc="default">
        <name>The Working
        <name>Working Group Chair</name>
        <t>Each Working Group WG is headed by a Chair chair who has
the responsibility for facilitating the group's activities, presiding
over the group's meetings, and ensuring that the commitments of the
group with respect to its role in the Internet standards process are
met. In particular, the WG Chair chair is the formal point of contact
between the WG and the Internet Engineering Steering Group (IESG), via the AD of the area to
which the WG belongs.</t>
        <t>The details on the selection and responsibilities of a Working
Group Chair WG
chair can be found in <xref target="WGPROCS" format="default"/>.</t>
      </section>
      <section anchor="the-area-director" numbered="true" toc="default">
        <name>The Area
        <name>Area Director</name>
        <t>Each Working Group WG is assigned a single responsible Area Director area director (AD).
The AD can
assist the WG chair in assessing consensus and executing process.
The AD also reviews documents after the WG has approved them and, them, and
when satisfied, the AD
coordinates the IESG review and IETF last call of Last Call of
the document.</t>
        <t>An AD can also sponsor a draft an Internet-Draft directly, but this is not very common.
When this is done, a Working Group WG is not involved.</t>
        <t>Except for the General Area,
IETF Areas areas traditionally have multiple Area Directors.</t> ADs.</t>
      </section>
    </section>
    <section anchor="organizations" numbered="true" toc="default">
      <name>Key Organizations in the Process</name>
      <t>The following organizations and organizational roles are involved in
the Internet standards process.</t>
      <section anchor="internet-engineering-task-force-ietf" numbered="true" toc="default">
        <name>Internet Engineering Task Force (IETF)</name>
        <t>The IETF is an open international
community of network designers, operators, implementors, researchers,
and other interested parties who are
concerned with the evolution of the Internet architecture and the
smooth operation of the Internet.  It is the principal body engaged
in the development of new Internet Standard specifications and related documents.</t>
      </section>
      <section anchor="working-groups-wgs" numbered="true" toc="default">
        <name>Working Groups (WGs)</name>
        <t>The technical work of the IETF is done in its Working Groups, WGs, which
are organized by topics into several
<eref target="https://www.ietf.org/topics/areas/">Areas</eref>, target="https://www.ietf.org/topics/areas/">areas</eref>,
each one under the coordination of an Area Director.
Working Groups AD.
WGs typically have a narrow focus and a lifetime bounded
by completion of specific tasks as defined in their charter
and milestones. Some Working Groups WGs are long-lived and intended to conduct
ongoing maintenance on IETF protocol(s). There are also "dispatch" Working
Groups whose role is to WGs
that assess where new work in the IETF should be done, done but do
not directly produce standards.</t>
        <t>For all purposes relevant to the Internet Standards development
process, membership in the IETF and its Working Groups WGs is defined to
be established solely and entirely by individuals who
participate in
IETF and Working Group WG activities.
These individuals do not formally represent any organizations they may be affiliated with,
although affiliations are often used for identification.</t>
        <t>Anyone with the time and interest to do so is entitled and urged to
participate actively in one or more Working Groups WGs and to attend
IETF meetings, which are usually held
three times a year <xref target="MEETINGS" target="RFC8719" format="default"/>.
A WG may also schedule interim meetings (virtual, in-person, or hybrid).
These are scheduled and announced to the entire WG.
Active Working Group WG participation is possible without attending
any in-person meetings.</t>
        <t>Participants in the IETF and its Working Groups WGs must disclose
any relevant current or pending intellectual
property rights that are reasonably and personally known to the
participant if they participate in discussions about a specific
technology.
The full intellectual property policy is defined in <xref target="IPRRIGHTS1" format="default"/> and
<xref target="IPRRIGHTS2" format="default"/>.</t>
        <t>New Working Groups WGs are established by the IESG
and almost always have a specific and explicit charter.
The charter can be modified as the Working Group WG progresses.
The guidelines and procedures for the formation and
operation of Working Groups WGs are described in detail in <xref target="WGPROCS" format="default"/>.</t>
<t>A Working Group WG is managed by a Working Group Chair, WG chair, as described in
<xref target="wgchair" format="default"/>.  Documents produced by the group have an Editor, editor, as
described in <xref target="doceditor" format="default"/>.  Further details of Working Group WG operation can
be found in <xref target="WGPROCS" format="default"/>.</t>
        <t>Working Groups
        <t>WGs ideally display a spirit of cooperation as well as a high
degree of technical maturity; IETF participants recognize that the
greatest benefit for all members of the Internet community results
from cooperative development of technically excellent protocols and
services.</t>
      </section>
      <section anchor="internet-engineering-steering-group-iesg" numbered="true" toc="default">
        <name>Internet Engineering Steering Group (IESG)</name>
        <t>The IESG is
responsible for the management of the IETF technical
activities.  It administers the Internet Standards process according
to the rules and procedures defined in <xref target="IETFPROCS" format="default"/>.  The IESG is responsible
for the actions associated with the progression of documents
along the "IETF stream," IETF Stream, including the initial
approval of new Working Groups, WGs, any subsequent
rechartering, and the final approval of
documents.  The IESG is composed of the
Area Directors
ADs and the IETF Chair, who Chair. The IETF Chair also chairs the IESG and
is the Area Director AD for the General Area.
The Chair of the Internet Architecture Board (IAB) is an ex-officio ex officio member of the IESG.
  Various other bodies have liaisons with the IESG.</t> IESG;
  the full list can be found at
	<eref target="https://www.ietf.org/about/groups/iesg/members/" brackets="angle"/>.
</t>
        <t>All members of the IESG are nominated by a Nominations Committee
(colloquially, NomCom), "NomCom")
and are confirmed by the IAB.  See <xref target="NOMCOM" format="default"/> for a detailed
description of the NomCom procedures. Other matters concerning its the
organization and operation of the NomCom are described in the IESG charter Charter <xref target="IESG" target="RFC3710" format="default"/>.</t>
      </section>
      <section anchor="internet-architecture-board-iab" numbered="true" toc="default">
        <name>Internet Architecture Board (IAB)</name>
        <t>The IAB provides oversight of the architecture of the Internet and its
protocols.  The IAB approves IESG candidates put forward by the
NomCom. It also reviews all proposed IETF WG charters.</t>
        <t>The IAB provides oversight of the standards process
and serves as an appeal board for related complaints about improper
execution <xref target="IETFPROCS" format="default"/>. In general, it acts as a source
of advice about
technical, architectural, procedural, and policy matters
pertaining to the Internet and its enabling technologies.</t>
        <t>The members of the IAB are nominated by the NomCom, NomCom
and are confirmed by the Board of the Internet Society (ISOC).
The IETF Chair is also a member of the IAB, and the
Chair of the Internet Research Task Force (IRTF) is an ex-officio ex officio member.
Other
matters concerning the IAB's organization and operation are described in the IAB
charter
Charter <xref target="IAB" format="default"/>.</t>
      </section>
      <section anchor="the-rfc-production-center-rpc" numbered="true" toc="default">
        <name>The RFC
        <name>RFC Production Center (RPC)</name>
        <t>Publication
	<t>Editorial preparation and publication of RFCs is are handled by the RFC
   Production Center (RPC), including
editorial preparation and publication. (RPC).
RFC policy is defined by the RFC
Series Working Group (RSWG), an open group (similar to IETF Working Groups), WGs),
and approved by the RFC Series Advisory
Board (RSAB), which has appointed members.  The RFC Series Consulting Editor
	  (RSCE) is a position funded by the IETF Administration LLC, with responsibilities to consult
with all parties, and be a member of the RSAB.</t> defined in <xref target="RFC9280" format="default"/>.</t>
        <t>Full details on the roles and responsibilities of the RPC are specified in
<xref target="RFCEDMODEL" target="RFC9280" format="default"/>, in particular Section 4.</t> <xref target="RFC9280" sectionFormat="bare" section="4"/>.</t>
      </section>
      <section anchor="internet-assigned-numbers-authority-iana" numbered="true" toc="default">
        <name>Internet Assigned Numbers Authority (IANA)</name>
        <t>Many protocol specifications include parameters that must be
        uniquely assigned.  Examples of this include port numbers, option
        identifiers within a protocol, and so on. The Internet Assigned
        Numbers Authority (IANA) is responsible for assigning values to these
        protocol parameters, maintained in parameters and maintaining parameter registries.
These registries are <eref target="https://www.iana.org/protocols">maintained online</eref>. online (<eref
        target="https://www.iana.org/protocols"/>). Assignments are coordinated
        by writing an "IANA Considerations" section for a given document, as descrribed
        described in <xref target="IANADOCS" format="default"/>.  The IETF's
        relationship with IANA is defined by formal agreements, including
        <xref target="IANAMOU" target="RFC2860" format="default"/>.</t>
        <t>IANA also is also responsible for operating and maintaining
<eref target="https://www.iana.org/domains">several aspects of the DNS</eref> and
<eref target="https://www.iana.org/numbers">coordinating of IP address assignments</eref>.</t>
      </section>
      <section anchor="internet-research-task-force-irtf" numbered="true" toc="default">
        <name>Internet Research Task Force (IRTF)</name>
        <t>The IRTF focuses on longer-term research issues related to the Internet as a
parallel organization to the IETF, which
focuses on the shorter-term issues of engineering, operations, and
specification of standards.</t>
<t>The IRTF consists of a number of Research Groups research groups (RGs) chartered to research
various aspects related to the broader Internet.
The products of these RGs are typically research results that are
often published in scholarly conferences and journals, but they can also be published
as RFCs on the IRTF's RFC stream. IRTF Stream. RGs also
sometimes develop experimental protocols or technologies, some of which may be suitable
for possible standardization in IETF. Similarly, IETF working groups WGs
sometimes ask RGs for advice or other input.  Contributions  However, contributions from
RGs, however, in general
RGs generally
carry no more weight in the IETF than other community input, input
and go through the same standards setting standards-setting process as any other proposal.</t>
        <t>The IRTF is managed by the IRTF Chair in consultation with the Internet
Research Steering Group (IRSG).  The IRSG membership includes the IRTF Chair,
the Chairs chairs of the various RG RGs, and possibly other individuals
("members at large") from the community. Details of the organization
and operation of the IRTF, the ISRG, and its RGs may be found in
<xref target="IRTF" target="RFC2014" format="default"/>, <xref target="IABIRTF" target="RFC4440" format="default"/>, <xref target="IRTFPRIMER" target="RFC7418" format="default"/>, and <xref target="IRTFCHAIR" target="RFC7827" format="default"/>.</t>
      </section>
      <section anchor="the-ietf-trust" numbered="true" toc="default">
        <name>The IETF
        <name>IETF Trust</name>
        <t>The IETF Trust is the legal owner of intellectual
property for the IETF, IRTF, and IAB.
This includes their trademarks, the copyrights to RFCs and to works
of the IETF such as the IETF web site, website, and
copyright licenses for IETF contributions including Internet Drafts. Internet-Drafts.
The principles for the copyright licenses granted to and from the
Trust are described in <xref target="IPRRIGHTS1" format="default"/>
and <xref target="COPYRIGHT" target="RFC8721" format="default"/>, and the licenses themselves are in the
<eref target="https://trustee.ietf.org/documents/trust-legal-provisions/">Trust Legal Provisions</eref>.</t>
        <t>The Trust also currently owns IANA's domain names and trademarks through an
agreement with the IANA clients.</t> IANA.</t>
        <t>The Trustees that govern the Trust are selected from the IETF community, as
described in <xref target="TRUSTEES" target="RFC8714" format="default"/> and the rationale given in <xref target="TRUSTRAT" target="RFC8715" format="default"/>.</t>
      </section>
      <section anchor="ietf-administration-llc-ietf-llc" numbered="true" toc="default">
        <name>IETF Administration LLC (IETF LLC)</name>
        <t>The IETF Administration Limited Liability Corporation Company
(colloquially, the IETF LLC) "IETF LLC") provides
the corporate legal home for the IETF, the IAB, and the IRTF.</t>
<t>The IETF LLC is responsible for supporting the ongoing operations
of the IETF, managing its finances and budget, and raising money.
It regularly reports to the community.
The IETF LLC is the legal entity that signs contracts for the IETF
Secretariat, meeting hotels, tools development contractors, among many others.
The IETF LLC also responds to legal requests; these are often subpoenas
in patent lawsuits.</t>
        <t>Selection of the IETF LLC Board of Directors is defined in <xref target="NOMCOM" format="default"/>.</t>
        <t>The IETF Executive Director handles the IETF's daily tasks and management, management
and is overseen by the IETF LLC Board of Directors.</t>
        <t><xref section="6" sectionFormat="comma" target="ISOCIETF" sectionFormat="of" target="RFC8712" format="default"/> describes the legal relationship between the IETF
LLC and the Internet Society.</t>
      </section>
      <section anchor="ietf-secretariat" numbered="true" toc="default">
        <name>IETF Secretariat</name>
        <t>The administrative functions necessary to support the activities of
the IETF and its various related boards and organizations
are performed by a Secretariat contracted by the IETF LLC.
The IETF Secretariat handles much of the logistics of running the in-person
meetings,
meetings and is responsible for
maintaining the formal public record of the Internet standards
process <xref target="IETFPROCS" format="default"/>.</t>
      </section>
      <section anchor="internet-society-isoc" numbered="true" toc="default">
        <name>Internet Society (ISOC)</name>
        <t>ISOC plays an important role in the standards process.
In addition to being the legal entity that hosts the IETF LLC,
ISOC appoints the NomCom Chair, confirms IAB candidates selected by the NomCom,
and acts as the final authority in the appeals process.
This is described in <xref target="ISOCIETF" target="RFC8712" format="default"/>.</t>
        <t>The way in which the the ISOC leadership is
selected,
selected and other matters concerning the operation of the Internet
Society,
Society are described in <xref target="ISOC" format="default"/>.</t>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document introduces no new security considerations.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>We are grateful to the authors of <xref target="RFC2028" format="default"/>, Richard Hovey and Scott
Bradner.</t>
      <t>Barry Lieba, Colin Perkins, Eric Auerswald, John Levine, and Lars Eggert
provided useful feedback and corrections to this document.</t>
    </section>
  </middle>
  <back>

<displayreference target="RFC8721" to="COPYRIGHT"/>
<displayreference target="RFC4440" to="IABIRTF"/>
<displayreference target="RFC2860" to="IANAMOU"/>
<displayreference target="RFC3710" to="IESG"/>
<displayreference target="RFC2014" to="IRTF"/>
<displayreference target="RFC7827" to="IRTFCHAIR"/>
<displayreference target="RFC7418" to="IRTFPRIMER"/>
<displayreference target="RFC8712" to="ISOCIETF"/>
<displayreference target="RFC8719" to="MEETINGS"/>
<displayreference target="RFC9280" to="RFCEDMODEL"/>
<displayreference target="RFC8714" to="TRUSTEES"/>
<displayreference target="RFC8715" to="TRUSTRAT"/>

    <references>
      <name>Informative References</name>

      <referencegroup anchor="IAB" target="https://www.rfc-editor.org/info/bcp39">
        <!-- reference.RFC.2850.xml -->
<reference anchor="RFC2850" target="https://www.rfc-editor.org/info/rfc2850">
          <front>
            <title>Charter of the Internet Architecture Board (IAB)</title>
            <seriesInfo name="DOI" value="10.17487/RFC2850"/>
            <seriesInfo name="RFC" value="2850"/>
            <seriesInfo name="BCP" value="39"/>
            <author>
              <organization>Internet Architecture Board</organization>
            </author>
            <author fullname="B. Carpenter" initials="B." role="editor" surname="Carpenter">
              <organization/>
            </author>
            <date month="May" year="2000"/>
            <abstract>
              <t>This memo documents the composition, selection, roles, and organization of the Internet Architecture Board.  It replaces RFC 1601.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2850.xml"/>
      </referencegroup>

      <reference anchor="ISOC" target="https://www.internetsociety.org/about-internet-society/governance-policies/by-laws/">
        <front>
          <title>Amended and restated By-Laws of the Internet Society</title>
          <author>
            <organization/>
            <organization>Internet Society</organization>
          </author>
          <date year="2021" month="March"/>
        </front>
      </reference>
      <reference anchor="COPYRIGHT">
        <front>
          <title>Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents</title>
          <seriesInfo name="DOI" value="10.17487/RFC8721"/>
          <seriesInfo name="RFC" value="8721"/>
          <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern">
            <organization/>
          </author>
          <date month="February" year="2020"/>
          <abstract>
            <t>Contributors grant intellectual property rights to the IETF.  The IETF Trust holds and manages those rights on behalf of the IETF.  The Trustees of the IETF Trust are responsible for that management.  This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative Oversight Committee (IAOC), which was part of the IETF Administrative Support Activity (IASA).</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="IABIRTF">
        <front>
          <title>IAB Thoughts on the Role of the Internet Research Task Force (IRTF)</title>
          <seriesInfo name="DOI" value="10.17487/RFC4440"/>
          <seriesInfo name="RFC" value="4440"/>
          <author fullname="S. Floyd" initials="S." role="editor" surname="Floyd">
            <organization/>
          </author>
          <author fullname="V. Paxson" initials="V." role="editor" surname="Paxson">
            <organization/>
          </author>
          <author fullname="A. Falk" initials="A." role="editor" surname="Falk">
            <organization/>
          </author>
          <author>
            <organization>IAB</organization>
          </author>
          <date month="March" year="2006"/>
          <abstract>
            <t>This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF.  This document evolved from a discussion within the IAB as part of a process of appointing a new chair of the IRTF.  This memo provides information for the Internet community.</t>
          </abstract> month="May"/>
        </front>
      </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8721.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4440.xml"/>

      <referencegroup anchor="IANADOCS" target="https://www.rfc-editor.org/info/bcp26">
        <!-- reference.RFC.8126.xml -->
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/>
            <seriesInfo name="RFC" value="8126"/>
            <seriesInfo name="BCP" value="26"/>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing 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 authors, in order to assure that the provided guidance for the IANA Considerations 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>
            </abstract>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </referencegroup>
      <reference anchor="IANAMOU">
        <front>
          <title>Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority</title>
          <seriesInfo name="DOI" value="10.17487/RFC2860"/>
          <seriesInfo name="RFC" value="2860"/>
          <author fullname="B. Carpenter" initials="B." surname="Carpenter">
            <organization/>
          </author>
          <author fullname="F. Baker" initials="F." surname="Baker">
            <organization/>
          </author>
          <author fullname="M. Roberts" initials="M." surname="Roberts">
            <organization/>
          </author>
          <date month="June" year="2000"/>
          <abstract>
            <t>This document places on record the text of the Memorandum of Understanding 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, 2000.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2860.xml"/>

      <referencegroup anchor="IETFPROCS" target="https://www.rfc-editor.org/info/bcp9">
        <!-- reference.RFC.2026.xml -->
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026">
          <front>
            <title>The Internet Standards Process -- Revision 3</title>
            <seriesInfo name="DOI" value="10.17487/RFC2026"/>
            <seriesInfo name="RFC" value="2026"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="October" year="1996"/>
            <abstract>
              <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.5657.xml -->
<reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rfc5657">
          <front>
            <title>Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard</title>
            <seriesInfo name="DOI" value="10.17487/RFC5657"/>
            <seriesInfo name="RFC" value="5657"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="L. Dusseault" initials="L." surname="Dusseault">
              <organization/>
            </author>
            <author fullname="R. Sparks" initials="R." surname="Sparks">
              <organization/>
            </author>
            <date month="September" year="2009"/>
            <abstract>
              <t>Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol.  Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers.  This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report.   This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.6410.xml -->
<reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc6410">
          <front>
            <title>Reducing the Standards Track to Two Maturity Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC6410"/>
            <seriesInfo name="RFC" value="6410"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="R. Housley" initials="R." surname="Housley">
              <organization/>
            </author>
            <author fullname="D. Crocker" initials="D." surname="Crocker">
              <organization/>
            </author>
            <author fullname="E. Burger" initials="E." surname="Burger">
              <organization/>
            </author>
            <date month="October" year="2011"/>
            <abstract>
              <t>This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026.  Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.7100.xml -->
<reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rfc7100">
          <front>
            <title>Retirement of the "Internet Official Protocol Standards" Summary Document</title>
            <seriesInfo name="DOI" value="10.17487/RFC7100"/>
            <seriesInfo name="RFC" value="7100"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="P. Resnick" initials="P." surname="Resnick">
              <organization/>
            </author>
            <date month="December" year="2013"/>
            <abstract>
              <t>This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards".  It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.7127.xml -->
<reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rfc7127">
          <front>
            <title>Characterization of Proposed Standards</title>
            <seriesInfo name="DOI" value="10.17487/RFC7127"/>
            <seriesInfo name="RFC" value="7127"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="O. Kolkman" initials="O." surname="Kolkman">
              <organization/>
            </author>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <author fullname="S. Turner" initials="S." surname="Turner">
              <organization/>
            </author>
            <date month="January" year="2014"/>
            <abstract>
              <t>RFC 2026 describes the review performed by the Internet Engineering 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>
          </front>
        </reference>
        <!-- reference.RFC.7475.xml -->
<reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rfc7475">
          <front>
            <title>Increasing the Number of Area Directors in an IETF Area</title>
            <seriesInfo name="DOI" value="10.17487/RFC7475"/>
            <seriesInfo name="RFC" value="7475"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="S. Dawkins" initials="S." surname="Dawkins">
              <organization/>
            </author>
            <date month="March" year="2015"/>
            <abstract>
              <t>This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area".  This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.8789.xml -->
<reference anchor="RFC8789" target="https://www.rfc-editor.org/info/rfc8789">
          <front>
            <title>IETF Stream Documents Require IETF Rough Consensus</title>
            <seriesInfo name="DOI" value="10.17487/RFC8789"/>
            <seriesInfo name="RFC" value="8789"/>
            <seriesInfo name="BCP" value="9"/>
            <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern">
              <organization/>
            </author>
            <author fullname="E. Rescorla" initials="E." role="editor" surname="Rescorla">
              <organization/>
            </author>
            <date month="June" year="2020"/>
            <abstract>
              <t>This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus.  This updates RFC 2026.</t>
            </abstract>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5657.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6410.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7100.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7127.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7475.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8789.xml"/>
      </referencegroup>
      <reference anchor="IESG">
        <front>
          <title>An IESG charter</title>
          <seriesInfo name="DOI" value="10.17487/RFC3710"/>
          <seriesInfo name="RFC" value="3710"/>
          <author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
            <organization/>
          </author>
          <date month="February" year="2004"/>
          <abstract>
            <t>This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF).  It is meant to document the charter of the IESG as it is presently understood.  This memo provides information for the Internet community.</t>
          </abstract>
        </front>
      </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3710.xml"/>

      <referencegroup anchor="IPRRIGHTS1" target="https://www.rfc-editor.org/info/bcp78">
        <!-- reference.RFC.5378.xml -->
<reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5378">
          <front>
            <title>Rights Contributors Provide to the IETF Trust</title>
            <seriesInfo name="DOI" value="10.17487/RFC5378"/>
            <seriesInfo name="RFC" value="5378"/>
            <seriesInfo name="BCP" value="78"/>
            <author fullname="S. Bradner" initials="S." role="editor" surname="Bradner">
              <organization/>
            </author>
            <author fullname="J. Contreras" initials="J." role="editor" surname="Contreras">
              <organization/>
            </author>
            <date month="November" year="2008"/>
            <abstract>
              <t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible.  This memo details the IETF policies on rights in Contributions to the IETF.  It also describes the objectives that the policies are designed to meet.  This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026.  This document  specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5378.xml"/>
      </referencegroup>

      <referencegroup anchor="IPRRIGHTS2" target="https://www.rfc-editor.org/info/bcp79">
        <!-- reference.RFC.8179.xml -->
<reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179">
          <front>
            <title>Intellectual Property Rights in IETF Technology</title>
            <seriesInfo name="DOI" value="10.17487/RFC8179"/>
            <seriesInfo name="RFC" value="8179"/>
            <seriesInfo name="BCP" value="79"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <author fullname="J. Contreras" initials="J." surname="Contreras">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process.  The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders.  This document sets out the IETF policies concerning IPR related to technology worked on within the IETF.  It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026.  This document also obsoletes RFCs 3979 and 4879.</t>
            </abstract>
          </front>
        </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8179.xml"/>
      </referencegroup>
      <reference anchor="IRTF">
        <front>
          <title>IRTF Research Group Guidelines and Procedures</title>
          <seriesInfo name="DOI" value="10.17487/RFC2014"/>
          <seriesInfo name="RFC" value="2014"/>
          <seriesInfo name="BCP" value="8"/>
          <author fullname="A. Weinrib" initials="A." surname="Weinrib">
            <organization/>
          </author>
          <author fullname="J. Postel" initials="J." surname="Postel">
            <organization/>
          </author>
          <date month="October" year="1996"/>
          <abstract>
            <t>This document describes the guidelines and procedures for formation and operation of IRTF Research Groups.  It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB).  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="IRTFCHAIR">
        <front>
          <title>The Role of the IRTF Chair</title>
          <seriesInfo name="DOI" value="10.17487/RFC7827"/>
          <seriesInfo name="RFC" value="7827"/>
          <author fullname="L. Eggert" initials="L." surname="Eggert">
            <organization/>
          </author>
          <date month="March" year="2016"/>
          <abstract>
            <t>This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="IRTFPRIMER">
        <front>
          <title>An IRTF Primer for IETF Participants</title>
          <seriesInfo name="DOI" value="10.17487/RFC7418"/>
          <seriesInfo name="RFC" value="7418"/>
          <author fullname="S. Dawkins" initials="S." role="editor" surname="Dawkins">
            <organization/>
          </author>
          <date month="December" year="2014"/>
          <abstract>
            <t>This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF).  This document emphasizes differences in expectations between the two organizations.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="ISOCIETF">
        <front>
          <title>The IETF-ISOC Relationship</title>
          <seriesInfo name="DOI" value="10.17487/RFC8712"/>
          <seriesInfo name="RFC" value="8712"/>
          <author fullname="G. Camarillo" initials="G." surname="Camarillo">
            <organization/>
          </author>
          <author fullname="J. Livingood" initials="J." surname="Livingood">
            <organization/>
          </author>
          <date month="February" year="2020"/>
          <abstract>
            <t>This document summarizes the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="MEETINGS">
        <front>
          <title>High-Level Guidance for the Meeting Policy of the IETF</title>
          <seriesInfo name="DOI" value="10.17487/RFC8719"/>
          <seriesInfo name="RFC" value="8719"/>
          <seriesInfo name="BCP" value="226"/>
          <author fullname="S. Krishnan" initials="S." surname="Krishnan">
            <organization/>
          </author>
          <date month="February" year="2020"/>
          <abstract>
            <t>This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.</t>
          </abstract>
        </front>
      </reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2014.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7827.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7418.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8712.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8719.xml"/>

      <referencegroup anchor="NOMCOM" target="https://www.rfc-editor.org/info/bcp10">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8713.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8788.xml"/>
      </referencegroup>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2028.xml"/>

<!-- reference.RFC.8713.xml -->
<reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713">
          <front>
            <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title>
            <seriesInfo name="DOI" value="10.17487/RFC8713"/>
            <seriesInfo name="RFC" value="8713"/>
            <seriesInfo name="BCP" value="10"/>
            <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy">
              <organization/>
            </author>
            <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden">
              <organization/>
            </author>
            <author fullname="J. Livingood" initials="J." role="editor" surname="Livingood">
              <organization/>
            </author>
            <date month="February" year="2020"/>
            <abstract>
              <t>The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437.  Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.</t>
              <t>This document obsoletes [RFCEDMODEL] [I-D.iab-rfcefdp-rfced-model] RFC 7437 and RFC 8318.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.8788.xml 9280 -->

<reference anchor="RFC8788" target="https://www.rfc-editor.org/info/rfc8788">
          <front>
            <title>Eligibility for the 2020-2021 Nominating Committee</title>
            <seriesInfo name="DOI" value="10.17487/RFC8788"/>
            <seriesInfo name="RFC" value="8788"/>
            <seriesInfo name="BCP" value="10"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2020"/>
            <abstract>
              <t>The 2020-2021 Nominating Committee (NomCom) is to be formed between the IETF 107 and IETF 108 meetings, and the issue of eligibility of who can serve on that NomCom needs clarification. This document provides a one-time interpretation of the eligibility rules that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting.  This document only affects the seating of the 2020-2021 NomCom and any rules or processes that relate to NomCom eligibility before IETF 108; it does not set a precedent to be applied in the future.</t>
            </abstract>
          </front>
        </reference>
      </referencegroup>
      <reference anchor="RFC2028">
        <front>
          <title>The Organizations Involved in the IETF Standards Process</title>
          <seriesInfo name="DOI" value="10.17487/RFC2028"/>
          <seriesInfo name="RFC" value="2028"/>
          <seriesInfo name="BCP" value="11"/>
          <author fullname="R. Hovey" initials="R." surname="Hovey">
            <organization/>
          </author>
          <author fullname="S. Bradner" initials="S." surname="Bradner">
            <organization/>
          </author>
          <date month="October" year="1996"/>
          <abstract>
            <t>This document describes the individuals and organizations involved in the IETF.  This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFCEDMODEL" target="https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/"> anchor="RFC9280" target="https://www.rfc-editor.org/info/rfc9280">
<front>
<title>RFC Editor Model (Version 3)</title>
          <author>
            <organization/>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="TRUSTEES">
        <front>
          <title>Update to the Process for Selection of Trustees for the IETF Trust</title>
          <seriesInfo name="DOI" value="10.17487/RFC8714"/>
          <seriesInfo name="RFC" value="8714"/>
          <seriesInfo name="BCP" value="101"/>
<author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization/>
          </author>
          <author fullname="T. Hardie" initials="T." surname="Hardie">
            <organization/> fullname="Peter Saint-Andre" initials="P." surname="Saint-Andre" role="editor"> </author>
<date month="February" year="2020"/>
          <abstract>
            <t>This memo updates the process for selection of Trustees for the IETF Trust. Previously, the IETF Administrative Oversight Committee (IAOC) members also acted as Trustees, but the IAOC has been eliminated as part of an update to the structure of the IETF Administrative Support Activity (IASA). This memo specifies that the Trustees shall be selected separately.</t>
            <t>This memo obsoletes RFC 4371.  The changes relate only to the selection of Trustees. All other aspects of the IETF Trust remain as they are today.</t>
          </abstract> month="June" year="2022"/>
</front>
      </reference>
      <reference anchor="TRUSTRAT">
        <front>
          <title>IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust</title>
          <seriesInfo name="DOI" value="10.17487/RFC8715"/>
<seriesInfo name="RFC" value="8715"/>
          <author fullname="J. Arkko" initials="J." surname="Arkko">
            <organization/>
          </author>
          <date month="February" year="2020"/>
          <abstract>
            <t>This document captures the rationale for the changes introduced in RFC 8714, "Update to the Process for Selection of Trustees for the IETF Trust".</t>
            <t>At the time RFC 8714 was published, the changes to the IETF Administrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF Administrative Oversight Committee (IAOC), which was being phased out, had served as Trustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update.</t>
          </abstract>
        </front> value="9280"/>
<seriesInfo name="DOI" value="10.17487/RFC9280"/>
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8714.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8715.xml"/>

      <referencegroup anchor="WGPROCS" target="https://www.rfc-editor.org/info/bcp25">
        <!-- reference.RFC.2418.xml -->
<reference anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418">
          <front>
            <title>IETF Working Group Guidelines and Procedures</title>
            <seriesInfo name="DOI" value="10.17487/RFC2418"/>
            <seriesInfo name="RFC" value="2418"/>
            <seriesInfo name="BCP" value="25"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="September" year="1998"/>
            <abstract>
              <t>This document describes the guidelines and procedures for formation and operation of IETF working groups.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.3934.xml -->
<reference anchor="RFC3934" target="https://www.rfc-editor.org/info/rfc3934">
          <front>
            <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title>
            <seriesInfo name="DOI" value="10.17487/RFC3934"/>
            <seriesInfo name="RFC" value="3934"/>
            <seriesInfo name="BCP" value="25"/>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman">
              <organization/>
            </author>
            <date month="October" year="2004"/>
            <abstract>
              <t>This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists.  In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.7776.xml -->
<reference anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7776">
          <front>
            <title>IETF Anti-Harassment Procedures</title>
            <seriesInfo name="DOI" value="10.17487/RFC7776"/>
            <seriesInfo name="RFC" value="7776"/>
            <seriesInfo name="BCP" value="25"/>
            <author fullname="P. Resnick" initials="P." surname="Resnick">
              <organization/>
            </author>
            <author fullname="A. Farrel" initials="A." surname="Farrel">
              <organization/>
            </author>
            <date month="March" year="2016"/>
            <abstract>
              <t>IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists.  This document lays out procedures for managing and enforcing this policy.</t>
              <t>This document updates RFC 2418 by defining new working group guidelines and procedures.  This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</t>
            </abstract>
          </front>
        </reference>
        <!-- reference.RFC.8716.xml -->
<reference anchor="RFC8716" target="https://www.rfc-editor.org/info/rfc8716">
          <front>
            <title>Update
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2418.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3934.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7776.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8716.xml"/>
      </referencegroup>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>We are grateful to the IETF Anti-Harassment Procedures for the Replacement authors of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC</title>
            <seriesInfo name="DOI" value="10.17487/RFC8716"/>
            <seriesInfo name="RFC" value="8716"/>
            <seriesInfo name="BCP" value="25"/>
            <author fullname="P. Resnick" initials="P." surname="Resnick">
              <organization/>
            </author>
            <author fullname="A. Farrel" initials="A." surname="Farrel">
              <organization/>
            </author>
            <date month="February" year="2020"/>
            <abstract>
              <t>The IETF Anti-Harassment Procedures are described in RFC 7776.</t>
              <t>The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, <xref target="RFC2028" format="default"/> -- <contact fullname="Richard Hovey"/> and <contact fullname="Scott
Bradner"/>.</t>
      <t><contact fullname="Barry Leiba"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Eric Auerswald"/>, <contact fullname="John Levine"/>, and <contact fullname="Lars Eggert"/>
provided useful feedback and the IETF Administrative Director has been replaced by the IETF LLC Executive Director.  This document updates RFC 7776 to amend these terms.</t>
              <t>RFC 7776 contained updates corrections to RFC 7437.  RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.</t>
            </abstract>
          </front>
        </reference>
      </referencegroup>
    </references> document.</t>
    </section>

  </back>
  <!-- ##markdown-source:
H4sIAE5/L2IAA5VbXXPbOJZ9x69AJQ9tV8lO4sl0pz0PvbLjdns2Hy7LPamt
1NQWREISN/xQE6TVGlf/9z33XgAEabl39iGxRJHAxf089wA8OTlReZPVprLn
Om/NqjtpnSn/dXL2+uzdsnAnpems61SzdE1p8fFc0y+qK7oST1zV+FBYp2/q
h6Z8sLkuat1trL65uv9ZLzpT56bNnb5tm8w6pzKMtm7a/bleZlu1a9pv67bp
t+f6p59+UsW2Pddd27vu7PXrH1+fKeVogP82ZVNjrr11alucK627JpOvWrum
7Vq7cvH7vkq/Zk21NVkXf+2X8UrdKPXN7iFDfq6/3lwtrmf67udLfZUXXdPO
9M3d/c8zWceHD5f4tPiM/1u7LlzXYsm4Mv80/6dSpu82TUtyneCf1qLLuyLb
6AU0ydeadn2u599MZQp9b7NN3ZTNumCZtLa4Wp5r1vt/GL7pFGKqol41bWW6
4sHS6Dfzi3N9cXn7lx/pC6Q556c7064t1rPpuq07f/Vqt9udFnVn29p2rskK
2+1PMf0rs2z67iT8cuJ/erVuHnDB1Jk92TZlgYvu1XIPs+/cKxlfLD2vbJ3D
vjAIlADDdPhysT/5gBt1sxKj+8H1Qgbn53Pcea4/mjbbzMh33uDq5efb/7q7
uf7l/pxU/u4Hvoj1kc750tu3b1/zpU/z958vF7zus+/9lY+ff+Wbzt59zzfB
RLd34S5WDozJd/zlhzd8x+0dz7Z4w7f88C69dibX+Lkw/dnrN2/998tf5jd3
fPGHd2c/+Iu3dzcfr/zVt2/eeXuQIH5Bb85w7ePV1f3Np+tFuEZTfPr88fLz
R56SRePJzt6dhw9y6er9x8/vrz4cNjAUarrWZN9sewotr9i6iOFXEr6FWZ60
q8yu8i3/zU+qJrflyJiDn+uP9KM++odtXdHU+i/HuO/+7tfF/dVVFPxtuHY3
DxZ781dc+3I96P3sr0qdnJxos3QkXKfU/aZwGnL18JxO59ZlbbFEqiBPKeq8
eCjy3pSOPQpLMHXxL/h6Uzv8GpOJisnExWSylWQy08bFYTnx8H2QRf94qm46
XMnKHjfoJeJ15W/dyhTeY23IX2HKmSJx6KcW+Y4+7PW2NPuQ155IcUoL9SLS
o0XncFPbZ13fWr0xD1b3CJx2jRymK1PvdbYx9RpTOshn9Zsff/x+pncbW5Ni
FfmA3mFh235ZFm5j81PofqRJ5LfSZp0oUgYbK9CUapAghGaQLyZydgKa7lQM
VxV5XlqlXlIYt02O5zGWrM6vVfcOUy33w4hIU1VfF91eI1WNFORlwfwKTyNj
N97UPFYO0aD0if0eH2Ms//HHKWY2XepAq6JGxvSTrNloB6eM/sFmtL/1RWtp
CEdCqqp5KOq1NsPIS9vtLPQvo8508IBuv7XsKeFOUYCC8DRCR1aJXjC2UZGT
Z63Is1xTRSug3iSuzy52wP8VrwtrH1zs5UuUjbYquG7sp7EFj0D4oiw+HTyo
CAL3pWlnyvWoS/CvF0a/D89LKjh9oW5qjGVK2HMmvuolhB+tirIU41dNS4Fh
YFu49BYzQ+eQludB7QM2qOyp+hkOkWFKHqwb54IGg9ZNR+rU201rHL6XxTer
X1xuTNHqI3q2OcnoyzHkovVfjsImOK/456opy2ZHRgnBxYG3JKtWJrcz0kPd
6K1puyIjRUDjCMpzuL6e51TXYsjDVHfWbWGHYomvcyhEv4cHZZQtj+bvj8lg
qrUnPAKefHxMstkff5AZRJ7gREUGcxDWWeHi6XhKjqJ5DssSrBD/BdyIPsi/
3xMmonEfH0eOQkGC0S59DkiyOu6lb7cxjvWlpeI8o198AknyB+EQ0hOZ9/Fx
KEB+AhH38RE1p252cIO1xBMWS3I+PnaDb/prWWlNjYf6rQQAwSzYB9ELvLfe
AIrw9MElyMX1fyI6bpLC4H3XY0f9+DLVs48BZ2V5z5WXGAZjeBojC2XCdJ2t
th3HD1JuF10hSsCWpi+7DaE6LgoUE2FUNR4V6bzoeIkNrra7Al5uf98i41EY
woHXNVJDRpjLhzaenQQj5tRzBpZYd04Zk65i1R8bSPgFzkRDXRN4dvroy7U7
htNlPS8fAWRXSHVYUiNBilE4amMiU5xfMrPlGiHPkIcStOvLznHRsWEexfNo
iU1oGgugrmA09NY2W5QP6NDZFrFnxBKymiN3rKhAmDQCo+15LtFom0QeJWtb
u5BsfYbJGvgxpWKfUmNSMVnWI4BsuU8dXOU2KxyXfB5inBdCLRvpEzb5QuU4
qRBwNOobGucBMFkDHwHUa0yHQVJNJF46U+wrFfDD0kqapowBJUE90eJiZ+ic
VJ7DA5Hh2KkLpyhLDg7TPSmzz1ag3vlYoNh8kurjEqduhyGMN7RXMKX0sYKo
QrJnK7nRwddL0kaN+pkGAkza9D6RDda+WYXn/UQFFwNlHtAGGVheCveXa1b1
/L2uKPtVTS2ZLRkezgLrmhI2yOA9q54+QbnsNTb6jBKnJvmHSn7YXci9HD0e
/Wu0ck79PCwmDWKEAsk5n/AaG6Lw+AxXKUXB6xoAujUnboWxeQAKhgPZKc2K
L9NA1GkgPr7crblCIitcGeSl8U0QYGNNLjU72HS3aRACAqJirBVlAHArk9EX
00nIWc3d+XekLSyBkfJMUyIrOJlT6zi6rbKWHvUY6lDwVlXRVUn8Kn6UEyYL
xHZoGEVzNQ50Qugsn/g96V5VlvyqTrJL9KHoYh3jBPTT0HuDNpgEoGRCvUpA
gInfjWa9qtfAnpYXs+j8B1HzETWbxzP9UBh+Bv7qPccQcugaFYsGDb20ZQMF
+a4htx18ntM0h5otfTnzXfZgn0KQqDmYkpEZKL+sONgYR/vOjOu3d6ERkHnO
Y4yjZENZjiFjOc7IT7HQKS8Da4YIih725RMrzUTxNY3pK98QXOwev9usZ09L
UhgPhsxJKOWhsDuXhuyq8/6G4eHF2mzx5IMgqYrGnClupBwc2AF85zNvEpU1
jD+4agmsWlz7GVgWhlmlcVQTEZhoWiblBXqc136hIh+rhWsa991I3KSXEmB3
yeBGcgDlb0TJnl2/qU8l74Zfc9SN2WDUwQ70WMgKmPrq98xuh+R/bWvbwo/J
HjMlEBIfsbTWII1zC4i8xrWuosy3nRrPRcD1edJ5TyDXGG9O0fa4bZ82MkOH
k2Cl2NM/G9Hisgdj7964bxqNBRqAI1r2cdJ8k/cC7WyhXiG5Qi889KiwKUZk
nCMoBr3LjB5BIWjoY1FBU2Ru/gbXt0Rb0V1MC0jR4tGtIwAQEjilVcpDcPCM
pM4loTHDgGX3vhMeJxUaGjBC2nSfcpSrGsziZTrwFMDSTRfS2RZKyYot9Lxs
8j3y7RoFOKLR3D4g2Wy5uvPKdwlB55WuuYISthhM2NqSyb0YeGKQQ5hT1N8R
oRmbnBHj4H2c/IpS+niMmeBpRe7h/cbTCw16JnJGRpMP5OvqK3v4P49GNGdg
v+SBV5Rx3avjmbKU3Ghepl586fEZwCsVvjKKCETmeIG+cQtxZHRt2hZNncBs
UpRBu7Cy1O1C/zRTrpYc6HCiME3Qr+7guk4YK+IxQq2n7L2BFwFM0ZBVgXjp
IDnQ4KKZAi+JJCogJ2UhsdQJKwtFwfeo11P4taEnCJziV+oyqL6wOQITAzzO
aLPlKiX57AWQ59Z02ebFuMawdzvfHBdOwCtldCKt8DD5Fds9Zf49JFxaSXEM
Y0OCJCkgaYJh4WDEFjAk6luC2Y680D4Q4sV8Y2455ovEwVVsvSpbLRGwm2I7
EihQcxN9FoM9UKkhLjHbnnjTRJRBXIEyHaQXrJ9yl1CNEtCBMOzIz1WcboIc
I4LiMufGHGjecMoXfMKQlFAWtzX1fpJm05bCrFZABxyulHGQpkrqPNeb+IuE
NROB8AZh8KiOBIZKIp/L254iJiYu9mtWm893ZAnICVeB1pg4LX071LdrUWCq
Cl4wqawY96BTj66lH+rIk0V5A4oU6ETS966XWLQlIfDWioDUreyRpAF5AttO
mGdOCIFUJJUaKTzvGUxiJUUVJ9BHD0XbYWDih06EyZqRoJv9si3y42ApEiAM
Iis2dY2IzyTyApFMi7vG5AL3x+YfNCONHTCoE1AVuALRAIUdmTzKE4WFiW7D
IISG/g3v5sYJYZ2VCCkeNkYVmp+WC0OLzp2nZe1wswKFUDxhftTMtlhvOt88
S4duIBViRAJDhGTTEDdUe30MnkDd88rz6KNAYcF6J705b04R6PTpUnVhk2wv
qJB6u5GEOkrI21b7NJSFSo6bPkJJqeTSGQPjT8hcB/JrmgIi17245vxsyor4
F1PuzN6FwhBzvKDaLe2idSGti/j+S0DqVZMTOZwHlmTiK22zbrmxlIfXPYK1
JPJ7SqAHQOj3CaVxUCPwcGCBI85dWpCnXcP8KSiVBt/3kwc60icbMlB5aFH/
AHB5H5G8rwBRv9IEijrruAOLPnWyPTAQYTTez33LgCx2UZPVJiiK2pPnO6Rp
UcgtOzQVRNr6IQsXbeE7xmFQrHYHf6S/Rm8QJxB3TZmJEFDERDBMTyT433wJ
TmMYBbFZE+wZuAoMwDvucJMa7iygnyqjL2xPYOQAbz13p1ZtUw2CPjxBglE2
rNGis0BI1Z0e7dIoIvGKzP4ZGD/YCAdAjvaqcGpC57Hg4kVRlpDColAqqZQM
do1nx3mL4zASiFxAlgWeWdJy25dPo2acJpIdJyE9vfBp56uC8CbzBdXR/nms
u4GV4rD1gTdwrXR+QeiUF34nEzauZi/8BmXgWrDIrqD1c1drygDap6CZ8rjr
l87+1hPygQ9JcsE9w94VVogRkqHUAOfHy4zEpidkxn3ieCPChzm3O1RZObaT
jpo8x/cmY67gUOcqyW3ENUbTztPe6KKhTuXoZn5x7Ls8+/tJA3yTFY0Pi8GV
FqjA/zBt0RCFx+kBvVERdoSAiApHBoxWkyfU/ECE8YoI4TYVUwc+832Sr+wH
l0xoIRDUETF9zW8905Ezugm/HUvfSIMAnq+KtkpqyvwCllggXTw+yqkA1Ckh
ySWh0U7jsGUdpJKBE3c+1Z95mRUBiJbsyT0oV3Q4X4odpUMf8te0FsRVh3JF
4bG4DizS/2kdH/zzCxIP0JY4qwc6WAAIMbBiybNPWmLBMcOOcfBVDOnJHucl
xK1FznzOtuckuSMxRLdKlHTK2SPlkjxrK/7+Ja4zbuL/qeRPiAq2Le92cGNH
xNB2a7kbJ1nIlqGX5qaQGrIAdYpK8IvyLFjzJBfd1Hot0QJ0StsbncwCAN63
mWUOOaccLSOqmEBnqY7pa/AV/olSoQAm7zCKUBRE4zTUHLQH0C0hIrohObvk
lTaNGjLVNGgGx/2TgBBHeuYoERxs8fnS841DLuJ8QBY200Qwv4jJUB3OMXee
3hmzSnf3Pz+bZU4Vh5o6EGp+zu+c/n8H3PxCJfE2v0hJ24ObuPro7vYSwXZL
R0SyiPRwLze0G0xaDmr9kyFmQwVSgqsKBtYWIGWQfztMc8qnkw4g7mEutbB0
Om6CxI7uFl+IJQ8MnQC+I1dUBW0Fwu/YpuNSF7JnYHmTBc3h+a5p98pnn7sF
0k/oFz01TCQ/bdKJf/pMQg97CS+RwP22kCBOhWEur8T61J8xk4rOo84np174
PGDcshhx9ELE0LiKb0i2ecQfqWmf+CoJTxQItTiTHYHhhMih3QB++PZS+lNp
QgLuTvfw+fRDsvG68JsMb6dpPZD/n3oJadmYLDj65p/mcLmPBD5Cdp6Sh/68
FfV+prIerwHWchu6JDKuAGShxtFPBJtc/W6ILvPLKejsCw8C/bedrkUQ4mil
bw7Halqp4LS7EMURb0EuID+FrdW/v7AJ3OOtZxGSvAMAqhfTdkwHxPUPC50J
3WYCroy/JAdGA5swXGHDfU2ebGpq8yYkJ/Ayk5yxKCILyor8tkibsJviqTus
jQ851YCcWCD7OpQnUe1ehGMTflN+jSahjoB1aOPSg1n+JKacy5I4+M5JfaMh
iW9jh+fpxpnB77oZ6o1Y5JkakK8M/fHzr5z2+GlO6E8tEhIpryuPCqfk9dWz
xJB8y0fjfHC8/7R4Rpl5Q887OczzdSCHaVNjpW9uUVvzlluKQdPPDOWd9HgS
Tc+XFw828FHIZD5JwbSubU94uz7sPEALrrcuwogn9RnycbihhSvHlSfcekWn
mIVnTyZjPIMQ6MKMfiKs3Q4t3myoXZK91Cjimd9OONy4KsqAcHG/Yyn68eeq
ZFlhD+GOzq344ifLCytXDx7DB4tOVLBsG0PUftwXCecUqc4F+yPYMAMHyMDm
R936djlSW0oY0njwkhzfZZsGKZMOGACuQEgUfMnH/wMUVtMRD97ui7uCSHNx
AKQQKcpe4aSb7+TcpbSApyIenlN0SEoITd+sE5FEZCUcT8gu35xTI5WAsFk8
Xyi1z/PCri+IxJLGNVKN04OS/sjsqV5IHabGhQvcztdhLtMuEY5cmWTmvCHo
kwLT74sBiSOlI9cguy17KQpERig8MtObZkdRytXII1uVmbbd08k8poZ3lvF2
ymzKOUMefyA6eCZJ92tyBz5SNhxWGYC6s126wSwofe/Hk0bAlKnnjlmuYLSA
NetQ20V9Qw/pnVBFB3/Cjdwtro9DM4PP420Kf0x5PB2fHZKPMZ+FoLi79kCe
DbuPBogbCuroRcDlcO6STpC/OGZbxHMYrMpT/X4gz+iXNIeoMXoN+Jnfi+BP
i7vrWewRyC289wWajShX3E0IhJFt8iUeoqfvcogwnrZPAfBw/jHZ6pXzkJ5o
KO2aCI5dLTnmMIsd+AdJh7IE3vcn5CXndRIrwNa0k24r037zx4izZrsPVHgj
Ue13LihWnEqprHDENl7Y2aUGmrSSQ+NQGija1s7zuP48dRo7Q5WMGf89nTVw
Idvx9m+ZEMEHxl63pvaJkyQOPqBEiU9akjFxrsQ08X2NYC1WfJgBXypny4e4
08/jf5UJPrB5bqmrZqp/KKL8po+1o3cYhKGSn07Ysifb+OirYx+qXnRmoGQf
g2JgB40RfviOttOouvObON5O0ZwxXdCBlYBIklAmAJKVhd/3jrNZ6wuFvC/D
9w4alIM7dtDu5HT8IS47vGThD8wy2vdHFqxHZMN9d/P7yMI8c2L4KLQm6aGI
6X3I8yTmh8L4U1+XTQukLeE+obDSduc48iJK3EyeCtG3oRo0jrFpE85Bl74s
QTIfAHmu3xL0Dz112M0egEgaajPJ1p7rYtIzFuhln69tJ/O3puADSFVT2z0f
+gUI76Wwo9vlo7IeWAypkUX1Ug6Jhjc+9+ILhAydxCzTM6kG0AdnLXIrWupu
FjbxoChkJ0opDdXylJcPo/DJE1M1vIMfapUbhPF8FiktlyPLLBa95mABuf7m
cc+w4+v65baxteHXCmjvraaCsCOEQB6+iGfOvF5pkkjFDDzwdHstUJapSa+E
y3qwA/ErZMSQCyk4UW/24TxEnScbAlLSC8+90YE8X4QPy4Spka38i1ez2NZ+
j4gaHwcPKkp6lfTEH5trdOh+Qj4lgZdYVRZukgh7oH3K2m8R1JYgh2n5RKr3
6riH8BB6+OH9plBHQ40PgJfJxENviRg+dd1SdxWo6US66FBPuYuEREsfCKaq
qHx5ZyCQ6To6jIMLbV/Xw2aF359W4zOfBxrppFEbNitLTyvxFtgB2i9iuHCy
Y/py0KjXGpOEaCPxh1/bYh6vqEj3tBOdHik9cO7spqa2rwj909IGkZ+G/qZx
nRtpdSazeuLJpWS93zbxjKdjjjQhsGP1OMSUetq3G/Z0InfhFyKk8/Qg+IF3
q3ykxJjdyWttw/lUAXVYREkHhz06Bfz38omFm+d2GzhdP3duTXkTzQ4iDswp
NiWH5N3SCWMxfeOp8K+o8XtEvEvmwoPZ6EEe9AAFMh2QOEOMJPxDNjw6n7zy
oh9fPnkLRqkvknDXVBJXfRlqiZiKY4cZOXphiRAUvRtMyewX5Dk5RrHImq5T
F0ApNdHM6oL7og+FXZoZJC+hpltLPRnC7KpF2Mx7aH9nShjl780Gld0+FLUA
TP3BYM6r9RrIV/myndPBH5JsZW2+xArkJZ2mba1PVyxyopFT9b8Ix8TvGz4A
AA==

-->

</rfc>