Sam,
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