Network make-work
RFC 514

Document Type RFC - Unknown (June 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 514 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      W. Kantrowitz
Request for Comments: 514                                        LL TX-2
NIC: 16445                                                   5 June 1973
Updates: RFC 459

                           NETWORK MAKE-WORK

   The ARPA Network seems to have developed the proclivity of dragging
   compulsive collectors and organizers out of the woodwork and placing
   them in the forefront to annoy everybody.

   Recent occurrences have been:

   1. A set of charts on characteristics of the hosts.  The orientation
      seems to have been:  If you can come up with names for the
      horizontal and vertical nodes and if it has to do with the hosts,
      make a chart out of it.  This collection of charts goes under the
      euphemism "ARPA Network handbook".  Information on a host is
      scattered over all the pages which is a questionable organizing
      scheme.  Additionally, since the charts contain much of what is
      already in the Resource Notebook, we now have the delightful task
      of maintaining two documents when changes are necessary.

   2. A telephone call asking for hourly loads on the TX-2 computer for
      every hour of the months April and May.  One can easily imagine
      all this information being keypunched in some computer (on the
      network, of course) and then lovely bar graphs, curves, plots,
      etc., being generated.  Probably in triplicate.

   3. A mailbox message about a "central software repository" and a
      personnel file. (Copy of the message is attached).  This was just
      too much and is the immediate precursor of this RFC.

   My first reaction to the "central software repository" was that this
   has got to be some kind of prank.  But when the second message
   (identical to the first) arrived an hour later and when I learned
   that others had also received it, I reluctantly accepted its
   legitimacy.  Actually, sending the message in duplicate fits in very
   nicely with the general bureaucratic syndrome evidenced by the
   contents of the message.

   This RFC addresses itself merely to the idea of listings of every
   program.  That does not mean that I think that the rest of the
   request is better, just that I don't have the time to write a
   treatise on the general subject.  It should be noted (if not obvious)
   that what follows is being written with almost unbearable restraint.

Kantrowitz                                                      [Page 1]
RFC 514                    NETWORK MAKE-WORK                5 June 1973

   Listings of every program available to network users?  Has anybody
   calculated how much paper would be generated?  How many trees would
   have to be cut down for this paper?  How many filing cabinets are
   going to be needed?  How is this massive amount of information in its
   totality going to be of use anyone?  Is there going to be an
   answering service which will answer such questions as to what is on
   the third line of page 5 of the listings of the editor at a given
   host?  Will one be "required" to send a new listing in order to
   change a program?

         This material has not been reviewed for public release and is
         intended only for use with the ARPA network.  It should not be
         quoted or cited in any publication not related to the ARPA


   From the point of view of a site such as TX-2, the questions become
   even more intriguing.  Many of our programs are written in assembly
   language.  Should we, therefore, also send along a copy of our
   (incomplete) assembly language manual?  Or should we drop everything
   else and complete the manual?  What about listings of our operating
   system since the programs make calls upon the system for input-
   output, file management, etc.?  (I could go on and on, but the
   readers should get the idea by now.)  Much of this applies to any
   host, but for a host which has a one-and-only computer,the problems
   are more acute.

   Once again, may I repeat my plea from RFC 459.  There are small
   research sites on the network.  TX-2 is one of them.  Please, network
   community, don't drown us in a sea of make-work.  We might get
   nothing done just keeping up with it.  Or is that no longer

   In particular, the network community ought to be glad that in the mid
   1960's we at TX-2 weren't bombarded with tons of make-work and were
   able to get something done.  What I have in mind is the initial
   experimentation with a small-scale network prototype with SDC which
   demonstrated the feasibility of networks and led to the ARPA Network.
   (Please see reference.)  Who knows what we, or some other site, will
   come up with if given the chance?

   Some people have suggested that I not write this RFC reasoning that
   if I just ignore it, the problem will go away.  But the problem is
   not going away.  If anything, it seems to be getting worse.  Silence
Show full document text