Re: Back to the drawing board,was Re: Last Call: Registry Registrar Prot

--On Wednesday, 05 January, 2000 06:32 -0800 Ed Gerck 
<egerck(_at_)nma(_dot_)com> 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