Paul Hoffman wrote:
> At 12:06 AM -0700 7/21/06, Dave Crocker wrote:
>> By way of providing some incentive, I suggest that Proposed have a limit,
>> such as 3 or 5 years (and, yes, we can quibble about that, too.) If the
>> work cannot gain sufficient adoption by the end of that time, it has failed
>> and warrants moving to Historic.
>
> Fully disagree. If there is "some implementation but not enough" it
> should remain "proposed". Otherwise, vendors will hesitate to implement
> protocols that might eventually make them look silly ("why does the box
> include the FrobzBaz protocol when everyone knows that it is Historic?").
That sounds like an extremely reasonable concern, except for all the empirical
evidence to the contrary.
Vendors do not look silly by being aggressive in providing new features.
And they take risks about the future, formal approval and market-wide acceptance
of a technology all the time.
> This leads to two designations: Proposed and Full. An implementer
> looking at a Proposed standard would assess how long it has been out and
> which other implementers have put it in competing products to assess
> whether they want to put it in theirs. Things labelled Full standard
> would probably be put in by default.
So, we are in agreement about having 2 levels and having the second one be based
on market acceptance? Our disagreement is about deprecating Proposed specs that
have not reached Full after a period of time.
Note that we already have this policy, although it applied erratically by the
decade, not mechanically by the year.
ALso as you worry about incentives, note that automatic deprecation provides an
incentive for those asserting community need to prove it and to do the proving
in a timely fashion. (What specifications have failed to gain significant
adoption after, say, 5 years but have, nonetheless, become "successful"?)
> Vendors really do care about this. They don't want to look bad for
> including the "wrong" features, and they don't want to look bad for not
> including popular ones.
I've never seen one that was faulted for having extra features, no matter their
"formal" status.
I regularly get calls from VPNC members asking
> about whether or not they should implement various standards, both in
> the positive sense ("is it worth paying an OEM to include this?") and in
> the negative sense ("will we look silly if we include this, even though
> it is in the standard?").
The best I can guess is that anyone worrying about looking silly, for having
extra features, probably is new to the marketing game or is hopelessly naive
about their product space.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
