ietf
[Top] [All Lists]

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

2011-09-07 10:33:23
On Sep 7, 2011, at 10:17 AM, Ned Freed wrote:

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.

I am aware of those, but I consider those the rare exceptions to the general 
rule.  I also think that the email community has a couple of influential 
individuals who really believe in following the process all the way through, 
but that belief is not typical of IETF as a whole.

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.

Yes, I really think that holds as a general rule.  Again, to me the email 
advancement efforts look like the exceptional cases.   (I applaud those 
individuals for their diligence!)

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

If it were generally clear that this change was a Good Idea, I might buy that 
argument.  But what you seem to be saying is that if people don't back this 
change even though it appears to many people to be useless at best (and harmful 
to some), they'll never back any change to our process even if it appears to be 
more useful.

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?

FIne.  Let's rename "Proposed Standard" to something that doesn't contain the 
word "standard" (call them "frobs" for the sake of argument).  And let's not 
publish them as RFCs, but instead leave them as Internet-Drafts, and amend the 
rules for Internet-Drafts to allow "frobs" (once approved by IESG) to expire in 
two years rather than six months.  

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.

I agree at least somewhat with that.   I do think that our processes in general 
need more use of engineering discipline, but I also think that there will 
always be things that slip through the cracks.  Which is why we need a process 
that recognizes the need for specifications to be maintained in light of 
experience.

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>