A proposal for managing the process of determining the IETF process
History and status
Since 199x, the IETF's process issues have been handled by a couple of
working groups, POISED and POISSON.
POISED finished its initial work of defining the IETF process and was
closed down; POISSON has tackled issues that have occured since that time.
It is a widespread impression that the process currently is not working
Debates in the WG tend to be wide-ranging, contentious, inconclusive and
not terribly well informed; many members of the community are staying away
from the WG because they do not relish the style of dialogue; it takes a
very long time to get consensus on even reasonably simple things.
These are all consistent with the characteristics of long-lived working
groups; in other areas, the Right Thing is most of the time to close the
working group and start over.
This proposal suggests the same thing for POISSON.
A new way of attacking the problem
There are 2 overriding concerns when deciding how to decide policy for the
- The process must be open. Anything else would compromise the essential
nature of the IETF.
- The process must achieve quality results. Anything else endangers the
function and continued existence of the IETF.
The proposal below aims to achieve those two things.
The proposal is funded on the idea that process work is more like an area
than it is like a working group; there are problems that pop up from time
to time, there is a need for a constant ability to address issues, there
are large and small pieces of work that need to be done.
However, the idea of a process area has been tried (and has failed) in the
past; for one thing, there simply isn't enough work around to make it
necessary to have a whole area for it.
Procedural issues are a task of the General Area of the IETF.
The IETF Chair will act as AD for this area, and perform the usual
functions of process management for the process-making process.
There will no longer be a special IETF process list; instead, issues of
interest to the community will be raised on the general IETF list.
This list will be used for pre-charter discussion of new items, as well as
general process issues.
When items of a significant nature are to be considered, working groups
will be chartered as needed. Each group will have a scope limited to one or
a few documents, or portions of documents, will work out or recycle those
documents only, and will then shut down.
WG documents will generally be Last Called in the usual fashion and issued
as BCPs. Non-WG documents will be discussed as needed, on the IETF list or
elsewhere, and will get a 4-week Last Call.
At the pleasure of the IETF Chair, there may exist a directorate to
help in generating coherent plans for the area.
The existence of formalized, short-term working groups may help with the
problem of "WG rot" that has characterized the POISSON effort.
The increased focus may also help with the problem that POISSON has had
with meeting at IETFs: when it is scheduled opposite other meetings, there
will always be participants who have no possibility of attending; in
particular, most of the IESG will be busy in other meetings.
More focused WGs will not need so much attention.
Not having a special "process" list is one of the more uncertain aspects of
The advantages of using the general IETF list are:
- A great number of relevant people are already present on this list
- It is better linked into the community than a process-only list is likely
The disadvantage is that all participants will have to read process-related
discussions whether they are interested or not.
This suggests that the threshold for creating special lists for specific
issues should be rather low, even for documents that do not require the
full apparatus of spinning up a working group.
There is a very real danger that documents that are too small to require a
working group will get inadequate review. This can be ameliorated by:
- discussing the documents on the IETF list
- using 4-week Last Calls, with pointers to appropriate mailing lists
- the ADs requesting independent review of documents
Comments on this proposal are sought; the general IETF list is the list
that this proposal advocates for such comments, but the attempted "process"
list (ietf-process(_at_)lists(_dot_)elistx(_dot_)com) may be more appropriate for detailed
The General AD will monitor all 3 relevant lists, and make a decision on
the proposal no earlier than October 19.