[ This is a repost from 6 Nov 1998.
In particular the section on:
o Separate The RFC Publication Service from the IETF/IESG/IAB.
is relevant to the current:
STRAW PROPOSAL RFC Editor charter
thread. ]
Complaints Against The IESG
and The RFC-Editor
About Publication of RFC-2188 (ESRO)
Mohsen Banan
mohsen at 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:
o The publication of the RFC was delayed for *8 months*
for no good reason.
o During 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 RFC was published exactly as it was submitted
(plus the IESG note).
o The IESG was irresponsible and negligent in
fulfilling its role.
o The RFC-Editor was negligent in fulfilling its
role.
o In practice, the publicized processes and
procedures for the Informational RFC publication
were not being followed neither by the IESG and nor
by the RFC-Editor.
o In practice, RFC-Editor was reduced to a puppet of
IESG acting as a glorified secretary and an
inefficient messenger.
o The IESG over stepped the scope of its authority
and displayed an arrogant an dictatorial attitude
which caused serious delays in the publication of
the RFC.
I (Mohsen Banan -- mohsen at 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:
o the IESG frequently abuses its authority and in
fact is allowed to delay the publication of RFCs
indefinitely and even engage in censorship of
material that it just does not like or that it does
not understand.
o both the IESG and the RFC-Editor operate with an
"authority" oriented attitude as opposed to a
"responsibility" oriented attitude.
o in 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 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:
o Informational designation does not represent an
Internet recommendation of any sort.
o Publication of Informational RFCs is supposed to be
"timely".
o The RFC-Editor (and NOT the IESG) is responsible
for determining suitability for publication based
on:
-- Relevance to Internet activity
-- Meets the technical standard for RFCs
-- Meets the editorial standard for RFCs
o The 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 areas of overlap with on going or future
IETF activities.
-- The IESG can recommend that the document be
brought in the IETF.
-- The IESG can determine that the document
conflicts with or is inimical 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 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.
o What process is the RFC Editor following for the
publication of Informational RFCs (since it clearly
is not the process define in BCP-9)?
o What do "reasonable period of time" and "timely"
mean to the RFC Editor and the IESG?
o What does the IESG think the scope and purpose of
its review of the non IETF RFCs are?
o What is the RFC Editor expected to do when the IESG
does not review the document in a reasonable period
of time?
o Who do the RFC Editor and the IESG find themselves
accountable to?
o What should the Author of an RFC do when its
repeated questions and concerns 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 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.
o Recognize 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. Based on my interactions with
them, I have concluded that they hardly reach the
"average" level of competence in my book -- both
in their technical and in their management
abilities. The IESG often has little relevant
experience and knowledge 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 defined 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 publication of work coming
from outside of IETF because they just don't like
it, because 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 control and irresponsible.
It needs to be checked and managed.
o Strengthen the RFC-Editor's Role.
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.
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
opportunity to see the IESG note prior to
publication.
The RFC Publication Service can benefit from
additional resources. I am pretty sure that
getting funding for such a critical service is not
going to be difficult if we look at it the right
way.
o Ensure 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 procedures 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 happens.
o Introduce more accountability, structure and order
to the RFC publication service.
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 IESG or the RFC Editor.
Define specifically, what is supposed to happen
when the IESG does not complete its limited review
in a timely manner.
Re-orient everything towards responsibilities of
the publication service providers instead of their
authorities.
o Separate 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 Service to be managed and
funded by one of its users. The problem is that
IETF/IESG/IAB is likely to claim control over the
entire RFC Publication Service and delay the
publication or exclusion of protocols coming from
outside of it and suppress standards competition
even more.
Clear separation of powers is a good thing. It is
a good way of introducing 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 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 at 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 at 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 at 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 at 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.
(Message-Id: <199704010128.RAA26066 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at rostam.neda.com>)
August 8, 97 -- Scott Bradner to Authors: Scott Bradner
asks: What is causing this feeling of urgency?
(Message-Id: <199708082046.QAA01197 at newdev.harvard.edu>)
August 8, 97 -- Mohsen BANAN To Scott Bradner: I
explain.
(Message-Id: <199708082219.PAA14258 at 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 at newdev.harvard.edu>)
August 17, 97 -- Mohsen BANAN To Scott Bradner: I
thanked him and said that I will.
(Message-Id: <199708180434.VAA26606 at 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 at newdev.harvard.edu>)
August 18, 97 -- Mohsen BANAN To Scott Bradner: I
respond to that technical comment.
(Message-Id: <199708181850.LAA27366 at 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 at 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 at 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:
o The 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
informed of communications related to this RFC.
o After delaying the publication for 8 months, why
is the IESG Note based on "a cursory
examination".
o If that IESG Note is true, then why were the
Authors not given a chance to know about them
and fix them?
o If that IESG Note is true, then why did the Area
Director want to put it on the Standards Track
and issue a Last Call for it?
o The IESG note is so vague that up until recently
I thought that it was 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 "power
trip" by an out of control IESG.
o I 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 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.
Complete 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 and
deleting duplicate message digests, 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, personal or confidential.
------- start of digest (30 messages) (RFC 934 encapsulation) -------
See http://www.esro.org/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf