<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC3777  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml'>

]>
	<rfc category="bcp" updates="3777" ipr="trust200811" docName="draft-dawkins-nomcom-openlist-02"> 

  	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  	<?rfc toc="yes" ?>

  	<?rfc symrefs="yes" ?>

 	<?rfc sortrefs="yes"?>

  	<?rfc iprnotified="no" ?>

  	<?rfc strict="yes" ?>

	<?rfc compact="yes" ?>

	<?rfc comments="yes"?>

	<?rfc inline="yes"?>

<front>
  <title abbrev="NomCom Issues">Nominating Committee Process: Open Disclosure of Willing Nominees</title>

  <author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="editor">
    <organization abbrev="Huawei (USA)">Huawei Technologies (USA)</organization>
    <address>
      <phone>+1 214 755 3870</phone>
      <email>spencer@wonderhamster.org </email>
    </address>
  </author> 
  
  <date month="February" year="2009" />

  <area>RAI</area>
  <workgroup>Network Working Group</workgroup>

<abstract>
	<t>This document updates RFC 3777, Section 3, Bullet 6 to allow a Nominating and Recall
		Commitee to disclose the list of nominees who are willing to serve in 
		positions the NomCom is responsible for filling.
	</t>
</abstract>
</front>

<middle>

<section anchor="intro" title="Introduction">

	<t>The Internet Engineering Steering Group (IESG), the Internet Architecture Board (IAB), 
		and at-large IETF representatives to the IETF Administrative Oversight Committee (IAOC) are 
		selected by a "Nominating and Recall Committee" (universally abbreviated as "NomCom").
		<xref target='RFC3777' /> defines how the NomCom is selected, and the processes it follows as
		it selects candidates for these positions.
	</t>

	<t>The NomCom is responsible for filling positions across the breadth of the Internet Engineering
		Task Force (IETF). The NomCom needs relevant information about nominees being considered
		for these positions, but current <xref target='RFC3777' /> requirements for confidentiality
		limit the ability of the NomCom to solicit that information. The process change described in
		this document allows the 
		NomCom to openly solicit information about willing nominees.
	</t>

</section>

<section anchor="currentrules" title="Current Rules on Confidentiality" >

	<t><xref target='RFC3777' /> is the latest in a series of revisions to the NomCom process. 
	</t>

	<t><xref target='RFC3777' /> describes the confidental nature of NomCom deliberations in
		section 3, "General", bullet 6, which states:
	</t>

	<t><list><t>All deliberations and supporting information that relates to
      			specific nominees, candidates, and confirmed candidates are
      			confidential.
			<vspace blankLines='1' />
		</t>
		
		<t>The nominating committee 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.
			<vspace blankLines='1' />
		</t>
		
		<t>It is consistent with this rule for current nominating committee
      			members who have served on prior nominating committees to advise
      			the current committee on deliberations and results of the prior
      			committee, as necessary and appropriate.
		</t>
	</list></t>

</section>

<section anchor="problems" title="Problems with Existing Rules">

	<t>There are two problems with existing practice - nominee lists aren't as confidential as
		<xref target='RFC3777' /> would lead the reader to believe, but they aren't visible to
		the entire IETF community, either.
	</t>

	<t>Since at least 1996, most NomComs have sent out a "short list" of nominees under consideration
		to a variety of audiences. The target audiences differ from year to year, but have included
		members of specific leadership bodies, working group chairs in
		a specific area (for IESG positions), and all working group chairs 
		(for IAB and IAOC positions). "All working group chairs" includes multiple hundreds 
		of recipients.
	</t>
	
	<t>This practice is unavoidable, because most NomCom members will not have personal 
		experience with most nominees for most positions, but it is periodically 
		challenged because it's not explicitly allowed as an exception to the blanket 
		requirement for confidentiality.
	</t>

	<t>In an attempt to maintain the required level of confidentiality, past NomComs have also included
		"ringers" on the short list - nominees who have notified NomCom that they are NOT willing
		to serve. Since anyone who sees the short list does not know who the ringers are, 
		consciencious IETF participants also provide feedback on nominees who have already 
		declined. This is a waste of precious IETF-participant cycles, and Joel Halpern (2008-2009
		NomCom Chair) reports that "the ringer pool leaks like a sieve" - it's also ineffective.
	</t>

	<t>We also note that the practice of publishing a "short list" 
		penalizes IETF participants who aren't members of one of the
		audiences being surveyed - they have no way of knowing who is being considered, except
		for incumbent(s), 
		and have little incentive to provide feedback to NomCom on individuals who might not 
		even be nominees.
	</t> 

</section>

<section anchor="askingcommunity" title="Asking the Entire Community for Feedback" >

	<t>We take it as given that for today's NomComs, members will not likely have personal experience with
		all nominees for all positions under review. 
	</t>

	<t>We assume that asking the larger community for 
		feedback about these nominees is preferable to NomCom members without personal experience 
		simply deferring to the members of the NomCom
		who DO have personal experience with specific nominees. 
	</t>

	<t>We assume that asking for feedback from the entire community is preferable to asking for
		feedback from specific segments of the community.
	</t>

</section>

<section anchor="accuratelist" title="Publishing an Accurate Nominee List">

	<t>In proposing that an accurate nominee list be published as part of NomCom's request for
		feedback from the community, we considered three possibilities:
	</t>

	<t><list style='numbers'>
		<t>Asking for feedback on all nominees, whether they are willing to serve or not.</t>
		<t>Asking for feedback on all nominees who are willing to serve.</t>
		<t>Asking for feedback on the nominees that NomCom is seriously considering (the "short
			list").</t>
	</list></t>

	<t>Asking for feedback on nominees who are not willing to serve is a waste of 
		precious IETF-participant cycles, and may make it less likely that NomCom would receive 
		feedback on some nominees who ARE willing to serve.
	</t>

	<t>Asking for feedback on all nominees who are willing to serve allows the community to point 
		out specific strengths and weaknesses of all nominees, and this feedback should be useful 
		to NomCom in deciding which nominees to seriously consider. It also allows NomCom to
		receive
		feedback on nominees who might not appear on a "short list" initially, in the event
		that a strong nominee is suddenly unwilling or unable to serve.
	</t>

	<t>We also note that the list of willing nominees would include incumbents who are willing to 
		serve an additional term.
	</t>

</section>

<section anchor="concerns" title="Concerns About Open Nominee Lists">

	<t>This section acknowledges possible concerns about publishing open nominee
		lists in previous discussions.
	</t>

	<t>It is possible that nominees who are willing to be considered if the nominee list
		is not published, would not be willing to be considered if the nominee list is
		published. This reluctance might be the result of personal pride, or the result of
		the fear of retribution, for a nominee being considered as a replacement
		for the nominee's managing Area Director (this concern is usually raised in
		an IESG context).
	</t>

	<t>Spencer's personal opinion is that if retribution for willingness to be considered for 
		IETF leadership positions is a serious concern, we have bigger
		problems than nominee list confidentiality, and Spencer notes that it's called the
		"Nominating AND RECALL Committee" for a reason.
	</t>

	<t>We note that (for example) the Internet Architecture Board publishes the nominee list
		for their representative to the Internet Society Board of Trustees, without apparent
		ill effects.
	</t>

	<t>It is possible that publishing the nominee list publicly would lead to "lobbying",
		public statements supporting nominees on the IETF mailing list, etc. 
	</t>

	<t>Rather than trying to prohibit specific "undesirable" behaviors, we trust that NomCom would 
		focus on factual feedback, rather than on statements of support, in its deliberations.
	</t>

	<t>We note that nominees know they are under consideration and can "lobby" today, by telling
		people they are willing to serve and asking them to provide feedback to NomCom. Several
		nominees (both incumbents and non-incumbents) have posted statements of candidacy
		to the IETF Discussion mailing list, for example.
	</t>

</section>

<section anchor="updatedtext" title="Updated text from RFC 3777">
	<t>At the end of the three paragraphs in  <xref target='RFC3777' />, section 3, 
		"General", bullet 6, which are currently:
	</t>

	<t><list><t>All deliberations and supporting information that relates to
      			specific nominees, candidates, and confirmed candidates are
      			confidential.
			<vspace blankLines='1' />
		</t>
		
		<t>The nominating committee 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.
			<vspace blankLines='1' />
		</t>
		
		<t>It is consistent with this rule for current nominating committee
      			members who have served on prior nominating committees to advise
      			the current committee on deliberations and results of the prior
      			committee, as necessary and appropriate.
		</t>
	</list></t>

	<t>add the following paragraphs:
	</t>

	<t><list>
		<t>The list of nominees willing to serve in positions under review 
			in the current NomCom cycle is not confidential.
			The NomCom will publish the list of names of all
			willing nominees to the community,
			in order to obtain feedback from the community on these nominees.
			The list of nominees published should not contain nominees who
			have not indicated a willingness to serve in the position(s) under
			review.
			<vspace blankLines='1' />
		</t>

		<t>The published list is intended to be published as a complete list, but the
			NomCom may publish an updated list if the NomCom identifies errors/omissions
			in a previously-published version of the public list, or if the NomCom finds 
			it necessary to call for additional nominees, and these nominees indicate 
			a willingness to serve in time to be considered by the NomCom.
		</t>
	</list></t>

</section>

<section anchor="security" title="Security Considerations">
	<t>This specification describes issues with the current IETF Nominating Committee process 
		(<xref target='RFC3777' />) and proposes an update to allow the NomCom to 
		solicit feedback on willing nominees from the entire community.
		No security considerations apply.
	</t>
</section>

<section anchor="iana" title="IANA Considerations">
	<t>No IANA actions are requested in this specification.
	</t>
</section>  

<section anchor="acks" title="Acknowledgements">
	<t>The editor thanks the following folks who have provided useful observations and 
		guidance on previous versions of this draft: Brian Carpenter, Leslie Daigle, 
		Joel Halpern, Danny McPherson.
	</t>
</section> 

</middle>

<back>

	<references title="Normative References">

		&RFC3777;

	</references>

</back>
</rfc>