Summary

  • SRI’s 1988 qualifications statement reported contract numbers, dates, funding and work, but public copies of the underlying contracts, modifications and statements of work have not been located, leaving the exact obligations, remedies and overlapping periods unresolved.
  • DCA procurement supported NIC services within the DDN and DoD chain, while DDN operating rules, IAB and DARPA domain policy, USC/ISI’s IANA delegation and outside reliance supplied separate, service-specific bridges that cannot be collapsed into a universal contractual mandate.
  • The 1991 handover shows that the operating provider changed while data, request channels and services were carried forward; it does not establish the missing procurement terms, transition duties, ownership, costs or remedies for outside users.

A contractor’s account of its own record

The most detailed public table of DDN-NIC contract numbers does not come from a signed Defense Communications Agency contract, a statement of work or a government inspection report. It appears in an SRI International document dated 27 October 1988 and prepared for an entirely different opportunity: Qualifications Statement for Solicitation F04701-88-R-0043: Technical Support for Global Positioning System Information Center. SRI’s Network Information Systems Center submitted the document to demonstrate that it could develop and operate a proposed civilian GPS information centre. Its discussion of DDN-NIC was corporate experience offered in support of that bid.

That provenance changes how every entry in the table must be read. SRI reported that DCA200-83-C-0025 ran from 1 June 1983 to 31 December 1985 and carried funding of $3,122,367. It reported DCA200-84-C-0024 as running from 15 June 1984 to 31 January 1987, with funding of $8,128,495. It listed DCA200-87-C-0020 for two annual periods beginning on 1 February 1987, with $3,772,115 for the first year and $4,121,252 for the second. The dates overlap. Public copies of the underlying contracts, modifications and statements of work have not been located, so the overlap cannot safely be explained as an option, a separate work package, a bridge arrangement or a change in contractual structure.

SRI also described eight areas of work, including core network information services; information and database protocols and architecture; network access control and user registration; the DDN and ARPANET audit-trail and billing system; naming and directory service for the DoD Internet; and operation of a government computer facility. It listed WHOIS, name service, domain registration, protocol distribution, a telephone hotline, user registration, online information services, publications and software. At the end of the table, SRI asserted that its deliverables had been completed without overruns.

These statements are useful evidence of what SRI represented about its experience in 1988. They are not independent findings that DCA purchased every listed activity under every reported contract, that the work met government acceptance criteria, or that every Internet user fell within the procurement’s covered population. SRI was describing itself to a prospective customer. The document’s purpose rewarded a comprehensive account of capability and successful performance. It did not provide the institutional distance of an audit or a contracting officer’s acceptance decision.

One part of the reported chain has separate federal corroboration. The National Technical Information Service catalogues the 1985 DDN Protocol Handbook, Volume 1: DoD Military Standard Protocols as an SRI DDN-NIC technical report produced under DCA200-83-C-0025. The NTIS record describes a handbook for implementers planning to attach computers to the Defense Data Network, including the ARPANET. It identifies the roles of DCA and the DDN Program Management Office in protocol standardisation and configuration management. This establishes that the contract number was associated with at least that documented product. It does not disclose the rest of the contract’s scope, its payment structure, its remedies or the rights of people who were not parties to it.

The evidentiary caution is especially important because the SRI qualifications statement marked some work on its 1988 organisation chart as not covered by the DCA contract. That annotation warns against treating everything performed in the same centre, by the same staff or on the same computers as part of one procurement. SRI’s DDN work, DARPA-related activity, technical-community responsibilities and internally funded development could coexist inside the Network Information Systems Center without sharing an identical legal basis.

The opening procurement question must therefore remain narrower than the surviving service inventory: what did DCA require SRI to deliver, to whom, and under what supervisory and remedial arrangements? The public evidence answers only parts of that question. It identifies the contracting agency, the contractor, three reported contract numbers and dates, at least one associated deliverable, and a substantial body of services operating during the period. It does not supply the signed instruments needed to reconstruct every obligation.

The purchasing chain that can be established

The principal institutional relationship is clear at a high level. The Department of Defense supplied the governmental setting. DCA administered the Defense Data Network and contracted with SRI for NIC work. SRI International was the contractor. DDN-NIC was the operating centre through which SRI supplied registration, information and assistance services. DDN facilities and documented ARPANET and MILNET users formed the population for which governmental operating authority is most clearly visible.

The Computer History Museum’s 2011 Guide to the SRI ARC/NIC Records describes the surviving archive as containing proposals, statements of work, contracts, modifications, correspondence, monthly progress reports and contract-deliverable reports. It says that by 1987 the NIC work consisted of numerous tasks with assigned task leaders and budgets. Formal monthly reports are described as continuing through 1991, while contract-deliverable reports cover 1980 through 1990. The finding aid therefore identifies the kinds of records normally associated with government contract administration: numbered instruments, task structures, budgets, reporting and modification files.

A finding aid is not the content of those files. It tells a researcher that records exist, how they are organised and, in some instances, how the archivist summarised them. It does not establish the wording of a statement of work, the government’s acceptance of a deliverable, the contractor’s entitlement to payment or the remedy for defective performance. The guide was written by Elizabeth Feinler, who had led the NIC project at SRI. Her knowledge makes it valuable as an archival map and institutional history, but it does not convert its summaries into audited findings or contracting-officer decisions.

The strongest evidence of services actually supplied comes from contemporaneous operating documents. RFC 811, issued in March 1982, described the Hostnames Server as one of a series of name services maintained by SRI’s NIC on behalf of DCA. RFC 954, published in October 1985, identified the NICNAME/WHOIS server in the same way. The NTIS handbook record connects a major DDN publication to one reported contract number. RFC 1032, issued by SRI in November 1987, said DCA had designated the NIC to provide domain-registry services for the DDN and DARPA portions of the Internet. By February 1991, RFC 1206 still identified SRI International as the operator of NIC.DDN.MIL, the repository for RFCs and Internet Drafts, a provider of DDN user assistance, the site of the Internet Registry and an operator of domain and WHOIS services.

Together, those documents show that SRI performed the described work. They identify functioning servers, mailboxes, telephone support, publications, databases and registration procedures. They do not reveal which service was charged to which contract line item. An RFC describing an operating rule cannot be promoted into a statement of work, just as the existence of a public server cannot prove a third party’s contractual entitlement to continued service.

The agency name changes near the end of the period. DCA retained that name until 25 June 1991, when Department of Defense Directive 5105.19 renamed it the Defense Information Systems Agency. Contemporary and later accounts sometimes use the two names loosely when discussing the transition, but the date matters. DCA is the correct agency name for the SRI contracts reported in 1983, 1984 and 1987. DISA is the correct name for the agency identified in the September 1991 operational handover notice.

There is a material gap between those points. SRI’s 1988 qualifications table gives 31 January 1989 as the end of the listed DCA200-87-C-0020 period. RFC 1206 demonstrates that SRI was still operating the DDN NIC in February 1991, and the archival guide describes monthly reporting through that year. No reviewed public instrument identifies the option, extension, bridge contract, modification or successor arrangement that supported the work from February 1989 to the 1991 handover.

The gap does not prove that SRI worked without a contract. It means the procurement vehicle has not been established from the documents available for review. A later operating description cannot supply a missing award number, and continued service does not reveal whether continuity rested on an exercised option, a modification to an existing agreement or another procurement.

What DCA rules made compulsory

Inside the DDN environment, DDN-NIC’s actions were connected to governmental operating authority by rules more specific than the contractor’s own standing.

RFC 810, published in March 1982, specified the DoD Internet host table and attributed its maintenance to the NIC on DCA’s behalf. Its treatment of DoD and non-DoD records was not symmetrical. Names and addresses for DoD networks, gateways and hosts were to be negotiated and registered with the NIC before use and before a DoD host passed traffic to them. For an interim period, the NIC would attempt to maintain similar information for non-DoD networks and hosts if it was supplied and remained necessary while intercommunicating name servers were developed.

This was an operating specification, not a contract. Even so, it identifies a concrete source of authority. A DoD host was subject to rules governing a network administered by a DoD agency. The NIC received and maintained the required record, but the operational consequence came from DCA’s position over the DoD network and its participating facilities. SRI did not need independent regulatory power over a military host when DCA could make registration part of the conditions under which that host used the network.

The 1985 DDN Protocol Handbook fits the same pattern. Its stated purpose was to guide implementers attaching machines to the DDN. The handbook explained DoD protocol requirements, configuration management, and the roles of DCA and the DDN Program Management Office. Its force over a covered facility came from the facility’s place within the DDN programme, not from the handbook’s public availability or SRI’s authorship.

RFC 954 provides another bounded example. WHOIS was accessible across the Internet, and DCA encouraged network hosts to make the service available to users. Its registration language, however, concentrated on people with accounts on ARPANET or MILNET hosts who could pass traffic across the DoD Internet. MILNET Terminal Access Controller users had to be registered. The document gave the registrar’s mailbox and telephone number, but it did not declare that every person using TCP/IP anywhere had to enter the DCA-backed directory.

The service could be both publicly useful and officially compulsory for a specified population. Public accessibility did not make all users contractual beneficiaries. Mandatory registration for a MILNET TAC user did not prove a comparable obligation for an employee of a foreign university network.

DCA oversight also appears in RFC 1032’s application instructions. If adopting a fully qualified domain name would change the official hostname of an ARPANET or MILNET host, the applicant had to obtain DCA approval beforehand and allow time for processing. The administrative bridge is visible: the affected host belonged to a DCA-administered environment; its proposed name changed an official record used in that environment; the NIC processed the request; and DCA approval was required.

No reviewed public instrument establishes that the same approval requirement governed every local hostname on every outside network. RFC 1032 instead assigned much local naming responsibility to domain administrators and disclaimed a central role in adjudicating private organisational disputes. DDN-NIC exercised real authority at a registration boundary without administering all conduct behind that boundary.

That arrangement was not inherently defective. A government agency can define operating requirements for its network, appoint a service provider, require covered users to submit accurate information and reserve approval over changes to official records. SRI’s competence made that design work at increasing scale. The unanswered question begins where a user was neither a DDN facility nor otherwise within the relevant government sponsorship chain.

The authority supplied by Internet policy

Procurement was not the only bridge between DDN-NIC and the broader Internet. The positive authority conferred by technical policy must be weighed on its own terms.

RFC 920, published in October 1984 by Jon Postel and Joyce Reynolds at USC/ISI, declared itself an official policy statement of the Internet Activities Board and DARPA. It defined requirements for establishing domains in the ARPA-Internet and DARPA research community. Domains needed responsible administrators, reliable name service and registration within the hierarchy. The NIC was listed as agent for the initial top-level domains. DARPA was identified as administrator for ARPA, GOV, EDU, COM and ORG; the DDN Program Management Office was administrator for MIL.

This was a meaningful designation. An organisation seeking a second-level domain under a NIC-administered top-level domain had to work through the registration structure. The administrator of the higher level had to be satisfied that the applicable requirements were met before authorising the new domain. Applicants were expected to identify responsible contacts, describe their name servers and supply other operational information. Without an accepted delegation in the shared hierarchy, the proposed name would not be published through that hierarchy’s root data.

RFC 920 also divided authority rather than concentrating it indiscriminately. The owner of a host chose which domain to seek entry into, while a domain administrator chose which hosts to accept. Their agreement formed the administrative basis for the host’s position in the namespace. Administrators controlled names within their own domains and could delegate responsibility farther down the tree. The NIC’s central role coexisted with substantial local control.

The document expressly contemplated institutional replacement. It observed that other entities might be more appropriate agents or registrars for some domains and that responsibility should then be reassigned. It also said permanent NIC administration of every top-level domain was not desired. The IAB and DARPA were establishing a workable initial arrangement, not declaring SRI irremovable.

By November 1987, RFC 1032 described the implementation in more developed form. It said the NIC had been designated by DCA to provide registry services for the domain system on the DDN and DARPA portions of the Internet. It identified the NIC as registrar for top- and second-level domains, administrator of root-server zone files on behalf of DARPA and DDN, and temporary administrator of several named top-level domains until suitable organisations could assume them.

A prospective domain administrator obtained a questionnaire, supplied the required organisational and technical details and returned the completed form to HOSTMASTER at SRI. The guide said the application had to be complete before the NIC would authorise establishment of the domain. It also described alternative registration arrangements under which CSNET and UUCP management organisations processed applications for their communities and passed relevant information to the NIC for incorporation into the central database and root files.

This procedure supplied DDN-NIC with service-specific operational authority. The NIC could require a complete application before adding a delegation to the root data it administered. It could apply naming format and classification rules within the top-level domains placed in its charge. An applicant seeking entry into those domains had to follow the applicable registration process.

That authority did not derive solely from DCA’s procurement relationship with SRI. It rested on a combination of IAB and DARPA policy, DCA’s designation of the NIC for documented portions of the Internet, the hierarchy’s allocation of responsibility and an applicant’s request for inclusion. Nor was it unlimited. RFC 1032 treated many name choices as local matters. It said the NIC would not decide which disputing party had the underlying right to register a name for an organisation. Conflicts were to be resolved before registration, while the NIC confined itself to technical guidance and processing.

The limits did not make the registration decision inconsequential. A domain omitted from the common root could not expect normal resolution by systems following that root. A delayed or inaccurate delegation could impose substantial costs. But those consequences arose from a controlled registration service within a widely adopted hierarchy. No reviewed public instrument establishes that the registration process also gave SRI general authority over an applicant’s internal network, employment decisions, contractual relations or traffic policies.

Numbers, IANA and the Internet Registry

Internet-number administration followed another institutional path. The distinction between USC/ISI’s IANA function and SRI’s Internet Registry function is essential because the same staff mailbox could otherwise appear to derive all authority from the DCA procurement.

RFC 1020, published by SRI personnel in November 1987, announced that Hostmaster at DDN-NIC had assumed responsibility for assigning IP network numbers and autonomous-system numbers. It acknowledged continuing assistance from Jon Postel and Joyce Reynolds at USC/ISI. The document was an official status report listing assigned identifiers; it did not reproduce the agreement that transferred the operating work.

RFC 1174 supplied the contemporary policy account in August 1990. It described the IANA function as being performed at USC/ISI and stated that IANA had discretionary authority to delegate portions of identifier responsibility. For network and autonomous-system numbers, it said that responsibility had been lodged with the Internet Registry operated by SRI at DDN-NIC. SRI was therefore more than a passive recipient of forms. Within the accepted technical arrangement, it was the principal registry for those identifiers.

That delegation was a positive authority bridge. It explains why an organisation outside the DDN purchasing population might nevertheless submit a number request to DDN-NIC and treat the result as authoritative. The applicant wanted a globally unique identifier recognised by the common Internet coordination system. USC/ISI’s IANA function had placed the relevant registration responsibility with SRI. Other operators consulted and reused the registry’s assignments to avoid collisions.

The bridge still had defined edges. RFC 1174 kept IANA and the Internet Registry institutionally distinct. USC/ISI performed the central IANA function; SRI performed the registry work delegated to it. The IAB recommended that the registry allocate blocks to approved regional organisations and that further assignment authority be distributed internationally. DDN-NIC was to remain a default registry where no delegated registry existed, while aggregate copies of registration data would be shared to improve access and redundancy.

RFC 1174 does not establish the complete contractual basis for IANA’s relationship with DARPA, DCA or SRI. Its statement that IANA possessed discretionary delegation authority records the policy arrangement recognised by the IAB. It is not a substitute for the missing DARPA and DCA agreements. The US Government Accountability Office encountered a comparable evidentiary problem in 2016 when examining government property interests in historic Internet functions: key contracts from the 1970s through the 1990s could not be obtained, preventing confident conclusions about the rights those agreements had conveyed.

The institutional account is therefore layered. DoD agencies funded important facilities and functions. DCA procured NIC services for the DDN. DARPA and the IAB supplied policy for the research Internet and the emerging domain system. USC/ISI performed IANA and delegated number-registration work. SRI operated the Internet Registry and DDN-NIC. Applicants complied with the registration process because they sought recognised identifiers. Network and DNS operators then used the resulting data.

Each layer mattered. None supplies the complete authority of all the others.

Rice University: a snapshot, not a transaction file

Rice University illustrates both the reach of the registry and the limits of the surviving case evidence.

RFC 1020 lists RICE-NET at 128.42 and categorises it as a research network. RFC 1032 uses a WHOIS response for rice.edu as an example of how a domain administrator could verify registration data. The displayed record identifies Rice University, its contacts and its domain servers. These records establish that Rice-related number and domain information appeared in DDN-NIC publications and services in November 1987.

They do not reveal Rice’s original application, the identity of the official who submitted it, its funding relationship, its connection path, its exchanges with Hostmaster or the time required for processing. They do not show a disputed request, a rejection, an override, a formal approval notice or an appeal. RFC 1020 does not mark RICE-NET as one of the independent networks identified by an asterisk, so it would also be unsafe to describe Rice as an unaffiliated outside network on that basis.

RFC 1032’s registration instructions are generic. Their presence beside a Rice WHOIS example does not prove that Rice followed every described step in the form shown or that a particular correspondence produced the displayed entry. The number listing and WHOIS output are registry snapshots. The procedure is a published procedure. They cannot be assembled into a transaction narrative without the missing correspondence.

The operational consequence of the records can be described only at the system level. An allocated number gave the shared registry a unique identifier to publish for RICE-NET. A valid domain delegation enabled systems using the common DNS hierarchy to learn which servers were authoritative for rice.edu. The documents do not establish that any particular packet was routed, that Rice gained physical connectivity from DDN-NIC or that another network was compelled to carry Rice traffic.

No reviewed public instrument establishes a complete outsider dispute from 1983 through 1991 in which an identifiable non-contracting applicant submitted a domain or number request to DDN-NIC, received a contested decision, sought review and obtained a documented outcome. That is a limit on the available analysis, not evidence that disputes never occurred. Without such a file, it is not possible to test how SRI explained an adverse decision, whether DCA or USC/ISI reviewed it, what remedy existed or whether the applicant had an enforceable entitlement.

What can be established is the generic handling path published by the NIC. A domain applicant supplied contacts, server information, network addresses and other operational details. NIC personnel checked the submission for completeness and conformity with the applicable hierarchy. Acceptance allowed the delegation to be incorporated into registry and root-server data. A number applicant sought an identifier from the Internet Registry. Assignment created a recognised entry but did not itself provide interconnection.

RFC 1020 made the latter separation explicit. It recorded number assignments for networks connected to the research or operational Internet and for independent IP networks. Administrators of independent networks still had to seek separate permission to interconnect. Identifier assignment, registry publication and network access were different decisions.

The Rice material therefore proves neither compulsion nor insignificance. It shows an educational institution represented in a central registry with identifiers that mattered to interoperability. It does not show the legal relationship through which Rice entered or an occasion on which DDN-NIC exercised contested power over it.

Oversight without an opened remedy clause

The archival record indicates that purchaser-side administration records existed, but the public material reviewed here does not disclose the full remedy structure.

The Computer History Museum finding aid describes contracts arranged by number and then by document type, including statements of work, proposals, modifications, email and correspondence. It identifies formal monthly progress reports and contract-deliverable reports. It says the 1987 work was divided into tasks with separate leaders and budgets. These are descriptions of archival categories, not findings about the contents or legal effect of each document.

They do not identify the consequences of missed service levels. No reviewed public instrument establishes a cure period, withholding right, fee adjustment, termination standard, transition-assistance clause or damages remedy under the relevant SRI arrangements. SRI’s 1988 assertion that all deliverables had been met without overruns cannot fill that gap. It is the contractor’s performance representation, not an acceptance determination signed by DCA.

The finding aid also summarises episodes involving document production, an expenditure associated with the VOID database and the SAM personal-computer mail project. Those summaries indicate that the archive contains material about funding questions, government concerns and decisions affecting SRI work. The underlying correspondence, contract modifications, budget decisions and contracting-officer actions have not been reviewed. The episodes therefore cannot be presented as verified audits, formal enforcement actions or remedies available to registration applicants.

The same limit applies to the finding aid’s reference to an anonymous complaint associated with SAM. An archivist’s summary can identify a research lead. It does not establish the complaint’s exact allegations, the contractual task involved, the authority of the person who received it, DCA’s response or the conditions under which work stopped or resumed. It was not, in any event, a documented appeal by a domain or number applicant.

Even if purchaser-side controls were fully documented, they would answer only part of the accountability question. A government customer may possess contractual remedies against its supplier. An outside network using a publicly accessible service does not automatically acquire the same rights. Its position would depend on an agreement, a recognised beneficiary status, an administrative undertaking or another source of entitlement.

RFC 1032 provided mailboxes, a telephone hotline and correspondence with Hostmaster. It offered technical guidance and anticipated exchanges needed to complete an application. It did not describe an independent tribunal for rejected requests. Its policy of leaving local name disputes to the parties was a boundary on NIC decision-making, not an appeal system. No reviewed public instrument establishes damages, service credits or a formal review right for an overseas or commercial network affected by an SRI registration decision.

The uncertainty cuts both ways. The absence of an opened appeal clause does not prove that no complaint procedure existed. It also prevents a claim that outside users enjoyed contractual continuity or procedural protection. Public dependence may have grown faster than the formal rights visible in the surviving record.

Technical policy did include mechanisms for distributing responsibility. RFC 920 allowed registrar roles to be reassigned to more appropriate entities. RFC 1032 distributed administration down the DNS hierarchy and declined to centralise local disputes. RFC 1174 proposed further delegation of number registration and wider replication of registry data. These were not contractual remedies or judicial review, but they show that the architecture did not require one contractor to remain the sole operating centre indefinitely.

The 1990 reconsideration of reach

By 1990, the Internet’s population no longer matched the governmental and research communities for which earlier procedures had been designed. RFC 1174 described growth into industry, academia and non-US networks and proposed changes to both identifier assignment and the meaning of “connected” status.

The document did not recommend abolishing central coordination. It proposed retaining IANA and the Internet Registry while distributing blocks of identifiers to other qualified registries. DDN-NIC would continue as the principal and default registry, aggregate data would remain centralised for updating, and copies would be shared. This was a reform of central administration, not a denial that DDN-NIC possessed operational authority.

Its treatment of connected status is equally important. Earlier practice associated Internet connection with approval by a US government sponsoring organisation. RFC 1174 recommended removing that status from registry forms and databases, allowing registered networks into DNS without regard to a single connection classification and recording each network’s access, transit and acceptable-use policies instead.

The proposal recognised a boundary that procurement alone could not manage. A network number could be globally unique without entitling its holder to use a particular backbone. A domain could appear in DNS without requiring every operator to route traffic to it. A federally sponsored network could enforce its access criteria on traffic crossing its facilities. Other networks could make their own interconnection and transit decisions.

RFC 1174 also said it was inappropriate to require every non-US network to follow US access and use criteria. Federal criteria could govern traffic using federally sponsored networks. This responded directly to international growth: control over a supplied facility did not automatically become control over all registered networks.

The registry still exercised consequential power. It decided whether an identifier request conformed to its procedures, recorded assignments, maintained the database and supplied information used by other operators. DNS inclusion was important enough for the IAB to recommend separating it from government-sponsored connection status. That recommendation would have been unnecessary if registry decisions had no effect.

Outside reliance was not voluntary in a frictionless sense. An organisation wishing to interoperate broadly faced strong pressure to obtain unique numbers and recognised DNS delegations. Choosing a conflicting address or an unrecognised root could isolate it from systems it wanted to reach. The common registry had network effects, accumulated expertise and the support of influential governmental and technical institutions.

Those effects did not all arise from SRI’s DCA contracting relationship. The bridge for number registration was IANA delegation and the applicant’s participation in the common identifier system. The bridge for domain registration was the IAB and DARPA policy structure, DCA’s documented designation, the DNS hierarchy and the applicant’s request for inclusion. The bridge for DDN operating rules was use of the DDN and the relevant governmental relationship. The bridge for traffic carriage was the policy of the network being used. No reviewed public instrument establishes that SRI’s procurement contract fused these relationships into one general authority over every relying operator.

The missing years and the 1991 handover

The last phase of the chronology contains both the clearest demonstration of continuity and the largest procurement uncertainty.

SRI’s reported DCA200-87-C-0020 period ended on 31 January 1989. Contemporary RFCs show that SRI continued to operate DDN-NIC in 1990 and early 1991. The archive guide describes progress reports through 1991. No reviewed public instrument identifies the contract, option, modification or bridge award that supported the continuation. The procurement basis for the period from February 1989 to the 1991 transfer therefore remains unresolved.

On 25 June 1991, DCA became DISA. In September, RFC 1261 announced that the Network Information Center would move from SRI International in Menlo Park to Government Systems Inc. in Chantilly on 1 October. It identified services then offered to both DDN and Internet users: network and user registration, network-number and top-level-domain assignment, online information services, help-desk operations, and RFC and Internet-Draft archives and distribution.

The notice was written by Scott Williamson and Leslie Nobile of Network Solutions. It stated that SRI would continue answering calls and requests through 30 September. The WHOIS database would not be changed from 26 through 30 September while registration actions were suspended and the master database was transferred to GSI. Mail and fax requests were to use the new GSI address; electronic messages sent to familiar Hostmaster and Registrar mailboxes would continue and be redirected as appropriate. Registration activity would resume on 1 October. The new NIC used a Sun 470 SPARCserver running SunOS 4.1, replacing the prior TOPS-20 environment.

These details establish an operational provider handover. Data moved. Addresses, telephone numbers and computing infrastructure changed. Requests were suspended, redirected and resumed. The notice also establishes that DISA and GSI were publicly associated with the transition and that Network Solutions personnel participated in implementing or communicating the successor service.

A 1998 federal district-court opinion, Thomas v. Network Solutions, supplied a later legal account. The court reported that Network Solutions had obtained a subcontract under a procurement contract awarded to GSI by DISA and that its duties included domain registration and IP-number assignment. A separate 2000 federal opinion quoted a sworn account by National Science Foundation official George Strawn describing Network Solutions as GSI’s subcontractor supporting the DDN and Internet under a DISA contract.

Those later accounts support a high-level prime-and-subcontractor description: DISA as the government agency, GSI as the holder of the procurement relationship and Network Solutions as a subcontractor performing registry work. They do not disclose the award number, solicitation, selection record, signed prime contract or subcontract. They also contain retrospective summaries that should not displace RFC 1261’s contemporaneous account of the 1 October operational transfer.

