The Host Table Before the Market: Who Authorised the First Internet Ledger?

Summary

• The early host table acquired practical authority through a bounded chain: ARPA procured the Network Information Center for ARPANET, SRI maintained the common record, participating sites supplied and consumed host information, and DCA later incorporated the service into an operational DoD environment.
• RFC 810 published a registration precondition for names and addresses used in relation to traffic passed by DoD hosts, but the surviving specification does not demonstrate monitoring, packet rejection, sanctions, compliance rates or any particular blocked communication.
• The public record does not provide the complete early contracts, host-table request files, disputed decisions, correction outcomes, override records, enforcement reports or remedies needed to establish either unrestricted NIC discretion or a public mandate extending to every outside network.

On 8 March 1974, the Network Information Center asked every ARPANET site to change a local host table. The instruction appeared in RFC 620, “Request for Monitor Host Table Updates”, issued by Bill Ferguson of SRI’s Augmentation Research Center. NIC services had moved to OFFICE-1, at network site 53 in octal notation. Site 2 remained SRI-ARC, but its nickname was to become ARC; the familiar nickname NIC was to point instead to site 53. The notice supplied exact entries for TENEX monitor tables and told sites running other operating systems to make equivalent changes.

RFC 620 records an instruction, not an observed compliance case. It identifies no individual operator carrying out the work, no site that failed to do so and no resulting outage. The operator is nevertheless a necessary role implied by the document: someone at each site had to alter the locally used mapping in the manner appropriate to that operating system. If a table remained stale, it would continue associating NIC with site 2 and could direct a name-based attempt away from the intended NIC service. That consequence follows from the mapping change, but the RFC does not report an actual failed lookup or misdirected connection.

The notice exposes the administrative structure behind a seemingly simple name. SRI could announce the new association, but the announcement did not rewrite every remote machine. A site had to receive the instruction, interpret it and modify its own system. Shared naming worked when the maintained record, the distribution channel and local implementation converged.

On 25 March 1974, RFC 627 announced a more regular distribution mechanism. The online ASCII file of official host names was available at OFFICE-1, whose address appeared as 43 in decimal notation, equivalent to the 53 octal used in RFC 620. The NIC would maintain the file and incorporate additions or changes weekly. Each network host was responsible for retrieving new information through the File Transfer Protocol. Changes, additions, corrections and comments could be directed to Elizabeth “Jake” Feinler through network mail, telephone or the NIC identification system.

Those two March documents do not preserve a complete request-to-decision transaction. They can, however, be combined with earlier and later records to establish a minimum composite reconstruction, provided that its dates remain separate.

In 1971, a host selected a preferred formal name through its liaison under the procedure proposed in RFC 273. The liaison transmitted the choice; the document does not establish that a technical liaison personally possessed authority to make every organisational decision for the site. The proposed naming scheme expected nicknames to be unique within the network community and contemplated discussion if duplicate or exceptionally long names were selected. It did not specify a NIC veto, a rejection test, a final decision rule, an override or an appeal.

In January 1974, RFC 608 described the official host name as a string obtained through negotiation between the host and the NIC. It established character and formatting constraints, identified Feinler’s NLS source file, and proposed periodic generation of a machine-readable ASCII edition. It did not explain how contested negotiations ended or who prevailed when discussion failed.

In March 1974, RFC 627 established the available file, weekly incorporation of updates, a correction channel and each host’s responsibility to fetch new information. Only in 1982 did RFC 810 explicitly state that the user of the DoD host table was responsible for translating it into whatever local format was required. It would be inaccurate to compress these 1971, 1974 and 1982 statements into one observed routine or to assign every step to the same official.

The defensible composite is therefore modest. A host communicated its preferred name through a liaison. Published conventions governed the form of that name, nickname uniqueness was expected, and duplicate or long choices could prompt discussion. SRI maintained a source from which it generated a common file. Sites retrieved the file and incorporated its contents into local systems. By 1982, the user’s responsibility for local translation was stated expressly. What happened when a proposed name remained disputed, when a correction was challenged or when a site rejected an instruction cannot be recovered from the procedural RFCs alone.

This is the first boundary in the host table’s authority. The common record could determine what name a participating system recognised without deciding whether the underlying computer existed, whether a physical line had been installed or whether an organisation had been admitted to the network. Its effects were operational and sometimes severe for name-based use, but they were not identical to control over all connectivity.

Four divergent tables and the case for a common file

The online host file addressed an observed coordination problem. In December 1973, RFC 606 described four accessible TENEX systems—SRI-ARC, BBN-TENEX, USC-ISI and PARC-MAXC—whose mappings between host names and addresses differed. None was complete, and the author believed each diverged in some respect from the official list.

That evidence should not be inflated into a claim that every ARPANET site had an inaccurate table. It establishes divergence at four named systems. Even that limited finding was enough to demonstrate the cost of separate maintenance. A person moving among those machines could encounter different answers. A program written against one local set could fail when moved to another. A newly added or renamed host might be recognised at one site while remaining unknown at another.

RFC 606 proposed a centrally generated, machine-readable file maintained by the NIC. It distinguished the two core facts in an entry—host name and host address—from optional attributes such as host status, protocol behaviour and nicknames. Its author warned that attributes need not be complete and should not replace protocol negotiation, word of mouth or other ways of discovering a host’s properties. The proposal was deliberately specific: it sought to solve incompatible local lists, not to establish a comprehensive constitution for network participation.

RFC 608 accepted the central-file idea and reported that it had support from ARPA’s Information Processing Techniques office. Feinler maintained the source in SRI’s NLS format, while a program was to generate the ASCII distribution file periodically. Initially, the generated entries would contain the official name, decimal host address and status. Other information could be added as data became available. The document also allowed a network prefix for hosts outside ARPANET, showing that the authors already contemplated a comparison set wider than the ARPANET host population. It does not identify every outside host actually included.

The distinction between source and distribution mattered. NLS was an SRI system used to maintain structured information. The ASCII edition was designed for retrieval and processing by heterogeneous hosts. SRI-ARC was the organisational and computing context from which several of these notices were issued, while OFFICE-1 became the machine serving NIC users and the published host file in March 1974. Later documents used SRI-NIC for the host providing the DoD table and name service. These labels mark technical and organisational changes; they should not be treated as interchangeable names for one unchanging machine.

RFC 627 converted the proposal into an announced service. It encouraged hosts to use the official names in their monitors and made each host responsible for retrieving the file. Nicknames were optional, and systems providing name-to-address translation were encouraged rather than required to use them. The document supplied channels for additions and corrections, but the existence of a channel does not prove the time taken, the evidence demanded or the remedy available when a request was refused.

The architecture remained distributed at the point of use. SRI maintained the reference file, but remote sites decided when to fetch it and how to install it. A recently corrected master could coexist with stale local copies. An operator could supplement an official file with a local alias. A person who knew a numeric address might bypass a missing name. The table reduced inconsistency without becoming the packet-switching subnet itself.

A wrong entry could still have material effects. A name-based program might direct traffic towards the recorded address rather than the intended machine. An absent entry could leave software unable to translate the requested name. A delayed local update could preserve an obsolete result. The exact behaviour depended on the local operating system and application. The RFCs do not justify a universal claim that every omission produced disconnection or that every inaccurate entry produced the same error.

The March relocation illustrates the narrower proposition. After NIC moved to OFFICE-1, a site that implemented RFC 620’s change would associate the nickname with site 53. A stale site could continue associating it with site 2. SRI’s service move occurred independently of the remote table, while the usefulness of the shared nickname depended on remote adoption. The record was consequential because other machines acted upon it.

Names began with hosts, not an unlimited NIC veto

The common file did not emerge from a settled rule that allowed the NIC to assign any name it wished. The 1971 RFC discussion records substantial disagreement about naming.

RFC 226 circulated a proposed set of mnemonics and invited objections. Competing suggestions followed. Some participants favoured short call signs; others wanted names that preserved institutional and project identities. The debate was not merely cosmetic. Names appeared in commands, documents and users’ habits. A naming rule therefore distributed inconvenience and recognition as well as characters.

