The official dogma of every Standards Process is that the Process has
failed if it does not produce a document. In real life, no document
is more often a success than a failure. On the other side of the coin, a
committee document is more often a failure than a success. This side
is trivially proven for the IETF by referring to the RFC index.
Indeed. The ability to charter and re-charter a WG is a privilege and
not a right. There are several types of WGs that might best go
unchartered or not re-chartered:
A. The WG chartered to "combine the best features of protocols X and Y".
B. The WG chartered to produce a standard in an area in which there
is no running code.
C. The WG that is behind on its milestones by more than two years.
D. The WG that is chartered to document (for standards status) an
existing protocol.
I leave it to the reader to think of examples of WGs A, B, C and D.
Such WGs have existed in the past and continue to exist in the
present. However, I question the wisdom of continuing to charter
such WGs, particularly now when there is so much real work to be
done and so little precious time in which to do it.
WG A, is by definition being chartered to produce a cross-breed. As
in real life, few cross-breed protocols have the genetic material to
survive in the wild. Such a WG is more likely to produce a protocol
with *all* of the features of X and Y (and then some) than to focus
on the *union* of functionality common to the problem attacked by
protocols X and Y.
Now it can be argued that the vendors behind X and Y might just go
out and do their own thing, and therefore that an IETF effort is
of benefit. There are two problems with this argument. One is that
having some vendor implementation experience -- even of the proprietary
variety -- might be just the thing to refocus the effort
on customer needs. The second problem is that the attention
of the IESG is a finite and valuable resource. Every minute
spent on the WG A, B, C and Ds of the world detracts
from the time available to supervise WGs more likely to
make a difference.
As for WG B, a fundamental premise of standards activity is
that "we only standardize things we know how to do." This
makes sense if only because it is hard to create a
charter and milestones for a WG in an area where there
has never been running code. Such a WG would
be better chartered in the IRTF, which can develop
implementation experience to the point where the problem
can be better defined.
WGs like C that have gone way off their schedules are problematic
for a number of reasons. Firstly, we know that WGs that take
more than five years to complete their first milestones
are generally less likely to result in widely deployed
protocols than those that finish sooner. A WG that misses
its milestones by more than two years is a candidate to
become an "IETF lifer" and so deserves further scrutiny,
if only because the Internet changes so rapidly that the
world is often different after two years. Thus, the
WGs original assumptions may not longer be valid by the
time the work is finally completed.
Once a WG slips its schedule by two years, it is time
to examine the reasons behind the slip and reassess the
environment into which the protocol will be deployed.
WG C can get badly off track for many reasons -- poor leadership
being one of the most common. However, another common reason
is that the problem definition itself is inadequate or that a
fundamental assumption underlying the original approach
is invalid.
In such a case, the IESG should feel no obligation to
allow the WG to continue. The IESG does some of its best
work in shutting down WGs that have lost their way. If
the fault lies with the problem definition, not the work
itself, then one or more WGs can be subsequently chartered
with a sharper focus. If the problem lies with the leadership
of the WG, then perhaps new leadership will do the trick.
WG D is in effect chartered to give a proprietary protocol
the IETF's stamp of approval. However, the IETF is not a
rubber stamp, and if the proprietors wish to retain de
facto or de jure change control, then their protocol
should not be accepted on the standards track.
with a better focus.