18 months

[Brian E Carpenter]

Dave,

I don't get how a rigid time limit will make WGs do things better.
Some things just take two years. What is much more important
is strict follow up of missed milestones - if whatever was negotiated
initially doesn't work out, then there should be a conscious decision
each time to either kill the work item or extend the milestone date.
What really hurts us is drifting milestones.

I don't disagree that 18 months is a long time. We should clearly
target a lower average (say 12 months) and take steps to chop
off the long tail. But let's not cause artificial problems by
over-rigid process rules.

  Brian

Dave Crocker wrote:
> 
> 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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland