Re: Single vs many solution(s)

Folks,

I think that the following message is quite relevant to the discussion.

Yakov.
-----------------------------------------------------------------
Date:    Fri, 23 May 2003 10:04:39 EDT
To:      [email protected]
From:    Frank Kastenholz <[email protected]>
Subject: The One True Path To Nirvana

Folks,
I hate to inject a bit of reality into this but
whether the IETF decides to bless one-and-only-one
way to do FOO with the high-honor of "Standards Track
RFC" or allows multiple ways is only marginally
important.

Vendors, being interested in making money, try to
differentiate their products. The Offical IETF
Mantra in this regard is that vendor differentiation
arises out of things like quality. While true, it is not
the complete truth. Vendors will also have with their
own protocols as alternative ways to do FOO. The vendor's
marketing people will then tout their proprietary FOO
Protocol as "better" than the standard in various ways.
The proprietary FOO Protocol might even be what the 
vendor tried to get made a standard but failed (and
now there might be an installed base...)

Second, customers (bless their checkbooks and capex budgets)
sometimes what something that's not the standard. It could
have been something that was a candidate for standardizing
but didn't make it. It could be something that the customer
came up with. It could be some set of requirements that
the customer has (or thinks they have) that are not met
with the standard, requiring some non-standard-FOO.

Having multiple levels of standard really doesn't have
any effect on what vendors do or what customers want.
If the deltas from one level to the next are "just
bugfixes" then that's how they are treated by vendors.
If there are substantive changes in function (function-x
is available in proposed std, but not in draft, or vice
versa) then the implementation becomes the union of all
standard-levels, with config switches and the like. In other
words, the propose/draft/full hierarchy is little more than
feel-good self-gratification on the part of The Process Experts.

Btw, before I get roasted for heresy
a) There are always exceptions where things happen
   differently. When the right things happen, it's
   like winning the lottery. Enjoy it, but don't count
   on it
b) This is not a state of affairs that I find particularly
   desireable.  It is a state of affairs that does exist,
   however, and pretending that it does not exist is foolish.

So, the short answer is that multiple-competing-FOOs is
a fact of life. We live with it. We deal with it. Whatever
the IETF does, it will not go away. 

That said, what the IETF _can_ do is to make the problem
easier to deal with by
- getting the technical quality of things as high as we
  can as early as we can. That means -00 of the draft,
  if possible (yes, I know it won't happen, but the sooner,
  the better)
- getting drafts and changes and RFCs through the system
  faster (without sacrificing quality).
Ideally, -00 of the ID comes out 1 week after the first BOF
and there are no changes made to it, ever.



Frank Kastenholz

This is all my personal opinion and does not have anything to do
with what my employer says, thinks, does, etc.