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).
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.
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.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102