--On Wednesday, 20 September, 2006 08:23 -0400 Scott Bradner
<sob@xxxxxxxxxxx> wrote:
> Spencer remembered:
>> My understanding (as author of three of the proposals) was
>> that for most of the time newtrk was in existence, the
>> working group's attention was focused on ISDs as a way of
>> avoiding the need to tackle the 3 stage process. So I'm not
>> sure there was even a call for consensus on adopting any of
>> the proposals as a working group document.
>
> almost
>
> the newtrk chair (at least) felt that ISD would remove the
> issue of how many stages by taking a different path
So did another one of the authors.
Having seen the consequences of one-step standards processes,
especially in environments in which the standards designers are
not very closely tied to products that are shipping or ready to
ship, I remain strongly committed to a standards model that
separates "consensus proposals for implementation" and
"consensus standards that have been tested -- for both
specification quality and demonstrable experience with
interoperability and scalability-- by implementation and
deployment.
>From that point of view, there are three problems with our
present multi-step model:
(1) The complexity of our standards has risen
sufficiently that attaching a single category label
(with only three choices) as the maturity level of an
entire standard just doesn't make sense, if it ever did.
(2) The IESG has both responded to and aggravated the
difficulties of moving from one step to the next by
continually raising the threshold for the first step,
making it harder to get to that step. This creates less
differentiation from the subsequent steps as well as
more exhaustion, both of which deter getting there.
While the rate of deterioration has been slower than one
might expect, this is a positive feedback loop.
(3) If we had wanted to choose a term for the first step
that was guaranteed to cause confusion outside the
community, we could not have done much better than
"proposed standard". With apologies to the IEEE
"Standard for trial use" or even "Preliminary
specification for trial use" would have come much closer
to what we have historically thought we were doing.
I find myself in complete agreement with Dave Cridland's posting
and analysis of 20 September, 2006 10:17 +0100. I think that we
are more or less saying the same thing in different language and
that his explanation is better than anything I could come up
with during the period in which ISDs were a live issue.
ISDs were intended to change that situation, not by having an
extended argument over "two" or "three" (or even "one") but by
* removing both the fixed categories and the notion
that the same classification needed to apply to an
entire document with many features while
* continuing to be very clear about the IETF's beliefs
about the degree to which the specification had been
validated by implementation, interoperability testing or
demonstrations, and deployment.
They were also intended to do another job but, from the
perspective of this discussion, it is merely a useful
side-effect. That was to make it far more clear which
specifications were necessary or recommended to effectively
implement a particular function, answering the "what standard"
question of John Loughney's original I-D on the subject and
providing much of the function of the applicability statements
we never get around to writing.
>From my point of view, ISDs were a proposal for a fairly radical
change in the IETF's standards model and process, albeit one
that brought us closer to what I see as what the community
culture intends than what we have been doing in recent years.
They were much more about that change than about its expression
in specific document formats, organization, or titles. Part of
the community that argued for and against ISDs never understood
that ("non-normative ISD" is about as close to an oxymoron as
one can get). Others understood it perfectly well but were
unwilling or unable to consider anything that wasn't tiny-step
incrementalism.
As far as the "running code" part of this story was concerned,
several drafts were produced that showed what ISDs might look
like and how they might fit in. They were mostly ignored. To
the extent to which they were not, unimportant details of the
examples became the focus of attention, not the goals and
principles of the ISD model.
So we get stuck. Over and over and over and over and... again.
I felt (and feel) that seriously considering and refining a
change in the IETF's model for talking about standards would be
far more productive than an extended debate over "two" versus
"three" (or "one"). I believe that we will never get consensus,
except possibly by exhaustion, on "two" versus "three", mostly
because the change wouldn't solve any significant problem, and
that we will never get consensus on "one" because too much of
the community fundamentally understands the risks of speculative
(or "anticipatory" to use the official term) standards.
john
p.s. to avoid a separate note, Brian wrote...
> There was consensus to put forward the ISD proposal, which the
> IESG kicked back, with an explanation of its issues, which you
> can find in the newtrk archive. That didn't lead to a revised
> ISD proposal.
Obviously, interpretations of this differ. From the standpoint
of at least one of the newtrk authors and proponents, there was
no explanation from the IESG that anyone could satisfy. The
combination of the written explanation and the oral comments was
a general impression that the IESG simply did not like the
proposal because (i) it was too radical, (ii) it was a proposal
for significant change, rather than some incremental tuning,
and/or (iii) it might increase IESG workload for a while. The
message --as received, regardless of what was intended -- was no
proposal with any of those properties, much less all three of
them, was going anywhere as long as the IESG got to decide. And
the logical conclusion from that was that the precondition for
serious process changes was to change the IESG's ability to
decide, not to try to disguise ISDs into something that would
not solve any of the key problems to which they were addressed.
Just my opinion
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf