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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC3710 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3710.xml">
<!ENTITY RFC3777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml">
<!ENTITY RFC3797 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3797.xml">
<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4071.xml">
<!ENTITY RFC5078 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5078.xml">
<!ENTITY RFC5633 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5633.xml">
<!ENTITY RFC6859 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6859.xml">
<!ENTITY RFC7437 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7437.xml">
<!ENTITY RFC7776 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7776.xml">
<!ENTITY RFC8318 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8318.xml">

<!ENTITY I-D.ietf-iasa2-rfc4071bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-rfc4071bis.xml">

<!ENTITY I-D.ietf-iasa2-trust-update SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-trust-update.xml">

<!ENTITY I-D.ietf-iasa2-consolidated-upd SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-iasa2-consolidated-upd.xml">

]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> 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-rfc7437bis-09" indexInclude="true" ipr="trust200902" number="8713" obsoletes="7437, 8318"
    ipr="trust200902"> prepTime="2020-02-26T17:11:37" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7437bis-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8713" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="NomCom">
	IAB, abbrev="NomCom">IAB, IESG, IETF Trust Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
</title> Committees</title>
    <seriesInfo name="RFC" value="8713" stream="IETF"/>
    <seriesInfo name="BCP" value="10" stream="IETF"/>
    <author initials="M. S." initials="M." surname="Kucherawy" fullname="Murray S. Kucherawy" role="editor">
	<organization/>
      <organization showOnFrontPage="true"/>
      <address>
        <postal>
          <street>270 Upland Drive</street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94127</code>
          <country>United States</country> States of America</country>
        </postal>
        <email>superuser@gmail.com</email>
      </address>
    </author>
    <author fullname="Robert M. Hinden" initials="R." surname="Hinden" role="editor">
	<organization>Check
      <organization showOnFrontPage="true">Check Point Software</organization>
      <address>
        <postal>
		    <street></street>
          <street/>
          <city>San Carlos</city>
          <region>CA</region>
          			<country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>bob.hinden@gmail.com</email>
      </address>
    </author>
    <author fullname="Jason Livingood" initials="J." surname="Livingood" role="editor">
	<organization>Comcast</organization>
      <organization showOnFrontPage="true">Comcast</organization>
      <address>
        <postal>
		    <street></street>
          <street/>
          <city>Philadelphia</city>
          <region>PA</region>
          			<country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>jason_livingood@comcast.com</email>
      </address>
    </author>
    <date month="" year=""/> month="02" year="2020"/>
    <area>General</area>

<!--
    <workgroup>IETF Administrative Support Activity 2</workgroup>
-->

<abstract>

<!--
	<t> The process by which the members of the IAB and IESG, some
	Trustees of the IETF Trust, and
	some Directors of the IETF LLC are selected, confirmed, and
	recalled is specified in this document.  This document is based on
	RFC3777 and RFC7437 and has been updated to reflect the changes
	introduced by IASA 2.0.</t>
-->

	<t>The
    <keyword>IASA</keyword>
    <keyword>IASA 2.0</keyword>
    <keyword>IASA2</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">The process by which the members of the IAB and IESG, some
	Trustees of the IETF Trust, and some Directors of the IETF
	Administration LLC (IETF LLC)
	are selected, confirmed, and recalled is specified in this
	document.
        This document is based on RFC7437. RFC 7437.  Only
	those updates required to reflect the changes introduced
	by IASA IETF Administrative Support Activity (IASA) 2.0 have been included.
        Any other changes will be addressed in future documents.</t>

	<t>This
      <t pn="section-abstract-2">This document obsoletes RFC7437 RFC 7437 and RFC8318.</t> RFC 8318.</t>
    </abstract>

</front>

<middle>
    <boilerplate>
      <section anchor="intro" title="Introduction">

	<t> This document is a revision anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of <xref target="RFC7437"/> that
	updates it to be consistent with the
        IETF Administrative Support Activity (IASA) 2.0 changes.  RFC 7437
	was based on <xref target="RFC3777"/> that consolidated and updated
	other RFCs that updated that 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 into a single
	specification.  The result is a complete specification of the
	process by which members product of the Internet Architecture Board (IAB)
	and Internet Engineering Steering Group (IESG), some Trustees of Task Force
            (IETF).  It represents the IETF Trust, and some Directors consensus of the IETF Administration LLC
	(IETF LLC), are selected, confirmed, community.  It has
            received public review and recalled. </t>

	<t>This revision addresses only the changes required has been approved for IASA
	2.0; should publication by
            the community agree Internet Engineering Steering Group (IESG).  Further information
            on other changes, they will be
	addressed BCPs is available in future documents.</t>

	<t>Section Section 2 of <xref target="I-D.ietf-iasa2-trust-update"/>
	provides further details 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/rfc8713" 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 Trust Trustees
	positions that are filled by and the IETF Nominating Committee
	(NomCom). </t>

	<t>Section 5 of <xref target="I-D.ietf-iasa2-rfc4071bis"/>
	provides further details about persons identified as the IETF LLC Director
	positions that are filled by the NomCom.
            document authors. All rights reserved.
        </t>

	<t>The following two assumptions continue
        <t pn="section-boilerplate.2-2">
            This document is subject to be true of this specification:
		<list style="numbers">
			<t> The Internet Research Task Force (IRTF) BCP 78 and
			    Internet Research Steering Group (IRSG) are not a
			    part of the process described here. </t>

			<t> The organization (and reorganization) of the IESG
			    is not a part of the process described here. </t>
		</list>
	</t>

	<t> The time frames specified here use IETF meetings as
		    a frame of reference.  The time frames assume that the IETF meets three times per calendar year with
		    approximately equal amounts of time between them.  The
		    meetings are referred Trust's Legal
            Provisions Relating to as the First IETF, Second IETF,
		    or Third IETF as needed. </t>

	<t> The next section lists Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the words and phrases commonly used
		    throughout date of
            publication of this document document. Please review these documents
            carefully, as they describe your rights and restrictions with their intended meaning. </t>

	<t> The majority of
            respect to this document. Code Components extracted from this
            document is divided into four major
		    topics must include Simplified BSD License text as follows:

		<list style="hanging">
			<t hangText="General:"> This is a set described in
            Section 4.e of rules and
				constraints that apply to the selection Trust Legal Provisions and
				confirmation process are provided without
            warranty as a whole. </t>

			<t hangText="Nominating Committee Selection:"> This
				is the process by which the volunteers who
				will serve on described in the NomCom are
				selected. </t> 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-definitions">Definitions</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-general">General</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-completion-due">Completion Due</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t hangText="Nominating keepWithNext="true" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nominating-committee-princi">Nominating Committee Operation:"> This
				is the set of principles, rules, Principal Functions</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-positions-to-be-reviewed">Positions to Be Reviewed</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-term-lengths">Term Lengths</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mid-term-vacancies">Mid-term Vacancies</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confidentiality">Confidentiality</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advice-and-consent-model">Advice and
				constraints that guide the activities of
				the NomCom, including the
				confirmation process. </t> Consent Model</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.7.2">
                  <li pn="section-toc.1-1.3.2.7.2.1">
                    <t hangText="Member, Trustee, keepWithNext="true" pn="section-toc.1-1.3.2.7.2.1.1"><xref derivedContent="3.7.1" format="counter" sectionFormat="of" target="section-3.7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-positions-to-be-reviewed-2">Positions to Be Reviewed</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.7.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.7.2.2.1"><xref derivedContent="3.7.2" format="counter" sectionFormat="of" target="section-3.7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-candidate-selection">Candidate Selection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.7.2.3">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.7.2.3.1"><xref derivedContent="3.7.3" format="counter" sectionFormat="of" target="section-3.7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-candidate-review">Candidate Review</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.7.2.4">
                    <t keepWithNext="true" pn="section-toc.1-1.3.2.7.2.4.1"><xref derivedContent="3.7.4" format="counter" sectionFormat="of" target="section-3.7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confirmation">Confirmation</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.8">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.8.1"><xref derivedContent="3.8" format="counter" sectionFormat="of" target="section-3.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sitting-members-directors-a">Sitting Members, Directors, and Director Recall:"> This is the process by
				which the behavior of a sitting member Trustees</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.9">
                <t keepWithNext="true" pn="section-toc.1-1.3.2.9.1"><xref derivedContent="3.9" format="counter" sectionFormat="of" target="section-3.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-announcements">Announcements</xref></t>
              </li>
            </ul>
          </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-nominating-committee-select">Nominating Committee Selection</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-timeline">Timeline</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-term">Term</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure">Structure</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-chair-duties">Chair Duties</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-chair-selection">Chair Selection</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-temporary-chair">Temporary Chair</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.7">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.7.1"><xref derivedContent="4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-liaisons">Liaisons</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.8">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.8.1"><xref derivedContent="4.8" format="counter" sectionFormat="of" target="section-4.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-liaison-appointment">Liaison Appointment</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.9">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.9.1"><xref derivedContent="4.9" format="counter" sectionFormat="of" target="section-4.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-advisors">Advisors</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.10">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.10.1"><xref derivedContent="4.10" format="counter" sectionFormat="of" target="section-4.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-past-chair">Past Chair</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.11">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.11.1"><xref derivedContent="4.11" format="counter" sectionFormat="of" target="section-4.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-voting-volunteers">Voting Volunteers</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.12">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.12.1"><xref derivedContent="4.12" format="counter" sectionFormat="of" target="section-4.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-milestones">Milestones</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.13">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.13.1"><xref derivedContent="4.13" format="counter" sectionFormat="of" target="section-4.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-open-positions">Open Positions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.14">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.14.1"><xref derivedContent="4.14" format="counter" sectionFormat="of" target="section-4.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-volunteer-qualification">Volunteer Qualification</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.15">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.15.1"><xref derivedContent="4.15" format="counter" sectionFormat="of" target="section-4.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-not-qualified">Not Qualified</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.16">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.16.1"><xref derivedContent="4.16" format="counter" sectionFormat="of" target="section-4.16"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-selection-process">Selection Process</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.17">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.17.1"><xref derivedContent="4.17" format="counter" sectionFormat="of" target="section-4.17"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-announcement-of-selection-r">Announcement of the
				IESG, or IAB, IETF Trust Selection Results</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.18">
                <t keepWithNext="true" pn="section-toc.1-1.4.2.18.1"><xref derivedContent="4.18" format="counter" sectionFormat="of" target="section-4.18"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-committee-organization">Committee Organization</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-nominating-committee-operat">Nominating Committee Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discretion">Discretion</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-selection-timeline">Selection Timeline</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-confirmation-timeline">Confirmation Timeline</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-milestones-2">Milestones</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-voting-mechanism">Voting Mechanism</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-voting-quorum">Voting Quorum</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.7">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-voting-member-recall">Voting Member Recall</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.8">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.8.1"><xref derivedContent="5.8" format="counter" sectionFormat="of" target="section-5.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-chair-recall">Chair Recall</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.9">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.9.1"><xref derivedContent="5.9" format="counter" sectionFormat="of" target="section-5.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deliberations">Deliberations</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.10">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.10.1"><xref derivedContent="5.10" format="counter" sectionFormat="of" target="section-5.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-call-for-nominees">Call for Nominees</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.11">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.11.1"><xref derivedContent="5.11" format="counter" sectionFormat="of" target="section-5.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nominations">Nominations</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.12">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.12.1"><xref derivedContent="5.12" format="counter" sectionFormat="of" target="section-5.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-candidate-selection-2">Candidate Selection</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.13">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.13.1"><xref derivedContent="5.13" format="counter" sectionFormat="of" target="section-5.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-consent-to-nomination">Consent to Nomination</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.14">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.14.1"><xref derivedContent="5.14" format="counter" sectionFormat="of" target="section-5.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-notifying-confirming-bodies">Notifying Confirming Bodies</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.15">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.15.1"><xref derivedContent="5.15" format="counter" sectionFormat="of" target="section-5.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-confirming-candidates">Confirming Candidates</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.16">
                <t keepWithNext="true" pn="section-toc.1-1.5.2.16.1"><xref derivedContent="5.16" format="counter" sectionFormat="of" target="section-5.16"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-archives">Archives</xref></t>
              </li>
            </ul>
          </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-dispute-resolution-process">Dispute Resolution Process</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-member-trustee-and-director">Member, Trustee, or IETF
				LLC and Director may be questioned, perhaps
				resulting in the removal of the sitting
				member. See <xref target="defs"/> for a description of
				what Recall</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-petition">Petition</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-community-petition">Community Petition</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.2.1"><xref derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ombudsteam-petition">Ombudsteam Petition</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recall-committee-chair">Recall Committee Chair</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recall-committee-creation">Recall Committee Creation</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recall-committee-rules">Recall Committee Rules</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recall-committee-operation">Recall Committee Operation</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-3-4-majority">3/4 Majority</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-position-to-be-filled">Position to Be Filled</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <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.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-3777">Changes Since RFC 3777</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-since-rfc-7437">Changes Since RFC 7437</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedContent="Appendix C" format="default" sectionFormat="of" target="section-appendix.c"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-oral-tradition">Oral Tradition</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedContent="Appendix D" format="default" sectionFormat="of" target="section-appendix.d"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-nominating-committee-timeli">Nominating Committee Timeline</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.f"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</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"> This document is a sitting member means for each revision of these groups. </t>

        </list> </t>

		<t> A final section describes how this document differs from <xref target="RFC3777"/>
			and <xref target="RFC7437"/>. </t>

		<t> An appendix of useful facts and practices collected from
		previous NomComs is also included. </t>

     <t>
       This document target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> that
	updates the IAB, IESG, and IAOC Selection, Confirmation, and Recall Process it to be
       aligned consistent with IASA the
        IETF Administrative Support Activity (IASA) 2.0 Model changes.  RFC 7437
	was based on <xref target="I-D.ietf-iasa2-rfc4071bis"/> target="RFC3777" format="default" sectionFormat="of" derivedContent="RFC3777"/> that creates consolidated and updated
	other RFCs that updated that document into a IETF Administration Limited Liability Company
      ("IETF LLC") managed by single
	specification.  The result is a complete specification of the
	process by which members of the Internet Architecture Board (IAB)
	and Internet Engineering Steering Group (IESG), some Trustees of
	the IETF Trust, and some Directors ("IETF of the IETF Administration LLC Board").

     This document obsoletes <xref target="RFC7437"/> and <xref target="RFC8318"/>.</t>

	</section>

	<section anchor="defs" title="Definitions">
		<t> The following words and phrases
	(IETF LLC), are commonly used
		    throughout this document.  They are listed here with
		    their intended meaning for selected, confirmed, and recalled. </t>
      <t pn="section-1-2">This revision addresses only the convenience of changes required for IASA
	2.0; should the
		    reader.

		    <list style="hanging">
			<t hangText="Candidate:"> A nominee who has been
				selected to community agree on other changes, they will be considered for confirmation by
				a confirming body. </t>
	addressed in future documents.</t>
      <t hangText="Confirmed Candidate:"> A candidate pn="section-1-3"><xref target="RFC8714" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8714#section-2" derivedContent="RFC8714"/>
	provides further details about the IETF Trust Trustees
	positions that
				has been reviewed and approved by a
				confirming body. </t>

			<t hangText="Nominating Committee Term:"> The term
				begins when its members are officially
				announced, which is expected to be prior to filled by the Third IETF to ensure it is fully
				operational at the Third IETF.  The term ends
				at Nominating Committee
	(NomCom). </t>
      <t pn="section-1-4"><xref target="RFC8711" section="5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8711#section-5" derivedContent="RFC8711"/>
	provides further details about the Third IETF (not three meetings) after LLC Director
	positions that are filled by the next NomCom's term
				begins. NomCom. </t>
      <t hangText="IETF Executive Director:"> pn="section-1-5">The following two assumptions continue to be true of this specification:
      </t>
      <ol spacing="normal" type="1" start="1" pn="section-1-6">
        <li pn="section-1-6.1" derivedCounter="1."> The person
				charged with day-to-day operation Internet Research Task Force (IRTF) and
			    Internet Research Steering Group (IRSG) are not a
			    part of the IETF's
				administrative functions.  (See Section 4.1 process described here. </li>
        <li pn="section-1-6.2" derivedCounter="2."> The organization (and reorganization) of
				<xref target="I-D.ietf-iasa2-rfc4071bis"/>).
			        Note:  This was previously the name IESG
			    is not a part of the process described here. </li>
      </ol>
      <t pn="section-1-7"> The time frames specified here use IETF Secretariat position meetings as
		    a frame of reference.  The time frames assume that is
				now called the "Managing Director, IETF
				Secretariat".</t>

			<t hangText="Managing Director,
		    IETF Secretariat:">
			        The person charged meets three times per calendar year with
			        operation
		    approximately equal amounts of time between them.  The
		    meetings are referred to as the First IETF, Second IETF,
		    or Third IETF Secretariat function.  (See
			        Section 2 of <xref target="RFC3710"/> and
			        <xref target="I-D.ietf-iasa2-consolidated-upd"/>).</t>

			<t hangText="Nominee:"> A person who is being or
			has been considered for one or more open
			positions of the IESG, IAB, IETF Trust Trustee or
			IETF LLC. as needed. </t>
      <t hangText="Sitting Member:"> A person who is
			currently serving as a member of the IESG or IAB.
                         <!--
			, or as a Trustee for pn="section-1-8"> The next section lists the Internet Society
                        --> words and phrases commonly used
		    throughout this document with their intended meaning. </t>
      <t hangText="Sitting Director:"> A person who pn="section-1-9"> The majority of this document is
			currently serving divided into four major
		    topics as a Director of the
			IETF LLC. follows:

      </t>

                        <t hangText="Sitting IETF Trust Trustee:"> A person who
      <dl newline="false" spacing="normal" pn="section-1-10">
        <dt pn="section-1-10.1">General:</dt>
        <dd pn="section-1-10.2"> This is
			currently serving as a Trustee of the IETF
			Trust.</t>

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

	<section anchor="general" title="General">
		<t> The following set of rules and
				constraints that apply to the selection and
				confirmation process as a whole.  If necessary, a paragraph discussing the
		    interpretation of each rule </dd>
        <dt pn="section-1-10.3">Nominating Committee Selection:</dt>
        <dd pn="section-1-10.4"> This
				is included. </t>

		<section anchor="gen_completion" title="Completion Due">
			<t> The completion of the annual process is due
			    within seven months. </t>

			<t> The completion of by which the annual process volunteers who
				will serve on the NomCom are
				selected. </dd>
        <dt pn="section-1-10.5">Nominating Committee Operation:</dt>
        <dd pn="section-1-10.6"> This
				is due
			    one month prior to the Friday set of principles, rules, and
				constraints that guide the week
			    before the First IETF.  It is expected to begin
			    at least eight months prior to the Friday activities of
				the
			    week before NomCom, including the
				confirmation process. </dd>
        <dt pn="section-1-10.7">Member, Trustee, and Director Recall:</dt>
        <dd pn="section-1-10.8"> This is the First IETF. </t>

			<t> The process officially begins with by
				which the
			    announcement behavior of a sitting member of the Chair
				IESG, or IAB, or IETF Trust Trustee, or IETF
				LLC Director may be questioned, perhaps
				resulting in the removal of the committee.
			    The process officially ends when all confirmed
			    candidates have been announced. </t>

			<t> The annual process is comprised of three major
			    components as follows:

			    <list style="numbers">
				<t> The selection and organization sitting
				member. See <xref target="defs" format="default" sectionFormat="of" derivedContent="Section 2"/> for a description of the
				    NomCom members. </t>

				<t> The selection
				what a sitting member means for each of candidates by the
				    NomCom. these groups. </dd>
      </dl>
      <t pn="section-1-11"> A final section describes how this document differs from <xref target="RFC3777" format="default" sectionFormat="of" derivedContent="RFC3777"/>
			and <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/>. </t>

				<t> The confirmation
      <t pn="section-1-12"> An appendix of the candidates. </t>
			    </list> </t>

			<t> There useful facts and practices collected from
		previous NomComs is an additional month set aside between
			    when also included. </t>
      <t pn="section-1-13">
       This document updates the annual process is expected to end IAB, IESG, and
			    the term of the new candidates is IAOC Selection, Confirmation, and Recall Process
       to begin.  This
			    time may be
       aligned with IASA 2.0 Model <xref target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>
      that creates an IETF Administration Limited Liability Company
      (IETF LLC) managed by a Board of Directors (IETF LLC Board).

     This document obsoletes <xref target="RFC7437" format="default" sectionFormat="of" derivedContent="RFC7437"/> and <xref target="RFC8318" format="default" sectionFormat="of" derivedContent="RFC8318"/>.</t>
    </section>
    <section anchor="defs" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-definitions">Definitions</name>
      <t pn="section-2-1"> The following words and phrases are commonly used during unusual circumstances to
			    extend the time allocated
		    throughout this document.  They are listed here with
		    their intended meaning for any the convenience of the
			    components listed above.
		    reader.

      </t>
		</section>

		<section anchor="gen_func"
		         title="Nominating
      <dl newline="false" spacing="normal" pn="section-2-2">
        <dt pn="section-2-2.1">Candidate:</dt>
        <dd pn="section-2-2.2"> A nominee who has been
				selected to be considered for confirmation by
				a confirming body. </dd>
        <dt pn="section-2-2.3">Confirmed Candidate:</dt>
        <dd pn="section-2-2.4"> A candidate that
				has been reviewed and approved by a
				confirming body. </dd>
        <dt pn="section-2-2.5">Nominating Committee Principal Functions">

			<t> Term:</dt>
        <dd pn="section-2-2.6"> The principal functions of the NomCom term
				begins when its members are officially
				announced, which is expected to
			review each open IESG, IAB, IETF Trust, and be prior to
				the Third IETF LLC Director position
			and to select either its incumbent or a
			superior candidate. </t>

<!--
			<t> Although there ensure it is no term limit for serving in
			    any IESG, IAB, IETF Trust, or fully
				operational at the Third IETF.  The term ends
				at the Third IETF LLC Board position, (not three meetings) after
				the NomCom
			    may use length next NomCom's term
				begins. </dd>
        <dt pn="section-2-2.7">IETF Executive Director:</dt>
        <dd pn="section-2-2.8"> The person
				charged with day-to-day operation of service as one the IETF's
				administrative functions.  (See
				<xref target="RFC8711" section="4.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8711#section-4.1" derivedContent="RFC8711"/>).
			        Note:  This was previously the name of its
			    criteria for evaluating an incumbent. </t>
-->

                        <t>Although there
				the IETF Secretariat position that is no term limit
				now called the "Managing Director, IETF
				Secretariat".</dd>
        <dt pn="section-2-2.9">Managing Director, IETF Secretariat:</dt>
        <dd pn="section-2-2.10">
			        The person charged with
			        operation of the IETF Secretariat function.  (See
			        <xref target="RFC3710" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3710#section-2" derivedContent="RFC3710"/> and
			        <xref target="RFC8717" format="default" sectionFormat="of" derivedContent="RFC8717"/>).</dd>
        <dt pn="section-2-2.11">Nominee:</dt>
        <dd pn="section-2-2.12"> A person who is being or
			has been considered for serving in any one or more open
			positions of the IESG, IAB, or IETF Trust position, the NomCom may use length Trustee, or
			IETF LLC. </dd>
        <dt pn="section-2-2.13">Sitting Member:</dt>
        <dd pn="section-2-2.14"> A person who is
			currently serving as a member of service the IESG or IAB.
			</dd>
        <dt pn="section-2-2.15">Sitting Director:</dt>
        <dd pn="section-2-2.16"> A person who is
			currently serving as
                           one a Director of its criteria for evaluating an incumbent.</t>

			<t> The NomCom does not select the
			    open positions to be reviewed; it
			IETF LLC. </dd>
        <dt pn="section-2-2.17">Sitting IETF Trust Trustee:</dt>
        <dd pn="section-2-2.18"> A person who is instructed
			currently serving as a Trustee of the IETF
			Trust.</dd>
      </dl>
    </section>
    <section anchor="general" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-general">General</name>
      <t pn="section-3-1"> The following set of rules apply to which positions to review. the process as a
		    whole.  If necessary, a paragraph discussing the
		    interpretation of each rule is included. </t>

			<t>
      <section anchor="gen_completion" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-completion-due">Completion Due</name>
        <t pn="section-3.1-1"> The NomCom will be given completion of the titles annual process is due
			    within seven months. </t>
        <t pn="section-3.1-2"> The completion of the positions annual process is due
			    one month prior to be reviewed and a brief
			    summary of the desired expertise Friday of the candidate
			    that week
			    before the First IETF.  It is selected expected to begin
			    at least eight months prior to the Friday of the
			    week before the First IETF. </t>
        <t pn="section-3.1-3"> The process officially begins with the
			    announcement of the Chair of the committee.
			    The process officially ends when all confirmed
			    candidates have been announced. </t>
        <t pn="section-3.1-4"> The annual process is comprised of three major
			    components as follows:

        </t>
        <ol spacing="normal" type="1" start="1" pn="section-3.1-5">
          <li pn="section-3.1-5.1" derivedCounter="1."> The selection and organization of the
				    NomCom members. </li>
          <li pn="section-3.1-5.2" derivedCounter="2."> The selection of candidates by the
				    NomCom. </li>
          <li pn="section-3.1-5.3" derivedCounter="3."> The confirmation of the candidates. </li>
        </ol>
        <t pn="section-3.1-6"> There is an additional month set aside between
			    when the annual process is expected to end and
			    the term of the new candidates is to begin.  This
			    time may be used during unusual circumstances to
			    extend the time allocated for any of the
			    components listed above. </t>
      </section>
      <section anchor="gen_func" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-nominating-committee-princi">Nominating Committee Principal Functions</name>
        <t pn="section-3.2-1"> The principal functions of the NomCom are to
			review each open IESG, IAB, IETF Trust, and IETF LLC Director position
			and to select either its incumbent or a
			superior candidate. </t>
        <t pn="section-3.2-2">Although there is no term limit for serving in any IESG, IAB, or IETF
                           Trust position, the NomCom may use length of service as
                           one of its criteria for evaluating an incumbent.</t>
        <t pn="section-3.2-3"> The NomCom does not select the
			    open positions to be reviewed; it is instructed
			    as to which positions to review. </t>
        <t pn="section-3.2-4"> The NomCom will be given the titles
			    of the positions to be reviewed and a brief
			    summary of the desired expertise of the candidate
			    that is selected to fill each position. </t>

			<t>
        <t pn="section-3.2-5"> Incumbents must notify the NomCom
			    if they wish to be nominated. </t>

			<t>
        <t pn="section-3.2-6"> The NomCom does not confirm its
			    candidates; it presents its candidates to the
			    appropriate confirming body as indicated
			    below. </t>

			<t>
        <t pn="section-3.2-7"> A superior candidate is one who the
			    NomCom believes would contribute in such a
			    way as to improve or enhance the body to which
			    he or she is nominated. </t>
      </section>
      <section anchor="gen_positions"
		         title="Positions To numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-positions-to-be-reviewed">Positions to Be Reviewed">

		        <t>Approximately Reviewed</name>
        <t pn="section-3.3-1">Approximately one-half of each of the then
		        current IESG and IAB positions, one IETF Trust
		        position, and one IETF LLC Director position, is selected
		        to be reviewed each year.</t>

			<t>
        <t pn="section-3.3-2"> The intent of this rule is to ensure the
			review of approximately one-half of each of the
			IESG and IAB sitting members, one of the three
			NomCom nominated
			NomCom-nominated IETF LLC Director
			positions, and one of the three nominated IETF Trust
			Trustee positions, each year.  It is recognized
			that circumstances may exist that will require
			the NomCom to review more or less
			than the usual number of positions, e.g., if the
			IESG, IAB, IETF Trust, or IETF LLC Board have reorganized prior to
			this process and created new positions, if there
			are an odd number of current positions, or if a
			member, a director, Director, or a trustee Trustee unexpectedly resigns. </t>
      </section>
      <section anchor="gen_terms" title="Term Lengths">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-term-lengths">Term Lengths</name>
        <t pn="section-3.4-1"> Confirmed IESG and IAB candidates are
			expected to serve at least a two-year term. The
			intent of this rule is to ensure that members of
			the IESG and IAB serve the number of years that
			best facilitates the review of one-half of the
			members each year.</t>

			<t>
        <t pn="section-3.4-2"> Confirmed IETF LLC Director candidates
			are expected to serve at least a three-year term,
			except if a nominating or selection body decides
			to use a shorter term to allow for initial
			staggered appointments. Please refer to Section 6
			of
			<xref target="I-D.ietf-iasa2-rfc4071bis"/> target="RFC8711" section="6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8711#section-6" derivedContent="RFC8711"/> for
			additional guidance on term length and term
			limits for the IETF LLC Board. </t>

			<t>Confirmed
        <t pn="section-3.4-3">Confirmed IETF Trust Trustee candidates are expected to
			serve at least a three-year term, except if a
			nominating or selection body decides to use a
			shorter term to allow for initial staggered
			appointments. Please refer to Section 2. of
                        <xref
			target="I-D.ietf-iasa2-trust-update"/> target="RFC8714" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8714#section-2" derivedContent="RFC8714"/>
                        for additional
			guidance on term length and term limits for the
			IETF Trust. </t>

			<t>
        <t pn="section-3.4-4"> The term of a confirmed candidate selected
			according to the mid-term vacancy rules may be
			less than a full term (two years for IESG and
			IAB, three years for the IETF Trust and IETF
			LLC), as stated elsewhere in this document. </t>

			<t>
        <t pn="section-3.4-5"> It is consistent with this rule for the NomCom
			    to choose one or more of the currently
			    open positions to which it may assign a term of
			    not more than three years in order to ensure the
			    ideal application of this rule in the future. </t>

			<t>
        <t pn="section-3.4-6"> It is consistent with this rule for the
			NomCom to choose one or more of the
			currently open positions that share
			responsibilities with other positions (both those
			being reviewed and those sitting) to which it may
			assign a term of not more than three years to
			ensure that all such members, directors, Directors, or trustees Trustees will
			not be reviewed at the same time. </t>

			<t>
        <t pn="section-3.4-7"> All sitting member terms end during the First IETF
			    meeting corresponding to the end of the term for
			    which they were confirmed.  All confirmed
			    candidate terms begin during the First IETF
			    meeting corresponding to the beginning of the term
			    for which they were confirmed. </t>

			<t>
        <t pn="section-3.4-8"> For confirmed candidates of the IESG, the terms
			    begin no later than when the currently sitting
			    members' terms end on the last day of the meeting.
			    A term may begin or end no sooner than the first
			    day of the meeting and no later than the last day
			    of the meeting as determined by the mutual
			    agreement of the currently sitting member and the
			    confirmed candidate.  A confirmed candidate's term
			    may overlap the sitting member's term during the
			    meeting as determined by their mutual
			    agreement. </t>

			<t>
        <t pn="section-3.4-9"> For confirmed candidates of the IAB, the
			    terms overlap with the terms of the sitting
			    members for the entire week of the meeting. </t>

			<t>
        <t pn="section-3.4-10"> For confirmed Trustee candidates of the IETF
			Trust, the term begins at the next IETF Trust
			meeting or as dictated by the policies and
			procedures of the IETF Trust. </t>

			<t>
        <t pn="section-3.4-11"> For confirmed Director candidates of the IETF
			LLC, the term begins at the next appropriate IETF
			LLC Board meeting or as dictated by the policies
			and procedures of the IETF LLC Board. </t>

			<t>
        <t pn="section-3.4-12"> For candidates confirmed under the mid-term
			    vacancy rules, the term begins as soon as possible
			    after the confirmation. </t>
      </section>
      <section anchor="gen_vacancies" title="Mid-term Vacancies">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-mid-term-vacancies">Mid-term Vacancies</name>
        <t pn="section-3.5-1"> Mid-term vacancies are filled by the same rules
			    as documented here with four qualifications,
			    namely:

			    <list style="numbers">
				<t>

        </t>
        <ol spacing="normal" type="1" start="1" pn="section-3.5-2">
          <li pn="section-3.5-2.1" derivedCounter="1."> When there is only one official NomCom,
				    the body with the mid-term
				    vacancy relegates the responsibility to
				    fill the vacancy to it.  If the mid-term
				    vacancy occurs during the period of time
				    that the term of the prior year's
				    NomCom overlaps with the
				    term of the current year's
				    NomCom, the body with the mid-term
				    vacancy must relegate the responsibility
				    to fill the vacancy to the prior year's
				    NomCom. </t>

				<t> </li>
          <li pn="section-3.5-2.2" derivedCounter="2."> If it is the case that the NomCom
				    is reconvening to fill the
				    mid-term vacancy, then the completion of
				    the candidate selection and confirmation
				    process is due within six weeks, with all
				    other time periods otherwise unspecified
				    prorated accordingly. </t>

				<t> </li>
          <li pn="section-3.5-2.3" derivedCounter="3."> The confirming body has two weeks from the
				    day it is notified of a candidate to
				    reject the candidate, otherwise the
				    candidate is assumed to have been
				    confirmed. </t>

				<t> </li>
          <li pn="section-3.5-2.4" derivedCounter="4.">
            <t pn="section-3.5-2.4.1"> The term of the confirmed candidate will
				    be either:

			    <list style="letters">
				<t>

            </t>
            <ol spacing="normal" type="A" start="1" pn="section-3.5-2.4.2">
              <li pn="section-3.5-2.4.2.1" derivedCounter="A."> the remainder of the term of the
				    open position if that remainder
				    is not less than one year or </t>

				<t> </li>
              <li pn="section-3.5-2.4.2.2" derivedCounter="B."> the remainder of the term of the open
				position plus the next two-year term for
				IESG and IAB positions or three-year term
				for IETF LLC Director and IETF Trust
				positions if that remainder is less than
				one year.</t>

 			        </list> </t>
			        </list> </t>

			<t> year.</li>
            </ol>
          </li>
        </ol>
        <t pn="section-3.5-3"> In both cases, a year is the period of time from a
			    First IETF meeting to the next First IETF
			    meeting. </t>
      </section>
      <section anchor="gen_confidential" title="Confidentiality">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-confidentiality">Confidentiality</name>
        <t pn="section-3.6-1"> All deliberations and supporting information that
			    relates
			    relate to specific nominees, candidates, and
			    confirmed candidates are confidential. </t>

			<t>
        <t pn="section-3.6-2"> The NomCom and confirming body
			    members will be exposed to confidential
			    information as a result of their deliberations,
			    their interactions with those they consult, and
			    from those who provide requested supporting
			    information.  All members and all other
			    participants are expected to handle this
			    information in a manner consistent with its
			    sensitivity. </t>

			<t>
        <t pn="section-3.6-3"> It is consistent with this rule for current
			    NomCom members who have served on
			    prior NomComs to advise the current
			    committee on deliberations and results of the
			    prior committee, as necessary and appropriate. </t>

			<t>
        <t pn="section-3.6-4"> The list of nominees willing to be considered for
			    positions under review in the current NomCom
			    cycle is not confidential.  The NomCom
			    may disclose a list of names of nominees
			    who are willing to be considered for positions under
			    review to the community, in order to obtain feedback
			    from the community on these nominees. </t>

			<t>
        <t pn="section-3.6-5"> The list of nominees disclosed for a specific
			    position should contain only the names of nominees
			    who are willing to be considered for the position
			    under review. </t>

			<t>
        <t pn="section-3.6-6"> The NomCom may choose not to include
			    some names in the disclosed list, at their
			    discretion. </t>

			<t>
        <t pn="section-3.6-7"> The NomCom may disclose an updated
			    list, at its discretion.  For example, the
			    NomCom might disclose an updated list
			    if it identifies errors/omissions in a previously
			    disclosed version of the disclosed list, or if the
			    NomCom finds it necessary to call for
			    additional nominees, and these nominees indicate a
			    willingness to be considered before the NomCom
			    has completed its deliberations. </t>

			<t>
        <t pn="section-3.6-8"> Nominees may choose to ask people to provide
			    feedback to the NomCom but should
			    not encourage any public statements of support.
			    NomComs should consider
			    nominee-encouraged lobbying and campaigning to be
			    unacceptable behavior. </t>

			<t>
        <t pn="section-3.6-9"> IETF community members are encouraged to provide
			    feedback on nominees to the NomCom
			    but should not post statements of support/non-support
			    for nominees in any public forum. </t>
      </section>
      <section anchor="gen_model" title="Advice numbered="true" toc="include" removeInRFC="false" pn="section-3.7">
        <name slugifiedName="name-advice-and-consent-model">Advice and Consent Model">
			<t> Model</name>
        <t pn="section-3.7-1"> Unless otherwise specified, the advice and
			    consent model is used throughout the process.
			    This model is characterized as follows. </t>
        <section anchor="gen_model_1"
			         title="Positions To numbered="true" toc="include" removeInRFC="false" pn="section-3.7.1">
          <name slugifiedName="name-positions-to-be-reviewed-2">Positions to Be Reviewed">

				<t> Reviewed</name>
          <t pn="section-3.7.1-1"> The chair Chairs of the IESG, IAB, IETF
				Trust
				Trust, and IETF LLC Board each informs the
				NomCom of their respective
				positions to be reviewed. </t>

				<t>
          <t pn="section-3.7.1-2"> The IESG, IAB, IETF Trust Trust, and IETF
				LLC are responsible for providing a
				summary of the expertise desired of the
				candidates selected for their respective
				open positions. The summaries are
				provided to the NomCom for
				its consideration. </t>
        </section>
        <section anchor="gen_model_2"
			         title="Candidate Selection">
				<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.7.2">
          <name slugifiedName="name-candidate-selection">Candidate Selection</name>
          <t pn="section-3.7.2-1"> The NomCom selects
				    candidates based on its understanding of
				    the IETF community's consensus of the
				    qualifications required and advises each
				    confirming body of its respective
				    candidates. </t>
        </section>
        <section anchor="gen_model_3" title="Candidate Review">
				<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.7.3">
          <name slugifiedName="name-candidate-review">Candidate Review</name>
          <t pn="section-3.7.3-1"> The confirming bodies review their
				    respective candidates, candidates; they may at their
				    discretion communicate with the NomCom,
				    and then consent to some, all,
				    or none of the candidates. </t>

				<t>
          <t pn="section-3.7.3-2"> The sitting IAB members review the IESG
				    candidates. </t>

				<t>
          <t pn="section-3.7.3-3"> The Internet Society Board of Trustees
				reviews the IAB candidates. </t>

				<t>The
          <t pn="section-3.7.3-4">The sitting IESG members review the
				IETF Trust Trustee candidates.</t>

				<t>
          <t pn="section-3.7.3-5"> The IETF LLC Director candidate is reviewed as
				    specified in <xref target="I-D.ietf-iasa2-rfc4071bis"/>. target="RFC8711" format="default" sectionFormat="of" derivedContent="RFC8711"/>. </t>

				<t>
          <t pn="section-3.7.3-6"> The confirming bodies conduct their review reviews
				    using all information and any means
				    acceptable to them, including but not
				    limited to the supporting information
				    provided by the NomCom,
				    information known personally to members of
				    the confirming bodies and shared within
				    the confirming body, the results of
				    interactions within the confirming bodies,
				    and the confirming bodies' interpretation
				    of what is in the best interests of the
				    IETF community. </t>

				<t>
          <t pn="section-3.7.3-7"> If all of the candidates are confirmed,
				    the job of the NomCom with
				    respect to those open positions is
				    complete. </t>

				<t>
          <t pn="section-3.7.3-8"> If some or none of the candidates
				    submitted to a confirming body are
				    confirmed, the confirming body should
				    communicate with the NomCom
				    both to explain the reason why all the
				    candidates were not confirmed and to
				    understand the NomCom's
				    rationale for its candidates. </t>

				<t>
          <t pn="section-3.7.3-9"> The confirming body may reject individual
				    candidates, in which case the NomCom
				    must select alternate candidates
				    for the rejected candidates. </t>

				<t>
          <t pn="section-3.7.3-10"> Any additional time required by the
				    NomCom should not exceed its
				    maximum time allotment. </t>
        </section>
        <section anchor="gen_model_4" title="Confirmation">
				<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.7.4">
          <name slugifiedName="name-confirmation">Confirmation</name>
          <t pn="section-3.7.4-1"> A confirming body decides whether it
				    confirms each candidate using a
				    confirmation decision rule chosen by the
				    confirming body. </t>

				<t>
          <t pn="section-3.7.4-2"> If a confirming body has no specific
				    confirmation decision rule, then
				    confirming a given candidate should
				    require at least one-half of the
				    confirming body's sitting members to
				    agree to that confirmation. </t>

				<t>
          <t pn="section-3.7.4-3"> The decision may be made by conducting a
				    formal vote, by asserting consensus based
				    on informal exchanges (e.g., email), or
				    by any other mechanism that is used to
				    conduct the normal business of the
				    confirming body. </t>

				<t>
          <t pn="section-3.7.4-4"> Regardless of which decision rule the
				    confirming body uses, any candidate that
				    is not confirmed under that rule is
				    considered to be rejected. </t>

				<t>
          <t pn="section-3.7.4-5"> The confirming body must make its decision
				    within a reasonable time frame.  The
				    results from the confirming body must be
				    reported promptly to the NomCom.</t>
        </section>
      </section>
      <section anchor="gen_sitting" title="Sitting numbered="true" toc="include" removeInRFC="false" pn="section-3.8">
        <name slugifiedName="name-sitting-members-directors-a">Sitting Members,
						     Directors Directors, and Trustees">
			<t> Trustees</name>
        <t pn="section-3.8-1"> The following rules apply to nominees and
			candidates who are currently sitting members of
			the IESG or IAB,
                       IETF Trust Trustees,
                       or IETF LLC Directors Directors, and who are not sitting in an open
			position being filled by the NomCom. </t>

			<t>
        <t pn="section-3.8-2"> The confirmation of a candidate to an open
			position does not automatically create a vacancy
			in the IESG, IAB, IETF Trust, or IETF LLC Board
			position currently occupied by the candidate.
			The mid-term vacancy cannot exist until, first,
			the candidate formally resigns from the current
			position and, second, the body with the vacancy
			formally decides for itself that it wants the
			NomCom to fill the mid-term vacancy according to
			the rules for a mid-term vacancy documented
			elsewhere in this document. </t>

			<t>
        <t pn="section-3.8-3"> The resignation should be effective as of when
			    the term of the new position begins.  The
			    resignation may remain confidential to the IESG,
			    IAB, IETF Trust, IETF LLC Board, and NomCom until the
			    confirmed candidate is announced for the new
			    position.  The process, according to rules set out
			    elsewhere in this document, of filling the seat
			    vacated by the confirmed candidate may begin as
			    soon as the vacancy is publicly announced. </t>

			<t>
        <t pn="section-3.8-4"> Filling a mid-term vacancy is a separate and
			    independent action from the customary action of
			    filling open positions.  In particular, a
			    NomCom must complete its job with
			    respect to filling the open positions and then
			    separately proceed with the task of filling the
			    mid-term vacancy according to the rules for a
			    mid-term vacancy documented elsewhere in this
			    document. </t>

			<t>
        <t pn="section-3.8-5"> However, the following exception is permitted in
			    the case where the candidate for an open position
			    is currently a sitting member of the IAB.  It is
			    consistent with these rules for the announcements
			    of a resignation of a sitting member of the IAB
			    and of the confirmed candidate for the mid-term
			    vacancy created by that sitting member on the IAB
			    to all occur at the same time as long as the
			    actual sequence of events that occurred did so in
			    the following order:

			    <list style="numbers">
				<t>

        </t>
        <ol spacing="normal" type="1" start="1" pn="section-3.8-6">
          <li pn="section-3.8-6.1" derivedCounter="1."> The NomCom completes the
				    advice and consent process for the open
				    position being filled by the candidate
				    currently sitting on the IAB. </t>

				<t> </li>
          <li pn="section-3.8-6.2" derivedCounter="2."> The newly confirmed candidate resigns
				    from their current position on the
				    IAB. </t>

<!--
				<t> The IAB with the new mid-term vacancy
				    requests that the NomCom
				    fill the position. </t>
-->

				<t> </li>
          <li pn="section-3.8-6.3" derivedCounter="3."> The IAB Chair (or the Managing Director,
					IETF Secretariat, if no Chair has been named
					or the vacancy was created via the departure
					of the IAB Chair) informs the NomCom
					of the mid-term vacancy. </t>

				<t> </li>
          <li pn="section-3.8-6.4" derivedCounter="4."> The NomCom acts on the
				    request to fill the mid-term vacancy. </t>
			    </list> </t> </li>
        </ol>
      </section>
      <section anchor="gen_announce" title="Announcements">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-3.9">
        <name slugifiedName="name-announcements">Announcements</name>
        <t pn="section-3.9-1"> All announcements must be made using at least
			    the mechanism used by the IETF Secretariat for
			    its announcements, including a notice on the
			    IETF web site. </t>

			<t>
        <t pn="section-3.9-2"> As of the publication of this document, the
			    current mechanism is an email message to both
			    the "ietf" and the "ietf-announce" mailing
			    lists. </t>
      </section>
    </section>
    <section anchor="selection" title="Nominating numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-nominating-committee-select">Nominating Committee Selection">
		<t> Selection</name>
      <t pn="section-4-1"> The following set of rules apply to the creation of the
		    NomCom and the selection of its members. </t>
      <section anchor="sel_timeline" title="Timeline">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-timeline">Timeline</name>
        <t pn="section-4.1-1"> The completion of the process of selecting and
			    organizing the members of the NomCom
			    is due within three months. </t>

			<t>
        <t pn="section-4.1-2"> The completion of the selection and organization
			    process is due at least one month prior to the
			    Third IETF.  This ensures the NomCom
			    is fully operational and available for interviews
			    and consultation during the Third IETF. </t>
      </section>
      <section anchor="sel_term" title="Term">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-term">Term</name>
        <t pn="section-4.2-1"> The term of a NomCom is expected to
			    be 15 months. </t>

			<t>
        <t pn="section-4.2-2"> It is the intent of this rule that the end of a
			    NomCom's term overlap by
			    approximately three months the beginning of the
			    term of the next NomCom. </t>

			<t>
        <t pn="section-4.2-3"> The term of a NomCom begins when its
			    members are officially announced.  The term ends
			    at the Third IETF (not three meetings), i.e., the
			    IETF meeting after the next NomCom's
			    term begins. </t>

			<t>
        <t pn="section-4.2-4"> A term is expected to begin at least two months
			    prior to the Third IETF to ensure the NomCom
			    has at least one month to get organized
			    before preparing for the Third IETF. </t>

			<t>
        <t pn="section-4.2-5"> A NomCom is expected to complete
			    any work in progress before it is dissolved at
			    the end of its term. </t>

			<t>
        <t pn="section-4.2-6"> During the period of time when the terms of
			the NomComs overlap, all mid-term vacancies are
			to be relegated to the prior year's NomCom.  The
			prior year's NomCom has no other responsibilities
			during the overlap period.  At all times other
			than the overlap period, there is exactly one
			official NomCom and it is responsible for all
			mid-term vacancies. </t>

			<t>
        <t pn="section-4.2-7"> When the prior year's NomCom is filling a
			mid-term vacancy during the period of time that
			the terms overlap, the NomCom NomComs operate
			independently.  However, some coordination is
			needed between them.  Since the prior year's
			Chair is a non-voting advisor to the current
			NomCom, the coordination is expected to be
			straightforward. </t>
      </section>
      <section anchor="sel_structure" title="Structure">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-structure">Structure</name>
        <t pn="section-4.3-1"> The NomCom comprises at least a
			    Chair, 10 voting volunteers, two liaisons,
			    and an advisor. </t>

<!--
			<t> Any committee member may propose the addition
			of an advisor to participate in some or all of
			the deliberations of the committee.  The addition
			must be approved by the committee according to
			its established voting mechanism.  Advisors
			participate as individuals. </t>
-->
			<t>
        <t pn="section-4.3-2"> Any committee member may propose the addition
			of an advisor to participate in some or all of
			the deliberations of the committee.  The addition
			must be approved by the committee according to
			its established voting mechanism.  Advisors
			participate as individuals.</t>

                        <t>Committee
        <t pn="section-4.3-3">Committee members are encouraged to propose
                        the addition of advisor(s) who are
                        knowledgeable about the operations of the IETF
                        Trust and/or IETF LLC Board, whether or not that NomCom
                        is reviewing an IETF Trust Trustee or IETF LLC Director
                        position.  The NomCom may choose to ask
                        the IETF Trust and/or IETF LLC Board to suggest
                        advisors who are knowledgeable about their
                        operations but may select any advisor they vote
                        to approve.</t>

			<t>
        <t pn="section-4.3-4"> Any committee member may propose the addition of a
			    liaison from other unrepresented organizations to
			    participate in some or all of the deliberations of
			    the committee.  The addition must be approved by
			    the committee according to its established voting
			    mechanism.  Liaisons participate as
			    representatives of their respective
			    organizations. </t>

			<t>
        <t pn="section-4.3-5"> The Chair is selected according to rules stated
			    elsewhere in this document. </t>

			<t>
        <t pn="section-4.3-6"> The 10 voting volunteers are selected according
			    to rules stated elsewhere in this document. </t>

			<t>
        <t pn="section-4.3-7"> The IESG and IAB liaisons are selected
			    according to rules stated elsewhere in this
			    document. </t>

			<t>
        <t pn="section-4.3-8"> The Internet Society Board of Trustees may appoint
			    a liaison to the NomCom at its own
			    discretion. </t>

			<t>
        <t pn="section-4.3-9"> The IETF Trust may appoint
			    a liaison to the NomCom at its own
			    discretion. </t>

			<t>
        <t pn="section-4.3-10"> The IETF LLC Board may appoint
			    a liaison to the NomCom at its own
			    discretion. </t>

			<t>
        <t pn="section-4.3-11"> The Chair of the prior year's NomCom
			    serves as an advisor according to rules stated
			    elsewhere in this document. </t>

			<t>
        <t pn="section-4.3-12"> The Chair, liaisons, and advisors do not vote on
			    the selection of candidates.  They do vote on all
			    other issues before the committee unless otherwise
			    specified in this document. </t>
      </section>
      <section anchor="sel_chair_duties" title="Chair Duties">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-chair-duties">Chair Duties</name>
        <t pn="section-4.4-1"> The Chair of the NomCom is
			    responsible for ensuring the NomCom
			    completes its assigned duties in a timely fashion
			    and performs in the best interests of the IETF
			    community. </t>

			<t>
        <t pn="section-4.4-2"> The Chair must be thoroughly familiar with
			the rules and guidance indicated throughout this
			document.  The Chair must ensure the NomCom
			completes its assigned duties in a manner that is
			consistent with this document. </t>

			<t>
        <t pn="section-4.4-3"> The Chair must attest by proclamation at a plenary
			    session of the First IETF that the results of
			    the committee represent its best effort and the
			    best interests of the IETF community. </t>

			<t>
        <t pn="section-4.4-4"> The Chair does not vote on the selection of
			    candidates. </t>
      </section>
      <section anchor="sel_chair_selection" title="Chair Selection">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-chair-selection">Chair Selection</name>
        <t pn="section-4.5-1"> The Internet Society President appoints the
			    Chair, who must meet the same requirements for
			    membership in the NomCom as a
			    voting volunteer. </t>

			<t>
        <t pn="section-4.5-2"> The NomCom Chair must agree to
			    invest the time necessary to ensure that the
			    NomCom completes its assigned duties
			    and to perform in the best interests of the
			    IETF community in that role. </t>

			<t>
        <t pn="section-4.5-3"> The appointment is due no later than the Second
			    IETF meeting to ensure it can be announced during
			    a plenary session at that meeting.  The completion
			    of the appointment is necessary to ensure the
			    annual process can complete at the time specified
			    elsewhere in this document. </t>
      </section>
      <section anchor="sel_chair_temp" title="Temporary Chair">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.6">
        <name slugifiedName="name-temporary-chair">Temporary Chair</name>
        <t pn="section-4.6-1"> A Chair, in consultation with the Internet
			    Society President, may appoint a temporary
			    substitute for the Chair position. </t>

			<t>
        <t pn="section-4.6-2"> There are a variety of ordinary circumstances
			    that may arise from time to time that could
			    result in a Chair being unavailable to oversee
			    the activities of the committee.  The Chair, in
			    consultation with the Internet Society President,
			    may appoint a substitute from a pool comprised of
			    the liaisons currently serving on the committee
			    and the prior year's Chair or designee. </t>

			<t>
        <t pn="section-4.6-3"> Any such appointment must be temporary and does
			    not absolve the Chair of any or all responsibility
			    for ensuring the NomCom completes
			    its assigned duties in a timely fashion. </t>
      </section>
      <section anchor="sel_liaisons_1" title="Liaisons">

			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.7">
        <name slugifiedName="name-liaisons">Liaisons</name>
        <t pn="section-4.7-1"> Liaisons are responsible for ensuring the
			    NomCom in general and the Chair in
			    particular execute their assigned duties in the
			    best interests of the IETF community. </t>

			<t>
        <t pn="section-4.7-2"> Liaisons are expected to represent the views of
			    their respective organizations during the
			    deliberations of the committee.  They should
			    provide information as requested or when they
			    believe it would be helpful to the committee. </t>

			    <t>
        <t pn="section-4.7-3"> Liaisons
<!--
			    from the IESG, IAB, IETF Trust, and
			    IETF LLC Board
-->
			    are expected to provide information to the
			    NomCom regarding the operation,
			    responsibility, and composition of their
			    respective bodies. </t>

			<t>
        <t pn="section-4.7-4"> Liaisons are expected to convey questions from the
			    committee to their respective organizations and
			    responses to those questions to the committee, as
			    requested by the committee. </t>

			    <t>Liaisons
<!--
                            Liaisons from the IESG, IAB, and Internet
			    Society Board of Trustees (if one was appointed)
-->
        <t pn="section-4.7-5">Liaisons
			    are expected to review the operation and executing
			    process of the NomCom and to report
			    any concerns or issues to the Chair of the
			    NomCom immediately.  If they cannot
			    resolve the issue between themselves, liaisons must
			    report it according to the dispute resolution
			    process stated elsewhere in this document. </t>

			<t>
        <t pn="section-4.7-6"> Liaisons from confirming bodies are expected to
			    assist the committee in preparing the testimony it
			    is required to provide with its candidates. </t>

			<t>
        <t pn="section-4.7-7"> Liaisons may have other NomCom
			responsibilities as required by their respective
			organizations or requested by the NomCom, except
			that such responsibilities may not conflict with
			any other provisions of this document. </t>

			<t>
        <t pn="section-4.7-8"> Liaisons do not vote on the selection of
			    candidates. </t>
      </section>
      <section anchor="sel_liaisons_2" title="Liaison Appointment">

<!--
				<t>DISCUSSION
				<list>
                                <t>Should the IETF Trust and IETF LLC appoint a liaisons
				to the NomCom?
				</t>
				</list></t>
-->

			<t> The numbered="true" toc="include" removeInRFC="false" pn="section-4.8">
        <name slugifiedName="name-liaison-appointment">Liaison Appointment</name>
        <t pn="section-4.8-1">The sitting IAB and IESG members each appoint a liaison someone from
   their current membership,
			    someone membership who is not sitting in an open position, position
   to serve on as a liaison to the NomCom. </t>

			<t> NomCom.</t>
        <t pn="section-4.8-2"> The sitting IETF Trust Trustees and IETF LLC
			Directors each may appoint a liaison from their
			current membership, someone who is not sitting in
			an open position, to serve on the NomCom. </t>
      </section>
      <section anchor="sel_advisors" title="Advisors">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.9">
        <name slugifiedName="name-advisors">Advisors</name>
        <t pn="section-4.9-1"> An advisor is responsible for such duties as
			    specified by the invitation that resulted in
			    the appointment. </t>

			<t>
        <t pn="section-4.9-2"> Advisors do not vote on the selection of
			    candidates. </t>
      </section>
      <section anchor="sel_chair_past" title="Past Chair">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.10">
        <name slugifiedName="name-past-chair">Past Chair</name>
        <t pn="section-4.10-1"> The Chair of the prior year's NomCom
			    serves as an advisor to the current committee. </t>

			<t>
        <t pn="section-4.10-2"> The prior year's Chair is expected to review
			the actions and activities of the current Chair
			and to report any concerns or issues to the
			NomCom Chair immediately.  If they cannot
			resolve the issue between themselves, the prior
			year's Chair must report it according to the
			dispute resolution process stated elsewhere in
			this document. </t>

			<t>
        <t pn="section-4.10-3"> The prior year's Chair may select a designee from
			    a pool composed of the voting volunteers of the
			    prior year's committee and all prior Chairs if the
			    Chair is unavailable.  If the prior year's Chair is
			    unavailable or is unable or unwilling to make such a
			    designation in a timely fashion, the Chair of the
			    current year's committee may select a designee in
			    consultation with the Internet Society
			    President. </t>

			<t>
        <t pn="section-4.10-4"> Selecting a prior year's committee member as the
			    designee permits the experience of the prior year's
			    deliberations to be readily available to the current
			    committee.  Selecting an earlier prior year Chair
			    as the designee permits the experience of being a
			    Chair as well as that Chair's committee
			    deliberations to be readily available to the current
			    committee. </t>

			<t>
        <t pn="section-4.10-5"> All references to "prior year's Chair" in this
			    document refer to the person serving in that role,
			    whether it is the actual prior year's Chair or a
			    designee. </t>
      </section>
      <section anchor="sel_volunteers" title="Voting Volunteers">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.11">
        <name slugifiedName="name-voting-volunteers">Voting Volunteers</name>
        <t pn="section-4.11-1"> Voting volunteers are responsible for completing the
			    tasks of the NomCom in a timely
			    fashion. </t>

			<t>
        <t pn="section-4.11-2"> Each voting volunteer is expected to participate in
			    all activities of the NomCom with a
			    level of effort approximately equal to all other
			    voting volunteers.  Specific tasks to be completed
			    are established and managed by the Chair according
			    to rules stated elsewhere in this document. </t>
      </section>
      <section anchor="sel_milestones" title="Milestones">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.12">
        <name slugifiedName="name-milestones">Milestones</name>
        <t pn="section-4.12-1"> The Chair must establish and announce milestones for
			    the selection of the NomCom
			    members. </t>

			<t>
        <t pn="section-4.12-2"> There is a defined time period during which the
			    selection process is due to be completed.  The
			    Chair must establish a set of milestones which,
			    if met in a timely fashion, will result in the
			    completion of the process on time. </t>
      </section>
      <section anchor="sel_positions" title="Open Positions">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.13">
        <name slugifiedName="name-open-positions">Open Positions</name>
        <t pn="section-4.13-1"> The Chair (or the Managing Director, IETF Secretariat, if no
			    Chair has been named four weeks after the First IETF
			    meeting of the year) obtains the list of positions
			    to be reviewed and announces it along with a
			    solicitation for names of volunteers from the IETF
			    community willing to serve on the NomCom.</t>

			<t>
        <t pn="section-4.13-2"> If the Managing Director, IETF Secretariat Secretariat, issues the
			    solicitation for volunteers, the Managing Director, IETF Secretariat Secretariat,
			    must also collect responses to the
			    solicitation and provide the names of volunteers to
			    the incoming NomCom Chair when the
			    incoming NomCom Chair is named. </t>

			<t>
        <t pn="section-4.13-3"> At the Chair's request, the IETF Secretariat may
			    perform other clerical support tasks, as long as
			    the task being performed does not require NomCom
			    Chair judgment, in the NomCom
			    Chair's opinion, and as long as the
			    community is appropriately notified that this
			    request is being made.  This request may come from
			    the incoming NomCom Chair (if one has
			    been selected for this NomCom cycle)
			    or the previous NomCom Chair (if the
			    search for an incoming NomCom Chair is
			    still underway). </t>

			<t>
        <t pn="section-4.13-4"> The solicitation must permit the community at
			    least 30 days during which they may choose to
			    volunteer to be selected for the NomCom.</t>

			<t>
        <t pn="section-4.13-5"> The list of open positions is published with the
			    solicitation to facilitate community members
			    choosing between volunteering for an open position
			    and volunteering for the NomCom. </t>
      </section>
      <section anchor="sel_qualify" title="Volunteer Qualification">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.14">
        <name slugifiedName="name-volunteer-qualification">Volunteer Qualification</name>
        <t pn="section-4.14-1"> Members of the IETF community must have attended at
			    least three of the last five IETF meetings in order
			    to volunteer. </t>

			<t>
        <t pn="section-4.14-2"> The five meetings are the five most recent meetings
			    that ended prior to the date on which the
			    solicitation for NomCom volunteers
			    was submitted for distribution to the IETF
			    community. </t>

			<t>
        <t pn="section-4.14-3"> The IETF Secretariat is responsible for confirming
			    that volunteers have met the attendance
			    requirement. </t>

			<t>
        <t pn="section-4.14-4"> Volunteers must provide their full name, email
			    address, and primary company or organization
			    affiliation (if any) when volunteering. </t>

			<t>
        <t pn="section-4.14-5"> Volunteers are expected to be familiar with the
			    IETF processes and procedures, which are readily
			    learned by active participation in a working group
			    and especially by serving as a document editor
			    or working group chair. </t>
      </section>
      <section anchor="sel_disqualify" title="Not Qualified">

			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.15">
        <name slugifiedName="name-not-qualified">Not Qualified</name>
        <t pn="section-4.15-1"> Any person who serves on the Internet Society
			Board of Trustees, the IETF Trust, the IETF LLC Board of
			Directors, the IAB, or the IESG, including those
			who serve on these bodies in ex officio
			positions, may not volunteer to serve as voting
			members of the NomCom. In addition,
			employees or contractors of the IETF LLC
			may not volunteer to serve as voting members of
			the NomCom.  Liaisons to these
			bodies from other bodies or organizations are not
			excluded by this rule.</t>
      </section>
      <section anchor="sel_process" title="Selection Process">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.16">
        <name slugifiedName="name-selection-process">Selection Process</name>
        <t pn="section-4.16-1"> The Chair announces both the list of the pool
			    of volunteers from which the 10 voting volunteers
			    will be randomly selected and the method with which
			    the selection will be completed. </t>

  			<t>
        <t pn="section-4.16-2"> The announcement should be made at least one week
			    prior to the date on which the random selection will
			    occur.  </t>

			<t>
        <t pn="section-4.16-3"> The pool of volunteers must be enumerated or
			    otherwise indicated according to the needs of the
			    selection method to be used. </t>

			<t>
        <t pn="section-4.16-4"> The announcement must specify the data that will be
			    used as input to the selection method.  The method
			    must depend on random data whose value is not
			    known or available until the date on which the
			    random selection will occur. </t>

			<t>
        <t pn="section-4.16-5"> It must be possible to independently verify that
			    the selection method used is both fair and
			    unbiased.  A method is fair if each eligible
			    volunteer is equally likely to be selected.  A
			    method is unbiased if no one can influence its
			    outcome in favor of a specific outcome. </t>

			<t>
        <t pn="section-4.16-6"> It must be possible to repeat the selection method,
			    either through iteration or by restarting in such a
			    way as to remain fair and unbiased.  This is
			    necessary to replace selected volunteers should they
			    become unavailable after selection. </t>

			<t>
        <t pn="section-4.16-7"> The selection method must produce an ordered list
			    of volunteers. </t>

			<t>
        <t pn="section-4.16-8"> One possible selection method is described in
			    <xref target="RFC3797"/>. target="RFC3797" format="default" sectionFormat="of" derivedContent="RFC3797"/>. </t>
      </section>
      <section anchor="sel_announce"
		         title="Announcement numbered="true" toc="include" removeInRFC="false" pn="section-4.17">
        <name slugifiedName="name-announcement-of-selection-r">Announcement of Selection Results">
			<t> Results</name>
        <t pn="section-4.17-1"> The Chair randomly selects the 10 voting
			    volunteers from the pool of names of volunteers and
			    announces the members of the NomCom.</t>

			<t>
        <t pn="section-4.17-2"> No more than two volunteers with the same
			primary affiliation may be selected for the
			NomCom.  The Chair reviews the primary
			affiliation of each volunteer selected by the
			method in turn.  If the primary affiliation for a
			volunteer is the same as two previously selected
			volunteers, that volunteer is removed from
			consideration and the method is repeated to
			identify the next eligible volunteer. </t>

			<t>
        <t pn="section-4.17-3"> There must be at least two announcements of all
			    members of the NomCom. </t>

			<t>
        <t pn="section-4.17-4"> The first announcement should occur as soon after
			    the random selection as is reasonable for the
			    Chair.  The community must have at least one week
			    during which any member may challenge the results of
			    the random selection. </t>

			<t>
        <t pn="section-4.17-5"> The challenge must be made in writing (email is
			    acceptable) to the Chair.  The Chair has 48 hours to
			    review the challenge and offer a resolution to the
			    member.  If the resolution is not accepted by the
			    member, that member may report the challenge
			    according to the dispute resolution process stated
			    elsewhere in this document. </t>

			<t>
        <t pn="section-4.17-6"> If a selected volunteer, upon reading the
			    announcement with the list of selected volunteers,
			    finds that two or more other volunteers have the
			    same affiliation, then the volunteer should notify
			    the Chair who will determine the appropriate
			    action. </t>

			<t>
        <t pn="section-4.17-7"> During at least the one week challenge period, the
			    Chair must contact each of the members and confirm
			    their willingness and availability to serve.  The
			    Chair should make every reasonable effort to contact
			    each member.

			    <list style="symbols">
				<t>

        </t>
        <ul spacing="normal" bare="false" empty="false" pn="section-4.17-8">
          <li pn="section-4.17-8.1"> If the Chair is unable to contact a liaison,
				    the problem is referred to the respective
				    organization to resolve.  The Chair should
				    allow a reasonable amount of time for the
				    organization to resolve the problem and then
				    may proceed without the liaison. </t>

				<t> </li>
          <li pn="section-4.17-8.2"> If the Chair is unable to contact an advisor,
				    the Chair may elect to proceed without the
				    advisor, except for the prior year's Chair
				    for whom the Chair must consult with the
				    Internet Society President as stated
				    elsewhere in this document. </t>

				<t> </li>
          <li pn="section-4.17-8.3"> If the Chair is unable to contact a voting
				    volunteer, the Chair must repeat the random
				    selection process in order to replace the
				    unavailable volunteer.  There should be at
				    least one day between the announcement of
				    the iteration and the selection process. </t>
			    </list> </t>

			<t> </li>
        </ul>
        <t pn="section-4.17-9"> After at least one week and confirming that 10
			    voting volunteers are ready to serve, the Chair
			    makes the second announcement of the members of the
			    NomCom, which officially begins the
			    term of the NomCom. </t>
      </section>
      <section anchor="sel_organize"
		         title="Committee Organization">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-4.18">
        <name slugifiedName="name-committee-organization">Committee Organization</name>
        <t pn="section-4.18-1"> The Chair works with the members of the committee to
			    organize itself in preparation for completing its
			    assigned duties. </t>

			<t>
        <t pn="section-4.18-2"> The committee has approximately one month during
			    which it can self-organize.  Its responsibilities
			    during this time include but are not limited to the
			    following:

			    <list style="symbols">
				<t>

        </t>
        <ul spacing="normal" bare="false" empty="false" pn="section-4.18-3">
          <li pn="section-4.18-3.1"> Setting up a regular teleconference
				    schedule. </t>

				<t> </li>
          <li pn="section-4.18-3.2"> Setting up an internal web site. </t>

				<t> </li>
          <li pn="section-4.18-3.3"> Setting up a mailing list for internal
				    discussions. </t>

				<t> </li>
          <li pn="section-4.18-3.4"> Setting up an email address for receiving
				    community input. </t>

				<t> </li>
          <li pn="section-4.18-3.5"> Establishing operational procedures. </t>

				<t> </li>
          <li pn="section-4.18-3.6"> Establishing milestones in order to monitor
				    the progress of the selection process. </t>
			    </list> </t> </li>
        </ul>
      </section>
    </section>
    <section anchor="operation" title="Nominating numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-nominating-committee-operat">Nominating Committee Operation">
		<t> Operation</name>
      <t pn="section-5-1"> The following rules apply to the operation of the
		    NomCom.  If necessary, a paragraph
		    discussing the interpretation of each rule is
		    included. </t>

		<t>
      <t pn="section-5-2"> The rules are organized approximately in the order
		    in which they would be invoked. </t>
      <section anchor="op_discretion" title="Discretion">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-discretion">Discretion</name>
        <t pn="section-5.1-1"> All rules and special circumstances not otherwise
			    specified are at the discretion of the
			    committee. </t>

			<t>
        <t pn="section-5.1-2"> Exceptional circumstances will occasionally arise
			    during the normal operation of the NomCom.
			    This rule is intended to foster the
			    continued forward progress of the committee. </t>

			<t>
        <t pn="section-5.1-3"> Any member of the committee may propose a rule for
			    adoption by the committee.  The rule must be
			    approved by the committee according to its
			    established voting mechanism. </t>

			<t>
        <t pn="section-5.1-4"> All members of the committee should consider whether
			    the exception is worthy of mention in the next
			    revision of this document and follow-up follow up
			    accordingly. </t>
      </section>
      <section anchor="op_timeline_1" title="Selection Timeline">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-selection-timeline">Selection Timeline</name>
        <t pn="section-5.2-1"> The completion of the process of selecting
			    candidates to be confirmed by their respective
			    confirming body is due within three months. </t>

			<t>
        <t pn="section-5.2-2"> The completion of the selection process is due at
			    least two months prior to the First IETF.  This
			    ensures the NomCom has sufficient time
			    to complete the confirmation process. </t>
      </section>
      <section anchor="op_timeline_2" title="Confirmation Timeline">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-confirmation-timeline">Confirmation Timeline</name>
        <t pn="section-5.3-1"> The completion of the process of confirming the
			    candidates is due within one month. </t>

			<t>
        <t pn="section-5.3-2"> The completion of the confirmation process is due
			    at least one month prior to the First IETF. </t>
      </section>
      <section anchor="op_milestones" title="Milestones">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-milestones-2">Milestones</name>
        <t pn="section-5.4-1"> The Chair must establish
			    a set of NomCom milestones for the candidate
			    selection and confirmation process. </t>

			<t>
        <t pn="section-5.4-2"> There is a defined time period during which the
			    candidate selection and confirmation process must be
			    completed.  The Chair must establish a set of
			    milestones that, if met in a timely fashion, will
			    result in the completion of the process on time.
			    The Chair should allow time for iterating the
			    activities of the committee if one or more
			    candidates are not confirmed. </t>

			<t>
        <t pn="section-5.4-3"> The Chair should ensure that all committee members
			    are aware of the milestones. </t>
      </section>
      <section anchor="op_voting" title="Voting Mechanism">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-voting-mechanism">Voting Mechanism</name>
        <t pn="section-5.5-1"> The Chair must establish a voting mechanism. </t>

			<t>
        <t pn="section-5.5-2"> The committee must be able to objectively determine
			    when a decision has been made during its
			    deliberations.  The criteria for determining closure
			    must be established and known to all members of the
			    NomCom. </t>
      </section>
      <section anchor="op_quorum" title="Voting Quorum">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-voting-quorum">Voting Quorum</name>
        <t pn="section-5.6-1"> At least a quorum of committee members must
			    participate in a vote. </t>

			<t>
        <t pn="section-5.6-2"> Only voting volunteers vote on a candidate
			    selection.  For a candidate selection vote, a
			    quorum is comprised of at least seven of the
			    voting volunteers. </t>

			<t>
        <t pn="section-5.6-3"> At all other times, a quorum is present if at
			    least 75% of the NomCom members are
			    participating. </t>
      </section>
      <section anchor="op_recall_1" title="Voting numbered="true" toc="include" removeInRFC="false" pn="section-5.7">
        <name slugifiedName="name-voting-member-recall">Voting Member Recall">
			<t> Recall</name>
        <t pn="section-5.7-1"> Any member of the NomCom may propose
			    to the committee that any other member except the
			    Chair be recalled.  The process for recalling the
			    Chair is defined elsewhere in this document. </t>

			<t>
        <t pn="section-5.7-2"> There are a variety of ordinary circumstances that
			    may arise that could result in one or more members
			    of the committee being unavailable to complete their
			    assigned duties, for example, health concerns, family
			    issues, or a change of priorities at work.  A
			    committee member may choose to resign for
			    unspecified personal reasons.  In addition, the
			    committee may not function well as a group because
			    a member may be disruptive or otherwise
			    uncooperative. </t>

			<t>
        <t pn="section-5.7-3"> Regardless of the circumstances, if individual
			    committee members cannot work out their differences
			    between themselves, the entire committee may be
			    called upon to discuss and review the
			    circumstances.  If a resolution is not forthcoming, a
			    vote may be conducted.  A member may be recalled if
			    at least a quorum of all committee members agree,
			    including the vote of the member being recalled. </t>

			<t>
        <t pn="section-5.7-4"> If a liaison member is recalled, the committee must
			    notify the affected organization and must allow a
			    reasonable amount of time for a replacement to be
			    identified by the organization before
			    proceeding. </t>

			<t>
        <t pn="section-5.7-5"> If an advisor member other than the prior year's
			    Chair is recalled, the committee may choose to
			    proceed without the advisor.  In the case of the
			    prior year's Chair, the Internet Society President
			    must be notified and the current Chair must be
			    allowed a reasonable amount of time to consult with
			    the Internet Society President to identify a
			    replacement before proceeding. </t>

			<t>
        <t pn="section-5.7-6"> If a single voting volunteer position on the
			    NomCom is vacated, regardless of the
			    circumstances, the committee may choose to proceed
			    with only nine voting volunteers at its own
			    discretion.  In all other cases, a new voting member
			    must be selected, and the Chair must repeat the
			    random selection process including an announcement
			    of the iteration prior to the actual selection as
			    stated elsewhere in this document. </t>

			<t>
        <t pn="section-5.7-7"> A change in the primary affiliation of a
			voting volunteer during the term of the NomCom is
			not a cause to request the recall of that
			volunteer, even if the change would result in
			more than two voting volunteers with the same
			affiliation. </t>
      </section>
      <section anchor="op_recall_2" title="Chair Recall">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.8">
        <name slugifiedName="name-chair-recall">Chair Recall</name>
        <t pn="section-5.8-1"> Only the prior year's Chair may request the
			    recall of the current Chair. </t>

			<t>
        <t pn="section-5.8-2"> It is the responsibility of the prior year's
			    Chair to ensure the current Chair completes the
			    assigned tasks in a manner consistent with this
			    document and in the best interests of the IETF
			    community. </t>

			<t>
        <t pn="section-5.8-3"> Any member of the committee who has an issue or
			    concern regarding the Chair should report it to
			    the prior year's Chair immediately.  The prior
			    year's Chair is expected to report it to the Chair
			    immediately.  If they cannot resolve the issue
			    between themselves, the prior year's Chair must
			    report it according to the dispute resolution
			    process stated elsewhere in this document. </t>
      </section>
      <section anchor="op_deliberations" title="Deliberations">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.9">
        <name slugifiedName="name-deliberations">Deliberations</name>
        <t pn="section-5.9-1"> All members of the NomCom may
			    participate in all deliberations. </t>

			<t>
        <t pn="section-5.9-2"> The emphasis of this rule is that no member can be
			    explicitly excluded from any deliberation.  However,
			    a member may individually choose not to participate
			    in a deliberation. </t>
      </section>
      <section anchor="op_call" title="Call numbered="true" toc="include" removeInRFC="false" pn="section-5.10">
        <name slugifiedName="name-call-for-nominees">Call for Nominees">
			<t> Nominees</name>
        <t pn="section-5.10-1"> The Chair announces the open positions to be
			    reviewed, the desired expertise provided by the
			    Managing Director, IETF Secretariat, and the call for
			    nominees. </t>

			<t>
        <t pn="section-5.10-2"> The call for nominees must include a request for
			    comments regarding the past performance of
			    incumbents, which will be considered during the
			    deliberations of the NomCom. </t>

			<t>
        <t pn="section-5.10-3"> The call must request that a nomination include a
			    valid, working email address, a telephone number,
			    or both for the nominee.  The nomination must
			    include the set of skills or expertise the nominator
			    believes the nominee has that would be
			    desirable. </t>
      </section>
      <section anchor="op_nominations" title="Nominations">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.11">
        <name slugifiedName="name-nominations">Nominations</name>
        <t pn="section-5.11-1"> Any member of the IETF community may nominate any
			    member of the IETF community for any open position,
			    whose eligibility to serve will be confirmed by the
			    NomCom. </t>

			<t>
        <t pn="section-5.11-2"> A self-nomination is permitted. </t>

			<t>
        <t pn="section-5.11-3"> NomCom members are not eligible to
			    be considered for filling any open position by
			    the NomCom on which they serve.  They
			    become ineligible as soon as the term of the
			    NomCom on which they serve officially
			    begins.  They remain ineligible for the duration of
			    that NomCom's term. </t>

			<t>
        <t pn="section-5.11-4"> Although each NomCom's term overlaps
			    with the following NomCom's term,
			    NomCom members are eligible for
			    nomination by the following committee if not
			    otherwise disqualified. </t>

  			    <t>
        <t pn="section-5.11-5"> Members of the IETF community who were
 			    recalled from any IESG, IAB, IETF Trust, or
			    IETF LLC Board position during the previous two
			    years are not eligible to be considered for
			    filling any open position. </t>
      </section>
      <section anchor="op_candidates" title="Candidate Selection">

			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.12">
        <name slugifiedName="name-candidate-selection-2">Candidate Selection</name>
        <t pn="section-5.12-1"> The NomCom selects candidates based
			    on its understanding of the IETF community's
			    consensus of the qualifications required to fill
			    the open positions. </t>

			<t>
        <t pn="section-5.12-2"> The intent of this rule is to ensure that the
			    NomCom consults with a broad base of
			    the IETF community for input to its deliberations.
			    In particular, the NomCom must
			    determine if the desired expertise for the open
			    positions matches its understanding of the
			    qualifications desired by the IETF community. </t>

			<t>
        <t pn="section-5.12-3"> The consultations are permitted to include names
			    of nominees, if all parties to the consultation
			    agree to observe the same confidentiality rules as
			    the NomCom itself, or the names are
			    public as discussed in
			    <xref target="gen_confidential"/>. target="gen_confidential" format="default" sectionFormat="of" derivedContent="Section 3.6"/>.  Feedback on
			    individual nominees should always be
			    confidential. </t>

			<t>
        <t pn="section-5.12-4"> A broad base of the community should include the
			    existing members of the IESG and IAB, IETF
			    Trust Trustees, and
			    IETF LLC Directors,
			    especially sitting members who share
			    responsibilities with open positions, e.g.,
			    co-Area Directors, and working group chairs,
			    especially those in the areas with open
			    positions. </t>

			<t>
        <t pn="section-5.12-5"> Only voting volunteer members vote to select
			    candidates. </t>
      </section>
      <section anchor="op_consent" title="Consent numbered="true" toc="include" removeInRFC="false" pn="section-5.13">
        <name slugifiedName="name-consent-to-nomination">Consent to Nomination">
			<t> Nomination</name>
        <t pn="section-5.13-1"> Nominees should be advised that they are being
			    considered and must consent to their nomination
			    prior to being chosen as candidates. </t>

			<t>
        <t pn="section-5.13-2"> Although the NomCom will make every
			    reasonable effort to contact and to remain in
			    contact with nominees, any nominee whose contact
			    information changes during the process and who
			    wishes to still be considered should inform the
			    NomCom of the changes. </t>

			<t>
        <t pn="section-5.13-3"> A nominee's consent must be written (email is
			    acceptable) and must include a commitment to provide
			    the resources necessary to fill the open position
			    and an assurance that the nominee will perform the
			    duties of the position for which they are being
			    considered in the best interests of the IETF
			    community. </t>

			<t>
        <t pn="section-5.13-4"> Consenting to a nomination must occur prior to a
			    nominee being a candidate and may occur as soon
			    after the nomination as needed by the NomCom.</t>

			<t>
        <t pn="section-5.13-5"> Consenting to a nomination must not imply the
			    nominee will be a candidate. </t>

			<t>
        <t pn="section-5.13-6"> The NomCom should help nominees
			    provide justification to their employers. </t>
      </section>
      <section anchor="op_announce_1"
		         title="Notifying numbered="true" toc="include" removeInRFC="false" pn="section-5.14">
        <name slugifiedName="name-notifying-confirming-bodies">Notifying Confirming Bodies">
			<t> Bodies</name>
        <t pn="section-5.14-1"> The NomCom advises the confirming
			    bodies of their candidates, specifying a single
			    candidate for each open position and testifying as
			    to how each candidate meets the qualifications of
			    an open position. </t>

			<t>
        <t pn="section-5.14-2"> For each candidate, the testimony must include a
			    brief statement of the qualifications for the
			    position that is being filled, which may be exactly
			    the expertise that was requested.  If the
			    qualifications differ from the expertise originally
			    requested, a brief statement explaining the
			    difference must be included. </t>

			<t>
        <t pn="section-5.14-3"> The testimony may include a brief
			    resume of the candidate and/or a brief summary of the
			    deliberations of the NomCom. </t>
      </section>
      <section anchor="op_announce_2" title="Confirming Candidates">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.15">
        <name slugifiedName="name-confirming-candidates">Confirming Candidates</name>
        <t pn="section-5.15-1"> Confirmed candidates must consent to their
			    confirmation, and rejected candidates and nominees
			    must be notified before confirmed candidates are
			    announced. </t>

			<t>
        <t pn="section-5.15-2"> It is not necessary to notify and get consent from
			    all confirmed candidates together. </t>

			<t>
        <t pn="section-5.15-3"> A nominee may not know they were a candidate.  This
			    permits a candidate to be rejected by a confirming
			    body without the nominee knowing about the
			    rejection. </t>

			<t>
        <t pn="section-5.15-4"> Rejected nominees, who consented to their
			    nomination, and rejected candidates must be notified
			    prior to announcing the confirmed candidates. </t>

			<t>
        <t pn="section-5.15-5"> It is not necessary to announce all confirmed
			    candidates together. </t>

			<t>
        <t pn="section-5.15-6"> The NomCom must ensure that all
			    confirmed candidates are prepared to serve prior to
			    announcing their confirmation. </t>
      </section>
      <section anchor="op_archive" title="Archives">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-5.16">
        <name slugifiedName="name-archives">Archives</name>
        <t pn="section-5.16-1"> The NomCom should archive the
			    information it has collected or produced for a
			    period of time but not to exceed its term. </t>

			<t>
        <t pn="section-5.16-2"> The purpose of the archive is to assist the
			    NomCom should it be necessary for it
			    to fill a mid-term vacancy. </t>

			<t>
        <t pn="section-5.16-3"> The existence of an archive, how it is implemented,
			    and what information to archive is at the discretion
			    of the committee.  The decision must be approved by
			    a quorum of the voting volunteer members. </t>

			<t>
        <t pn="section-5.16-4"> The implementation of the archive should make every
			    reasonable effort to ensure that the confidentiality
			    of the information it contains is maintained. </t>
      </section>
    </section>
    <section anchor="dispute" title="Dispute numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-dispute-resolution-process">Dispute Resolution Process">
		<t> Process</name>
      <t pn="section-6-1"> The dispute resolution process described here is to be used
		    as indicated elsewhere in this document.  Its applicability
		    in other circumstances is beyond the scope of this
		    document. </t>

		<t>
      <t pn="section-6-2"> The NomCom operates under a strict rule of
		    confidentiality.  For this reason, when process issues arise,
		    it is best to make every reasonable effort to resolve them
		    within the committee.  However, when circumstances do not
		    permit this, or no resolution is forthcoming, the process
		    described here is to be used. </t>

		<t> The
      <t pn="section-6-3">The following rules apply to the process.

		    <list style="numbers">
			<t> process:
      </t>
      <ol spacing="normal" type="1" start="1" pn="section-6-4">
        <li pn="section-6-4.1" derivedCounter="1."> The results of this process are final and binding.
			    There is no appeal. </t>

			<t> </li>
        <li pn="section-6-4.2" derivedCounter="2."> The process begins with the submission of a request
			    as described below to the Internet Society
			    President. </t>

			<t> </li>
        <li pn="section-6-4.3" derivedCounter="3."> As soon as the process begins, the NomCom
			    may continue those activities that are
			    unrelated to the issue to be resolved except that
			    it must not submit any candidates to a confirming
			    body until the issue is resolved. </t>

			<t> </li>
        <li pn="section-6-4.4" derivedCounter="4."> All parties to the process are subject to the
			    same confidentiality rules as each member of the
			    NomCom. </t>

			<t> </li>
        <li pn="section-6-4.5" derivedCounter="5."> The process should be completed within two
			    weeks. </t>

		    </list> </t>

		<t> </li>
      </ol>
      <t pn="section-6-5"> The process is as follows: </t>

		    <t><list style="numbers">
			<t>
      <ol spacing="normal" type="1" start="1" pn="section-6-6">
        <li pn="section-6-6.1" derivedCounter="1."> The party seeking resolution submits a written
			    request (email is acceptable) to the Internet
			    Society President detailing the issue to be
			    resolved. </t>

			<t> </li>
        <li pn="section-6-6.2" derivedCounter="2."> The Internet Society President appoints an arbiter
			    to investigate and resolve the issue.  A
			    self-appointment is permitted. </t>

			<t> </li>
        <li pn="section-6-6.3" derivedCounter="3."> The arbiter investigates the issue making every
			    reasonable effort to understand both sides of the
			    issue.  Since the arbiter is subject to the same
			    confidentiality obligations as all NomCom
			    members, all members are expected to
			    cooperate fully with the arbiter and to provide all
			    relevant information to the arbiter for review. </t>

			<t> </li>
        <li pn="section-6-6.4" derivedCounter="4."> After consultation with the two principal parties
			    to the issue, the arbiter decides on a resolution.
			    Whatever actions are necessary to execute the
			    resolution are immediately begun and completed as
			    quickly as possible. </t>

			<t> </li>
        <li pn="section-6-6.5" derivedCounter="5."> The arbiter summarizes the issue, the resolution,
			    and the rationale for the resolution for the
			    Internet Society President. </t>

			<t> </li>
        <li pn="section-6-6.6" derivedCounter="6."> In consultation with the Internet Society President,
			    the arbiter prepares a report of the dispute and
			    its resolution.  The report should include all
			    information that in the judgment of the arbiter
			    does not violate the confidentiality requirements
			    of the NomCom. </t>

			<t> </li>
        <li pn="section-6-6.7" derivedCounter="7."> The Chair includes the dispute report when
			reporting on the activities of the NomCom to the
			IETF community. </t>

		    </list> </t> </li>
      </ol>
    </section>
    <section anchor="recall" title="Member, numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-member-trustee-and-director">Member, Trustee, and Director Recall">

		<t> Recall</name>
      <t pn="section-7-1"> The following rules apply to the recall process.  If
		    necessary, a paragraph discussing the interpretation of
		    each rule is included. </t>

                <t>It
      <t pn="section-7-2">It applies to IESG and IAB Members, the NomCom
		appointed NomCom-appointed
         IETF Trust Trustees, and the NomCom appointed NomCom-appointed IETF LLC Directors.</t>
      <section anchor="recall_petition" title="Petition">

        <t>At numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-petition">Petition</name>
        <t pn="section-7.1-1">At any time, a signed petition (email is acceptable) may be
        submitted to the Internet Society President to request the recall
        of any sitting IESG or IAB member, or NomCom appointed NomCom-appointed IETF Trust
        Trustee, or NomCom appointed NomCom-appointed IETF LLC Director. There are two
        different types of petitions: a petition by participants of the IETF
        community, and a petition by the Ombudsteam as described in <xref
        target="RFC7776"/>.</t> target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>.</t>
        <section anchor="c_petition" title="Community Petition">

         <t>A numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-community-petition">Community Petition</name>
          <t pn="section-7.1.1-1">A recall petition can be made by at least 20 members of the
         IETF community who are qualified to be voting members of a
         NomCom. All individual and collective qualifications of NomCom
         eligibility are applicable, including that no more than two
         signatories may have the same primary affiliation.</t>

         <t>Each
          <t pn="section-7.1.1-2">Each signature must include a full name, email address, and
         primary company or organization affiliation.</t>

         <t>The
          <t pn="section-7.1.1-3">The IETF Secretariat is responsible for confirming that each
         signatory is qualified to be a voting member of a NomCom.  A
         valid petition must be signed by at least 20 qualified
         signatories.</t>

         <t>The
          <t pn="section-7.1.1-4">The petition must include a statement of justification for
         the recall and all relevant and appropriate supporting
         documentation.</t>

         <t>The
          <t pn="section-7.1.1-5">The petition and its signatories must be announced to the
         IETF community.</t>
        </section>
        <section anchor="o_petition" title="Ombudsteam Petition">

        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-7.1.2">
          <name slugifiedName="name-ombudsteam-petition">Ombudsteam Petition</name>
          <t pn="section-7.1.2-1">The Ombudsteam process allows the Ombudsteam to form a recall
        petition on its own without requiring 20 signatories from the
        community.  As defined in <xref target="RFC7776"/>, target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>, the petition
        and its signatories (the Ombudsteam) shall be announced to the
        IETF community, and a Recall Committee Chair shall be appointed
        to complete the Recall Committee recall committee process.  It is expected that
        the Recall Committee recall committee will receive a briefing from the Ombudsteam
        explaining why recall is considered an appropriate remedy.</t>
        </section>
