Re: Work effort? (Re: Proposed Standard and Perfection)
2004-03-12 19:03:08
(2) When a document comes up for review for
Proposed->Draft, we look for implementations, etc.,
perhaps following Keith's proposal outline. If the
implementations are there, we issue a Last Call for
identification of serious technical/definitional flaws
in the document as published, where "serious" is defined
as "problematic enough to interfere with independent
interoperable implementations". If none are found, we
advance the maturity level of the document, in place --
no new RFC publication required and hence little or no
opportunity to reopen old wounds that lack demonstrated
interoperability impact. If the document is about to
time out in grade, we issue a Last Call, wait a
reasonable period for protests and volunteers, and then
downgrade it in place. The notion of having to write an
RFC, following all of today's complex rules, and get
formal consensus in order to declare a Protocol obsolete
that isn't implemented and won't operate in today's
environment is one of the more astonishing triumphs of
bureaucracy over rationality. Similar rules would apply
to Draft->Full (or whatever formula newtrk comes up
with).
John,
I cannot support the notion that the only technical flaws that should
prevent a document from advancing from Proposed to Draft are those that
"interfere with independent interoperable implementations".
A protocol may interoperate quite well with itself, and yet have a
peripheral effect on a large number of other protocols. A protocol that
does not share channel capacity fairly with TCP can have a disruptive
effect on TCP-based protocols. A protocol that defines a new kind of
(IPv4 or IPv6) address space that behaves differently from existing
address space can break applications even if that protocol does not
directly interact with those applications. A protocol which doesn't
provide adequate authentication can cause its hosts to be compromised
which in turn affects the operation and security of other services.
That, and it's too easy for technical flaws to be missed at Proposed
Standard that show up after some implementation and/or deployment
experience is gained - and these aren't at all limited to flaws that
interfere with interoperation.
I do agree that we should not reopen noncontroversial documents that
aren't found to have significant flaws. I have occasionally suggested
that rather than re-edit documents advancing in grade, we start out by
making lists of things that need to be changed. If that list ends up
being less than N pages or X% of the length of the original
specification, publish the list with a preface that says "RFC XXXX,
with the following clarifications, changes, and corrections, is
approved for Draft Standard".
OTOH, some documents that were controversial at Proposed probably do
deserve special scrutiny at Draft. That doesn't mean that we should
automatically reopen them, but it might be that given the subsequent
experience with the document it no longer meets the criteria for
Proposed (e.g. "no known technical omissions").
Principle: If we are going to spend as much time and energy as we do
getting something to Proposed, then moving it to Draft or Full should
usually require only identification of implementations, deployment,
and desirability, not extensive and time-consuming document rewriting
What if we applied the same "principle" to software? What if once a
program were written there were an expectation that it should never be
substantially changed, never be re-evaluated in light of changed
conditions or new understanding?
Keith
|
|