Mohsen Banan
mohsen@neda.com
November 5, 1998
This is a complaint against the IESG and the RFC-Editor about publication of RFC-2188 (Efficient Short Remote Operations - ESRO) as an Informational RFC. A lot went wrong in the process of publication of RFC-2188. The highlights are:
I (Mohsen Banan - mohsen@neda.com) have used very strong words in the above list to characterize the problems in this specific case. Use of those words are in no way extreme. Use of ALL of those words are justified in this message.
The fact that a lot went wrong in the case of publication of RFC-2188 is known to many. Steve Coya and Scott Brander have admitted that there were a number of problems and have apologized for them.
Scott Bradner> ... the iesg fucked up and I'm trying to fix the issue ... Steve Coya> You DO have a valid complaint, but not with the RFC Editors. Scott Bradner> ... As I said things slipped through Scott Bradner> the cracks and I am sorry that happened. ...
I accepted their apologies and after the publication of RFC-2188 I was going to let this drop. However, since then I have seen even more evidence of the IESG being way out of control and now feel that something needs to be done.
This note is complete and includes all that is necessary to allow people to judge for themselves the validity of my complaints.
My goal is to PRESERVE the so far mostly open Informational RFC publication process from censorship by the likes of IESG. We need to find a way to ensure that what went wrong in this case never happens again. I am preparing this complaint because I think that it can help a number of areas which are critical to the continued success of the Internet.
In the absence of any sort of accountability by the IESG and the RFC-Editor to anyone, I am hoping that peer pressure and public embarrassment can be used as tools to bring the IESG under control and restore the Information RFC publication process to the open process that it is supposed to be.
Internet Standards are better than other standards because we realize that no entity (IETF/IESG/IAB) has exclusivity on good ideas. Many (if not most) good/successful Internet protocols have come from outside of committees, task forces, groups or boards. (If you are looking for examples, consider the web.)
Fair and equitable access to the RFC publication service is fundamental to the success and growth of the Internet. Good protocols (as well as bad protocols) coming from outside of the IETF should have access to the RFC publication service, so that they can be used and even sometimes compete with IETF/IESG work. The network and the market place ultimately decides the winners and the loosers.
Now, my experience with the publication of RFC-2188 has convinced me that:
If any of the above is true we have a problem. Unfortunately, this note clearly demonstrates that all of the above were true in the case of RFC-2188. I am also now convinced that the problems in the case of RFC-2188 were not isolated to that case alone. There is a serious problem.
The rest of this note substantiates my claims about the problem. Because this deals with a concrete and specific case, because it deals with history of what has already happened, because it is a complete case, I hope that this note can be used to identify and fix the serious problems that exist.
Because this note is documentation of a complete case, it is somewhat lengthy.
This note is organized in 4 sections.
In this section, I substantiate all of the above mentioned claims and problems.
In theory, "The Internet Standards Process" (BCP-9, RFC-2026) defines at a high level a very reasonable process for publication of non IETF protocols as Informational RFCs. The problem is that in practice that process is not followed. The IESG is allowed to indefinitely delay the publication of RFCs or simply reject them because the IESG does not get them or because the IESG does not like them.
The highlights of the process of publication of non IETF protocols as Informational RFCs (taken from sections 4.2.2 and 4.2.3 of RFC-2026) are:
In that case the document may still be published as an Informational RFC with an IESG disclaimer.
This process is very reasonable. Irrelevant or sub-standard specifications (such as Internet Porn Protocol - IPP) will be stoped by the RFC-Editor. Reasonable protocols get a chance to be published in a timely manner. The IESG is not allowed to censor anything in favor of its own activities or opinions.
In practice the role of the RFC Editor for documents coming from outside of the IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG. In other words in practice the IESG has already expanded its limited role as a conflict detector to a commentator and the authorative reviewer and the final decision maker.
In practice, the RFC Editor is not in charge the IESG is.
Neither the IESG, nor the RFC Editor have any respect for the requirement of "timely" processing of the non IETF Informational RFCs.
During the process of publication of RFC-2188 when it became obvious that the process being followed is not that of BCP-9. I started asking the following questions. These questions were asked a number of times from the RFC-Editor and the IESG. They have never responded to any of them. They remain unanswered.
In light of everything that happened in the case of RFC-2188, I consider all of these questions valid and legitimate. These questions have been asked many times to no avail. They remain unanswered.