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

[[e-mail]]

> 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.

Just one small problem here - every document advancement exercise I've seen in
the past two decades - and I've seen a bunch - directly contradicts your
assertions here.

In essentially every case advancement occurred when some individual or some
subgroup believed doing so was important and pushed the issue. The most common
reason for believing that is probably that the document in question replaces
some other document that's already at draft or full, and IETF rules require
advancement before the original document can be marked historic. The SNMP and
MSGFMT/SMTP specifications are both good examples of this.

In other cases advancement was the result of a strong sense that it was needed
to legitimize the specification. This is why MIME was advanced so quickly. And
please note that in the case of MIME we advanced it with minimal changes first
(RFCs 1521/1522 aren't that far from 1341/1342), and only then revised it
extensively (RFCs 2045-2049) without further advancement. So much for the
notion of using advancment as an excuse to fix stuff.

Another common reason to advance a specification has been the simple belief
that following out processes is the right thing to do. I assure you that was my
only real motivation for working to advance the SMTP extensions framework, the
SMTP size extension, and the PIPELINING extension.

And finally, there are cases where the motivations for pushing for advancment
were frankly mysterious to me. The FAX WG experience comes to mind here. To
this day I have no idea why advancment of those specifications was so
important, especially when many similar groups clearly didn't give a crap about
following the process.

Now, I have no doubt that if you looked hard enough you can find a case or two
where the primary motivation was to pry something open and fix it. However, the
opposite sentiment is far more common: "Opening that up would be a real can of
worms so please don't try and advance it". Nevertheless, the assertion that
this is the only reason for advancment is demonstrably false.

> We've been using "advancement" as a proxy for "maintenance" for about as long
> as I've been in IETF.

Wow, you really think that? I'm frankly amazed at the degree of disconnect
here.

> (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.)

Well, now you're shifting to talking about a fundamental change of
philosophies. Tell you what - let's see if even a small change like this one is
possible first, because if it isn't a shift like this isn't even worth wasting
the electrons to discuss.

> > 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.

There are things we have control over and things we don't. We have no control
over this. The best we can do is to make our labels meaningful - and they
aren't currently. So perhaps we should fix that, you know?

> > 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.

That presuppoes we have the ability to actually perform such analysis without
actually trying things at some sort of scale. I'm sorry, but I've seen no 
evidence that the necessary skills for this actually exists.

				Ned