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/rfc849.txt | 112 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 doc/rfc/rfc849.txt (limited to 'doc/rfc/rfc849.txt') diff --git a/doc/rfc/rfc849.txt b/doc/rfc/rfc849.txt new file mode 100644 index 0000000..d1c2619 --- /dev/null +++ b/doc/rfc/rfc849.txt @@ -0,0 +1,112 @@ +Network Working Group Mark Crispin +Request for Comments: 849 Stanford + May 1983 + + + SUGGESTIONS FOR IMPROVED HOST TABLE DISTRIBUTION + + This RFC may be something unique among modern-day RFC's, an RFC +that actually is a request for comments. The issue dealt with is that +of a naming registry update procedure, both as exists currently and what +could exist in the future. None of the proposed solutions are intended +as standards at this time; rather it is hoped that a general consensus +will emerge as the appropriate solution, leaving eventually to the +adoption of standards. + + THE PROBLEM + + I am somewhat dissatisfied with the current level of Internet name +service and name registry updating. Each site is expected to +individually maintain a copy of the [SRI-NIC]HOSTS.TXT file, +and in fact has to, since SRI-NIC is simply not reliable enough to +depend upon as a name server. Neither the Tenex operating system nor +the Foonly computer are known for exceptional reliability or +performance. Probably they serve the NIC's internal operations well; +that is not at issue. What is needed is a name service that is +available at all times. Only then could a site sacrifice maintaining +its own local copy of "the host table". + + The NIC indirectly acknowledges this, by providing a service by +which the entire Internet name registry can be dumped, as well as +ANONYMOUS FTP access to the HOSTS.TXT file. The problem is, +some individual has to know to retrieve the latest version of the file +from the NIC. The NIC has not always been careful to announce updates +to the name registry. My experience with maintaining an independent +name registry from the NIC's in the past leads me to appreciate the +NIC's problems. + + There also seems to be no good automated way to cross-check the +version at the local site with the NIC's. It is clearly inefficient to +go to the effort of retrieving the same version of the host table that +already has been installed on site. + + SOME SOLUTIONS + + One could argue that a solution is to replace or augment the +present SRI-NIC system with VAX Unix system(s) dedicated to name service +and network information. A reliable and highly-responsive name service +would ultimately lead to the elimination of the necessity to maintain +copies of the registry locally. This solution requires money, time, and +effort, which may or may not be immediately available; it must therefore +be considered a longer-term solution. + + + +Crispin [Page 1] + + A more short-term solution is to make possible faster and more +thorough updating of the various local copies of the name tables. I +have several suggestions in this area, and would like to hear comments +(I said this was an RFC that requested comments!): + + (1) a new protocol by which the NIC could ship updated name +registries to the hosts itself. This would take the form of a server +process on each site listening on a registered port for updates from +certain "trusted" sites (specifically SRI-NIC but possibly other sites +as well). This would allow for nearly immediate updates for cooperating +sites, provided that the hosts in question are up. There should be some +sort of checksum applied to the updated name registry, to make sure it +arrived complete and intact. + + (2) a new protocol by which the NIC will report the current +"version" of the host table. Tenex and TOPS-20 sites would find the use +of the file generation number natural. I presently maintain a +SYSTEM:HOSTS.TXT with the same generation as it existed on the NIC, and +just check at the NIC from time to time to see if the generation number +changed there. I would like to automate this. + + (3) A variation on (1), whereby the NIC would mail the updated host +table to a mailing list of "host table update" recepients and each site +would establish its own update procedures. This is the simplest to +implement for the NIC, but is fraught with all sorts of problems. Mail +is not a good means for bulk-shipping files to many recepients, +especially when the files are likely to become hugh. + + I like (1) best of these three, because that would guarantee +immediate updating without a local necessity to periodically poll the +NIC. That does place the burden on the NIC to make sure all sites +receive the update, and also requires that the NIC remember which sites +are dead to retry the update later. This leads me to what I think is +the best solution, which is: + + (4) A combination of (1) and (2). The NIC will ship updates to all +hosts which are registered with it to receive the updates, and will try +only once. Each site, as part of its system startup procedure, will run +a program to poll the NIC for a possible update and if one is available +retrieve it. As a backup, there could also be a periodic poll on, say, +a daily basis. + + + + + + + + + + + + + +Crispin [Page 2] + -- cgit v1.2.3