Re: IESG review of RFC Editor documents

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Keith,

Pete has covered most of what I would have said, but I want to address one other issue with your comments/ suggestions.

It seems to me that at least latent in your suggestions is the assumption that the RFC Editor should publish only IETF consensus documents or documents that are in general agreement with IETF consensus. My sense is almost exactly the opposite. The IESG is not omniscient and wouldn't be omniscient even if they had a lot more time. The IETF isn't omniscient either. And nothing in our process, including the appeals process, is designed to deal effectively with something that has consensus, including IESG consensus, but is still wrong-headed.

IMO, one of the most valuable types of documents the RFC Editor could publish would be an independent, in-depth analysis of why some standards-track document was an operational hazard and generally a complete crock of excrement. Now I would expect that a very high editorial and technical standard would be applied to the arguments of such a document. I would expect it to be excruciatingly clear that the positions it was taking were in disagreement with an IETF Standards-Track procedure. But I would hope it would be publishable, and, given those document quality standards, published, even if every single member of the IESG disagreed with its stated position.

Clearly-stated dissent is not "harmful". Indeed, I suggest that it is healthy. And the procedure you propose would tend to suppress such dissent, no matter how well reasoned that dissent was.

More broadly, our standards process has an almost-unique property relative to most other standards groups in the information technology area (and relative to all of those I would consider even moderately successful). In their processes, there comes a point in the approval process in which people who disagree with the proposed document are explicitly identified along with their disagreements and, in some form, exactly what it would take to get them to agree. Then there is a very serious process to try to resolve the disagreements and, if that fails, often nearly-automatic appeals on the substance of the proposal, documentation of the disagreements, and so on. That model has some advantages and many disadvantages but the important thing is that we don't use it.

Instead, we use the notion of "rough consensus" to essentially run over dissent by small minorities, even small minority dissent that is well-reasoned and has significant merit. And our appeals is useless in dealing with that issue because the "rough consensus" really does exist. And that makes the ability for the dissenters to write a dissent, and have it published in near proximity to the official/standard specification, really important to preserving the openness and honesty of the system. Without it, all sorts of theories about cabals become very plausible.

Now we haven't used that mechanism very much. In my personal opinion, we haven't used it nearly often enough -- especially in the last several years, the losing dissenters have tended to just go away rather than documenting their positions --but that is another issue. But taking it away, which I think your suggestion would ultimately do, could ultimately be extremely harmful to our standardization model.

john


--On Friday, 26 March, 2004 16:21 -0500 Keith Moore <moore@xxxxxxxxxx> wrote:


Okay, I read draft-iesg-rfced-documents-00.txt regarding a
proposed change in IESG policy regarding RFC-Ed documents.

I'm opposed to the change, because I believe it would make it
too easy for harmful documents to be published as RFCs.
...



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]