On Sep 20, 2010, at 4:51 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
I certainly recall instances where features were dropped from the Draft
Standard version of a specification precisely because interoperability had
not
been demonstrated.
As can I on quite a few occasions, but what I cannot provide is any evidence -
or even an anecdote - that in the present climate of high scrutiny before
getting to proposed, such changes demonstrably improved interoperability and
deployability in the field.
I'm sure that there is a point of diminishing returns, past which more scrutiny
doesn't result in improved interoperability or deployability, and may degrade
the latter.
I also think that there is limited utility in having multiple review periods.
But I do believe that interoperability testing is valuable at helping debug a
specification.
Part of the problem with moving to Draft Standard in the current process may be
that such testing, and resulting improvement of the specification, mostly
benefits late adopters. The early adopters who are the experts at the protocol
already know what it takes to make it work, even if the specification is
ambiguous in places. Those are the very people who need to be involved in
cleaning up the specification, but (depending on market conditions) they may
see it as mostly benefiting their competitors.
But I don't think that a prospective implementor cares (much) whether a
specification is Proposed, Draft, or Full, or perhaps even Informational or
Experimental. I think they care about whether the specification reflects
current widespread practice (or if the protocol is new, best known practice),
whether it's sufficiently precise to permit implementations to interoperate,
whether it's implementable with reasonable effort, whether its encumbered by
patents or other constraints, and whether it is deployable.
If I'm close to right about these things, maybe we would do well to rethink our
standards process along these lines. Rather than moving to Draft, then Full,
maybe we should periodically make an assessment about how well a specification
still reflects existing practice, how widely it is used, how precise it is, and
so on.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf