<?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 rfc2119 PUBLIC ''"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> -->
<!ENTITY rfc2418 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
<!ENTITY rfc5377 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5377.xml">

<!-- Outline of entity definition for citations to Internet Drafts
     &lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM 
     "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfcs">
     corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt.
     Naming convention for draft-ietf-xx-yy is that
       ietf-xx-yy  is latest version
       draft-ietf-xx-yy-NN is that version.  Similarly for draft-foo
       rather than draft-ietf: foo-xx-yy and draft-foo-xx-yy-NN
   -->
<!-- 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 -->

<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
         original ipr values are: full3978, noModification3978, noDerivatives3978), 
         2008 IETF Trust versions: trust200811, noModificationTrust200811, noDerivativeTrust200811
         2009/Current: trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
     Also for Internet-Drafts, you must specify a value for attributes "docName" which is 
        typically the file name under which it is filed but need not be.
     If relevant, "iprExtract" may be specified to denote the anchor attribute value of a
        section that can be extracted for separate publication, it is only useful when the value
        of "ipr" does not give the Trust full rights.
     "updates" and "obsoletes" attributes can also be specified here, their arguments are
        comma-separated lists of RFC numbers (just the numbers) -->

<rfc  docName="draft-klensin-iasa2-2418upd-5377upd-00"
     ipr="trust200902"  category="info"
	 updates="2418, 5377">
     <!-- obsoletes='2821, 821' updates='1123'
        category='std' (bcp, info, exp, historic)  -->   


  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="IASA2 Terminology Updates">IASA2 Updates for Terminology
	   and Relationships</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author fullname="John C Klensin" initials="J.C." surname="Klensin">      <organization/>
      <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="October" day="22" year="2018" />

    <!-- Meta-data Declarations
    <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>Network Working Group</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>The IASA2 effort changes the terminology associated with
		 several roles and the relationships among existing bodies and
		 functions to the successors of others.   In some cases, the
		 relevant earlier documents address other matters, including
		 ones that are critical to IETF processes, and are better
		 dealt with by updating the relevant terminology or provisions
		 rather than attempting to replace the earlier documents in
		 their entirety.  This document provides those updates for
		 RFCs 2418 and 5377 [[and perhaps others in later versions]].
		 </t>
    </abstract>

	<!-- Note here if needed -->
	   <note title="Note in Draft">
		  <t> There has been a recent discussion on the IASA2 list,
			 and partially on the IETF one, about the desirability of
			 completely replacing important procedural or IETF process
			 definitional documents in order to align terminology with
			 the new IASA model.  It has been suggested (by this
			 author and others) that such changes are error-prone,
			 unnecessary work, may be misleading, and may (presumably
			 inadvertently) violate the WG's charter by changing IETF
			 procedures for creation, review, and approval of
			 standards for the Internet.</t>
		  <t> With the posting deadline for IETF 103 (Bangkok) and
			 awareness of the difficulty of holding a WG discussion
			 of a problem with 
			 one or more documents without a concrete counterproposal
			 in hand, this hastily-prepared I-D is provided for the
			 convenience of the WG and the IETF community.   Should
			 the WG decide to make use of it, a co-author or
			 replacement author should be sought who would take the
			 lead in smoothing rough edges, inserting references where
			 needed, adding material for other specifications that
			 should be updated, etc.</t>
	   </note>
	
  </front>

  <middle>
    <section title="Introduction">
      <t>The 2018 transition from the original IETF Administrative Support
		 Activity (IASA) to a new model renames a number of roles and
		 tunes the relationships among various bodies.  These changes
		 affect the terminology associated with existing definitional
		 and procedural specifications without actually making
		 substantive changes to the procedures or operations involved.
		 Rather than replacing ("obsoleting") the original documents
		 where that is not strictly and substantively necessary,
		 potentially creating confusion about references to them and
		 risking inadvertent substantive changes, this document
		 provides those updates that are required for consistency with
		 the new IASA2 approach and clarifies the relationships
		 involved. </t>
	  <t> This version of the I-D provides the changes needed
		 to update the base specifications for IETF Working Group
		 operations and procedures <xref target="RFC2418"/> and advice
		 to the IETF Trust <xref target="RFC5377"/> to reflect the
		 IASA2 changes.  It does not attempt to address other issues
		 with those documents that have arisen as the IETF has
		 evolved or errors have been detected.</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="Overview">
	   <t> The changes from the original IASA model to the iASA2 one
		  include changes that, while important in their own right,
		  affect the terminology used in other procedural documents
		  without changing the underlining procedures or
		  specifications of those documents.  These changes include
		  <list style="symbols">
			 <t> Changes of titles, e.g., from "IETF Executive
				Director" to "Managing Director of the IETF
				Secretariat".  The IASA2 specifications may change the
				underlying roles as well, but those changes do not
				affect the documents that are the subject of this
				specification.</t>
			 <t> Changes of relationships. e.g, the Trustees of the
				IETF Trust are no longer simply the members of what is
				in principle another body (the IAOC, which has been
				eliminated) but are separately appointed.  In part
				because there is little actual change to the structure
				or responsibilities of the Trustees themselves, the
				documents that are the subject of this specification
				should be updated to eliminate assertions about the
				previous relationships but do not require more
				substantive chagnes.</t>
		   </list></t>
		</section>

		<section title="Document updates: RFC 2418">
		   <t>In Section 1, paragraph 6, "The area directors sitting
			  as a body...", change
			  <list style="empty">
				 <t>  The IETF Executive Director is... </t>
			  </list>
			  to
			  <list style="empty">
				 <t> The Managing Director of the IETF Secretariat
					is...</t>
			  </list>
		      See above for explanation.</t>
		</section>

		<section title="Document updates: RFC 5377">
		   <t><list style="hanging">
			  <t hangText="Section 1, paragraph 1">
				 Drop "made up of the members of the IAOC [RFC4371]"
				 after "board of trustees" </t>
			  <t hangText="Section 2, last paragraph">
				 Drop "Appeals of the actions of the Trustees of the
				 IETF Trust are governed by other documents.  As the
				 Trustees are the members of the IAOC, the appeals
				 procedure documented in BCP 101 (currently
				 [RFC4371]) is applicable."
				 <vspace blankLines="0"/><cref> This is in need of
					careful checking.  Probably the correct change is
					not this one but would be a reference to
					whatever document lays out the new appeals
					procedures.</cref></t>
			    <t hangText="Section 3, first paragraph">
				   Drop ", which is made up of the members of the
				   IAOC, as described in [RFC4071] and [RFC4371]".</t>
			</list></t>
		 </section>
				   

    <!-- Possibly a 'Contributors' section ... -->

	<section title="Acknowledgements">
	   <t> This document was initiated as a response to perceived
		  issues with efforts to replace RFC 2418
		  and RFC 5377 <cref> Insert references in -01</cref>. It
		  borrows extensively from the changes suggested in those
		  drafts and would not have been possible without the work of
		  Rich Salz and Joel Halpern in constructing the drafts and
		  their suggested text. </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>This specification is about technical updates to IETF
		 procedures.  It does not change the security of the Internet
		 and any issues are identified in the documents normatively
		 referenced.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split to informative and normative -->

    <references title="Normative References">

	  &rfc2418;
	  &rfc5377;

<!-- the following is the minimum to make xml2rfc happy -->	  
   <!--   <reference anchor="min_ref">

        <front>
          <title>Minimal Reference</title>
          <author initials="authInitials" surname="authSurName">
            <organization></organization>
	        <address/>
          </author>
          <date year="2006" />
        </front>
      </reference>  -->
    </references>

<!--    <references title="Informative References"> -->
      <!-- Right back at the beginning we defined an entity which (we asserted) would contain
             XML needed for a reference... this is where we use it. -->

      <!-- A reference written by by an organization not a person. 
           NOTE: This reference is not referenced: this is immoral in I-Ds and RFCs, but may not
	   be in other technical documents. It will be flagged when strict="yes". -->

   <!--      <reference anchor="DOMINATION"
                 target="http://www.example.com/dominator.html">
        <front>
          <title>Ultimate Plan for Taking Over the World</title>
          <author>
            <organization>Mad Dominators, Inc.</organization>
          </author>
          <date year="1984" />
        </front>
      </reference>  -->
	   
    <!-- </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-10-22) to -01">
          <t><list style="symbols">
			 <t>	... </t>
		  </list></t>
	   </section>
	
	</section>      -->

  </back>
</rfc>
