Subject: Community Collaboration, versus Central Management

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2004 16:21:54 +0900

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>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 4 Mar 2004 06:21:39 -0500

> This will probably devolve into a yes-you-did, no-i-didn't exchange,
> thereby nicely distracting us all from the focus of my posting.

For my part, I fess up.

> However, just so no one thinks that I constructed these:
> 
> This was said by Jon Peterson, in the IMPP working group, before he
> became an area director.

I fear that Mr. Crocker portrays my remark here a bit too generously. In
fact, I said something even more radical - that the documents authored by
participants in the IETF are, essentially, ghostwritten for the IESG; that
the IESG, since they make the decision to standardize these documents, are
ultimately responsible for document content. But I think the citation above
is sufficiently close to the spirit of what I said. The context of this
discussion was a dispute about whether or not we should follow IESG guidance
on a particular proposed change to an IMPP working group item (I believed we
should, and Mr. Crocker disagreed).

At the time, Mr. Crocker told me that I was quite wrong about the role of
the IESG, and that he and I would revisit this issue some time in the
future. I am glad that he has chosen to remind me of it now. It would take
someone about five minutes as an Area Director to see how misguided my
perspective had been: to see how forceful pushback on IESG guidance from the
community can be, and to see that the enormity of the review task makes IESG
'ownership' of document content infeasible, even if it were desirable.

Of course, reflecting on my pre-IESG self, I still see the logic in my
former perspective. The quickest path to standardization is to tailor
documents to the tastes of the IESG. What I didn't understand so well then,
I think, is that these "tastes" are the norms of the community, as the IESG
see them. In those cases where the guidance of the IESG does not reflect the
norms of the community, I have found that comments or discusses are easily
overcome by document authors.

Given the change in my own perspective, I had flattered myself that I had
finally become enlightened enough to share Mr. Crocker's view. But it seems,
Dave, that you and I are destined never to be on the same page. There's no
question in my mind today that we live in a bottom-up organization.

Jon Peterson
NeuStar, Inc.