On Sep 6, 2011, at 2:26 PM, Ned Freed wrote:
I find it impossible to believe that this will not result in even more
hard-line positions on the part of some IESG members when something
with which they disagree is a candidate for PS. I see no way in which
the draft solves this problem, which remains one of its implicit
goals. I said before, I don't care if it is published, because I
think it will have little effect. But I think we'd better be prepared
for some IESG members to insist on the same high bar for PS that we
have under RFC 2026, regardless of what the RFC says.
+1
Best statement of the problem with this document that I've seen so far.
Except for one small problem: It's nonsensical.
Why is it nonsensical? Because you're comparing the status quo with a possible
future course of action. The one thing that's we can be certain of is things
won't remain the same. They never do. So in order to make a reasonable
comparison you have to project what's likely to happen if this document isn't
approved, then compare that with what might happen if it is.
And the future where this isn't approved is fairly easy to predict: As more
and
more documents become proposed standards and then fail to progress along the
standards track - and the trend lines for this could not be clearer - we
effectively move more and more to a one-step process.
Face it, we've effectively had a one-step process pretty much ever since 2026
was approved. For the most part, the documents that have advanced have been
those that were buggy enough to need to be fixed, but not so buggy that they
had to recycle at Proposed. We've been using "advancement" as a proxy for
"maintenance" for about as long as I've been in IETF. (Which is why what I
think we need is to restructure our processes so that they actually are
designed to _maintain_ our specifications rather than pretending that there's
ever a situation when those specifications are "mature" in this constantly
changing world.)
The IESG has only one rational response to that: Continue to raise the bar on
the initial step to proposed.
And that was indeed a perfectly rational, and reasonable, response. Nor is
there anything that changing our process can really do about that, so long as
our first publications intended for public consumption are labeled "______
Standard" and as RFCs (as people think the latter means "standard" no matter
how much we protest to the contrary). Changing what happens _after_ Proposed
Standard and/or RFC publication will never address this problem.
Will the imposition of a two step process change this? It certainly won't do
so
immediately, so the likely outcome is that yes indeed, the bar will continue
to
go up, at least initially, irrespective of whether or not this document is
approved. But if more documents start advancing - and yes, that's an if - that
will lessen the pressure on the initial step, and perhaps break the cycle
we're
currently stuck in.
You might turn out be right, but I don't see things happening that way. The
reason is that I don't think that either implementors or the consumers of
hardware and software that implement these protocols care about whether we
label something as a Proposed Standard or an Internet Standard. Proposed
Standards are still going to get implemented and widely deployed. And when
they break, it's still going to be a big mess. IESG is still going to feel a
responsibility to try to do something about it. As they should.
And please don't try trotting out a bunch of additional what ifs about how if
this proposal fails we can then get past this distraction (or however you
would
characterize it) and address whatever it is you think the actual problems are.
The actual problem is that people think that deploying products based on
Proposed Standards is a good idea, and our process doesn't consistently produce
documents of sufficient quality to warrant that. There are two ways to fix
that problem. One is to stop labeling our initially published specifications
(intended for prototyping and testing) as either Proposed Standards or RFCs.
The other is to impose more engineering rigor on the process that leads to the
creation of Proposed Standards.
Given the time that has gone into trying to make this one simple and fairly
obvious change, if it fails, the odds of someone attempting even more
fundamental changes are pretty darned low.
Except that, for some reason, the "obvious" change is obviously wrong to many
of us.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf