<?xml version='1.0' encoding="utf-8"?>
<rfc category="bcp" docName="draft-resnick-variance-00"
	submissionType="IETF" xml:lang="en" version="3" ipr="trust200902"
	consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude">

	<front>
		<title abbrev="Variances">Variances to Provisions of Best Current Practices</title>
		<author initials="P." surname="Resnick" fullname="Peter W. Resnick" role="editor">
			<organization abbrev="Episteme">Episteme Technology Consulting LLC</organization>
			<address>
				<postal>
					<street>503 West Indiana Avenue</street>
					<city>Urbana</city>
					<region>IL</region>
					<code>61801-4941</code>
					<country>US</country>
				</postal>
				<phone>+1 217 337 1905</phone>
				<email>resnick@episteme.net</email>
				<uri>https://www.episteme.net/</uri>
			</address>
		</author>

		<abstract>
				<t>From time to time, there are unforeseen circumstances
				which make following the requirements of a Best Current
				Practice (BCP) untenable, or where the procedures
				described in the BCP gives no guidance. This document
				defines a process for the IETF to grant a variance to
				any IETF process for a single use or of very short
				duration.</t>
			</abstract>
		</front>

	<middle>
		<section anchor="intro"><name>Introduction</name>
			<t>The Best Current Practice (BCP) document series, among
			other things, defines the operations, policies, and
			processes of the IETF. From time to time, there are
			unforeseen circumstances which make following the
			requirements of a BCP untenable, or where the procedures
			described in the BCP gives no guidance, yet the BCP gives no
			latitude for anyone in IETF leadership to simply call for a
			variance to the procedure. RFC 2026 section 9 <xref
			target="RFC2026"/> describes a variance procedure for the IETF
			Standards Process, but the result of the variance is a
			published BCP, which is often inappropriate for a one-off or
			short-lived variance.</t>

			<t>This document defines a process for the IETF to grant a
			variance to any IETF process in cases where publishing an
			RFC in the BCP series is inappropriate because the variance
			is for a single use or of very short duration. This variance
			procedure is modeled on the variance procedure described in
			RFC 2026 section 9 <xref target="RFC2026"/>.</t>
		</section>

		<section anchor="procedure"><name>The Variance Procedure</name>
			<t>Upon the recommendation of an IETF Working Group or an ad
			hoc committee of IETF participants, the IESG may craft a
			variance to any BCP requirement via the following procedure.
			In approving a variance, the IESG must first determine that
			the likely benefits to the Internet community are likely to
			outweigh any costs to the Internet community that result
			from noncompliance with the requirements of the BCP in
			question. In exercising this discretion, the IESG shall at
			least consider (a) the merit of waving the provision of the
			BCP in question, (b) the possibility of achieving the goals
			of the BCP provision without granting a variance, (c)
			alternatives to the granting of a variance, (d) the
			collateral and precedential effects of granting a variance,
			and (e) the IESG's ability to craft a variance that is as
			narrow as possible. In determining whether to approve a
			variance, the IESG has discretion to limit the scope of the
			variance to particular parts of the BCP in question and to
			impose such additional restrictions or limitations as it
			determines appropriate to protect the interests of the
			Internet community.</t>

			<t>The proposed variance must detail the problem perceived,
			explain the precise provision of the BCP in question which
			is causing the need for a variance, and the results of the
			IESG's considerations including consideration of points (a)
			through (d) in the previous paragraph. The proposed variance
			shall be issued as an Internet Draft. The IESG shall then
			issue an extended Last-Call, of no less than 4 weeks, to
			allow for community comment upon the proposal.</t>

			<t>In a timely fashion after the expiration of the Last-Call
			period, the IESG shall make its final determination of
			whether or not to approve the proposed variance, and shall
			notify the IETF of its decision via electronic mail to the
			IETF Announce mailing list. If the variance is approved, it
			shall be published on the IETF web site in a place
			designated for such variances.</t>
		</section>
		
		<section anchor="exclusions"><name>Exclusions</name>
			<t>This variance procedure is for use when a one-time waving
			of some provision of the BCP in question is felt to be
			required. In no event shall the waiver remain in place for
			longer than one year. Permanent changes to the BCP in
			question shall be accomplished through the normal BCP
			process.</t>

			<t>No use of this procedure may lower any delays for
			community notifications, nor exempt any procedure from the
			requirements of openness, fairness, or consensus, nor from
			the need to keep proper records of the meetings and mailing
			list discussions.</t>
		</section>
	</middle>
	
	<back>
		<references><name>References</name>
			<references><name>Normative References</name>
				<xi:include href="http://www.rfc-editor.org/refs/bibxml/reference.RFC.2026.xml"/>
			</references>
		</references>
    </back>
</rfc>