In RFC 237, the NIC argued that it was a logical body to maintain the naming standard and proposed assigning names to new hosts once the Network Working Group had settled the syntax and current list. That was an institutional proposal by the service operator. It is evidence of what the NIC wanted its role to be, not evidence that every connected organisation or a superior public authority accepted the entire claim.

RFC 273 responded to the failure of previous proposals to achieve acceptance. It said hosts, through their liaisons, should choose their own formal names, possibly subject to discussion if they selected duplicate or extra-long names. Hosts at one institution were expected to use the same institutional mnemonic. A nickname should be unique within the network community.

The language establishes local choice and the possibility of central discussion. It does not define who could issue a final refusal. A duplicate would frustrate the purpose of a shared nickname, but technical incompatibility alone does not reveal the administrative remedy. The NIC might have persuaded a site to choose another name; a sponsor might have intervened; sites might have accepted an informal convention; or some disagreement might have remained unresolved. A complete case file would be needed to distinguish those possibilities.

RFC 289, issued in December 1971, reported that almost all sites had responded with desired names. Its title, “What We Hope Is An Official List of Host Names,” preserves the tentative character of the exercise. The emerging list reflected solicitation and site response within a bounded ARPANET community. It was neither a unilateral private invention nor the result of a worldwide public delegation.

The role of the liaison also requires care. RFC 273 used liaisons as the channel through which hosts chose and communicated names. A later Computer History Museum guide to the SRI ARC/NIC records says technical liaisons generally did not have authority to speak for site administration. The archive guide describes the later creation of a Host Administrator role whose holder could authorise site action. Because the guide spans a longer period, it cannot simply be projected backwards into every 1971 exchange. It does, however, warn against treating “liaison” as synonymous with institutional executive.

The most that can safely be said is that the host was the originating chooser in the published 1971 procedure, the liaison was the communication channel, and the NIC maintained the shared result. Syntax and expected uniqueness constrained what could function in the common namespace. The documents do not disclose a comprehensive adjudication system.

That limited discretion was still meaningful. Once a name appeared in documents and machine-readable files, users elsewhere could rely on it. A host could change its name, but doing so imposed costs on software, documentation and local knowledge. Stability became a source of practical authority. The centre did not need a broad legal power to make its maintained answer difficult to ignore.

ARPA’s service contract and the DCA handover

The institutional chain began with a federal research programme, not with the wider Internet.

ARPANET was a particular packet-switched network established through the Advanced Research Projects Agency within the United States Department of Defense. ARPA financed the research programme, selected contractors and supported participating research centres. The agency became the Defense Advanced Research Projects Agency in 1972. “ARPA” is therefore appropriate for the network’s establishment and the early naming debate, while “DARPA” appears in records from the later period.

The ARPANET Completion Report, prepared in 1978, says Stanford Research Institute received a contract to develop and operate a Network Information Center for ARPANET. Work began alongside implementation of the network in 1969. The report describes a service that maintained participant and distribution lists, archived technical documents, supplied information about host resources, provided access to SRI’s NLS system and maintained ARPANET protocol specifications.

This establishes a sponsor-contractor relationship. ARPA procured an information service for the network and research community it supported. SRI had a duty to perform whatever the contract required, and ARPA had the corresponding right to contracted performance. The public report does not reproduce the early statement of work, amendments, acceptance standards, sanctions, data clauses or host-name decision rules. It therefore cannot establish the full legal content of that duty.

The sites connected to ARPANET were institutionally diverse. They included universities, research institutes, government laboratories, military facilities and private contractors. Diversity of legal form did not make every site an unaffiliated public operator. Many participated through federal sponsorship, contracts or approved mission relationships. At the same time, the absence of the underlying site instruments prevents a claim that every connected organisation had an identical contractual clause requiring host-table compliance.

The strongest direct account of the transfer from ARPA to the Defense Communications Agency is staged and dated. The Completion Report describes an ARPA-DCA memorandum under which management of ARPANET transferred to DCA on 1 July 1975. It also records a six-month phase-over, lasting through 31 December 1975, during which ARPA continued assisting DCA while DCA took on the management role. A detailed transition plan had been completed by June.

