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
