Network Working Group E. Davies, Ed.
Internet-Draft Folly Consulting
Expires: April 19, 2006 October 16, 2005
Goals and Principles for IETF Process Evolution
draft-davies-pesci-initial-considerations-00
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 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document identifies a set of goals and principles for the next
stages in revising and updating the Internet Engineering Task Force
(IETF) process for developing standards and other specifications. It
does not propose specific changes to the process, which should be the
subject of future documents. It suggests a strawman for the way in
which process changes could be specified and identifies some initial
target areas for process change.
Davies Expires April 19, 2006 [Page 1]
Internet-Draft PESCI Principles October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Principles, Policy, Process and Procedure . . . . . . . . 3
1.2. About This Document . . . . . . . . . . . . . . . . . . . 4
2. Background reading . . . . . . . . . . . . . . . . . . . . . . 4
3. Short problem analysis . . . . . . . . . . . . . . . . . . . . 5
4. High Level Goals and Principles of IETF Process Change . . . . 7
4.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Desired Outcomes . . . . . . . . . . . . . . . . . . . 7
4.1.2. Change Management Guidelines . . . . . . . . . . . . . 8
4.2. Principles to be Considered . . . . . . . . . . . . . . . 9
4.2.1. Development and Authorisation of the Changed
Processes . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. The Content of the Changed Processes . . . . . . . . . 10
4.2.3. Management and Leadership in the Changed Processes . . 10
4.2.4. Individual Participants . . . . . . . . . . . . . . . 11
4.2.5. Protocol Parameter Assignments . . . . . . . . . . . . 12
4.2.6. Areas . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.7. Working Groups . . . . . . . . . . . . . . . . . . . . 12
4.2.8. Extended Review . . . . . . . . . . . . . . . . . . . 13
5. The Arena for Change . . . . . . . . . . . . . . . . . . . . . 13
5.1. Components Not Considered for Major Change in this
Document . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Components Considered for Major Change in the Document . . 15
6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Change Process Proposal . . . . . . . . . . . . . . . . . 18
6.2. Immediate Tasks for the Change Process . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Raw principles . . . . . . . . . . . . . . . . . . . 21
A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
A.2. Management and Leadership . . . . . . . . . . . . . . . . 22
A.3. Documents (may change after techspec BOF) . . . . . . . . 23
A.4. Intellectual Property . . . . . . . . . . . . . . . . . . 24
A.5. Protocol Parameter Assignments . . . . . . . . . . . . . . 24
A.6. Working Groups . . . . . . . . . . . . . . . . . . . . . . 24
A.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. PESCI Announcement . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Davies Expires April 19, 2006 [Page 2]
Internet-Draft PESCI Principles October 2005
1. Introduction
This document identifies a set of goals and principles for the next
stages in revising and updating the Internet Engineering Task Force
(IETF) process for developing standards and other specifications. It
does not propose specific changes to the process, which should be the
subject of future documents. It does, however, suggest a strawman
for the way in which the process changes could be specified and
identifies some areas of current IETF process that appear to be the
most urgently in need of improvement in the light of problems
previously identified. It has been produced by a design team
selected by the IETF Chair and is submitted to the IETF community for
discussion, modification, and hopefully approval.
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. This document attempts to set the scene for
focused work to change only those specific aspects of the IETF
process that need change, by identifying goals and principles that
can be expressed simply and can potentially reach consensus in the
community.
1.1. Principles, Policy, Process and Procedure
Before going on to discuss process change we should be clear about
what we mean by "process", and 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 and "rough consensus and running code" as
an operating principle. This document attempts to
capture a large subset of these principles relevant to
the issue of process changes (see Section 4.2).
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.
Davies Expires April 19, 2006 [Page 3]
Internet-Draft PESCI Principles October 2005
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.
Procedures are normally developed by the people doing the
work, and documented and published as these bodies feel
it appropriate.
1.2. About This Document
This document was produced by the PESCI design team selected by the
IETF Chair and is submitted to the IETF community for discussion,
modification, and hopefully expeditious approval. 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
has no special status in the IETF process; it is simply the group of
people who produced this document under the leadership of the IETF
Chair.
Discussion of this draft is welcomed on the pesci-discuss@ietf.org
list (join via https://www1.ietf.org/mailman/listinfo/pesci-discuss).
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.
Davies Expires April 19, 2006 [Page 4]
Internet-Draft PESCI Principles October 2005
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).
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
Davies Expires April 19, 2006 [Page 5]
Internet-Draft PESCI Principles October 2005
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)
* 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 loose 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)
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-
Davies Expires April 19, 2006 [Page 6]
Internet-Draft PESCI Principles October 2005
editing, and excessive author changes in AUTH48. There is to be 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. High Level Goals and Principles of IETF Process Change
This section lists specific goals and principles of changing the IETF
process for developing standards and other specifications. 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.
In this section the team has concentrated on goals and principles
that specifically concern change to the process. However, in some
cases this is hard to do (for example, when it seems that a basic
principle is only partly implemented by today's process). The team
expects more refinement and tighter focus in this section as a result
of community discussion.
4.1. Goals
Goals for changing the IETF processes can be separated into
o targets for the end point of the change ( Section 4.1.1), and
o guidelines that should be followed during the creation of the new
processes and the transition needed to put the approved processes
into use (Section 4.1.2).
4.1.1. Desired Outcomes
G1. Identify and document improvements and additions to the existing
processes for developing standards and other specifications to
enable the IETF to be more effective and efficient in the
performance of its mission.
To this end, define and document processes which will:
1. Provide an environment in which the mission of the IETF can
be carried out efficiently and effectively including, but not
limited to, provision of tools, communication mechanisms and
meetings that will take the mission forwards.
2. Deliver, in a timely manner, a set of accurate, consistent,
usable, maintainable, coordinated, and relevant documents
that describe
Davies Expires April 19, 2006 [Page 7]
Internet-Draft PESCI Principles October 2005
+ the architectural principles of the Internet
+ the protocols over which the IETF asserts ownership
+ additions and extensions developed within the IETF for
protocols not owned by the IETF
+ any necessary supporting information and practices.
3. React in a timely fashion to events from internal and
external sources that affect the Internet as a whole and the
document development process.
4. Maintain the quality of IETF output both initially and over
the entire lifetime of a protocol.
5. Deliver visibility of the process to all participants,
together with adequate protections against abuse of the
process by any participant.
6. Maintain metrics which will allow the efficiency and
effectiveness of the processes to be monitored.
7. Provide effective coordination between the various component
structures defined by the process (such as the current IAB
and the IESG) and the individual participants in the IETF.
8. Provide a transition path and continuity in the process of
change, both as regards the processes themselves and the
protocols owned.
4.1.2. Change Management Guidelines
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.
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. Changes to processes should err towards the maintenance of
stability.
G5. Avoid changes that would require unrealistic resources or
behaviours.
G6. Protect the continuity of ongoing IETF work.
G7. As far as possible, minimize simultaneous changes that may
interfere with each other.
G8. Avoid "thrashing" by repeated changes in the same area.
G9. Try to explicitly estimate the impact of changes before making
them, and try to measure whether the expectations were met after
making the change.
G10. 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
Davies Expires April 19, 2006 [Page 8]
Internet-Draft PESCI Principles October 2005
standards).
4.2. Principles to be Considered
When developing, approving and implementing the changes to IETF
standards development processes there are a number of principles that
should be borne in mind. In developing the set of principles listed
in this section the design team took into account a much longer list
of "raw principles" (currently in Appendix A) . This work tries to
abstract from this data the true principles that should be taken into
account. However we would urge both the community and the developers
of the changed processes to look critically at these "principles",
but accept that perfection is impossible (_rough_ consensus is the
aim):
o If good and sufficient reason to reject or modify any of them can
be found, such change should not be a taboo subject.
o The principles, except for those in Section 4.2.1, provide
guidance not constraints or requirements: it is up to the
developers of the changed processes and the community to decide
_how_ these principles should affect the change process or be
enshrined in the resulting changed processes.
o Each principle will be applicable to only a part of the process
changes: if a principle is applicable to some part of the process
changes, the aim should be improvement along the dimension given
by the principle. Aiming for completeness or perfection in one
cut, even on a single principle, is likely to seriously delay
design of the changed processes.
We have endeavoured to keep any element of "solutionism" out of these
principles.
4.2.1. Development and Authorisation of the Changed Processes
This group of principles deals 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
principles appear to be required by our current process, and similar
principles should be true of any future process.
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
Davies Expires April 19, 2006 [Page 9]
Internet-Draft PESCI Principles October 2005
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.
P6. The revised process should be documented in a new set of coherent
and comprehensive documents, rather than updates to the existing
ad hoc set.
4.2.2. The Content of the Changed Processes
This section contains principles relating to what should and should
not be in the revised processes. A minimalist approach is taken to
give the authors of change maximum freedom to do the right thing.
P7. New process rules should be flexible enough to allow unusual
cases to be handled according to common sense.
P8. Parts of the existing process that have proved impractical
should be improved or removed.
P9. The number of steps in the document approval process must be
kept to a minimum subject to adequate review and approval being
carried out.
P10. Document quality criteria, decision criteria, and procedures
that support the process should be publicly documented.
P11. A complete complaints, conciliation, and appeals process for
each decision process should be documented.
4.2.3. Management and Leadership in the Changed Processes
The IETF prides itself on being a technically led organization (i.e.,
our leaders are primarily technologists, rather than managers) with
open processes which can, whenever possible, be challenged by
participants if they feel there has been a miscarriage. This is a
major part of the IETF ethos and altering it would change the IETF
fundamentally. However, if the standards development process is to
be effective, people, process, and technical management skills are
also required. Finding enough technically skilled participants, who
also have these management skills, to populate the leadership
positions is challenging. At present the management of the standards
development process is mostly carried out by WG chairs under the
supervision of ADs with the members of the IAB primarily in the role
of technical consultants and policy setters. The cadre of ADs is
Davies Expires April 19, 2006 [Page 10]
Internet-Draft PESCI Principles October 2005
relatively small and the work that they do is so different in
character from that of WG chairs that it is difficult for
participants to acquire the skills needed for the AD task other than
by doing it: this can make new ADs relatively inefficient.
P12. All decisions are subject to appeal using the procedures
documented in the processes.
P13. Management and leadership of the standards process should be
predominantly carried out by people who are technically
competent in the area in which they are leading, and the
processes should ensure that people in leadership positions
remain knowledgeable about the state of the art (and beyond) in
their areas of responsibility. At the highest levels, overall
architectural awareness of the Internet become at least as
important as technical expertise in a particular speciality.
P14. The processes should ensure that it is possible for IETF
participants to acquire or hone the particular skills needed for
management and leadership positions in the IETF before taking on
these positions, for example by forms of apprenticeship. "On
the job" training is valuable but we should try to give it in
such a way that leaders are as productive as possible as soon as
they are appointed.
P15. The processes should seek to give opportunities to as many
people as possible to participate in management of the process
outside the narrow technical confines of a single working group,
in order to increase the pool of people available for choosing
leaders.
P16. The processes should ensure that, so far as is possible, the
pool of skills and experience developed by those in leadership
and management positions remains available to the IETF and
continues to be seen to be valued whilst giving these leaders a
period to refresh their skill in the technical arena.
P17. Selection of IETF leaders and managers should be by a competence
based process which is, subject to the needs of individual
confidentiality, open and independently verifiable.
P18. Leadership positions should be defined such that the workload is
compatible with other employment and personal life. Very few
leadership positions should require effective full time work.
P19. The amount of work needed to select the IETF leaders and
managers should not be disproportionate. To this end the number
of posts involved should not be allowed to grow without limit
and the size of the selection panel should be constrained.
4.2.4. Individual Participants
The IETF is extremely unusual in that it has no formal membership.
Participants are self-selecting and involvement is by the
individual's choice. There is no formal mechanism for outside
Davies Expires April 19, 2006 [Page 11]
Internet-Draft PESCI Principles October 2005
corporate entities to affect IETF decisions, although there are
arrangements for exchange of "liaisons" with other recognised
standardisation organisations.
P20. IETF processes should make it as easy as possible for
individuals to participate fully in standards development work
with no discrimination on the basis of race, religion,
nationality, country of residence, gender, sexual orientation or
disability.
P21. Official IETF work is carried out exclusively in the English
language.
P22. Individual participants need not physically attend any meetings
to participate in standards development work.
4.2.5. Protocol Parameter Assignments
This section contains principles which relate to the way in which
IANA registries are established and the processes by which additional
values can be registered.
P23. The IETF functions of the IANA must be under IETF control.
4.2.6. Areas
Areas have become a fundamental structuring mechanism for IETF work
since the Kobe reorganization. Area Directors (ADs) are at the
moment the central focus of management and technical expertise in the
IETF.
P24. The IETF needs a wide breadth of expertise in its participants
and those who supervise its processes. Providing a number of
more concentrated foci for that expertise (which might be called
"specialities") allows participants to discuss their interests
with like minded people.
P25. Besides experts in particular areas, it is important that the
IETF also takes an architectural view and encourages
participants who are able to work at the overall architectural
level both to direct the standards development work in the IESG
ambit; and to set technical guidelines internally, monitor
technical developments in the research and commercial world out
side the IETF and interact with external groups.
P26. Areas must not become isolated "silos" in which work is carried
out in isolation from other specialities.
4.2.7. Working Groups
The chartered Working Group (WG) normally led by two WG co-chairs is
the way in which the IETF organizes units work. It has proved a
Davies Expires April 19, 2006 [Page 12]
Internet-Draft PESCI Principles October 2005
durable structure and when working well appears to be an effective
way of doing standards development.
P27. WG Chairs are responsible for ensuring that WGs execute their
charters, meet their milestones, and produce deliverables that
are ready for publication.
P28. WGs should be primarily responsible for the quality of their
output, and for obtaining and responding to cross-area and other
external review.
4.2.8. Extended Review
The SIRS experiment and the General Area review team have shown the
value of extended, cross-area review of documents. Currently most
such review is carried out too late in the document life cycle for
best effectiveness.
P29. It is essential that standards documents are not developed in
isolation and that the effects of a particular proposal on other
areas needs to be taken into account through consultancy and
review by people outside the particular speciality developing
the standards.
P30. Extended review, and review in general, should be carried out
starting as early as possible in the life cycle of the document.
P31. Documents should not be presented for approval outside a working
group until after successful cross-area review.
P32. The new processes should provide means to ensure that cross-area
review can be carried out effectively.
5. The Arena for Change
The IETF operates through a number of organizational components, some
of which have been relatively stable (such as the IAB and the IESG)
as regards their functions and processes since the Kobe
reorganization in 1992 while others (such as IAOC and IASA) have a
more recent genesis. The design team looked at the various bodies to
see how standards development process change should or ought to
affect the components. In some cases major structural change as a
result of these changes is either inappropriate or out of scope. The
rest of this section considers the various components divided into
those areas that it appears should be maintained with only peripheral
changes and those areas that might be more heavily affected by any
proposed process changes.
5.1. Components Not Considered for Major Change in this Document
In drawing up the high level goals and principles presented in
Davies Expires April 19, 2006 [Page 13]
Internet-Draft PESCI Principles October 2005
Section 4 we consider that there are a number of fixed points in the
overall organisation and operation of the IETF that are either
outside our control, have served it well or have been recently put in
place and are unlikely to need wholesale change. This group has not
considered changes that would involve changing the responsibilities
of these bodies but some of their responsibilities and interactions
with other bodies may need modification as part of the process
changes.
ISOC ISOC acts as IETF's legal parent and guarantor. This
process is not at liberty to change the relationship
between ISOC and IETF. The ISOC board acts as court of
final approval for some processes (such as appointments to
IAB) and backstop for appeals in all processes. This
should not change although it might be appropriate to
consider the route by which appeals and approvals reach the
ISOC board. Their seal of approval will be needed on any
major process changes that may result from this effort.
IAB The main function of the IAB is architectural oversight of
developments in the Internet. This includes monitoring
standards development work to ensure that it does not
adversely impact the existing Internet, setting guidelines
for architectural aspects of development, helping to
determine what new working groups should be chartered,
keeping a watching brief on technical developments outside
the IETF, and providing statements on such developments as
appropriate.
The IAB currently acts as the second line of appeal for
decisions of the IESG on standards development and other
matters. This function is not an ideal fit with the
general architectural remit of the IAB: the competencies of
the IAB members do not necessarily equip them to deal with
the process appeals that come to them from the IESG. Some
of the members of the IAB may consider them a distraction
from their architectural role.
IAOC/IAD/IASA
The administrative functions of the IETF are now handled by
these structures. They are recently in place and until
they have been given chance to "bed in" it would be
inappropriate (and costly) to alter these structures and
their internal relationships. However this does not say
that what the administrative function does cannot be
altered. The changed processes will almost certainly
require some additional or changed functions from the
administrative functions.
Davies Expires April 19, 2006 [Page 14]
Internet-Draft PESCI Principles October 2005
IRTF The Internet Research Task Force (IRTF) will continue to
exist in parallel with the IETF and sharing many of the
administrative functions. The documents that it produces
add a small amount to the document approval and processing
load.
RFC Editor
The RFC Editor provides the back end processing for all
documents from approval to publication. The techspec BOF
is considering how this process can be improved and it will
not be considered further here.
IANA The Internet Assigned Numbers Authority provides all the
registry facilities for IETF protocols according to
criteria and guidelines laid down by the IETF. IANA is
likely to continue in existence. The processes which need
to be carried out to establish and maintain these
registries can be considered as part of the process
changes.
5.2. Components Considered for Major Change in the Document
The following components are structures that have served the IETF
well, and are likely to be part of whatever structure is suggested by
the effort which follows on from the publication of this document.
However, the ways in which they are put together and how
responsibility is divided amongst them may need to change as part of
this process. Likewise, this should not be seen as constraining the
changes that may be suggested: alternative or additional structures
could take on part of the functions that are needed.
IESG The IESG is central to the processes of standards
development in the IETF. The steering role of the IESG in
acceptance of new work, formation, and chartering of WGs,
monitoring of WGs, and final stages of document processing
seems to be appropriate, as it is essential to coordinate
these functions. This does not imply that the IESG must be
solely responsible for final cross-area review.
The problems which the IESG is seen to encounter in these
jobs appear to be related to the amount of work involved
especially in reviewing documents. This is at least
partially due to a lack of technical assistance for most
ADs giving them no easy way to delegate parts of this work
and making it difficult for them to operate "management by
exception".
Another area where process changes might lead to greater
confidence in the standards development process is the
Davies Expires April 19, 2006 [Page 15]
Internet-Draft PESCI Principles October 2005
degree of self-regulation which the IESG exercises: in many
process related disputes the IESG is expected to act as
judge and jury on actions in which it is itself involved.
Areas The partition of expertise in standards development into a
number of areas appears to be a useful way of providing
foci for participants and structure for an extremely wide
technical field.
Currently there is only informal recognition that not all
areas are born equal. The cross-area role of the security
ADs and the interaction of the transport standards with
most higher and lower layer standards means that the "out-
of-area" loads on the security and transport area ADs are
highly significant and there is little formal support for
them in carrying out this extra work. Operations work is
also a key cross-area function.
The effect of the current rigid structuring of work into
areas is something which has not been much considered. It
is possible that the way in which the IESG is made up of
ADs, basically two per area, with the ADs managing the
working groups exacerbates some of the IETF's problems:
* Management "fan-out" constraint: The management capacity
of the area ADs artificially limits the amount of work
that can be carried out in an area - an active area
might really need more working groups than can be
realistically handled by the fixed set of ADs. However,
any increase of management capacity that might result
from process changes should not inhibit critical
assessment of any proposed new work both as to value and
its likely effect on the overall architectural
cohesiveness of the IETF work.
* Management "fan-in" overload: The number of working
groups is expanded to and often beyond the point at
which two ADs can successfully manage and review the
output of those working groups on their own, but there
is little formal delegation of such work which could
possibly reduce this overload.
* ADs are primarily specialists: The concentration on area
specialisms may lead NOMCOM to appoint people who are
primarily specialists to AD positions rather than those
with an over-arching architectural view. This may lead
to the overall attitude of the IESG de-emphasising
architectural effectiveness.
* Area Workload Imbalance: Areas are not born equal. The
appointment of the same number of ADs in all areas leads
to even greater overload in some areas.
Davies Expires April 19, 2006 [Page 16]
Internet-Draft PESCI Principles October 2005
* Areas can be a straitjacket: If some work naturally
falls across speciality boundaries it may be difficult
to fit it into the area model so that it either gets
distorted to fit the model or does not get carried out
at all (in the IETF). It is conceivable that this at
least part of the reason why the IETF does not seem to
be good at solving complex problems.
* Area silos raise the stakes on cross-area review:
Working groups and their participants effectively live
in a single speciality environment. Cross speciality
working does not come naturally so that cross-area
review becomes more of a big deal paradoxically making
it more difficult to ensure it is done just when the
need for it is greatest.
The current area directorates are fairly informal
organisations and are, in most cases, not formally involved
in the management process (MIB doctors and the general area
reviewing team are exceptions). They could be a much
bigger resource for ADs and specialities.
IETF Chair
The IETF Chair also currently wears the hats of chair of
the IESG and AD of the General Area. This multiplicity of
jobs can lead to an overlap of roles and conflicting skills
requirements in the single holder of the posts. Serious
consideration should be given to splitting the posts
between two (or more) people.
Working Groups
Working Groups appear at base to be a successful way of
carrying out an agreed charter of standards or other
development work.
The main areas for concern here are ensuring high quality
output and maintaining momentum over the period of
development, particularly in the later stages when the
creative work is essentially finished and the work is
mainly polishing. Active management by supervisors
together with more rigorous and earlier review of documents
seems to be required. Taking work through from initial
standardisation to full standard appears to be difficult to
achieve, The newtrk group may have some input here.
NOMCOM The NOMCOM provides the means of selecting leaders and the
volunteer managers for the IETF. The process by which this
is performed is time consuming and could be considered
onerous for participants, but it is vital that the process
remains as open as possible and endeavours to keep the IETF
Davies Expires April 19, 2006 [Page 17]
Internet-Draft PESCI Principles October 2005
as free of undue external influences as possible.
Changes to these processes should ensure that overlaps of
role (as regards those performing the selection and the
leaders being selected) do not arise and that the workload
of the NOMCOM does not get out of hand.
6. Next Steps
What the PESCI design team propose should be done next:
We believe that an early proposal is needed for a new process for
developing changes to the IETF processes especially in the area of
developing standards documentation and other specifications.
This proposed new process
o would be used by all individuals, design teams, and working groups
who wish to propose changes or additions to IETF processes,
o should involve consultation with the IESG, the IAB, the IAOC, the
Working Group chairs, and IETF participants generally, but
o must avoid requiring the IESG to develop the new processes or
micromanage this process of development and approval.
The new proposals, both for the change process and any resulting
changed processes, should be implemented as a matter of urgency and
should be handled expeditiously by the existing approvals and
publishing process.
6.1. Change Process Proposal
We propose that the design team model is the most effective way of
engineering process changes. Within the context of the existing IETF
process, this could be arranged by constituting a set of design teams
with appropriate oversight and the charter of carrying out process
change. The design teams would operate within these charters: the
overseers would invite design team members to participate, but
alternative teams could offer solutions if they feel they have better
solutions.
The teams should function with an open discussion list, in the same
way that the PESCI committee has done. The result of the committee
should be tested against the IETF consensus in the normal fashion; we
believe that if there is clear IETF consensus that the proposal makes
sense, the IESG (and the ISOC Board of Trustees) will respect that
consensus and approve of it.
Davies Expires April 19, 2006 [Page 18]
Internet-Draft PESCI Principles October 2005
6.2. Immediate Tasks for the Change Process
Assuming that the model suggested in Section 6.1 is adopted, the
following process change task appears to be the most urgent one, and
a team should start on this as soon as possible.
The most important single management role in the IETF at the moment
is that of the IESG, including the role of IETF Chair. This should
therefore also receive the most scrutiny. It's unreasonable to ask
people to grade their own performance, or to attempt to perform a
role at full speed while having to review how it could be done
otherwise. Therefore, a review of the roles the IESG has should be
rooted outside the IESG - while asking current and former IESG
members for information and advice at every opportunity.
This should include:
o Creating a list of the tasks that currently gate on the IESG
o Identifying any additional related tasks that might be appropriate
to improve efficiency and effectiveness
o Making proposals for discarding or restructuring the existing
tasks in combination with the new tasks
o Making a proposal for grouping those tasks into separate task
groups that can be assigned to different bodies at need.
o Developing a proposal for how the standards development work of
the IETF should be partitioned to provide optimum efficiency while
allowing the IETF to take on all appropriate work.
o Developing a suggestion for an initial set of bodies for handling
those tasks in the new work partitioning scheme, including, if
appropriate, a restructuring of the IESG.
o Describing the process by which the set of bodies gets modified.
o Describing how members of the proposed bodies get selected,
replaced, and (if needed) removed.
7. 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.
8. IANA Considerations
This document does not require action by the IANA. However, IANA
Davies Expires April 19, 2006 [Page 19]
Internet-Draft PESCI Principles October 2005
activities do form part of the IETF process and process changes may
affect IANA.
9. 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.
10. Informative References
[I-D.carpenter-procdoc-roadmap]
Carpenter, B., "The IETF Process: a Roadmap",
draft-carpenter-procdoc-roadmap-02 (work in progress),
October 2005.
[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,
Davies Expires April 19, 2006 [Page 20]
Internet-Draft PESCI Principles October 2005
February 2004.
[RFC3774] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[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. Raw principles
This Appendix is a laundry list of items, not all of which can
properly be called principles. Some of them are indeed basic
principles, others simply reflect current practice, and yet others
summarize recent proposals for change. The purpose of the list was
to act as raw material for PESCI in searching for general principles
for changing the IETF process, and it is presented here as a matter
of record.
A.1. General
R1. The IETF works by an open process and by rough consensus, and
this also applies to process changes. But the IETF also observes
experiments and running code with interest, and this should also
apply to process changes.
Davies Expires April 19, 2006 [Page 21]
Internet-Draft PESCI Principles October 2005
R2. The IETF works in areas where it has, or can find, technical
competence.
R3. The IETF depends on a volunteer core of active participants.
R4. Membership of the IETF or of its WGs is not fee based, nor
organizationally defined, but is based upon self-identification
and active participation by individuals.
R5. There is a question of principle of how the IETF, which only
recognizes individuals, deals with technical input that comes
from another standards organization, i.e. does it get extra
weight because it represents collective thinking from a peer
group?
R6. While the IETF needs clear process rules for the normal cases,
there should be enough flexibility to allow unusual cases to be
handled according to common sense. We apply personal judgment
and only codify when we're certain. (But we do codify who can
make personal judgements.)
R7. Parts of the process that have proved impractical should be
removed or made optional.
A.2. Management and Leadership
R8. The IETF recognizes leadership positions and grants power of
decision to the leaders, but decisions are subject to appeal.
R9. The leaders may and should delegate power and responsibility, so
long as this is made public and remains subject to appeal.
R10. Appeals stop at the IAB and exceptionally the ISOC Board. As a
fact of life, there are decisions that can't be *effectively*
appealed. But dissent, complaint, and appeal are a consequence
of the IETF's nature and should be regarded as normal events.
R11. Decision criteria and processes should be publicly documented.
R12. Leadership positions are for fixed terms (although we have no
formal term limits).
R13. People should cycle through leadership positions rather than
making them a career. [klensin proposal] Stints of more than
four years should be considered exceptional.
R14. Leadership positions should be defined such that the workload is
compatible with other employment and personal life. Very few
leadership positions should require effective full time work.
R15. It is important to develop future leaders within the active
community.
R16. A community process is used to select the leadership.
Question: can we devise something better than the random
selection of NOMCOM members?
R17. The primary consideration in selecting the leadership is
personal ability to do the job. (Employer consent to execute
the workload is close behind.)
Davies Expires April 19, 2006 [Page 22]
Internet-Draft PESCI Principles October 2005
R18. Leaders are empowered to make the judgement that rough consensus
has been demonstrated. Absent formal membership, there are no
formal rules for consensus.
R19. The technical leadership is subdivided into
* The ADs, assembled as the IESG
* [klensin proposal] The Review Panel
* The IAB
* The IETF Chair
* The WG Chairs (appointed by the ADs)
R20. The IAB is responsible for architectural oversight, which should
include supporting ADs in their guidance and direction roles.
R21. [carpenter proposal] It is desirable to separate the role of the
IETF Chair from that of chairing the IESG. (Note to ADs: not
because I don't like you; indeed it isn't obvious which of the
two jobs I'd pick in free space - BC)
A.3. Documents (may change after techspec BOF)
R22. IETF documents often start as personal drafts, may become WG
drafts, and are approved for permanent publication by a
leadership body independent of the WG or individuals that
produced them.
R23. IETF documents belong to the community, not to their authors.
But authorship is recognized and valued, as are lesser
contributions than full authorship.
R24. Technical quality and correctness is the primary criterion for
reaching consensus about documents.
R25. IETF specifications are not considered to be satisfactory
standards until interoperable independent implementations have
been demonstrated. (This is the embodiment of the "running
code" slogan.) But (on legal advice) the IETF doesn't take
responsibility for interop tests and doesn't certify
interoperability.
R26. IETF specifications may be published as Informational,
Experimental, Standards Track, or Best Current Practice.
R27. IETF processes are currently published as Best Current Practice.
R28. Useful information that is neither a specification nor a process
may be published as Informational.
R29. Obsolete or deprecated specifications and processes may be
downgraded to Historic.
R30. The standards track should distinguish specifications that have
been demonstrated to interoperate.
R31. Standards Track and Best Current Practice documents must be
subject to IETF wide rough consensus (Last Call process). WG
rough consensus is normally sufficient for other documents.
Davies Expires April 19, 2006 [Page 23]
Internet-Draft PESCI Principles October 2005
R32. Substantive changes made after a document leaves a WG must be
referred back to the WG.
R33. The IETF determines requirements for publication and archival of
its documents.
A.4. Intellectual Property
R34. TBD
A.5. Protocol Parameter Assignments
P35. TBD
A.6. Working Groups
R36. WGs should be primarily responsible for the quality of their
output, and therefore for obtaining early review; the leadership
should act as a quality backstop.
R37. WGs should be primarily responsible for assessing negative
impact of their work on the Internet as a whole, and therefore
for obtaining cross-area review; the leadership should act as a
cross-area backstop.
R38. Early review of documents is more effective in dealing with
major problems than late review.
R39. ADs are responsible for guiding the formation and chartering of
WGs, for giving them direction as necessary, and for terminating
them.
R40. WG Chairs are responsible for ensuring that WGs execute their
charters, meet their milestones, and produce deliverables that
are ready for publication.
R41. ADs are responsible for arranging backstop review and final
document approval.
A.7. Other
R42. [klensin proposal] It is desirable to separate the work of WG
and process management, including "steering" of the IETF, from
the work of final review of documents.
Appendix B. 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
Davies Expires April 19, 2006 [Page 24]
Internet-Draft PESCI Principles October 2005
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.
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.
-----
Davies Expires April 19, 2006 [Page 25]
Internet-Draft PESCI Principles October 2005
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
- 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.
Davies Expires April 19, 2006 [Page 26]
Internet-Draft PESCI Principles October 2005
- nothing in this proposal prevents ongoing operational improvements
within the current process.
Davies Expires April 19, 2006 [Page 27]
Internet-Draft PESCI Principles October 2005
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 19, 2006 [Page 28]
Internet-Draft PESCI Principles October 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Davies Expires April 19, 2006 [Page 29]