ISSUE: Determinants for timeliness missing in section 2.1

Dave Crocker dhc at
Sun Jun 8 18:32:46 CEST 2003


Thank you for the examples.  They are both painful and enlightening.

I think there is a commonality among the two examples and a number of
other problematic IETF efforts.

HTA> The IPv6 proponents were in a desperate hurry to get this deployed in 1993,
HTA> because addresses were running out.
HTA> The IPv6 opponents did not agree on the basic needs, and therefored did not
HTA> agree on the requirements for the timetable.

During those debates, an interesting fulcrum for the two sides was the
definition of "running out".  For some, it was "reasonable requests for
address blocks get turned down".  For others it was "there are no more
addresses left to assign".

There were plenty of statements about *existing* problems getting
desired (and, I would argue, reasonable) allocations. In other words, if
we looked at the question of having difficulty getting needed address
blocks, we were already in a crisis.

Those arguing for a lack of urgency took the latter definition, and
developed clever analyses that said we would not have a problem until
2010 or 2020.

Key to this is that those who felt a sense of urgency were forced to
take many years longer.  This, then, gave the IPv6 work an opportunity
to add a remarkable number of additional requirements that would have
been approached more incrementally, if the urgency had been allowed to
direct near-term efforts.

HTA> If we'd had perfect (fore/hind)sight, we might have concluded in 1993 that
HTA> we needed something by 1997,

Let me suggest that wishing for, and thinking about, such insight is
something we all tend to do, but that it is exactly the wrong point to

We will never have it. Wishing otherwise distracts us from finding
constructive paths.

What well *might* be constructive is to try to understand why we did not
take the action that we now wish we had.

In this case, I believe the constructive path should have been to note
the considerable base of support for near-term efforts and then letting
it proceed.

     Instead, frankly, the IETF served primarily as a block to near-term

That is, when we talk about being unable to get agreement, what we mean
is that we could not get a strong consensus among everyone who was
participating in the discussions.  On its face, that sounds exactly like
a lack of consensus.  What it misses is the opportunity to redefine the
population for which consensus is sought.

There are times that the only thing to do is divide the constituencies
up.  Each will achieve a strong consensus for their independent views.
As long as each has credible participation, that should be enough.

And though I use this example far too much, I will again cite the MIME
and ESMTP efforts.  Those seeking to support 'international' characters
in Internet mail could not agree on a single approach.  So the efforts
were divided between the "enhance content labeling" versus "enhance
transport".  And they went their separate ways.  The results was quite

Except for being required to share MIB data, SNMP and CMOT were allowed
to develop independently.  Again, the result was quite nice.

HTA> Or in the IM debaclee - if we had had consensus in 1997 that nobody's going
HTA> to make IM systems interoperable over the next five years if we don't do
HTA> it, and that this interoperability is actually what the IETF wants, we
HTA> might have been able to force the IMPP group to stop dithering about and
HTA> get its documents published three years ago.

1. The IM discussions were saddled with the very real difficulty of
being unable to partition the problem into sufficiently independent
technical pieces, until 2 years ago. There is a strong argument that
that was too late. Even then, not very many people seemed able to
maintain the conceptual separation.

2. Multiple proposals were, in fact, developed, as you know, since it
was on your watch as working group chair. However, again, they were
forced to "coordinate" and, in effect, were made dependent on a fourth,
separate effort that had the claimed intend of permitting "gatewaying"
among the alternatives. Worse, that fourth effort did not have a documented
charter and its goal moved around, making its work at best inconsistent.

HTA> In both of those cases, we started off (IMHO) with unclear and unresolved
HTA> visions of what we wanted to achieve, and this led to setting schedules
HTA> that had much to do with our feeling of hurry, but little to do with a
HTA> realistic expectation of when the industry needed our end product.

On the contrary, I believe there were plenty of people in both
situations that had a very clear vision of what they wanted to achieve.
The real problem is that they were prevented from pursuing those
visions, due to requirements to satisfy additional constraints and/or to
coordinate with competing efforts.

As much as we all dislike fragmented results, the IETF has a pretty
terrible track record when it tries to coerce coordination.  (Just ask
the SNMP MIB guys how much they like ASN.1, for example.)

This all suggests two lines of changes:

1. Really require clear, focused, near-term deliverables, and require
that the deliverables result in a discrete, usable bits of
functionality. (Derivative change is to stop chartering efforts that
cannot define those clear, focused, near-term deliverables.)

2. Stop requiring the the deliverables be saddled with large amounts of
additional constraints and features and coordination with others, and
especially stop trying to coordinate among competing efforts.

   Any effort that can amass a credible constituency for doing the work
   and seeming likely to implement it should be allowed to proceed. When
   competition is between paradigms, the differences can't be resolved.
   If we can legitimately get the community to choose one paradigm, then
   fine, but when the schism holds, then divide and let time and work do
   the conquering.

HTA> In the case of DHCPv6 - we got an external customer (3GPP), with a 
HTA> documented need and a fixed deadline - and the document got out.

That's what happened for fax-over-email, too, based on ITU deadlines. I
would agree that it had very good effect.

 Dave Crocker <mailto:dcrocker at>
 Brandenburg InternetWorking <>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

More information about the Problem-statement mailing list