On 4/9/00 at 12:39 PM -0800, ned(_dot_)freed(_at_)innosoft(_dot_)com wrote:
>[...]the RFC Editor exercises editorial control over the RFC series,
>but doesn't specify exactly what editorial control means.
Actually, Harald's quote from 2026 does make it pretty clear:
Section 4.2.3:
The RFC Editor
is expected to exercise his or her judgment concerning the editorial
suitability of a document for publication with Experimental or
Informational status, and may refuse to publish a document which, in
the expert opinion of the RFC Editor, is unrelated to Internet
activity or falls below the technical and/or editorial standard for
RFCs.
>However, the RFC Editor has interpreted its editorial
>responsibilities as involving review with the distinct possibility
>of not publishing documents not believed to be worth publishing for
>at least as long as I've been involved in the IETF.
Absolutely. The question is on what basis that decision is made. 2026
gives basically two criteria by which the RFC Editor may refuse
publication:
1. It's unrelated to Internet activity. That's the one Dave and I
(and others) have been pointing to. Clearly this draft is related to
Internet activity; it's deployed technology, for better or for worse.
2. It falls below the technical and/or editorial standard for RFCs.
Now, I think we all agree that the current document *does* fall below
editorial standards insofar as it plays the "I am a standard" game in
the text, making itself out to sound like a standard even though it's
not. The document should be held up until that is fixed. But again,
that's not Keith's main issue. He's complaining about "technical
merit" (and sometimes legal or moral merit).
Well, there's at least one more that's clearly called out in RFC 2026: If a
document is directly related to an area where there's ongoing IETF standards
activity it should not be published. (It isn't clear to me whether or not the
present document falls into this category.)
But regardless of the specifics in RFC 2026, my point is I've seen past cases
where the RFC Editor has refused publication where the apparent basis was none
of these things. And in particular, there have been cases where it was clearly
technical merit in Keith's sense of the term that was at issue. (I've also seen
cases where there were clear technical merit issues but publication happened
anyway.)
And nowhere does RFC 2026 say that the list of criteria for rejection it
provides is deemed to be exhaustive.
So, here I want to split a hair, but I think it's one worthy of
splitting: RFC 2026 says "falls below the technical *standard* for
RFCs". I don't believe what it's referring to here is whether the RFC
Editor thinks that the document is describing a technically a bad
idea, but rather whether the technical *quality* of the document
(e.g., whether it is technically coherent, describes the protocol in
appropriate detail, doesn't have the classic Gary Larson "...and then
a miracle occurs..." clause in the middle of equation, etc.) is up to
snuff. This seems like a good criterion to base publication on,
whereas the other does not: It is always good to publish what I'm
likely to have to deal with on the net, whether or not it's a good
thing that it actually is going on.
I'm sorry, but I think splitting this particular hair is a place we really
don't want to go. I'd much rather rely on the RFC Editor's judgement
as to whether or not to publish something than try to nail down an
exhaustive list of criteria for rejection (or acceptance).
And if you don't believe this is a really bad idea, I suggest that you read
"The Death of Common Sense". It argues this point rather forcefully IMO.
It is of course a good thing not to standardize things that are
technically bad ideas. But standardization is not at issue here. This
is a question of how the RFC Editor should exercise its editorial
judgement. 2026 lays out a reasonable guideline. I think Keith's
request falls outside that (admittedly loose) bound.
I'm afraid I have to disagree. I think that Keith's assessment of technical
merit is a completely valid input to the decision process. The furthest I'd go
is to say it is by no means a decisive factor. However, in the case of the
present document I also think its more or less a moot point, as there are
plenty of other reasons why the document should not be published in its present
form, and once those are addressed the technical merit issue will have been
addressed as well, one way or the other.
Ned