--On Wednesday, 05 January, 2000 06:32 -0800 Ed Gerck
<[EMAIL PROTECTED]> wrote:
> Yes, but IMO IETF RFCs, even informational, should not be
> bureaucratic milestones in a chart but real contributions --
> where it is OK to be wrong since in Science a NO is also an
> answer. So, an RFC should not be fictional or clearly wrong.
Ed,
Assuming for purposes of argument that I agree with this
distinction, the hypothetical chart and its milestones are a
strawman. I'm not especially attracted to the reasons some
people participate in the IETF, but I think we need to judge the
quality of the output almost independent of our guesses about
the psychology of its sources. Moreover, there has always been
a distinction between Informational RFCs --which are expected to
be an explanation or statement about something-- versus
Experimental ones. The latter should be subject to the
scientific criteria you suggest. Indeed, I've often felt that
we would be better off if the authors of Experimental RFCs
assumed an obligation to come back after a reasonable amount of
time and write a new RFC explaining how the experiment came out
and proposing the next experiment if appropriate.
If something is an opinion about how something should be done,
one might disagree with it and it might even be wrong
technically, but that doesn't make it an invalid statement about
that opinion. And, if someone asserts that something they want
to publish describes a partcular process, then I believe that we
should publish that assertion along with the description. But
going further than that takes us dangerously close to certifying
that the document and the implementation match, and that just
isn't a good idea.
> And this has nothing to do with "freedom of press" but with
> old accepted rules of technical publication in whatever forum.
When I review things for a journal, I review them differently,
and apply different criteria, depending on whether they
represent opinion pieces or description on the one hand or,
e.g., experimental results.
Let me try a strawman out on you: Suppose I came to the RFC
Editor with a document entitled "a review of operational
experience with the foobar protocol" that I wanted published as
informational. It would be entirely rational for the RFC
Editor (or the IESG) to issue a Last Call whose key question was
"does this description agree with the experience of others".
Now, for many scientific publications, if the answer came back
"no", the paper would go back to the authors, with a note that
said "talk with these other folks and revise". The tradition in
the RFC series (and with some journals) has been that such
things are suggested but, when the fail, the document is
published, sometimes with an "opinions differ" disclaimer and
the commenters are encouraged to write their own critiques.
Either approach is scientifically reasonable and can be quite
effective and illuminating; the second is arguably better at
spreading knowledge of negative results.
But this document is, I believe, an NSI statement of what they
think the protocol is, or would like the protocol to be, or
want people to think the protocol is (again, I think that needs
to be clear). To the extent that it is an accurate statement of
their views in one of those categories, it can't be "fictional"
or "clearly wrong". To the extent that they claim it reflects
the protocol and you believe it doesn't, your best recourse is
to drop NSI a note that says, more or less, "if you publish that
as if it were the protocol, I'll round up a bunch of registrars
and sue you... partially on the theory that the Judge can lift
the NDA that prevents our making the problems public". But that
isn't an IETF problem, and we put the IETF at risk by tryng to
make it one.
john
