Republished with HTML adjustments from http://www.esro.org/complaint-2188/one/

Complaints Against The IESG
and The RFC-Editor
About Publication of RFC-2188 (ESRO)

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.

1.
A summary analysis of the publication process for non IETF Informational RFCs both in "theory" and in "practice".
2.
Recommendations For Improvements.
3.
Summary of ALL The Communications Records from the date of submission to the date of publication.

In this section, I substantiate all of the above mentioned claims and problems.

4.
A Message Digest for ALL email exchanges from the date of submission to the date of publication.

Info RFC Publication In Theory and in Practice

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.

Info RFC Publication In Theory

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:

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.

Practice

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.

Un-Answered Questions

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.

Recommendations For Improvements

Because of the RFC-2188 experience and other interactions that I have had with the IESG and the RFC-Editor, I have some suggestions for improving the non IETF Informational RFC publication process and practice.

Limiting IETF/IESG/IAB's role in the RFC Publication Process

Let's look at what needs to happen in the bigger picture. Standardization process iterates through 4 essentially distinct steps.

1) Development of the Protocol.

IETF/IESG are just one of the entities developing protocols. Many good protocols are developed by non-standards related entities.

2) Publication of the Protocol.

A wide open, quick and fair publication service is needed to allow for anyone who wants to build or play with protocols to have access to its specification. The fundamental characteristics of the RFC Publication Service for the most part have been working real well. Any relevant protocol coming from essentially anywhere which meets a minimum technical and/or editorial standard should have speedy access to the RFC Publication Service.

3) Use of the Protocol.

If it is anything useful and is done right, it will be used. How it gets used is very important and unpredictable.

4) Blessing of the Protocol.

Some entity (e.g., IETF/IESG/IAB) blesses the protocol by putting some label on it. Although necessary, this function is mostly ceremonial. The real legitimacy comes from usage and the market place.

Without a question, IETF/IESG/IAB should play some role in step (1).

Without a question, IETF/IESG/IAB need to focus on step (4).

But, I am saying that putting step (2) under management and funding of IETF/IESG/IAB/ISOC is WRONG. Because it has the potential of further suppressing the results of step (1) coming from outside of IETF/IESG.

Note, that I don't have a problem with the spirit of the relationship between The RFC-Editor and IETF/IESG/IAB/ISOC as described in BCP-9. My point is that by making step (2) completely and truly independent of management and funding by IETF/IESG/IAB/ISOC, we will bring about the necessary checks and balances that are needed for a healthy overall process which needs to even encourage competition in step (1).

Summary Of The Communication Records in Chronological Order

All the communication between the Authors, the RFC Editor and the IESG were in the form of email exchanges. There were no phone calls or face-to-face conversations of any sort.

The email exchanges are factually summarized below and reference to the actual email is included.

Jan 11, 97 - Authors To RFC-Editor:
Mark Taylor (then of AT&T) submitted the ESRO protocol for publication as an Informational RFC.
(Message-Id: <32D7FFCA@wddmssmtp.nwest.airdata.com>)

Jan 15, 97 - Mohsen BANAN To RFC-Editor:
Shortly after that (on 1/15/97) I incorporated IANA's port assignment for the ESRO protocol and resubmitted it to the RFC-Editor.
(Message-Id: <199701160714.XAA29795@jamshid.neda.com>)

Jan 23, 97 - RFC-Editor To Authors:
On January 23rd, the RFC editor acknowledged receipt and placed it in the publication queue and forwarded it to the IESG/IETF for their review.
(Message-Id: <199701231743.AA10376@zen.isi.edu>)

Jan 29, 97 - RFC-Editor To IETF-Announce:
The ESRO protocol was put in the internet drafts directory on January 29th.
(Message-Id: <9701300942.aa02647@ietf.org>)

March 31, 97 - Mohsen BANAN To RFC-Editor:
On March 31st I checked on the current status of this RFC and expressed our desire to see it published soon.
(<199704010128.RAA26066@jamshid.neda.com>)

