Re: Conclusion of the last call on draft-housley-two-maturity-levels

[Keith Moore <[e-mail]>]

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