On Wed, Nov 11, 2009 at 10:40:53PM -0500, Tony Hansen wrote:
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.
DNSEXT has this problem in spades, partly because it's not zero work
to move something along the standards track. Even if the document
needs no revision, you still have to meander through the process.
This takes time and, as important, the energy to prove that the
document really is ready to proceed.
What is the incentive to do the work? Why bother? Who is going to
spend time and effort on what is essentially a housekeeping task,
which is way less interesting than inventing new solutions (or
problems)? Especially since you still have to go through last call,
at which point every kook on the Internet who has a lot of will (or
time on his or, rarely, her hands) has the opportunity to haul out
their rusty old axes and start grinding.
We have more and more formal rules around determining rough consensus.
Meanwhile, the running code is the actual measure of effectiveness,
and once there is a broadly stable, already interoperating standard,
there's very little incentive to go through the bureaucratic hurdles
to demonstrate even less-rough consensus. There's not even the sort
of money incentive that causes people to do drudgery in their day
jobs: the management responsible for paying salaries are surely
unlikely to want to burn expensive engineer time jumping process
hurdles if there's not a clear benefit.
This all means, to me, that the incentives just aren't there to move
most standards. But so what?
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)
Surely, this is already an indication that we have more process than
is needed. If everyone agrees that something is needed for
interoperation, and it's widely deployed like that, why in the world
do we require a lot of hoops to include that when we move the document
along? Errata are, by definition, strictly speaking part of the
original document. If they weren't, they wouldn't be errata: they'd
be revisions to the specification. And we all know, of course, that
nobody ever tries to use an erratum to make a subtle change to the
specification in order to avoid using the standards process, right?
A
--
Andrew Sullivan
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf