<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 3.4.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-eggert-procon-chair-delegate-02" category="bcp" consensus="true" submissionType="IETF" updates="2850, 3710, 4949, 8713, 9281" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title>The IETF Chair May Delegate</title>
    <seriesInfo name="Internet-Draft" value="draft-eggert-procon-chair-delegate-02"/>
    <author initials="L." surname="Eggert" fullname="Lars Eggert" role="editor">
      <organization>Mozilla</organization>
      <address>
        <postal>
          <street>Stenbergintie 12 B</street>
          <city>Kauniainen</city>
          <code>02700</code>
          <country>FI</country>
        </postal>
        <email>lars@eggert.org</email>
        <uri>https://eggert.org/</uri>
      </address>
    </author>
    <date year="2026" month="June" day="29"/>
    <workgroup>Process Document Consolidation</workgroup>
    <abstract>
      <?line 28?>

<t>This document affirms that the IETF Chair may delegate some of their
responsibilities to other Area Directors, and updates several
existing RFCs to enable that.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://ietf-wg-procon.github.io/ietf-chair-may-delegate/draft-eggert-procon-chair-delegate.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-eggert-procon-chair-delegate/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        procon Working Group mailing list (<eref target="mailto:procon@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/procon/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/procon/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-procon/ietf-chair-may-delegate"/>.</t>
    </note>
  </front>
  <middle>
    <?line 34?>

<section anchor="intro">
      <name>Introduction</name>
      <t>Throughout the history of the IETF, the role of the IETF Chair has
always been filled by a single person. None of the foundational
documents of the organization precisely define the role, but most are
written with an understanding that the role is filled by a single
person who is then tasked with numerous responsibilities. The expired
Internet-Draft <xref target="I-D.carpenter-ietf-chair-tasks"/> attempted to
define the role of the IETF Chair more precisely but was not taken
forward.</t>
      <t>Few documents explicitly say that the IETF Chair may delegate some of
these responsibilities. Over time, this has created a situation where
even a full-time commitment by a single person may no longer be
sufficient to fulfill all of these roles and duties. There may also
be periods of high activity where not all duties can be performed due
to other, higher-priority tasks.</t>
      <t>Single bottlenecks like this have obvious scaling and fault tolerance
issues. This document hence explicitly allows the IETF
Chair to delegate some of their responsibilities to one or more other
Area Directors. It leaves it up to each IETF Chair to determine if
they would like to delegate some of their responsibilities, and if
so, which ones, to whom and when.</t>
      <t>One model that is specifically enabled by this document is a
separation of the roles of the IETF Chair from that of the IESG
Chair, allowing another Area Director to take over the chairperson
role of the IESG and its associated responsibilities. It also enables
delegation of the IETF Chair's full IAB membership and delegation or
sharing of the role of the General Area Director.</t>
      <t>This document does not require or even recommend that the IETF chair
delegate any of their duties, it merely permits them to do so if they
so choose. Specifically, with these changes, it should be possible
for the IESG to request the selection of a General Area Director who
is not at the same time also the IETF Chair, to whom the IETF Chair
may then delegate some of their responsibilities.</t>
      <t>There must be community transparency about which roles the IETF Chair
has delegated to which other Area Director, and for which time. This
transparency can be guaranteed in several ways, such as through the
IESG website or public email. Such operational details are left to
the discretion of the IESG.</t>
    </section>
    <section anchor="separating-the-ietf-chair-and-iesg-chair-roles">
      <name>Separating the IETF Chair and IESG Chair Roles</name>
      <t>This section analyzes which RFCs imply that the IETF Chair and IESG
Chair roles need to be filled by the same person, and makes
updates that would allow a separation.</t>
      <section anchor="background">
        <name>Background</name>
        <t><xref target="RFC2026"/> is surprisingly silent on the role of the IETF Chair,
only mentioning it in <xref section="14" sectionFormat="of" target="RFC2026"/> as part of the
terminology:</t>
        <ul empty="true">
          <li>
            <t>Area Director - The manager of an IETF Area.  The Area Directors
  along with the IETF Chair comprise the Internet Engineering
  Steering Group (IESG).</t>
            <t>Internet Engineering Steering Group (IESG) - A group comprised of
  the IETF Area Directors and the IETF Chair. (...)</t>
          </li>
        </ul>
        <t>Similarly, the role of the IESG Chair is only briefly mentioned in
<xref section="6.5.2" sectionFormat="of" target="RFC2026"/> as part of how process failures are
handled:</t>
        <ul empty="true">
          <li>
            <t>If an individual should disagree with an action taken by the IESG in
  this process, that person should first discuss the issue with the
  IESG Chair. If the IESG Chair is unable to satisfy the complainant
  then (...)</t>
          </li>
        </ul>
        <t><xref target="RFC2026"/> does not require the IETF Chair to also fulfill the role
of IESG Chair. <xref section="1.2" sectionFormat="of" target="RFC1602"/>, the earlier revision of
the standards process that <xref target="RFC2026"/> obsoletes, is an
Informational RFC and does include text to that effect, however:</t>
        <ul empty="true">
          <li>
            <t>The IESG is composed of the IETF Area Directors and the
  chairperson of the IETF, who also serves as the chairperson of the
  IESG.</t>
          </li>
        </ul>
        <t><xref section="1.2" sectionFormat="of" target="RFC1602"/> is likely the basis for
<xref target="RFC2028"/>, a BCP that includes similar text:</t>
        <ul empty="true">
          <li>
            <t>The IESG is composed of the IETF Area Directors and the chair of the
  IETF, who also serves as the chair of the IESG.</t>
          </li>
        </ul>
        <t><xref section="3.3" sectionFormat="of" target="RFC9281"/>, a BCP that obsoletes
<xref target="RFC2028"/>, retains that text and also states that the IETF Chair is
the Area Director for the General Area:</t>
        <ul empty="true">
          <li>
            <t>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.</t>
          </li>
        </ul>
        <t><xref section="4" sectionFormat="of" target="RFC4949"/>, an Informational RFC containing an Internet
Security Glossary, contains this text under the "Internet Engineering
Steering Group (IESG)" glossary item:</t>
        <ul empty="true">
          <li>
            <t>The part of the ISOC responsible for technical management of IETF
  activities and administration of the Internet Standards Process
  according to procedures approved by the ISOC Trustees. Directly
  responsible for actions along the "standards track", including
  final approval of specifications as Internet Standards. Composed of
  IETF Area Directors and the IETF chairperson, who also chairs the
  IESG. (RFC 2026)</t>
          </li>
        </ul>
      </section>
      <section anchor="prop-chair-roles">
        <name>Delegation of the IESG Chair Role</name>
        <t>To allow the IETF Chair to delegate the role of IESG Chair to another
AD (as arguably intended to be allowed by <xref target="RFC2026"/>), the
following updates to existing RFCs are needed:</t>
        <ol spacing="normal" type="1"><li>
            <t>Remove the sentence "The IETF Chair also chairs the IESG and is the
AD for the General Area." from <xref section="3.3" sectionFormat="of" target="RFC9281"/>.</t>
          </li>
          <li>
            <t>Change the clause "The IETF chair, who is also the chair of the
Internet Engineering Steering Group (IESG)" in the second sentence
of <xref section="1" sectionFormat="of" target="RFC2850"/> to "The IETF chair or their delegate".
(This is also part of the change in <xref target="prop-gen-ad"/>.)</t>
          </li>
          <li>
            <t>Remove the clause "who also chairs the IESG" from the "Internet
Engineering Steering Group (IESG)" glossary item in <xref section="4" sectionFormat="of" target="RFC4949"/>.</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="delegation-of-the-iab-membership">
      <name>Delegation of the IAB Membership</name>
      <t>This section analyzes which RFCs contain text about the full IAB
membership of the IETF Chair, and makes updates that
would allow delegation of the IAB membership.</t>
      <section anchor="background-1">
        <name>Background</name>
        <t><xref section="1" sectionFormat="of" target="RFC2850"/> requires the IETF Chair to be a full member
of the IAB:</t>
        <ul empty="true">
          <li>
            <t>The Internet Architecture Board (IAB) shall consist of thirteen full
  members, composed of the chair of the Internet Engineering Task
  Force (IETF), and of twelve sitting members.</t>
          </li>
        </ul>
        <t><xref section="C" sectionFormat="of" target="RFC8713"/> contains a similar statement as part of the
second item in a list of "oral traditions" recorded
for "consideration by future NomComs":</t>
        <ul empty="true">
          <li>
            <t>No person should serve both on the IAB and as an Area Director,
  except the IETF Chair whose roles as an IAB member and Area
  Director of the General Area are set out elsewhere.</t>
          </li>
        </ul>
        <t><xref section="3.4" sectionFormat="of" target="RFC9281"/> says:</t>
        <ul empty="true">
          <li>
            <t>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.</t>
          </li>
        </ul>
      </section>
      <section anchor="delegation-of-the-iab-member-role">
        <name>Delegation of the IAB Member Role</name>
        <t>To allow the IETF Chair to delegate their full IAB membership to
another AD, the following updates to existing RFCs are needed:</t>
        <ol spacing="normal" type="1"><li>
            <t>Add "or their Delegate Area Director" at the end of the
clause "composed of the chair of the Internet Engineering Task Force
(IETF)" in <xref section="1" sectionFormat="of" target="RFC2850"/>.</t>
          </li>
          <li>
            <t>Add "With the publication of RFCXXXX, IETF guidance on this issue
has changed as described there." to the second bullet item in
<xref section="C" sectionFormat="of" target="RFC8713"/>.</t>
          </li>
          <li>
            <t>Change the sentence "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." to "The IETF Chair or their delegate is also a
member of the IAB, and the Chair of the Internet Research Task Force
(IRTF) is an ex officio member." in <xref section="3.4" sectionFormat="of" target="RFC9281"/>.</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="delegation-of-the-general-area-director-role">
      <name>Delegation of the General Area Director Role</name>
      <t>This section analyzes which RFCs contain text about the responsibility
of the IETF Chair to also serve as Area Director of the General Area,
and makes updates that would allow delegation of or
sharing of the role.</t>
      <section anchor="background-2">
        <name>Background</name>
        <t><xref section="2" sectionFormat="of" target="RFC3710"/> states that the IETF Chair is the General
Area Director:</t>
        <ul empty="true">
          <li>
            <t>The IETF Chair, who also functions as the General Area Director when
  this area is active</t>
          </li>
        </ul>
        <t><xref section="3.3" sectionFormat="of" target="RFC9281"/> also makes a similar statement:</t>
        <ul empty="true">
          <li>
            <t>The IETF Chair also chairs the IESG and is the AD for the General
  Area.</t>
          </li>
        </ul>
      </section>
      <section anchor="prop-gen-ad">
        <name>Delegation of the GEN Area AD Role</name>
        <t>To allow the IETF Chair to delegate the Area Director role of the
General Area, the following updates to existing RFCs are needed:</t>
        <ol spacing="normal" type="1"><li>
            <t>Replace "who also functions as the General Area Director" with "who
may also function as a General Area Director or may share that role
with or delegate that role to another Area Director" in <xref section="2" sectionFormat="of" target="RFC3710"/>.</t>
          </li>
          <li>
            <t>Change the clause "The IETF chair, who is also the chair of the
Internet Engineering Steering Group (IESG)" in the second sentence
of <xref section="1" sectionFormat="of" target="RFC2850"/> to "The IETF chair or their delegate".
(This is also part of the changes in <xref target="prop-chair-roles"/>.)</t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="other-updates">
      <name>Other Updates</name>
      <t>This section collects updates to some text in existing RFCs that has
become stale.</t>
      <section anchor="staff-supervision">
        <name>Staff Supervision</name>
        <t><xref section="7.1" sectionFormat="of" target="RFC3710"/> says</t>
        <ul empty="true">
          <li>
            <t>The IETF Chair has primary responsibility for supervising the work
  of the IETF Secretariat, with the advice and consent of the IESG,
  the IAB Chair and the ISOC president.</t>
          </li>
        </ul>
        <t>With the publication of <xref target="RFC8711"/>, this responsibility has moved to
the IETF Executive Director. The document updates
<xref section="7.1" sectionFormat="of" target="RFC3710"/> to remove the sentence above.</t>
      </section>
    </section>
    <section anchor="other-roles">
      <name>Other Roles</name>
      <t>This section briefly summarizes other roles the IETF Chair has, but
which require no updates, usually because delegation is already
permitted.</t>
      <section anchor="liaison-statements">
        <name>Liaison Statements</name>
        <t><xref section="3.1" sectionFormat="of" target="RFC4691"/> says</t>
        <ul empty="true">
          <li>
            <t>Liaison statements are only sent on the initiative of the IETF
  chair, the IAB chair, IETF Area Directors, or IETF working group
  chairs.</t>
          </li>
        </ul>
        <t><xref section="4" sectionFormat="of" target="RFC4052"/> says</t>
        <ul empty="true">
          <li>
            <t>For a liaison statement generated on behalf of the IETF as a whole,
  the IETF Chair must have generated or must agree with the sending
  of the liaison statement.  If the liaison statement is not sent by
  the IETF Chair, then his or her agreement must be obtained in
  advance and confirmed by copying the IETF Chair on the message.</t>
          </li>
        </ul>
        <t>The combination of these two statements already allows another Area
Director to send a liaison statement on behalf of the IETF with IETF
Chair approval.</t>
      </section>
      <section anchor="transgressions-of-the-ietf-guidelines-for-conduct">
        <name>Transgressions of the IETF Guidelines for Conduct</name>
        <t><xref section="A" sectionFormat="of" target="RFC7154"/> says "An individual can report
transgressions of the guidelines for conduct to the IETF Chair or the
IESG."</t>
        <t>However, <xref target="RFC7154"/> does not define any reactions the IETF Chair or
the IESG should or may take, so the IETF Chair only acts as a
recipient here.</t>
      </section>
      <section anchor="appointments-to-the-ombuds-moderator-and-last-call-list-moderation-teams">
        <name>Appointments to the Ombuds-, Moderator and Last-Call List Moderation Teams</name>
        <t>The IETF Chair is tasked with managing the constituency of the
ombudsteam <xref target="RFC7776"/> and the moderator team of the IETF discussion
list <xref target="RFC9245"/>. They also select moderators for the Last-Call
mailing list, and other lists with an organizational scope
encompassing the entire IETF.</t>
        <t>This document does not make any changes here, but the community may
consider allowing delegation of either of these responsibilities if
revisions of <xref target="RFC7776"/> or <xref target="RFC9245"/> are undertaken.</t>
      </section>
      <section anchor="serving-on-the-ietf-llc-board">
        <name>Serving on the IETF LLC Board</name>
        <t><xref target="RFC8711"/> suggests that the IETF Chair, or a delegate selected by
