<?xml version="1.0" encoding="UTF-8"?>


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	
	<!ENTITY RFC2026 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
	<!ENTITY RFC2418 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml'>
	<!ENTITY RFC3710 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3710.xml'>
	<!ENTITY RFC3777 PUBLIC '' 
		'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml'>
]>


<rfc category="bcp" ipr="trust200902" docName="draft-dawkins-iesg-one-or-more-02.txt" 
	submissionType="IETF" updates="2026,2418">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>

<?rfc compact="yes" ?>

<?rfc symrefs="yes" ?>

<?rfc sortrefs="yes"?>

<?rfc iprnotified="no" ?>

	<front>

	        <title abbrev='More Area Directors in an Area'>
			Increasing the Number of Area Directors in an IETF Area</title>

		<author initials="S." surname="Dawkins" fullname="Spencer Dawkins">
			<organization abbrev="Huawei">Huawei Technologies</organization>
			<address>
	      			<email>spencerdawkins.ietf@gmail.com</email>
	 		</address>
	  	</author>

        	<date month="November" year="2014" />
		<workgroup>IESG</workgroup>

        	<abstract>
			<t>This document removes a limit on the number of Area Directors who manage an 
				Area in the definition of "IETF Area".
				This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).
			</t>
		</abstract>

	</front>

	<middle>

        <section title="Introduction and Scope">

		<t>This document updates RFC 2026 (<xref target="RFC2026"/>, BCP 9) to remove a
			limit on the number of Area Directors who manage an Area in the definition of "IETF Area".
			This document also updates RFC 2418 (<xref target="RFC2418"/>, BCP 25) to reflect this 
			updated definition.
		</t>

		<t>The change described in this document is intended to allow the
			IESG additional flexibility in organizing the IETF's work.  It does
   			not make any changes to the role of an Area, and does
   			not argue that assigning more than two Area Directors to an
   			Area is an optimal solution in the long run. In particular, this
   			change is not intended to increase the size of the IESG
   			significantly. If several Areas will require more than two Area
   			Directors, the IESG should consider investigating alternative
   			ways of organizing the IETF's work.
		</t>

	</section>

        <section title="Discussion">

        	<t>In recent discussions, the IESG has explored splitting and combining Areas. 
			One proposal resulted in a single Area that would be managed by three Area Directors.
		</t>

        	<t>An Area managed by three Area Directors conflicts with this definition 
			in Section 14, &quot;DEFINITIONS OF TERMS&quot; of RFC 2026 (<xref target="RFC2026"/>):
		</t>

		<t><list style="empty">
			<t>IETF Area - A management division within the IETF.  An Area consists
      				of Working Groups related to a general topic such as routing.  An
      				Area is managed by one or two Area Directors.
			</t>
		</list></t>

		<t>A similar statement appears in Section 1, &quot;Introduction&quot; of RFC 2418 (<xref target="RFC2418"/>):
		</t>

		<t><list style="empty">
			<t>Each IETF area is managed by one or two Area Directors (ADs).  
			</t>
		</list></t>

        	<t>In the distant past, all IETF Areas had a single Area
			Director. The movement from single Area Directors in an Area to pairs of Area Directors in most 
			Areas happened over a period of years (for reference, see 
			http://www.ietf.org/iesg/past-members.html), as part of the IESG organizing itself to do the 
			work the IESG is chartered to do, 
		</t>

		<t>The last time the IESG increased the number of Area
			Directors in an Area was when they provided a position description to the Nominating Committee
			for a second Area Director in the Routing Area in 1999. Although the number of Area Directors in an 
			Area hasn't changed since then, the IESG continues to be responsible for specifying the 
			positions that Nomcom would fill each year. 
		</t>

		<t>It is consistent with the IESG's role in creating and dismantling entire Areas to allow the IESG
			flexibility in assigning enough Area Directors who have been selected by the Nominating Committee to
			effectively manage the working groups within an Area.
		</t>

		<t>Note that the requirement in RFC 3777  (<xref target="RFC3777"/>, BCP 10) 
			that the Nominating Committee review (approximately) 
			half the positions for the IESG each
			year is unchanged. The Nomcom may assign an appropriate term duration for each position to 
			ensure the ideal application of this rule in the future,
			and this is also unchanged.
		</t>

        </section>

        <section title="Normative Text Change">

        	<t>For this text (OLD) in Section 14, &quot;DEFINITIONS OF TERMS&quot; 
			of RFC 2026 (<xref target="RFC2026"/>):
		</t>

		<t><list style="empty">
			<t>IETF Area - A management division within the IETF.  An Area consists
      				of Working Groups related to a general topic such as routing.  An
      				Area is managed by one or two Area Directors.
			</t>
		</list></t>

        	<t>Replace with this text (NEW):
		</t>

		<t><list style="empty">
			<t>IETF Area - A management division within the IETF.  An Area consists
      				of Working Groups related to a general topic such as routing.  An
      				Area is managed by one or more Area Directors.
			</t>
		</list></t>

        	<t>For this text (OLD) in Section 1, &quot;Introduction&quot; of RFC 2418 (<xref target="RFC2418"/>):
		</t>

		<t><list style="empty">
			<t>Each IETF area is managed by one or two Area Directors (ADs).  
			</t>
		</list></t>

        	<t>Replace with this text (NEW):
		</t>

		<t><list style="empty">
			<t>Each IETF area is managed by one or more Area Directors (ADs).  
			</t>
		</list></t>

		<t>Informational RFCs such as RFC 3710 (<xref target="RFC3710"/>) and informal descriptions
			of IETF organizational structure which also describe 
			IETF Areas as being managed by one or two Area Directors should be considered updated
			by this normative specification.
		</t>

        </section>

        <section title="Security Considerations">

        	<t>This document updates an IETF process BCP 
			and has no direct Internet security implications.
		</t>

        </section>

        <section title="IANA Considerations">

        	<t>This document makes no requests of IANA, and the RFC Editor
			can safely remove this section during publication.
		</t>

        </section>

        <section title="Acknowledgements">

        	<t>Thanks to Barry Leiba and Jari Arkko for applying the giggle test to this document
			and to Brian Carpenter and David Harrington for providing comments.
		</t>

        </section>

    </middle>

    <back>

        <references title='Normative References'>

		&RFC2026;
		&RFC2418;
		&RFC3777;

	</references>

        <references title='Informative References'>

		&RFC3710;

	</references>

    </back>

</rfc>
