Subject: Re: IANA split and RFC Editor

From: [email-masked]
Date: Tue, 24 Feb 1998 09:39:25 -0800

> In addition to splitting IANA, I am also concerned that the RFC
> Editorship might get lumped into the "new" corporation.  This would be
> a Bad Thing.

Bill:

The RFC Editor task will not be part of the "new IANA corporation", and
will be a separate function to managed and funded by the
IETF/IESG/IAB/ISOC.

--jon.

---

From: Mohsen Banan <[email-masked]>
Date: Tue, 24 Feb 1998 13:34:30 -0800 (PST)

>>>>> On Tue, 24 Feb 98 16:58:27 GMT, "William Allen Simpson" <[email-masked]> said:

  William> In addition to splitting IANA, I am also concerned that the RFC
  William> Editorship might get lumped into the "new" corporation.  This would be a
  William> Bad Thing.

>>>>> On Tue, 24 Feb 1998 09:39:25 -0800, [email-masked] said:

  postel> Bill:

  postel> The RFC Editor task will not be part of the "new IANA corporation", and
  postel> will be a separate function to managed and funded by the
  postel> IETF/IESG/IAB/ISOC.

This is a very bad idea for many reasons.

Before getting to the reasons, note that I am NOT
saying that The RFC Editor task needs to be part of
the "new IANA corporation". I am saying that it needs
to be a completely separate function INDEPENDENT of
management and funding by the IETF/IESG/IAB/ISOC.

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.)

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 is an obvious inherent problem with allowing a
common Publication Service 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.

Now, in theory, according to "The Internet Standards
Process" (BCP-9) the RFC Editor should threat
documents coming from outside of the IETF in a
responsible, independent manner. However, 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.

I am very worried that if the RFC Editor task comes
under the management and funding of IETF/IESG/IAB/ISOC
this situation will only get worse.

May be a concrete example will make my concern more
clear. Let's take the case of the Informational RFC
2188, "Efficient Short Remote Operations (ESRO)".

We submitted that document for publication in January
of 1997. The RFC Editor under instructions from the
IESG delayed the publication of that document for more
than 8 months (there was no good reason for that
delay). During those 8 months the RFC Editor's role
was nothing more than an inefficient messenger for the
IESG. The situation was a total mess. Postel, Coya,
Bradner, the IESG and the RFC Editors already know
well about the failures of the current process. I can
supply a complete transcript of all the email
exchanges related to the publication of RFC-2188 to
others, if there is any doubt about the problems with
current practices.

Let's look at what needs to happen in the bigger
picture. Standardization process iterates through
4 essential 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 protocol 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 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).

One more observation, the RFC Publication process
needs more structure, definition and order. Further,
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 right.

I think the future of the RFC Publication Service is
as important as DNS and IANA. However, I think that it
has not been discussed enough in any of the recent
threads on this list and elsewhere.

I am very interested in hearing other (e.g., opposing)
views on this.

...Mohsen.

---

From: Sascha Ignjatovic <[email-masked]>
Date: Tue, 24 Feb 1998 23:30:35 +0100 (MET)

> management and funding by the IETF/IESG/IAB/ISOC.

what you think about microsoft are they ok ?
they would do a great job and founding is never a problem for them  ha ?
and they are also independent isnit ?:-)

sorry you may have some critical points who may be useful to think of 
but what you not have is the autority to put your self in 
"center of the internet world" and become "higher" than the 
IETF/IESG/IAB/ISOC by declaring them incompetent and obsolete 

this kind of radical changes never work  but what is working is a improval 
starting with the situation we have now and improve it

if you think you may contribute than please do so by helping the people 
who are trying their bests to do even better 

they would apreciate very much your competenc and work and would be happy 
to share it with you 

but if you start with "we need something new i have no idea what it could
be and we need a funding too and i dont know how and of course we have to
start with 0 and of course there are so little other work that we have to
concentrate just on this..."

its like you may say 

"this internet is bad  lets make a new internet from sratch"

there where many people trying to replace the internet and to build 
"something better"  but as today the intenet is remaining and it evolves 
slowly but steadily its own way 

> I am very interested in hearing other (e.g., opposing)

i apreciate your coments and like to ask you very humbly to put your
competence in the service of existing internet and to serve the process
and help to imporve it 

but please dont try to establish a "new internet" 

it would't work 

> ...Mohsen.

thank you
sascha
ps.but of course  if you dont belive it   just try it :-)
 
   and of course as always i am not competent :-)

   just a personal comment :-)

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 24 Feb 1998 19:58:01 -0500

Date: Tue, 24 Feb 1998 13:34:30 -0800 (PST)
   From: Mohsen Banan <[email-masked]>

It's already the case that the RFC editor task has a dotted-line
relationship to the IAB, and you can't just squirt out a random RFC
without some consultation between the RFC editor and the IESG.

