Network Working Group E. Davies, Ed.
Internet-Draft Folly Consulting
Intended status: Informational October 23, 2006
Expires: April 26, 2007
Moving Forwards with IETF Process Evolution
draft-davies-pesci-initial-considerations-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides a summary of previously identified problems
with the Internet Engineering Task Force (IETF) process for
developing standards and other specifications; and then identifies a
set of goals to aim at, and guidelines that should be followed during
any activity seeking to revise and update this process. It does not
propose specific changes to the process, which should be the subject
of future documents.
Davies Expires April 26, 2007 [Page 1]
Internet-Draft PESCI Goals and Guidelines October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Guidelines and Goals . . . . . . . . . . . . . . . . . . . 3
1.2. Principles, Policy, Process and Procedure . . . . . . . . 3
1.3. About This Document . . . . . . . . . . . . . . . . . . . 5
2. Background reading . . . . . . . . . . . . . . . . . . . . . . 5
3. Short problem analysis . . . . . . . . . . . . . . . . . . . . 6
4. Goals and Guidelines for IETF Process Change Activities . . . 7
4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Guidelines for Process Change Activities . . . . . . . . . 8
5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. PESCI Announcement . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Davies Expires April 26, 2007 [Page 2]
Internet-Draft PESCI Goals and Guidelines October 2006
1. Introduction
This document provides a summary of previously identified problems
with the Internet Engineering Task Force (IETF) process for
developing standards and other specifications (referred to as the
IETF standards development process in this document); and then
identifies a set of goals to aim at, and guidelines that should be
followed during any activity seeking to revise and update this
process. It also provides a reading list of the diverse material
that currently defines and discusses the various parts of this
process. It does not propose specific changes to the process, which
should be the subject of future documents. It has been produced by a
design team (the PESCI design team) selected by the IETF Chair and is
submitted to the IETF community for discussion.
The IETF almost continually debates its own process and this is in
many ways a healthy sign of its openness. However, the debate is
often inconclusive. The goals and guidelines set out in this
document represent an application of the IETF's Principles on
specification development and decision making appropriate to making
changes to the IETF standards development process.
1.1. Guidelines and Goals
The IETF has previously come to the conclusion that the IETF
standards development process suffers from a number of problems as
summarized in Section 3. In defining an activity to improve the IETF
standards development process, the activity needs to have a clear
goal or goals in ameliorating some part of these problems. Besides
the basic goal of process improvement, the activity should also aim
at a number of general goals applicable to the way in which the
improvement is defined and implemented. Because it is an IETF
activity, the activity itself and its results should follow the
general principles and policies which underlie the operation of the
IETF. Although the IETF has a Mission Statement [RFC3935], the
principles on which the IETF operates are mostly part of the
unwritten lore of the organization, and the PESCI design team created
a set of principles out of their collective experience of the way in
which the IETF operates. This set has been used to inform the
creation of a set of goals and guidelines applicable to any activity
which seeks to improve the IETF standards development process:
Section 4, which documents this set of goals and guidelines, provides
the results of this work.
1.2. Principles, Policy, Process and Procedure
Before going on to discuss process problems and guidelines for change
activities we should be clear about what we mean by "process", and
Davies Expires April 26, 2007 [Page 3]
Internet-Draft PESCI Goals and Guidelines October 2006
some of the other "P" words which will be used in the document.
Principles A set of statements that sets out how the IETF will
approach its work and carry out its mission.
Collectively they set the organization's ethos. These
include such things as requiring that development of
documents and organizational matters are as far as
possible open with "rough consensus and running code" as
an operating principle. When the PESCI design team
started work no such set of statements existed, and the
team created a set based on their collective
understanding of how the IETF functions. These
statements are not incorporated in this document but may
be published separately, possibly as part of a revision
of the Tao of the Internet.
Policy An agreement on what the IETF sets out to accomplish. At
the highest level this is incorporated in the IETF
Mission Statement[RFC3935]. This is refined in the
"constitutions" (usually known as "charters" in the IETF)
for the various component bodies which provide the
organisation of the IETF (listed in Section 2), but these
documents are not confined to policy matters. Overall
IETF policy and the constitutions of the bodies are
adopted by establishing strong IETF consensus.
Process Descriptions of the methods and mechanisms by which the
IETF works. These must be visible to all the IETF
participants; core pieces of the existing process are
contained in the IESG charter and the IAB charter
together with the definition of the IETF Standards Track
in [RFC2026]. Additions or modifications to IETF
processes are verified by establishing an IETF (rough)
consensus, but normally, the specification of the process
should be developed under the aegis of the body or bodies
that will oversee the operation of the process.
The process category covers area descriptions, large
proportions of the material in RFC2026 and the mechanisms
used to handle Intellectual Property Rights (IPR)
disclosures [RFC3979], as well as (for instance) the IAB
document on liaisons [RFC4053].
Procedures The "nuts and bolts" of the execution of the process.
The I-D tracker, the tools team work, the liaison
statements document - even the IPR trust agreement -
belong in this category.
Davies Expires April 26, 2007 [Page 4]
Internet-Draft PESCI Goals and Guidelines October 2006
Procedures are normally developed by the people doing the
work, and documented and published as these bodies feel
it appropriate.
1.3. About This Document
This document was produced by the PESCI design team selected by the
IETF Chair and is published here as a record of discussion. PESCI
stands for Process Evolution Committee of the IETF and is in the
IETF's naming tradition as a successor of the earlier POISSON working
group. The membership of the design team is listed in the
Acknowledgements and the original announcement of PESCI is given as
an Appendix. PESCI had no special status in the IETF process; it was
simply the group of people who produced this document under the
leadership of the IETF Chair.
2. Background reading
The primary objective of the IETF process is to support the IETF
Mission Statement, [RFC3935]. Readers should be familiar with that
document.
The early phase of the current round of process discussions led to a
problem statement [RFC3774]. A general overview of current and draft
process documents can be found in [I-D.carpenter-procdoc-roadmap].
At the time of writing, two process related working groups exist:
newtrk (New IETF Standards Track Discussion) and ipr (Intellectual
Property Rights). Their charters, mailing lists, etc., may be found
via http://www.ietf.org/html.charters/wg-dir.html#General%20Area.
The organisations involved in the IETF standards process are
discussed in [RFC2028]. Information about the constitutions,
purposes, and policy of the main IETF bodies involved in these
processes can be found in:
o The Internet Architecture Board(IAB) Charter[RFC2850]
o The Internet Engineering Steering Group (IESG) Charter[RFC3710]
o The Nominating and Recall Committee (NOMCOM)[RFC3777]
o Request For Comments (RFC) Editor: See the RFC Editor web pages
including RFC Editor Purpose description
(http://www.rfc-editor.org/DOCUMENTS/purpose.html) and some
procedures in [RFC3932]
o The memorandum of understanding under which the Internet Assigned
Numbers Authority (IANA)) operates is in [RFC2860]; the processes
and procedures as they affect IETF relationships to IANA are
currently under discussion and will be the subject of the
"techspec" BOF in November 2005 (see Section 3).
Davies Expires April 26, 2007 [Page 5]
Internet-Draft PESCI Goals and Guidelines October 2006
o The mission of the Internet Research Task Force (IRTF) is
described on its web page (http://www.irtf.org/), and the policies
and procedures for the IRTF are in [RFC2014]
o Liaisons with external bodies are conducted through the IAB (see
[RFC4052] and [RFC4053])
In the last two years or so, a major effort has been made to update
the IETF's administrative structure, creating the IAOC, the IETF
Administrative Support Activity (IASA), and appointing the IETF
Administrative Director (IAD) (see [RFC4071] for details of these
bodies). This should not be confused with process change, although
its goal is to improve support for the process. Additionally, the
former and present IETF Chairs, and the IESG have taken steps to
improve procedures and their transparency. The Tools team and the
Education team are busy, many improvements have been made in details
of IESG document processing and shepherding, and the IESG has made a
number of efforts to improve the transparency of its discussions.
Such efforts are valuable, but orthogonal to process change as such.
However, they are part of the response to the problem statement
[RFC3774].
3. Short problem analysis
The PESCI team reviewed earlier [RFC3774] and recent discussion of
IETF process problems. This generated the following list of problems
that seem to affect the development of standards and other
specifications (following the remit of the design team described in
Section 1) and that appear to be potentially soluble.
1. Timeliness of IETF output
2. Lack of clarity about authority and delegation
3. Variable quality of output from WGs
* At least 30% of drafts attract IESG "DISCUSS" comments even
after IETF Last Call.
* Unsolved issue of adequate cross-area review earlier in the
process.
4. IESG overload, which leads to subsidiary problems
* bottleneck effect
* too little steering
* perception issues and them/us mentality
* burnout
* potential lack of candidates
5. Lack of a "career path" for IESG members - "dropped in,
overworked and chopped off"
* there is no form of apprenticeship for Area Directors (ADs)
Davies Expires April 26, 2007 [Page 6]
Internet-Draft PESCI Goals and Guidelines October 2006
* ADs are trained "on the job" leading to lower effectiveness
early in their terms
* lack of any sort of formal recognition or role for "emeritus"
ADs
* potential to lose both experience and capability of ex-ADs
6. Binary nature of appeal/recall process
* there is a disincentive to "go nuclear" leading to festering
problems
* appeals are very time consuming for IESG (and maybe also for
IAB)
* the IESG judge and jury problem for process issues
7. Difficulties which the IETF has in dealing with complex problems
(architectural issues are hard to handle in the current IESG/
area/working group structure)
8. Failures to follow through on the standards advancement process,
generally poor maintenance of standards and slow progress of
standards
Newtrk issues are in scope for the process change but we should
allow Newtrk to work - there maybe some opportunities to provide
input to newtrk through the principles we propose here.
9. Authority and decision mechanisms for parameter assignments
(IANA considerations).
10. Lack of a coherent set of documents defining the IETF processes.
Issues that are to be considered under the "techspec" banner are out
of scope for PESCI. The scope of techspec includes resolving
concerns regarding lack of visibility into RFC Editor state, copy-
editing, and excessive author changes in AUTH48. There was a
techspec BOF at IETF 64 in Vancouver. (see discussion list archive at
http://www1.ietf.org/mail-archive/web/techspec/current/).
IPR issues have their own WG (ipr) and have been thoroughly reviewed.
4. Goals and Guidelines for IETF Process Change Activities
This section lists specific goals and guidelines for any activity
seeking to change the IETF standards development process. An effort
has been made to write these very briefly and in self-explanatory
words. Many existing documents, including [RFC3774] and those cited
in [I-D.carpenter-procdoc-roadmap], have been consulted, as well as
recent mailing list discussions and private communications. An
intermediate output was a set of IETF Principles that is not
reproduced here but may be published separately.
Davies Expires April 26, 2007 [Page 7]
Internet-Draft PESCI Goals and Guidelines October 2006
4.1. Goals
Any activity which seeks to change the IETF standards development
process needs to have a well-defined aim of ameliorating some part of
the problems set out in Section 3 or identified subsequently. The
activity should also aim to satisfy a number of goals identified here
that should allow the changes to provide maximum improvement with
minimum disruption.
When designing new processes, it should be borne in mind that process
changes that require major structural changes within the IETF may
have wide-scale impact on the operation of the IETF: evolutionary
change may be more effective than revolutionary change.
G1. Ameliorate a well-defined part of the process problem space.
G2. Preserve those parts of the process that work reasonably well
today, unless they block other necessary changes.
G3. Make changes that seem certain to improve those parts of the
process that work less well.
G4. Avoid changes that would require unrealistic resources or
behaviours.
G5. Protect the continuity of ongoing IETF work.
G6. As far as possible, minimize simultaneous changes that may
interfere with each other.
G7. Avoid "thrashing" by repeated changes in the same area.
G8. Try to explicitly estimate the impact of changes before making
them, and try to measure whether the expectations were met after
making the change.
G9. Acknowledge that some refinement of the initial proposals may be
needed after trials. To this end try to work expeditiously to
provide a nearly right solution that delivers most of the gains
rather than refining the solutions endlessly before any
implementation (in line with the IETF's usual way of developing
standards).
4.2. Guidelines for Process Change Activities
Any activity for developing, approving and implementing changes to
IETF standards development process needs to operate in line with the
general principles of the IETF. This section presents a number of
guidelines developed from these principles that should apply to any
such activity. They deal with how any proposed changes to the IETF
processes for developing standards and other specifications should be
developed and authorized by the IETF community. These guidelines
appear to be broadly in line with our current process for development
activities, and similar principles should be true of any future
process.
Davies Expires April 26, 2007 [Page 8]
Internet-Draft PESCI Goals and Guidelines October 2006
P1. Changes to the IETF process must themselves be agreed by an open
process approved by the IETF community.
P2. The process for developing and agreeing these changed processes
must itself be the subject of IETF rough consensus.
P3. The development process must incorporate taking advice from
* the IESG, the IAB, the IAOC, and the Working Group chairs
* legal advisors
P4. When the proposed changes have been fully documented, "buy-in"
or more formal assent to the changed processes needs to be
obtained as follows:
* Any negative comments from the Working Group chairs must be
seriously considered.
* Formal consent must be obtained from the IESG, the IAB, and
the IAOC.
* Acceptance must be obtained from the ISOC board.
P5. The development and authorisation of the changed processes must
ensure that the IESG is not required itself to develop the new
processes.
5. Next Steps
The remit of the PESCI design team did not extend to determining what
IETF standards development process activities should be undertaken.
However the team encourages members of the community to produce
proposals for such activities in line with the above goals and
guidelines.
6. Security Considerations
This document has no direct impact on the security of the Internet.
However, a smooth and efficient IETF process is necessary to deal
rapidly with emerging security threats. Also, a badly designed
process may be subject to social denial of service attacks that could
damage both the IETF and indirectly the Internet itself. We should
also note that the change process (and the evaluation of potential
change) is itself vulnerable to social DoS.
7. IANA Considerations
This document does not require action by the IANA. However, IANA
activities do form part of the IETF process and process changes may
affect IANA.
Davies Expires April 26, 2007 [Page 9]
Internet-Draft PESCI Goals and Guidelines October 2006
8. Acknowledgements
The members of the PESCI team at the time this document was written
were:
Harald Alvestrand
Scott Brim
Brian Carpenter
Elwyn Davies
Adrian Farrel
Michael Richardson
This document was produced using the xml2rfc tool[RFC2629] and edited
with the xxe editor plug-in.
9. Informative References
[I-D.carpenter-procdoc-roadmap]
Carpenter, B., "The IETF Process: an Informal Guide",
draft-carpenter-procdoc-roadmap-05 (work in progress),
August 2006.
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
and Procedures", BCP 8, RFC 2014, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028,
October 1996.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710,
February 2004.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
Davies Expires April 26, 2007 [Page 10]
Internet-Draft PESCI Goals and Guidelines October 2006
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, October 2004.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes
for Management of IETF Liaison Relationships", BCP 102,
RFC 4052, April 2005.
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF",
BCP 103, RFC 4053, April 2005.
[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101,
RFC 4071, April 2005.
Appendix A. PESCI Announcement
To: IETF Announcement list <ietf-announce@ietf.org>
From: IETF Chair <chair@ietf.org>
Date: Fri, 16 Sep 2005 11:21:18 -0400
Subject: IETF Process Evolution
There has been quite a bit of community discussion of IETF process
change in recent months. Obviously, process changes must obtain
rough consensus in the IETF and follow the procedures in place
(principally RFC 2026 today). However, past experience has shown
that general discussion of IETF process change on the main IETF list,
or in a normal working group, rapidly tends towards divergent
opinions with consensus being extremely hard and slow to establish.
On the other hand, we have experience that discussion of simply
formulated principles and of consistent process proposals can be
constructive and convergent.
This note describes a method of starting the next phase of IETF
process change, possibly including updating the change process
itself.
Davies Expires April 26, 2007 [Page 11]
Internet-Draft PESCI Goals and Guidelines October 2006
As IETF Chair, I intend to lead a short term design team, to be known
as PESCI (Process Evolution Study Committee of the IETF).
I will request PESCI to
- review recent discussions on IETF process changes
- identify a concise set of goals and principles for process change
- publish these for comment and seek IETF debate and rough consensus
The target is to have a draft of goals and principles by IETF64.
The next steps will depend on the agreed goals and principles after
this debate. It is very likely that we will need a process that will
generate a consistent set of proposals and a sequence for
implementing them, with target dates. It is also likely that the
first proposal will be a new process for process change. And it's a
given that open discussion and rough consensus, in accordance with
IETF principles, will be required.
A non-binding proposal for the next steps is appended to this
message.
Given the short time until the next IETF, the team will have to start
very soon and work quite intensively. If you would like to volunteer
for the PESCI team or nominate someone to serve on it, please send me
email immediately. I want to create the team within a week.
Brian Carpenter
IETF Chair
N.B. The open discussion list will be pesci-discuss@ietf.org, but it
hasn't yet been created at the time of sending this message.
-----
Possible next steps after the PESCI goals and principles are agreed:
- decide whether to renew the PESCI design team (assumed below) or
use an alternative discussion forum
- consider various process change proposals from any source
- reach a team consensus on a consistent set of proposals and a
sequence for implementing them, with target dates. All proposals
must embed the principle of rough IETF consensus and must provide an
appeal mechanism.
- one of the proposals, likely the first, may be a proposal for a new
process for process change
- post the proposals as Internet-Drafts intended for publication as
BCPs
- seek IETF-wide rough consensus on these drafts
Davies Expires April 26, 2007 [Page 12]
Internet-Draft PESCI Goals and Guidelines October 2006
- legal considerations, IASA financial considerations, and
considerations of practicality raised by current or past Area
Directors, WG Chairs and the like will be given special
consideration. If IETF consensus appears to be for a proposal which
is legally, financially or practically unacceptable, PESCI will need
to convince the community to change its mind.
To enable this, as relevant, the ADs, IAB members, and IAOC members
including the IAD will be asked to provide personal input
specifically on the feasibility of implementing the proposed process
changes as they affect their specific roles.
- forward proposals for approval as BCPs* and acceptance by the ISOC
Board. Until such time as the new process for process change has
been approved, the proposals will be submitted directly to the
General Area Director and the approval body will be the IESG.
However, the IESG members' principal chance to comment on and
influence the proposals is prior to their forwarding for approval.
*An alternative would be to use the mechanism described in RFC 3933,
if consensus was weak. In particular, this can be used to experiment
with the practicality of ideas.
Additional conditions for PESCI's work
- a subsidiary goal is to end up with a clearly defined and
interlocked set of process documents, rather than a patchwork of
updates to existing documents
- PESCI will provide an open mailing list where discussion with the
community will be encouraged. It will issue regular (monthly?)
progress reports and generally operate as transparently as possible.
Discussion in IETF plenary sessions is also expected.
- nothing in this proposal prevents ongoing operational improvements
within the current process.
Davies Expires April 26, 2007 [Page 13]
Internet-Draft PESCI Goals and Guidelines October 2006
Author's Address
Elwyn Davies (editor)
Folly Consulting
Soham,
UK
Phone: +44 7889 488 335
Fax:
Email: elwynd@dial.pipex.com
URI:
Davies Expires April 26, 2007 [Page 14]
Internet-Draft PESCI Goals and Guidelines October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Davies Expires April 26, 2007 [Page 15]