<!--
			<t> All individual and collective qualifications of
			    NomCom eligibility are applicable,
			    including that no more than two signatories may
			    have the same primary affiliation. </t>

			<t> Each signature must include a full name, email
			    address, and primary company or organization
			    affiliation. </t>

			<t> The IETF Secretariat is responsible for confirming
			    that each signatory is qualified to be a voting
			    member of a NomCom.  A valid petition
			    must be signed by at least 20 qualified
			    signatories. </t>

			<t> The petition must include a statement of
			    justification for the recall and all relevant and
			    appropriate supporting documentation. </t>

			<t> The petition and its signatories must be announced
			    to the IETF community. </t>
-->
      </section>
      <section anchor="recall_chair" title="Recall numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-recall-committee-chair">Recall Committee Chair">
			<t> Chair</name>
        <t pn="section-7.2-1"> The Internet Society President shall appoint a Recall
			    Committee Chair. </t>

			<t>
        <t pn="section-7.2-2"> The Internet Society President must not evaluate the
			    recall request.  It is explicitly the responsibility
			    of the IETF community to evaluate the behavior of
			    its leaders. </t>
      </section>
      <section anchor="recall_cmte" title="Recall numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-recall-committee-creation">Recall Committee Creation">
			<t> Creation</name>
        <t pn="section-7.3-1"> The recall committee is created according to the
			    same rules as is the NomCom with the
			    qualifications that both the person being
			    investigated and the parties requesting the recall
			    must not be a member of the recall committee in any
			    capacity. </t>
      </section>
      <section anchor="recall_rules" title="Recall numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-recall-committee-rules">Recall Committee Rules">
			<t> Rules</name>
        <t pn="section-7.4-1"> The recall committee operates according to the same
			    rules as the NomCom with the
			    qualification that there is no confirmation
			    process. </t>
      </section>
      <section anchor="recall_ops" title="Recall numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-recall-committee-operation">Recall Committee Operation">
			<t> Operation</name>
        <t pn="section-7.5-1"> The recall committee investigates the circumstances
			    of the justification for the recall and votes on
			    its findings. </t>

			<t>
        <t pn="section-7.5-2"> The investigation must include at least both an
			    opportunity for the member being recalled to present
			    a written statement and consultation with third
			    parties. </t>
      </section>
      <section anchor="recall_maj" title="3/4 Majority">
			<t> numbered="true" toc="include" removeInRFC="false" pn="section-7.6">
        <name slugifiedName="name-3-4-majority">3/4 Majority</name>
        <t pn="section-7.6-1"> A 3/4 majority of the members who vote on the
			    question is required for a recall. </t>
      </section>
      <section anchor="recall_position" title="Position To numbered="true" toc="include" removeInRFC="false" pn="section-7.7">
        <name slugifiedName="name-position-to-be-filled">Position to Be Filled">
			<t> Filled</name>
        <t pn="section-7.7-1"> If a sitting member is recalled, the open position is
			    to be filled according to the mid-term vacancy
			    rules. </t>
      </section>
<!--
  	   </section>