No reviewed public instrument establishes whether GSI’s selection resulted from a recompetition, an ordinary successor award or another procurement mechanism. No reviewed public instrument supplies a termination clause for SRI, a transition-assistance obligation, government ownership of the registry data, software-licence terms, service levels, migration costs or rights held by outside users. The movement of the master database shows that transfer occurred. It does not prove the contractual rule that required or permitted the transfer.

The handover should not be made to carry more legal meaning than its evidence allows. It demonstrates that the operating provider changed while services, mailboxes, master records and public expectations were carried forward. It does not demonstrate why SRI was legally required to cooperate, who owned each software component, which party bore the transition costs or what remedy an external registrant would have had if the transfer failed.

The service population also requires care. RFC 1261 addressed both DDN and Internet users, proving that the operational transition was designed around a community wider than military facilities. That statement does not establish that all those users were contractual beneficiaries. A government can purchase a service made publicly available without granting every user a right to enforce the procurement.

The observable achievement was substantial. Registration activity was paused for a defined period rather than abandoned. The master database was transferred, communication channels were redirected and services were scheduled to resume under a new operator. The transition made dependence visible because continuity required deliberate technical work. It also demonstrated that the operation could be handed from SRI to another provider.

What survived the transfer cannot be attributed confidently to any single legal source. The service names survived. Familiar electronic addresses were redirected. Registry data were carried forward. Users were told to expect minimal impact. Yet no reviewed public instrument establishes whether those outcomes followed contractual transition duties, government property rights, cooperation negotiated for the occasion, professional practice or some combination of them.

The counterfactual raised by the procurement record must therefore remain precise. If DCA or DISA had replaced SRI while outside networks continued relying on the registry, the surviving documents show that operational continuity would have required movement of data, redirection of requests, communication with users and preservation of recognised identifier records. They do not establish which party could legally compel those actions, which data or software were government property, what payment accompanied the transfer, or which users could demand performance.

Different evidence could change that answer. The SRI contract and its modifications might identify government-furnished property, data-delivery requirements, termination assistance or continuing obligations. A successor solicitation and GSI award might define the service population, transition milestones and acceptance conditions. The Network Solutions subcontract might identify the actual division of labour. None of those terms can be inferred from the fact that the handover succeeded.

RFC 1261 is nonetheless important because it demonstrates that outside reliance was an operational concern rather than an abstract possibility. The notice spoke to DDN and Internet users, anticipated disruption, preserved familiar electronic request paths and scheduled a short database freeze. The service was being managed as shared infrastructure even though the legal position of every outside user is not disclosed in the notice.

Practical dependence and its limits

By the late 1980s, DDN-NIC sat at the intersection of several forms of dependence. Some were direct consequences of governmental operating rules. Others came from technical delegation, hierarchy and common adoption.

For a covered DDN, ARPANET or MILNET user, the relevant obligation could be explicit in an operating specification or management instruction. A host might have to register its official name, obtain approval for a change or supply accurate user information because the network’s governmental administrator required it. SRI handled the record, but the binding relationship ran through the government-administered facility.

For a domain applicant outside that population, the immediate consequence came from the shared namespace. A complete application and compliant name-server arrangement were conditions for a delegation under the relevant top-level domain. DDN-NIC’s role was supported by IAB and DARPA policy, DCA’s designation for the DDN and DARPA portions, and the hierarchical authority assigned to registrars and domain administrators. The applicant’s incentive was recognised resolution through the common system.

For a number applicant, RFC 1174 identified a different bridge: USC/ISI’s IANA function had lodged network-number and autonomous-system registration responsibility with SRI’s Internet Registry. The value of the assignment arose from uniqueness and recognition across participating systems. It did not by itself create a route, a connection or permission to use a federally sponsored backbone.

For an operator consulting registry records, dependence could be indirect. The operator used published numbers, names and contacts because coordination reduced collisions and made communication workable. That reliance could make an error at the registry consequential even without a direct contract between the operator and SRI. It still did not mean that every policy decision of the operator had been delegated to the registry.

These relationships are not interchangeable. Formal scope concerns the population and tasks identified by a governmental arrangement. Technical dependency concerns whether a system can function conveniently or reliably without a common record. Interoperability convention concerns the shared practices by which independent systems recognise identifiers. Institutional acceptance concerns the weight operators give to assignments endorsed by established technical bodies. Inherited reliance concerns dependence that accumulates because earlier participants built around the service.

