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>