Folks,
Some thoughts for the Thursday night plenary:
What is the basic style of the IETF that we want? An obvious
distinction is between bottom up, versus top down. That is, initiative
and work coming from the community, versus initiative and direction
coming from a hierarchical authority
Both models have plenty of examples in the real world. Both models can
be made to work. Both models have their strengths and their
weaknesses. The one that is chosen needs to match the requirements of
the organization and the personalities of those participating in the
organization.
The IETF has always had a mixture of both. In the beginning, there was
DARPA funding and direction. You can't much more centralized than
that. However the organizational style for most activities was,
instead, a grass-roots approach. The basic style of the IETF has
tended to be that those who do specific work also initiate it and
direct it to its conclusion. The "central management" function used to
be for coordination, for general oversight, and for ultimate quality
control.
In other words, the authority role for the central management function
in the IETF has really been an adjunct, such as for catching errors
that managed to slip through. There is a hallowed tradition for such a
safety-net approach to design in the Internet -- for example, note the
rationale for the weak checksum of TCP.
This safety net role has been essential for imposing limits, and
eliminating unproductive and misguided efforts.
However things have changed. That change was nicely summarized a
couple of years ago by someone who is now an area director. He
said that, really, working groups work for the area director. The
IESG really makes the standards.
So let's be clear about the actual, strategic, historical effect of
IETF management in the real work of producing useful IETF
specifications:
IETF management has never been responsible for initiating any
successful work in the IETF.
All successful work in the IETF has come from community
initiative, that self-forms into a cohesive, productive group.
IETF management can facilitate or impede such efforts, but it has
no track record of replacing it with any sort of top-down model.
This responsibility for initiative and productivity has always rested
with the community. In fact it largely covers the organization and
process of the IETF, itself. What might be taken as process design by
the IETF's central management has in fact come from contributions and
established practise of the general community.
IETF management is an essential part of that community, but only a
part. The "leadership" of IETF management has really been the same as
for the rest of the community: individual leadership through excellent
collaboration.
The real conceptual basis for the process design of the IETF has
always been a reliance on diversity of contribution.
If a wide range of independent contributors participate in a decision,
the odds are pretty good that the decision will be viable. The
different agendas, needs, perspectives and styles of that diverse set
of participants ensure the viability of the result.
There is a very powerful robustness in diversity, if one can figure
out how to corral it into a collaborative process.
A critical danger in central management is an inherent fragility in
decision-making. Real diversity is lost. This becomes even more
serious, as the central management becomes more homogeneous and more
isolated.
Some interesting and unfortunate cliche's have been making the rounds,
recently.
One is a repeated concern that the community should "trust" the IESG.
However we do not hear the balancing concern that the IESG should trust
the community. Or that, in fact, what is really needed is to stop
talking about trust and start working in a collaborative manner.
Collaboration is about leveraging diversity through an open exchange.
Some of the best collaboration comes from the diversity of
disagreement. And, yes, trust. Mutual trust.
If someone says they do not trust you because they usually disagree
with you, then they are missing this essential point. And, indeed,
that appears to be a pervasive problem in the IETF today.
We have an IESG that acknowledges that it is overloaded, yet it seems
intent upon taking on more and more work. We have some urgent,
strategic problems that will not go away and have shown no signs of
getting fixed for two years.
My own version of the urgent needs is:
1. Better quality work, where quality covers such things as
utility and efficiency of the design.
2. More timely work, so its consumers get it when they need it.
3. More accountable lines (and processes) of IETF management, so
that things happen predictably, appropriately, and in the best
interests of the IETF community
4. Stable funding, so that the IETF can attend to its work without
economic distraction.
It is time that we apply some very basic, simplistically rational
questions to any proposed change:
1. Does a proposed change address an urgent, strategic IETF need
that is otherwise posing a serious threat to the viability of the
IETF?
2. Does the proposed change build upon a model of community
collaboration, or does it rely on isolated, central management?
3. Is the proposed change based on well-understood practise that is
known to be applicable to an IETF style of operation?
4. Is the proposed change likely to permit stable IETF operation, or
is it likely to be disruptive?
5. Is the change likely to be compatible with the IETF culture that
we profess?
6. Is the change being pursued in a careful, incremental manner
7. Is the change being modified according to community feedback? Is
it being pursued in a way that develops community rough consensus?
No doubt there are more questions to ask, but the list is already too
long.
As you evaluate tonight's presentations and comments, please consider
these thoughts.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>