-->
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <t>No numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-8-1">This document has no IANA actions required.</t> actions.</t>
    </section>
    <section anchor="security" title="Security Considerations">
		<t> numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-9-1"> Any selection, confirmation, or recall process
		    necessarily involves investigation into the qualifications
		    and activities of prospective candidates.  The
		    investigation may reveal confidential or otherwise private
		    information about candidates to those participating in the
		    process.  Each person who participates in any aspect of
		    the process must maintain the confidentiality of any and
		    all information not explicitly identified as suitable for
		    public dissemination. </t>

		<t>
      <t pn="section-9-2"> When the NomCom decides it is necessary to share
		confidential or otherwise private information with
		others, the dissemination must be minimal and must
		include a prior commitment from all persons consulted to
		observe the same confidentiality rules as the NomCom
		itself. </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">

	&RFC3777;
<!--
	&RFC4071;
	&I-D.ietf-iasa2-struct;
-->
	&RFC7437;
	&RFC7776;
        &I-D.ietf-iasa2-rfc4071bis;
        &I-D.ietf-iasa2-trust-update;
        &I-D.ietf-iasa2-consolidated-upd;

</references> pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references title="Informative References"> pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="Err232"> anchor="RFC3777" target="https://www.rfc-editor.org/info/rfc3777" quoteTitle="true" derivedAnchor="RFC3777">
          <front>
  <title>Erratum ID 232</title>
  <author><organization>RFC Errata</organization></author>
  <date></date>
            <title>IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees</title>
            <author initials="J." surname="Galvin" fullname="J. Galvin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="June"/>
            <abstract>
              <t>The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified.  This document is a self-consistent, organized compilation of the process as it was known at the time of publication.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3777"/>
          <seriesInfo name="DOI" value="10.17487/RFC3777"/>
        </reference>
        <reference anchor="Err4179"> anchor="RFC7437" target="https://www.rfc-editor.org/info/rfc7437" quoteTitle="true" derivedAnchor="RFC7437">
          <front>
  <title>Erratum ID 4179</title>
  <author><organization>RFC Errata</organization></author>
  <date></date>
  </front>
  <seriesInfo name="RFC" value="3777"/>
  </reference>

	&RFC3710;

	&RFC3797;
        &RFC8318;
<!--
	&RFC5078;
	&RFC5633;
	&RFC6859;
-->

</references>

<section anchor="changes" title="Changes Since RFC 3777">
	<t> <list style="symbols">
		<t>  Converted source file from nroff to XML,
			resulting in some reformatting. </t>

   	        <t> Applied errata for RFC 3777 (<xref target="Err232"/>
            <title>IAB, IESG, and <xref target="Err4179"/>). </t>

		<t> Applied RFC 5078 update. </t>

		<t> Applied RFC 5633 update. </t>

		<t> Applied RFC 5680 update. </t>

		<t> Applied RFC 6859 update. </t>

		<t> Corrected a few grammatical errors. </t>

		<t> Added a reference to RFC 3710. </t>
	    </list> </t>
</section>

<section anchor="changes7437" title="Changes Since RFC 7437">
	<t> <list style="symbols">
		<t> Changed all mentions IAOC Selection, Confirmation, and Recall Process: Operation of the Internet Administrative
		Oversight committee (IAOC), Nominating and replaced it with Recall Committees</title>
            <author initials="M." surname="Kucherawy" fullname="M. Kucherawy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="January"/>
            <abstract>
              <t>The process by which the
		appropriate references to members of the IETF Administration LLC
		(IETF LLC).  This included making changes on an as needed
		basis to IAB and IESG, and some aspects members of the IAOC, are selected, confirmed, and recalled is specified in this document.  This document is a self-consistent, organized compilation of the process for as it was known at the IETF LLC, in
		accordance with IASA2. </t>

               <t>Revised definition time of IETF Executive Director, and
               added definition publication of "Managing Director, IETF Secretariat".
               Changed text to "Managing Director, RFC 3777, with various updates since that version was published.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="7437"/>
          <seriesInfo name="DOI" value="10.17487/RFC7437"/>
        </reference>
        <reference anchor="RFC7776" target="https://www.rfc-editor.org/info/rfc7776" quoteTitle="true" derivedAnchor="RFC7776">
          <front>
            <title>IETF Anti-Harassment Procedures</title>
            <author initials="P." surname="Resnick" fullname="P. Resnick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t>IETF Participants must not engage in harassment while at IETF Secretariat"
               where appropriate.</t>

	       <t>Added references to appropriate IASA2 documents. </t>

		<t>Modified the Advice meetings, virtual meetings, or social events or while participating in mailing lists.  This document lays out procedures for managing and Consent model to enable IESG,
		IAB, enforcing this policy.</t>
              <t>This document updates RFC 2418 by defining new working group guidelines and IETF LLC to communicate directly with procedures.  This document updates RFC 7437 by allowing the NomCom
		rather than via Ombudsteam to form a recall petition without further signatories.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="25"/>
          <seriesInfo name="RFC" value="7776"/>
          <seriesInfo name="DOI" value="10.17487/RFC7776"/>
        </reference>
        <reference anchor="RFC8711" target="https://www.rfc-editor.org/info/rfc8711" quoteTitle="true" derivedAnchor="RFC8711">
          <front>
            <title>Structure of the Managing Director, IETF
		Secretariat.</t>

                <t>Updated removal text Administrative Support Activity, Version 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 month="February" year="2020"/>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8711"/>
          <seriesInfo name="DOI" value="10.17487/RFC8711"/>
        </reference>
        <reference anchor="RFC8714" target="https://www.rfc-editor.org/info/rfc8714" quoteTitle="true" derivedAnchor="RFC8714">
          <front>
            <title>Update to reflect the new LLC rules, which
		enables removal via the LLC or Process for Selection of Trustees for the IETF recall process, except 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="RFC8717" target="https://www.rfc-editor.org/info/rfc8717" quoteTitle="true" derivedAnchor="RFC8717">
          <front>
            <title>IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology</title>
            <author initials="J" surname="Klensin" fullname="John Klensin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="February" year="2020"/>
          </front>
          <seriesInfo name="BCP" value="101"/>
          <seriesInfo name="RFC" value="8717"/>
          <seriesInfo name="DOI" value="10.17487/RFC8717"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Err232" target="https://www.rfc-editor.org/errata/eid232" quoteTitle="false" derivedAnchor="Err232">
          <front>
            <title>Erratum ID 232</title>
            <author>
              <organization showOnFrontPage="true">RFC Errata</organization>
            </author>
          </front>
          <refcontent>RFC 3777</refcontent>
        </reference>
        <reference anchor="Err4179" target="https://www.rfc-editor.org/errata/eid4179" quoteTitle="false" derivedAnchor="Err4179">
          <front>
            <title>Erratum ID 4179</title>
            <author>
              <organization showOnFrontPage="true">RFC Errata</organization>
            </author>
          </front>
          <refcontent>RFC 3777</refcontent>
        </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 ISOC-appointed Director.</t>

                <t>Updated the document to clarify that there are members Internet Engineering Steering Group (IESG), a management function of the IAB and IESG, Trustees of Internet Engineering Task Force (IETF).  It is meant to document the IETF Trust, and
                Director charter of the IETF LLC.</t>

                <t>Updated document to also specify procedures IESG as it is presently understood.  This memo provides information for the
 	        NomCom appointed Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3710"/>
          <seriesInfo name="DOI" value="10.17487/RFC3710"/>
        </reference>
        <reference anchor="RFC3797" target="https://www.rfc-editor.org/info/rfc3797" quoteTitle="true" derivedAnchor="RFC3797">
          <front>
            <title>Publicly Verifiable Nominations Committee (NomCom) Random Selection</title>
            <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="June"/>
            <abstract>
              <t>This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.  As an example, the selection of the voting members of the IETF Trust Trustees.</t>

                <t>Revised Abstract Nominations Committee (NomCom) from the pool of eligible volunteers is used.  Similar techniques would be applicable to other cases.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3797"/>
          <seriesInfo name="DOI" value="10.17487/RFC3797"/>
        </reference>
        <reference anchor="RFC8318" target="https://www.rfc-editor.org/info/rfc8318" quoteTitle="true" derivedAnchor="RFC8318">
          <front>
            <title>IAB, IESG, and Introduction IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee</title>
            <author initials="S." surname="Dawkins" fullname="S. Dawkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="January"/>
            <abstract>
              <t>This specification formalizes an ad hoc practice used to provide current
		context.</t>

               <t>Changed "nominating committee" to "NomCom" throughout
               the document because it is what most use advice to describe the IETF Nominating Committee.</t>

               <t>Added that Committee (NomCom) about the operations of the IETF Trust Trustees Administrative Oversight Committee (IAOC).</t>
              <t>This document updates RFC 7437.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="10"/>
          <seriesInfo name="RFC" value="8318"/>
          <seriesInfo name="DOI" value="10.17487/RFC8318"/>
        </reference>
      </references>
    </references>
    <section anchor="changes" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-changes-since-rfc-3777">Changes Since RFC 3777</name>
      <ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-1">
        <li pn="section-appendix.a-1.1">  Converted source file from nroff to XML,
			resulting in some reformatting. </li>
        <li pn="section-appendix.a-1.2"> Applied errata for RFC 3777 (<xref target="Err232" format="default" sectionFormat="of" derivedContent="Err232"/>
		    and IETF LLC
               Directors, each may appoint <xref target="Err4179" format="default" sectionFormat="of" derivedContent="Err4179"/>). </li>
        <li pn="section-appendix.a-1.3"> Applied RFC 5078 update. </li>
        <li pn="section-appendix.a-1.4"> Applied RFC 5633 update. </li>
        <li pn="section-appendix.a-1.5"> Applied RFC 5680 update. </li>
        <li pn="section-appendix.a-1.6"> Applied RFC 6859 update. </li>
        <li pn="section-appendix.a-1.7"> Corrected a liaison to the NomCom.</t>

               <t>Incorporated the update few grammatical errors. </li>
        <li pn="section-appendix.a-1.8"> Added a reference to RFC7437 done by RFC7776.</t>

               <t>Incorporated RFC 3710. </li>
      </ul>
    </section>
    <section anchor="changes7437" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-changes-since-rfc-7437">Changes Since RFC 7437</name>
      <ul spacing="normal" bare="false" empty="false" pn="section-appendix.b-1">
        <li pn="section-appendix.b-1.1"> Changed all mentions of the update to RFC7437 done by <xref
               target="RFC8318"/> Internet Administrative
		Oversight committee (IAOC), and updated replaced it to refer with the
		appropriate references to the IETF
               Trust and IETF LLC, instead Administration LLC
		(IETF LLC).  This included making changes on an as needed
		basis to some aspects of the IAOC.</t>

               <t>Editorial changes.</t>

	    </list> </t>

</section>

