> > Merely calling something or someone a name like sclerotic or dillitante > > is unconvincing. You haven't seen a proposal yet, you have no idea of > > how this would work > > Good point. The sooner you send around a proposal, the sooner we can > figure out how it might improve the process. Fair enough. But I think Michael's note illustrates a somewhat different, but related, and very common phenomenon in IETF that is relevant to this problem. All too often, we (and I include myself here) shoot down ideas before they've had a fair hearing. We take an idea that is embryonic and - because we can _imagine_ that idea going somewhere that _might_ have a bad result - we do our best to kill it before it can breed. In this way we discard many good ideas not because they have no merit, but because they bring with them the potential to change things. The result is stagnation. I think we do this because we lack confidence in the IETF working group process. We all know that once something gets to the working group stage, it's very hard to kill. No matter how badly it turns out, the IESG is likely to end up holding its nose - maybe demand a trivial text change or two or add a nasty disclaimer - but basically approve it. By the time the WG has spent 2-3 years or more, exhausted itself and declared itself to be done, it takes a lot of Last Call feedback and IESG gumption to push back on it. Simple fixes can of course be made, but significant design flaws can rarely be corrected. At the same time, experienced WG participants know that even small, apparently trivial objections made late in a WG's lifetime have the potential to delay the WG's output for months or sometimes years. So once there is a significant investment in a particular direction within a WG, there tends to be tremendous resistance on the part of core participants to feedback that would call that direction into question. Trouble is, in our current process, there's rarely any formal request for feedback, and little external visibility of a WG's output, until Last Call. Which basically means that working groups get most of the external feedback about their fundamental design choices long after the designs are frozen and the working group is too exhausted to fix anything. Ideally our process should encourage these differences to be resolved early - before there is a significant investment in the WG's output that would encourage denial on the part of its proponents, and before the WG is exhausted to the point that it cannot respond quickly and flexibility to external input. And if we had a process that made it likely that significant problems were discovered early, the latter stages of review should be less time consuming and less risky. So when I'm saying that working groups need multiple stages of formal, external review, what I'm really saying is that we need a structure for working groups in which we can have confidence that sufficient feedback will be obtained early enough to put good ideas on the right track and to see that truly bad ideas get weeded out in due time, most of the time. You (or Michael) and I might have somewhat different ideas about how to gain that confidence, or about the details for how to make it work without bogging down working groups, but the concept working groups need earlier external feedback is sound. Keith p.s. as for additional review stages bogging things down, any good protocol engineer ought to understand that sliding windows produce better throughput than stop-and-wait, that a fin-wait state is unavoidable if you want a clean close, but the way to reduce time in fin-wait is to minimize rtt and packet loss... _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf