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@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf