<?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.26 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-rsalz-8717-update-01" category="bcp" consensus="true" updates="3710, 3929, 4633, 6702, 9281" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="8717update">Update to RFC 8717: IETF Administrative Terminology</title>
    <seriesInfo name="Internet-Draft" value="draft-rsalz-8717-update-01"/>
    <author initials="R." surname="Salz" fullname="Rich Salz">
      <organization>Akamai Technologies</organization>
      <address>
        <email>rsalz@akamai.com</email>
      </address>
    </author>
    <date year="2025" month="April" day="01"/>
    <area>General</area>
    <workgroup>TBD</workgroup>
    <keyword>Internet-Draft, IASA, terminology</keyword>
    <abstract>
      <?line 33?>

<t>RFC 8717 updated several RFCs pertaining to the organization of the IETF
to use the term "Managing Director, IETF Secretariat" (MDS).
As that term does not accurately reflect the organization or roles of
the IETF staff, the MDS term is no longer relevant.
This document removes mention of particular staff roles, and instead
updates the source documents so that the job to be done, and who
the responsible entity is, are described.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/richsalz/draft-8717-update"/>.</t>
    </note>
  </front>
  <middle>
    <?line 43?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC8717"/> updated several RFCs pertaining to the organization of the IETF
to use the term "Managing Director, IETF Secretariat" (MDS).
As that term does not accurately reflect the organization or roles of
the IETF staff, the MDS term is no longer relevant.
This document removes mention of particular staff roles, and instead
updates the source documents so that the job to done, and who
the responsible entity is, are described.</t>
      <t>This document updates <xref target="RFC3710"/> and <xref target="RFC6702"/>. It also changes the
status of <xref target="RFC3929"/> and <xref target="RFC4633"/> to Historic.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="updates-being-made">
      <name>Updates Being Made</name>
      <t><xref section="2" sectionFormat="comma" target="RFC8717"/> explained that <xref target="RFC2606"/> did not need to be updated
because <xref target="RFC8179"/> removed the need for it.
While the same section of RFC 8717 provided an update to <xref target="RFC2028"/>,
that has similarly been overtaken by events in that it was obsoleted by
<xref target="RFC9281"/>, and Section 3 of RFC 9281 does not need revising.</t>
      <t>Further, the IETF is in the "consideration" stage of forming a working
group to update <xref target="RFC2418"/>; for discussion,
see <eref target="https://mailman3.ietf.org/mailman3/lists/procon.ietf.org/">the mailing list</eref>.
An online document proposing changes to RFC 2418 to comply with
<eref target="https://github.com/richsalz/draft-rsalz-2418bis/pull/14">this document</eref>
are available.</t>
      <t>The following sub-sections make the specific changes for each RFC and
therefore this document completely replaces Section 2 of RFC 8717.</t>
      <section anchor="changes-to-rfc-3710">
        <name>Changes to RFC 3710</name>
        <t><xref section="2" sectionFormat="comma" target="RFC3710"/> describes the composition of the IESG and mentions
the IETF Executive Director twice.</t>
        <t>The first mention:</t>
        <artwork><![CDATA[
The Internet Architecture Board (IAB) Chair and the IETF Executive
Director, as ex-officio members of the IESG.
]]></artwork>
        <t>Is replaced with the following text:</t>
        <artwork><![CDATA[
The Internet Architecture Board (IAB) Chair and the IETF Executive
Director or their designee, as ex-officio members of the IESG.
]]></artwork>
        <t>The second mention:</t>
        <artwork><![CDATA[
The IETF Executive Director is the person charged with running the
IETF Secretariat.
]]></artwork>
        <t>is deleted.</t>
      </section>
      <section anchor="changes-to-rfc-3929">
        <name>Changes to RFC 3929</name>
        <t><xref target="RFC3929"/> is an Experimental RFC published in 2004. This document changes its status to
Historic.</t>
      </section>
      <section anchor="changes-to-rfc-4633">
        <name>Changes to RFC 4633</name>
        <t><xref target="RFC4633"/> is an Experimental RFC published in 2006. This document changes its status to
Historic.</t>
      </section>
      <section anchor="changes-to-rfc-6702">
        <name>Changes to RFC 6702</name>
        <t><xref section="5" sectionFormat="comma" target="RFC6702"/> says that WG Chairs and Area Directors are
encouraged to ask the IETF Executive Directory to contact those who
submitted an early intellectual property disclosure and request an update.
This document specifies an email address to be used for that purpose:</t>
        <artwork><![CDATA[
To help prevent early IPR disclosures from becoming stale
or incomplete, at important junctures in the standardization process
(e.g., at working group adoption, before Working Group Last Call, and
before IETF Last Call) WG chairs and ADs are encouraged to request
that the Executive Director of the IETF contact those who submitted
early IPR disclosures about updating their disclosures by
sending email to XXX@ietf.org.
]]></artwork>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document has no security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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="RFC3929">
          <front>
            <title>Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF</title>
            <author fullname="T. Hardie" initials="T." surname="Hardie"/>
            <date month="October" year="2004"/>
            <abstract>
              <t>This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3929"/>
          <seriesInfo name="DOI" value="10.17487/RFC3929"/>
        </reference>
        <reference anchor="RFC4633">
          <front>
            <title>Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists</title>
            <author fullname="S. Hartman" initials="S." surname="Hartman"/>
            <date month="August" year="2006"/>
            <abstract>
              <t>Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4633"/>
          <seriesInfo name="DOI" value="10.17487/RFC4633"/>
        </reference>
        <reference anchor="RFC6702">
          <front>
            <title>Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules</title>
            <author fullname="T. Polk" initials="T." surname="Polk"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="August" year="2012"/>
            <abstract>
              <t>The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6702"/>
          <seriesInfo name="DOI" value="10.17487/RFC6702"/>
        </reference>
        <reference anchor="RFC8717">
          <front>
            <title>IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology</title>
            <author fullname="J. Klensin" initials="J." role="editor" surname="Klensin"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>In 2018, the IETF began the transition to a new administrative structure and updated its IETF Administrative Support Activity (IASA) to a new "IASA 2.0" structure. In addition to more substantive changes that are described in other documents, the transition to the 2018 IETF Administrative Support structure changes several position titles and organizational relationships that are referenced elsewhere. Rather than reissue those referencing documents individually, this specification provides updates to them and deprecates some now-obsolete documents to ensure that there is no confusion due to these changes.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8717"/>
          <seriesInfo name="DOI" value="10.17487/RFC8717"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC2606">
          <front>
            <title>Reserved Top Level DNS Names</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="A. Panitz" initials="A." surname="Panitz"/>
            <date month="June" year="1999"/>
            <abstract>
              <t>To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. 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="32"/>
          <seriesInfo name="RFC" value="2606"/>
          <seriesInfo name="DOI" value="10.17487/RFC2606"/>
        </reference>
        <reference anchor="RFC8179">
          <front>
            <title>Intellectual Property Rights in IETF Technology</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <author fullname="J. Contreras" initials="J." surname="Contreras"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="79"/>
          <seriesInfo name="RFC" value="8179"/>
          <seriesInfo name="DOI" value="10.17487/RFC8179"/>
        </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="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="RFC2418">
          <front>
            <title>IETF Working Group Guidelines and Procedures</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="September" year="1998"/>
            <abstract>
              <t>This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="2418"/>
          <seriesInfo name="DOI" value="10.17487/RFC2418"/>
        </reference>
      </references>
    </references>
    <?line 153?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Just me.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1X23IbuRF9x1cg3Bd7i6RESZFsZrNeSpRtpiTL0aXsLZdr
CzPT5GA1HMwCGMpclf4l35Ivy2lghhdLW+VKJXkKX4jBpbvRl9MHvV5PeO0L
GsrOTZUpT9Ibefn6RL44GhwN5eT0+rUcZXNdauet8npB8posvk1hZsuOUEli
aYHTvL8OEjoi/ruh3D8a7Hbl/su9l115cLi/35WHR7t7Xfly78VAZCYt1Rya
M6umvmedKn7vsZhePN/bHYgU/zNjl0OZpJUQurJD6W3t/N7u7svdPaEsqaF8
QyVZVYg7Y29n1tTVUF4fj8UtLTGT4RalJ1uS741ZU1dORlejrvTrewjhvCqz
X1RhShi0JCfcXFn/y2+1CRcpjaj0UH7yJu1KZ6y3NHUYLec8+CyEqn1u7FDI
npD46RKHLvvyCncKE/GmlzrN13PGzlSpf4dXTTmUo1s1VxreTfNglIYRvIsw
WwxlcM9PKmzqp2YuRGnsPEQEWjlk7Ox2CI83Q3Z7M2TfD+HEcro+KUSv15Mq
4eimXog29DLGIJOOFuxbPu9kRdYr5EI54zTxOW3dQZppmOOkEVivHYVvdrTs
nKtSzfjkWFtKvbHdmF1XlFryymrlO/LZ+fjqeV+MHA4qH09mhhwC4KVK0xo5
SMVSwusFhDxhgpXWFDhgpqK1RSK402k3bIb8KFWzTIl4zwhHqKCFKn1fXOdY
QGbWcyo95udmAWH80VywQlrotC6UjWKjuq5E+nDUPamszf+g0JnaprQS6TDR
3A2Lv5qEHZnweklRyF1uguWWXGVKp5OCJKv3S9iMLRabyaVWJ5T1Y/jmOssK
EuI7znRrsjpla4W4v/8TwsbhfHj4f0D/hwH9t6O5bW2r9v6+KW+EkYWGb67m
h4e+nMCPBWxIc4WrBxsZzXzNLmuOAg42jzIm4BuGvgWsG6vTPifPiSkX0S8u
7B3TFKkRvtkykgBUyYjqEPybq+tON/7LdxdhfHn695vJ5emYx1dvR2dnq4Fo
dly9vbg5G69H65MnF+fnp+/G8TBm5daU6JyPfu5Ej3Yu3l9PLt6NzjoID267
6TB2Z6wnzZBfIQ+R8cqJlY/5zPHJ+3/+Y3AgY3nsDQbsnKZWBkcH+LjLqYza
TInkjJ9w7FKoqiJkCqSoopCpqrSH97EXeZCbu1LmZAne/P4Te+bzUP6AxjU4
+LGZ4AtvTbY+25oMPns88+hwdOITU0+oWXlza/4rT2/bO/p567v1+8bkD68K
XZLsDV68+lFwCt00GXtMDAznKiNGoQaEugwNoeyQuJK+VAWgByEJ1XN//4qD
cbh7iLVMZwEgSuLlENAGvkRCqWIcivsRLw5eLOsslGA4gw4nNar/Q66LiFkO
DRjYl7Zlv2p0lTULnXGalI0S1tiYs7v34uGhK4KFOcdYzzWQAjmREEHOgvHz
FqNkKWkR4CAkJbZrL+9wwiQOeMJpmCxFlMrsB1JDfrUe2W9t4sU1QobLgGBp
B38irV7XFpex3RUsM+wFjSQ7KQNMRjYAZ4fRbEYslts9h0Nx8d5iJAJJ4ms2
F25uezDAbf8SnJdpl9bOQVBXOCIwH2hgJsKCCqDG52e595Ub7uzw7FyV+31N
ftoHeK9mdnij24GHYdp6mftByZXFubOqXeyqDF9zjWSRibJZPAbpqbgYtc/F
p626X9syw2KdMD/aAarlzJl2Nukly0o0TKqLYmdw8JwJpFQL2KuAzP0Ic1NT
FOaOLXF10mtyBj0DgY6pVFGqpzpdGcoOIwVqx+Yiqoz4aGiG0WgLn8IVqGl4
SP8Uh1c1sZmVjMffSXmy7QluAU09RWa9WU8txMUuxZrgze0ufvUm5FzT/Ny6
n55+obQO5L7t5dLf6XTlEG2db4+BMzIt5fmWV8uRTXPtcbDGlY+Nspl8Nhkd
P+cLaBuUPtYVxKy5A2qFvvTMFI7VBsrmCVm3aTuMmbjWb1nIg7C2DpenL/6/
Yx7TEGzBZrhZz1CW32Ywm4EEMmuvb9r3B67XMYTgZg7RQ5LZWXtfW5eRrOXR
vq8JF1RyvlFAnD9IIpCBNokiL9Dc7mEIFGq2MpJDWdUJ6jePPRPvrYO+3KYn
bfprJkGRcXgjNinFY+1MPRrtDQv5Ru2H/wntzJka7fEh2hbQn2GIU8uGpX54
EzMj0qAR3pir4DjmGILKFCxQzWJ3Uu72ifxZHVlG8MLNAr81aF7MCoEtc+19
bDwUegqTloJpcA0nMB6iuywDFBfGce6yOZZ+qwnluGpXX3PcBp4o+DW8HqXK
MhBQ17ZS13TIcNmqtkAKavPSgMEUFbSHdtYYNnl/uWEGAM+aOSQBZAJKImbU
vGhxhxbkUCHogoAhtEhI+rUuQwGu+lV4cqMWW6bPbQJGBkHPqD/rBwFNy5Kx
ZanMVLy5C+0BXz80y2/C8pmCY07AzEJzDZKafSE2q+XnHOJ0I8TjEFe5HdfG
00HMiuE/Ua8br6THcZarOMfX/JP+VImpG7rfVLe2WxvAHfi0ozLjDTGqMPHj
x48/tX01cHgkdG35dXGySQbc1y8L5jJ4Lbl29xZ1cEHSZPRu9G1Swk6Vtkf5
RZqo9JaFjNLb0twVlM3CW0ncD8uacZKyv3amIM7UeRDib3XoLn3xLzlt4JmO
EgAA

-->

</rfc>
