<?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"?> version='1.0' encoding='utf-8'?>
<!-- Sets the number of levels of sections/subsections... in ToC.
   Can be overridden updated by 'toc="include"/"exclude"' on the section
<!-- 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 Jean Mahoney, converted 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 v3, /10/31/19 -->
<!-- This is -07c, the posting version xml2rfc v2v3 conversion 2.34.0 -->

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc  docName="draft-ietf-iasa2-consolidated-upd-07"
     ipr="trust200902"  category="bcp"
updates="2028, 2418, 3005, 3710, 3929, 4633, 6702" >
        <!-- JcK 20181203: removed 3979, 4879, 8179 from Obsoletes
             JcK 20190117: removed 4844, 5377
             JcK 20190311, removed 3929, 4633 and moved to updates -->

  <!-- ***** FRONT MATTER ***** -->


    <title abbrev="IASA2 abbrev="IASA 2.0 Consolidated 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"/>
    <seriesInfo name="BCP" value="101"/>
    <author fullname="John C Klensin" initials="J.C." initials="J." surname="Klensin" role="editor">
          <street>1770 Massachusetts Ave, Ste 322</street>
        <phone>+1 617 245 1457</phone>
    <date month="March" day="11" year="2019" />

    <!-- Meta-data Declarations --> month="January" year="2020"/>


<!-- WG name at the upper left corner of [rfced]   The abstract does not explicitly mention the doc,
         IETF fine for individual submissions.  You can also
         omit RFCs
that this element in which case document updates nor does it defaults to "Network Working Group" -
         a hangover from the ancient history of explicitly call out the IETF! -->

	<!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have RFC that
this document moves to Historic.

               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 effect on text or nroff output.
   confusion due to these changes.</t>

               Rather than reissue those referencing documents
   individually, this specification provides updates to RFCs 2028,
   2418, 3005, 3710, 3929, 4633, and 6702 to make those terminology
   and related changes.  In addition, it requests that RFC 3716
   be made Historic.
