Revised issues list from wgchairs

[Harald Tveit Alvestrand]

I went over the issues list I posted on wgchairs again, trying to sort the 
concerns raised into some groups.

One obvious conclusion is that a list of problems that doesn't talk about 
how WGs operate is incomplete....

HTML at the URL below. Text dump follows.

                   Harald


               Issues/Problems in the IETF process

   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.

The problems

  Problem area/subject matter issues

   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)

  WG process issues

    Who the participants are and represent

   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)

    How the consensus process works

   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)

    How the interaction works

   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)

    Quality control issues

   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)

  IETF management issues (non-WG)

   Predictability, Accountability, Competency and Timeliness
   are important to the IETF, and we don't have enough of
   them (draft by Marshall Rose, Geoff Huston)

    IESG processing problems

   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)

    Community review and coordination problems

   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)

  Reform process issues

   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)