As the person who most recently complained, let me elaborate on my comments. The problem I believe we all are facing is that the distinction between Proposed, Draft, and Internet Standard has been lost.
I agree with you 100% that...
The point of proposed standard is to throw things out there and get implementation experience.
But when it comes to...
If specs are unclear, then we're not going to get implementation experience; we are going to waste time.
We disagree (slightly). In my experience one needs to actually get the implementation experience to recognize when things are unclear. And my understanding is that this is precisely why we have PS and DS.
I've had a lot of experience with a rather unclear spec with some significant problems that managed to make its way to proposed standard: For the past 10 years I have been dealing with problems in Kerberos (RFC 1510). This leads me to believe very strongly that catching problems before documents reach PS is worth a fairly high price in time.
We come to different conclusions here. My conclusion is that no standard should remain at proposed for more than 2 years unless it's revised. Either it goes up, it goes away, or it gets revised and goes around again.
Your fundamental problem with RFC 1510 is that it is too painful for people to go and fix the text. And that's a problem that should be addressed as well.
Thus, let the IESG have a bias towards approval for PS, and let implementation experience guide them on DS and full standard. But set a clock.
This has impact on the WG process of course. People want to do their work and go home. We like WGs to end. Well, what really needs to happen is that either the WG hangs around to push the thing forward, or the doc needs to be assigned some sort of standing WG, akin to a an area directorate, who will take responsibility for moving it forward or killing it.
And moving it forward shouldn't be that hard EITHER. Mostly in the editing of clarifications, removal of functions not found to be used, or perhaps changing a few SHOULDs to MUSTs and visa versa.
Let's take an example: COPS-PR; RFC 3084. How many people actually implement it? If we can't find anyone who is, won't it just cause confusion to leave it at PS?
And I'd like to know when someone plans to do the work to get Kerberos to DS. Heck, at least it's used by people. Consider HARPOON, RFC1496 on the downgrading of X.400/88 -> X.400/84 with MIME. Ya think Harald wants to take the time to update that one now?! Well, why didn't it happen in some reasonable period of time, when perhaps it might have been more interesting? Was it because nobody actually implemented it or was it simply because nobody felt the need to update it?
That said, I realize too much time can be spent on a review. When we're not sure we understand the implications of an issue well enough to know whether it will a be a problem, letting a document go to PS and getting implementation experience can be useful.
Don't get me wrong. Some review is definitely in order. In as much as they are going to happen they should happen either prior to sending the doc to the IESG at all (remaining within the WG) or in parallel with IESG review.
Similarly, if the review process will never successfully conclude,
then having the review early is good.
ALso, I am simply saying that waiting for complete reviews is good and the pressure to get things out as PS faster with less review is dangerous.
Only because today PS = Internet Standard, in reality. And that's what needs to change.
Eliot