18 months

[Dave Crocker]

Folks,

Tuesday, December 10, 2002, 3:45:55 AM, you wrote:
>>I believe we would have behaved differently had there been a
>>rule setting boundaries both for overall time and allowed slippage.

Margaret> Rules are not a substitute for active and effective management.

Margaret> Making a hard rule like "publish in 18 months or perish" will not
Margaret> serve the community in the long run.

Rules come from a need to make things more predictable, more fair and more
efficient. In the extreme we could try to have no rules at all, relying on
the subjective decision-making of ADs and the IESG. Unfortunately, we need
more consistency, more efficiency and more fairness than that. So we make some
rules.

The draft-huston-ietf-pact proposal for an 18 month limit is prefaced with a
specific assertion:

   If an effort requires more than 1.5 years to produce something that
   is ready for IETF last call, then it is not yet ready for the IETF.
   The effort must do its pre-standards work elsewhere and then come to
   the IETF when a solution is ready to be standardized.

In other words, there things the IETF does well and things it does not do
well. John Klensin posted a note also observing that we need to pay
attention to what we do well and let other things be done elsewhere.
<http://eikenes.alvestrand.no/pipermail/problem-statement/2002-December/000216.html>.

When we have a clear sense of the problem to be solved and an urgent
pressure to produce something useful in a timely fashion, the IETF does
wonderful things. When either of these factors is not present, we flounder.

Floundering is very expensive. My guess is that the shortest, smallest IETF
standards effort costs multiple millions of dollars. Worse, these effort
waste scarce IETF resources, ranging from AD time, to meeting space, to
community goodwill.

One can quibble with the particular phrasing that we measure the IETF by the
"commercial success" of its output -- my own phrasing is that we look for
actual use -- but the point being made is absolutely key: our rough measure
of productivity is producing standards document and our precise measure of
success is adoption and use of those documents.

    A document that is not produced or is not used is not a success.

An organization that has a track record of not producing, or of producing
work that is not used, is irrelevant.

The 18 month proposal has been called draconian. I would call it
procrustean. We are trying to make all efforts fit into the bed of near-term
productivity. The problem is that the draft-huston-ietf-pact did not create
the bed. The IETF track record over the last 15 years created the bed. The
IETF does near-term work well. The IETF does long-term work very badly.

We have a serious problem and we need concrete, serious steps to make things
better.

What happens if we actually impose the 18 month rule?

The formation of a working group will include more attention to whether
milestones are achievable. Better still, the operation of the working group
will pay more attention to hitting those milestones. The working group will
not take 1-2 years to produce a requirements document. They will largely do
requirements work elsewhere, so that when the working group is formed, it
will actually focus on satisfying requirements, rather than debating what
they are.

An alternative to the 18 month rule that a few people have suggested is
regular, zero-based review of a working group. In the extreme, this would be
a formal re-chartering process. Note that this is not necessarily an
alternative to the 18 month rule. It could, in fact, be a way of
implementing the need for timeliness. The difficulty is in making sure that
such reviews are real and not pro forma. In other words, we need to create a
real requirement that working groups be productive. We need to take that
requirement seriously.

At the moment, some people seem to think that it is acceptable for a working
group to take 2 or 4 years, or even longer, before producing anything
useful. This is spite of demonstrated problems with such lengthy efforts.
An effort that takes that long usually misses the market window, usually
cannot sustain good continuity of IETF participation, and often produces
specifications that are bloated, complex and flawed.

Deadlines are very effective project management tools, when they are
carefully chosen and carefully enforced.

Timeliness is not an opposing force to quality. Timeliness and quality
interact. Indeed, doing things too quickly reduces quality. But so does
doing things too slowly.


Margaret> The IESG is already empowered to employ the scalpel.  WG chairs
Margaret> serve at their pleasure, and they can shut down WGs without
Margaret> even discussing it publicly...  This isn't something that any
Margaret> responsible person (and all of the IESG members are, certainly
Margaret> responsible people) would do lightly, but the IESG does have
Margaret> the power...

Separate from whether that power has been exercised adequately, we must
prevent situations that require its exercise. When that power is exercised,
it means that we have wasted an enormous amount of time and energy.


Margaret> I agree that it is important that we come up with some way to
Margaret> hold the IESG more accountable for doing their work in a timely
Margaret> fashion.

There is strong community feeling that document processing delays are a
problem. However we clearly also have a serious problem with delays inside
the working group. An IESG with absolutely perfect management skills cannot
fix this. To make working groups be more productive and timelier, we need
both to structure their work better and we need an attitude among working
group participants that timeliness is an equal partner to quality.


Margaret> What we need to do, as you allude, is prioritize our work...

Correct.  As Marshall has been saying, we need to get better at saying no.


Margaret> The first place I think that we should look is at the side
Margaret> track for publication of informational/experimental RFCs.

It is certainly a good idea to eliminate tasks like these, if they are
wasteful. But is this issue really one that is having a major impact on the
consumption of IESG time. For that matter, how will changing this make
working groups more productive?

d/
-- 
 Dave Crocker  <mailto:dhc@dcrocker.net>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850