ISSUE: Determinants for timeliness missing in section 2.1
Harald Tveit Alvestrand
harald at alvestrand.no
Sun Jun 8 19:34:44 CEST 2003
--On søndag, juni 08, 2003 09:13:36 -0700 Dave Crocker <dhc at dcrocker.net>
> HTA> SUGGESTED RESOLUTION: Add something like this:
> HTA> o The IETF is unable to determine explicitly what effect it desires
> to HTA> have in the marketplace, and is therefore unable to determine
> what HTA> requirements of timeliness are appropriate to consider when
> planning work.
> i thought we knew exactly what effect we wanted to have: we want to
> define protocols that get used.
> i suspect you mean something deeper than that. please clarify.
ok... I'll argue by controversial example again, as usual...
The IPv6 proponents were in a desperate hurry to get this deployed in 1993,
because addresses were running out.
The IPv6 opponents did not agree on the basic needs, and therefored did not
agree on the requirements for the timetable.
Addresses got more expensive, which led to tricks (like NAT) to avoid
consuming them so rapidly. So around 1997 there was a kind of lull, where
the IPv6 advocates slogged along, refining their stuff and considering what
added features could help "sell" IPv6 in the marketplace.
In 2003, the pain of those tricks seems to have grown to the point where we
(again) are desperate to get IPv6 deployed. And some of the stuff that
seemed like a good idea in 1997 doesn't seem so great any more.
If we'd had perfect (fore/hind)sight, we might have concluded in 1993 that
we needed something by 1997, and would plan take a little more time to -
for instance - settle the endpoint-identifier vs aggregatable/routable
identifier by 1995 rather than leaving bits and pieces that point in both
directions cluttering up the landscape (and the discussion lists!) to the
Or in the IM debaclee - if we had had consensus in 1997 that nobody's going
to make IM systems interoperable over the next five years if we don't do
it, and that this interoperability is actually what the IETF wants, we
might have been able to force the IMPP group to stop dithering about and
get its documents published three years ago.
In both of those cases, we started off (IMHO) with unclear and unresolved
visions of what we wanted to achieve, and this led to setting schedules
that had much to do with our feeling of hurry, but little to do with a
realistic expectation of when the industry needed our end product.
In the case of DHCPv6 - we got an external customer (3GPP), with a
documented need and a fixed deadline - and the document got out.
The customer provided the necessary timeframe - "if you want to get this
done in this particular context in a standard way, give us the standard by
Beneficial results for all.
More information about the Problem-statement