Dave CROCKER <dhc(_at_)dcrocker(_dot_)net> wrote:
On 6/20/2010 11:53 AM, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does "require
implementation and/or operational experience prior to granting Proposed
Standard status".
That's news to me: I can't recall any recent discusses calling for
operational experience before publishing as Proposed Standard.
Some years ago, there was such a requirement for Routing Area, but
that was declared obsolete. (In actuality, there seems to still be a
somewhat informal requirement to document implementations for _some_
Routing Area documents, but it is not by IESG direction.)
Well, they do not /always/ require it.
I'm willing to be corrected: does anyone want to document a single
case where this was required _by_the_IESG_ in the last two years?
That said, the fact that they often do and that we've lived with the
reality of that for a long time could make it interesting to simplify
things significantly:
1. Have the current requirements for Draft be the entry-level
requirement for a standard -- do away with Proposed, not Draft.
That strikes me as a terrible idea.
I can think of several cases where WG LastCall was postponed until
two implementations were demonstrated.
By that time, folks were so set on their implementations that it
proved "just too difficult" to dislodge that with facts about faults
in the specification.
(I realize that only flame-wars can follow such a statement as
"the reason" to keep 2026 the way it is for Proposed Standard. I
shall try to find a sufficiently flame-proof suit...)
Please consider human nature here. We do have folks that are good
at pointing out theoretical weaknesses of proposed algorithms. But
they stand no chance of prevailing against "running code" that's
already deployed in the field.
I grant that IETF runs on "rough consensus and running code"; and
I have no particular interest in even _trying_ to change that.
But can't we PLEASE keep the review stage before we cast the
"running code" in silicon?
2. Have a clear demonstration of industry acceptance (deployment and
use) be the criterion for "Internet Standard" (ie, Full.)
In truth, there are interlocking reasons why advancement beyond
Proposed Standard is so difficult -- but I'd like to call attention
to one particular reason: the IESG is overworked.
Look at any bi-weekly agenda.
Count the pages in the I-Ds.
Glance through some of the questions raised. Even if you think
the majority of them are spurious, documents _do_ reach the IESG
in a state which essentially precludes implementation working only
from the document.
Now, imagine bringing every standard-track document back two more
times. :^(
We've had several Working Groups over the years consider this;
and IMHO they've mostly agreed the IESG shouldn't have to act on
these documents three times.
But we don't have to abolish the three-levels of 2026 to accomplish
that: there have been several proposals to simplify the process of
advancement.
It is a characteristic of consensus process that sometimes it's
"obvious" to a majority that the "wrong consensus" was reached.
That doesn't mean, however, that proposing a "better consensus"
is workable. We've gone through years of proposing "better consensus"
here; and I'm frankly not convinced it's worth another half hour of
Plenary time to propose another.
We have three levels in RFC 2026. The levels are reasonable,
starting with a clear specification, progressing through interoperable
implementation, and finishing with experience in the field.
Frankly, the fact that we seldom get past the first _doesn't_
convince me there's anything wrong with the levels. And I don't see
why we should expect it to convince anyone who doesn't already
subscribe to one or another "better consensus".
I wish we could instead discuss how to improve the _process_ of
advancing through the levels. It may be that some prior IESG was
unwilling to let go of a death-grip on blocking advancement for any
perceived imperfection. (I simply don't know...)
I do NOT believe, however, that the current IESG has any such
interest in keeping tight control of advancement.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf