<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
 <!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="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="Entities in IETF Standards Process">Entities Involved in the IETF Standards Process</title>
    <seriesInfo 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="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 BCP 9.
It includes brief descriptions of the entities involved
and the role they play in the standards process.</t>
      <t>The IETF and its structure have undergone many changes since RFC
2028 was published in 1996.  This document reflects the changed organizational
structure of the IETF and obsoletes RFC 2028.</t>
    </abstract>
  </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"/>.
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."
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 (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 (AD) and
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" to "RFC Production Center" to reflect the changes
made by <xref target="RFC9280" format="default"/>.</li>
<li>Added the <xref target="terminology" format="title"/> and <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>Document Editor or Author</name>
        <t>Most working groups (WGs) focus their efforts on one or more documents
that capture their work results.  The WG chair designates one or more people
to serve as the editor(s)
for a particular document.  The editor is responsible for
ensuring that the contents of the document accurately reflect the
decisions that have been made by the WG.</t>
        <t>When a document is composed and edited mainly by one or more individuals,
they may be referred to as "document authors". The distinction is
not significant for the standards process.
This document uses the term "document editor".</t>
        <t>When a document editor is a chair of the same WG, another
chair should manage the process around the document. If another 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 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>Working Group Chair</name>
        <t>Each WG is headed by a 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 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 WG
chair can be found in <xref target="WGPROCS" format="default"/>.</t>
      </section>
      <section anchor="the-area-director" numbered="true" toc="default">
        <name>Area Director</name>
        <t>Each WG is assigned a single responsible 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
when satisfied, the AD
coordinates the IESG review and IETF Last Call of
the document.</t>
        <t>An AD can also sponsor an Internet-Draft directly, but this is not very common.
When this is done, a WG is not involved.</t>
        <t>Except for the General Area,
IETF areas traditionally have multiple 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 WGs, which
are organized by topics into several
<eref target="https://www.ietf.org/topics/areas/">areas</eref>,
each under the coordination of an AD.
WGs typically have a narrow focus and a lifetime bounded
by completion of specific tasks as defined in their charter
and milestones. Some WGs are long-lived and intended to conduct
ongoing maintenance on IETF protocol(s). There are also "dispatch" WGs
that assess where new work in the IETF should be 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 WGs is defined to
be established solely and entirely by individuals who
participate in
IETF and 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 WGs and to attend
IETF meetings, which are usually held
three times a year <xref 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 WG participation is possible without attending
any in-person meetings.</t>
        <t>Participants in the IETF and its 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 WGs are established by the IESG
and almost always have a specific and explicit charter.
The charter can be modified as the WG progresses.
The guidelines and procedures for the formation and
operation of WGs are described in detail in <xref target="WGPROCS" format="default"/>.</t>
<t>A WG is managed by a WG chair, as described in
<xref target="wgchair" format="default"/>.  Documents produced by the group have an editor, as
described in <xref target="doceditor" format="default"/>.  Further details of WG operation can
be found in <xref target="WGPROCS" format="default"/>.</t>
        <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, including the initial
approval of new WGs, any subsequent
rechartering, and the final approval of
documents.  The IESG is composed of the
ADs and the IETF Chair. The IETF Chair also chairs the IESG and
is the AD for the General Area.
The Chair of the Internet Architecture Board (IAB) is an ex officio member of the IESG.
  Various other bodies have liaisons with the 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")
and are confirmed by the IAB.  See <xref target="NOMCOM" format="default"/> for a detailed
description of the NomCom procedures. Other matters concerning the
organization and operation of the NomCom are described in the IESG Charter <xref 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
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 member.
Other
matters concerning the IAB's organization and operation are described in the IAB
Charter <xref target="IAB" format="default"/>.</t>
      </section>
      <section anchor="the-rfc-production-center-rpc" numbered="true" toc="default">
        <name>RFC Production Center (RPC)</name>
	<t>Editorial preparation and publication of RFCs are handled by the RFC
   Production Center (RPC).
RFC policy is defined by the RFC
Series Working Group (RSWG), an open group (similar to IETF 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 defined in <xref target="RFC9280" format="default"/>.</t>
        <t>Full details on the roles and responsibilities of the RPC are specified in
<xref target="RFC9280" format="default"/>, in particular Section <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 and maintaining parameter registries online (<eref
        target="https://www.iana.org/protocols"/>). Assignments are coordinated
        by writing an "IANA Considerations" section for a given document, as
        described in <xref target="IANADOCS" format="default"/>.  The IETF's
        relationship with IANA is defined by formal agreements, including
        <xref target="RFC2860" format="default"/>.</t>
        <t>IANA 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 (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 Stream. RGs also
sometimes develop experimental protocols or technologies, some of which may be suitable
for possible standardization in IETF. Similarly, IETF WGs
sometimes ask RGs for advice or other input.  However, contributions from
RGs generally
carry no more weight in the IETF than other community input
and go through the same 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 of the various 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="RFC2014" format="default"/>, <xref target="RFC4440" format="default"/>, <xref target="RFC7418" format="default"/>, and <xref target="RFC7827" format="default"/>.</t>
      </section>
      <section anchor="the-ietf-trust" numbered="true" toc="default">
        <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 website, and
copyright licenses for IETF contributions including 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="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 IANA.</t>
        <t>The Trustees that govern the Trust are selected from the IETF community, as
described in <xref target="RFC8714" format="default"/> and the rationale given in <xref 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 Company
(colloquially, the "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
and is overseen by the IETF LLC Board of Directors.</t>
        <t><xref section="6" 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 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="RFC8712" format="default"/>.</t>
        <t>The way in which the ISOC leadership is
selected and other matters concerning the operation of the Internet
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>
  </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">
<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>Internet Society</organization>
          </author>
          <date year="2021" 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">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </referencegroup>

<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">
<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>

<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">
<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">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8179.xml"/>
      </referencegroup>

<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"/>

<!-- [RFCEDMODEL] [I-D.iab-rfcefdp-rfced-model] RFC 9280 -->

<reference anchor="RFC9280" target="https://www.rfc-editor.org/info/rfc9280">
<front>
<title>RFC Editor Model (Version 3)</title>
<author fullname="Peter Saint-Andre" initials="P." surname="Saint-Andre" role="editor"> </author>
<date month="June" year="2022"/>
</front>
<seriesInfo name="RFC" 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">
<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 authors of <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 corrections to this document.</t>
    </section>

  </back>

</rfc>
