> From: [EMAIL PROTECTED]
> ...
> Then I took a look at RFC2026 in closer detail, and section 3.3 (e)
> defines a "Not Recommended" status, just like I remembered.
>
> Unfortunately, that seems to be strictly applicable to standards-track
> documents only, not 'informational'. Whether this is a bug or a feature
> I'll let others decide - it looks like a giant economy sized can-o-worms.
I've been whining about such problems with informational RFC's for years.
It's clear that for familiar bureaucratic and social or political reasons,
the IETF will not in the foreseeable future do any real filtering of
Information (or even in many cases of standards track) RFC's. Even I
admit that real filtering would have major problems and leads inevitably
to something even more like the ANSI, IEEE, and ITU than the IETF has
already become.
There is an alternative that would be more effective and easier. That is
to do even less filtering than is done now. Advancing many drafts like
draft-terrell-ip-spec-ipv7-ipv8-addr-cls-*.txt would go a long way to
removing the incentive for organizations to try to misappropriate the
cachet of the IETF with Informational RFC's. Flooding the space with
RFC's that are other than influential would be more effective than any
disclaimers, more effective than filtering, and easier than the limited
filtering currently provided by the IESG and the RFC Editor.
I suspect analogous thinking but about the academic stuffed shirt syndrome
was one of the motivations for the early April Fool's RFC's. Today, the
audience (and many of the authors) of RFC's are not capable of inferring
such an implication of new versions of Avian Carriers. Something less
subtle is needed.
In other words, consider the ideas behind the censoring that has gotten
some ISP's into trouble and the lack of censoring that has protected
others.
Vernon Schryver [EMAIL PROTECTED]
