Network Working Group                                         J. Klensin
Internet-Draft
Updates: 4071,4371                                            J. Halpern
(if approved)                                                   Ericsson
Intended status: BCP                                     August 23, 2009
Expires: February 24, 2010


        Policy Decisions and IASA -- IETF Trust and IAOC Issues
                    draft-klensin-iasa-policy-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 24, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Experience has indicated that the role of the various components of



Klensin & Halpern       Expires February 24, 2010               [Page 1]


Internet-Draft            IASA Policy Decisions              August 2009


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  IASA Decisions and Responsibilities -- Key principles . . . . . 4
     2.1.  Policy Making . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Stream Decisions and Consensus  . . . . . . . . . . . . . . 4
     2.3.  Problem Identification  . . . . . . . . . . . . . . . . . . 4
   3.  Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Defining and Agreeing to Policy Changes . . . . . . . . . . . . 6
   5.  Emergency Situations  . . . . . . . . . . . . . . . . . . . . . 6
   6.  Effects and Intent vis-a-vis IETF Trust Issues  . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



























Klensin & Halpern       Expires February 24, 2010               [Page 2]


Internet-Draft            IASA Policy Decisions              August 2009


1.  Introduction

   The IETF Administrative Support Activity (IASA) was established in
   April 2005 by RFC 4071 [1] and expanded by RFC 4371 [2] 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.

   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.

   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.

   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.

   The document borrows the concept of "stream" from the "RFC Stream"
   concept described in Section 5 of RFC 4844 [4] 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 [3] and successor documents.  Each other stream is free to work
   out decision arrangements as it sees fit, as long as approval for any



Klensin & Halpern       Expires February 24, 2010               [Page 3]


Internet-Draft            IASA Policy Decisions              August 2009


   policies, documents, or other measures used to instruct or advise the
   IASA are clear.


2.  IASA Decisions and Responsibilities -- Key principles

   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 [5], to the other streams.

2.1.  Policy Making

   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.

   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.

2.2.  Stream Decisions and Consensus

   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.

2.3.  Problem Identification

   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 Section 5), if the Trustees or IAOC are convinced
   that there is a problem, their job is to convince the stream, not to



Klensin & Halpern       Expires February 24, 2010               [Page 4]


Internet-Draft            IASA Policy Decisions              August 2009


   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.


3.  Feasibility

   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.

   In particular:

   o  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.

   o  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.

   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.



Klensin & Halpern       Expires February 24, 2010               [Page 5]


Internet-Draft            IASA Policy Decisions              August 2009


   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.


4.  Defining and Agreeing to Policy Changes

   In broad outline, the above principles imply the that Trust and IAOC
   procedure for dealing with policy changes is:

   1.  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).

   2.  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.


5.  Emergency Situations

   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



Klensin & Halpern       Expires February 24, 2010               [Page 6]


Internet-Draft            IASA Policy Decisions              August 2009


   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.

   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, .

   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.


6.  Effects and Intent vis-a-vis IETF Trust Issues

   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.

   It is worth noting that application of the provisions of Section 3
   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.




Klensin & Halpern       Expires February 24, 2010               [Page 7]


Internet-Draft            IASA Policy Decisions              August 2009


7.  Acknowledgments

   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.


8.  IANA Considerations

   [[Comment.1: RFC Editor: Please remove this section before
   publication.]]

   This memo includes no requests to or actions for IANA.


9.  Security Considerations

   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.


10.  References

10.1.  Normative References

   [1]  Austein, R. and B. Wijnen, "Structure of the IETF Administrative
        Support Activity (IASA)", BCP 101, RFC 4071, April 2005.

   [2]  Carpenter, B. and L. Lynch, "BCP 101 Update for IPR Trust",
        BCP 101, RFC 4371, January 2006.

   [3]  Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

10.2.  Informative References

   [4]  Daigle, L. and Internet Architecture Board, "The RFC Series and
        RFC Editor", RFC 4844, July 2007.

   [5]  Bradner, S. and J. Contreras, "Rights Contributors Provide to
        the IETF Trust", BCP 78, RFC 5378, November 2008.







Klensin & Halpern       Expires February 24, 2010               [Page 8]


Internet-Draft            IASA Policy Decisions              August 2009


Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, Ste 322
   Cambridge, MA  02140
   USA

   Phone: +1 617 245 1457
   Email: john+ietf@jck.com


   Joel M. Halpern
   Ericsson
   P. O. Box 6049
   Leesburg, VA  20178
   US

   Phone: +1 703 371 3043
   Email: jhalpern@redback.com
































Klensin & Halpern       Expires February 24, 2010               [Page 9]