On Mon, Sep 20, 2010 at 3:13 PM, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf