<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- Getting references from the online citation library.
     There has to be one entity for each item to be referenced. -->

<!ENTITY rfc2026 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY rfc2028 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2028.xml">
<!ENTITY rfc2418 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
<!ENTITY rfc3005 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3005.xml">
<!ENTITY rfc3710 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3710.xml">
<!ENTITY rfc3716 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3716.xml">
<!ENTITY rfc3929 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3929.xml">
<!ENTITY rfc3979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3979.xml">
<!ENTITY rfc4633 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4633.xml">
<!-- <!ENTITY rfc4844 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4844.xml"> -->
<!ENTITY rfc4879 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4879.xml">
<!-- <!ENTITY rfc5377 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5377.xml"> -->
<!ENTITY rfc6702 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6702.xml">
<!-- <!ENTITY rfc7500 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7500.xml"> -->
<!ENTITY rfc8179 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8179.xml">

<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">

]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions- PIs (for a complete list and description,
     see file http://xml.resource.org/authoring/README.html.
     You may find that some sphisticated editors are not able to edit PIs when palced here.
     An alternative position is just inside the rfc elelment as noted below. -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<!-- Controls display of <cref> elements -->
<?rfc comments="yes" ?>
<!-- When no, put comments at end in comments section,
     otherwise, put inline -->
<?rfc inline="yes" ?>
<!-- When yes, insert editing marks: editing marks consist of a
     string such as <29> printed in the blank line at the
     beginning of each paragraph of text. -->
<?rfc editing="no" ?>
<!-- Create Table of Contents (ToC) and set some options for it.
     Note the ToC may be omitted for very short documents,but idnits insists on a ToC
     if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC.
   Can be overridden by 'toc="include"/"exclude"' on the section
   element-->
<!-- Choose the options for the references.
     Some like symbolic tags in the references (and citations) and others prefer
     numbers. The RFC Editor always uses symbolic tags.
     The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
			 This doesn't have any effect unless symrefs is "yes"
          also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
     main section on a new page but does not omit the blank lines between list items.
     If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->

<!-- This is -07c, the posting version --> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="bcp" consensus="true" docName="draft-ietf-iasa2-consolidated-upd-07" indexInclude="true" ipr="trust200902"  category="bcp" number="8717" prepTime="2020-02-26T17:48:47" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" updates="2028, 2418, 3005, 3710, 3929, 4633, 6702" >
        <!-- JcK 20181203: removed 3979, 4879, 8179 from Obsoletes
                list
             JcK 20190117: removed 4844, 5377
             JcK 20190311, removed 3929, 4633 and moved to updates -->

  <!-- ***** FRONT MATTER ***** --> xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-consolidated-upd-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8717" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IASA2 abbrev="IASA 2.0 Consolidated Updates"> Updates">IETF Administrative Support Activity 2.0: Consolidated IASA 2.0 Updates of to IETF Administrative Terminology</title>
	 <!-- Before -05 was  "Consolidated IASA2-Related Document Updates"
	     Change per email from Brian Carpenter, 20180117 -->

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="8717" stream="IETF"/>
    <seriesInfo name="BCP" value="101" stream="IETF"/>
    <author fullname="John C Klensin" initials="J.C." initials="J." surname="Klensin" role="editor">
	   <organization/>
      <organization showOnFrontPage="true"/>
      <address>
        <postal>
          <street>1770 Massachusetts Ave, Ste 322</street>
          <city>Cambridge</city>
          <region>MA</region>
          <code>02140</code>
          <country>USA</country>
        </postal>
        <phone>+1 617 245 1457</phone>
        <email>john-ietf@jck.com</email>
      </address>
    </author>
    <date month="March" day="11" year="2019" />

    <!-- Meta-data Declarations --> month="02" year="2020"/>
    <area>General</area>

    <!-- WG name at the upper left corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case it defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->
    <workgroup>IASA2</workgroup>

	<!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->
	<!-- <keyword>Text</keyword> (as many of those elements as needed -->

    <abstract>
      <t>In
    <keyword>IASA</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">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>

	<!-- Note here if needed
	   <note title=""><t> .... </t></note> -->

  </front>

  <middle>
    <boilerplate>
      <section title="Introduction" anchor="Intro">
      <t>In 2018, 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 pn="section-boilerplate.1-1">
            This memo documents an Internet Best Current Practice.
        </t>
        <t pn="section-boilerplate.1-2">
            This document is a product of the IETF began Internet Engineering Task Force
            (IETF).  It represents the consensus of the transition to a new
		 administrative structure, and updated its IETF
		 Administrative Support Activity (IASA) to a new "IASA 2.0"
		 structure <xref target="RFC-Struct"/>.   Key IASA 2.0 changes have community.  It has
            received public review and has been
		<!-- The approved for publication by
            the Internet Engineering Steering Group (IESG).  Further information
            on BCPs is available in Section 2 of RFC 7841.
        </t>
        <t 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/rfc8717" 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 pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF initiated a major revision Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t 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 its administrative
		 support arrangements
            publication of this document. Please review these documents
            carefully, as they describe your rights and procedures restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in 2018
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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 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>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" 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-where-appropriate-replaceme">Where Appropriate, Replacement of the IETF Executive Director Position with the Managing Director, IETF Secretariat</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" 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-removal-of-the-ietf-executi">Removal of the IETF Executive Director as an Option</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" 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-deprecated-documents">Deprecated Documents</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-documents-whose-context-is-">Documents Whose Context Is Changed by This Specification</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-general-description-of-the-">General Description of the IETF Administrative Model</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" 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-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" 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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" 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-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" 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-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">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 <xref target="RFC-Struct"/>.  Those target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>.   Key
		 IASA 2.0 changes have been -->
		 specified in a series of documents, including
		    <!-- notably a description of -->
		 changes to the IETF Trust <xref target="RFC-trust-update"/>, target="RFC8714" format="default" sectionFormat="of" derivedContent="RFC8714"/>,
		 the rationale for it <xref target="RFC-trust-rationale"/>, target="RFC8715" format="default" sectionFormat="of" derivedContent="RFC8715"/>,
		 a new defining document for the IETF Administration LLC <xref target="LLC-Agreement"/> target="LLC-Agreement" format="default" sectionFormat="of" derivedContent="LLC-Agreement"/> (informally called the "IETF
		 LLC" or just "the LLC" in places in this document and elsewhere) elsewhere),
		 and adjustments to the procedures for nominations and
		 selections for relevant positions
		 <xref target="RFC-7437bis"/>.</t>
	<t>In target="RFC8713" format="default" sectionFormat="of" derivedContent="RFC8713"/>.</t>
      <t pn="section-1-2">In addition to more substantive changes that are described in
	   those and other documents, the IASA 2.0 structure changes
	   several position titles and organizational relationships that
	   are referenced in other documents. Rather than reissue those
	   documents individually, this document provides a unified
	   update to them. </t>
	     <!-- Among the substantive changes in those documents are changes
		 in names of organizations, position titles, and associated
		 relationships.
	   Rather than reissue those documents individually,
		 address other topics but mention those names, titles, and
		 relationships, this specification provides updates to them
		 to ensure that there is no confusion due to changes in
		 terminology.  -->
	  <t>
      <t pn="section-1-3"> This document updates RFCs 2028, 2418, 3005, 3710, 3929,
		 4633, and <!-- 5377 removed --> 6702 (citations in context below)
		 to make those terminology and related changes.  In addition,
		 with the authorization of the IAB, it requests
		 that the Informational RFC 3716 be made
		 Historic (see <xref target="MakeHistoric"/>). target="MakeHistoric" format="default" sectionFormat="of" derivedContent="Section 4"/>).
		 The sections that follow identify the details of the
		 relevant documents and the required changes. </t>

    <!--  <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in
	  <xref target="RFC2119">RFC 2119</xref>.</t> -->
    </section>

  <!--
    <section title="Remove Text About the Connection Between anchor="ExecDir-Managing" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-where-appropriate-replaceme">Where Appropriate, Replacement of the IAOC and IETF Trust">
	   <t> Some documents that discuss Executive Director Position with the Managing Director, IETF Trust or its
		  relationship to the community describe it, or the Trustees,
		  in relation to the IAOC.  That connection must be eliminated to
		  reflect the new IASA 2.0 structure.

	   <t> This document applies that change to the following:
		  <list style="symbols">
   			 <t> <xref target="RFC5377">RFC 5377</xref>, Advice to
				the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents.
				 These changes require dropping "made up of the
				 members of the IAOC [RFC4371]" after "board of
				 trustees" in the first paragraph of Section 1 and
				 "which is made up of the members of the IAOC, as
				 described in [RFC4071] and [RFC4371]"
				 in the first paragraph of Section 3.
				 <vspace blankLines="0"/> <cref> RFC Editor please
					note that the bracketed strings above are quoted
					text, not references. </cref></t>
		   </list></t>
	</section>  -->

   <!-- <section title="Replacement of IAOC with IETF Administration LLC"
			anchor="LLCRepl">
		<t>All mentions of the IETF Administrative Oversight
		   Committee (IAOC) that are not removed by the prior
		   section, shall be updated and replaced by the IETF
		   Administration LLC (IETF-LLC).  This is necessary because
		   the IAOC is phased out under the IASA 2.0 structure.  </t>
	   <t> This document applies that change to the following:
		  <list style="symbols">
        	 <t><xref target="RFC4844">RFC 4844</xref>, the RFC
				Series and RFC Editor Sections 3.3, 3.4, and 4.</t>
 			 <t><xref target="RFC7500">RFC 7500</xref> Principles for
				Operation of Internet Assigned Numbers Authority
				(IANA) Registries, Section 3.4. This means that the
				IETF LLC, the body responsible for IETF
				administrative and financial matters, maintains an
				SLA with the current registry operator, the Internet
				Corporation for Assigned Names and Numbers (ICANN).
				It also means that both the Internet Architecture
				Board (IAB) and the IETF LLC are accountable to the
				larger Internet community for the IANA registries.</t>

		  </list></t>
	</section>  -->

	<section title="Where Appropriate, Replacement of the IETF Executive Director position with the Managing Director, IETF Secretariat"
			anchor="ExecDir-Managing">
	   <t>Under Secretariat</name>
      <t pn="section-2-1">Under the IASA 2.0 structure, most of the responsibilities
		  of the former position of IETF
		  Executive Director have been assigned to a new position (or at
		  least title) of Managing Director of the Director, IETF Secretariat.
		  An "Executive Director" title is now associated with
		  different, and largely new, responsibilities as an Officer officer
		  of the IETF Administration
		  LLC.  These changes are described covered in the description of the
		  new structural arrangements <xref target="RFC-Struct"/>.</t>
	   <t> target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>.</t>
      <t pn="section-2-2"> This document applies that change to the following:
		  <!-- RFC Editor: the inconsistency in the positioning of
		  section numbers in citations below is deliberate, to call
		  your attention to an issue about this type of reference that
		  I've been commenting/ inquiring/ complaining about since
		  1999.  Fix it however you like. -->
		  <list style="symbols">
			 <t>RFC following:</t>
      <ul spacing="normal" bare="false" empty="false" pn="section-2-3">
        <li pn="section-2-3.1">RFC 2028, The "The Organizations Involved in the IETF
                                Standards Process Process", <xref target="RFC2028"/>,
				 Section 3.3.</t>

			 <t>RFC target="RFC2028" sectionFormat="comma" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2028#section-3.3" derivedContent="RFC2028"/>.</li>
        <li pn="section-2-3.2">RFC 2418, IETF "IETF Working Group Guidelines and Procedures Procedures",
                                <xref target="RFC2418"/>, Section 1.</t>

			 <t>RFC target="RFC2418" sectionFormat="comma" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2418#section-1" derivedContent="RFC2418"/>.</li>
        <li pn="section-2-3.3">RFC 3710, An "An IESG Charter, Section 2 Charter",
                                <xref target="RFC3710"/>.</t>

			 <t>RFC target="RFC3710" sectionFormat="comma" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3710#section-2" derivedContent="RFC3710"/>.</li>
        <li pn="section-2-3.4">RFC 3929, Alternative "Alternative Decision Making Processes for
                 Consensus-Blocked Decisions in the IETF IETF",
                             <xref target="RFC3929"/>, target="RFC3929" format="default" sectionFormat="of" derivedContent="RFC3929"/>, Sections 4.1.1 and 4.3
				 (twice).</t>

			 <t>RFC <xref target="RFC3929" section="4.1.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3929#section-4.1.1" derivedContent="RFC3929"/>
                             and <xref target="RFC3929" section="4.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3929#section-4.3" derivedContent="RFC3929"/>
                                 (twice).</li>
        <li pn="section-2-3.5">RFC 4633, Experiment "Experiment in Long-Term Suspensions From
              Internet Engineering Task Force (IETF) Mailing
			  Lists
                          Lists", <xref target="RFC4633"/>, Section 1.</t>

			<t>RFC target="RFC4633" sectionFormat="comma" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4633#section-1" derivedContent="RFC4633"/>.</li>
        <li pn="section-2-3.6">RFC 6702, Promoting "Promoting Compliance with Intellectual
                           Property Rights (IPR) Disclosure Rules,
			   Section 5 Rules",
                           <xref target="RFC6702"/>.</t>

		  </list></t>
	      <t> target="RFC6702" section="5" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6702#section-5" derivedContent="RFC6702"/>.</li>
      </ul>
      <t pn="section-2-4"> Note that the current description of the Internet
			 Standards Process <xref target="RFC2026"/> target="RFC2026" format="default" sectionFormat="of" derivedContent="RFC2026"/> does not
			 require an update by this document for this purpose
			 because the reference
			 to the IETF Executive Director in RFC 2026 was replaced
			 by a document <xref target="RFC3979" format="default" sectionFormat="of" derivedContent="RFC3979"/> that precedes the current
			 effort <xref target="RFC3979"/>
			 effort, and that document was, in turn,
			 obsoleted by <xref target="RFC8179">RFC target="RFC8179" format="default" sectionFormat="of" derivedContent="RFC8179">RFC 8179</xref>.</t>
    </section>
    <section title="Remove numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-removal-of-the-ietf-executi">Removal of the IETF Executive Director as an Option">
	   <t> Option</name>
      <t pn="section-3-1"> In a few cases, it is no longer appropriate for either the
		  Managing Director, IETF Secretariat (former IETF Executive
		  Director position) or the new IETF Executive Director (for
		  the LLC) to perform a particular historical function.
          The relevant documents are updated to remove
		  the IETF Executive Director from the list of people with
		  specific responsibilities or authority.  Those documents
		  will not be updated to use "Managing Director, IETF
		  Secretariat" but, instead, the mention of the position will
		  simply be dropped.</t>
	   <t>
      <t pn="section-3-2"> This document applies that change to the following:
		  <list style="symbols">
			 <t>RFC
      </t>
      <ul spacing="normal" bare="false" empty="false" pn="section-3-3">
        <li pn="section-3-3.1">RFC 3005, IETF "IETF Discussion List Charter Charter"
				<xref target="RFC3005"/>, target="RFC3005" format="default" sectionFormat="of" derivedContent="RFC3005"/>, section titled "Charter for
				the IETF Discussion List".  This document is modified
				to remove the authorization for the IETF Executive
				Director to restrict people from posting, etc.</t>
			    <!-- Jason:  As a result, only etc.</li>
      </ul>
    </section>
    <section anchor="MakeHistoric" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-deprecated-documents">Deprecated Documents</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-documents-whose-context-is-">Documents Whose Context Is Changed by This Specification</name>
        <t pn="section-4.1-1">Both of the IETF Chair,
				   or a sergeant-at-arms appointed documents that follow were obsoleted in 2017
			 by <xref target="RFC8179" format="default" sectionFormat="of" derivedContent="RFC8179">RFC 8179</xref>, which changed
			 mentions of the Chair, are
			       empowered IETF Executive Director to do so.  -->
		  </list></t>
	</section>

	<section title="Deprecated Documents" anchor="MakeHistoric">
	   <t><cref> Note point to
		     the WG, IESG, and RFC Editor: I hope this
		  section correctly reflects the conclusions of discussions in
		  and with the WG.  If it does not, the issues should
		  certainly be identified and fixed.  However, details of
		  some of the actions are the responsibility of the RFC Editor
		  and RFC 3716 is an IAB document containing the report of an
		  IAB Advisory Committee.  If that text, especially the
		  phrasing of various actions, is not quite right, I hope
		  those involved can sort the language out with the RFC Editor
		  rather than requiring that the WG iterate on the
		  draft. --JcK, editor.   RFC Editor: should this paragraph reach
		  you, please remove it.</cref></t>

	   <section title="Documents Whose Context is Changed by This Specification ">
		  <t>Both of the documents that follow were obsoleted in 2017
			 by <xref target="RFC8179">RFC 8179</xref>, which changed
			 mentions of the IETF Executive Director to point to
		     the IETF Secretariat more generally.</t>
			 <t><list style="symbols">
			 <t><xref target="RFC3979">RFC 3979</xref>.</t>
			 <t><xref target="RFC4879">RFC 4879</xref>.</t>
		  </list></t>
	   </section>

	   <section title="General Description IETF Secretariat more generally.</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-4.1-2">
          <li pn="section-4.1-2.1">
            <xref target="RFC3979" format="default" sectionFormat="of" derivedContent="RFC3979">RFC 3979</xref></li>
          <li pn="section-4.1-2.2">
            <xref target="RFC4879" format="default" sectionFormat="of" derivedContent="RFC4879">RFC 4879</xref></li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-general-description-of-the-">General Description of the IETF Adminstrative Model">
			 <t><xref target="RFC3716">RFC Administrative Model</name>
        <t pn="section-4.2-1"><xref target="RFC3716" format="default" sectionFormat="of" derivedContent="RFC3716">RFC 3716</xref> is was a
		report of an IAB Advisory Committee that served as a
		starting point for the work that led to the original
		IASA structure.  That report is was an IAB document
		rather than an IETF one.  The IAB approved a proposal
		to move RFC 3716 to Historic on March 6, 2019. 2019
                <xref target="IAB-3716-Historic" format="default" sectionFormat="of" derivedContent="IAB-3716-Historic"/>. </t>
      </section>
    </section>
    <section anchor="Acknowledgments" title="Acknowledgments">
      <t> Brian Carpenter's careful checking and identification of
		 documents that did, and did not, require consideration was
		 essential to the draft in its current form.  He also made
		 several other significant contributions.  Bob Hinden also
		 gave the document a careful reading and made useful
		 suggestions.  In additional to the above, Alissa Cooper,
		 Eliot Lear, Heather Flanagan (the RFC Series Editor), and the
		 current membership to the IAB helped sort out the handing of
		 RFC 3716.</t>
    </section>

	<section title="Contributors">
	   <t>Jason Livingood did the hard work of identifying the
		  documents that required updating and supplied considerable
		  text used in this document.</t>
	</section>

    <section anchor="IANA" title="IANA Considerations">
	  <t><cref> RFC Editor: Please remove this section before
		 publication.</cref></t>
      <t>This memo includes no requests to or actions for IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-5-1">The changes specified in this document are matters of
		 terminology and organizational structure derived from
		 documents it references.  It should have no effect on
		 Internet security.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->
  <back>
    <references title="Normative References">

	  <!-- &rfc2119; -->
	   &rfc2028;
	   &rfc2418;
	   &rfc3005;
	   <!-- &rfc4844; -->
	   <!-- &rfc5377; -->
	   &rfc3710;
	   &rfc6702;
 <!-- 	   &rfc7500; --> pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC-Struct"
		   target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4071bis/"> anchor="LLC-Agreement" target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf" quoteTitle="true" derivedAnchor="LLC-Agreement">
          <front>
          <title>Structure
            <title>Limited Liability Company Agreement of the IETF Administrative Support Activity, Version 2.0</title>
          <author initials="B." surname="Haberman">
            <organization></organization>
	        <address/>
          </author>
          <author initials="J." surname="Hall">
            <organization></organization>
	        <address/>
          </author>
          <author initials="J." surname="Livingood">
            <organization></organization>
	        <address/> Administration LLC</title>
            <author>
              <organization showOnFrontPage="true">IETF Administration LLC</organization>
            </author>
            <date year="2018" month="December" day="5" /> month="August" day="28"/>
          </front>
        </reference>

	  <!--
        <reference anchor="RFC-StructS3"
		   target="https://tools.ietf.org/html/draft-ietf-iasa2-struct-06#section-3"> anchor="RFC2028" target="https://www.rfc-editor.org/info/rfc2028" quoteTitle="true" derivedAnchor="RFC2028">
          <front>
          <title>Structure of
            <title>The Organizations Involved in the IETF Administrative Support Activity, Version 2.0</title> Standards Process</title>
            <author initials="B." surname="Haberman">
            <organization></organization>
	        <address/> initials="R." surname="Hovey" fullname="R. Hovey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hall">
            <organization></organization>
	        <address/>
          </author>
          <author initials="J." surname="Livingood">
            <organization></organization>
	        <address/> initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="December" day="5" />
        </front>
      </reference>   -->

<reference anchor="RFC-trust-update"
		target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/">
        <front>
          <title>Update to year="1996" month="October"/>
            <abstract>
              <t>This document describes the Process for Selection individuals and organizations involved in the IETF.  This includes descriptions of Trustees for the IESG, the IETF Trust</title>
          <author initials="J." surname="Arkko">
            <organization></organization>
	        <address/>
          </author>
          <author initials="T." surname="Hardie">
            <organization></organization>
	        <address/>
          </author>
          <date year="2018" />
        </front>
      </reference>

<reference anchor="RFC-trust-rationale"
	 target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale/">
        <front>
          <title>Discussion of Working Groups and the IASA 2.0 Changes as They Relate to relationship between the IETF Trust</title>
          <author initials="J." surname="Arkko">
            <organization></organization>
	        <address/>
          </author>
          <date year="2018" /> 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="LLC-Agreement"
	 target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf"> anchor="RFC2418" target="https://www.rfc-editor.org/info/rfc2418" quoteTitle="true" derivedAnchor="RFC2418">
          <front>
          <title>Limited Liability Company Agreement of IETF Administration LLC</title>
            <title>IETF Working Group Guidelines and Procedures</title>
            <author >
            <organization>IETF Administration LLC</organization>
	        <address/> initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August" day="28"/>
        </front>
      </reference>

<reference anchor="RFC-7437bis"
		   target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7437bis/">
        <front>
          <title>IAB, IESG, year="1998" month="September"/>
            <abstract>
              <t>This document describes the guidelines and IETF LLC Selection, Confirmation, procedures for formation and
			 Recall Process: Operation operation of the IETF Nominating working groups.  This document specifies an Internet Best Current Practices for the Internet Community, and
			 Recall Committees</title>
          <author initials="M." surname="Kucherawy" role="editor">
            <organization></organization>
	        <address/> </author>
          <author initials="R." surname="Hinden" role="editor">
            <organization></organization>
	        <address/> </author> 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="RFC3005" target="https://www.rfc-editor.org/info/rfc3005" quoteTitle="true" derivedAnchor="RFC3005">
          <front>
            <title>IETF Discussion List Charter</title>
            <author initials="J." surname="Livingood" role="editor">
            <organization></organization>
	        <address/> initials="S." surname="Harris" fullname="S. Harris">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" />
        </front>
      </reference>

    </references>

   <references title="Informative References">
	    &rfc2026;
		&rfc3716;
		&rfc3929;
		&rfc3979;
		&rfc4633;
 	    &rfc4879;
	    &rfc8179;
   </references>

<!--   Sections below here become  Appendices.  -->

	<section title="Change Log" anchor="ChangeLog">
	    <t>RFC Editor: Please remove this appendix before
        	publication.</t>

	<section title="Changes from version -00 (2018-11-15) to -01">
          <t><list style="symbols">
			 <t> Removed RFCs 3979 and 4879 from the "obsoletes" list
				because they had already been obsoleted (by 8179).  It
				also removes RFC 8179 from the "updates" year="2000" month="November"/>
            <abstract>
              <t>The Internet Engineering Task Force (IETF) discussion mailing list because
				8179 uses "IETF Secretariat" terminology rather than
				"IETF Executive Director".
			 <vspace blankLines="1"/> <cref> Note in Draft: That
				suggests an idea which might considerably mitigate furthers the
				name confusion issue: Instead development and specification of singling out the
				Managing Director Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures.  As this is the Secretariat as a named
				individual, perhaps we should be referring most general IETF mailing list, considerable latitude is allowed. Advertising, whether to the
				Secretariat itself, leaving the contact point solicit business or
				address up to them promote employment opportunities, falls well outside the range of acceptable topics, as an internal administrative
				matter.   Just do discussions of a thought. --JcK</cref></t>
			 <t> Added text to explain why RFC 2026 is not on personal nature.  This document specifies an Internet Best Current Practices for the hit
				list.</t>
			 <t> Added an acknowledgment to Brian Carpenter.  If he
				catches another batch of errors and supplies text, he
				gets promoted to Contributor.</t>
			 <t> Adjusted reference [RFC-Struct] to point to 4071bis.</t>
			 <t> Minor editorial corrections Internet Community, and changes. </t>
		  </list></t>
	   </section>

	  <section title="Changes from version -01 (dated 2018-12-06 but
	      posted 2012-12-07) to -02">
			 <t> I accidentally omitted RFC 4844 from requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="45"/>
          <seriesInfo name="RFC" value="3005"/>
          <seriesInfo name="DOI" value="10.17487/RFC3005"/>
        </reference>
        <reference anchor="RFC3710" target="https://www.rfc-editor.org/info/rfc3710" quoteTitle="true" derivedAnchor="RFC3710">
          <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>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
				header "updates" list 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="RFC6702" target="https://www.rfc-editor.org/info/rfc6702" quoteTitle="true" derivedAnchor="RFC6702">
          <front>
            <title>Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules</title>
            <author initials="T." surname="Polk" fullname="T. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="August"/>
            <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="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711">
          <front>
            <title>Structure of the IETF Administrative Support Activity, Version 01 2.0</title>
            <author initials="B." surname="Haberman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hall">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Livingood">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="February"/>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8711"/>
          <seriesInfo name="DOI" value="10.17487/RFC8711"/>
        </reference>
        <reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713" quoteTitle="true" derivedAnchor="RFC8713">
          <front>
            <title>IAB, IESG, IETF Trust, and noticed that
				in response IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title>
            <author initials="M." surname="Kucherawy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Hinden" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Livingood" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="February" year="2020"/>
          </front>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="8713"/>
          <seriesInfo name="DOI" value="10.17487/RFC8713"/>
        </reference>
        <reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="RFC8714">
          <front>
            <title>Update to an unrelated question almost
				immediately after posting.   The correction seemed
				important enough to justify almost immediate
				re-posting.  Changes are only that header, the Process for Selection of Trustees for the IETF Trust</title>
            <author initials="J." surname="Arkko">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Hardie">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="February" year="2020"/>
          </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="RFC8715">
          <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">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="February" year="2020"/>
          </front>
          <seriesInfo name="RFC" value="8715"/>
          <seriesInfo name="DOI" value="10.17487/RFC8715"/>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="IAB-3716-Historic" target="https://www.iab.org/documents/minutes/minutes-2019/iab-minutes-2019-03-06/" quoteTitle="true" derivedAnchor="IAB-3716-Historic">
          <front>
            <title>IAB Minutes 2019-03-06</title>
            <author>
              <organization showOnFrontPage="true">Internet Architecture Board</organization>
            </author>
            <date year="2019" month="March" day="6"/>
          </front>
        </reference>
        <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" quoteTitle="true" derivedAnchor="RFC2026">
          <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>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 file name, between stages and the date.  --JcK </t>
	    </section>

	   <section title="Changes from version -02 (2018-12-07) to -03">
          <t><list style="symbols">
			 <t> Removed types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and pointers to RFC 7500 - 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="RFC3716" target="https://www.rfc-editor.org/info/rfc3716" quoteTitle="true" derivedAnchor="RFC3716">
          <front>
            <title>The IETF in the Large: Administration and Execution</title>
            <author>
              <organization showOnFrontPage="true">IAB Advisory Committee</organization>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t>In the fall of 2003, the IETF Chair and the IAB
				will publish separately. </t>
			 <t> Added text Chair formed an IAB Advisory Committee (AdvComm), with a mandate to describe (very superficially) RFC 3716.
				 That review the existing IETF administrative structure and relationships (RFC Editor, IETF Secretariat, IANA) and to propose changes to the IETF management process or structure to improve the overall functioning of the IETF.  The AdvComm mandate did not include the standards process itself.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3716"/>
          <seriesInfo name="DOI" value="10.17487/RFC3716"/>
        </reference>
        <reference anchor="RFC3929" target="https://www.rfc-editor.org/info/rfc3929" quoteTitle="true" derivedAnchor="RFC3929">
          <front>
            <title>Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF</title>
            <author initials="T." surname="Hardie" fullname="T. Hardie">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="October"/>
            <abstract>
              <t>This document was obsoleted 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 previous version group has come to consensus that a particular decision must be made but not described.</t>
			 <t> Removed rant about titles and responsibilities from
				<xref target="ExecDir-Managing"/> and cannot agree on the decision itself.  This document describes alternative mechanisms for reaching a subsequent
				editorial note I hope it decision in those cases.  This is no longer needed --JcK.
				In additional, several blocks not meant to provide an exhaustive list, but to provide a known set of text tools that were
				commented out 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="RFC3979" target="https://www.rfc-editor.org/info/rfc3979" quoteTitle="true" derivedAnchor="RFC3979">
          <front>
            <title>Intellectual Property Rights in IETF Technology</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="March"/>
            <abstract>
              <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in earlier versions of the XML IETF are designed to ensure that IETF working groups and participants have been
				removed entirely.</t>
		  </list></t>
	    </section>

	   <section title="Changes from version -03 (2018-12-12) to -04">
          <t><list style="symbols">
			 <t> Removed RFC 4844 from as much information about any IPR constraints on a technical proposal as possible.  The policies are also intended to benefit the update list Internet community and discussion
				because the consensus in public at large, while respecting the legitimate rights of IPR holders.  This memo details the WG seemed IETF policies concerning IPR related to be technology worked on within the IETF.  It also describes the objectives that it
				(and the policies are designed to meet.  This memo updates RFC Editor) should be handled separately. </t>
			 <t> Removed 2026 and, with RFC 5377 from 3978, replaces Section 10 of RFC 2026.  This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418.  This document specifies an Internet Best Current Practices for the update list Internet Community, and requests discussion
				because it involves the Trust. </t>
			 <t> Editor's note in draft:
				<list style="empty">
				   <t> The above changes and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3979"/>
          <seriesInfo name="DOI" value="10.17487/RFC3979"/>
        </reference>
        <reference anchor="RFC4633" target="https://www.rfc-editor.org/info/rfc4633" quoteTitle="true" derivedAnchor="RFC4633">
          <front>
            <title>Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists</title>
            <author initials="S." surname="Hartman" fullname="S. Hartman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t>Discussion in the earlier removal of community has begun to question whether RFC 3683 and RFC 7500
						so 3934 provide the IAB could publish it own appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists.  This document completely
						eliminate is an RFC 3933 experiment designed to allow the earlier Sections 2 and 3.  That may call
						for community to experiment with a revision broader set of tools for mailing list management while trying to determine what the Introduction and/or Abstract, but I
						have not done a review long-term guidelines should be.  This memo defines an Experimental Protocol for this iteration the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4633"/>
          <seriesInfo name="DOI" value="10.17487/RFC4633"/>
        </reference>
        <reference anchor="RFC4879" target="https://www.rfc-editor.org/info/rfc4879" quoteTitle="true" derivedAnchor="RFC4879">
          <front>
            <title>Clarification of
						whether such changes are needed.</t>
					 <t> As documents and references are
						shuffled the Third Party Disclosure Procedure in RFC 3979</title>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="April"/>
            <abstract>
              <t>This document clarifies and out of this one, it occurred to me
						that having updates a non-normative appendix somewhere single sentence in RFC 3979.  Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that
						would identify all of the documents containing changes
						to reflect IETF Executive Director notify the IASA 1.x to 2.0 transition would be of
						great help IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any future historian trying to
						understand what we did and probably helpful disclosure that needs to be made, per applicable RFC 3979 rules.  This document specifies an Internet Best Current Practices for the
						IETF if some of these changes don't work out and/or
						require further tuning.   After a brief discussion,
						Jason Internet Community, and I concluded that appendix did not belong requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4879"/>
          <seriesInfo name="DOI" value="10.17487/RFC4879"/>
        </reference>
        <reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179" quoteTitle="true" derivedAnchor="RFC8179">
          <front>
            <title>Intellectual Property Rights in
						this iteration of this document.</t>
				  </list></t>
		  </list></t>
	    </section>

       <section title="Changes from version -04 (2019-01-17) to -05">
          <t><list style="symbols">
			  <t> Changed title from "Consolidated IASA2-Related
				 Document Updates" 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>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to "Consolidated IASA 2.0 Updates of technologies developed in the IETF
				 Administrative Terminology" per suggestions from Brian
				 Carpenter and Bob Hinden are designed to ensure that IETF working groups and 2019-01-31 WG decision.</t>
			  <t> Removed CREF from <xref target="Intro"/> (should participants have
				 been done as much information as possible about any IPR constraints on a technical proposal as early as possible in -04). the development process.  The only remaining CREFs policies are intended to benefit the one in
				 this section (above) that should probably be
				 preserved through IETF Last Call Internet community and notes to the RFC Editor. </t>
			  <t> Updated acknowledgments.</t>
		  </list></t>
	    </section>

        <section title="Changes from version -05 (2019-01-31) to -06">
          <t><list style="symbols">
			  <t> Changes public at large, while respecting the legitimate rights of IPR holders.  This document sets out the IETF policies concerning IPR related to text about documents technology worked on within the IETF.  It also describes the objectives that the policies are updated and
				 made historic, per advice from RFC Editor, WG
				 Chairs, and IAB. designed to meet. This includes a statement about IAB
				 action of 2019-03-06 that requests that the document updates RFC
				 Editor move 2026 and, with RFC 3716 to Historic but does not obsolete 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>
      </references>
    </references>
    <section anchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t pn="section-appendix.a-1"> <contact fullname="Brian Carpenter's"/> careful checking and identification of
		 documents that
				 Informational report.  When minimal changes were
				 attempted, <xref target="MakeHistoric"/> became very
				 hard to read did, and hence did not, require consideration was restructured
		 essential to the document in its current form.  He also made
		 several other significant contributions.  <contact fullname="Bob Hinden"/> also
		 gave the document a careful reading and somewhat
				 rewritten (and then further modified made useful
		 suggestions.  In additional to work around
				 an xml2rfc glitch).  Special attention should be paid the above, <contact fullname="Alissa Cooper"/>,
		 <contact fullname="Eliot Lear"/>, <contact fullname="Heather Flanagan"/> (the RFC Series Editor), and the
		 current membership to the note at IAB helped sort out the beginning handing of that section.</t>
			  <t> Updated the Acknowledgments section.</t>
		   </list></t>
		 RFC 3716.</t>
    </section>
    <section title="Changes from version -06 (2019-03-06) to -07">
          <t><list style="symbols">
			  <t> Moved RFCs 3929 and 4633 from "obsoleted" to
				 "updated" and stripped text requested that they be
				 made Historic at numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t pn="section-appendix.b-1"><contact fullname="Jason Livingood"/> did the direction hard work of identifying the IETF Chair, WG
				 Co-chair, and an author. </t>
			  <t> Added a section number for a document listed in
				 Section 2
		  documents that was missing.</t>
			  <t> Added some notes to the RFC Editor required updating and others.</t>
			  <t> Updated the acknowledgments.</t>
		  </list></t> supplied considerable
		  text used in this document.</t>
    </section>

 <!--
    <section title="Changes from version -07 (2019-03-11) to
		-08">
          <t><list style="symbols">
			  <t> ... </t>
		  </list></t>
	    </section> --> anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="John C Klensin" initials="J." surname="Klensin" role="editor">
        <organization showOnFrontPage="true"/>
        <address>
          <postal>
            <street>1770 Massachusetts Ave, Ste 322</street>
            <city>Cambridge</city>
            <region>MA</region>
            <code>02140</code>
            <country>USA</country>
          </postal>
          <phone>+1 617 245 1457</phone>
          <email>john-ietf@jck.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>