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

From: Vernon Schryver <[email-masked]>
Date: Sat, 7 Nov 1998 09:37:59 -0700 (MST)

> From: Jeffrey Altman <[email-masked]>

> ...
> > Or at least change the name, to something like "WBSN," Whacko Blue Sky
> > Nonsense?  Such a name would not affect the good contents of a document
> > or the attention they get from rational people, but it would stop the
> > transparent efforts to borrow the imprimatur of a standards organization.
>
> Huh?
>
> The reason for Informational RFCs is not always to borrow the name of
> the IETF.  My reason for Informational RFCs is for proprietary
> protocol extensions to be published so they can be used by others.
> Using the Informational RFC mechanism provides a nice single
> repository for people to look at when try to find related documents.

translating Mr. Altman's words into Unvarnished English:

  I want to borrow the reputation of the IETF to bamboozle people into
  buying or even implementing my proprietary notions.  The IETF also
  provides an effective and free editing and distribution mechanism.
  Using it to publish my ideas saves me significant time and money.

That is completely fine and respectable.  Anyone who does that is is doing
a Good Thing(tm) (by the current rules), provided one is honest about it.

> Very often there are things that the IETF would just not be interested
> in trying to standardize.  There is only so much person power.

Given its scarcity, why should the IETF spend its "person power" on
anything that the IETF is "just not interested in"?  Why should standards
track documents wait behind irrelevant (to the IETF) documents for the
attention of the IESG or the RFC Editor?  Why should the IETF pay to edit
or publish every random document from every random person who wants the
cachet of being an RFC author?  

Only if the Informational RFCs were named something offensive, such as
SNJ (Stupid Nonsense and Junk), would more or less innocent people be less
likely to delude themselves with high sounding delusions about their goals
and means.  Simply prefixing "RFC" with "i" or any other letter would
completely fail the design goal.  It is only the general shape of names
that matter, as that of "Jon" and "John."  Essentially all of the world,
including the few who actually read any particular RFC, cannot perceive a
difference between "Informational" and "Standards Track."  No matter how
much noise the IETF makes about such differences, people simply won't see
them.  They do not, will not, and cannot care.  They are also incapable
of perceiving any difference among "RFC", "IETF", "IEEE" "ITU", and "ANSI".
All of those are translated by essentially everyone, including those who
teach the world in the trade rags and academia, into "technical document
with nearly the force of law; don't read it, just believe it says what I
say it does."  We all know this, since we have all used "read RFC 9876"
or "see ANSI x.12345" to squelch an idiot.  The only way you can get people
to see a difference is to hit them in the face with it.

Someone suggested heckling public speakers who abuse "RFC".  Never mind
that the situations that matter are private talks with salespeople and
the inter-ad filler in the trade rags.  How could you correct a speaker
who says "The wonderful protocol standardized in (mumble)RFC 8765 is the
perfect solution"?

Of course, the modern IETF takes itself too seriously to use the
prejorative label solution to the problem.  The only possible solution is
to require that all RFCs including Informational be supported by consensus
in a chartered working group.  That will end certain RFCs published on
April 1, but the new IETF is too self-important for those.  Requiring
working group support for every document will come eventually, as the IETF
finishes becoming a peer of the IEEE and the ANSI.  There are compelling
reasons for most of the characteristics of the old standards bodies.