The evidence is strongest when it identifies the exact bridge. RFC 810 tied registration to the conditions under which DoD hosts exchanged traffic. RFC 920 tied domain establishment to the policy and hierarchy of the ARPA-Internet and DARPA research community. RFC 1032 tied authorisation to a complete application and the responsibilities of domain administration. RFC 1174 tied number registration to IANA delegation while separating registration from connected status and routing policy. RFC 1261 showed that service continuity for DDN and Internet users required a managed operational transfer.

No reviewed public instrument establishes that one of these bridges silently contained all the others. A domain application was not a general agreement to obey every DDN rule. A network-number assignment was not permission to use every backbone. Reliance on WHOIS did not make the querying operator a contractual beneficiary. Publication in a shared database did not transfer control of an organisation’s internal network to SRI.

The converse is also true. The absence of a universal procurement clause does not make the NIC’s decisions optional in every practical sense. An organisation seeking a recognised domain under a NIC-administered top-level domain could not simply ignore the registrar’s procedure and expect the same delegation to appear in the shared hierarchy. A network seeking a unique number from the delegated Internet Registry had to submit to its assignment process. The authority was narrow, but it was real where the service boundary was real.

This is why contractor status is neither an accusation nor a complete explanation. SRI could deliver a competent, trusted and widely relied-upon service under government sponsorship. Its staff could exercise substantial judgement in checking applications, maintaining data, coordinating contacts and operating servers. The governance question is not whether that work mattered. It is which principal authorised each action, which users were covered by that principal’s rules, and which additional institutions connected the service to people outside the purchasing chain.

What the title can safely mean

The evidence supports a bounded answer to three separate questions.

Inside the DDN and DoD chain, DCA had a documented governmental role and SRI was a documented contractor. Operating specifications and manuals required registration or approval for defined DDN, ARPANET and MILNET activities. DDN-NIC processed records, maintained services and communicated procedures on DCA’s behalf. The force of those actions came from DCA’s administration of the network and the obligations of covered facilities. Because the relevant statements of work and remedy clauses remain unavailable, the exact contractual perimeter cannot be reconstructed.

Outside that purchasing population, organisations accepted and depended on several services. They sought unique identifiers from the Internet Registry, applied for domains in the shared hierarchy, queried WHOIS, obtained RFCs and relied on root-server data. Their reasons included IANA delegation, IAB and DARPA policy, DCA’s limited designation, applicant compliance with registration procedures, technical interoperability, accumulated trust and the practical cost of departing from a widely used system. Those bridges gave DDN-NIC real authority over particular registration decisions.

Authority over a registry entry was not authority over every associated institution or network. Domain administrators retained responsibility within their domains. IANA remained distinct from the Internet Registry. DCA and DARPA had different institutional roles. Identifier assignment did not supply interconnection. DNS inclusion did not command every route. A backbone’s acceptable-use policy applied through use of that backbone, not merely through appearance in a central database.

No reviewed public instrument establishes a universal bridge by which DCA’s purchase of SRI services, on its own, bound every non-contracting network that used the resulting records. Nor does the absence of such an instrument erase the narrower authority supplied by IAB policy, DARPA sponsorship, IANA delegation, hierarchy rules and applicant participation.

The procurement record is too incomplete to support a larger legal conclusion. Actual contracts could reveal more: a broader purchased population, interagency commitments, data rights, transition requirements or defined remedies. An outsider application file could show how a contested decision was handled. Until those instruments are produced, duties, rights and remedies cannot be reverse-engineered from RFCs, archive summaries or later institutional histories.

In that disciplined sense, DDN-NIC was a contractor, not a constitution. The phrase does not mean the centre lacked authority or legitimacy. It means contractor status explains the delivery of a government-backed service and some of the power exercised within the purchasing chain, while authority elsewhere must be traced through additional, service-specific relationships.

That account gives DDN-NIC proper credit. SRI operated important infrastructure during a period of rapid institutional and technical change. Its staff maintained registries, directories, publications, support channels and servers used beyond the narrowest military population. The services were sufficiently valuable that their 1991 transfer required suspension of registration actions, movement of the master database, redirection of requests and a coordinated change of host infrastructure.

The governance lesson lies in that combination of achievement and incomplete documentation. Successful administration can become common infrastructure before the rights of every relying party are visible in public records. Technical dependence can give a contractor great practical influence. It does not remove the need to identify the principal, the delegated function, the covered population, the review mechanism and the boundary beyond which another institution must supply authority.

Sources