My thoughts about the problems of the IETF

Keith Moore moore at cs.utk.edu
Wed Apr 16 13:29:54 CEST 2003


> Problem: The IETF runs on personal relationships

There are several very important points in this section, some of with
which I agree and others that I at least question.

- I agree that the dependence on personal trust doesn't scale.
- I agree that interpersonal trust isn't transitive, so the fact
  that a chair trusts his AD doesn't mean that the WG members
  trust the chair's trust of the AD's trust of the IESG.
- I agree that the need for interpersonal trust severely hampers our
  ability  to choose leaders such as WG chairs or ADs.
- I agree that the dependence on personal memory, rather than 
  institutional memory, makes changes in personnel more costly.

- I don't see how technology (in a general sense) is useful as part of a
  solution. In  general  I think an over-reliance in technology is more
  dangerous  than an over-reliance in interpersonal trust.  However
  specific  mechanisms might be useful.  e.g. the IESG document tracker
  helps  provide increased visibility and decreases the reliance that is
  placed in interpersonal trust.

- I don't see interpersonal trust as a problem - I see over-reliance on
  interpersonal trust as a problem.  In other words, we haven't figured
  out how to write charters, recruit workers, find chairs, or design 
  processes that consistently produce good results - where
  'good' includes such varied concepts as correctness, efficiency, ease
  of implementation, freedom from IPR encumberances, market fairness, 
  and appropriate impact on affected parties.  So we expect "trusted 
  people"- people whom we know to have done this sucessfully in the 
  past- to take up the slack.  This puts a huge burden on those people,
  who are in short supply.  To me this means we need to figure out how
  to adapt our processes so we can place more trust in their output.
  But I don't think any of this will obviate the need for interpersonal
  trust. 

> Problem: Technology "Focus" is Designing for Stagnation

Mumble.  we definitely need to realize that our current processes don't
scale to our current size.  but we also need to keep in mind that any
organization needs to have a focus if it's going to be useful. I don't
think it's necessarily desirable to try to re-design IETF so that its
management structure can scale to accomodate several thousand
participants, especially when one of IETF's biggest problems is its
inability to keep narrowly-focused working groups from producing results
that harm others.

>      * We blinker the view of our own engineers in their
>        core fields, because they lose touch with what the
>        Internet is truly being used for; we then run the
>        risk of "fighting the last war" and optimizing
>        "our" parts of the Internet for applications that
>        just aren't there.

IMHO, an even greater danger is optimizing the Internet for only
those applications that are "there" _now_, or are widely visible _now_ -
and thus pessimizing the Internet for less visible but
important applications in the present, and precluding new applications
in the future. Indeed it's precisely this kind of optimization - of
which NATs are a prime example - which is causing the Internet to
stagnate.  There's more than one kind of blinder here - there's the
blinder of old folks who can't get accustomed to new ways of doing
things even when they make sense, and the blinder of new folks who have
learned to use "the web" in specific ways without appreciation for the
underlying architecture.

>      * We encourage the growth of other standards
>        organizations, many with different participation
>        models than the one the IETF uses. 

...and some with similar participation models.  I think it's far more
constructive for IETF to try to be as useful as possible within its
chosen area, than for IETF to worry about how to discourage growth of
other standards organizations.  and we can hardly blame other
organizations from trying to learn from IETF's strengths - and
weaknesses - and to select or change their models accordingly.  but we
should try to learn from those also.

>    I personally believe that if the IETF management were
>    structured in such a way that adding new work items
>    when it makes sense to do them in the IETF, the IETF
>    would be a more dynamic and flexible organization,
>    where it was easier to get work done.

within reason, I agree.  but along with figuring out how make IETF scale
to a larger size we would also need to figure out what "makes sense to
do in the IETF" - in other words, we need to better define IETF's scope.


> Problem: The AD job can't be done well

entirely agree.

> Problem: The range of knowledge required of the IESG is too
> large

I don't really agree with this - I think that even for a restructured
IETF to be successful and produce good quality output, it will still be
essential to have a steering group and review board of about the
size of the current IESG, that consists of generalists.  If anything,
we need more people looking at the big picture (some short-term, some
long-term).


I might restate this problem as saying that we're expecting IESG to know
about too many details - in other words, IMHO the range of knowledge
we're expecting from IESG is about right, but we're expecting IESG
generalists to do too much detail work.  It's not so much a problem for
IESG people to be knowledgable about the diversity of issues Harald
mentions -- but it *is* a problem to expect IESG people to perform
detailed evaluation of potential solutions to those issues, or worse,
to _author_ detailed technical solutions to those issues (which IESG
people sometimes find themselves having to do merely in order to get
closure on those issues in finite time.  for example, when WGs get
pushback from IESG that there's a technical problem, they often refuse
to fix the problem themselves and demand that the AD dictate the
solution to them)

> Problem: The IESG is too big to manage the IETF effectively

and it's too small.  or maybe it's just right.  

(should we replace IESG with three bears and a little girl?)

I suspect if we can remove some of the burden from IESG then the size of
IESG becomes a tad less critical.


Keith


More information about the Problem-statement mailing list