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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>

<rfc
   category="bcp"
   docName="draft-ietf-genarea-bcp10upd-01"
   ipr="trust200902"
   updates="BCP10">
   <front>
      <title>RFC 3777 Update for Vacancies</title>

      <author
         fullname="Dave Crocker"
         initials="D."
         surname="Crocker">
         <organization>Brandenburg InternetWorking</organization>
         <address>
            <postal>
               <street>675 Spruce Drive</street>
               <city>Sunnyvale</city>
               <region>CA</region>
               <code>94086</code>
               <country>USA</country>
            </postal>
            <phone>+1.408.246.8253</phone>
            <email>dcrocker@bbiw.net</email>
         </address>
      </author>

      <author
         fullname="J. Galvin"
         initials="J."
         surname="Galvin">
         <organization>Afilias USA</organization>
         <address>
            <postal>
               <street>300 Welsh Road, Bldg 3, Ste 105</street>
               <city>Horsham</city>
               <region>PA</region>
               <code>19044</code>
               <country>USA</country>
            </postal>
            <phone>+1-215-706-5715</phone>
            <email>galvin+ietf@elistx.com</email>
         </address>

      </author>
      <date
         year="2012"></date>
      <area></area>
      <workgroup></workgroup>
      <keyword></keyword>
      <abstract>
         <t>BCP 10 (RFC 3777) specifies IETF processes for selection,
            confirmation and recall of appointees to IETF positions. It also
            refers to the mechanism of resignation as part of a sequence that
            moves a sitting member to a new IETF position. However it does not
            more generally deal with vacancies created by resignation, death or
            uncontested, sustained absence from participation. This update to
            BCP 10 specifies procedures for handling vacancies.</t>
      </abstract>
   </front>

   <middle>

      <section
         title="Introduction">
         <t><xref
               target="RFC3777"></xref> (BCP 10) specifies IETF processes for
            selection, confirmation and recall of appointees to IETF positions.
            It also refers to the mechanism of resignation as part of a sequence
            that moves a sitting member to a new IETF position. However it does
            not more generally deal with vacancies created by resignation, death
            or uncontested, sustained absence from participation. This update to
            RFC 3777 specifies procedures for handling vacancies.</t>
         <section
            title="Draft changes">
            <t><list style="hanging">
               <t hangText="NOTE TO RFC EDITOR:">Remove this section prior to publication.</t>
            </list></t>
            <t><list
                  style="symbols">
                  <t>"For vacancies due to death or resignation..." - slight
                     wording tweak.</t>
                  <t>"Extended Last Call" - changed to cite RFC 2026 and match
                     its use of the label.</t>
                  <t>"For a contested, sustained absence,..." - reworded</t>
               </list></t>
         </section>
      </section>

      <section
         title="Changes to RFC 3777 (BCP 10)">

         <t>BCP 10 is modified as follows: <list
               style="symbols">
               <t>A new section is added, containing the text of the <xref
                     target="vacancy">Mid-Term Vacancy</xref> section,
                  below.</t>

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

      <section
         anchor="vacancy"
         title="Mid-Term Vacancy">
         <t>The process of filling a mid-term vacancy is specified in Section 5
            of <xref
               target="RFC3777"></xref>(BCP10).</t>

         <section
            title="Definition">
            <t>A mid-term vacancy occurs in the IAB, IESG or IAOC when a sitting
               member of that body ceases to participate in its activities.
               Vacancy can occur due to death, resignation, or sustained
               absence.</t>
         </section>

         <section
            title="Determination">
            <t>The IETF body of which the sitting member is a part will
               determine that the sitting member has vacated their position. In
               the case of vacancy due to uncontested, sustained absence, the
               body will make multiple different queries to the member, to
               determine the cause and likely duration of the absence. If the
               member who is at issue contests the determination that they have
               vacated the position, the existing Member Recall process, as
               specified in Section 7 of [RFC3777], is required.</t>
            <t>A two-thirds majority vote of the IETF body is needed to
               determine that a vacancy exists.</t>
         </section>

         <section
            title="Confirmation">
            <t>For vacancies due to death or resignation, no further action is
               required before declaring the seat vacant.</t>
            <t>For vacancies due to uncontested, sustained absence, the IETF
               body making that determination will issue an extended Last-Call <xref
                  target="RFC2026">Section 9.1, RFC 2026</xref> to the
               community. The Last Call will explain the basis for declaring the
               position vacant and include a summary of efforts to contact the
               member to resolve the issue. </t>
            <t>The results of the Last Call are assessed by the IETF body, with
               a two-thirds vote of the body. </t>
         </section>

      </section>




      <section
         title="Security Considerations">
         <t>This document carries no security concerns.</t>
      </section>
   </middle>
   <back>



      <references
         title="References - Normative">

         <reference
            anchor="RFC2026">
            <front>
               <title>The Internet Standards Process -- Revision 3</title>
               <author
                  fullname="S. Bradner"
                  initials="S."
                  surname="Bradner"></author>
               <date
                  month="October"
                  year="1996"></date>
            </front>
            <seriesInfo
               name="RFC"
               value="2026"></seriesInfo>
            <seriesInfo
               name="BCP"
               value="9"></seriesInfo>
         </reference>

         <reference
            anchor="RFC3777">
            <front>
               <title>IAB and IESG Selection, Confirmation, and Recall Process:
                  Operation of the Nominating and Recall Committees</title>
               <author
                  fullname="J. Galvin"
                  initials="J."
                  role="editor"
                  surname="Galvin">
                  <organization>eList eXpress LLC</organization>
               </author>
               <date
                  month="June"
                  year="3004"></date>

            </front>
            <seriesInfo
               name="RFC"
               value="3777"></seriesInfo>
            <seriesInfo
               name="BCP"
               value="10"></seriesInfo>
         </reference>

      </references>

   </back>
</rfc>