The report says the transferred network was to operate as a DoD facility used for government business. DCA would finance operation and maintenance through a cost-allocation arrangement involving ARPANET sponsors. DCA was initially to contract with BBN and SRI for network operation, maintenance and NIC functions. The report says it was clearly implied that DCA could retain other contractors later, certainly after the first year.

That is evidence of institutional replaceability at the level of contractor selection. It does not prove that DCA possessed a complete portable copy of every NIC record, unlimited rights in contractor-created data, a tested transition package or an enforceable remedy for every service failure. A customer may be able to select another provider in principle while facing formidable practical obstacles in transferring staff knowledge, software, archives, current records and site relationships.

A 1978 DCA publication indexed as the ARPANET Information Brochure also gives 1 July 1975 as the management-transfer date. The later Computer History Museum finding aid presents a conflicting retrospective account: it says ARPANET operation was turned over to DCA in 1973 and that DCA contract funding supported the SRI NIC after 1974.

The conflict should remain visible. The formal memorandum chronology in the Completion Report supplies a precise transfer date and phase-over. The finding aid supplies different summary dates but not the underlying instrument that would reconcile them. It also says that the NIC became a separate project in 1973, which is a different institutional change from transfer of ARPANET management. Without the relevant contracts and administrative records, the 1973 operational statement and post-1974 funding statement cannot be converted into a single seamless chronology.

After the formal transfer, DARPA could continue sponsoring research that used ARPANET while DCA managed the operational network. DoD was the parent governmental environment; DARPA and DCA had different functions within it. SRI remained a contractor performing NIC services rather than becoming the government itself. Participating sites operated hosts. Host liaisons and later contact roles transmitted information and instructions. Keeping those roles distinct prevents procurement authority from being mistaken for universal authority.

Admission to ARPANET was not a host-table decision

The host table recorded machines within an operating environment, but SRI’s maintenance of the record did not make SRI the sole authority deciding who could join ARPANET.

The December 1978 ARPANET Directory described subscriber categories and the process for obtaining service. Its framework placed admission and sponsorship within DCA’s network-management structure. A prospective subscriber needed an acceptable governmental purpose, sponsorship and available facilities. Those decisions concerned access to a specific managed network.

The distinction is fundamental. DCA could administer ARPANET subscriber eligibility. SRI could maintain the directory and host information used after or around admission. A host-table entry might be necessary for convenient shared use, but recording the host was not the same institutional act as approving the organisation’s connection, installing an Interface Message Processor, supplying a circuit or authorising a mission.

The ARPANET population also should not be equated with the DoD Internet. ARPANET was one network. The DoD Internet was an internetworking environment in which ARPANET, packet-radio systems, satellite systems and other networks could use Internet protocols and common coordination information. The wider emerging Internet was broader still: a changing set of networks, experiments and operators whose legal, contractual and technical relationships were not uniform.

By September 1981, RFC 790 listed assigned Internet network numbers for numerous named networks, including ARPANET, UCLNET, CYCLADES, TELENET, the British Post Office EPSS, DATAPAC, TRANSPAC, LCSNET, TYMNET and an assortment of packet-radio, satellite, local and experimental systems. It identified Jon Postel at the University of Southern California’s Information Sciences Institute as the contact for network-number assignments.

The list proves that the assigned-number environment extended beyond a list of ARPANET hosts. It does not, by itself, establish that every named network was operationally interconnected at that moment, independent of government sponsorship, commercial, non-DoD or governed by the SRI host-table process. A number appearing in an assignment document is not a complete account of the network’s contractual status or actual traffic.

It also separates functions that later histories sometimes blur. Postel’s assigned-number role at USC-ISI concerned network and protocol parameters. SRI maintained the host table and name service. DCA managed ARPANET and commissioned the NIC service. DARPA continued research sponsorship. None of those facts makes one actor the sole author of the entire emerging Internet.