April 3, 97 - RFC-Editor To Authors:
On April 3th we were told that The IESG had requested that the ESRO document not be published at this time and that they would be in contact with us after their meeting that coming week in Memphis.
(Message-Id: <199704032357.AA17887@zephyr.isi.edu>)

April 3, 97 - Mohsen BANAN To RFC-Editor:
I immediately replied requesting an explanation of this delay and the name of the relevant IESG contact person. I again offered to discuss and respond to questions/comments regarding the ESRO protocol.
(Message-Id: <199704040100.RAA07041@jamshid.neda.com>)

At that time our only contact point was the RFC Editor. The Editor neglected to reply to that message. Those questions remain unanswered even today. Had the RFC Editor responded to that message in April, we would have saved a lot of time. The above instance alone justifies my fair use of the word "negligently" with respect to the RFC Editor.

July 28, 97 - Mohsen BANAN To RFC-Editor:

Having not heard from the RFC Editor since April 3rd (nearly 4 months), I prepared a detailed message which explained that the RFC Editor and IESG's treatment of this RFC is totally unreasonable.
(Message-Id: <199707290658.XAA28413@jamshid.neda.com>)

July 28, 97 - RFC-Editor To Steve Coya:

The RFC Editor (Mary Kennedy) forwarded my message to Steve Coya.
(Message-Id: <199707291539.AA11953@zephyr.isi.edu>)

August 4, 97 - Mohsen BANAN To RFC-Editor and Steve Coya:

At that time (6 months after initial submission and a week after my previous detailed request for explanation) Steve Coya and the IESG had still not responded to ANY of our messages and requests.

Our repeated requests for an explanation kept being ignored. The IESG's actions up to that point combined with their dictatorial attitude and arrogance at that point, at a minimum, justifies my use of the words "negligent" and "irresponsible".
(Message-Id: <199708041804.LAA07856@rostam.neda.com>)

August 4, 97 - Steve Coya to Authors:

After more than 6 months, this is the first time that anyone at the IESG has communicated with us. In that message, Steve Coya tells us that the IESG requested that the document not be published. This is a clear violation of the procedures of BCP-9. No where in RFC 2026 is the IESG given the authority to stop the publication of a non IETF Informational RFC. Now, add to that the level of arrogance that says IESG can ignore the Authors' inquiries for 6 months and provide no explanation what-so-ever to why IESG has prevented the publication of the RFC. Then add to it, that later it becomes clear that Steve Coya was just wrong.
(Message-ID: <Pine.WNT.3.96.970804141858.-301315F-100000@dell06.cnri.reston.va.us>)

August 4, 97 - Scott Bradner to Authors:

Scott Bradner tells us that it appears that it might be worth while to issue an IETF last call on it and advance it as a proposed standard! Obviously that was contradictory to what Steve Coya had said earlier that same day.
(Message-Id: <199708041935.PAA05510@newdev.harvard.edu>)

August 4, 97 - Mohsen BANAN To Scott Bradner:

I re-iterate the sense of urgency here.

August 6, 97 - Mohsen BANAN To Scott Bradner:

I check on status of progress and mention that a lot has gone wrong so far and that is why we are impatient.

August 6, 97 - Scott Bradner to Authors:

Scott Bradner tells me that no abuse should be directed towards the RFC Editor.
(Message-Id: <199708061908.PAA09003@newdev.harvard.edu>)

August 7, 97 - Mohsen BANAN To Scott Bradner:

I explain that my use of the words "irresponsibly and negligently" do not constitute abuse towards the RFC Editor. And I justify them again.
(Message-Id: <199708071844.LAA12806@rostam.neda.com>)

August 7, 97 - Scott Bradner to Mohsen BANAN:

Scott Bradner in a message only to me suggests that if I can't see that the tone of my messages are abusive I should talk to a friend.
(Message-Id: <199708071924.PAA10978@newdev.harvard.edu>)

I do not consider this a personal or private message. On a personal level, I wish to have no relationship what-so-ever with anyone on the IESG. I simply want them to fulfill their particular responsibilities with respect to facilitation of publication of my Informational RFCs.

