From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc531.txt | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 doc/rfc/rfc531.txt (limited to 'doc/rfc/rfc531.txt') 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] + -- cgit v1.2.3