Vernon Schryver    [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Nov 1998 07:32:07 +0000

Let me throw out a few comments that may be helpful to the community in
understanding a process that may appear to be behind closed doors. We were
already planning on a presentation at the IETF meeting (during the IAB
Plenary) from the RFC Editor's office on what's happening there; we will
ask the editrix to include this topic.

>cachet of being an RFC author?  

I think the issue here is that there are lots of folks who would like the
cachet of having published an RFC, and having an RFC that documents their
work or ideas. That is not bad; consider that some random documents, like
RFC 970, have identified and explored significant problems, and others,
like RFC 950, have proposed ideas that eventually got incorporated into the
base architecture. Ideas are good things, even if they are not standards,
and even if they turn out to not be the best ideas.

What has become problematic is people using that process to circumvent the
working group process, to publish things that aren't so hot with a title
that means to the average reader "an improvement over something else", or
using the RFC process as a way to get free advertising or something their
marketing can claim is an RFC "and therefore good or a standard". (This
comment is not pointed at anyone in particular - we see a lot of documents
that fit into those categories, and the RFC Editrix sees more). There is a
balance to be drawn between limiting publication - something we don't want
to do - and limiting things that don't make sense or are highly biased. As
a result, the RFC Editor's office (which the IETF now funds through ISOC
money; that wasn't true two months ago) sends documents mailed to it to the
IESG for review prior to publication.

Generally, the result is a comment to the RFC Editor along the lines of

  - "we think this document has insufficient merit to publish - 'what I
     did on my summer vacation' is not something to record for posterity."
  - "we think it's OK; we'd suggest you change the title from 'the way to
     do foo' to 'Frobnitz Corporation's way to do foo' if you publish it"
  - "this overlaps the work of the Screwball WG; we will ask some screwball
     to contact the author, and recommend that you consider this an
     individual submission to that working group"
  - "we have no problem with you publishing this."

We explicitly wrestle with the problem of "this is a bad idea", and
although we often feel like saying "bad idea, don't publish it", we try to
avoid that trap. We'd rather see several bad ideas published, and
eventually some body of evidence grow describing a problem that a good idea
could solve effectively, than simply toss ideas that were Not Invented
Here. Our usual solution to that is the addition of an IESG note. In this
case, we say to the RFC Editor

  - "if you choose to publish this, we would like you to add a paragraph
     to the front that says 'the IESG thinks the document has the following
     problems; this idea needs work.'"

During our review, we frequently make comments back to the author along the
lines of "how about if you identify your company in the title", "have you
thought about management or security?", "there seem to be some bugs of this
form." Comments also come from quarters other than ours. All such non-IESG
review is, of course, a good thing, both because it off loads us and
because it gets the author the sort of review one would expect in a public
forum. Understand here that we do not *tell* the RFC Editrix what to do
(that office reports to the IAB, not the IESG), but we advise her team on
our viewpoint. Considering that the author probably wants to have a good
quality product, we don't advise the RFC Editor that we're OK with it if
there appear to be gaping holes.

I think it's important for all to understand that the ADs give first
priority to looking at the documents that the working groups have sent us,
and look over other submissions in their copious spare time. We do try to
be timely, but individual submissions are not our highest priority, and are
generally reviewed by a small subset of the Area Directors rather than
getting full IESG review. So this type of stuff is not holding up other
more pressing work.

As a practical suggestion: if you are worried about the IESG reviews, one
thing that you can do is offer your reviewing services to the various Area
Directors. You can either drop a note to the relevant ADs for subjects
you'd be willing to be involved in, or drop a note to [email-masked] stating
what sorts of documents you would be willing to help out with.

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Nov 1998 07:32:07 +0000

---

From: "Mitch Denny" <[email-masked]>
Date: Thu, 12 Nov 1998 11:03:09 +1000

Here Here!,

Quality must be maintained while still providing a valuable peer-review
process.  The process of actually getting a document published as an RFC
should perhaps not come into review, but rather the collaboration methods we
use.

Can we brainstorm of alternative ways of organising our collaborative
efforts?

I am hoping (time permitting) to start work on a directory service system
that I don't necessarily want published as an RFC (mainly because I don't
think it would have a chance of being adopted) but would like input from
peers.

Also, sometimes it would be nice to have working models of what people are
actually proposing (if possible).

For example:

If I develop a directory service protocol, I could create a client interface
to interact with a prototype directory server.  It could have public access
and people could create their own zones, networks, hosts etc.

Do we really want to become like the medical profession where everyone trys
to do each other over just to get that grant!

Cheers.

Mitch Denny
[email-masked]

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Thursday, November 12, 1998 17:32
> To: [email-masked]
> Subject: A perspective on the FYI RFC Publication Process
>
>

---

From: "Mitch Denny" <[email-masked]>
Date: Thu, 12 Nov 1998 11:03:09 +1000

Here Here!,

For example:

Cheers.

Mitch Denny
[email-masked]

---

From: Mohsen BANAN <[email-masked]>
Date: Mon, 30 Nov 1998 01:05:31 -0800 (PST)

This is a collection of responses to a number of messages that 
have appeared in the  <[email-masked]> mailing list under the following
threads:

      -	A perspective on the FYI RFC Publication Process
      -	IANA split and RFC Editor
      -	Two modest proposals
      - Complaints Against The IESG and The RFC-Editor About
           Publication of RFC-2188 (ESRO)

Instead of responding to individual messages, I have
structured this message by topic. This message is
focussed around the following key topics:

   - Is RFC 2026 (BCP-9) authoritative? (for Non-IETF,
     Non-Standards Track RFCs)

   - IETF/IESG should have complete control over all of RFC publication

   - Strength, Independence and Credibility of RFC
     Editor.

The scope of my comments and questions in this note is
limited to Non-IETF, Non-Standards Track Inormational
and Experimental RFCs which do NOT represent an Internet
community consensus or recommendation and are in no way 
associated with IETF or IESG.

In that context, I have pretty serious problems with
many of the perspectives presented so far.  Note that I
have no problem what so ever with any of the
perspectives related to RFC publication of IETF
initiated or standards track documents.

Is RFC 2026 (BCP-9) Authoritative?
==================================

In particular, the relevant sections  are 4.2.2 and 4.2.3.

Three major perspectives have been expressed so far.

  1) RFC 2026 (BCP-9) is not authoritative and IETF
     practices have precedence over it.

An example of this perspective is:

>>>>> On Mon, 9 Nov 1998 10:54:23 -0800, [email-masked] said:

  braden> Mohsen,
  braden> I would like to suggest a procedural confusion in your messages.

  braden> I believe that BCPs simply document current practice.  They are not
  braden> standards, and they are not constitutional documents.  BCP-9 is a
  braden> best-effort attempt to document procedures of the IETF.  Like the
  braden> Internet itself, it provides no guarantees.  If the BCP does not agree
  braden> with practice, it is likely that the BCP, not the practice, is deficient.

I have a serious problem with that.

That sort of an attitude results into transformation of
IETF/IESG into a cult in no time. That in effect says: we
do as we please, just follow us.

Also, because in this case we are dealing with
interactions outside of the IETF (with RFC Editor and
non-IETF RFC producers), that sort of a perspective
amounts to false advertising and bogus marketing.
(We advertise RFC 2026, but do as we please.)

At any point in time, the process of getting a Non-IETF,
Non-Standards Track document published as an RFC should
be clear to those outside of the IETF. If that is not
RFC 2026, then whatever else it is should be concrete
and clear.

   2) Pay Lip Service to RFC 2026, but do whatever we want.

This is my reading (in between the lines) of some of the
old timer's messages and it is also consistent with my
experience with publication of RFC-2188.

   3) RFC 2026 is Authoritative.

This is what I like to hear.

If that is the case, then a whole lot of the
perspectives expressed on this list are way out of line.

IETF/IESG should have complete control over all of RFC publication.
===================================================================

By now, many have expressed the above perspective. 

Many people on this list dis-like the possibility of
non-standards track documents from outside of the IETF
being published as Informational/Experimental RFCs
without IETF/IESG's full review and approval. The
reasons often sited are low quality documents and abuse
of the RFC name.

Apparently, the IETF/IESG does not trust the RFC
Editor's judgment on publication of the non-IETF,
non-standards track documents and wants to exert
complete control over publication/non-publication of all
documents.

Based on RFC 2026, IESG has a very limited scope for
review in the case of non-standards track documents that
are not from IETF. The scope of the IESG review for
non-standards track documents from outside of the IETF
is to identify and address possible conflicts with the
current work of IETF Working Groups. Such a limited
scope review can be done very quickly and is quite
easy. Therefore, the referred document can be reviewed
by the IESG within a reasonable period of time without
impacting IESG's own protocol development work.

There are many good reasons for limiting the scope of
review of the IESG for non-standards track documents
from outside of the IETF and letting a strong and
independent RFC Editor watch over the quality and
suitability for publication of non-IETF, non-standards
track documents.

Below are some of the reasons why the scope of review of
non-standards track documents from outside of the IETF
by the IESG should be limited to what RFC 2026 says it
should be.
  
  - IETF/IESG are themselves protocol producing entities
    and progressing their own work is of a higher
    priority than reviewing the work of others. They are
    very busy and a general review of other's work is of
    a lower priority. Therefore they can not fulfill 
    the *timely* publication requirement of sections
    4.2.{2,3} of RFC 2026 if the scope of their review
    is broad. 

    This was stated in the following message:
    ---
    From: Fred Baker <[email-masked]>
    Date: Thu, 12 Nov 1998 07:32:07 +0000
    Message-Id: <[email-masked]>
    ---

  - IETF/IESG may in fact be competing or may wish to
    compete with the subject document. Therefore, the
    IESG has a conflict of interest problem. A strong 
    and independent RFC Editor does not have that
    problem.

    The possibility of IESG delaying or censoring 
    protocols which may compete with its own work
    is very problematic.

  - The employers of IESG members may in fact be
    competing or may wish to compete with the 
    subject document. Therefore, at a minimum there is
    the perception of a conflict of interest. A strong 
    and independent RFC Editor does not have that
    problem.

  - ...

The fact that the IESG wants to increase its direct
involvement in determining suitability for publication
of non-IETF, non-standards track documents is no secret.

In an Internet-Draft titled:
    Secret Handshakes: How to get RFCs published in the IETF
                 <draft-bradner-handshake-01.txt>

in Section 6, which includes in its scope non-standards
track documents from outside of the IETF, the draft says:

   "....  Finally the IESG can decide that the
   document does not meet the quality or other
   standards for publication which the IESG is
   charged with maintaining."

According to RFC-2026 and RFC-2223 the IESG is NOT
charged with maintaining quality or other standards for
publication of non-standards track documents from
outside of the IETF. 

The fact that IETF/IESG wish to weaken the RFC Editor's
role and expand their own is consistent with many
messages on this list.

Strength, Independence and Credibility of the RFC Editor
========================================================

Is the RFC Editor presently independent enough and
strong enough to carry out the responsibilities
enumerated in sections 4.2.2 and 4.2.3 of RFC 2026?

The best way to to judge and determine that is to
introduce an audit trail and have some level of
transparency into the process and communications related
to publication of non-ietf, non-standards track
documents.

>>>>> On Thu, 12 Nov 1998 23:20:39 +0000 (GMT), Lloyd Wood <[email-masked]> said:

  Lloyd> On Thu, 12 Nov 1998, Vernon Schryver wrote:
  >> As someone else said, the value of any publication today is in the editing,
  >> in what does not get published.

  Lloyd> Not just editing. There's a lot to be said in favour of having an
  Lloyd> _independent_ editor.

  Lloyd> That independence goes with accountability - ...

If there was a way to go and see:

  -  which submissions were not published and why
  -  how long it took for various submissions to reach publication
  -  how much of the delay was due to the IESG's
     supposedly limited review
  -  how often did the RFC Editor and the IESG
     disagree
  -  ...

then, the strength, independence, integrity and
credibility of the RFC Editor could be judged.

If the RFC Editor Office presently is not strong enough
and independent enough, then we should strengthen it. By
funding it more, by adequately equipping it with
knowledge and experience and ....

Of all the difficulties surrounding the "IANA Split",
shaping the future of RFC Publication Service and the
RFC Editor seems simplest and most obvious to me.

We need a not-for-profit independent RFC Publication
Organization.  Getting funding for such a crucial
service should not be difficult at all. By now most
people understand that DARPA was the best investment that
the US ever made ... I am willing to make a contribution
to a not-for-profit independent RFC Publication
Organization with no strings attached. 

It is quite reasonable for the RFC Editor to charge the
IETF for the services that the RFC Editor provides to
IETF.

But funding the RFC Editor's office entirely and
exclusively by IETF funds is recipe for disaster. I
objected to this in February, and now that:

  Fred> As  a result, the RFC Editor's office (which the IETF now funds through ISOC
  Fred> money; that wasn't true two months ago) ...

that mode of funding is done, I consider it a serious
problem.

Such an arrangement reduces the RFC Editor's
independence and further stifles publication of
non-ietf, non-standards track documents.

With respect to the RFC Editor's priorities, IETF
submissions and non-ietf, non-standards submissions
should be equal. Otherwise, at least the spirit (if not
the letter) of sections 4.2.{2,3} of RFC-2026 are
violated.

Many on this IETF list don't see much value in
publication of non-ietf, non-standards track
documents. They refer to them as random documents from
random persons who want the cachet of RFC authorship.

I see a great deal of value in non-ietf, non-standards
track documents. They can document and publish the
significant work of other groups (how did the Web come
about?).  They can provide for parallel experimentation
(in addition to IETF work). They can introduce
competition in development of protocols (e.g., PGP, PEM
- S/MIME) ...

Facilitating propagation of technical information to the
Internet technical community and then letting the
network and the market choose winners and loosers is the
only paradigm that has worked. 

A strong RFC Editor (not the IESG) can take care of the
"quality concerns" about the non-ietf, non-standards
track documents.

Those of you who wish to change the IESG and RFC
Editor's roles and responsibilities should at least be
honest and start by updating BCP-9. 

Those of you who wish to completely suppress the
non-ietf, non-standards track documents and make the RFC
publication process the exclusive right of IETF/IESG are
meddling with powers which you could not possibly
comprehend.

...Mohsen.

---

From: Mohsen BANAN <[email-masked]>
Date: Mon, 30 Nov 1998 01:05:31 -0800 (PST)

braden> Mohsen,

  

  - ...

...Mohsen.

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 30 Nov 1998 07:13:22 -0500

Mohsen,

I didn't follow the part where you seemed to say that funding
of the RFC editor by "IETF" somehow weakened the RFC Editor.
The funding isn't from IETF, it is from ISOC.

ISOC supports IETF and it will support the RFC-editor function.
That's part of our mission. Neither support function should
erode the independence of the editorial decisions made by the
RFC-editor. ISOC has a proposal from ISI for funding of the
RFC-editor function and the board has responded favorably
to the idea. ISOC has no intention of interfering with the
editorial process.

Vint Cerf

=================================================================

See you at INET'99, San Jose, CA, June 22-25,1999 
http://www.isoc.org/inet99/

---

From: "vinton g. cerf" <[email-masked]>
Date: Mon, 30 Nov 1998 07:13:22 -0500

Mohsen,

Vint Cerf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Nov 1998 18:50:01 +0000

Could we perhaps have this discussion on the POISSON WG list
where it belongs?

Thanks

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Nov 1998 18:50:01 +0000

Thanks

   Brian

---

From: Mohsen BANAN <[email-masked]>
Date: Mon, 30 Nov 1998 11:14:08 -0800 (PST)

>>>>> On Mon, 30 Nov 1998 07:13:22 -0500, "vinton g. cerf" <[email-masked]> said:

  Vint> Mohsen,
  Vint> I didn't follow the part where you seemed to say that funding
  Vint> of the RFC editor by "IETF" somehow weakened the RFC Editor.
  Vint> The funding isn't from IETF, it is from ISOC.

My point was that if the IETF/IESG are in "in the loop" as far as 
control of funds to the RFC Editor goes, then that impacts the 
RFC Editor's independence.

Some in the IETF seem to think that "their" money is "wasted" on
review of non-ietf, non-standard track documents.

This was at least implied in a message that Fred Baker included:

  Fred> At 02:37 AM 11/8/98 -0700, someone wrote:
  >> ...  Why should the IETF pay to edit

Also, Fred Baker, used the words "the IETF now funds", instead of
saying that the "ISOC is now funding" the RFC Editor.

>>>>> On Thu, 12 Nov 1998 07:32:07 +0000, Fred Baker <[email-masked]> said:
  Fred> ... (which the IETF now funds through ISOC
  Fred> money; that wasn't true two months ago) ...

Based on the above, I felt that the nature and the manner of the
funding could in fact impact the independence of the RFC Editor.

  Vint> ISOC supports IETF and it will support the RFC-editor function.
  Vint> That's part of our mission. Neither support function should
  Vint> erode the independence of the editorial decisions made by the
  Vint> RFC-editor. ISOC has a proposal from ISI for funding of the
  Vint> RFC-editor function and the board has responded favorably
  Vint> to the idea. ISOC has no intention of interfering with the
  Vint> editorial process.

  Vint> Vint Cerf

That is good.

Please keep us posted on how the specifics of ISOC's funding of the
RFC Editor turn out ...

We also need to make sure that the amount of the funding is adequate
so that we can have a strong, independent and credible RFC Editor.

...Mohsen.

---

From: Mohsen BANAN <[email-masked]>
Date: Mon, 30 Nov 1998 11:14:08 -0800 (PST)

Vint> Mohsen,

  Vint> Vint Cerf

That is good.

...Mohsen.