The key point not to be missed here is that if the IESG has been doing its job, we would not be discussing the tone of my messages.

I did not dignify that message with a response.

August 7, 97 - Scott Bradner to Authors:

Scott Bradner tell us that ex-transport co-AD feels that this ID represents a significant technical contribution and feels that it should be advanced on the IETF standards track.
(Message-Id: <199708071943.PAA11036@newdev.harvard.edu>)

Scott Bradner asks us to choose between the Informational RFC publication route or the Proposed Standard route.

August 8, 97 - Mohsen BANAN To Scott Bradner:

The Authors choose the Informational RFC route because the urgency for publication in this case outweighs our interest in getting this document on the standards track.
(Message-Id: <199708081853.LAA14067@rostam.neda.com>)

August 8, 97 - Scott Bradner to Authors:

Scott Bradner asks: What is causing this feeling of urgency?
(Message-Id: <199708082046.QAA01197@newdev.harvard.edu>)

August 8, 97 - Mohsen BANAN To Scott Bradner:

I explain.
(Message-Id: <199708082219.PAA14258@rostam.neda.com>)

August 17, 97 - Scott Bradner to Authors:

Scott Bradner informs us of his recommendation of ESRO for publication and that he hopes we will put this specification on standards track when it is ready.
(Message-Id: <199708180051.UAA08685@newdev.harvard.edu>)

August 17, 97 - Mohsen BANAN To Scott Bradner:

I thanked him and said that I will.
(Message-Id: <199708180434.VAA26606@rostam.neda.com>)

August 18, 97 - Scott Bradner to Authors:

Scott Bradner forwards a technical comment from Harald Alvestrand to the Authors. This is the *ONLY* technical comment that we ever received from the IESG or the RFC Editor.
(Message-Id: <199708181217.IAA09055@newdev.harvard.edu>)

August 18, 97 - Mohsen BANAN To Scott Bradner:

I respond to that technical comment.
(Message-Id: <199708181850.LAA27366@rostam.neda.com>)

August 28, 97 - Mohsen BANAN To Scott Bradner:

I explicitly ask that he keeps me posted on his communications with the RFC Editor related to this RFC.
(Message-Id: <199708282146.OAA11605@rostam.neda.com>)

If there was to be an IESG Note, I wanted to have a chance and see it before publication.

August 28, 97 - Scott Bradner to Authors:

Scott Bradner informs us that he publication was approved by the IESG. But does not mention anything about the IESG note.
(Message-Id: <199708282229.SAA23730@newdev.harvard.edu>)

September 9, 97 - Mohsen BANAN To Scott Bradner:

I ask about the expected publication date.

September 9, 97 - RFC Editor to IETF-Announce:

The RFC Editor announces publication of RFC-2188.

The text of RFC-2188 is materially same as what we submitted to the RFC Editor on Jan 15, 1997, with the exception of the IESG note.

To our surprise we discovered the following IESG note in our RFC.

IESG Note

   This protocol has not had the benefit of IETF Working Group review,
   but a cursory examination reveals several issues which may be
   significant issues for scalability.  A site considering deployment
   should conduct a careful analysis to ensure they understand the
   potential impacts.

A few key points about this IESG Note:

If any of my employees were to ever be responsible for a small fraction of the types of arrogance, negligence and mistakes that were commited during the process of publication of RFC-2188, I would fire or demote them immediately.

But, the IESG is a collection of volunteers which answers to no one.

Unless we can find a way to deal with problems like this and fix them, I am afraid that arrogance, negligence, irresponsibility and incompetence will be institutionalized inside of the IESG.

Message Digest

ALL of the messages related to this case that I originated or received starting from the time of initial submission up until the time of publication of the RFC are included as 30 email messages below. Other than deleting the attachments of the original specification, these messages have not been edited in any way.

My interactions with individulas at the IESG and the RFC Editor were in the context of them functioning in their roles as Service Providers. I consider none of these email messages private or personal or confidential.