<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- Getting references from the online citation library.
     There has to be one entity for each item to be referenced. -->

<!ENTITY rfc4071 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4071.xml">
<!ENTITY rfc4371 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4371.xml">x
<!ENTITY rfc4844 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4844.xml">x
<!ENTITY rfc5378 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5378.xml">x
<!ENTITY rfc2026 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">x

<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">

]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions- PIs (for a complete list and description,
     see file http://xml.resource.org/authoring/README.html.
     You may find that some sphisticated editors are not able to edit PIs when placed here.
     An alternative position is just inside the rfc elelment as noted below. -->
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<!-- Controls display of <cref> elements -->
<?rfc comments="yes" ?>
<!-- When no, put comments at end in comments section,
     otherwise, put inline -->
<?rfc inline="yes" ?>
<!-- When yes, insert editing marks: editing marks consist of a 
     string such as <29> printed in the blank line at the 
     beginning of each paragraph of text. -->
<?rfc editing="no" ?>
<!-- Create Table of Contents (ToC) and set some options for it.  
     Note the ToC may be omitted for very short documents,but idnits insists on a ToC 
     if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC.
   Can be overridden by 'toc="include"/"exclude"' on the section
   element-->
<!-- Choose the options for the references. 
     Some like symbolic tags in the references (and citations) and others prefer 
     numbers. The RFC Editor always uses symbolic tags.
     The tags used are the anchor attributes of the references. -->
<?rfc symrefs="no"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
			 This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each 
     main section on a new page but does not omit the blank lines between list items. 
     If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- Information about the document.
     category values: std, bcp, info, exp, and historic
     For Internet-Drafts, specify attribute "ipr".
     (ipr values are: full3978, noModification3978, noDerivatives3978), 
     (2008 IETF Trust versions: trust200811, noModificationTrust200811, noDerivativeTrust200811
     Also for Internet-Drafts, you must specify a value for attributes "docName" which is 
     typically the file name under which it is filed - but need not be - and,if relevant, 
     "iprExtract".  
     Note that the value for iprExtract is the anchor attribute value of a section (such as 
     a MIB specification) that can be extracted for separate publication, and is only useful 
     when the value of "ipr" is not "full3978".
     "updates" and "obsoletes" attributes can also be specified here,
     their arguments are comma-separated lists of RFC numbers (just
	 the numbers) -->
<!-- Per Marshall Rose, 20090225 add trust200811,
    noModificationTrust200811, noDerivativesTrust200811, trust200902,
    noModificationTrust200902, noDerivativesTrust200902,
	pre5378Trust200902 -->

<rfc  docName="draft-klensin-iasa-policy-00.txt"
     ipr="trust200902" updates='4071,4371' category='bcp'>
     <!-- obsoletes='2821, 821' updates='1123,666' category='std' -->   

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="IASA Policy Decisions">Policy Decisions and IASA --
	   IETF Trust and IAOC Issues</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author fullname="John C Klensin" initials="J.C." surname="Klensin">
      <organization/>
      <address>
        <postal>
          <street>1770 Massachusetts Ave, Ste 322</street>
          <city>Cambridge</city> <region>MA</region>
          <code>02140</code>
          <country>USA</country>
        </postal>
        <phone>+1 617 245 1457</phone>
        <email>john+ietf@jck.com</email>
      </address>
    </author>
    <author fullname="Joel M. Halpern" initials="J.M." surname="Halpern">
      <organization abbrev="Ericsson">Ericsson</organization>
      <address>
        <postal>
          <street>P. O. Box 6049</street>
          <city>Leesburg</city>
          <region>VA</region>
          <code>20178</code>
          <country>US</country>
        </postal>
        <phone>+1 703 371 3043</phone>
        <email>jhalpern@redback.com</email>
      </address>
    </author>

    <date month="August" day="23" year="2009" />

    <!-- month and day are optional -->

    <!-- Meta-data Declarations -->
    <area>General</area>
	<keyword>IASA</keyword>
	<keyword>IAOC</keyword>
	<keyword>IETF Trust</keyword>

    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case in defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF!
    <workgroup>Network Working Group</workgroup>   -->
    <!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. -->

    <abstract>
      <t>Experience has indicated that the role of the various
		 components of the IETF Administrative Support Activity (IASA)
		 in developing and setting policies is not sufficiently clear
		 in the defining documents.  This document provides an
		 explicit statement of principles for policy formulation and
		 decision-making about areas of IASA responsibility.</t>
    </abstract>
	
  </front>

  <middle>
    <section title="Introduction">
	   <t> The IETF Administrative Support Activity (IASA) was
		  established in April 2005 by
		  <xref target='RFC4071'>RFC 4071</xref> and
		  expanded by <xref target="RFC4371">RFC 4371</xref> in
		  January 2006 to 
		  include the IETF Trust.  The intent of the community in the
		  discussions leading up to RFC 4071 (BCP 101) was that the
		  IASA carry out administrative and related functions for the
		  IETF (and related bodies as needed).  However, there have
		  been multiple discussions in subsequent years that, taken
		  together, suggest that it is desirable to clarify the
		  mechanisms for generating and adopting fundamental policies
		  for the IASA, including adjustments or clarifications of
		  IASA scope.</t>
	   <t>This document provides an explicit statement of principles
		  for policy formulation and decision-making about areas of
		  IASA responsibility.  It supplements those principles with
		  an informal description of the decision-making process.</t>
	   <t>The authors do not believe that this document changes BCP
		  101 in any significant way.  It is being written because
		  there has been enough misunderstanding about the intent of
		  BCP 101 that documented clarification may save the
		  communities involved significant time and aggravation.</t>
	   <t>The IASA is inherently a body created by the IETF and
		  designed to serve it.  However, there are several activities
		  that lie at least partially outside the IETF that are most
		  efficiently administered by the IASA but under the
		  supervision of of their own administrations and
		  constituencies.  Examples of this include administration of
		  some IAB and IRTF mailing lists and activities, support for the
		  full range of RFC Editor activities (not just IETF-produced
		  documents), and support for Intellectual Property procedures
		  and document repositories for IAB, IRTF, and Independent
		  Submissions to the RFC Editor.   Even if those other groups
		  request that the IASA be involved, it is an IETF decision as
		  to whether the IASA should take on those efforts or not.
		  However, IASA assuming some administrative responsibilities
		  for those group does not shift authority for decisions of
		  those groups into the IETF.</t>
	   <t>The document borrows the concept of "stream" from the "RFC
		  Stream" concept described in
		  <xref target="RFC4844">Section 5 of RFC 4844</xref> and uses
		  the term "stream body" to designate the body responsible for
		  determining consensus and setting policies for a given
		  streams, including policies that the IASA (and specifically
		  the IAOC and IETF Trustees) are expected to administer.  For
		  the IETF Stream (including all relevant IETF activities),
		  the "stream body" is the IESG as specified
		  in <xref target="RFC2026"/> and successor documents.  Each
		  other stream is free to work out decision 
		  arrangements as it sees fit, as long as approval for any
		  policies, documents, or other measures used to instruct or
		  advise the IASA are clear.</t>
    </section>

	<section title="IASA Decisions and Responsibilities -- Key principles">
	   <t>This section identifies a few principles that generalize
		  from the IETF-specific provisions of RFC 4071 with regard to
		  IAOC authority and responsibility and, for the IETF Trust,
		  the IETF-specific provisions and language of
		  <xref target="RFC5378"/>, to the other streams.</t>
	   <section title="Policy Making">
		  <t>The IASA (specifically, the IETF Trustees for
			 IPR-related matters and the IAOC for other matters) does
			 not make policy.  The 
			 IASA is an implementer of policies set by the various
			 streams.  As part of that implementation process, the
			 IASA is inevitably going to need to interpret the
			 stream-set policies and generate details and specific
			 procedures, but even those are subject to review by the
			 relevant streams.</t>
		  <t>There is obviously a line between policies and policy
			 decisions 
			and implementation of policies and determination of details.  I
			think we can trust the Trustees to use good sense about that
			(subject to appeal) as long as there is general agreement on
			these principles.  I think that where we are hung up now is that
			many of us believe, based on the provisions of BCP 101 and a
			general sense of the consensus of the community both when  the
			IASA was established and now, that the Trust doesn't make
			policy.  By contrast, the Trustees appear to be making
			statements and proposing policies (including this latest draft)
			that make them both determiners of policy and of consensus in
			bodies whom they are not chosen to represent.</t>
	  </section>
	  <section title="Stream Decisions and Consensus">
		 <t>The IASA is not set up to be an interpreter of consensus
			of the bodies associated with any particular stream.  In
			general, each stream has its own mechanism for making
			consensus determinations.  If those mechanisms are
			inadequate in any way, the problem is not the IASA's to
			solve.</t>
	  </section>
      <section title="Problem Identification">
	   <t>There is no problem with an administrative or IPR procedure or
		  policy until some stream, or the approving bodies and
		  processes for that stream, are convinced that there is a
		  problem.  Except in real
		  emergencies (see <xref target="emergencies"/>), if the
		  Trustees or IAOC are convinced that there is a problem,
		  their job is to convince the stream, not to start making
		  policy to solve a problem about which consensus has not been
		  identified.  They can do this using the
                  same mechanisms which are available to any other community member.</t>
	   </section>
	  </section>
	  
	  <section title="Feasibility" anchor="feasibility">
		 <t>A corollary to the IASA's role as an implementer of
			policies and as an administrative body for matters in
			which the relevant communities may not have deep expertise
			is that it has a key role in determining the feasibility
			of policy decisions coming from the streams.</t>
		 <t>In particular:
			<list style="symbols">
			   <t> For the IETF Trust, the Trustees and Counsel are
				  expected to evaluate the feasibility and legal
				  appropriateness of policy decisions coming from the
				  streams.  If the Trust determines that a particular policy
				  cannot be implemented without negative legal consequences or
				  significant negative procedural ones, then the Trust can, and
				  should, bounce the policy back to the originating stream with an
				  explanation.</t>
			   <t>For other IASA activities and responsibilities, the
				  IAOC is expected to evaluate the
				  administrative feasibility (including costs and
				  available budget) of policy decisions and requests
				  for IASA activities coming from the streams.  If
				  the IAOC determines that a particular policy  
				  cannot be implemented without negative or otherwise
				  unacceptable administrative or financial
				  consequences, significant negative procedural ones,
				  or that is just is not practical, then the IAOC can, and
				  should, bounce the policy back to the originating
				  stream with an explanation.   It may be useful to
				  think of that "bouncing" 
				  process as as an appeal from the IAOC to the
				  Stream, but an appeal that is explicitly of the
				  character of "you missed some important issues when
				  you agreed to this and sent it to us, here 
				  are the issues, please rethink your decision".   While it is
				  obviously desirable to have that sort of response on a timely
				  basis, there should not be a fixed time limit:
				  problems should be dealt with as soon as feasible
				  after they are discovered.</t>
		 </list></t>
	     <t>In both cases, it may be useful to think of the "bouncing
			back" process as as an appeal from the IASA to the Stream, but an
			appeal that is explicitly of the character of "you missed some
			important issues when you agreed to this and sent it to us, here
			are the issues, please rethink your decision".   While it is
			obviously desirable to have that sort of response on a timely
			basis, there should not be a fixed time limit:
			problems should be dealt with as soon as feasible
			after they are discovered.</t>
		 <t>This document does not change the formal appeals
			procedures described in BCP 101.  It does, however,
			clarify that those procedures apply to the Trustees as
			well as to the IAOC.</t>
	</section>

    <section title="Defining and Agreeing to Policy Changes">
	   <t>In broad outline, the above principles imply the that Trust
		  and IAOC procedure for dealing with policy changes is:
		  <list style="numbers">
			 <t>Policy change suggestions originate with the streams.
				It is 
				their responsibility to determine what is important and what is
				not and to determine whether they have sufficient consensus for
				a change.  If the IAOC or Trustees determine that
				changes are needed for 
				a particular stream, they are free to propose those changes to
				the body responsible for the stream, using the processes of that
				body.  Typically they will act as individual participants in the
				work associated with that stream or, if necessary, by generating
				suggestions transmitted as liaison notes (the latter
				is nearly a last resort -- requiring that much
				procedural bureaucracy would be a sign of fundamental
				problems within the IASA or the broader
				community).</t>
			 <t>When the body associated with a stream concludes that
				it is ready to establish a new policy, that policy is
				submitted to the Trustees (and, presumably, to
				Counsel) or the IAOC as appropriate for review and
				comment (not approval -- whether the Trustees or IAOC
				"like" the policy or not is not at issue here).   If
				the Trustees believe the policy can be implemented in
				a way that is legally and procedurally sound, or the
				IAOC believes that the policy can be implemented in a
				way that is administratively and financially sound,
				they proceed to drafting such implementation details
				as are 
				appropriate.  Those details are then presented back to the
				relevant stream body for approval and signoff (or rejection and
				either adjustment of the policy or further discussion).   If the
				Trustees or IAOC believe that the policy cannot be implemented in a
				reasonable way, they return the policy
				specification to the stream body with an explanation adequate to
				enable that body to perform a thoughtful and informed review and
				reevaluation.</t>
			 </list></t>
		  </section>
		  
		<section title="Emergency Situations" anchor="emergencies">
		   <t>Emergencies can and do (unfortunately) occur.  It is understood that
			  in an emergency, steps will be taken, and remedies applied.  The 
			  general rule is that if the Trust acts on an emergency
			  basis, the intent of BCP 101 and this document is that
			  it will quickly consult with the relevant community to
			  verify that 
			  the community does not wish some other remedy.  This consultation
			  needs to include clear descriptions of the issue at hand, as well
			  as the planned or taken actions.  If, as is likely in an emergency,
			  very prompt action is required, it may be sensible to have
			  two discussions.  First, a notification and brief review for 
			  immediate action, and then a lengthier community review to allow
			  for suitable evaluation and discussion of additional alternatives.</t>
		   <t>One class of emergency that must be acknowledged is a legal emergency.
			  For example, if a judge issues an order about the Trust polices
			  and procedures, the Trustees must comply with that order within 
			  the time frame the judge specifies.  In such circumstances, the
			  Trustees must notified the affect body or bodies of the change 
			  in procedure, and must provide as much clarity as to the cause
			  as is legally permitted.  The Trustees, on behalf of the Trust,
			  should consult with the relevant community about the effects of its
			  actions, and in general the stream body should verify that the
			  community supports the action.  In such a situation, the Trustees
			  can and should accept direction from the streams as
			  described above for other issues, but only within the
			  limits of the legal situation, .</t>
		   <t>It is also possible for the Trust to discover that there is an opportunity
			  for abuse of the Trust policies and procedures.  In that case, the
			  Trustees should consult with the leadership of the affected stream to
			  determine if it is an emergency, and what the appropriate response is.  
			  If it is agreed that it is an emergency, and actions must be taken 
			  promptly, there must still be provision for clear notification to the
			  community of the issue and for review of the planned resolution.</t>
		</section>

	<section title="Effects and Intent vis-a-vis IETF Trust Issues">
	   <t> This document is intended to clarify some specific
		  issues with the operation of the IETF Trust, particularly an apparent
                  misunderstanding in the way RFC 5378 has been interpreted by some individuals,
                  as compared with what the authors believe was the conceptual
		  intent of the WG.  It provides a basis for moving forward
		  from that interpretation and its consequences and
		  generalized from that experience in the hope of avoiding
		  future problems.</t>
	   <t>It is worth noting that application of the provisions of
		  <xref target="feasibility"/> would have prevented the
		  situation in which the Trust felt obligated to try to
		  enforce a narrow reading of RFC 5378, with that enforcement
		  effective at a time when the Trustees and community already
		  understood that doing so would cause fairly serious
		  problems.</t>
	</section>




	
    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>The ideas here reflect conversations with many people, often in ways
         only loosely related to the actual Trust rules.  Their assistance in 
         clarifying both their expectations, and their understanding of the 
         rules, is appreciated.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
	  <t><cref> RFC Editor: Please remove this section before
		 publication.</cref></t>
      <t>This memo includes no requests to or actions for IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document clarifies procedures for making policy changes
		 for the IASA (including the IETF Trust).  It should have no
		 effect on operational Internet security; any relevant issues
		 should be addressed as part of BCP 101.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split to informative and normative -->

    <references title="Normative References">

       <!-- BCP 101 -->
       &rfc4071;
       &rfc4371;

	   &rfc2026;

    </references>

    <references title="Informative References">

	   &rfc4844;  <!-- RFC Streams -->
	   &rfc5378;  <!-- IPR Contributions -->
		  
      <!-- Right back at the beginning we defined an entity which (we asserted) would contain
             XML needed for a reference... this is where we use it. -->

      <!-- A reference written by by an organization not a person. 
           NOTE: This reference is not referenced: this is immoral in I-Ds and RFCs, but may not
	   be in other technical documents. It will be flagged when strict="yes". -->
<!--
      <reference anchor="DOMINATION"
                 target="http://www.example.com/dominator.html">
        <front>
          <title>Ultimate Plan for Taking Over the World</title>
          <author>
            <organization>Mad Dominators, Inc.</organization>
          </author>
          <date year="1984" />
        </front>
      </reference>  -->
    </references>

<!--    <section  anchor="app-additional" title="Additional stuff">
      <t>This becomes an Appendix.</t>
    </section>  -->

<!--
	<section title="Change Log" anchor="ChangeLog">
	   <section title="Changes from version -00 to -01">
		  <t><list style="symbols">
			 <t>Blather</t>
		  </list></t>
	   </section>
	</section>      -->

  </back>
</rfc>