<section anchor="oral" title="Oral Tradition">
		<t> Over process for the years, various NomComs have IETF LLC, in
		accordance with IASA2. </li>
        <li pn="section-appendix.b-1.2">Revised definition of IETF Executive Director, and
               added definition of "Managing Director, IETF Secretariat".
               Changed text to "Managing Director, IETF Secretariat"
               where appropriate.</li>
        <li pn="section-appendix.b-1.3">Added references to appropriate IASA2 documents. </li>
        <li pn="section-appendix.b-1.4">Modified the Advice and Consent model to enable IESG,
		IAB, and IETF LLC to communicate directly with the NomCom
		rather than via the Managing Director, IETF
		Secretariat.</li>
        <li pn="section-appendix.b-1.5">Updated removal text to reflect the new LLC rules, which
		enables removal via the LLC or the IETF recall process, except for
		the ISOC-appointed Director.</li>
        <li pn="section-appendix.b-1.6">Updated the document to clarify that there are members
                of the IAB and IESG, Trustees of the IETF Trust, and
                Director of the IETF LLC.</li>
        <li pn="section-appendix.b-1.7">Updated document to also specify procedures for the
 	        NomCom-appointed IETF Trust Trustees.</li>
        <li pn="section-appendix.b-1.8">Revised Abstract and Introduction to provide current
		context.</li>
        <li pn="section-appendix.b-1.9">Changed "nominating committee" to "NomCom" throughout
               the document because it is what most use to describe the
               IETF Nominating Committee.</li>
        <li pn="section-appendix.b-1.10">Added that the IETF Trust Trustees and IETF LLC
               Directors, each may appoint a liaison to the NomCom.</li>
        <li pn="section-appendix.b-1.11">Incorporated the update to RFC 7437 done by <xref target="RFC7776" format="default" sectionFormat="of" derivedContent="RFC7776"/>.</li>
        <li pn="section-appendix.b-1.12">Incorporated the update to RFC 7437 done by <xref target="RFC8318" format="default" sectionFormat="of" derivedContent="RFC8318"/>
               and updated it to refer to the IETF
               Trust and IETF LLC, instead of the IAOC.</li>
        <li pn="section-appendix.b-1.13">Editorial changes.</li>
      </ul>
    </section>
    <section anchor="oral" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-oral-tradition">Oral Tradition</name>
      <t pn="section-appendix.c-1"> Over the years, various NomComs have learned
		    through oral tradition passed on by liaisons that there are
		    certain consistencies in the process and information
		    considered during deliberations.  Some items from that oral
		    tradition are collected here to facilitate its consideration
		    by future NomComs.

		    <list style="numbers">
			<t>

      </t>
      <ol spacing="normal" type="1" start="1" pn="section-appendix.c-2">
        <li pn="section-appendix.c-2.1" derivedCounter="1."> It has been found that experience as an IETF
			    Working Group Chair or an IRTF Research Group Chair
			    is helpful in giving a nominee experience of what
			    the job of an Area Director involves.  It also
			    helps a NomCom judge the technical,
			    people, and process management skills of the
			    nominee. </t>

			<t> </li>
        <li pn="section-appendix.c-2.2" derivedCounter="2."> No person should serve both on the IAB and as an
			    Area Director, except the IETF Chair whose roles as
			    an IAB member and Area Director of the General Area
			    are set out elsewhere. </t>

			<t> </li>
        <li pn="section-appendix.c-2.3" derivedCounter="3."> The strength of the IAB is found in part in the
			    balance of the demographics of its members (e.g.,
			    national distribution, years of experience, gender,
			    etc.), the combined skill set of its members, and
			    the combined sectors (e.g., industry, academia,
			    etc.) represented by its members. </t>

			<t> </li>
        <li pn="section-appendix.c-2.4" derivedCounter="4."> There are no term limits for IAB and IESG
			members explicitly because the issue of
			continuity versus turnover should be evaluated
			each year according to the expectations of the
			IETF community, as it is understood by each
			NomCom. </t>

			<t> </li>
        <li pn="section-appendix.c-2.5" derivedCounter="5."> The number of NomCom members with the
			    same primary affiliation is limited in order to
			    avoid the appearance of improper bias in choosing
			    the leadership of the IETF.  Rather than defining
			    precise rules for how to define "affiliation", the
			    IETF community depends on the honor and integrity of
			    the participants to make the process work. </t>
		    </list> </t> </li>
      </ol>
    </section>
    <section anchor="timeline" title="Nominating numbered="true" toc="include" removeInRFC="false" pn="section-appendix.d">
      <name slugifiedName="name-nominating-committee-timeli">Nominating Committee Timeline">
		<t> Timeline</name>
      <t pn="section-appendix.d-1"> This appendix is included for the convenience of the reader
		    and is not to be interpreted as the definitive timeline.
		    It is intended to capture the detail described elsewhere in
		    this document in one place.  Although every effort has been
		    made to ensure the description here is consistent with the
		    description elsewhere, if there are any conflicts the
		    definitive rule is the one in the main body of this
		    document. </t>

		<t>
      <t pn="section-appendix.d-2"> The only absolute in the timeline rules for the annual
		    process is that its completion is due by the First IETF of
		    the year after the NomCom begins its term.
		    This is supported by the fact that the confirmed candidate
		    terms begin during the week of the First IETF. </t>

		<t>
      <t pn="section-appendix.d-3"> The overall annual process is designed to be completed in
		    seven months.  It is expected to start nine months prior to
		    the First IETF.  The time is split between three
		    major components of the process roughly as follows:

		    <list style="numbers">
			<t>

      </t>
      <ol spacing="normal" type="1" start="1" pn="section-appendix.d-4">
        <li pn="section-appendix.d-4.1" derivedCounter="1."> First is the selection and organization of the
			    committee members.  Three months are allotted for
			    this process. </t>

			<t> </li>
        <li pn="section-appendix.d-4.2" derivedCounter="2."> Second is the selection of the candidates by the
			    NomCom.  Four months are allotted
			    for this process. </t>

			<t> </li>
        <li pn="section-appendix.d-4.3" derivedCounter="3."> Third is the confirmation of the candidates by
			    their respective confirming bodies.  Two months are
			    allotted for this process. </t>
		    </list> </t>

		<t> </li>
      </ol>
      <t pn="section-appendix.d-5"> The following list captures the details of the milestones
		    within each component.  For illustrative purposes, the
		    list presumes the Friday before the First IETF is
		    March 1.  Numbers shown in square brackets indicate the
		    expected number of weeks at each step.

		    <list style="numbers">
			<t>

      </t>
      <ol spacing="normal" type="1" start="1" pn="section-appendix.d-6">
        <li pn="section-appendix.d-6.1" derivedCounter="1."> BEGIN Eight Months Prior to First
				IETF (approx. June 1); Internet Society
				President appoints the Chair.  The appointment
				must be done no later than the Second IETF or
				eight months prior to the First IETF, whichever
				comes first.  The Chair must be announced and
				recognized during a plenary session of the
				Second IETF. [0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.2" derivedCounter="2."> The Chair establishes and announces
				milestones to ensure the timely selection of the
				NomCom members. [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.3" derivedCounter="3."> The Chair contacts the IESG, IAB,
				and Internet Society Board of Trustees,
                                IETF Trust, and IETF LLC
				and requests a liaison.  The Chair contacts
				the prior year's Chair and requests an
				advisor.  The Chair obtains the list of IESG,
				IAB, IETF Trust, and IETF LLC open positions and descriptions
				from the chairs of each group. [0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.4" derivedCounter="4."> The Chair announces the solicitation
				for voting volunteer members that must remain
				open for at least 30 days.  The announcement
				must be done no later than seven months and two
				weeks prior to the First IETF (approx. June
				15). [6] </t>

			<t> </li>
        <li pn="section-appendix.d-6.5" derivedCounter="5."> After the solicitation closes, the
				Chair announces the pool of volunteers and the
				date of the random selection, which must be at
				least one week in the future.  The announcement
				must be done no later than six months and two
				weeks prior to the First IETF (approx. July
				15). [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.6" derivedCounter="6."> On the appointed day, the random
				selection occurs and the Chair announces the
				members of the committee and the one week
				challenge period.  The announcement must be done
				no later than six months and one week prior to
				the First IETF (approx. July 22). [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.7" derivedCounter="7."> During the challenge period, the Chair
				contacts each of the committee members and
				confirms their availability to participate.
				[0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.8" derivedCounter="8."> After the challenge period closes, the
				Chair announces the members of the committee and
				its term begins.  The announcement must be done
				no later than six months prior to the First
				IETF (approx. August 1). [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.9" derivedCounter="9."> The committee has one month during
				which it is to self-organize in preparation for
				completing its assigned duties.  This must be
				done no later than five months prior to the
				First IETF (approx. September 15). [6] </t>

			<t> </li>
        <li pn="section-appendix.d-6.10" derivedCounter="10."> END the Committee Member Selection
				Process; BEGIN the Selection of Candidates; Time
				is at least five months prior to the First IETF
				(approx. September 22). [0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.11" derivedCounter="11."> The Chair establishes and announces
				the milestones to ensure the timely selection of
				the candidates, including a call for nominations
				for the open positions.  The announcement must
				be done no later than five months prior to the
				First IETF (approx. October 1). [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.12" derivedCounter="12."> Over the next three months, the
				NomCom collects input and
				deliberates.  It should plan to conduct
				interviews and other consultations during the
				Third IETF.  The committee is due to complete
				its candidate selection no later than two
				months prior to the First IETF (approx. January
				1). [17] </t>

			<t> </li>
        <li pn="section-appendix.d-6.13" derivedCounter="13."> END the Selection of Candidates;
				BEGIN the Confirmation of Candidates; Time is
				at least two months prior to the First IETF
				(approx. January 1). [0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.14" derivedCounter="14."> The committee presents its candidates
				to their respective confirming bodies.  The
				presentation must be done no later than two
				months prior to the First IETF (approx.
				January 1). [0] </t>

			<t> </li>
        <li pn="section-appendix.d-6.15" derivedCounter="15."> The confirming bodies have one month
				to deliberate and, in communication with the
				NomCom, accept or reject
				candidates. [4] </t>

			<t> </li>
        <li pn="section-appendix.d-6.16" derivedCounter="16."> The Chair notifies and advises
				unsuccessful nominees that they have not been
				selected. [1] </t>

			<t> </li>
        <li pn="section-appendix.d-6.17" derivedCounter="17."> The Chair announces the confirmed
				candidates.  The announcement must be done no
				later than one month prior to the First IETF
				(approx. February 1). [4] </t>
		    </list> </t> </li>
      </ol>
    </section>
    <section anchor="thanks" title="Acknowledgments">
		<t> numbered="false" toc="include" removeInRFC="false" pn="section-appendix.e">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t pn="section-appendix.e-1"> A great deal of work went into the RFCs that preceded
		    this one.  The 2014 NomCom and this editor
		    would like to thank all of them once again for the time
		    and energy it took to get us to where we are now.  In
		    no particular order, we acknowledge:

  <figure><artwork>
  Jeff Case           Fred Baker        John Curran
  Guy Almes           Geoff Huston      Mike St. Johns
  Donald Eastlake     Avri Doria        Bernard Adoba
  Ted T'so            Phil Roberts      Jim Galvin
  Harald Alvestrand   Leslie Daigle     Joel Halpern
  Thomas Narten       Spencer Dawkins   Barry Leiba
  Lars Eggert         Ross Callon       Brian Carpenter
  Robert Elz          Bernie Hoeneisen  John Klensin
  Danny McPherson     S. Moonesamy      Scott Bradner
  Ralph Droms         Pekka Savola
  </artwork></figure> </t>

		<t> Allison Mankin and Russ White

      </t>
      <t pn="section-appendix.e-2">
<contact fullname="Jeff Case"/>,
<contact fullname="Fred Baker"/>,
<contact fullname="John Curran"/>,
<contact fullname="Guy Almes"/>,
<contact fullname="Geoff Huston"/>,
<contact fullname="Michael StJohns"/>,
<contact fullname="Donald Eastlake"/>,
<contact fullname="Avri Doria"/>,
<contact fullname="Bernard Aboba"/>,
<contact fullname="Ted T'so"/>,
<contact fullname="Phil Roberts"/>,
<contact fullname="Jim Galvin"/>,
<contact fullname="Harald Alvestrand"/>,
<contact fullname="Leslie Daigle"/>,
<contact fullname="Joel Halpern"/>,
<contact fullname="Thomas Narten"/>,
<contact fullname="Spencer Dawkins"/>,
<contact fullname="Barry Leiba"/>,
<contact fullname="Lars Eggert"/>,
<contact fullname="Ross Callon"/>,
<contact fullname="Brian Carpenter"/>,
<contact fullname="Robert Elz"/>,
<contact fullname="Bernie Hoeneisen"/>,
<contact fullname="John Klensin"/>,
<contact fullname="Danny McPherson"/>,
<contact fullname="S. Moonesamy"/>,
<contact fullname="Scott Bradner"/>,
<contact fullname="Ralph Droms"/>, and
<contact fullname="Pekka Savola"/>.
</t>
      <t pn="section-appendix.e-3"><contact fullname="Allison Mankin"/> and <contact fullname="Russ White"/> provided early reviews
		    and feedback about this document. </t>

		<t> Jari Arkko
      <t pn="section-appendix.e-4"><contact fullname="Jari Arkko"/> was very helpful by independently verifying
		    that the previous text from all the merged documents was
		    marshaled correctly into this one, and Adrian Farrel
		    and Brian Carpenter <contact fullname="Adrian Farrel"/>
		    and <contact fullname="Brian Carpenter"/> caught the nits that fell through
		    the cracks. </t>
    </section>
    <section anchor="IDchanges" title="Change log [RFC Editor: Please remove]">

  <t><list>

 <t>draft-ietf-iasa2-rfc74337bis-09, 2019-July-11</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

      <t>Added text to Abstract
      noting that
      this revision addresses only the changes required for IASA
      2.0 and other changes will be addressed in future documents.</t>

      <t>Editorial changes based on IESG reviews:
      <list>

      <t>Remove RFC3747 from Abstract because this document is only based
      on RFC7437.</t>
      <t>Making member, director, and trustee terminology consistent.</t>
      <t>Changed "nominated" to "selected" in <xref target="gen_func"/>.</t>
      <t>Add Trustee to end of second paragraph of <xref target="gen_model_1"/>.</t>
      <t>Correct section reference to [I-D.ietf-iasa2-rfc4071bis] in
      <xref target="gen_terms"/></t>
      <t>Clarify that there are two and three terms in
      <xref target="gen_vacancies"/>. bullet 4. B.</t>
      <t>Add Trustee to <xref target="gen_sitting"/> section title and first paragraph.</t>
      <t>Clarify that there are only term limits for IAB and IESG members
      in <xref target="oral"/> bullet 4.</t>
      <t>Add IETF Trust and IETF LLC to <xref target="timeline"/> bullet 3.</t>
      <t>Spelled out IETF Administrative Support Activity (IASA) on
      first use in <xref target="intro"/>.</t>
      <t>Minor editorial changes</t>

      </list></t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-08, 2019-June-26</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

      <t>Added a paragraph to <xref target="intro"/> "Introduction"
      noting that
      this revision addresses only the changes required for IASA
      2.0 and that should the community agree on other changes, they will be
      addressed in future documents.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-07, 2019-June-7</t>

  <?rfc subcompact="yes" ?>

       <t><list style="symbols">

        <t>Added reference to
        <xref target="I-D.ietf-iasa2-consolidated-upd"/> in
	<xref target="defs"/>.</t>

	 <t>Changed reference to RFC3710 to Informational.</t>

	 <t>Removed step 3 from IAB mid-term vacancies in <xref
	 target="gen_sitting"/> as it was redundant with step 4.
         </t>

	<t>Correct summary below for -06 version.
	</t>

	<t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-06, 2019-March-26</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

	<t>Removed IETF LLC from the list of positions who don't have term
	limits in
	<xref target="gen_func"/>.
	</t>

        <t>Added IETF Trust to the list of positions who can be recalled
	in
	<xref target="op_nominations"/>.
	</t>

	<t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-05, 2019-January-11:</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

	<t>Changed text to point to appropriate Sections of <xref
	target="I-D.ietf-iasa2-rfc4071bis"/>.
	</t>

	<t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-04, 2019-January-3:</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

       <t>Added IETF Trust to the title.</t>

       <t>Changed references to point to current IASA 2.0 structure
       document <xref target="I-D.ietf-iasa2-rfc4071bis"/></t>

       <t>Added IETF Trust to a few places it was missing.</t>

	<t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-03, 2018-October-22:</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

        <t>Revised <xref target="recall"/> to focus on repeal of the the
	NomCom appoint LLC Director positions.</t>

	<t>Added that the IETF Trust Trustees and IETF LLC Directors,
	each may appoint a liaison to the NomCom.</t>

        <t>Incorporated the update to RFC7437 done by RFC7776.</t>

       <t>Incorporated the update to RFC7437 done by <xref
       target="RFC8318"/> and updated it to refer to the IETF
       Trust and IETF LLC. instead of the IAOC.</t>

	<t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

 <t>draft-ietf-iasa2-rfc74337bis-02, 2018-October-19:</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

      	<t>Added "IETF" before Nominating and Recall Committees in the title.</t>

	<t>Added leading capitalization to Trustee(s) and Director(s) for consistency.</t>

	<t>Fixed other minor grammatical, spelling, or abbreviation nits.</t>

      </list></t>

      <?rfc subcompact="no" ?>

  <t>draft-ietf-iasa2-rfc74337bis-01, 2018-October-16:</t>

  <?rfc subcompact="yes" ?>

      <t><list style="symbols">

	<t>Modified the Advice and Consent model to enable IESG, IAB, and
	IETF LLC to communicate directly with the NomCom rather than via
	the Managing Director, IETF Secretariat.</t>

	<t>Updated member removal text to reflect the new LLC rules,
	which enables removal via the LLC or the IETF recall process,
	except for the ISOC-appointed Director.</t>

	<t>Removed discussion text from the volunteer eligibility
	section. This means that IETF LLC employees and contractors
	cannot volunteer for the NomCom but does not extend that
	prohibition to ISOC employees and contractors.</t>

        <t>Updated the document to clarify that there are members of the
        IAB and IESG, Trustees of the IETF Trust, and Directors of the
        IETF LLC.</t>

        <t>Removed ISOC Board of Trustees members from the definition of
	"sitting members" because it doesn't apply.</t>

         <t>Updated document to also include procedures for the
	 NomCom appointed IETF Trust Trustees.</t>

        <t>Revised Abstract and Introduction to provide current
        context.</t>

        <t>Changed "nominating committee" to "NomCom" throughout the
	document because it is what most use to describe the IETF
	Nominating Committee.</t>

        <t>Added an no-actions IANA Considerations Section.</t>

       <t>Editorial changes.</t>

      </list></t>

      <?rfc subcompact="no" ?>

  <t>draft-ietf-iasa2-rfc74337bis-00, 2018-October-12:</t>

  <?rfc subcompact="yes" ?>

  <t>Initial bis draft, Changes include:<list style="symbols">

		<t> Changed all mentions of the Internet Administrative
		Oversight committee (IAOC), and replaced it with the
		appropriate references to the IETF Administration LLC
		(IETF LLC).  This included making changes on an as needed
		basis to some aspects anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.f">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Kucherawy" fullname="Murray S. Kucherawy" role="editor">
        <organization showOnFrontPage="true"/>
        <address>
          <postal>
            <street>270 Upland Drive</street>
            <city>San Francisco</city>
            <region>CA</region>
            <code>94127</code>
            <country>United States of the process for the IETF LLC, in
		accordance with IASA2. </t>

               <t>Revised definition America</country>
          </postal>
          <email>superuser@gmail.com</email>
        </address>
      </author>
      <author fullname="Robert M. Hinden" initials="R." surname="Hinden" role="editor">
        <organization showOnFrontPage="true">Check Point Software</organization>
        <address>
          <postal>
            <street/>
            <city>San Carlos</city>
            <region>CA</region>
            <country>United States of IETF Executive Director, and
	       added definition America</country>
          </postal>
          <email>bob.hinden@gmail.com</email>
        </address>
      </author>
      <author fullname="Jason Livingood" initials="J." surname="Livingood" role="editor">
        <organization showOnFrontPage="true">Comcast</organization>
        <address>
          <postal>
            <street/>
            <city>Philadelphia</city>
            <region>PA</region>
            <country>United States of "Managing Director, IETF
	       Secretariat".  Changed text to "Managing Director, IETF
	       Secretariat" where appropriate.</t>

		<t> Added references to appropriate IASA2 documents. </t>

		<t> Corrected a few grammatical errors. </t>

      </list></t>

  <?rfc subcompact="no" ?>

  </list></t> America</country>
          </postal>
          <email>jason_livingood@comcast.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>