Subject: Re: The Non-IETF Informational RFC Publication Fiction

From: Bob Braden <[email-masked]>
Date: Tue, 27 Jun 2000 15:48:50 GMT

*> 
  *> The Real component is that IETF/IESG/IAB is well on its way towards
  *> becoming a cult violating all published procedures. IETF/IESG/IAB now
  *> claims full ownership of the RFC Publication process and quashes
  *> whatever may want to compete with it or that it does not
  *> like. IETF/IESG/IAB often inserts notes in Non-IETF Informational RFCs
  *> which go above and beyond the scope and purpose of IESG
  *> review. IETF/IESG/IAB often regards the RFC-Editor as merely its
  *> agent. IESG/IAB has become a group of irresponsible volunteers who
  *> consider themselves accountable to no one.
  *> 

Mohsen,

One of the advantages of becoming a geezer is that you get to say what
you REALLY think.  However, good taste prevents my telling you in public
what I REALLY think about your message.

I would like to remind you that, had the RFC Editor been "a mere
agent" of the IESG, your EMSD RFC 2524 would not have been
published at all.

Bob Braden

---

From: Mohsen BANAN-Public <[email-masked]>
Date: 27 Jun 2000 16:38:48 -0000

>>>>> On Tue, 27 Jun 2000 15:48:50 GMT, Bob Braden <[email-masked]> said:

  Mohsen>
  Mohsen> The Real component is that IETF/IESG/IAB is well on its way towards
  Mohsen> becoming a cult violating all published procedures. IETF/IESG/IAB now
  Mohsen> claims full ownership of the RFC Publication process and quashes
  Mohsen> whatever may want to compete with it or that it does not
  Mohsen> like. IETF/IESG/IAB often inserts notes in Non-IETF Informational RFCs
  Mohsen> which go above and beyond the scope and purpose of IESG
  Mohsen> review. IETF/IESG/IAB often regards the RFC-Editor as merely its
  Mohsen> agent. IESG/IAB has become a group of irresponsible volunteers who
  Mohsen> consider themselves accountable to no one.
  Mohsen>

  Bob> Mohsen,

  Bob> One of the advantages of becoming a geezer is that you get to say what
  Bob> you REALLY think.  However, good taste prevents my telling you in public
  Bob> what I REALLY think about your message.

  Bob> I would like to remind you that, had the RFC Editor been "a mere
  Bob> agent" of the IESG, your EMSD RFC 2524 would not have been
  Bob> published at all.

That is true.

In the case of RFC-2524, the RFC Editor did demonstrate
independence. I believe I also played a significant role in
establishing the RFC Editor's independence based on my insistence on
doing it by the book.

Complete communication records related to publication of RFC-2524 are
available through http://www.emsd.org/

In the case of RFC-2188, the RFC Editor did *nothing* and just waited
for the IESG for more than 7 months. That is well documented.

I have heard of various other reports of IESG's interference. See DJB's
case study for example ...

My exact words were:

  Mohsen> IETF/IESG/IAB often regards the RFC-Editor as merely its agent.
                        ^^^^^

That is why I said, "often".

...Mohsen.

---

From: Tim Salo <[email-masked]>
Date: Tue, 27 Jun 2000 12:26:53 -0500 (CDT)

> Date: 27 Jun 2000 16:38:48 -0000
> From: Mohsen BANAN-Public <[email-masked]>
> Subject: Re: The Non-IETF Informational RFC Publication Fiction
> 	[...]
> I believe I also played a significant role in
> 	[...]

And, Al Gore is the father of the Internet...

-tjs

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Jun 2000 14:27:29 -0400

> for the IESG for more than 7 months. That is well documented.

A bit of explanation is in order.

The IESG takes its review responsibilities seriously, and cannot
always in good conscience approve the publication of a document.

In such cases the IESG tries to give feedback to the author as to 
what changes to the specification might cause it to (in the opinion
of IESG) merit publication.  Sometimes providing this feedback is 
quite difficult, especially when the specification is poorly written,
or when the author lacks knowledge about how to design a protocol 
that works well over the Internet.  (Lack of understanding about
security - including DoS attacks, and congestion avoidance, are 
common problems)

In most cases the author and IESG work out a compromise that allows
the document to be published.  But when the author stubbornly insists 
that he has the *right* to have his document published without significant 
changes, it becomes nearly impossible for the author and IESG to compromise. 

In this case IESG, knowing that the RFC Editor might choose to publish
the document over its objections, attempts to write an IESG Note that
will at least explain to readers what IESG thinks is wrong with the 
document.  This can also be quite difficult and time consuming, because
it's not always possible to rectify major problems with a brief note.

