On Mon, Sep 20, 2010 at 3:13 PM, Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
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.
For protocols where interoperability with others' implementations is
important for your customers'
view of your product, there is probably enough benefit to get the
involvement; if you look bad because
other people aren't able to read the spec, you have some incentive.
But that may no longer be the
common case.
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.
A periodic call for comments, say at 2 and 5 years out, with those
judged to be still useful moving up the ladder,
for example?
I understand that "objection based processing" was not the most polite
way to word this in my draft,
and I'm sufficiently chastened to change it in the next version. But
I think any system we base on a periodic
assessment like the above has to have a default of "advance". The
current Proposed standards
get a lot of scrutiny and generally are pretty good. If we don't do
"default advance", we are adding
friction to the common case, where they should move forward.
We also have the much harder task of judging the consensus on
documents based on what is likely
to be small amounts of commentary. That's tough, but getting more
than small amounts is
likely going to be substantial amounts of work. For substantial
amounts of work, our current
criteria for draft are much cleaner: two interoperable implementations
from different code bases and license
grants. For the record, I still think that it useful data to have,
but my personal read is that the community
as a whole doesn't see the value in it for things that work. So the
common case stays at proposed.
Things get moved up when they're already being pruned of things that
didn't work or because some
external force requires them to.
Maybe a single stage with revisions at that stage is all we really
need. But I suspect the opportunity to raise and
resolve issues would be valuable, especially if the "default advance"
attracted the attention.
Just my two cents,
Ted
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf