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

From: Mohsen BANAN <[email-masked]>
Date: Sat, 18 Mar 2006 01:21:07 -0800

[ 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 19 Mar 2006 04:56:57 +0100

>            About Publication of RFC-2188 (ESRO)
I suppose I should make a note to this, since I was apps AD at the time:

I think ESRO is a badly designed protocol that would have been harmful 
to the Internet if it had ever been deployed at scale.
The IESG pointed some of the issues out to the RFC Editor, who handled 
the communication with the author; that was the procedure at that time.
Nevertheless, the RFC Editor felt that the document was worthy of 
publication, and published anyway.

The IESG note put on this document says:

IESG Note

That's more or less consistent with the now-standard note put on all RFC 
Editor independent submissions, but at that time, it was an unusually 
strong statement.
Of course, it was far milder than the one put on the EMSD spec, RFC 
2524, published in February 1999:

IESG Note

   The protocol specified in this document may be satisfactory for
   limited use in private wireless IP networks.  However, it is
   unsuitable for general-purpose message transfer or for transfer of
   messages over the public Internet, because of limitations that
   include the following:

   - Lack of congestion control

      EMSD is layered on ESRO [RFC 2188], which does not provide
      congestion control.  This makes EMSD completely unsuitable for
      end-to-end use across the public Internet.  From [email-masked] Sat Mar 18 23:27:16 2006
Date: Sun, 19 Mar 2006 04:56:57 +0100
From: Harald Alvestrand <[email-masked]>
To: Mohsen BANAN <[email-masked]>
Cc: [email-masked]
Subject: Re: Complaints Against The IESG and The RFC-Editor About Publication
 of RFC-2188 (ESRO)

>            About Publication of RFC-2188 (ESRO)
I suppose I should make a note to this, since I was apps AD at the time:

I think ESRO is a badly designed protocol that would have been harmful 
to the Internet if it had ever been deployed at scale.
The IESG pointed some of the issues out to the RFC Editor, who handled 
the communication with the author; that was the procedure at that time.
Nevertheless, the RFC Editor felt that the document was worthy of 
publication, and published anyway.

The IESG note put on this document says:

IESG Note

That's more or less consistent with the now-standard note put on all RFC 
Editor independent submissions, but at that time, it was an unusually 
strong statement.
Of course, it was far milder than the one put on the EMSD spec, RFC 
2524, published in February 1999:

IESG Note

   The protocol specified in this document may be satisfactory for
   limited use in private wireless IP networks.  However, it is
   unsuitable for general-purpose message transfer or for transfer of
   messages over the public Internet, because of limitations that
   include the following:

   - Lack of congestion control

      EMSD is layered on ESRO [RFC 2188], which does not provide
      congestion control.  This makes EMSD completely unsuitable for
      end-to-end use across the public Internet.  EMSD should be
      considered for use in a wireless network only if all EMSD email
      exchanged between the wireless network and the public Internet
      will transit an EMSD<->SMTP gateway between the two regions.

   - Inadequate security

      The document specifies only clear-text passwords for
      authentication.  EMSD should be used across a wireless network
      only if sufficiently strong encryption is in use to protect the
      clear-text password.

   - Lack of character set internationalization

      EMSD has no provision for representation of characters outside of
      the ASCII repertoire or for language tags.

   - Poorly defined gatewaying to and from Internet Mail

      Because Internet Mail and EMSD have somewhat different and
      conflicting service models and different data models, mapping
      between them may provide good service only in limited cases, and
      this may cause operational problems.

   The IESG therefore recommends that EMSD deployment be limited to
   narrow circumstances, i.e., only to communicate with devices that
   have inherent limitations on the length and format of a message (no
   more than a few hundred bytes of ASCII text), using either:

   a. wireless links with adequate link-layer encryption and gatewayed
      to the public Internet, or

   b. a private IP network that is either very over-provisioned or has
      some means of congestion control.

   In the near future, the IESG may charter a working group to define an
   Internet standards-track protocol for efficient transmission of
   electronic mail messages, which will be highly compatible with
   existing Internet mail protocols, and which wil be suitable for
   operation over the global Internet, including both wireless and wired
   links.

In this case, too, the RFC Editor exercised the RFC Editor's independent 
judgment and published the document.

The Internet seems to have survived the publication, but I can't see any 
tangible benefit to the Internet from their publication either.

WRT formalities, Google found this reply to the posting of the note:

http://www1.ietf.org/mail-archive/web/ietf/current/msg08332.html

which seems to indicate that the IAB archives should show what happened 
afterwards; the mailing list also had a followup discussion that might 
be of interest.

This was eight years ago. The IESG that the complaint was made against was:

Alvestrand, Harald 	Applications
Bradner, Scott 	Transport
Burgan, Jeff 	Internet
Curran, John 	Operations & Management
Halpern, Joel 	Routing
Moore, Keith 	Applications
Narten, Thomas 	Internet
O'Dell, Michael 	Operations & Management
Reynolds, Joyce 	User Services
Romanow, Allyn 	Transport
Schiller, Jeff 	Security

What's the point of reposting this message now?

                                  Harald

---

From: Dave Crocker <[email-masked]>
Date: Sat, 18 Mar 2006 21:10:10 -0800

> This was eight years ago. The IESG that the complaint was made against was:

Seems like there ought to be a statute of limitations.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Mohsen BANAN <[email-masked]>
Date: Sun, 19 Mar 2006 01:46:30 -0800

>>>>> On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand <[email-masked]> said:

  >> About Publication of RFC-2188 (ESRO)

  Harald> The IESG pointed some of the issues out to the RFC Editor, who handled
  Harald> the communication with the author; that was the procedure at that time.
  Harald> Nevertheless, the RFC Editor felt that the document was worthy of
  Harald> publication, and published anyway.

As the written record clearly shows, this is
factually incorrect.

In the case of RFC-2188 the RFC Editor was no more
than an IESG puppet. Publication was held up for
more than 7 months, until finally Scott Bradner
(Transport Area Director at the IESG) made it
happen -- emphatically *not* the RFC Editor. Scott
can step in, if he wishes.

Full communication records are available at:
  http://www.esro.org/communicationRecord/rfc2188Publication/maillist.html

And then there is the communication record of what
happened when the IESG invited us to put ESRO on the
standards track.
  http://www.esro.org/noStdTrack/main.html

  Harald> The IESG note put on this document says:

In general, I consider the garbage that IESG puts
in non-IETF RFCs as a badge of honor for the
author.

For example, the negative IESG note in the
original HTTP specs and the success of HTTP
demonstrated IESG's attitude and its eventual
relevance.

  Harald> In this case [RFC-2524], too, the RFC
  Harald> Editor exercised the RFC Editor's
  Harald> independent judgment and published the
  Harald> document.

Had it not been for my very public RFC-2188
complaint, I do not believe RFC-2524 would have
been published at all.

Please note the time of my complaint and of the
RFC-2524 publication.

How many other non-IETF RFCs have ever been
published by the RFC Editor in the face of IESG
opposition?

I believe the answer is very few if not zero. If I
am wrong, I ask the RFC Editor/IESG to correct the
record. Please name the RFCs.

  Harald> This was eight years ago. ...

Lack of true independence of the RFC Editor was
the issue then, and it is the issue now.

...Mohsen

---

From: Mohsen BANAN <[email-masked]>
Date: Sun, 19 Mar 2006 01:50:08 -0800

>>>>> On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker <[email-masked]> said:

  Harald> What's the point of reposting this message now?

  Dave> Seems like there ought to be a statute of limitations.

In response to both of you: the point of referring
to eight-year old history is not to disinter the
corpse of the past.

The point is that this history is directly
relevent to a current discussion thread.

I believe I made the point of reposting clear in
the following header:

  Mohsen> [ This is a repost from 6 Nov 1998.
  Mohsen>   In particular the section on:
  Mohsen>      o Separate The RFC Publication Service from the IETF/IESG/IAB.
  Mohsen>   is relevant to the current:
  Mohsen>        STRAW PROPOSAL RFC Editor charter
  Mohsen>   thread. ]

---

From: Dave Cridland <[email-masked]>
Date: Sun, 19 Mar 2006 11:23:45 +0000

> demonstrated IESG's attitude and its eventual

For the crowd watching who were curious, but not curious enough to 
bother looking, RFC1945 (HTTP/1.0), which of course is NOT the 
original HTTP spec at all, carries the note:

   The IESG has concerns about this protocol, and expects this 
document
   to be replaced relatively soon by a standards track document.

RFC2068, HTTP/1.1, was published a little over half a year later, 
which would appear to be "relatively soon".

Something appears to be wrong with your DNS, so reading your webpages 
is somewhat impractical.

FWIW, I reviewed EMSD a little while ago, to see whether there was 
anything worth raising for Lemonade, and decided that the IESG note 
on that still stands, except more so, as various problems they noted 
have become more important as time has passed. [For the crowd, EMSD 
is a wireless replacement for the Submission protocol, but does not 
support anything but ASCII, has no authentication, and insists on 
using its own message format in ASN.1]

But back to your argument, which appears to be that if the RFC editor 
function were utterly independent from the IAB/IETF/IESG, your 
protocols would have been published without those notes, and without 
the review those notes required. Which part is the problem, the 
review, or the note attached to the document?

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Mar 2006 08:08:10 -0500

> can step in, if he wishes.

I will go on record to say that I was the IESG member who did the most 
to discourage publication of your document as an RFC.  Contrary to your 
perception of things, the RFC Editor published it over my strong 
objections, and also insisted on diluting the IESG note that was 
originally written for that document.  I don't recall the reasons for 
the delay other than the high workload of IESG (we were reviewing dozens 
of documents per week, the fact that IESG discussed things in conference 
calls every two weeks, and there were several iterations of 
back-and-forth with the RFC Editor regarding your document.  It is my 
recollection that your document was handled much more quickly than 
working group documents -- because unlike WG documents which proceeded 
normally though the IESG's queue (and for which the speed of processing 
was sensitive to IESG's workload), the RFC Editor had a policy of giving 
IESG a limited amount of time to comment on independent submissions that 
had the perverse side-effect of giving priority to those submissions.

It was and still is my opinion that RFC 2188 was not suitable for 
publication as an RFC, as it is poorly designed and has numerous 
technical flaws.  To have published this document IMHO dilutes the 
quality of the RFC series and may confer an undeserved appearance of 
acceptance on ESRO.  Perhaps more importantly, the discussion about this 
document wasted a colossal amount of time that could have been put to 
much better use reviewing working group output (on the part of the IESG) 
and editing better quality documents (on the part of the RFC Editor).

As Harald points out, this was eight years ago, and the process has 
changed significantly since that time.  Also, I'm no longer on the IESG 
and don't expect to ever be on the IESG again.  Life is too short. 
Since all of the circumstances and nearly all of the people have changed 
since this incident, I don't see how it's relevant now.

Keith

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 19 Mar 2006 09:42:50 -0800 (PST)

I too agree with Mohsen's comments, overall. What Mohsen points out as true
eight years ago continues to be true even now. Not a lot changed, IMHO. I
believe, it had gotten worse. IESG continues to wield enormous influence over
the independent submissions sent to the RFC editor. The RFC editor needs to be
independent.

regards,
suresh

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 19 Mar 2006 13:00:30 -0500

> the independent submissions sent to the RFC editor. The RFC editor needs to be

Why?  There are plenty of other publication venues.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 19 Mar 2006 10:17:13 -0800 (PST)

Right, that is the foced outcome of the current practice. Without an
independent channel, people find other avenues outside the IETF to get their
work done. 

regards,
suresh

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 19 Mar 2006 13:40:32 -0500

> independent channel, people find other avenues outside the IETF to get their
More precisely, to publish their work.  My question is why this is bad
for anyone except those who want the "RFC" label on their work.  Put
another way, the real question is what "RFC" means.  Given the
confusion that already exists in the market ("We implement RFC 1149!"),
I'd rather there were more IETF controls on what bears that label.  I'm
not saying it should be completely an IETF publishing venue (though
frankly, I wouldn't mind it at all if the IETF could trademark "RFC"),
but I do think that avoiding gratuitous confusion is a good idea.

---

From: Mohsen BANAN <[email-masked]>
Date: Sun, 19 Mar 2006 11:20:05 -0800

>>>>> On Sun, 19 Mar 2006 11:23:45 +0000, Dave Cridland <[email-masked]> said:

  >> demonstrated IESG's attitude and its eventual

  Dave> For the crowd watching who were curious, but not curious enough to
  Dave> bother looking, RFC1945 (HTTP/1.0), which of course is NOT the
  Dave> original HTTP spec at all, carries the note:

  Dave>    The IESG has concerns about this protocol, and expects this document
  Dave>    to be replaced relatively soon by a standards track document.

  Dave> RFC2068, HTTP/1.1, was published a little over half a year later,
  Dave> which would appear to be "relatively soon".

The primary author of Informational RFC1945 with
the negative IESG note is Tim Berners-Lee.

He then pulled out of the IETF/IESG and formed
W3C. 

Why do you think that happened?

And where is IETF/IESG with W3C now?

In my opinion what started with the Informational
RFC1945 is the most significant advancement since
formation of IETF/IESG/IAB/... 

Almost always innovation comes from outside of
committees.

  Dave> But back to your argument, which appears to be that if the RFC editor
  Dave> function were utterly independent from the IAB/IETF/IESG, your
  Dave> protocols would have been published without those notes, and without
  Dave> the review those notes required. Which part is the problem, the
  Dave> review, or the note attached to the document?

None of those.

My concern is not my own RFCs. I got them
published despite of the IETF/IESG opposition. The
IESG note is a badge of honor similar to Tim
Berners-Lee's.

The perspective that the world needs the IESG note
to be able to judge the merits of a protocol is at
best comical. The scope and purpose of the IESG
note should be limited to relevance and overlap
with current or planned IETF work.  An independent
RFC Editor should enforce this and put the IESG in
its place. That is what the then BCP -- RFC-2026
-- said. Of course, things work differently in a
cult.

I suspect that lots of direct independent RFC
submissions are being censored by the IESG. The
community is being fragmented. And the trend
appears to be for the situation to only be getting
worse.

Again, all of this is in the context of:

where the key topics are:

 - Independence of RFC Publication Service
 - Relationship of IETF/IESG/IAB with the RFC Publication Service
 - Use of the RFC Publication Service by the Internet Community

Tony gets it:

>>>>> On Sun, 19 Mar 2006 09:28:17 -0800, "Tony Hain" <[email-masked]> said:

  Tony> The point is that the past IESG practice which has driven out those who
  Tony> would submit individual submissions, resulting in the current ratios, MUST
  Tony> NOT become the guide for what SHOULD happen going forward. The RFC editor
  Tony> role needs to be extricated from the overbearing IESG and returned to its
  Tony> independent role. Doing otherwise further fragments the community which will
  Tony> only lead to its downfall.

>From my perspective, based on past performance,
the IETF/IESG/IAB can not be trusted to control
the RFC Publication Service.

...Mohsen

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 19 Mar 2006 13:29:31 -0600

> Why do you think that happened?
Because he had specific ideas he wanted to pursue, and wanted staff to 
work on them.
That required a different model than the IETF.

"Pulled out" is an exaggeration, however. W3C has sent people to IETF 
meetings ever since it was founded.
> And where is IETF/IESG with W3C now?
Cooperating quite well and respecting each others' areas of competence, 
I think.

---

From: Mohsen BANAN <[email-masked]>
Date: Sun, 19 Mar 2006 12:59:46 -0800

Keith,

You have totally confused ESRO with EMSD.

RFC-2188 is different from RFC-2524.

1) RFC-2188 (ESRO)
  As far as I know the RFC-2188 complaint had
  nothing to do with you. Everything is fully
  documented. We are talking about historic facts,
  not opinions. IESG did not object to publication
  of ESRO (RFC-2188). I declined IESG's invitation
  to put ESRO on standards track. That was my
  choice. The problem was that it took 7 months.

2) RFC-2524 (EMSD)
  You lost. I managed to convince the RFC Editor
  of the merits of publication. 
  I used the RFC-2188 complaint to strengthen the
  RFC Editor's independence. There has never been 
  any formal complaints related to RFC-2524.

  The only part of the IESG note that can be
  considered to have any aspect of legitimacy is:

-- In the near future, the IESG may charter a working group to define an
-- links.

And that was in 1999. I am curious to know what
happened.

In the mean time of course there has been the
proprietary and patent full BlackBerry.

Our real enemy are proprietary patented
protocols.

It would be hard to argue that existence of the
WhiteBerry concept has done any harm.
  http://www.freeprotocols.org/operationWhiteberry/index.html

Back to the topic at hand:

  Keith> ... I don't see how it's relevant now.

... Mohsen

>>>>> On Sun, 19 Mar 2006 08:08:10 -0500, Keith Moore <[email-masked]> said:

  >> can step in, if he wishes.

  Keith> I will go on record to say that I was the IESG member who did the most
  Keith> to discourage publication of your document as an RFC.  Contrary to
  Keith> your perception of things, the RFC Editor published it over my strong
  Keith> objections, and also insisted on diluting the IESG note that was
  Keith> originally written for that document.  I don't recall the reasons for
  Keith> the delay other than the high workload of IESG (we were reviewing
  Keith> dozens of documents per week, the fact that IESG discussed things in
  Keith> conference calls every two weeks, and there were several iterations of
  Keith> back-and-forth with the RFC Editor regarding your document.  It is my
  Keith> recollection that your document was handled much more quickly than
  Keith> working group documents -- because unlike WG documents which proceeded
  Keith> normally though the IESG's queue (and for which the speed of
  Keith> processing was sensitive to IESG's workload), the RFC Editor had a
  Keith> policy of giving IESG a limited amount of time to comment on
  Keith> independent submissions that had the perverse side-effect of giving
  Keith> priority to those submissions.

  Keith> It was and still is my opinion that RFC 2188 was not suitable for
  Keith> publication as an RFC, as it is poorly designed and has numerous
  Keith> technical flaws.  To have published this document IMHO dilutes the
  Keith> quality of the RFC series and may confer an undeserved appearance of
  Keith> acceptance on ESRO.  Perhaps more importantly, the discussion about
  Keith> this document wasted a colossal amount of time that could have been
  Keith> put to much better use reviewing working group output (on the part of
  Keith> the IESG) and editing better quality documents (on the part of the RFC
  Keith> Editor).

  Keith> As Harald points out, this was eight years ago, and the process has
  Keith> changed significantly since that time.  Also, I'm no longer on the
  Keith> IESG and don't expect to ever be on the IESG again.  Life is too
  Keith> short. Since all of the circumstances and nearly all of the people
  Keith> have changed since this incident, I don't see how it's relevant now.

  Keith> Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Mar 2006 23:09:31 +0100

> Seems like there ought to be a statute of limitations.

In the IETF process, that's two months. I presume that anybody who
found the RFC 3932 (BCP 92) procedures unsatisfactory would have
complained in 2004 when it was approved.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Mar 2006 18:02:13 -0500

> RFC-2188 is different from RFC-2524.

I stand corrected.

>   Tony> only lead to its downfall.

I strongly disagree with Tony that the IESG has been overbearing.
>From my perspective IESG has been too permissive.  But perhaps this is
beside the point.   I believe that we need to have high standards for
RFC publication - not just for working group documents or standards
track documents but for all documents that are labeled RFCs.  In order
for that to happen, _someone_ has to do a thorough technical review of
those documents, and that _someone_ has to be willing and empowered to
reject documents that don't cut it.  There are advantages to having
IESG do that review (e.g. uniformity, lower cost) and advantages to
having another party do that review (e.g. spreading the workload).  I
don't have a strong opinion about who does the review of
non-standards-track, non-working-group documents, as long as the review
is done and the document series is held to high standards.  

I will however caution against the assumption that IESG is inherently
overbearing and a separate review function is inherently more
reasonable.  No matter who does the review there will always be the
potential for capriciousness on the part of the reviewer.  Similarly,
no matter who does the review there will always be those who will
insist that IETF lend its imprimatur to their flaky designs or poorly
written documents, and who will consume valuable resources trying to
degrade the RFC series.  IMHO, it is vitally important that we avoid
wasting either volunteer energy or money on such foolishness.

Keith

---

From: Dave Cridland <[email-masked]>
Date: Sun, 19 Mar 2006 23:23:12 +0000

>   considered to have any aspect of legitimacy is:

I say again, I examined RFC2524 is some detail, both because it was 
prior art in an area that was under heavy discussion at the time in 
Lemonade, and because you'd suggested it be a reference in the 
Lemonade Profile Bis draft, and concluded that the IESG note was 
correct in all its points, save that I cannot claim to have enough 
experience to look at ESRO in detail.

Do you object to:

a) The "censorship" of RFCs based on technical merit? (In other 
words, would you prefer to be able to publish any technical document, 
no matter how bad?)

b) That the IESG is providing the technical review needed by the RFC 
Editor to ensure the RFC series maintains quality?

c) That the RFC Editor chooses to publish the IESG's review, on 
occasion, in the actual document?

As to your free protocol foundation and whiteberry projects, I'd 
never heard of either until you brought them up. That's certainly 
causing no harm. If they were popular projects pulling useful input 
away from the IETF and Lemonade respectively, I'd classify that as 
harm.

Dave.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 19 Mar 2006 15:26:50 -0800 (PST)

> potential for capriciousness on the part of the reviewer.

It seems to me that while many prefer IESG review some believe it may not 
always be fair and balanced. So if I can make a suggestion, it would be
good while defaulting to IESG review to also specify that submitter may
challenge their review results and/or request an independent review from
another source. So it would be good if we had some other organization or
specified procedure on how RFC-Editor can request review from somebody
other then IESG or some other then IETF-related body.

Also it seems that not specifying how long review should take allows to
delay document indefinitely, which is a form of rejection without officially
saying so - so maximum time that review can take should be specified (say
6 months) and if results are not made available to author and RFC-Editor
by end of this time, RFC-Editor default choice should be to publish as-is
without any IESG note.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 19 Mar 2006 15:29:02 -0800 (PST)

On Sun, 19 Mar 2006, Dave Cridland wrote:

> If they were popular projects pulling useful input away from the IETF 
> and Lemonade respectively, I'd classify that as harm.

Why? Harm to who and in what way?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Mar 2006 18:42:13 -0500

> always be fair and balanced. 

Again, this will be true no matter who does the review.

> So if I can make a suggestion, it would be
> another source. 

That sounds like an appeals process to me.  It's not at all clear to me
that we can afford the resources to give the privilege of appeal to
mere individuals.

> delay document indefinitely

That's a bit like saying that an SMTP server should not be able to
delay mail indefinitely no matter how much SPAM it gets. 
 
There are a near-infinite number of simians with keyboards, while IETF
review resources are (and always will be) finite and precious.  So no
matter who does the review for individual submissions, I think that
it's perfectly reasonable for that reviewer to be able to say "Sorry,
we receive too many invididual submissions to review them all, and yours
doesn't pass the smell test.  You may wish to seek publication through
other channels".  This is no different than any other publisher.  IETF
is not a vanity press.

Keith

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 19 Mar 2006 16:17:24 -0800 (PST)

> Again, this will be true no matter who does the review.

True. But if you want to make RFC-Editor a separate function from 
IETF/IESG you must allow it choices on who would do a review

> That sounds like an appeals process to me.

Both appeals process and process where submitter if he thinks IETF is not
fair in its reviews can request independent review in the first place
(though IESG would still need to provide its review as to if there are
any conflicts and may choose to provide additional technical review as
additional input as well). The point being that technical reviews do not
have to come exclusively from IESG and that rfc-editor should have access 
to multiple inputs deciding if publication is appropriate.

> It's not at all clear to me

Excuse me? What do you think IETF is or do you really prefer to see
it officially turn into IVTF?

> delay mail indefinitely no matter how much SPAM it gets.

It should not. If server is loaded with processing existing email, it
should not delay processing longer and longer internally but directly
start answering with 400 error. To turn this analogy (which I don't
think is very good in the first place) to publication process - RFC
editor can say that its overloaded and will not accept submissions
in the first place, but if it accepted submission - there should be
finite time in which it should be delayed within IESG review stage.

> doesn't pass the smell test.

No smell tests please just because you're overworked and don't have time
for substantial review. Either all submissions are rejected due to load
or none.

RFC-Editor can report to ISOC and IETF if it begins to experience too
high a load with individual reviews and request additional funding or
input to improve its process to deal with this. However if I understand 
current situation, the individual publications requests directly to RFC 
Editor have not been anything close to serious issue and its IETF's own 
documents that require IESG review that put greatest stress on IESG 
workload and delays in RFC publication.

> You may wish to seek publication through other channels".  This is no 
> different than any other publisher.  IETF is not a vanity press.

The question here is about RFC Editor and its process. Original function
of RFCs after all was to document internet protocols and how to use them
to allow others to know what each protocol is about from common easily 
searchable source. IETF on the other hand is organization responsible with
engineering standards for certain internet functions - that means it goes
quite a bit further then just publication or approval of documents but 
actually is engaged in group effort to engineer the service/protocol where 
the need for such functionality exists.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Sun, 19 Mar 2006 20:44:40 -0500

>> It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals.
> 
> Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF?

IETF is, or should be, an engineering organization.  Not a vanity press. 
IETF exists to benefit the entire Internet community, rather than 
authors wanting recognition or vendors wanting endorsement for their 
products.  It's more important for IETF to produce good engineering than 
it is for anyone to be able to exhaust IETF's resources trying to get 
his or her way.

> finite time in which it should be delayed within IESG review stage.

SMTP servers can bounce with 400 errors also.

> for substantial review.   Either all submissions are rejected due to load

Strongly disagree.  When we reject a document we generally expect the 
reviewer to supply good reasons for rejecting and to explain what would 
make the document more deserving of publication.  It's relatively easy 
to competently sift potential wheat from chaff.  It's much harder to do 
full reviews where you explain what's wrong and how to fix it, and get 
into iterative negotiation with the author.

> input to improve its process to deal with this.

I believe flow control is needed at every point in the system.

> However if I understand current situation, the individual publications requests directly to RFC 
> Editor have not been anything close to serious issue 

if working with the Internet for 20 years has taught me anything, it's 
that any hole that exists will someday be exploited, and soon after 
that, will be exploited massively.

> searchable source.

most things evolve over time, including RFCs and IETF.  either that or 
they become extinct.

Keith

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 20 Mar 2006 04:10:38 +0100

At 02:44 20/03/2006, Keith Moore wrote:

>>>It's not at all clear to me that we can afford the resources to 
>>>give the privilege of appeal to mere individuals.
>IETF is, or should be, an engineering organization.  Not a vanity 
>press. IETF exists to benefit the entire Internet community, rather 
>than authors wanting recognition or vendors wanting endorsement for 
>their products.

Sorry. This was before RFC 3935. The IETF exists to "infuence people 
on the way to design use and manage" the Internet. And this is worth gold.

>   It's more important for IETF to produce good engineering than it 
> is for anyone to be able to exhaust IETF's resources trying to get 
> his or her way.

Agreed. The problem is the IANA. A key registry is worth gold too. 
Good engineering or not, some interests want to go through.
jfc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Mar 2006 11:53:48 +0100

On Sun, Mar 19, 2006 at 04:17:24PM -0800,
 william(at)elan.net <[email-masked]> wrote 
 a message of 92 lines which said:

> Either all submissions are rejected due to load or none.

I disagree. Even with good and honest engineers, there are enough
people in the world to overload the IESG. But when you take into
account trolls and protocol-kiddies, you *need* a laugh test to
eliminate quickly the works of these people. (It is exactly the method
we all use to skip quickly over Banan or Morfin's messages on a
mailing list.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Mar 2006 11:57:43 +0100

On Sun, Mar 19, 2006 at 01:46:30AM -0800,
 Mohsen BANAN <[email-masked]> wrote 
 a message of 73 lines which said:

> In general, I consider the garbage that IESG puts in non-IETF RFCs
> as a badge of honor for the author.
> 
> For example, the negative IESG note in the original HTTP specs and
> the success of HTTP demonstrated IESG's attitude and its eventual
> relevance.

It is true that the IESG Notes in RFC 1945 and RFC 1630 are quite
embarassing for the IETF today but you are not Tim Berners-Lee. For
one genius who had trouble being recognized at the beginning, there
are thousands of monkeys-with-keyboards who are rightly ignored.

Your reasoning is the same fallacy as saying "Galileo was persecuted
and he was right, I am persecuted so I am right".

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Mar 2006 07:08:13 -0600

> are thousands of monkeys-with-keyboards who are rightly ignored.
actually there's reason to look at the IESG notes on those specs....

RFC 1630, "Universal Resource Identifiers":

IESG Note:

   Note that the work contained in this memo does not describe an
   Internet standard.  An Internet standard for general Resource
   Identifiers is under development within the IETF.

A spec was developed. And that's what everyone's referring to as "the 
spec" when talking about URIs now.

RFC 1945, HTTP 1/0:

IESG Note:

   The IESG has concerns about this protocol, and expects this document
   to be replaced relatively soon by a standards track document.

The biggest concerns (that I remember) were:
- Over-consumption of IP addresses (fixed by the Host: header)
- Over-reliance on short TCP connections (fixed by HTTP 1.1 keepalive)
- Use of "TCP end of session" to delimit documents (fixed by use of 
length field + HTTP 1.1 chunked encoding)

At one point around that time, I believe that the second point was the 
cause of the statement "1/4 of the packets on the net are not under 
congestion control". Without the fix for the first, the modern hosting 
industry wouldn't have been possible.

I think the IESG can have some pride in those remarks, actually.....

                      Harald