On Fri May 6 17:50:07 2011, Andrew Sullivan wrote:
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote:
> On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
> >I think he is saying that there is are _de facto_ criteria that
> >neither called out in 2026 nor in this draft, and that those
> >are the running code, so the documentation ought to be made to
> Oh. But then that doesn't mean that the /current/ draft lowers
> quality but that the existing process has exhibited the lower.
No, it does not.
RFC 2026 has a low bar of entry to get something published as PS.
As a matter of fact, we don't do what's in 2026. Things published
PS are often quite mature. Since just about nothing moves past PS
anyway, people regard it as the effective final level of
standardization and therefore require high degrees of review before
publication. And once something is published at PS, it is all but
impossible to change it in any but the most trivial ways, because of
all the contracts that refer to that RFC and require conformance.
in fact a document published as PS has met criteria more stringent
than RFC 20206 would have one believe.
The present draft explicitly says that the actual criteria as
published in RFC 2026 are the right ones, and that additional
unwritten conventions and so on are to be removed.
Therefore, if one thinks those more stringent criteria make for
quality, then the current draft will lower quality.
I think we could state this all more neutrally by saying only that
existing actual criteria do not match the published criteria, and
therefore when the current draft says "go back to RFC 2026 published
criteria" is is in fact changing the criteria. Then we don't have
have an argument about whether the quality is better, since I don't
know how that would be measured anyway. But in any case, the
flat out admits that it is changing these criteria:
Various influences have made publishing a Proposed Standard much
harder than the stated requirements in RFC 2026. The intention
the two-tier maturity ladder is to restore practice to the
requirements for Proposed Standard from RFC 2026, and stop
performing more scrutiny than intended in IETF working groups and
So we should not pretend that the draft doesn't change criteria for
PS. It just reiterates a position about what should happen. It
remains to be seen what will actually happen.
Thanks for explaining that; it is indeed what I'm trying to say.
And again, I have no horse in this race. I don't believe the
will make any difference at all, but for that very reason I don't
whether it is adopted.
I would rather not make the situation worse, especially without
documentation which shows we have a real understanding of the
de-facto standards process.
Ideally, I'd rather we first - before any attempts are made to change
the standards process - document what it *is*.
Then, we should have a clearer understanding of the problems we're
attempting to solve, and it should prove a lot less contentious.
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Ietf mailing list