<!-- <keyword>Text</keyword> (as many [JcK 2020-01-20] It is my personal opinion that for a
document of this type, adding that list to the abstract makes
the latter less comprehensible rather than more so, especially
because those elements as needed two sentences are basically incomprehensible
unless someone happens to have the numbers memorized.  Those
sentences also violate the general principle that abstracts
should not contain references, whether the citation anchors are
explicit on not.

There is an additional consideration: If either the RFC Editor
or the IESG insist on such listings, especially in abstracts,
then any document proposed for BCP or Standards Track status
that says, whether explicitly or not, that any previous
document that happens to be inconsistent with it is now
partially obsolete and in need to alignment to the present
document becomes unpublishable.  -->

      <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"
		 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
		 this specification provides updates to them and deprecates
		 some now-obsolete documents to ensure that
		 there is no confusion due to these changes.</t>

	<!-- Note here if needed
	   <note title=""><t> .... </t></note> -->
    <section title="Introduction" anchor="Intro"> anchor="Intro" numbered="true" toc="default">
      <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 <xref target="RFC-Struct"/>. target="RFC8711" format="default"/>.   Key
		 IASA 2.0 changes have been
		<!-- The IETF initiated a major revision of its administrative
		 support arrangements and procedures in 2018
		 <xref target="RFC-Struct"/>.  Those 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"/>,
		 the rationale for it <xref target="RFC-trust-rationale"/>, target="RFC8715" format="default"/>,
		 a new defining document for the IETF Administration LLC <xref target="LLC-Agreement"/> target="LLC-Agreement" format="default"/> (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> target="RFC8713" format="default"/>.</t>
      <t>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
	   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> 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"/>).
		 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 title="Remove Text About the Connection Between anchor="ExecDir-Managing" numbered="true" toc="default">
      <name>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>
	</section>  -->

   <!-- <section title="Replacement of IAOC with IETF Administration LLC"
		<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>

	</section>  -->

	<section title="Where Appropriate, Replacement of the IETF Executive Director position with the Managing Director, IETF Secretariat"
			anchor="ExecDir-Managing"> Secretariat</name>

      <t>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> target="RFC8711" format="default"/>.</t>
      <t> 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">
        <li>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"/>.</li>
        <li>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"/>.</li>
        <li>RFC 3710, An "An IESG Charter, Section 2 Charter",
                                <xref target="RFC3710"/>.</t>

			 <t>RFC target="RFC3710" sectionFormat="comma" section="2" format="default"/>.</li>
        <li>RFC 3929, Alternative "Alternative Decision Making Processes for
                 Consensus-Blocked Decisions in the IETF IETF",
                             <xref target="RFC3929"/>, target="RFC3929" format="default"/>, Sections 4.1.1 <xref target="RFC3929" section="4.1.1" sectionFormat="bare"/>
                             and 4.3

			 <t>RFC <xref target="RFC3929" section="4.3" sectionFormat="bare"/>
        <li>RFC 4633, Experiment "Experiment in Long-Term Suspensions From
              Internet Engineering Task Force (IETF) Mailing
                          Lists", <xref target="RFC4633"/>, Section 1.</t>

			<t>RFC target="RFC4633" sectionFormat="comma" section="1" format="default"/>.</li>
        <li>RFC 6702, Promoting "Promoting Compliance with Intellectual
                           Property Rights (IPR) Disclosure Rules,
			   Section 5 Rules",
                           <xref target="RFC6702"/>.</t>

		  </list></t> target="RFC6702" section="5" sectionFormat="comma"/>.</li>
      <t> Note that the current description of the Internet
			 Standards Process <xref target="RFC2026"/> target="RFC2026" format="default"/> 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"/> 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">RFC 8179</xref>.</t>
    <section title="Remove numbered="true" toc="default">
      <name>Removal of the IETF Executive Director as an Option"> Option</name>
      <t> 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> This document applies that change to the following:
		  <list style="symbols">
      <ul spacing="normal">
        <li>RFC 3005, IETF "IETF Discussion List Charter Charter"
				<xref target="RFC3005"/>, target="RFC3005" format="default"/>, 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 the IETF Chair,
				   or a sergeant-at-arms appointed by the Chair, are
			       empowered to do so.  -->
		  </list></t> etc.</li>
    <section title="Deprecated Documents" anchor="MakeHistoric">
	   <t><cref> Note 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 anchor="MakeHistoric" numbered="true" toc="default">
      <name>Deprecated Documents</name>

      <section numbered="true" toc="default">
        <name>Documents Whose Context Is Changed by This Specification</name>
        <t>Both of the documents that follow were obsoleted in 2017
			 by <xref target="RFC8179">RFC target="RFC8179" format="default">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>
        <ul spacing="normal">
            <xref target="RFC3979" format="default">RFC 3979</xref></li>
            <xref target="RFC4879" format="default">RFC 4879</xref></li>
      <section title="General numbered="true" toc="default">
        <name>General Description of the IETF Adminstrative Model"> Administrative Model</name>

        <t><xref target="RFC3716">RFC target="RFC3716" format="default">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"/>. </t>

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

    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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>

  <!--  *****BACK MATTER ***** -->

    <references title="Normative References">

	  <!-- &rfc2119; -->
	   <!-- &rfc4844; -->
	   <!-- &rfc5377; -->
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2028.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2418.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3005.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3710.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6702.xml"/>
        <!-- 	   &rfc7500; draft-ietf-iasa2-rfc4071bis - RFC 8711  -->
        <reference anchor="RFC-Struct"
		   target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc4071bis/"> anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711">
            <title>Structure of the IETF Administrative Support Activity, Version 2.0</title>
            <author initials="B." surname="Haberman">
            <author initials="J." surname="Hall">
            <author initials="J." surname="Livingood">
            <date year="2018" month="December" day="5" /> year="2020" month="January"/>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8711"/>
          <seriesInfo name="DOI" value="10.17487/RFC8711"/>

<reference anchor="RFC-StructS3"
          <title>Structure of the IETF Administrative Support Activity, Version 2.0</title>
          <author initials="B." surname="Haberman">
          <author initials="J." surname="Hall">
          <author initials="J." surname="Livingood">
          <date year="2018" month="December" day="5" />
      </reference> draft-ietf-iasa2-trust-update - RFC 8714 -->
        <reference anchor="RFC-trust-update"
		target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-update/"> anchor="RFC8714" target="https://rfc-editor.org/info/rfc8714">
            <title>Update to the Process for Selection of Trustees for
			 the IETF Trust</title>
            <author initials="J." surname="Arkko">
            <author initials="T." surname="Hardie">
            <date year="2018" /> month="January" year="2020"/>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8714"/>
          <seriesInfo name="DOI" value="10.17487/RFC8714"/>

        <!-- draft-ietf-iasa2-trust-rationale - RFC 8715 -->
        <reference anchor="RFC-trust-rationale"
	 target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-trust-rationale/"> anchor="RFC8715" target="https://rfc-editor.org/info/rfc8715">
            <title>Discussion of the IASA 2.0 Changes as They Relate to
			 the IETF Trust</title>
            <author initials="J." surname="Arkko">
            <date year="2018" /> month="January" year="2020"/>
          <seriesInfo name="RFC" value="8715"/>
          <seriesInfo name="DOI" value="10.17487/RFC8715"/>

        <reference anchor="LLC-Agreement" target="https://www.ietf.org/documents/180/IETF-LLC-Agreement.pdf">
            <title>Limited Liability Company Agreement of IETF Administration LLC</title>
          <author >
              <organization>IETF Administration LLC</organization>
            <date year="2018" month="August" day="28"/>

        <!-- draft-ietf-iasa2-rfc7437bis - RFC 8713 -->
        <reference anchor="RFC-7437bis"
		   target="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7437bis/"> anchor="RFC8713" target="https://rfc-editor.org/info/rfc8713">
            <title>IAB, IESG, and IETF LLC Selection, Confirmation, and
			 Recall Process: Operation of the IETF Nominating and
			 Recall Committees</title>
            <author initials="M." surname="Kucherawy" role="editor">
            <author initials="R." surname="Hinden" role="editor">
            <author initials="J." surname="Livingood" role="editor">
            <date year="2018" /> month="January" year="2020"/>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="8713"/>
          <seriesInfo name="DOI" value="10.17487/RFC8713"/>

        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3716.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3929.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3979.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4633.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4879.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8179.xml"/>

        <reference anchor="IAB-3716-Historic" target="https://www.iab.org/documents/minutes/minutes-2019/iab-minutes-2019-03-06/">
            <title>IAB Minutes 2019-03-06</title>
              <organization>Internet Architecture Board</organization>
            <date year="2019" month="March" day="6"/>


   <references title="Informative References">

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

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

    <section title="Changes from version -00 (2018-11-15) to -01">
          <t><list style="symbols">
			 <t> Removed RFCs 3979 anchor="Acknowledgments" numbered="false" toc="default">
      <t> <contact fullname="Brian Carpenter's"/> careful checking and 4879 from the "obsoletes" list
				because they had already been obsoleted (by 8179).  It
				also removes RFC 8179 from the "updates" 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 the
				name confusion issue: Instead of singling out the
				Managing Director identification of the Secretariat as a named
				individual, perhaps we should be referring to the
				Secretariat itself, leaving the contact point or
				address up to them as an internal administrative
				matter.   Just a thought. --JcK</cref></t>
			 <t> Added text to explain why RFC 2026 is not on the hit
			 <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
		 documents that did, and changes. </t>

	  <section title="Changes from version -01 (dated 2018-12-06 but
	      posted 2012-12-07) did not, require consideration was
		 essential to -02">
			 <t> I accidentally omitted RFC 4844 from the document
				header "updates" list in Version 01 and noticed that in response 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
				document file name, and its current form.  He also made
		 several other significant contributions.  <contact fullname="Bob Hinden"/> also
		 gave the date.  --JcK </t>

	   <section title="Changes from version -02 (2018-12-07) to -03">
          <t><list style="symbols">
			 <t> Removed discussion and pointers to RFC 7500 - IAB
				will publish separately. </t>
			 <t> Added text to describe (very superficially) RFC 3716.
				 That document was obsoleted in the previous version
				 but not described.</t>
			 <t> Removed rant about titles and responsibilities from
				<xref target="ExecDir-Managing"/> and a subsequent
				editorial note I hope it is no longer needed --JcK.
				In additional, several blocks of text that were
				commented out in earlier versions of the XML have been
				removed entirely.</t>

	   <section title="Changes from version -03 (2018-12-12) to -04">
          <t><list style="symbols">
			 <t> Removed RFC 4844 from the update list careful reading and discussion
				because the consensus in the WG seemed made useful
		 suggestions.  In additional to be that it
				(and the above, <contact fullname="Alissa Cooper"/>,
		 <contact fullname="Eliot Lear"/>, <contact fullname="Heather Flanagan"/> (the RFC Editor) should be handled separately. </t>
			 <t> Removed RFC 5377 from the update list and discussion
				because it involves the Trust. </t>
			 <t> Editor's note in draft:
				<list style="empty">
				   <t> The above changes Series Editor), and the earlier removal of RFC 7500
		 current membership to the IAB could publish it own document completely
						eliminate the earlier Sections 2 and 3.  That may call
						for a revision of the Introduction and/or Abstract, but I
						have not done a review for this iteration of
						whether such changes are needed.</t>
					 <t> As documents and references are
						shuffled in and helped sort out of this one, it occurred to me
						that having a non-normative appendix somewhere that
						would identify all of the documents containing changes
						to reflect the IASA 1.x to 2.0 transition would be of
						great help to any future historian trying to
						understand what we did and probably helpful to the
						IETF if some of these changes don't work out and/or
						require further tuning.   After a brief discussion,
						Jason and I concluded that appendix did not belong in
						this iteration of this document.</t>

       <section title="Changes from version -04 (2019-01-17) to -05">
          <t><list style="symbols">
			  <t> Changed title from "Consolidated IASA2-Related
				 Document Updates" to "Consolidated IASA 2.0 Updates handing of IETF
				 Administrative Terminology" per suggestions from Brian
				 Carpenter and Bob Hinden and 2019-01-31 WG decision.</t>
			  <t> Removed CREF from <xref target="Intro"/> (should have
				 been done in -04). The only remaining CREFs are the one in
				 this section (above) that should probably be
				 preserved through IETF Last Call and notes to the
		 RFC Editor. </t>
			  <t> Updated acknowledgments.</t>
		  </list></t> 3716.</t>
    <section title="Changes from version -05 (2019-01-31) to -06">
          <t><list style="symbols">
			  <t> Changes to text about documents that are updated and
				 made historic, per advice from RFC Editor, WG
				 Chairs, and IAB.  This includes a statement about IAB
				 action of 2019-03-06 that requests that numbered="false" toc="default">
      <t><contact fullname="Jason Livingood"/> did the RFC
				 Editor move RFC 3716 to Historic but does not obsolete that
				 Informational report.  When minimal changes were
				 attempted, <xref target="MakeHistoric"/> became very hard to read and hence was restructured and somewhat
				 rewritten (and then further modified to work around
				 an xml2rfc glitch).  Special attention should be paid
				 to the note at the beginning of that section.</t>
			  <t> Updated identifying the Acknowledgments section.</t>

		<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
		  documents that they be
				 made Historic at the direction of the IETF Chair, WG
				 Co-chair, required updating and an author. </t>
			  <t> Added a section number for a document listed supplied considerable
		  text used in
				 Section 2 that was missing.</t>
			  <t> Added some notes to the RFC Editor and others.</t>
			  <t> Updated the acknowledgments.</t>

 <!--       <section title="Changes from version -07 (2019-03-11) to
          <t><list style="symbols">
			  <t> ... </t>
	    </section> --> this document.</t>