At 09:36 AM 3/27/2004, Harald Tveit Alvestrand wrote:
That, I think, would be counter productive. I think it fairly
apparent that there is a fair amount of crap (by mine, your, or
anyone's opinion) published as RFCs. I content that much of
that crap was produced by the IETF.
permit me to disagree..... not with your core statement, but with the
statement that citing examples would be counterproductive.
I was attempting to make a few points:
1) the series is not intended to be "crap" free
2) what is "crap" is quite subjective
3) we need to continue to allow others to publish
what we might consider to be "crap".
which may have been missed by some.
What I personally view as "crap" has no bearing in regards to these
points, excepting that where I feel strong enough to produce an I-D
detailing why I think something is "crap" I should be allowed
(if I can met general editorial and technical standards) to publish
that opinion as an RFC even though consensus of the IETF (or Keith's
review board or the RFC Editor) might be that my opinion is "crap".
(That opinion could be expressed in the form of an alternative protocol
specification.)
The statement that "a fair amount of crap is published as RFCs" has been
repeated for so long that it's almost become a mantra.
Yes. But normally its uttered as an argument to increase publishing
requirements. I am arguing that we should not increase publishing requirements
here.
However, in my opinion, for *every single one* of those RFCs, there's a reason
why it was published. If we are to change the process that produces this
stuff, we HAVE to understand what the reasons are that reasonable, competent
people produce things that are sub-par, broken or "crap". And IMHO, we can't
do that without saying what these unacceptable results of the process are.
Yes. I argue that we should not change the process (as described
in RFC 2026) that produces this stuff as that process is producing
acceptable results (e.g., the current level of crap is acceptable).
Moving from the generic to the specific might actually be an useful catharsis
for the community - and just might change the community opinion from "a lot of
our 3000 RFCs are crap" to "there are 30 bad RFCs, 300 that could have been
better and 3000 reasonably OK ones", or even to "the quality control system
does not work well enough, there are too many borderline cases".
It would be interesting to see how many of documents folks consider
to be crap would have been blocked under a different process. If
I look at the documents that stand out to me as crap, I note that
Keith's new review process would have no impact... as most of the
documents I consider to be crap were produced by the IETF or
underwent some IETF review. But I'm not of the opinion that the
documents I consider to be crap should have been blocked (though
I might argue that some of them shouldn't be on the Standard Track).
I don't think anonymous, class-based criticism will get us much further. We
need to be specific about what our problems are.
The problem I see with being specific here is that what's crap to me
is not necessarily the same as to you, and we'll just end up arguing
over wether something is crap or not, and that will overshadow the
key aspect of my argument that we should each be allowed to own
opinions as to what is crap and be able to act on those opinions,
including publication of what others might consider to be crap.
Kurt