the IESG, will serve on the Board of Directors of the IETF
Administration LLC. Because delegation of that role is already
explicitly allowed, no changes are made here.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The usual security considerations <xref target="RFC3552"/> do not apply to this
document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>These individuals suggested improvements to this document:</t>
      <ul spacing="normal">
        <li>
          <t>Alvaro Retana</t>
        </li>
        <li>
          <t>Brian Carpenter</t>
        </li>
        <li>
          <t>Jari Arkko</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2026">
          <front>
            <title>The Internet Standards Process -- Revision 3</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <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>
          <seriesInfo name="BCP" value="9"/>
          <seriesInfo name="RFC" value="2026"/>
          <seriesInfo name="DOI" value="10.17487/RFC2026"/>
        </reference>
        <reference anchor="RFC9281">
          <front>
            <title>Entities Involved in the IETF Standards Process</title>
            <author fullname="R. Salz" initials="R." surname="Salz"/>
            <date month="June" year="2022"/>
            <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>
          <seriesInfo name="BCP" value="11"/>
          <seriesInfo name="RFC" value="9281"/>
          <seriesInfo name="DOI" value="10.17487/RFC9281"/>
        </reference>
        <reference anchor="RFC2850">
          <front>
            <title>Charter of the Internet Architecture Board (IAB)</title>
            <author>
              <organization abbrev="IAB">Internet Architecture Board</organization>
            </author>
            <author fullname="B. Carpenter" initials="B." role="editor" surname="Carpenter"/>
            <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>
          <seriesInfo name="BCP" value="39"/>
          <seriesInfo name="RFC" value="2850"/>
          <seriesInfo name="DOI" value="10.17487/RFC2850"/>
        </reference>
        <reference anchor="RFC8713">
          <front>
            <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title>
            <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/>
            <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
            <author fullname="J. Livingood" initials="J." role="editor" surname="Livingood"/>
            <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 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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.carpenter-ietf-chair-tasks">
          <front>
            <title>Tasks of the IETF Chair, IESG Chair, and General Area Director</title>
            <author fullname="Brian E. Carpenter" initials="B. E." surname="Carpenter">
              <organization>IBM</organization>
            </author>
            <date day="25" month="April" year="2006"/>
            <abstract>
              <t>   This document describes tasks performed by the IETF Chair, the IESG
   Chair, and the Area Director of the General Area of the IETF.  Its
   purpose is to inform the community of what these tasks are, and to
   allow the community to consider whether combining all these roles in
   one person is optimal.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-carpenter-ietf-chair-tasks-00"/>
        </reference>
        <reference anchor="RFC1602">
          <front>
            <title>The Internet Standards Process -- Revision 2</title>
            <author>
              <organization abbrev="IAB">Internet Architecture Board</organization>
            </author>
            <author>
              <organization abbrev="IESG">Internet Engineering Steering Group</organization>
            </author>
            <date month="March" year="1994"/>
            <abstract>
              <t>This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1602"/>
          <seriesInfo name="DOI" value="10.17487/RFC1602"/>
        </reference>
        <reference anchor="RFC2028">
          <front>
            <title>The Organizations Involved in the IETF Standards Process</title>
            <author fullname="R. Hovey" initials="R." surname="Hovey"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <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>
          <seriesInfo name="RFC" value="2028"/>
          <seriesInfo name="DOI" value="10.17487/RFC2028"/>
        </reference>
        <reference anchor="RFC4949">
          <front>
            <title>Internet Security Glossary, Version 2</title>
            <author fullname="R. Shirey" initials="R." surname="Shirey"/>
            <date month="August" year="2007"/>
            <abstract>
              <t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="FYI" value="36"/>
          <seriesInfo name="RFC" value="4949"/>
          <seriesInfo name="DOI" value="10.17487/RFC4949"/>
        </reference>
        <reference anchor="RFC3710">
          <front>
            <title>An IESG charter</title>
            <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
            <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>
          <seriesInfo name="RFC" value="3710"/>
          <seriesInfo name="DOI" value="10.17487/RFC3710"/>
        </reference>
        <reference anchor="RFC8711">
          <front>
            <title>Structure of the IETF Administrative Support Activity, Version 2.0</title>
            <author fullname="B. Haberman" initials="B." surname="Haberman"/>
            <author fullname="J. Hall" initials="J." surname="Hall"/>
            <author fullname="J. Livingood" initials="J." surname="Livingood"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.</t>
              <t>This document obsoletes RFC 4071, RFC 4333, and RFC 7691.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8711"/>
          <seriesInfo name="DOI" value="10.17487/RFC8711"/>
        </reference>
        <reference anchor="RFC4691">
          <front>
            <title>Guidelines for Acting as an IETF Liaison to Another Organization</title>
            <author fullname="L. Andersson" initials="L." role="editor" surname="Andersson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t>Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4691"/>
          <seriesInfo name="DOI" value="10.17487/RFC4691"/>
        </reference>
        <reference anchor="RFC4052">
          <front>
            <title>IAB Processes for Management of IETF Liaison Relationships</title>
            <author fullname="L. Daigle" initials="L." role="editor" surname="Daigle"/>
            <author>
              <organization abbrev="IAB">Internet Architecture Board</organization>
            </author>
            <date month="April" year="2005"/>
            <abstract>
              <t>This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. 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="102"/>
          <seriesInfo name="RFC" value="4052"/>
          <seriesInfo name="DOI" value="10.17487/RFC4052"/>
        </reference>
        <reference anchor="RFC7154">
          <front>
            <title>IETF Guidelines for Conduct</title>
            <author fullname="S. Moonesamy" initials="S." role="editor" surname="Moonesamy"/>
            <date month="March" year="2014"/>
            <abstract>
              <t>This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.</t>
              <t>This document is an updated version of the guidelines for conduct originally published in RFC 3184.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="54"/>
          <seriesInfo name="RFC" value="7154"/>
          <seriesInfo name="DOI" value="10.17487/RFC7154"/>
        </reference>
        <reference anchor="RFC7776">
          <front>
            <title>IETF Anti-Harassment Procedures</title>
            <author fullname="P. Resnick" initials="P." surname="Resnick"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <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>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="7776"/>
          <seriesInfo name="DOI" value="10.17487/RFC7776"/>
        </reference>
        <reference anchor="RFC9245">
          <front>
            <title>IETF Discussion List Charter</title>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="S. Harris" initials="S." surname="Harris"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.</t>
              <t>This document obsoletes RFC 3005 and updates RFC 3683.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="45"/>
          <seriesInfo name="RFC" value="9245"/>
          <seriesInfo name="DOI" value="10.17487/RFC9245"/>
        </reference>
        <reference anchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="B. Korver" initials="B." surname="Korver"/>
            <date month="July" year="2003"/>
            <abstract>
              <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. 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="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+VaXXPbOpJ9x6/AKg+bVElK7Dg3iR9mxnE+1ru5yVTsqd1X
iIQklElCS5B2fFP573O6G+CHRDueu487VZNrkQTQ6D59+gNYLBaqcU1hT/Xs
amv1xYerj/p8a1ytfzd3+r0t7MY0dqYy/Lvx9d2pXmU71e5y/A6n+vjNqxdz
/fL1Ef49eXvydq7fvD56Oddvj98cqdxnlSkxdV6bdbOwm42tm8Wu9pmvFhkt
ssjjAosXxyq0q9KF4HzV3O0wimRR+DTYKrRYq6lbq25O9Ut16+vrTe3bHaT+
O6azIej3PmtLWzX6HCN84SAgZpqpG1u19lRpXRpX4HtZ/m/ONuulrzczvNm4
Ztuu8I4eLm43UcTn/FPkLM1dJysNKWj7DYZsm2YXTp8/Hw9dypRL5++b5Pmv
dbLcNmUxU8q0zdbXp0otsLDWotLPpg76A4/mp7UnG9rcNb7mB9jbqf7d/+GK
wvCD0NTWQuTLxlYrW29c1Tirj471O36duQbG/S/TVs64ylby0OeEjBfHr1+8
mMUnbdUQDD5e8G8rai0gzt9kM6RVftXW7lQn/fTvnmMji4U2Kwhkskapq60L
Ok/mM+u1q8ugm61p8M8IklCgTtrRwZdW+zV942pV27CD4d3KFQ77wnivPV7V
+qy2Rr93tc2gmjDXpsp1xK8O9sbWplD2uwuNqzb628dzHmorsyosC7EUeUuX
54VV6om+gAJ83maEL/3jiaOfP2kbQORm61sRG5vCendRQt7FnP8iSw2fxr1t
TVCmuDV3Qa+srfQahrO5Xt1powNEw6CdrQOwpb/4qpthDXsI1LGNpMSQ3kLd
pnJ/8Hu9gwpcsAXpcA0Td9LM9QpClz5A+7VVt7VrgBF9CwxDWxoLYOEGeiMN
dXbhfcByh4IqEVTfbj19gI8r3Zhwja94zgpCQldB7xttqYmD7PcdrJUr6NnW
lW0W78lV9I8ff71YvF9mpt5ZerMYeBbNHn7+1AaCl7sGCzVe7e1yQuelr+1A
LaSFWxN05bFDcw0fWPv61tQ5IPDR3upevRCxcPAYDArA5GOxqvBNsBPb/goY
6saVliAClQEMOgNuaSek1aYVE94C0FYBtBUer9uiWNAgOGVZuobd5xAvLEnl
deEruCDABaKFj2WOPgfUMQ2ZUBv8X1QURGGBXSVvO8tAWTSXKYJXK57e+Zyx
tnUbQAUecQMWESlZizSnTKAzIEkGQamlpYmtSk465xlg0x2mrGkOtij0filb
WfkGQaqy2XXQhbu2SU03UOvqxhGYQmYKAigJvTZtQZsr4N1VZhXCSiubGFIN
cJnZoS0hrr8NnSWVWBJCTpPOgSGZdMg3I7R4b2pMQEt90ejCQvKgXQMmYrox
2XYIHl4SGC8JwI5xA7X6tsjj7h8tkvAdpgh+DsM4rAMJ8RhTwD9Lfg2DVdD1
VyxWgvELATRUFXbwDWAFirmLnMie3oz0iL+NCnZnakFpdDTB0KHXrWssyyt0
7y4/ia7nYgIx4wR9k9Tkmdqzw2As+78AXY29/PKTbB3uakLwmWNvOvS9i4YR
HbcXVFTsYCO97P8e2Ov0xdk7XdoSYTRs3U78ZDCsVmFratrFQBXp70+AMWLO
eGPL/TCYeytEVNv/bV3NmGK/x/fwdosVx6zDilAdKkx114NCXHBOeAPzEtXt
CFsNQ71kNHngCDChB3fACqbzPtilvhwgYC70LQyB9cAnMmnYMjTJvT0SOKiR
mLO3AxagbSBj4mcgW5slBZtphRA44bbCInEYEh8mSbHX2DI9oMfPVcn8DMU9
0mHYEkx1LcRdCbkiKSJOApkEoBy0Aa5YUaQXjxKk7y1MHJ7WzEU69r5DVIuP
rnnT9AntUbhKjZaMFLpp4WiIgJjVVSmF0ZQ5zHVoMd6QLJyMkEyKTXBrVwgj
DKNduwLhSeYGA9MIDzzEJIKIBy8CpQLgqTXRKPGPzl1ASBr7xeWnJWVEl9H3
OT0Y+TptjNeXn99IURHqIWLAYNG7P6A/2TxnYK7cFdNhNU0YuVk0X1nRMJTT
ZyMdZIQdRMklyCOk8kUWEFpl3qHQ2dEY7eyJfmcyLjWqXKkfP/4N0h2/OP4N
qQbtoK0RrzjYIg9wBfktNnR/wjFXvsKn5OBYgNQF54ENf/y4jMo4OqFRg2Vg
SwiUqFJJTPCF39yhIPjLns8sOH8qoVGK9ORclaxOny01vx1HIyTqhhKDzrOH
ugbyaX+SQqVsTH+oUDpYS/SG0agm+E/9ieox/ZRs82yp/gLZpkZMfw/BzzQX
dN2aOaVLupdoLDbbciztUj9dLpfPKGMoHcoRoqtDS3RIhPnYFqva2XVvE/Yp
1dvjt+Wr5fH9JtkCM7tYgK7hNW1t2XHg/BWqhZxtdMF2cEifb1zewsMiXcKh
zAY1WZdoG1mTU8+EYBbZVawKyBwXmwt0Y4IX50PdBMYiN22DsBGnPZ1pMUev
gCWJdaiTNtY9CAdwgrAWIcgoBapCsI7YpErKHrnEQczawxNmZeZOGWcyj4Im
h5IN3EGU/1escfTbi+OfP8WmFuZ1lrj7xgUhJKYoLlKQr3d6EjWNhPSrgCUb
jlyEI5QZlJAm9sOHEs5pL67KijbHPux3TpV5NrteQ7o52Z6ol0181VkqsLK8
APhX8IUyB/nLuFSk4om1FWxNuaIJ+/lO4gSdiPgBvZFglDkWYtCVCVS5IVFB
VSW6eUPKNfrd+d9j9id7B8uJP7ES/i+bFdGHQv9qm3txpt/ey+XL5JPUaNqT
vLPw3uZqCmxV6iyQSUkyWbzp48EeaCkI79OmTtnNMHX5pW7O3k/z1rjvxozM
CRh+hN5FOZcNcaJJAUYqOkn2p64cKwih4ADpma9IJ5Jvd4StMEnLVdinAvmc
qUGl8csgNMTa474ASzGbDA6TVD/TmzgnYp8tO6UNgpy+uPx63udlhZXd2mxb
UR4a4xtnyUwcKNR0Kj5drFpNjjDpqMM0SliSmJcdUcT2Ic+Q+VpaHF74Ixc6
3+HHTZ9TsHRXNbJDS+WDYKK4wwz7IgufhxhhWVE9Q1Hz63o2j34mwXTtyDCy
oOFqvCvA4kxhYg9Lfd4jLTrWg/FywCEDB+wBlxhFPyWMEG8+41zo/URlNErt
9I8nEH0XmzKcm1FjzMfs6jAcdDn5MFIPJqWIUcUq+r1+aii4Iv1dgcYc9AAA
pryPVxAjDen+GQcMVCOprOxSPxR8o6YfpbuUR3LQPlrqb7aE1WO9Qmtl9qBF
/gtHVfc56kxq4AcIbckynHONJYRYmDYMJcik6ok9tq4iGpHs4zOwGaWhsld4
et5tmULzIKx0mdCbVy8QVKDEPYG0bJdqztQtX6qnnO8nKYeeLkWkpMCMnI2t
FibH/p/tGyEpYAKvrPdZ6isM6Eg9Yt8jOhon4ydqxKFc6kz4wNk7/XvXC3hE
cROpNIagVWoYp8aCGjQWDiuIvorRwypGDauYiQ7GqF8xVdncZ+KYyu1Xt8nr
RGqZWvWL9bEwIfCszrbQcNaAU/U7D96CBc7ePUPySk1COuaBN4q8rm64A46p
6dxG5J4fxNNxjjAF9SsTrjHDR1/DeZ+S9M9EgTTo1haAFopi5oC4CsfQs90O
1OK+6/OkDDrUgjK6IGi6rIgzBzm4GFdq0ZESqgzSL9nfzBMPgP5zx6Q+45ZO
DeLhpsmMVZHHepz4bN2y0r74EjwfZqzbL34v+ef0idqk21SCks05FBL77zUc
oBT7PbO7g2wH3tV3f3lgDx2ejebB6C4TmmpqEZUGmIKQbYtguR+8l8CdjPmO
2uhhkEEN0i/xdpOE6EE276La+V5mmbDwzQaUCvA7AkIHg2+AgeT+UAJGUS/c
x+mX9wW6zsk50D06qFG7c6Jh2HjV9TffS03zJ0LUWZ4TmuI66ax2bOpZ6p7Z
KjmOSlT65xxK9KjEnWZ77Ysxeyx7Mf879Rek+9QpF9/+D/43Fx1uWpdTw14w
zEEDFSy30iRUMJxRlWS1W1k2PpA1k9qsC14raByCR9d7wKEPouy9kf4hGKop
GP5LIFR7IJyNI+v5dGTthVKP9I0HhVK/8Iw9Ux+48D3hcbq7G53oT4bKUc/2
Th1Eya7TIKwIyIxXnxBNrHgYWPX9gXW6zf9QcO2KcrowQaT3UNk5FHF8hjTB
k4M8ft1WWVct3G8BOvNJXSVDb+i/VETZByttWUP0NBEFpyj8Xy9nIVcsaCfJ
+NOHL7IZjByWHTF5fHzFMdbIoFOoRtD4s/z8ze4Kkw1z1sfZZiYtOxqm0oFr
N5TD8j029XLsTKiUuwvSXuPZfD3ce3w1KLD2RRg5+7EaAff/VXUSBuXJsLDl
GuWJ/srK+4dgYo/SMmAGf4YhZPj0ifnMVXv4YbPQPZAVnfFxOzPxCYr99Vpf
tkj6pOU5dNLXy6N9YkE2NeGJFEd3tSup3BlzKHtgSNPHbgVds4IrDukVS1Ib
rXam6U8DtclvXGbZp+W+1uhod576+MiB+kOcrpWygyTIdyu6aHNfliCNPATt
I2kBu7AvP22t5DZNPK5icT98t1lLnNYftLJOumPWaJgHlcmnl4fNAISjG7ZO
hMDU2VY6XQhtCaU7im7ibFMnhrQHvoqj4qli7KJXPok5121o+SweCGGPG0Qk
RjB8OL9Tcrrb2FzA89kZR6XCZWLpMKb4bsMnv709GqAnjevYXSiOz03C4LDL
VahkDKt5gJXU3J53xo8/J/pTc/JMfk6YI/zxaVCaItzT2nzx6ngg7kdquaHM
2hNab5gr6RCWLGJRb65HmGZCBVMVdj48cYrXeOgUmO+ZDKaJjwenNxEZsY8X
Zz8QZanTqcuhlPGsO8glngNBWIsV3Sqj5QlCvDoPTSfVfkXJkhxhaXJKTqWj
V9KtOumPZX53N3FUG41Z2hDMxsoxONXcK1cNoy8dB976ESYEden2zDCeqOHF
DdLPpIGmzcJ6HVzDSW1RwfQVHYxDA3xfdHzL5BOKCFtAEXzCQfdB6bLeqLA/
SxB6ffTqJEJIz85Gp3R02l7bna8bOYU/WGwzXieTdVItcpC58zn8cqbUf8jB
0TyyWhShOzyL19boAgc0GNOFgxlVl0nFBkCM/XR4ONcH1yPEaU3WSFmv6M7b
zsklqDrGGGjHu6oRo8ZdfC1XbR4Wc/2755aEF/L+bEKzOKfGzWfqasSXBJIr
a8og2NnLZgcXALmDnyBIEaNxTctXHGJq4HnZBnMlJb1+zUevMXCUnTT8zdD6
8fyTQiR3XGT82+OTV4jYRP53qTSg0NzPFLoktNucohsSJCZNFBtHDG36Hbpj
2+ElSzrdhX9Zhd2gujahC6Z0vlyLjPdf9qG8mi2fUg+yjlzPFFWlqygwtUqN
ov7O1Lg+sY6F7e/07d9Wc2uVTlBDH2WjqqGMoeqY+fnEh4+nY1ZC6QKVP1Wv
/8+fz6W/p9QwaiMEbrChZrLaYfo3gxs6bBtmqw7nlG4Ab1LRxQWljwjJ+4OO
YQA6Gx8CQbKlfncYOHlISogHUXT/YqDN5xSLk2kMX4fMbedBujs2Ox+28KI3
cOSmxEA+GXX5QlT1y1cc0HIv1552fAnGc77T3e3llS7OvpxNrDK63MgXWeXL
yCI89Cy7rvxtYfNNzASuGBw98YVkKgokJZ99DShhsATdSNdnxY2pPUqdBj6N
3++QGlb6PF3SxZP/ROKDYHB97fke9QqVsfonTYaLV3cwAAA=

-->

</rfc>
