version 0.2 - http://www.alvestrand.no/ietf/issues.html
This list came about by reading a discussion on the wgchairs mailing list, October/November 2002.
The thread was started by a call for volunteers in helping draft a problem statement, but quickly turned into a discussion of what the problems were.
In the list below, I have tried to succintly reduce each issue to one sentence - since I'm doing duplicate suppression, many people will not see THEIR name in the list, but there are undoubtedly many who would add their names to the statements if they had the chance.
The list below attempts to group the problems into somewhat-related groups.
At the moment, we collectively accept almost any working group, and allow them to produce almost any result. (Joel Halpern)
I-Ds that are of the "wouldn't it be a good idea if this worked" type confuse the process (Eric Burger)
Insularity is unavoidable given the large number of working groups (Melinda Shore)
There are no roadmaps for areas or other large chunks of the architecure, just for WG efforts (David Harrington and others)
Too little architectural guidance in the IETF (Carl-Uno Manros)
It is impossible to define a single architecture for the Internet (Brian Carpenter)
Individuals' behaviour has changed (less commitment)? (Aaron Falk)
Less consensus on what parts of the IETF's work is "core" and "critical" (Aaron Falk)
Consensus process is not working, or is too slow, due to lack of interest in the common good (Melinda Shore)
What consensus means has been lost, or the spirit of consensus is missing (Edward Lewis)
Discussions in WGs turn into battles along "party lines" between companies, not an effort towards interoperability (Edward Lewis)
Heavy investment in alternatives pre-standardization leads to vested interest in outcomes, preventing consensus when there is no clear technical lead
Ratholing over fundamental disagreements on the goals of the process leads to bog-down; requirements documents can sometimes help avoid this (Tony Hain)
WG process is too slow, because of feeping creaturism, deadlocked conflicts or lack of worker bandwidth (Jari Arkko)
It's not possible to identify the time when major changes to an I-D set are unlikely, so that it's reasonably safe to start designing implementations (James Luciani)
Mailing lists are not (always) an effective tool (Aaron Falk)
Large groups don't interact well enough to form consensus (James Kempf)
Large WGs means that we get more groupings of intrasingent people, leading to difficulty with consensu (Donald Eastlake)
Mailing lists with large numbers of postings (500 in a week, for instance) are hard for peole to follow (Thomas Narten)
People sticking to fixed positions on mailing lists leads to lots of mail but no consensus (James Kempf)
Maintaining decorum and forward progress on a mailing list is not easy (many)
Problems (for instance security) get discovered at IESG time, not earlier (Randy Bush)
Not enough guru bandwidth for appropriate security review (Derek Atkins, Steve Bellovin)
WGs are not dilligent enough in ensuring quality control (Randy Bush)
Too little clarity and brevity in WG output (Aaron Falk)
Lack of running code means that unimplementable specifications get on track (Kurt Zeilenga)
we think there are cases where things go to Proposed Standard specifying
things that can't work.
One way to avoid that is to insist that someone try it before submission.
(Harald Alvestrand, summarizing)
Authors/editors do not understand what makes a document Good; they should be trained (Avri Doria)
There are a number of issues surrounding MIB modules (Bert Wijnen)
Predictability, Accountability, Competency and Timeliness are important to the IETF, and we don't have enough of them (draft by Marshall Rose, Geoff Huston)
Time from WG finished to IESG approval is too long
Queueing delays inside the IETF process are far too long (Don Eastlake)
(suggests that 1-2 months is most often a non-problematic delay, but that 1 year
is a disaster)
poor quality documents tend to act as DoS attacks... sucking away process/review bandwidth from quality documents. (Kurt Zeilenga)
For any X in the IETF process (WG, IESG, RFC Editor), it takes too long (David Meyer)
The process' slowness means that I-Ds take on the force of a standard (Eric Burger)
Lack of transparency makes it hard to diagnose what the organization's problems are (Hilarie Ormond)
IETF process is opaque, and therefore hard to coordinate with (Dean Willis)
Not enough information for the WG chairs or authors to identify the IESG concern and effect the resolution in a timely manner (Dean Willis)
Architectural decisions with IETF-wide impact doesn't get adequate community review (Margaret Wasserman)
Few people review drafts in IETF Last Call (Avri Doria)
We're not using the three-stage standards process as designed (Spencer Dawkins)
We as a community are not following the rules we set for ourselves (James Luciani)
It's hard to get a discussion going when the IAB works on architectural considerations (Rohan Mahy)
Documents that bypass the WG process sometimes have huge impact on the work we have to do (Glenn Parsons)
Some consider IAB architectural guidelines/question to be "meddling" by "outsiders" (Melinda Shore)
We don't have well-defined success criteria, and don't measure the ones we could have (Bernard Aboba)
We should act like the engineers we claim to be and measure things to determine if there are problems (Frank Kastenholz)
Trying to measure the progress of the IETF doesn't gather enough interest to be worth it (Marshall Rose)