The phrase “first Internet ledger” therefore needs a defined comparison. The host table was not the first directory ever maintained by a computer organisation, nor was the 1974 file a registry for a worldwide public Internet. It was an early shared, machine-readable name-and-address reference in the ARPANET-to-Internet lineage. By 1982, its successor format incorporated networks, gateways and Internet addresses and was described by its operators as a global host name and address database. Its historical significance lies in the widening scope and cross-organisational dependence of that reference, not in a proven mandate over every network.

The 1982 DoD rule: a published precondition, not proved enforcement

RFC 810 marked a change in scope and institutional language. Issued on 1 March 1982 by Feinler, Ken Harrenstien, Zaw-Sing Su and Vic White of SRI International’s Network Information Center, it said the earlier ARPANET host table no longer met the needs of the DoD community or internetworking. The new format included network, gateway and host entries, Internet addresses, operating systems and protocol information.

The table was available from the SRI-NIC host through FTP and through the Host Name Server. The RFC identified the server as a service maintained by the ARPANET NIC on behalf of DCA. It also assigned translation responsibility expressly to the user: whoever consumed the table had to convert it into the format required locally.

Its seventh assumption contained the strongest operating language in the host-table record. Names and addresses for DoD networks, gateways and hosts were to be negotiated and registered with the NIC before being used and before traffic was passed by a DoD host. This was a published precondition governing DoD-host behaviour. It connected registration to operation more directly than the 1974 encouragement to use official host names.

The sentence does not document enforcement. RFC 810 does not identify a monitor that inspected registrations, a router rule that rejected unregistered traffic, a sanction for noncompliance, a compliance rate or a particular communication that was blocked. The difference matters. A specification can define required conduct without proving how consistently operators implemented it.

The document treated non-DoD information differently. For an interim period, the NIC would attempt to maintain similar information for non-DoD networks and hosts if that information was provided and for as long as it was needed, pending intercommunicating name servers. It neither identified every non-DoD entry actually included nor imposed the same express precondition on all outside operators.

The new format also had a staged introduction. RFC 810 specified 1 May 1982 as the cutover date. During May, the existing HOSTS.TXT path still held the old edition while a new-format test file was available separately. During June and July, the main path held the new format, while old-format material remained accessible through another path. After 1 August, the old HOSTS.TXT format specified by RFC 608 would no longer be supported.

That overlap distinguished a published design from immediate universal implementation. Programs had time to adapt. Local systems could remain on different editions during the transition. The schedule shows active management of compatibility risk, but it does not prove that every host completed conversion on time.

RFC 811, issued the same day, specified the online Hostnames Server. A program could query for a host name or address or request the entire table. The server could return host, gateway or network records. If a requested name was absent, the defined error took the form ERR : NAMNFD : Name not found :. Other errors were possible, including TMPSYS, meaning a temporary system failure and a request to try later.

Those semantics belong to the SRI-NIC server protocol. They should not be projected onto every local resolver using a downloaded copy. A local lookup against a table lacking an entry could fail, use a supplementary mapping, prompt a user or behave in another system-dependent way. The absence of a name from a local copy and a NAMNFD response from the server were related conditions, not necessarily identical events.

RFC 811 described its database as an extension of the old ARPANET HOSTS.TXT file and called central administration an interim solution on the way to a decentralised, distributed name-and-address translation service. That institutional claim is important for two reasons. It shows that SRI understood the service as a transition mechanism rather than a permanent architecture, and it confirms that the table’s population and purpose had expanded beyond the original ARPANET list. It does not independently prove universal coverage.

By the early 1980s, the NIC was increasingly associated with the Defense Data Network environment, and historical collections later use the name DDN-NIC for the service. That later label should not be carried backwards into the 1969 contract or the 1971 host-name debate. SRI-ARC, the SRI NIC, SRI-NIC and DDN-NIC describe connected but temporally distinct organisational and host contexts.

What the archive can show—and what remains missing

The RFC series is unusually rich in proposals, specifications and announcements. It is much weaker as a record of individual administrative cases.

The Computer History Museum finding aid identifies relevant collections: NIC proposals and contracts, progress reports, naming and addressing records, host tables, reference-service material, correspondence and records concerning official network contacts. It says the early NIC contract was not broken down into tasks and that later contracts became more elaborate. It also describes technical liaisons, Host Administrators, Node Site Coordinators and other contacts through whom information or action messages moved.

A finding aid establishes the existence, approximate subject and arrangement of records. It does not disclose the contents of every contract, letter or decision. Its descriptions cannot prove that a host-name request was granted, refused or escalated in a particular way. The underlying documents would need to be opened and compared.

No complete request file has been produced here showing a host’s proposed name, the NIC’s questions, the site’s response and the final disposition. No preserved case demonstrates a NIC refusal based on duplication, a successful appeal, a sponsor override or a correction remedy. No comprehensive register supplies processing times or error rates. RFC 627’s contact details prove that a correction channel existed; they do not prove the outcomes delivered through it.

The missing contracts matter for a separate reason. A federal contract can confer a right to performance without conferring ownership of every record, title to a technical system or unrestricted rights in contractor-created data. It may specify deliverables, data licences, transition assistance and remedies, but those consequences depend on its actual clauses.

A much later Government Accountability Office analysis of federal Internet-function arrangements carefully distinguished performance rights, data-use rights, title and ownership. That 2016 opinion concerned later DNS and IANA arrangements and does not supply the missing terms of SRI’s 1970s contracts. Its value here is methodological. Federal financing alone cannot be used to infer every property or transition right.

The Completion Report does support one narrower conclusion: DCA initially intended to retain SRI for the NIC function and could later use another contractor. That shows contemplated provider replaceability. It does not establish that replacement could occur without delay, data disputes, software conversion, lost institutional memory or service interruption.

Implementation records are also absent for RFC 810’s traffic condition. To move from published rule to demonstrated enforcement, one would want DCA directives, host software, audit logs, incident reports, sanctions or a documented blocked flow. Without that material, the article can identify the rule’s stated reach but not its observed force.

Silence must operate in both directions. The lack of a published appeal procedure does not prove that no informal escalation existed. Telephone calls, network mail, NLS exchanges and sponsor intervention may have resolved disputes without an RFC. Conversely, the lack of published complaints does not prove that every participant regarded the process as legitimate or that every update was timely.

The resulting uncertainty is institutional rather than merely antiquarian. If requests were routinely corrected through transparent site confirmation, the service would look more clerical and cooperative. If the NIC could refuse entries without explanation and no sponsor review existed, the same file would carry a different governance meaning. The public evidence does not support either extreme as a general account.

The local-list alternative and its real costs

A historically feasible alternative to the common file was not the modern Domain Name System. It was the practice already visible before RFC 606: each site maintained its own mappings, obtained changes through personal communication and translated remote information into its own operating system.

At four sites, this could be manageable. Administrators knew one another, protocol designers met regularly, and a correction could travel by telephone, document or network mail. A site could adopt a local alias without waiting for a central publication. If two organisations communicated frequently, they could keep their shared information current even when a central machine was unavailable.

The maintenance burden grew rapidly. With ten sites, each maintaining entries for the other nine, there could be up to 90 directed local mappings. With one hundred sites, there could be up to 9,900. These figures describe directed copies held at sites, not 90 or 9,900 distinct bilateral relationships. The number of mappings actually needed would depend on communication patterns, but every new destination created more places in which information could become stale.

A host addition or address change would have to reach multiple administrators. Each would apply it on a separate timetable and in a local format. A correction could be acknowledged by one site, missed by another and transformed incorrectly by a third. Operators would need to identify which edition they had, compare conflicting reports and determine whether an apparent service failure came from the network, the remote host or a stale mapping.

RFC 606 supplies the observed warning: the four named TENEX systems already had incomplete, divergent tables. It does not quantify failures caused by those differences. The divergence itself demonstrates duplicated maintenance and inconsistent answers.

A common source reduced that burden. The affected host could communicate information through one recognised channel. SRI could generate one edition. Sites could fetch the same file and compare their local state with a dated reference. A support operator investigating a discrepancy had a focal point from which to begin.

