1 files changed, 112 insertions, 0 deletions
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]<NETINFO>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 <NETINFO>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]
+