(Note that in the case of at least one of Mr. Banan's documents, the 
RFC Editor further negotated with IESG to soften the wording of the 
original IESG Note.)

The problem is not that it took 7 months for the IESG to produce a
note about one of Mr. Banan's documents, but that the review of Mr. Banan's 
documents consumed precious IESG resources that would have been better 
applied to documents (both individual submissions and working group documents)
which were more deserving of publication.  This resulted in significant 
delays in publication of the more deserving documents.

If I were to suggest any change in the RFC review and publication process,
it would be to give IESG the power to say "no" to publication of individual
submissions.  (perhaps with the possibility of formal appeal to IAB)
I do not believe that IESG would do this capriciously, and I believe 
that this would make better use of IESG resources.  And such a change would 
make it quite clear that individuals authors do NOT have the right to have 
their documents published as RFCs.

Keith (no longer on IESG, and not speaking for them)

---

From: Bill Manning <[email-masked]>
Date: Tue, 27 Jun 2000 19:40:46 -0700 (PDT)

% If I were to suggest any change in the RFC review and publication process,
% it would be to give IESG the power to say "no" to publication of individual
% submissions.  (perhaps with the possibility of formal appeal to IAB)
% I do not believe that IESG would do this capriciously, and I believe 
% that this would make better use of IESG resources.  And such a change would 
% make it quite clear that individuals authors do NOT have the right to have 
% their documents published as RFCs.
% 
% Keith (no longer on IESG, and not speaking for them)

I think things are headed in that general direction and I think it is a
sad state of affairs. Historically, RFCs were used to document ideas, 
both good and bad. The series covered the range of idea generation
and expression and this was encouraged by the RFC editor. Now, many 
"non-conformant" ideas are being released into the community as defacto 
documents since it is too hard to get material documented in the RFC series 
as either informational or experimental. This is in part due to the IESG/IAB
review cycle that is now part of the process.  This practice leads to 
closed environments, documentation, code and operations.  Not what I would 
have hoped for in an evolved Internet.

--bill

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Jun 2000 16:07:19 -0400

> Not what I would have hoped for in an evolved Internet.

A lot has changed in the past 30 years.

The notion that 'anything is fair game' in the RFC series made a lot
more sense when the Internet was just an experimental network, and 
when packet-switched newtorking was brand new.  In such an environment
one could make the argument that all experiments in using the network
were more-or-less equally valid.

These days the value in the RFC series is not that it is a central
repository for everything having to do with Internet protocols
(as if such a repository were even feasible!) but that documents
in the series are likely to be relevant and of reasonable quality.
Indeed, were it not for the efforts of the RFC Editor and IESG to
maintain a high quality document series, folks wouldn't be nearly
so interested in having their documents published as RFCs.

Keith

---

From: "Yixin Zhu" <[email-masked]>
Date: Tue, 27 Jun 2000 15:36:03 -0500

Hi,

During the study of the SIP methods for implementation of some supplementary
service such as call hold, call waiting etc. It seems to me that we can use
re-invite or Info. Can some one here tell which method is better? Thanks.

For the SIP User agent available today, which method has been used in the
implementation (INFO method, or re-Invite)?

Many thinks.

Yixin Zhu

---

From: "Yixin Zhu" <[email-masked]>
Date: Tue, 27 Jun 2000 16:29:06 -0500

SNMP is a popular management interface for fault, performance and
configuration. Recently, JMX (Java managemant extension) are getting popular
every day. I would like to know a comparision study between SNMP and JMX.
Your help is greatly appreciated.

Thanks.

Yixin Zhu

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 27 Jun 2000 20:03:35 -0400

Keith Moore wrote:

> so interested in having their documents published as RFCs.

There are plenty of publication venues available for network protocols.
Even those without access to a local tech report service can avail
themselves of, say, www.arXive.org, where entries are cataloged and
announced to interested parties. There are about 50,000
networking-related papers in my network bibliography
(http://www.cs.columbia.edu/~hgs/netbib) and it is far from complete,
containing mostly journal and peer-reviewed conference articles (as well
as RFCs). [That said, additions are much appreciated.] Should everyone
of them be an RFC? Why? Every journal and conference worth
reading/attending has an editorial board or technical program committee.
The review process for these typically takes from six months to a year
or more, with rejection ratios of 70 to 90% not uncommon. Compared to
that, the threshold and review for informational RFCs is pretty low (too
low, if you like).

> 
> Keith
> 
> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Harald Alvestrand.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 28 Jun 2000 07:25:46 +0200

>establishing the RFC Editor's independence based on my insistence on

Not at all.

You did not change or play any specific role at all.

The standard mechanism was used.

    paf