The common file did not remove all distribution costs. Each site still required storage, retrieval software, local conversion and an update routine. Weekly publication introduced delay between a reported change and its appearance in the next edition. Fetching could fail when the serving host or a network path was unavailable. Local installation could lag after successful retrieval. The architecture centralised compilation, not every operational task.

Nor did one common source guarantee truth. SRI depended on hosts and contacts to provide accurate information. A wrong address supplied by a site could enter the master. A correct central update could be undermined by stale local deployment. A conflict could persist if the procedure for deciding it was unclear. The reference made disagreement visible and reduced duplication, but it did not abolish the need for verification.

The local-list alternative explains why organisations deferred to the NIC file without requiring a theory of unlimited command. One maintained answer was cheaper to consume than many independently reconstructed ones. Software and documentation became more reliable when they used common names. The resulting dependence gave the maintained record operational force.

A common ledger with more than one distributor

A second period-feasible alternative would have preserved one canonical file while distributing storage and retrieval more widely.

The idea appeared in contemporary documents. RFC 623 proposed that the NIC retain the master while another host maintained a frequently updated secondary copy. Its author volunteered UCSB and suggested daily synchronisation. The purpose was availability: if the NIC host could not serve the file, users could try the secondary.

RFC 625 accepted the principle that more than one host should maintain a copy and welcomed UCSB as a prospective secondary. It disagreed with replacing FTP by a dedicated retrieval protocol. RFC 627, issued later in March, still invited any host wishing to maintain a secondary copy to contact the NIC.

These records establish a proposed and accepted replication design. They do not prove that UCSB or another host operated a functioning mirror. Confirmation would require an operational notice, server log, archived secondary file, host manual or later report. The proposal should not be rewritten as deployment.

Had such a secondary operated, it would have required period-appropriate resources. The site needed storage for the file, staff or automated procedures to retrieve updates, and a schedule frequent enough to keep its edition useful. Users needed to know which host to contact and how to recognise the latest canonical version. The secondary needed a rule for what to do when its local copy differed from SRI’s.

An outage could make reconciliation difficult. Suppose the secondary missed two updates while SRI remained available, then returned with an older edition. A timestamp or sequence convention would be needed to prevent users from mistaking availability for currency. If SRI was unavailable while a disputed correction arrived, the secondary would need to know whether it could publish the change or merely continue serving the last confirmed master.

Replication also left amendment authority unresolved. A mirror could distribute the canonical file without deciding entries. Giving it independent editing power would create the possibility of competing masters. Avoiding that problem required a clear division between the organisation attesting to its facts, the centre reconciling the shared namespace, the distributor serving copies and any reviewer handling disputes.

Site confirmation could have been strengthened without modern infrastructure. Before weekly publication, the NIC might have sent a proposed change to the affected liaison or authorised site contact. A dated change notice could have accompanied the generated file. Secondary keepers could compare the announced changes with the file they received. Sites could report discrepancies against a specific edition rather than an undated local copy.

Those procedures would have imposed costs. Contacts had to respond. Corrections could wait for confirmation. Staff had to maintain logs and reconcile unanswered requests. A host that changed rapidly might find a weekly cycle too slow, while more frequent distribution increased computation, network use and operator workload. Formal review could improve accountability while also delaying urgent corrections.

Contractor transition presented a larger problem. DCA’s ability to select another provider did not guarantee seamless replacement of SRI. A successor needed the current canonical file, software that generated it, documentation of formats and publication schedules, open requests, correction history, contact lists, staff knowledge and access to the serving environment. If the contract did not specify delivery or data-use rights, transfer could become legally as well as operationally difficult.

The surviving public documents do not establish whether those transition materials existed as enforceable deliverables. They show that a different contractor was contemplated, not that a tested transfer mechanism was in place. Replaceability on paper and continuity in operation were separate achievements.

This alternative clarifies the governance choice. A single logical answer did not require a single physical distributor. A canonical edition could coexist with mirrors, site confirmation, preserved changes and a replacement service provider. Each addition would have shifted cost and responsibility without eliminating the need for final coordination.

A dated authority chain, not a universal mandate

Between 1969 and 1983, the host table’s authority accumulated through a series of different relationships.

In 1969, ARPA procured a Network Information Center for ARPANET. That established a federal customer, an SRI contractor and a defined service population. It did not make SRI the representative of every computer network.

In 1971, hosts were invited to choose names through liaisons within published conventions. Debate and response among ARPANET participants supplied bounded peer acceptance. The NIC’s proposed role was narrowed by local choice, while the shared namespace still required compatible results.

In 1973 and early 1974, divergent local tables prompted a machine-readable common file. RFCs 606 and 608 documented the proposal and source design. RFCs 620 and 627 documented a specific site-wide change instruction, the available ASCII file, weekly updates, local retrieval responsibility and correction channels. They did not document a general NIC veto or complete dispute system.

On 1 July 1975, according to the ARPA-DCA memorandum described in the Completion Report, management of ARPANET transferred to DCA, followed by a phase-over through 31 December. DCA retained SRI initially for NIC functions and could contemplate another contractor. The finding aid’s conflicting 1973 operational-transfer statement and post-1974 funding account remain unresolved.

By 1978, DCA’s subscriber framework placed ARPANET admission within government network management rather than SRI host-table maintenance. This separated the authority to admit a subscriber from the service that recorded and distributed host information.

By 1981, the assigned-number environment listed many networks beyond ARPANET, while network-number assignment was identified with Postel at USC-ISI. Appearance in that list did not establish that every network shared one legal or operational relationship with DCA or the NIC.

In March 1982, RFC 810 specified a broader DoD Internet host table and published prior registration as a condition for names and addresses used in relation to traffic passed by DoD hosts. Its separate interim treatment of non-DoD information marked a boundary. The rule was explicit; its enforcement remains unproved. The May-to-August cutover further showed that specification, transition and completed local implementation were different stages.

RFC 811’s server made the maintained answer available through online queries and described the central database as an interim bridge to distributed naming. That service increased reliance on SRI-NIC while acknowledging that the architecture was not intended to remain permanently central.

The host table therefore exercised its strongest demonstrated authority in three places. SRI owed performance to its federal customer within the scope of a contract whose full terms are unavailable. DCA could issue operating requirements for the DoD environment it managed. Participating machines and users depended on the common record for consistent name-based communication.

Outside those relationships, the table’s reach arose from interoperability and adoption. An outside network might contribute information or use the common file because doing so made communication easier. That reliance was consequential, but RFC 810 did not describe it as equivalent to the DoD precondition. No reviewed record shows a worldwide constituency delegating general authority to SRI.

The table also did not create everything it recorded. The sponsor approved network participation; contractors and sites supplied machines and software; circuits and packet switches carried traffic; other authorities handled network numbers; local systems consumed the published mappings. The NIC’s record helped make a name commonly recognisable, but it did not create the underlying organisation, physical connection or every numeric assignment.

Its practical authority was nevertheless substantial. A shared record consumed by many machines can constrain conduct even when no legislature or public membership body created it. A host wanting predictable recognition had reason to follow the naming conventions. A site wanting current answers had reason to retrieve the common file. A DoD host was addressed by a published registration precondition. A non-DoD operator could find deviation costly because other systems expected the maintained answer.

What remains unproved is equally important. The surviving public evidence does not show that the NIC owned the addresses it listed, could exclude any outside network at will, imposed sanctions on every noncompliant site or converted every missing entry into physical disconnection. It does not reveal a complete appeal structure, correction remedy or override hierarchy. It does not establish portable government ownership of all NIC data.

The early host table was authoritative where procurement, network management and machine reliance met. It solved a concrete problem: incompatible local mappings made shared names unreliable. Central compilation made one answer easier to distribute, compare and use. That achievement explains why the record acquired force before names and addresses became market assets.

It does not prove that the operator of the record received authority over every network the record could describe. The historical chain supports a narrower conclusion: SRI maintained a federally commissioned reference for a sponsored network, that reference became embedded in DoD Internet operations, and wider reliance expanded its practical reach. The ledger’s usefulness made it powerful. Its public mandate remained unestablished.