John C Klensin wrote:
Ed, I've followed your comments very carefully, but, applying
your reasoning to what I see as long-standing principles for
handling Info RFCs, I reach nearly opposite conclusions.
Then, we have gone full circle because your reasoning is exactly
mine in its gist -- as I wrote in the subject line, NSI should go back
with the proposed RFC and make it clear before it is accepted to
be published as an info RFC.
I think your review is also very useful for future uses and it
helps IMO to stress the IETF role as a third-party in the process.
I am snipping it off for clarity here, not for lack of importance.
In summary, I believe that our advice to the IESG should be
"make certain this document is clear about what it is and what
it proports to be, and that the authors (or author organization)
take responsibility for that being true. Make certain that,
should a RRP WG effort be launched, this document doesn't
unreasonaby constrain it. If areas are identified in which the
document isn't clear about what it calls for, get those fixed.
Consider attaching a disclaimer that indicates the list of
unresolved issues contains some fairly serious problems and that
there may be equally serious issues not on that list. Then,
since it is relevant and not obviously stupid, go ahead and
publish the thing."
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.
And this has nothing to do with "freedom of press" but with
old accepted rules of technical publication in whatever forum.
Cheers,
Ed Gerck