The problem is that without this, people can side-step the standards
process and publish random RFC's; many people assume that just because
it has the "RFC" stamp on it, it is an internet standing and treat all
RFC's with equal weight.  This is a long standing problem, and you could
just say that people are stupid, but if it's that easy to defraud
people, then perhaps we have some responsibility to assure that someone
can't just ask random porn (protocol porn or sexual porn) to be
published by the RFC editor just because someone claims that they're
another customer of the RFC Publication service.  

The obvious thing to do is mandate that you can't just publish any
random RFC that looks like it's trying to pretend to be an Internet
standard without either (a) IESG approval, or (b) serious disclaimers in
the text about how this is not an official IETF-sanctioned standards and
that it may have serious interoperability or portability problems.

There needs to be a process of deciding what gets published as an RFC,
and I'd much prefer a process which involved the IETF/IESG/IAB, rather
than one which is either "anything that gets submitted, is published" or
making it purely at the personal whim of the RFC editor.  It's much
better to say that the IETF/IESG/IAB is *the* primary customer of the
RFC Publication Service.

							- Ted

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Feb 1998 18:18:06 -0800 (PST)

> another customer of the RFC Publication service.

Protocol porn? Gotta write that one down -- what a great turn of phrase! 

Another thing to keep in mind is that things have changed just a little since
1969 when RFC 1 was published. Back in 1969 the costs of publishing your own
documents electronically were astronomical. This is no longer true; these days
anyone can put together their own RFC series and publish them on the Web, and
several people (and organizations) have done exactly this.

> that it may have serious interoperability or portability problems.

One can argue that such disclaimers may damage a proposal's chances of being
taken seriously. And similarly, one can argue that alternative forms of
publication don't have the cachet of the IETF's RFC series. And I would agree
with both of these. But the cachet of IETF-approved RFCs isn't undeserved; it
is something that has been earned through the blood, sweat, and tears of the
contributors to it, including those who have contributed in an editorial
capacity. So when someone comes along and insists on the right to publish
something in the series without adequate review or labelling, well, I view this
as basically an attempt to make off with some of the the IETF's reputation.

This is not to say that the process is free of problems. Of course it has
problems. Every process run by human beings does; it is, so to speak, the
nature of the beast. I myself have been more than a little upset at the RFC
Editor on more than one occasion over an action I viewed as stupid,
unwarranted, or worse.

But then again I've also had experience with editors in other venues, and when
I compare my experiences in publishing RFCs with what other editors have done
to my work the extraordinary quality of the RFC process is apparent. Ever had
an article approved and then watch it vanish down a sinkhole without a word
being said? I have. Ever have an article edited so incompetently that the end
result made the author (me) look like a complete jackass? I have. Ever had an
article's title changed to something that entirely missed the point? I have.
Ever had an article rejected because a reviewer didn't like way one label on
one of the graphs was written, with the result being that a critical deadline
was missed? I have.

The bottom line is that I've had to make some concessions and changes in how I
work to accomodate the RFC process, some of which I didn't especially like. But
this is not materially different than what I've had to do in other venues, and
overall the RFC publication process has given me nothing short of stellar
treatment, treatment I've _never_ received anywhere else, and treatment which
in some cases I'm sure I did not deserve. And I doubt if my experiences are all
that atypical. No, I suspect they are fairly typical of many RFC authors.

Now, I do not mean for a minute to suggest that you, Mohsen, don't have a
legitimate grievance or grievances. You may or may not -- I cannot tell since I
don't have a basis on which to judge. But I do not think that anything you have
claimed is wrong with the process is sufficient to justify the sorts of changes
you propose.  I believe the process works extraordinarily well most of the time
and that the only changes we should be making are ones to correct demonstrable
problems and ones we absolutely must make to insure that the process we have
continues to work.

> better to say that the IETF/IESG/IAB is *the* primary customer of the

Frankly, I would have no major problem saying that the IETF/IESG/IAB is the
_only_ customer, given the ease of publication elsewhere. However, I also think
the availability of a means to publish outside contributions is in general a
plus so I would be sorry to lose it.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Feb 1998 22:43:03 +0000

Please let's not waste time discussing this issue right now.
We have much more pressing problems. When the dust has settled
on them will be time enough to worry about the RFC Editor
function. For now, normal service will continue.

   Brian Carpenter

---

From: Mohsen Banan <[email-masked]>
Date: Wed, 25 Feb 1998 15:47:41 -0800 (PST)

>>>>> On Wed, 25 Feb 1998 22:43:03 +0000, Brian E Carpenter <[email-masked]> said:

  Brian> Please let's not waste time discussing this issue right now.
  Brian> We have much more pressing problems. When the dust has settled
  Brian> on them will be time enough to worry about the RFC Editor
  Brian> function. For now, normal service will continue.

  Brian>    Brian Carpenter

O.K.

Agreed. Given the current atmosphere (GP and all),
may be we are better off waiting a bit.

For now, I will not further pursue this issue and
wait till the dust has setteled.

There is a saying in Farsi that translates into
something like:

   "He who has been bitten by the snake
    becomes afraid of the rope."

My concerns about PRESERVING the so far open RFC
Publication Service, resulted into significant
over-reactions. 

I'll revisit those concerns later.

...Mohsen.