Subject: ISSUE: Determinants for timeliness missing in section 2.1

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 08 Jun 2003 13:39:00 +0200

OK, I'll push two specific issues into the debate today.... first one...

ISSUE: In section 2.1, "Participants in the IETF do not share a common 
understanding of its mission", I think there is a bullet missing.
The determination of "timely" market is a problem that is not mentioned.

 SUGGESTED RESOLUTION: Add something like this:
 o The IETF is unable to determine explicitly what effect it desires to 
have in the marketplace, and is therefore unable to determine what 
requirements of timeliness are appropriate to consider when planning work.

I believe this is a core problem which underlies our commonly occuring 
inability to have rational discussion about time-to-market vs quality.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 8 Jun 2003 09:13:36 -0700

Harald,

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.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 08 Jun 2003 18:34:44 +0200

--On søndag, juni 08, 2003 09:13:36 -0700 Dave Crocker <[email-masked]> 
wrote:

> 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.
>

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 
present day.

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 
this date".

Beneficial results for all.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 8 Jun 2003 12:47:34 -0400 (EDT)

Harald,

I understand the point you are trying to make ... but I'm not sure DHCPv6
is such a good example.  Unless there's more to the acceptance of DHCPv6
by the IESG than I know about, I think this history of DHCPv6 is something
of an oversimplification and omits many other pressures  - both positivie
and negative - on the forward progresss of DHCPv6.

- Ralph

---

From: Dave Crocker <[email-masked]>
Date: Sun, 8 Jun 2003 17:32:46 -0700

Harald,

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
consider.

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
     efforts.

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
nice.

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.

d/

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2003 10:27:57 +0200

--On søndag, juni 08, 2003 17:32:46 -0700 Dave Crocker <[email-masked]> 
wrote:

> 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.
>

I don't think those two descriptions contradict each other....
as I frequently say when asking for charters to be more clear:

"if you don't write it down in a way I understand, how can I tell that we 
agree?"

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jun 2003 10:53:32 +0200

following up my own posts is a bad habit, but this one was probably too 
cryptic.....

When we have the case of "plenty of people .... that had a very clear 
vision of what they wanted to achieve", and have "requirements to satisfy 
additional constraints", the people imposing additional constraints are 
people too, and part of the community. What's more, in the cases where 
those "imposing" people are chosen as leaders of the community, they 
believe that they represent other members of the community - and may even 
be right.

So - I think it is fair to say that AS A COMMUNITY, we had "unclear and 
unresolved visions of what we wanted to achieve".

             Harald