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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf