1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc531.txt b/doc/rfc/rfc531.txt
new file mode 100644
index 0000000..93b8909
--- /dev/null
+++ b/doc/rfc/rfc531.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                    M. A. Padlipsky
+Request for Comments #531                                    MIT-Multics
+NIC  17450                                                 June 26, 1973
+
+
+                            Feast or famine?
+        A Response to Two Recent RFC's About Network Information
+
+
+In RFC 514, Will Kantrowitz returns to the theme of his superb RFC 459.
+There are too many people spending too much time asking for too much
+information about Network Hosts.  In RFC 519, John Pickens returns to
+the theme of his rather querulous RFC 369.  It's not easy to learn how
+to use network Hosts.  On the one hand, it would seem that there's a
+veritable feast of information going around; on the other hand it would
+seem that there's a terrible famine.  Can this apparent contradiction be
+resolved?
+
+I think it can be, and will attempt to do so after making a few
+observations about the respective poles.  In regard to the issues
+Kantrowitz raises, matters are perhaps even worse for the "big" Servers
+than for the experimental ones; we have something like 50 CUBIC feet of
+system listings for Multics, plus untold user-supplied programs which
+might be of interest, plus several thousand employees (if our "site" is
+construed to mean M.I.T. as a whole) -- surely they didn't want all
+that, even before the request was withdrawn.
+
+But what of the issues Pickens raises?  Surely prospective users ought
+to have some means of learning about the resources available.   The
+point, it seems to me, is that they do ... but they aren't using them.
+As Network Technical Liaison for Multics, I've never heard from any of
+the U.C.S.B. investigators.  I don't even recall their having requested
+a Multics Programmers Manual despite the fact that our Resource Notebook
+section offers one to any Network site, on request.  I do recall seeing
+instance after instance of botched login attempts from them in our error
+logs, though.  I called their Liaison to alert him to the problem but
+they weren't in touch with him either.)  I also recall saying time after
+time, after seeing them floundering around, "it's a pity nobody reads
+the Resource Notebook."
+
+That, I think, is the key: we have a Resource Notebook; it lists
+Technical Liaisons; it gives information about the Hosts thought to be
+relevant to Network users; it gives references to other published
+information.  _Why_don't_we_use_it_???  Sure, not all the sections are
+up to par.  Sure, some sorts of information are neither contained nor
+pointed to.  But that amounts to a need for seasoning -- the meal is
+there, and it's neither a glutton's portion nor a starvation diet.
+Let's work with what we've got instead of charging around demanding MORE
+
+
+
+Padlipsky                                                       [Page 1]
+
+RFC 531                     Feast or famine?                   June 1973
+
+
+or sulking around bemoaning the (false) fact that the cupboard is bare.
+
+Placing the right amount of reliance on the Resource Notebook, then,
+ought to lead to a solution of the information problem.  In its current
+form, it would have solved the U.C.S.B. people's problems fairly
+completely, for it already tells them to get in touch with me and it
+already shows them how to log in.  (Assuming, of course, that it wasn't
+the unstated object of their game to do it all with only on-line
+information.)  The Resource Notebook could even have solved the RML
+people's problems, for had it been made clear to them that global
+requests for Host information are to be handled through the Notebook
+they'd have been in touch with people who could have explained why their
+requests were inappropriate.  And on close decisions, the Resource
+Notebook maintainers would know whom to consult with in regard to
+appropriateness of results for new categories, I believe.
+
+This is not meant to push the Resource Notebook as a panacea.  Clearly
+it needs strengthing in terms of content.  Even more clearly, it needs
+wide dissemination.  (The planned Network New Users' Packet will show
+how to get at it on-line at the NIC, I'm told.  Even better, perhaps we
+might want to make it available in microfiche.)  Also, this is certainly
+not meant to suggest that the Notebook be viewed as supplanting the
+individual Hosts' users' manuals, although it does seem to be the
+partial repository for documentation to any generic commands we manage
+to come up with.  But I also think it's important for the NWG to
+understand and agree on the proper perspective in which to view the
+Resource Notebook -- and I suggest that that perspective should be as
+"primary source of Host information." To view it otherwise would, it
+seems to me, be wasting both the investment it already represents, and
+the opportunity it can represent.
+
+
+
+
+
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Alex McKenzie with    ]
+       [ support from GTE, formerly BBN Corp.            10/99 ]
+
+
+
+
+
+
+
+
+Padlipsky                                                       [Page 2]
+