+1
But I also agree with part of Adrian's comments. Our vocabulary
for describing these things may be sub-optimal and that may have
gotten in our way. Perhaps something more along the lines of
"approved standard", "interoperable standard", and "verified
standard" would serve us better than PS/ DS/ Full. But a
different piece of vocabulary might be equally important:
perhaps we should be talking about "recognizing" something at a
standard at a particular level and not "advancing" it.
I also believe that part of the problem involves what amounts to
a positive feedback loop: because few documents are advanced
past PS, the IESG feels obligated to impose requirements on
approval at PS that go far beyond what is required by 2026.
Once documents are polished to a high luster, at the cost of
considerable time, for PS, there is little incentive to advance
them and, worse, even more impressive requirements are imposed
in practice at DS and Full, possibly to give them some
distinction beyond Proposed. If we could get back to treating
Proposed much as the IEEE used to treat "Draft Standard for
Trial Use" -- "no known technical defects" in the protocol and
documentation that was not required to be more than adequate to
explain the idea -- then we might be able to get things into
Proposed more quickly and have incentive for document revision
and advancement (sic) for those ideas that actually turned out
to get traction in practice.
Of course, since Brian found one dead horse to kick, I'm
semi-obligated to mention another. The ISD idea was to draw
things together in a different way, permitting binding several
documents together in ways that would deal with the problems
Spencer mentions, replacing the rigid "PS/ DS/ Full" categories
with explanatory prose, and binding errata and clarifications
more closely to the documents themselves than the RFC Editor
version of the errata permits. But neither that idea nor the
earlier one Brian mentioned is worth resurrecting and
reexamining unless the IESG wants to play and, so far, I've seen
little evidence that they do.
john
--On Wednesday, November 11, 2009 22:40 -0500 Tony Hansen
<tony(_at_)att(_dot_)com> wrote:
Yup, and most of those proposed standards and draft standards
should have been declared full standards *long* ago.
What we *don't* do well is revising the levels of standards
that got published, became fully interoperable and deployed
without needing a rev of the document. Why is their status
still marked 'proposed' or 'draft'? RFC 2026 does NOT require
a rev to the document to move forward if there are no errata.
For those specs that everyone has implemented and deployed,
but there are a number of errata that "everyone agrees" are
required for the spec to be useful, here's an idea for a
"revision lite" (the diet version of a revision): recycle the
spec almost totally *as-is*, with a section added called
"Verified Errata". Copy in such errata, attach the
interoperability and deployment reports, and publish.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf