On Sep 20, 2010, at 4:51 PM, ned+ietf@xxxxxxxxxxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf