main.tty
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:
fflThe publication of the RFC was delayed for *8 months* for no good reason.
fflDuring the period from the day of submission to the day of publication (8*
* months)
there was only one technical email exchange related to this RFC and the RF*
*C was
published exactly as it was submitted (plus the IESG note).
fflThe IESG was irresponsible and negligent in fulfilling its role.
fflThe RFC-Editor was negligent in fulfilling its role.
fflIn practice, the publicized processes and procedures for the Informationa*
*l RFC
publication were not being followed neither by the IESG and nor by the RFC-
Editor.
fflIn practice, RFC-Editor was reduced to a puppet of IESG acting as a glori*
*fied
secretary and an inefficient messenger.
fflThe IESG over stepped the scope of its authority and displayed an arrogan*
*t an
dictatorial attitude which caused serious delays in the publication of the*
* RFC.
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 kno*
*wn
to many. Steve Coya and Scott Brander have admitted that there were a number of
problems and have apologized for them.
1
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 t*
*hat what
went wrong in this case never happens again. I am preparing this complaint beca*
*use I
think that it can help a number of areas which are critical to the continued su*
*ccess 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 pro*
*cess
to the open process that it is supposed to be.
Internet Standards are better than other standards because we realize that n*
*o entity
(IETF/IESG/IAB) has exclusivity on good ideas. Many (if not most) good/successf*
*ul
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 t*
*he suc-
cess and growth of the Internet. Good protocols (as well as bad protocols) comi*
*ng 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:
fflthe IESG frequently abuses its authority and in fact is allowed to delay *
*the publi-
cation of RFCs indefinitely and even engage in censorship of material that*
* it just
does not like or that it does not understand.
fflboth the IESG and the RFC-Editor operate with an "authority" oriented att*
*itude
as opposed to a "responsibility" oriented attitude.
fflin practice there are not adequate checks and balances in the process to *
*guard
against mistakes by the IESG or the RFC-Editor.
If any of the above is true we have a problem. Unfortunately, this note cle*
*arly
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 c*
*ase
alone. There is a serious problem.
The rest of this note substantiates my claims about the problem. Because thi*
*s deals
with a concrete and specific case, because it deals with history of what has al*
*ready
2
happened, because it is a complete case, I hope that this note can be used to i*
*dentify
and fix the serious problems that exist.
Because this note is documentation of a complete case, it is somewhat length*
*y.
This note is organized in 4 sections.
1.A summary analysis of the publication process for non IETF Informational R*
*FCs
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 prob*
*lems.
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 Informationa*
*l RFCs.
The problem is that in practice that process is not followed. The IESG is allow*
*ed to
indefinitely delay the publication of RFCs or simply reject them because the IE*
*SG 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 Informati*
*onal
RFCs (taken from sections 4.2.2 and 4.2.3 of RFC-2026) are:
fflInformational designation does not represent an Internet recommendation o*
*f any
sort.
fflPublication of Informational RFCs is supposed to be "timely".
fflThe RFC-Editor (and NOT the IESG) is responsible for determining suitabil*
*ity
for publication based on:
-Relevance to Internet activity
-Meets the technical standard for RFCs
-Meets the editorial standard for RFCs
fflThe RFC-Editor refers the document to the IESG for review which is to be *
*in a
timely manner. The scope of IESG's review of the document is to identify a*
*reas
of overlap with on going or future IETF activities.
-The IESG can recommend that the document be brought in the IETF.
3
- The IESG can determine that the document conflicts with or is inimica*
*l to
an established IETF effort.
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 prot*
*ocols
get a chance to be published in a timely manner. The IESG is not allowed to cen*
*sor
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 oth*
*er
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 p*
*ro-
cess being followed is not that of BCP-9. I started asking the following quest*
*ions.
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.
fflWhat process is the RFC Editor following for the publication of Informati*
*onal
RFCs (since it clearly is not the process define in BCP-9)?
fflWhat do "reasonable period of time" and "timely" mean to the RFC Editor a*
*nd
the IESG?
fflWhat does the IESG think the scope and purpose of its review of the non I*
*ETF
RFCs are?
fflWhat is the RFC Editor expected to do when the IESG does not review the d*
*oc-
ument in a reasonable period of time?
fflWho do the RFC Editor and the IESG find themselves accountable to?
fflWhat should the Author of an RFC do when its repeated questions and conce*
*rns
are simply ignored?
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 time*
*s to
no avail. They remain unanswered.
4
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 Inf*
*or-
mational RFC publication process and practice.
fflRecognize what IESG really is and what its role is supposed to be. Limit *
*the
IESG's role to what it is supposed to be.
The IESG is a hand-full of volunteer engineers with a fancy group name. Ba*
*sed
on my interactions with them, I have concluded that they hardly reach the *
*"av-
erage" level of competence in my book - both in their technical and in the*
*ir
management abilities. The IESG often has little relevant experience and kn*
*owl-
edge in the specialized subject matter of the RFCs that it needs to review.
Instead of functioning in its limited co-ordination and conflict detector *
*role as de-
fined in section 4.2.3, in practice the IESG has already expanded its own *
*role and
has assumed ultimate authority over publication/non-publication of non IETF
originated Informational RFCs.
The IESG should not be permitted to engage in censorship or delay of publi*
*cation
of work coming from outside of IETF because they just don't like it, becau*
*se they
don't understand it, because they think that it may be competing with IETF*
*/IESG
work or because they think that it may be bad for the Internet.
Based on the case of RFC-2188, I have concluded that the IESG is out of co*
*ntrol
and irresponsible. It needs to be checked and managed.
fflStrengthen the RFC-Editor's Role.
In practice the role of the RFC Editor for documents coming from outside o*
*f the
IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG.
If and when the IESG does not complete its review of the refered documents*
*, it is
the RESPONSIBILITY of the RFC Editor to go ahead and publish the document.
The RFC Editor should not permit the IESG to introduce long delays in the
publication of documents.
The RFC Editor should ensure that the IESG note going into an Informational
RFC is in fact reasonable and correct and provide the author an opportunit*
*y to
see the IESG note prior to publication.
The RFC Publication Service can benefit from additional resources. I am pr*
*etty
sure that getting funding for such a critical service is not going to be d*
*ifficult if
we look at it the right way.
fflEnsure that the procedures of BCP-9 are followed in practice.
The spirit of sections 4.2.2 and 4.2.3 of BCP-9 is just right.
However, the case of RFC-2188 clearly shows that in practice the procedure*
*s of
BCP-9 are not being followed.
We need to find a way to make sure that what BCP-9 says is in fact what ha*
*ppens.
5
fflIntroduce more accountability, structure and order to the RFC publication*
* ser-
vice.
Tighten BCP-9 to be more clear about minimum technical requirements for
RFCs. Introduce an appeals process for when a document is rejected. More
clearly define "timely"...
Provide mechanisms that safeguard against mistakes and negligence by the I*
*ESG
or the RFC Editor.
Define specifically, what is supposed to happen when the IESG does not com-
plete its limited review in a timely manner.
Re-orient everything towards responsibilities of the publication service p*
*roviders
instead of their authorities.
fflSeparate The RFC Publication Service from the IETF/IESG/IAB.
The RFC Editor task is primarily a Publication Service. The IETF/IESG/IAB *
*is
JUST one of the users/customers of the the RFC Publication Service.
There has been talk of putting the RFC Publication Service under management
and funding of IETF/IESG/IAB/ISOC. That would be totally wrong.
There is an obvious inherent problem with allowing a common Publication Se*
*r-
vice to be managed and funded by one of its users. The problem is that IET*
*F/IESG/IAB
is likely to claim control over the entire RFC Publication Service and del*
*ay the
publication or exclusion of protocols coming from outside of it and suppre*
*ss
standards competition even more.
Clear separation of powers is a good thing. It is a good way of introduci*
*ng
accountability and checks and balances.
A powerful and independent RFC Editor role which would oversee a fair and
equitable RFC Publication service is ESSENTIAL for the Internet.
In practice, the RFC Editor role has been weakened over the years. We need*
* to
strengthen it.
Limiting IETF/IESG/IAB's role in the RFC Publication Process
Let's look at what needs to happen in the bigger picture. Standardization proce*
*ss iter-
ates 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 enti*
*ties.
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 ha*
*ve
access to its specification. The fundamental characteristics of the RFC Pu*
*blica-
tion Service for the most part have been working real well. Any relevant p*
*rotocol
coming from essentially anywhere which meets a minimum technical and/or ed-
itorial standard should have speedy access to the RFC Publication Service.
6
3) Use of the Protocol.If it is anything useful and is done right, it will be u*
*sed. How
it gets used is very important and unpredictable.
4) Blessing of the Protocol.Some entity (e.g., IETF/IESG/IAB) blesses the proto*
*col
by putting some label on it. Although necessary, this function is mostly c*
*eremo-
nial. 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 st*
*ep (1)
coming from outside of IETF/IESG.
Note, that I don't have a problem with the spirit of the relationship betwee*
*n 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 competit*
*ion in
step (1).
Summary Of The Communication Records in Chrono-
logical 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 conversation*
*s of
any sort.
The email exchanges are factually summarized below and reference to the actu*
*al
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 in-
corporated 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 acknowl-
edged receipt and placed it in the publication queue and forwarded it to t*
*he
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>)
7
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 so*
*on.
(<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 th*
*ey
would be in contact with us after their meeting that coming week in Memphi*
*s.
(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 E*
*SRO
protocol.
(Message-Id: <199704040100.RAA07041@jamshid.neda.com>)
At that time our only contact point was the RFC Editor. The Editor neglect*
*ed
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 l*
*ot
of time. The above instance alone justifies my fair use of the word "negli*
*gently"
with respect to the RFC Editor.
July 28, 97 - Mohsen BANAN To RFC-Editor:Having not heard from the RFC Ed-
itor since April 3rd (nearly 4 months), I prepared a detailed message whic*
*h ex-
plained that the RFC Editor and IESG's treatment of this RFC is totally un*
*rea-
sonable.
(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*
* expla-
nation) Steve Coya and the IESG had still not responded to ANY of our mess*
*ages
and requests.
Our repeated requests for an explanation kept being ignored. The IESG's ac*
*tions
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 "irresp*
*onsi-
ble".
(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, St*
*eve
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 t*
*he
IESG given the authority to stop the publication of a non IETF Information*
*al
RFC. Now, add to that the level of arrogance that says IESG can ignore the*
* Au-
thors' inquiries for 6 months and provide no explanation what-so-ever to w*
*hy
8
IESG has prevented the publication of the RFC. Then add to it, that later *
*it be-
comes clear that Steve Coya was just wrong.
(Message-ID: )
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 ear*
*lier
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 sh*
*ould
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 Ed*
*itor.
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 abusiv*
*e 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 t*
*hem
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 Infor-
mational RFC route because the urgency for publication in this case outwei*
*ghs
our interest in getting this document on the standards track.
(Message-Id: <199708081853.LAA14067@rostam.neda.com>)
9
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 recom-
mendation of ESRO for publication and that he hopes we will put this speci*
*fica-
tion 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 com-
ment 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 com-
ment.
(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 befo*
*re
publication.
August 28, 97 - Scott Bradner to Authors:Scott Bradner informs us that he publi-
cation was approved by the IESG. But does not mention anything about the I*
*ESG
note.
(Message-Id: <199708282229.SAA23730@newdev.harvard.edu>)
September 9, 97 - Mohsen BANAN To Scott Bradner:I ask about the expected pub-
lication date.
September 9, 97 - RFC Editor to IETF-Announce:The RFC Editor announces pub-
lication of RFC-2188.
The text of RFC-2188 is materially same as what we submitted to the RFC Ed*
*itor
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,
10
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:
fflThe Authors were never given a chance to know about any of the issues
that the note implies, even-though I had explicitly asked to be infor*
*med of
communications related to this RFC.
fflAfter delaying the publication for 8 months, why is the IESG Note ba*
*sed
on "a cursory examination".
fflIf that IESG Note is true, then why were the Authors not given a cha*
*nce to
know about them and fix them?
fflIf that IESG Note is true, then why did the Area Director want to pu*
*t it on
the Standards Track and issue a Last Call for it?
fflThe IESG note is so vague that up until recently I thought that it w*
*as about
the wrong perception of limitations of Service Access Points - which *
*was
the ONLY technical issue that was ever discussed with the Authors. How
can the IESG expect that such an unsubstantiated vague comment be of *
*use
to anyone? The best I can gather, this appears to have just been a "p*
*ower
trip" by an out of control IESG.
fflI am not saying that RFC-2188 is perfect and that no IESG note should
have ever been put in it. I am saying that the IESG note that was put*
* in
there was done the wrong way and is of little use, if any.
If any of my employees were to ever be responsible for a small fraction of t*
*he
types of arrogance, negligence and mistakes that were commited during the proce*
*ss 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 instituti*
*onalized
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 incl*
*uded as 30
email messages below. Other than deleting the attachments of the original speci*
*fication,
these messages have not been edited in any way.
My interactions with individulas at the IESG and the RFC Editor were in the *
*con-
text of them functioning in their roles as Service Providers. I consider none o*
*f these
email messages private or personal or confidential.
11