RFC 849

RFC 849: Suggestions for Improved Host Table Distribution ✨

okay bestie, this one is SO unique 🙈 it's an RFC that literally requests comments! It's from the Network Working Group 🧚, written by Mark Crispin at Stanford in May 1983 🎀. The header doesn't list a category, and it doesn't obsolete or update anything. It's about how the naming registry gets updated, both how it works now and how it could work later. Nothing in here is meant to be a standard yet. The goal is to get everyone talking until a general consensus shows up, and standards can come later 💅.

The Problem 💅

Mark is lowkey 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 they honestly have to, since SRI-NIC is simply not reliable enough to depend on as a name server 💀. Neither the Tenex operating system nor the Foonly computer is known for exceptional reliability or performance. They probably serve the NIC's internal operations well, but that's not the issue here 🫶. What's needed is a name service that's available at all times. Only then could a site give up maintaining its own local copy of "the host table" ✨.

The NIC kinda acknowledges this by offering a service that dumps the entire Internet name registry, plus ANONYMOUS FTP access to the <NETINFO>HOSTS.TXT file 📁. The problem is that someone has to know to go grab the latest version from the NIC. The NIC hasn't always been careful about announcing updates to the name registry. Mark has run his own name registry separate from the NIC's in the past, so he gets the NIC's problems 🥹.

There's also no good automated way to cross-check the local version against the NIC's. It's clearly inefficient to go through the effort of retrieving the same version of the host table that's already installed on site 🙃.

Some Solutions 🦋

One could argue the fix is to replace or augment the present SRI-NIC system with VAX Unix system(s) dedicated to name service and network information 🖥️. A reliable, highly responsive name service would eventually mean sites don't have to keep local copies of the registry at all. But that costs money, time, and effort, which may or may not be immediately available, so it's a longer-term solution 🕰️.

A more short-term option is making faster and more thorough updating of the various local copies of the name tables possible. Mark has a few suggestions and wants comments (he said this was an RFC that requested comments! 😭):

1. A new protocol where the NIC ships updated name registries to the hosts itself. This would be 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). It would allow nearly immediate updates for cooperating sites, as long as the hosts in question are up. There should be some sort of checksum applied to the updated name registry, so it's proven to have arrived complete and intact 🔐.
2. A new protocol where the NIC reports the current "version" of the host table. Tenex and TOPS-20 sites would find the use of the file generation number natural 🧠. Mark currently keeps a SYSTEM:HOSTS.TXT with the same generation as the one on the NIC, and just checks the NIC from time to time to see if the generation number changed there. He'd like to automate that 🤖.
3. A variation on (1), where the NIC mails the updated host table to a mailing list of "host table update" recipients, and each site sets up its own update procedures. This is the simplest for the NIC to implement, but it's fraught with all sorts of problems. Mail is not a good way to bulk-ship files to many recipients, especially when the files are likely to become huge 📬💀.

Mark likes (1) best of these three, because it would guarantee immediate updating without each site having to periodically poll the NIC. But that puts the burden on the NIC to make sure every site receives the update, and it means the NIC has to remember which sites are dead so it can retry later 😮‍💨. Which leads to what he thinks is the best solution 👑:

4. A combo of (1) and (2). The NIC will ship updates to all hosts registered with it to receive them, and it will only try 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 🌈.