Summary

  • The IETF NOCTools Working Group compiled its network-management tool catalog in 1989; RFC 1147 published it in April 1990. Shared keywords let an operator search by function, resource, method, environment and product form.
  • RFC 1470 replaced that edition in June 1993 and made the catalog available through Usenet and FTP. The editors had learned that a printed inventory of changing tools ages faster than its binding.

A network had problems; its operator had a search problem

Imagine being the person called when a remote link goes peculiar at midnight. You might need an alarm, a packet analyzer, a map of the network, or a program that drives a device into a reproducible state. First you have to know whether someone has already built it. The NOCTools group called the tendency to reinvent wheels endemic to data communications. Its answer was almost offensively practical: collect what people were using, say what each tool did, explain its mechanism and tell readers how to obtain it.

The group compiled the catalog in 1989; R. Stine edited the April 1990 RFC. The effort had sponsored compilation and editing, but the RFC credits volunteer work as the reason the catalog existed. That matters because its coverage came from a working community, rather than a central buyer with a complete view of the market. Administrators supplied knowledge that their peers would otherwise have had to discover during an outage. The catalog also offered a short tutorial and, more slyly, exposed gaps: an absent category of tool could be a clue to something operators still needed to build.

The index was the clever part

Alphabetizing names made the book browsable if you already knew a name. NOCTools went further. Each entry used a common set of keywords, grouped by what the tool did, which network resource it managed, its method, the system and hardware it ran on, and whether it was a hardware or software product. That let the reader ask a useful question before choosing a product: “What can show me the route?” or “What can trigger on an event?”

The distinction sounds small until you consider the alternatives. A pile of brochures organizes the world around sellers. A functional index organizes it around the operator’s problem. RFC 1147 listed roles such as alarm, analyzer, debugger, map, routing and security. The list made different entries comparable, and its empty spaces visible. It did not make their claims equally trustworthy. The editors said most tools had not been independently evaluated, and commercial descriptions mostly came from vendors. The shared vocabulary made discovery possible; judgment still belonged to the reader.

Then the catalog began to lose a race with its entries

June 1993 brought a successor, RFC 1470. Its opening admits the obvious embarrassment: a static document cannot incorporate the newest tools and revisions quickly enough, and some printed entries may already be stale. The replacement pointed readers to a live catalog on Usenet and an FTP archive. New and revised entries could be submitted for near-immediate electronic circulation; editors would fold them into master indexes as their time allowed.

That division of labor was revealing. Distribution became quick; editorial indexing still took human effort. The RFC carried an entry template and even an appendix of known tools that lacked full writeups. The catalog was honest about incomplete knowledge while giving contributors a route to improve it. The Internet had supplied both the subject and the delivery system for its own field guide.

The history here is neither a celebrated protocol nor a single miraculous utility. It is the quieter machinery that helps an administrator find a useful utility before trying to invent it at 2 a.m. The 1990 volume gave scattered expertise a common set of drawers. The 1993 revision left those drawers open on the network, where the labels could finally move at something closer to the speed of the tools.