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

1.  Introduction

The IETF Administrative Support Activity (IASA) was established in April 2005 by RFC 4071 (Austein, R. and B. Wijnen, “Structure of the IETF Administrative Support Activity (IASA),” April 2005.) [1] and expanded by RFC 4371 (Carpenter, B. and L. Lynch, “BCP 101 Update for IPR Trust,” January 2006.) [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 (Daigle, L. and Internet Architecture Board, “The RFC Series and RFC Editor,” July 2007.) [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] (Bradner, S., “The Internet Standards Process -- Revision 3,” October 1996.) 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.

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] (Bradner, S. and J. Contreras, “Rights Contributors Provide to the IETF Trust,” November 2008.), 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 (Emergency Situations)), 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.

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:

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

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

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

10.2. Informative References

Authors' Addresses