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]