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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
