<?xml version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-rsalz-2028bis-07" indexInclude="true" ipr="trust200902" number="9281" obsoletes="2028" prepTime="2022-06-30T10:09:19" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-rsalz-2028bis-07" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9281" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="Entities in IETF Standards Process">Entities Involved in the IETF Standards Process</title> <seriesInfo name="RFC" value="9281" stream="IETF"/> <seriesInfo name="BCP" value="11" stream="IETF"/> <author initials="R." surname="Salz" fullname="Rich Salz"> <organization showOnFrontPage="true">Akamai Technologies</organization> <address> <email>rsalz@akamai.com</email> </address> </author> <date month="06" year="2022"/> <keyword>IESG</keyword> <keyword>RFC Editor</keyword> <keyword>IRTF</keyword> <keyword>IETF LLC</keyword> <keyword>ISOC</keyword> <keyword>registries</keyword> <keyword>IANA</keyword> <abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">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 indent="0" pn="section-abstract-2">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> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This memo documents an Internet Best Current Practice. </t> <t indent="0" pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc9281" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2"> <li pn="section-toc.1-1.1.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.1.2.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-2028">Changes since RFC 2028</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.2"> <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-key-individuals-in-the-proc">Key Individuals in the Process</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2"> <li pn="section-toc.1-1.2.2.1"> <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-document-editor-or-author">Document Editor or Author</xref></t> </li> <li pn="section-toc.1-1.2.2.2"> <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-working-group-chair">Working Group Chair</xref></t> </li> <li pn="section-toc.1-1.2.2.3"> <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-area-director">Area Director</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-key-organizations-in-the-pr">Key Organizations in the Process</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2"> <li pn="section-toc.1-1.3.2.1"> <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-engineering-task-f">Internet Engineering Task Force (IETF)</xref></t> </li> <li pn="section-toc.1-1.3.2.2"> <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-working-groups-wgs">Working Groups (WGs)</xref></t> </li> <li pn="section-toc.1-1.3.2.3"> <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-engineering-steeri">Internet Engineering Steering Group (IESG)</xref></t> </li> <li pn="section-toc.1-1.3.2.4"> <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-architecture-board">Internet Architecture Board (IAB)</xref></t> </li> <li pn="section-toc.1-1.3.2.5"> <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-rfc-production-center-rpc">RFC Production Center (RPC)</xref></t> </li> <li pn="section-toc.1-1.3.2.6"> <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-assigned-numbers-a">Internet Assigned Numbers Authority (IANA)</xref></t> </li> <li pn="section-toc.1-1.3.2.7"> <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-research-task-forc">Internet Research Task Force (IRTF)</xref></t> </li> <li pn="section-toc.1-1.3.2.8"> <t indent="0" pn="section-toc.1-1.3.2.8.1"><xref derivedContent="3.8" format="counter" sectionFormat="of" target="section-3.8"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-trust">IETF Trust</xref></t> </li> <li pn="section-toc.1-1.3.2.9"> <t indent="0" pn="section-toc.1-1.3.2.9.1"><xref derivedContent="3.9" format="counter" sectionFormat="of" target="section-3.9"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-administration-llc-iet">IETF Administration LLC (IETF LLC)</xref></t> </li> <li pn="section-toc.1-1.3.2.10"> <t indent="0" pn="section-toc.1-1.3.2.10.1"><xref derivedContent="3.10" format="counter" sectionFormat="of" target="section-3.10"/>.聽<xref derivedContent="" format="title" sectionFormat="of" target="name-ietf-secretariat">IETF Secretariat</xref></t> </li> <li pn="section-toc.1-1.3.2.11"> <t indent="0" pn="section-toc.1-1.3.2.11.1"><xref derivedContent="3.11" format="counter" sectionFormat="of" target="section-3.11"/>.聽<xref derivedContent="" format="title" sectionFormat="of" target="name-internet-society-isoc">Internet Society (ISOC)</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.聽聽<xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">The process used by the IETF community for the standardization of protocols and procedures is described in BCP 9 <xref target="IETFPROCS" format="default" sectionFormat="of" derivedContent="IETFPROCS"/>. 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="include" removeInRFC="false" pn="section-1.1"> <name slugifiedName="name-terminology">Terminology</name> <t indent="0" pn="section-1.1-1">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="include" removeInRFC="false" pn="section-1.2"> <name slugifiedName="name-changes-since-rfc-2028">Changes since RFC 2028</name> <t indent="0" pn="section-1.2-1">The following changes have been made, in no particular order:</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-2"> <li pn="section-1.2-2.1">Added the role of responsible area director (AD) and reordered <xref target="individuals" format="default" sectionFormat="of" derivedContent="Section 2"/> to follow the typical workflow.</li> <li pn="section-1.2-2.2">Added the IETF Administration LLC and the IETF Trust to <xref target="organizations" format="default" sectionFormat="of" derivedContent="Section 3"/>.</li> <li pn="section-1.2-2.3">Changed "RFC Editor" to "RFC Production Center" to reflect the changes made by <xref target="RFC9280" format="default" sectionFormat="of" derivedContent="RFCEDMODEL"/>.</li> <li pn="section-1.2-2.4">Added the <xref target="terminology" format="title" sectionFormat="of" derivedContent="Terminology"/> and <xref target="acknowledgements" format="title" sectionFormat="of" derivedContent="Acknowledgements"/> sections.</li> <li pn="section-1.2-2.5">Cleaned up some wording throughout the document.</li> </ul> </section> </section> <section anchor="individuals" numbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-key-individuals-in-the-proc">Key Individuals in the Process</name> <t indent="0" pn="section-2-1">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="include" removeInRFC="false" pn="section-2.1"> <name slugifiedName="name-document-editor-or-author">Document Editor or Author</name> <t indent="0" pn="section-2.1-1">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 indent="0" pn="section-2.1-2">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 indent="0" pn="section-2.1-3">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="include" removeInRFC="false" pn="section-2.2"> <name slugifiedName="name-working-group-chair">Working Group Chair</name> <t indent="0" pn="section-2.2-1">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 indent="0" pn="section-2.2-2">The details on the selection and responsibilities of a WG chair can be found in <xref target="WGPROCS" format="default" sectionFormat="of" derivedContent="WGPROCS"/>.</t> </section> <section anchor="the-area-director" numbered="true" toc="include" removeInRFC="false" pn="section-2.3"> <name slugifiedName="name-area-director">Area Director</name> <t indent="0" pn="section-2.3-1">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 indent="0" pn="section-2.3-2">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 indent="0" pn="section-2.3-3">Except for the General Area, IETF areas traditionally have multiple ADs.</t> </section> </section> <section anchor="organizations" numbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-key-organizations-in-the-pr">Key Organizations in the Process</name> <t indent="0" pn="section-3-1">The following organizations and organizational roles are involved in the Internet standards process.</t> <section anchor="internet-engineering-task-force-ietf" numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-internet-engineering-task-f">Internet Engineering Task Force (IETF)</name> <t indent="0" pn="section-3.1-1">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="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-working-groups-wgs">Working Groups (WGs)</name> <t indent="0" pn="section-3.2-1">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/" brackets="none">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 indent="0" pn="section-3.2-2">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 indent="0" pn="section-3.2-3">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" sectionFormat="of" derivedContent="MEETINGS"/>. 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 indent="0" pn="section-3.2-4">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" sectionFormat="of" derivedContent="IPRRIGHTS1"/> and <xref target="IPRRIGHTS2" format="default" sectionFormat="of" derivedContent="IPRRIGHTS2"/>.</t> <t indent="0" pn="section-3.2-5">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" sectionFormat="of" derivedContent="WGPROCS"/>.</t> <t indent="0" pn="section-3.2-6">A WG is managed by a WG chair, as described in <xref target="wgchair" format="default" sectionFormat="of" derivedContent="Section 2.2"/>. Documents produced by the group have an editor, as described in <xref target="doceditor" format="default" sectionFormat="of" derivedContent="Section 2.1"/>. Further details of WG operation can be found in <xref target="WGPROCS" format="default" sectionFormat="of" derivedContent="WGPROCS"/>.</t> <t indent="0" pn="section-3.2-7">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="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-internet-engineering-steeri">Internet Engineering Steering Group (IESG)</name> <t indent="0" pn="section-3.3-1">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" sectionFormat="of" derivedContent="IETFPROCS"/>. 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 indent="0" pn="section-3.3-2">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" sectionFormat="of" derivedContent="NOMCOM"/> 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" sectionFormat="of" derivedContent="IESG"/>.</t> </section> <section anchor="internet-architecture-board-iab" numbered="true" toc="include" removeInRFC="false" pn="section-3.4"> <name slugifiedName="name-internet-architecture-board">Internet Architecture Board (IAB)</name> <t indent="0" pn="section-3.4-1">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 indent="0" pn="section-3.4-2">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" sectionFormat="of" derivedContent="IETFPROCS"/>. 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 indent="0" pn="section-3.4-3">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" sectionFormat="of" derivedContent="IAB"/>.</t> </section> <section anchor="the-rfc-production-center-rpc" numbered="true" toc="include" removeInRFC="false" pn="section-3.5"> <name slugifiedName="name-rfc-production-center-rpc">RFC Production Center (RPC)</name> <t indent="0" pn="section-3.5-1">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" sectionFormat="of" derivedContent="RFCEDMODEL"/>.</t> <t indent="0" pn="section-3.5-2">Full details on the roles and responsibilities of the RPC are specified in <xref target="RFC9280" format="default" sectionFormat="of" derivedContent="RFCEDMODEL"/>, in particular Section <xref target="RFC9280" sectionFormat="bare" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9280#section-4" derivedContent="RFCEDMODEL"/>.</t> </section> <section anchor="internet-assigned-numbers-authority-iana" numbered="true" toc="include" removeInRFC="false" pn="section-3.6"> <name slugifiedName="name-internet-assigned-numbers-a">Internet Assigned Numbers Authority (IANA)</name> <t indent="0" pn="section-3.6-1">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" brackets="none"/>). Assignments are coordinated by writing an "IANA Considerations" section for a given document, as described in <xref target="IANADOCS" format="default" sectionFormat="of" derivedContent="IANADOCS"/>. The IETF's relationship with IANA is defined by formal agreements, including <xref target="RFC2860" format="default" sectionFormat="of" derivedContent="IANAMOU"/>.</t> <t indent="0" pn="section-3.6-2">IANA is also responsible for operating and maintaining <eref target="https://www.iana.org/domains" brackets="none">several aspects of the DNS</eref> and <eref target="https://www.iana.org/numbers" brackets="none">coordinating of IP address assignments</eref>.</t> </section> <section anchor="internet-research-task-force-irtf" numbered="true" toc="include" removeInRFC="false" pn="section-3.7"> <name slugifiedName="name-internet-research-task-forc">Internet Research Task Force (IRTF)</name> <t indent="0" pn="section-3.7-1">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 indent="0" pn="section-3.7-2">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 indent="0" pn="section-3.7-3">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" sectionFormat="of" derivedContent="IRTF"/>, <xref target="RFC4440" format="default" sectionFormat="of" derivedContent="IABIRTF"/>, <xref target="RFC7418" format="default" sectionFormat="of" derivedContent="IRTFPRIMER"/>, and <xref target="RFC7827" format="default" sectionFormat="of" derivedContent="IRTFCHAIR"/>.</t> </section> <section anchor="the-ietf-trust" numbered="true" toc="include" removeInRFC="false" pn="section-3.8"> <name slugifiedName="name-ietf-trust">IETF Trust</name> <t indent="0" pn="section-3.8-1">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" sectionFormat="of" derivedContent="IPRRIGHTS1"/> and <xref target="RFC8721" format="default" sectionFormat="of" derivedContent="COPYRIGHT"/>, and the licenses themselves are in the <eref target="https://trustee.ietf.org/documents/trust-legal-provisions/" brackets="none">Trust Legal Provisions</eref>.</t> <t indent="0" pn="section-3.8-2">The Trust also currently owns IANA's domain names and trademarks through an agreement with IANA.</t> <t indent="0" pn="section-3.8-3">The Trustees that govern the Trust are selected from the IETF community, as described in <xref target="RFC8714" format="default" sectionFormat="of" derivedContent="TRUSTEES"/> and the rationale given in <xref target="RFC8715" format="default" sectionFormat="of" derivedContent="TRUSTRAT"/>.</t> </section> <section anchor="ietf-administration-llc-ietf-llc" numbered="true" toc="include" removeInRFC="false" pn="section-3.9"> <name slugifiedName="name-ietf-administration-llc-iet">IETF Administration LLC (IETF LLC)</name> <t indent="0" pn="section-3.9-1">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 indent="0" pn="section-3.9-2">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 indent="0" pn="section-3.9-3">Selection of the IETF LLC Board of Directors is defined in <xref target="NOMCOM" format="default" sectionFormat="of" derivedContent="NOMCOM"/>.</t> <t indent="0" pn="section-3.9-4">The IETF Executive Director handles the IETF's daily tasks and management and is overseen by the IETF LLC Board of Directors.</t> <t indent="0" pn="section-3.9-5"><xref section="6" sectionFormat="of" target="RFC8712" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8712#section-6" derivedContent="ISOCIETF"/> describes the legal relationship between the IETF LLC and the Internet Society.</t> </section> <section anchor="ietf-secretariat" numbered="true" toc="include" removeInRFC="false" pn="section-3.10"> <name slugifiedName="name-ietf-secretariat">IETF Secretariat</name> <t indent="0" pn="section-3.10-1">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" sectionFormat="of" derivedContent="IETFPROCS"/>.</t> </section> <section anchor="internet-society-isoc" numbered="true" toc="include" removeInRFC="false" pn="section-3.11"> <name slugifiedName="name-internet-society-isoc">Internet Society (ISOC)</name> <t indent="0" pn="section-3.11-1">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" sectionFormat="of" derivedContent="ISOCIETF"/>.</t> <t indent="0" pn="section-3.11-2">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" sectionFormat="of" derivedContent="ISOC"/>.</t> </section> </section> <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-4-1">This document introduces no new security considerations.</t> </section> <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-5-1">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 pn="section-6"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC8721" target="https://www.rfc-editor.org/info/rfc8721" quoteTitle="true" derivedAnchor="COPYRIGHT"> <front> <title>Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents</title> <author initials="J." surname="Halpern" fullname="J. Halpern" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="8721"/> <seriesInfo name="DOI" value="10.17487/RFC8721"/> </reference> <referencegroup anchor="IAB" target="https://www.rfc-editor.org/info/bcp39" derivedAnchor="IAB"> <reference anchor="RFC2850" target="https://www.rfc-editor.org/info/rfc2850" quoteTitle="true"> <front> <title>Charter of the Internet Architecture Board (IAB)</title> <author> <organization showOnFrontPage="true">Internet Architecture Board</organization> </author> <author initials="B." surname="Carpenter" fullname="B. Carpenter" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2000" month="May"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="39"/> <seriesInfo name="RFC" value="2850"/> <seriesInfo name="DOI" value="10.17487/RFC2850"/> </reference> </referencegroup> <reference anchor="RFC4440" target="https://www.rfc-editor.org/info/rfc4440" quoteTitle="true" derivedAnchor="IABIRTF"> <front> <title>IAB Thoughts on the Role of the Internet Research Task Force (IRTF)</title> <author initials="S." surname="Floyd" fullname="S. Floyd" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="V." surname="Paxson" fullname="V. Paxson" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Falk" fullname="A. Falk" role="editor"> <organization showOnFrontPage="true"/> </author> <author> <organization showOnFrontPage="true">IAB</organization> </author> <date year="2006" month="March"/> <abstract> <t indent="0">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> </front> <seriesInfo name="RFC" value="4440"/> <seriesInfo name="DOI" value="10.17487/RFC4440"/> </reference> <referencegroup anchor="IANADOCS" target="https://www.rfc-editor.org/info/bcp26" derivedAnchor="IANADOCS"> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials="M." surname="Cotton" fullname="M. Cotton"> <organization showOnFrontPage="true"/> </author> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Narten" fullname="T. Narten"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="June"/> <abstract> <t indent="0">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 indent="0">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 indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> </referencegroup> <reference anchor="RFC2860" target="https://www.rfc-editor.org/info/rfc2860" quoteTitle="true" derivedAnchor="IANAMOU"> <front> <title>Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority</title> <author initials="B." surname="Carpenter" fullname="B. Carpenter"> <organization showOnFrontPage="true"/> </author> <author initials="F." surname="Baker" fullname="F. Baker"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Roberts" fullname="M. Roberts"> <organization showOnFrontPage="true"/> </author> <date year="2000" month="June"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="2860"/> <seriesInfo name="DOI" value="10.17487/RFC2860"/> </reference> <reference anchor="RFC3710" target="https://www.rfc-editor.org/info/rfc3710" quoteTitle="true" derivedAnchor="IESG"> <front> <title>An IESG charter</title> <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"> <organization showOnFrontPage="true"/> </author> <date year="2004" month="February"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="3710"/> <seriesInfo name="DOI" value="10.17487/RFC3710"/> </reference> <referencegroup anchor="IETFPROCS" target="https://www.rfc-editor.org/info/bcp9" derivedAnchor="IETFPROCS"> <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true"> <front> <title>The Internet Standards Process -- Revision 3</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/> </reference> <reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rfc5657" quoteTitle="true"> <front> <title>Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard</title> <author initials="L." surname="Dusseault" fullname="L. Dusseault"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Sparks" fullname="R. Sparks"> <organization showOnFrontPage="true"/> </author> <date year="2009" month="September"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="5657"/> <seriesInfo name="DOI" value="10.17487/RFC5657"/> </reference> <reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc6410" quoteTitle="true"> <front> <title>Reducing the Standards Track to Two Maturity Levels</title> <author initials="R." surname="Housley" fullname="R. Housley"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Crocker" fullname="D. Crocker"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Burger" fullname="E. Burger"> <organization showOnFrontPage="true"/> </author> <date year="2011" month="October"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="6410"/> <seriesInfo name="DOI" value="10.17487/RFC6410"/> </reference> <reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rfc7100" quoteTitle="true"> <front> <title>Retirement of the "Internet Official Protocol Standards" Summary Document</title> <author initials="P." surname="Resnick" fullname="P. Resnick"> <organization showOnFrontPage="true"/> </author> <date year="2013" month="December"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7100"/> <seriesInfo name="DOI" value="10.17487/RFC7100"/> </reference> <reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rfc7127" quoteTitle="true"> <front> <title>Characterization of Proposed Standards</title> <author initials="O." surname="Kolkman" fullname="O. Kolkman"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Turner" fullname="S. Turner"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="January"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7127"/> <seriesInfo name="DOI" value="10.17487/RFC7127"/> </reference> <reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rfc7475" quoteTitle="true"> <front> <title>Increasing the Number of Area Directors in an IETF Area</title> <author initials="S." surname="Dawkins" fullname="S. Dawkins"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="March"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="7475"/> <seriesInfo name="DOI" value="10.17487/RFC7475"/> </reference> <reference anchor="RFC8789" target="https://www.rfc-editor.org/info/rfc8789" quoteTitle="true"> <front> <title>IETF Stream Documents Require IETF Rough Consensus</title> <author initials="J." surname="Halpern" fullname="J. Halpern" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="E." surname="Rescorla" fullname="E. Rescorla" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="June"/> <abstract> <t indent="0">This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="8789"/> <seriesInfo name="DOI" value="10.17487/RFC8789"/> </reference> </referencegroup> <referencegroup anchor="IPRRIGHTS1" target="https://www.rfc-editor.org/info/bcp78" derivedAnchor="IPRRIGHTS1"> <reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5378" quoteTitle="true"> <front> <title>Rights Contributors Provide to the IETF Trust</title> <author initials="S." surname="Bradner" fullname="S. Bradner" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Contreras" fullname="J. Contreras" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2008" month="November"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="78"/> <seriesInfo name="RFC" value="5378"/> <seriesInfo name="DOI" value="10.17487/RFC5378"/> </reference> </referencegroup> <referencegroup anchor="IPRRIGHTS2" target="https://www.rfc-editor.org/info/bcp79" derivedAnchor="IPRRIGHTS2"> <reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179" quoteTitle="true"> <front> <title>Intellectual Property Rights in IETF Technology</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Contreras" fullname="J. Contreras"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="79"/> <seriesInfo name="RFC" value="8179"/> <seriesInfo name="DOI" value="10.17487/RFC8179"/> </reference> </referencegroup> <reference anchor="RFC2014" target="https://www.rfc-editor.org/info/rfc2014" quoteTitle="true" derivedAnchor="IRTF"> <front> <title>IRTF Research Group Guidelines and Procedures</title> <author initials="A." surname="Weinrib" fullname="A. Weinrib"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Postel" fullname="J. Postel"> <organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="8"/> <seriesInfo name="RFC" value="2014"/> <seriesInfo name="DOI" value="10.17487/RFC2014"/> </reference> <reference anchor="RFC7827" target="https://www.rfc-editor.org/info/rfc7827" quoteTitle="true" derivedAnchor="IRTFCHAIR"> <front> <title>The Role of the IRTF Chair</title> <author initials="L." surname="Eggert" fullname="L. Eggert"> <organization showOnFrontPage="true"/> </author> <date year="2016" month="March"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="7827"/> <seriesInfo name="DOI" value="10.17487/RFC7827"/> </reference> <reference anchor="RFC7418" target="https://www.rfc-editor.org/info/rfc7418" quoteTitle="true" derivedAnchor="IRTFPRIMER"> <front> <title>An IRTF Primer for IETF Participants</title> <author initials="S." surname="Dawkins" fullname="S. Dawkins" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="December"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="7418"/> <seriesInfo name="DOI" value="10.17487/RFC7418"/> </reference> <reference anchor="ISOC" target="https://www.internetsociety.org/about-internet-society/governance-policies/by-laws/" quoteTitle="true" derivedAnchor="ISOC"> <front> <title>Amended and restated By-Laws of the Internet Society</title> <author> <organization showOnFrontPage="true">Internet Society</organization> </author> <date year="2021" month="May"/> </front> </reference> <reference anchor="RFC8712" target="https://www.rfc-editor.org/info/rfc8712" quoteTitle="true" derivedAnchor="ISOCIETF"> <front> <title>The IETF-ISOC Relationship</title> <author initials="G." surname="Camarillo" fullname="G. Camarillo"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood" fullname="J. Livingood"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">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> <seriesInfo name="RFC" value="8712"/> <seriesInfo name="DOI" value="10.17487/RFC8712"/> </reference> <reference anchor="RFC8719" target="https://www.rfc-editor.org/info/rfc8719" quoteTitle="true" derivedAnchor="MEETINGS"> <front> <title>High-Level Guidance for the Meeting Policy of the IETF</title> <author initials="S." surname="Krishnan" fullname="S. Krishnan"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">This document describes a meeting location policy for the IETF and the various stakeholders required to realize this policy.</t> </abstract> </front> <seriesInfo name="BCP" value="226"/> <seriesInfo name="RFC" value="8719"/> <seriesInfo name="DOI" value="10.17487/RFC8719"/> </reference> <referencegroup anchor="NOMCOM" target="https://www.rfc-editor.org/info/bcp10" derivedAnchor="NOMCOM"> <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true"> <front> <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title> <author initials="M." surname="Kucherawy" fullname="M. Kucherawy" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Hinden" fullname="R. Hinden" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Livingood" fullname="J. Livingood" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">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 indent="0">This document obsoletes RFC 7437 and RFC 8318.</t> </abstract> </front> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="8713"/> <seriesInfo name="DOI" value="10.17487/RFC8713"/> </reference> <reference anchor="RFC8788" target="https://www.rfc-editor.org/info/rfc8788" quoteTitle="true"> <front> <title>Eligibility for the 2020-2021 Nominating Committee</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="May"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="8788"/> <seriesInfo name="DOI" value="10.17487/RFC8788"/> </reference> </referencegroup> <reference anchor="RFC2028" target="https://www.rfc-editor.org/info/rfc2028" quoteTitle="true" derivedAnchor="RFC2028"> <front> <title>The Organizations Involved in the IETF Standards Process</title> <author initials="R." surname="Hovey" fullname="R. Hovey"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1996" month="October"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="11"/> <seriesInfo name="RFC" value="2028"/> <seriesInfo name="DOI" value="10.17487/RFC2028"/> </reference> <reference anchor="RFC9280" target="https://www.rfc-editor.org/info/rfc9280" quoteTitle="true" derivedAnchor="RFCEDMODEL"> <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> <reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="TRUSTEES"> <front> <title>Update to the Process for Selection of Trustees for the IETF Trust</title> <author initials="J." surname="Arkko" fullname="J. Arkko"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Hardie" fullname="T. Hardie"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">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 indent="0">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> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8714"/> <seriesInfo name="DOI" value="10.17487/RFC8714"/> </reference> <reference anchor="RFC8715" target="https://www.rfc-editor.org/info/rfc8715" quoteTitle="true" derivedAnchor="TRUSTRAT"> <front> <title>IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust</title> <author initials="J." surname="Arkko" fullname="J. Arkko"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">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 indent="0">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> <seriesInfo name="RFC" value="8715"/> <seriesInfo name="DOI" value="10.17487/RFC8715"/> </reference> <referencegroup anchor="WGPROCS" target="https://www.rfc-editor.org/info/bcp25" derivedAnchor="WGPROCS"> <reference anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418" quoteTitle="true"> <front> <title>IETF Working Group Guidelines and Procedures</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1998" month="September"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="2418"/> <seriesInfo name="DOI" value="10.17487/RFC2418"/> </reference> <reference anchor="RFC3934" target="https://www.rfc-editor.org/info/rfc3934" quoteTitle="true"> <front> <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title> <author initials="M." surname="Wasserman" fullname="M. Wasserman"> <organization showOnFrontPage="true"/> </author> <date year="2004" month="October"/> <abstract> <t indent="0">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> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="3934"/> <seriesInfo name="DOI" value="10.17487/RFC3934"/> </reference> <reference anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7776" quoteTitle="true"> <front> <title>IETF Anti-Harassment Procedures</title> <author initials="P." surname="Resnick" fullname="P. Resnick"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Farrel" fullname="A. Farrel"> <organization showOnFrontPage="true"/> </author> <date year="2016" month="March"/> <abstract> <t indent="0">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 indent="0">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> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="7776"/> <seriesInfo name="DOI" value="10.17487/RFC7776"/> </reference> <reference anchor="RFC8716" target="https://www.rfc-editor.org/info/rfc8716" quoteTitle="true"> <front> <title>Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC</title> <author initials="P." surname="Resnick" fullname="P. Resnick"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Farrel" fullname="A. Farrel"> <organization showOnFrontPage="true"/> </author> <date year="2020" month="February"/> <abstract> <t indent="0">The IETF Anti-Harassment Procedures are described in RFC 7776.</t> <t indent="0">The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, 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 indent="0">RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.</t> </abstract> </front> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="8716"/> <seriesInfo name="DOI" value="10.17487/RFC8716"/> </reference> </referencegroup> </references> <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t indent="0" pn="section-appendix.a-1">We are grateful to the authors of <xref target="RFC2028" format="default" sectionFormat="of" derivedContent="RFC2028"/> -- <contact fullname="Richard Hovey"/> and <contact fullname="Scott Bradner"/>.</t> <t indent="0" pn="section-appendix.a-2"><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> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-address">Author's Address</name> <author initials="R." surname="Salz" fullname="Rich Salz"> <organization showOnFrontPage="true">Akamai Technologies</organization> <address> <email>rsalz@akamai.com</email> </address> </author> </section> </back> </rfc>