One document matched: draft-dawkins-nomcom-3777-issues-00.xml

<?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 RFC2027  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2027.xml'>

<!ENTITY RFC3777  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml'>

<!ENTITY RFC5078  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5078.xml'>

]>
	<rfc category="info" ipr="full3978" docName="draft-dawkins-nomcom-3777-issues-00"> 

  	<?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: Issues since RFC 3777</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> 

  <author initials="D." surname="McPherson" fullname="Danny McPherson">
    <organization abbrev="Arbor Networks"> Arbor Networks, Inc.</organization>
    <address>
      <email>danny@arbor.net</email>
    </address>
  </author>   
  
  <date day="7" month="July" year="2008" />

  <area>RAI</area>
  <workgroup>Network Working Group</workgroup>

<abstract>
	<t>This document describes issues with the current IETF Nominating Committee process
		that have arisen in practice.
	</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>This document describes issues with the current NomCom process
		that have arisen in practice. It does not propose ways to resolve those issues - that will
		potentially be the role of one or more follow-on documents and/or IETF work items.
	</t>

</section>

<section anchor="background" title="Background of this document" >

	<t><xref target='RFC3777' /> is the latest in a series of revisions to the NomCom process, which dates back to 
		<xref target='RFC2027'/> in 1996. <xref target='RFC3777' /> has been updated once since 2004,
		but this update (<xref target='RFC5078' /> did not change normative text (it replaced a
		sample timeline, allowing more time for required tasks and identifying a small number of tasks
		that are performed every year but were not included in the sample timeline).
	</t>

	<t>Although NomCom deliberations are held to a high level of confidentiality, three recent NomCom 
		chairs {Danny McPherson {2004-2005}, Ralph Droms {2005-2006}, and Andrew Lange {2006-2007})
		have reported a variety of issues at IETF Plenaries. They reported several issues (that arise across
		NomCom cycles), including experience that NomComs seem to consistently "run out of time"
		at the end of the process, a small number of candidates for at least some positions, confusion
		with confirming bodies, and a tension between confidentiality and an open request for feedback
		on candidates.
	</t>

	<t>This document is a compilation of discussions among a number of recent NomCom chairs (named in 
		<xref target='contributors' />) who acted as a design team, at the IETF Chair's request. In addition,
		we used Lakshminath Dondeti's IETF 71 Plenary NomCom report, and subsequent on-list and off-list
		discussions, as input, but Lakshminath was not included in the design team because he was currently
		serving as NomCom chair.
	</t>

	<t>This document is closer to being a union of views than a consensus of views. Given that each NomCom operates
		behind a wall of confidentiality, with the past NomCom chair as the only "common" participant, 
		it's difficult even for a group of former NomCom chairs to agree on 
		"what the problems common to all NomComs are".
	</t>

</section>

<section anchor="commissues" title="Issues that Affect NomCom Participation">

	<section anchor="shortening" title="Shortening the NomCom Epoch" >

		<t>We struggled with several aspects of the length of the NomCom cycle. Using the schedule
			suggested in (<xref target='RFC5078' />,
			the 2008-2009 NomCom will be budgeting for a 43-week NomCom cycle. There are
			several concerns that go along with a very long NomCom cycle:
		</t>

		<t><list style='symbols'>
			<t>We have a sense that a longer NomCom commitment reduces the number of NomCom volunteers
				who are willing to serve.
			</t>

			<t>A longer NomCom cycle can also affect the continued willingness of candidates to be considered - 
				candidates are contacted immediately to see if they are willing to serve, and then immediately
				before their names are sent forward - and there can be a 5-6 month delay between these events,
				so candidates may lose enthusiasm, or may experience personal/professional changes that
				prevent them from serving, between the two contact points.
			</t>
			
			<t>A smaller number of NomCom volunteers raises concerns about large "IETF sponsors" "gaming" the
				system.
			</t>
		
			<t>In a small minority of cases - IAB or IESG members who are serving in a one-year term - the NomCom
				cycle starts almost immedately after the member is seated (52 weeks in a year - 43 weeks in a 
				NomCom cycle = 9 weeks of experience when the process begins).
			</t>

		</list></t>

	</section>

	<section anchor="random" title="Random Selection of NomCom Membership" >

		<t>NomCom membership is selected randomly from a set of qualified volunteers. This means that NomCom 
			members are probably not personally familiar with all of the candidates, and may not be familiar with the
			required skillset for specific positions. This has implications for the amount of time needed
			for NomCom to collect inputs from the community.
		</t>

		<t>We also discussed concerns about the level of awareness of IETF culture for a 
			randomly-selected NomCom - since
			an IETF attendee can become NomCom-eligible in one year.
		</t>

	</section>

	<section anchor="gaming" title="Gaming NomCom Participation">

		<t>We have a sense that there are a small number of large sponsors for IETF participants who provide a
			disproportionate number of NomCom volunteers.
		</t>

		<t>The issue isn't that a single sponsor can "pack" a NomCom - current <xref target='RFC3777' /> 
			rules limit that effect - 
			but that large sponsors can be almost assured of at least one participant being selected for NomCom,
			year after year. We note that for several years, 50-60 percent of NomCom participants have come from
			four large sponsors. We aren't saying this is a problem, only that it's a trend worth noticing.
		</t>

	</section>

	<section anchor="affiliation" title="Affiliation and Related Issues">

		<t>As described in [RFC3777], the term "primary affiliation" is used in the following ways:
		</t>

		<t><list style="symbols">
			<t>A nomcom volunteer's "primary affiliation" is used in determining whether
				a volunteer is eligible for membership on the nominating committee (Section 4, point 17)
			</t>

			<t>Within the recall process, a signatory's primary affiliation is used to
				determine whether a signature on a recall petition is valid (Section 7). 
			</t>
		</list></t>

		<t>Despite the importance of "primary affiliation" in determining eligibility for the
			nominating committee and the validity of a signature on a recall petition, 
			the term is never defined within RFC 3777.
		</t>

		<t>While a potential nominating committee member or signatory with a single
			employer may not have difficulty in determining their "primary affiliation", the
			"primary affiliation" of an individual with multiple consulting clients or part-time
			employers may be less clear.  Such ambiguities can make it difficult to determine
			whether the RFC 3777 requirements for nominating committee balance are being followed,
			and may even affect the ability of the nomcom to accurately assess the "primary
			affiliation" of the candidates for the positions that the nomcom is attempting to fill.
		</t>

		<t>For its definition of "affiliation", IEEE has come up with the following:
		</t>

		<t><list>
			<t>"An individual is deemed 'affiliated' with any individual or  
				entity that has been, or will be, financially or materially  
		    		supporting that individual's participation in a particular IEEE  
		    		standards activity.  This includes, but is not limited to, his or  
		    		her employer and any individual or entity that has or will have,  
		    		either directly or indirectly, requested, paid for, or otherwise  
				sponsored his or her participation."
			</t>
		</list></t>

		<t>It should not noted that the above definition focuses on support for
			a particular activity, and therefore it is possible for a participant
			to have different "affiliations" while developing a standards submission,
			participating in an chair position, or serving on one or more committees. 
		</t>

		<t>There are plenty of corner cases here - "do a UCLA professor and UC-Irvine grad student
			have the same affiliation?" - 
			so what's needed is guidance, judgement, and flexibility.
		</t>

	</section>

</section>

<section anchor="commOperation" title="Issues Affecting NomCom Operation">

	<section anchor="PEorC" title="Model for Candidate Evaluation" >

		<t>We discussed two models - a Personal Experience (PE) model, and a Consultive (C) model.
		</t>

		<t>Under the PE model, a NomCom member would use personal experience to determine positions on candidates
			where the NomCom member has enough background to support those positions, and would rely on candidate
			feedback only for the positions where the NomCom member cannot support a position based on 
			personal experience.
		</t>

		<t>Under the C model, a NomCom member would base candidate positions almost exclusively on candidate feedback
			for all positions under consideration.
		</t>

		<t>We recognized that there's a tension in both directions - "personal experience" can become "personal bias", 
			while "consultive" can become a popularity contest.
		</t>

		<t>One former chair pointed out that the NomCom moved pretty quickly from a model where a random sample of the
			community selects leadership based on personal experience to a model where the random sample of the IETF
			is expected to survey a large and increasing percentage of the total community in order to select
			leadership. If we expect NomCom to act as a PE group, the process would be less intrusive to the rest
			of the community and would require less time for NomCom deliberations.
		</t>

		<t>We also noted that since NomCom voting members are unlikely to have personal experience with all candidates
			in all areas, there's a tendency for NomCom voting members to rely on other NomCom members when 
			considering an unfamiliar candidates in an unfamiliar area.</t>

	</section>

	<section anchor="globalNomCom" title="One NomCom for All Positions" >

		<t>We discussed whether having a single group of randomly-selected IETF attendees working to fill all
			positions under consideration was the right model. For example, one former NomCom chair noted that
			the IAB's responsibilities have changed dramatically since the NomCom structure was put in place, 
			and a considerable amount of IAB time has been spent on administrative restructuring, hearing appeals, 
			and representing the IETF in
			liaisons with other SDOs. Is the NomCom the best way way to choose people with the 
			required skillset to carry out these tasks? 
		</t>

	</section>

</section>

<section anchor="candidates" title="Candidate Issues">

	<t>We had some discussions about a relatively shallow candidate pool for some positions. We noted that
		it's not unusual for recent NomComs to reopen specific positions for late nominations (an indicator that
		the first round didn't generate enough candidates who were both qualified and willing to serve) - this
		happened in both 2005-2006 and in 2006-2007.
	</t>

	<section anchor="losing" title="Candidates Who Are Not Selected">

		<t>We noted that candidates must obtain confirmation of support from employers for a multi-year commitment,
			including commitments to fund travel for IETF meetings and workshops. There are IETF participants who
			are willing to obtain these commitments every year, but other participants are not willing to be
			considered every year when they must obtain high-level approval to be considered, 
			and then must notify the same
			high approval levels that they weren't selected - especially if business plans were adjusted to 
			accommodate the candidate serving and must now be adjusted again to accommodate the candidate 
			not serving.
		</t>

		<t>Even if a candidate is willing to be considered every year, the current NomCom cycle length requires
			serious candidates to "put their lives on hold" for up to six months between first being 						approached/volunteering and ultimately being selected.  Being in limbo for this period of time may
			be a negative factor with respect to possible job actions, especially new employment and promotions.
		</t>

		<t>Potential candidates may be unwilling to be considered for leadership positions, or may simply be unwilling
			to be considered during a specific NomCom cycle (given a choice between standing for a position against
			an incumbent finishing a first term and an incumbent finishing a third or fourth term, a candidate may
			"lay out" for a year to be considered against the long-time incumbent).
		</t>

	</section>

	<section anchor="stronginc" title="Running Against an Incumbent">

		<t>For a variety of reasons, mostly good reasons, a NomCom may be influenced by a candidate being
			an incumbent.
		</t>

		<t>Rules we've heard discussed by various NomComs include:
		</t>
		<t><list style="symbols">
			<t>always return a first term incumbent unless there is a problem 
				(assume the first term was training),
			</t>
			<t>always return an incumbent unless there is a problem (keep good incumbents until they 
				are no longer willing or able to serve, or until they are no longer good incumbents),
			</t>
			<t>apply term limits in some form, and
			</t>
			<t>"shoot them all" (never actually done to our knowledge, but expressed in NomCom discussions)
			</t>
		</list></t>
	
		<t>Given the confidentiality requirements of <xref target='RFC3777' />, potential candidates
			do not know what the informal rules a NomCom may choose to follow. <xref target='RFC3777' /> 
			encourages candidates to be considered, anyway, but candidates may choose to "be conservative
			in when you are considered", and may decline to be considered even if the NomCom would like
			to replace an incumbent.
		</t>

		<t>Recent experience seems to show that a higher number of candidates emerge when incombents publicly
			state they are unavailable to return for another term than when incumbents publicly state
			that they are available to return for another term, although this is only an impression.
		</t>

		<t>Note that this effect exists today, before any proposed changes to NomCom confidentiality rules 
			are considered. We expect that the effect would be more pronounced if candidate lists are 
			made public (more about this in <xref target='asking' />).
		</t>

		<t>When potential candidates refuse to be considered, this complicates life for a NomCom evaluating an 
			incumbent who is willing to serve again, but really needs to be replaced.
		</t>
		
		<t>We see no way for a NomCom to signal that a slot is "REALLY open" under the current rules of engagement.
		</t>

		<t>We note that spending effort on NomCom questionnaires when a NomCom is ready to reappoint
			an incumbent wastes valuable IETF participant time, and this is doubly wasteful when 
			a NomCom requests input on a "ringer" who was not under consideration, and was only
			added to the list to obscure which candidates WERE under consideration.
		</t>

	</section>

	<section anchor="asking" title="Soliciting Feedback on Non-Incumbent Candidates">

		<t>NomCom announces the slots being considered in each NomCom cycle, so incumbents being considered
			are known publicly, but other candidates are not made public. This complicates the decision
			to provide input to NomCom, because community members may provide information about a "candidate"
			who isn't being considered, or who isn't willing to serve - or, equally likely, they may simply
			choose not to provide input about non-incumbent candidates without being solicited to do so.
		</t>

		<t>There isn't any formal guidance to NomComs about how to solicit input, so each NomCom
			tends to use a modified version of what the previous NomCom used to solicit input. 
			Current NomCom practice is to request feedback on lists of candidates from a large "private"
			population - existing working group chairs, RFC authors in an area, current document authors in an area,
			and the entire IESG and/or IAB likely to see 
			candidate lists which, although the lists contain "ringers", necessarily expose the names of 
			all candidates for a position to a large and relevant portion of the IETF community.
		</t>

		<t>Even with solicitation of feedback on large "private" distributions, non-incumbents are at a
			disadvantage because the NomCom announcement names the incumbents, but does not name the 
			non-incumbents - who may be tempted to do something that starts to look like campaigning, to
			make sure that people who honestly believe they would be the best candidate do provide input.
		</t>

	</section>

	<section anchor="collision" title="Interaction between Affiliation and Willingness to be Considered">

		<t>We noted that there are unwritten rules about affiliation that affect a candidate's willingness
			to be considered. For example, apparent NomCom practice is that two area directors in the same area
			should not have the same affiliation. If an area director is from company X, possible candidates 
			from company X may be less willing to be considered for the second area director slot, assuming they
			will be summarily rejected because of this affiliation.
		</t>

		<t>Potential candidates for IAB slots may have similar concerns, and may not be willing to be considered,
			if there are already two IAB members with the same affiliation serving.
		</t>

	</section>

</section>

<section anchor="ConfBody" title="Confirming Body Issues">

	<section anchor="ConfRole" title="Role of the Confirming Body" >

		<t>In an e-mail on 2008/03/17, the IETF Chair asked the design team 
			"to propose a definition for the role of 
			the confirming body.  The discussion in plenary indicates that this 
			is a place where RFC 3777 is lacking.  In part, this discussion has 
			already taken place on the IETF mail list, with members of the design 
			team taking radically different views.  Please review the archives of 
			the nomcom WG when they are available."
		</t>

		<t>We gave that our best shot.
		</t>

		<t>We recognized a tension between a confirming body that is expected to "rubber-stamp" a candidate
			slate, and a confirming body that expects to "re-run the NomCom process" - ("show us the information
			the NomCom used to select this candidate slate, and we'll see if you picked the right candidates").
			Conversations at IETF 71 frequently used these terms. We don't think either extreme is desirable. 
			In subsequent discussions we noted that there is a middle ground - a confirming body would use 
			information forwarded by the NomCom as part of its "sanity check" diligence.
		</t>

		<t>We haven't agreed on a proposed definition of the role of the confirming body (yet). 
			This is where the editor thinks we are, 
			as of 00 I-D submission cutoff for IETF 72 (and the editor apologizes in advance if he has been unable
			to capture the group's consensus on what we didn't have consensus about)...
		</t>

		<t><list style='symbols'>

			<t>The role of the confirming body is the acceptance or rejection of proposed candidates.
			</t>
			
			<t>The confirming body should confirm candidates it believes are qualified 
				for the nominated position AND whose selection would not be disruptive to 
				the IETF process by whatever measure the confirming body chooses to use. 
				Conversely, the confirming body should reject candidates who do not meet 
				these conditions.
			</t>
			<t>Although <xref target='RFC3777' /> states that confirming body deliberations are under the same 
				requirements for confidentiality as the NomCom itself, recent experience 
				shows that NomComs and confirming bodies can, and do, disagree on 
				how much information the NomCom should share with confirming bodies.
			</t>

			<t>Although <xref target='RFC3777' /> assigns process guardianship roles to confirming body 
				liaisons (as well as to the past NomCom chair), the confirming body itself 
				must rely on confirming body liaisons for its view into the NomCom, and the 
				liaisons are often reluctant to share information with the rest of the 
				confirming body, citing confidentiality concerns.
			</t>

		</list></t>

	</section>

	<section anchor="ConfLiasion" title="Confirming Body Liaisons" >

		<t>Two sets of concerns were expressed about liaisons:
		</t>

		<t><list style="numbers">
			<t>Concerns relating to affiliation and diversity imbalances created by liaisons; 
			</t>

			<t>Concerns relating to undue influence of liaisons on the nomcom process. 
			</t>

		</list></t>

		<t>Since <xref target='RFC3777' />  places no restrictions on the "primary affiliation" of
			liaisons, it is possible for more than two NomCom members
			to share the same primary affiliation.  One example is the 2006-2007
			NomCom, where two voting members, the past NomCom chair, the ISOC 
			Liaison and the IESG liaison all shared a single primary affiliation.
		</t>

		<t>In addition to affiliation imbalances, there is the issue of 
			diversity in liaison participation.  While IESG and IAB liaisons
			cannot serve in successive years (since IESG and
			IAB terms are two years and a candidate whose position is being
			considered is not eligible to serve as a liaison), no such
			restriction exists for other liaisons and it has become common
			for other liaisons to return in successive years. 
		</t>

		<t>While liaisons are non-voting, concerns were raised about the influence
			that liaisons may have on NomCom voting members.  Some
			confirming bodies have explicitly instructed liaisons not to provide
			any information unless the NomCom asks for the information directly,
			and some NomCom chairs have set similar rules for liaisons.  However,
			there is a tension between being told "say nothing unless you are asked
			directly", and participating in conference calls unable to say anything
			when incorrect or incomplete factual statements are made.
		</t>

		<t>We discussed how best to limit liaison participation
			in NomCom.  Currently, an important role of the liaisons is to monitor the
			nomcom process and raise potential concerns about process violations. 
			However, currently <xref target='RFC3777' />  does not provide guidance on what a liaison
			should do in the situation where a process violation occurs, and it is
			not clear that this responsibility primarily resides with the liaisons or
			with the past nomcom chair.  If the primarily responsibility for process
			monitoring is assumed to reside with the past nomcom chair, then the role
			of the liaisons may be reduced or eliminated, or the role may be restricted
			to those activities required to supplement the past nomcom chair's
			responsibilities.
		</t>

	</section>

	<section anchor="entireSlate" title="What a Confirming Body Actually Confirms">

		<t>The 2006-2007 NomCom encountered a situation where they moved one Area Director to IETF Chair and
			reopened nominations for the vacated position - at this point, they had a complete slate, except
			for the vacant slot, but IAB wasn't sure they could confirm a slate with one vacancy or not.
		</t>

		<t>Two considerations apply here.
		</t>

		<t><list style="numbers" >
			<t>Moving an incument, especially to IETF Chair, is "worst-case" - it would be helpful to know
				that the incumbent will be seated in the new position, before declaring the old position open.
			</t>

			<t>Confirming bodies don't just consider each candidate in isolation - there is also a sense that
				the confirming body ought to look at the proposed slate, together with incumbents whose positions
				were not considered during this NomCom cycle, as a group, to ensure that the group will work 
				well together.
			</t>
		</list></t>

		<t>While it would simplify the confirmation process if confirming bodies were willing to confirm partial slates
			or complete slates with problematic candidates 
			and "fill in" the remaining slots later, the design team members were aware of several cases where the
			confirming bodies identified concerns about two candidates serving together. In some cases, both
			candidates were asked if this was really a concern ("can you let bygones be bygones?"). In other cases,
			the NomCom provided a slate with a different candidate, to address the confirming body's concern.
		</t>

	</section>

	<section anchor="arbitrator" title="2007-2008 Dispute Resolution Process Experience">

		<t>The 2007-2008 NomCom exercised a new code path - for the first time, a NomCom chair invoked the RFC 3777
			dispute resolution process. This means that a third-party arbiter is selected to investigate and
			resolve the issue under dispute.
		</t>

		<section anchor="arbCollision" title="Selecting an Arbiter">

			<t>The arbiter is selected by the ISOC President - but the ISOC President has no way to know whether a
				proposed arbiter is also a current "willing candidate" being considered by the same NomCom
				committee.
			</t>

		</section>

		<section anchor="scope" title="Scope of Dispute Resolution Process">

			<t><xref target='RFC3777' /> names four cases where the dispute resolution process
				should be invoked. None of the cases cover disputes between the NomCom and a confirming body.
			</t>

		</section>

		<section anchor="deadlock" title="Constitutional Crisis">

			<t>It is possible for either the Nomcom or a CB to wedge the process in a way where it cannot proceed.  				The Nomcom can refuse to select a candidate.  A CB can refuse to either confirm or reject a 
				proposed candidate.  It's unlikely that it would make sense to provide an arbiter the powers to
				override either of these decisions.
			</t>

			<t>Ultimately, we're dependent on the good will of both the Nomcom and CB in the completion of the 
				nominations process, and such good will should be encouraged.  The maxim is that "good fences 
				make good neighbors" - in this case, a better delineation of expectations between the Nomcom 
				and the CB is probably the best defense against a future "Constitutional Crisis".
			</t>

		</section>

	</section>

</section>

<section anchor="security" title="Security Considerations">
	<t>This specification describes issues with the current IETF Nominating Committee process 
		(<xref target='RFC3777' />). No security considerations apply beyond those discussions
		regarding confidentiality of NomCom deliberations.
	</t>
</section>

<section anchor="iana" title="IANA Considerations">
	<t>No IANA actions are requested in this specification.
	</t>
</section>

<section anchor="contributors" title="Contributing Authors">

	<t><list style="symbols" >
		<t>   2006-2007   Andrew Lange </t>
		<t>   2005-2006   Ralph Droms </t>
		<t>   2004-2005   Danny McPherson </t>
		<t>   2003-2004   Richard Draves</t>
		<t>   2002-2003   Phil Roberts</t>
		<t>   2001-2002   Theodore Ts'o</t>
		<t>   2000-2001   Bernard Aboba</t>
		<t>   1999-2000   Avri Doria</t>
		<t>   1998-1999   Donald Eastlake 3rd</t>
		<t>   1997-1998   Michael St. Johns</t>
		<t>   1996-1997   Geoff Huston</t>
		<t>   1993-1994   Fred Baker</t>
	</list></t>

</section>

</middle>

<back>

	<references title="Normative References">

		&RFC3777;

	</references>

	<references title="Informative References">

		&RFC2027;

		&RFC5078;

	</references>
</back>
</rfc>