摘要

  • SRI 1988 年的资格声明报告了合同编号、日期、资金和工作内容，但未能找到相关基础合同、修改条款和工作说明的公开副本，因此确切的义务、补救措施和重叠时段仍未明确。
  • DCA 的采购支持了 DDN 和国防部体系内的 NIC 服务，而 DDN 操作规则、IAB 和 DARPA 的域名政策、USC/ISI 的 IANA 授权以及外部依赖则提供了各自独立的、针对特定服务的桥梁，这些无法被归结为一个普遍的合同性授权。
  • 1991 年的交接表明运营提供商发生了变更，而数据、请求渠道和服务得以延续；但这并不能确立缺失的采购条款、过渡义务、所有权、成本或对外部用户的补救措施。

承包商对自己记录的说明

DDN-NIC 合同编号最详细的公开表格并非来自签署的国防通信局合同、工作说明或政府检查报告，而是出现在一份日期为 1988 年 10 月 27 日、为完全不同的机会准备的 SRI International 文件中：应征建议书 F04701-88-R-0043 的资格声明：全球定位系统信息中心的技术支持。SRI 的网络信息系统中心提交该文件是为了证明其能够开发并运营一个拟议的民用 GPS 信息中心。其中关于 DDN-NIC 的讨论是作为支持该投标的公司经验提供的。

这一出处改变了表格中每一条目的解读方式。SRI 报告称 DCA200-83-C-0025 合同期限为 1983 年 6 月 1 日至 1985 年 12 月 31 日，资金额为 3,122,367 美元。报告称 DCA200-84-C-0024 合同期限为 1984 年 6 月 15 日至 1987 年 1 月 31 日，资金额为 8,128,495 美元。将 DCA200-87-C-0020 列为自 1987 年 2 月 1 日起的两个年度期，第一年为 3,772,115 美元，第二年为 4,121,252 美元。这些日期存在重叠。由于未能找到基础合同、修改条款和工作说明的公开副本，因此无法安全地将这种重叠解释为可选条款、独立的工作包、过渡安排或合同结构的变更。

SRI 还描述了八个工作领域，包括核心网络信息服务；信息和数据库协议与体系结构；网络访问控制和用户注册；DDN 和 ARPANET 审计跟踪和计费系统；国防部互联网的命名和目录服务；以及政府计算机设施的运营。它列出了 WHOIS、名称服务、域名注册、协议分发、电话热线、用户注册、在线信息服务、出版物和软件。在表格末尾，SRI 声称其交付物已全部完成，且未超支。

这些陈述是 SRI 在 1988 年对其经验所作表述的有用证据，但它们并非独立调查结果，不能证明 DCA 根据每一份报告的合同购买了所有列出的活动，不能证明工作满足政府验收标准，也不能证明每个互联网用户都处于该采购覆盖的人群范围内。SRI 是在向潜在客户描述自己。该文件的目的鼓励对能力和成功绩效进行全面陈述，但它并不具备审计或合同官员验收决定所需的制度距离。

报告链条的其中一部分得到了独立的联邦佐证。美国国家技术信息服务处将 1985 年的《DDN 协议手册，第一卷：国防部军用标准协议》归类为 SRI DDN-NIC 根据合同 DCA200-83-C-0025 制作的技术报告。NTIS 记录将该手册描述为面向计划将计算机连接到国防数据网（包括 ARPANET）的实施者的指南，并指出了 DCA 和 DDN 项目管理办公室在协议标准化和配置管理方面的角色。这至少确立了该合同编号与这一记录在案的产品相关联，但它并未披露合同的其他范围、支付结构、补救措施或非合同当事方的权利。

这种证据方面的审慎尤为重要，因为 SRI 的资格声明在其 1988 年的组织结构图中将某些工作标记为不在 DCA 合同覆盖范围内。这一注释提醒我们，不能将在同一中心、由同一员工或在相同计算机上完成的所有工作都视为一次采购的一部分。SRI 的 DDN 工作、与 DARPA 相关的活动、技术社区责任以及内部资助的开发项目可以在网络信息系统中心内部共存，而无需共享相同的法律基础。

因此，最初的采购问题必须比现存的服务清单更为狭义：DCA 要求 SRI 交付什么、向谁交付、以及在何种监督和补救安排下交付？公开证据只能回答该问题的部分内容，它确定了签约机构、承包商、三个报告的合同编号和日期、至少一件相关的交付物以及在期间运营的大量服务，但它并未提供重建每一项义务所需的已签署文件。

可以确立的采购链条

主要的制度关系在高层面上是清晰的。美国国防部提供了政府环境。DCA 管理国防数据网，并就 NIC 工作与 SRI 签约。SRI International 是承包商。DDN-NIC 是运营中心，SRI 通过它提供注册、信息和协助服务。DDN 设施以及记录在案的 ARPANET 和 MILNET 用户构成了政府运营权限最为明显可见的人群。

计算机历史博物馆 2011 年的《SRI ARC/NIC 记录指南》描述现存的档案包含建议书、工作说明、合同、修改条款、信函、月度进度报告和合同交付物报告。它指出，到 1987 年，NIC 工作已包含众多任务，并配备了指定的任务负责人和预算。据描述，正式的月度报告一直持续到 1991 年，而合同交付物报告则覆盖 1980 年至 1990 年。因此，该检索工具确定了通常与政府合同管理相关的记录类型：编号文件、任务结构、预算、报告和修改档案。

检索工具并非这些文件的内容本身。它告诉研究者记录存在、如何组织，并在某些情况下，档案管理员如何对其进行了概括。但它不能确立工作说明的措辞、政府对交付物的验收、承包商的收款权利或对缺陷履行的补救措施。该指南由曾领导 SRI NIC 项目的 Elizabeth Feinler 编写。她的知识使其作为档案地图和制度历史具有价值，但并不能将其摘要转化为经审计的调查结果或合同官员的决定。

关于实际提供服务的强有力证据来自同期运营文件。1982 年 3 月发布的 RFC 811 将主机名服务器描述为 SRI 的 NIC 代表 DCA 维护的一系列名称服务之一。1985 年 10 月发布的 RFC 954 以同样的方式标识了 NICNAME/WHOIS 服务器。NTIS 手册记录将一份重要的 DDN 出版物与一个报告的合同编号联系起来。1987 年 11 月由 SRI 发布的 RFC 1032 指出，DCA 已指定 NIC 为 DDN 和 DARPA 部分的互联网提供域名注册服务。到 1991 年 2 月，RFC 1206 仍然将 SRI International 标识为 NIC.DDN.MIL 的运营者、RFC 和互联网草案的存储库、DDN 用户协助的提供者、互联网注册处的站点以及域名和 WHOIS 服务的运营者。

这些文件共同表明 SRI 执行了所描述的工作。它们标识了运行中的服务器、邮箱、电话支持、出版物、数据库和注册程序，但并未揭示哪项服务对应哪个合同细目。描述操作规则的 RFC 不能被提升为工作说明，正如公共服务器的存在不能证明第三方对持续服务的合同性权利一样。

该时期末，机构名称发生了变化。DCA 一直保留该名称直到 1991 年 6 月 25 日，彼时国防部指令 5105.19 将其更名为国防信息系统局（DISA）。同期和后期的叙述在讨论过渡时有时会混用这两个名称，但日期至关重要。对于 1983、1984 和 1987 年报告的 SRI 合同，正确的机构名称是 DCA。对于 1991 年 9 月运营交接通知中标识的机构，正确的名称是 DISA。

这些时间点之间存在一个实质性的空白。SRI 1988 年的资格表将 1989 年 1 月 31 日列为所列 DCA200-87-C-0020 的结束日期。RFC 1206 证明 SRI 在 1991 年 2 月仍在运营 DDN NIC，而档案指南描述了贯穿该年度的月度报告。经审查的公开文件中，没有一份能指明支持从 1989 年 2 月到 1991 年交接之间工作的选择权、延期、过渡合同、修改或后续安排。

这一空白并不证明 SRI 在没有合同的情况下工作。它意味着采购工具尚未从可供审查的文件中得以确立。后来的运营描述不能补全缺失的授予编号，而持续的运营并不能揭示这种延续是基于已行使的选择权、对现有协议的修改还是其他的采购。

DCA 规则强制的范围

在 DDN 环境中，DDN-NIC 的行动通过与承包商自身地位无关的更具体规则，联结于政府运营权限。

1982 年 3 月发布的 RFC 810 详细规定了国防部互联网主机表，并将其维护工作归于代表 DCA 的 NIC。它对国防部和非国防部记录的处理并不对等。国防部网络、网关和主机的名称和地址，必须在使用前以及国防部主机向它们传递流量之前与 NIC 协商并进行注册。在过渡期内，对于非国防部网络和主机，如果提供了类似信息，且在开发互通名称服务器期间仍有必要，NIC 将尝试维护这些信息。

这是一份操作规范，而非合同。即便如此，它指明了一个具体的权力来源。国防部主机须遵守管理由国防部机构运营的网络的规则。NIC 接收并维护所需的记录，但操作后果源于 DCA 对国防部网络及其参与设施的管理地位。当 DCA 可以将注册作为该主机使用网络的条件之一时，SRI 并不需要对军用主机拥有独立的监管权力。

1985 年的《DDN 协议手册》也符合同一模式。其声明的目的是指导将机器连接到 DDN 的实施者。该手册解释了国防部协议要求、配置管理以及 DCA 和 DDN 项目管理办公室的角色。它对所覆盖设施的强制力源于该设施在 DDN 项目中的位置，而非手册的公开可用性或 SRI 的作者身份。

RFC 954 提供了另一个有边界的例子。WHOIS 在整个互联网上均可访问，DCA 鼓励网络主机向用户提供该服务。然而，其注册用语集中于在 ARPANET 或 MILNET 主机上拥有账户、能够在国防部互联网上传递流量的用户。MILNET 终端访问控制器用户必须注册。该文件提供了注册商的邮箱和电话号码，但并未宣称任何地方使用 TCP/IP 的所有人都必须加入 DCA 支持的目录。

该服务可以对特定人群兼具公共用途和官方强制性。公共可访问性并不使所有用户成为合同受益者。MILNET TAC 用户的强制注册并不能证明对外国大学网络的员工存在同等的义务。

DCA 的监督也出现在 RFC 1032 的申请指南中。如果采用完全限定域名会改变 ARPANET 或 MILNET 主机的官方主机名，申请人必须事先获得 DCA 批准并留出处理时间。行政管理桥梁是明显的：受影响的主机属于 DCA 管理的环境；其提议的名称会改变该环境中使用的官方记录；NIC 处理请求；且需要 DCA 的批准。

经审查的公开文件中，没有一份能确定同样的批准要求适用于每个外部网络上的每一个本地主机名。相反，RFC 1032 将大量本地命名责任分配给了域名管理员，并声明不在裁决私人组织纠纷中扮演核心角色。DDN-NIC 在注册边界上行使了实际权力，但并未管理该边界之后的所有行为。

这种安排本身并非存在缺陷。一个政府机构可以为其网络定义操作要求、指定服务提供商、要求覆盖范围内的用户提交准确信息，并保留对官方记录变更的审批权。SRI 的能力使得这一设计在日益扩大的规模上得以运作。尚未解答的问题始于用户既非 DDN 设施、也不在相关政府资助链条内的情况。

互联网政策提供的权力

采购并非 DDN-NIC 与更广阔互联网之间的唯一桥梁。技术政策所赋予的积极权力必须根据其自身条件加以权衡。

1984 年 10 月由 USC/ISI 的 Jon Postel 和 Joyce Reynolds 发布的 RFC 920，声明自己是互联网活动委员会和 DARPA 的官方政策声明。它定义了在 ARPA- 互联网和 DARPA 研究社区中建立域名的要求。域名需要有负责的管理员、可靠的名称服务，并在层级中进行注册。NIC 被列为初始顶级域名的代理机构。DARPA 被认定为 ARPA、GOV、EDU、COM 和 ORG 的管理者；DDN 项目管理办公室是 MIL 的管理者。

这是一项有实际意义的指定。寻求在 NIC 管理的顶级域名下注册二级域名的组织，必须通过该注册架构操作。上级域名的管理员必须确信已满足适用要求，才会授权新域名。申请人需指定负责联系人、描述其名称服务器并提供其他操作信息。在共享层级中没有被接受的授权，所提议的名称将不会通过该层级的根数据发布。

RFC 920 还划分了权力，而非不加区分地集中权力。主机的所有者选择要进入的域名，而域名管理员选择要接受哪些主机。他们的协议构成了主机在命名空间中位置的行政管理基础。管理员控制自己域名内的名称，并可将责任向下级委托。NIC 的中心角色与大量的本地控制并存。

该文件明确设想了制度的更替。它指出，对于某些域名，其他实体可能是更合适的代理或注册机构，责任应随之重新分配。它还表示，并不希望 NIC 永久管理每一个顶级域名。IAB 和 DARPA 正在建立一个可行的初步安排，而非宣布 SRI 不可替换。

到 1987 年 11 月，RFC 1032 以更成熟的形式描述了实施情况。它指出 NIC 已被 DCA 指定为 DDN 和 DARPA 部分互联网的域名系统提供注册服务。它将 NIC 标识为顶级和二级域名注册机构、代表 DARPA 和 DDN 的根服务器区域文件管理员，以及若干指定顶级域名的临时管理员，直至有合适的组织可以承担这些职责。

潜在的域名管理员会获取一份问卷，提供所需的组织和技术细节，并将填写完整的表格返回给 SRI 的 HOSTMASTER。该指南指出，申请必须完整，NIC 才会授权建立域名。它还描述了替代性的注册安排，根据这些安排，CSNET 和 UUCP 管理组织为其社群处理申请，并将相关信息传递给 NIC，以便纳入中央数据库和根文件。

这一程序赋予了 DDN-NIC 针对特定服务的运营权力。NIC 可以要求完整的申请，然后才将授权添加到其管理的根数据中。它可以在其负责的顶级域名内应用命名格式和分类规则。寻求进入这些域名的申请人必须遵循适用的注册流程。

这一权力并非仅仅源自 DCA 与 SRI 的采购关系。它建立在 IAB 和 DARPA 政策、DCA 对 NIC 管理互联网特定部分的指定、层级结构的责任分配以及申请人的纳入请求等组合之上。而且，这一权力并非没有限制。RFC 1032 将许多名称的选择视为地方事务。它表示，NIC 不会裁决争执的哪一方拥有为某个组织注册名称的底层权利，冲突应在注册之前解决，而 NIC 仅限于提供技术指导和处理。

这些限制并未使注册决定变得无关紧要。一个在公共根中被遗漏的域名，不能指望由遵循该根的系统进行正常解析。延迟或不准确的授权可能会带来巨大的成本。但这些后果源于在一个被广泛采用的层级结构中受控的注册服务。经审查的公开文件中，没有一份能证明该注册过程也赋予了 SRI 对申请人内部网络、雇佣决策、合同关系或流量政策的普遍权力。

号码、IANA 与互联网注册处

互联网号码管理遵循另一条制度路径。USC/ISI 的 IANA 职能与 SRI 的互联网注册处职能之间的区分至关重要，因为否则相同的员工邮箱可能会让人觉得所有权力都源自 DCA 采购。

1987 年 11 月由 SRI 人员发布的 RFC 1020 宣布，DDN-NIC 的 Hostmaster 已承担分配 IP 网络号和自治系统号的职责。它确认继续得到 USC/ISI 的 Jon Postel 和 Joyce Reynolds 的协助。该文件是一份罗列已分配标识符的官方状态报告；它并未复制转让运营工作的协议。

RFC 1174 在 1990 年 8 月提供了当代的政策说明。它将 IANA 职能描述为在 USC/ISI 执行，并指出 IANA 拥有将部分标识符责任委托的自由裁量权。对于网络号和自治系统号，它表示该责任已交给了由 SRI 在 DDN-NIC 运营的互联网注册处。因此，SRI 不仅仅是表单的被动接收者。在公认的技术安排内，它是这些标识符的主要注册机构。

这一授权构成了积极的权力桥梁。它解释了为什么 DDN 采购人群之外的组织仍可能向 DDN-NIC 提交号码请求并将结果视为权威。申请人想要一个被公共互联网协调系统认可的全球唯一标识符。USC/ISI 的 IANA 职能已将相关的注册责任交给了 SRI。其他运营者查阅并复用注册处的分配，以避免冲突。

这座桥梁仍有明确的边界。RFC 1174 保持了 IANA 与互联网注册处在制度上的区分。USC/ISI 执行中央 IANA 职能；SRI 执行委托给它的注册工作。IAB 建议注册处将地址块分配给经认可的区域组织，并将进一步的分配权在国际上分布。在不存在委托注册处的地区，DDN-NIC 将继续作为默认注册处，同时注册数据的聚合副本将被共享，以改善访问性和冗余度。

RFC 1174 并未确立 IANA 与 DARPA、DCA 或 SRI 关系的完整合同基础。其关于 IANA 拥有自由裁量委托权的陈述，记录了 IAB 认可的政策安排，但这并不能替代缺失的 DARPA 和 DCA 协议。美国政府问责署在 2016 年审查政府对历史性互联网功能的财产权益时，也遇到了类似的证据问题：无法获得 1970 年代至 1990 年代的关键合同，从而无法就这些协议所转让的权利得出可靠的结论。

因此，制度性的叙述是分层的。国防部机构资助了重要设施和功能。DCA 为 DDN 采购了 NIC 服务。DARPA 和 IAB 为研究互联网和新兴的域名系统提供政策。USC/ISI 执行 IANA 职能并委托号码注册工作。SRI 运营互联网注册处和 DDN-NIC。申请人遵守注册流程，因为他们寻求被认可的标识符。网络和 DNS 运营者随后使用由此产生的数据。

每一层都很重要。但没有一层能提供其他所有层的完整权力。

莱斯大学：一张快照，而非交易档案

莱斯大学既说明了注册处的覆盖范围，也显示了现存案例证据的局限性。

RFC 1020 将 RICE-NET 列在 128.42，并归类为研究网络。RFC 1032 使用了rice.edu的 WHOIS 响应作为域名管理员验证注册数据的示例。显示的记录标识了莱斯大学、其联系人和域名服务器。这些记录证明与莱斯大学相关的号码和域名信息在 1987 年 11 月出现在 DDN-NIC 的出版物和服务中。

但它们并未揭示莱斯大学最初的申请、提交申请的官员身份、其资金关系、连接路径、与 Hostmaster 的交流或处理所需的时间。它们没有显示有争议的请求、拒绝、否决、正式批准通知或申诉。RFC 1020 并未将 RICE-NET 标记为以星号标识的独立网络之一，因此基于此将莱斯大学描述为无附属关系的外部网络也是不安全的。

RFC 1032 的注册指南是通用的。它在莱斯大学 WHOIS 示例旁出现，并不能证明莱斯大学遵循了所示形式中描述的每一步，或者特定的通信产生了显示的条目。号码列表和 WHOIS 输出是注册处的快照。程序是已发布的程序。在缺少相关通信的情况下，它们无法被组合成一份交易叙事。

这些记录的操作后果只能在系统层面描述。分配的号码为共享注册处提供了一个发布给 RICE-NET 的唯一标识符。有效的域名授权使得使用公共 DNS 层级结构的系统能够了解哪些服务器对rice.edu具有权威性。这些文件并未确定任何特定的数据包被路由，莱斯大学从 DDN-NIC 获得了物理连接，或者其他网络被迫承载莱斯大学的流量。

经审查的公开文件中，没有一份能确立一个从 1983 年到 1991 年间的完整外部纠纷案例，其中可识别的非合同申请人向 DDN-NIC 提交了域名或号码请求，收到了有争议的决定，寻求审查并获得了记录在案的结果。这是现有分析的局限，而非证明纠纷从未发生过的证据。没有这样的档案，就无法检验 SRI 如何解释不利决定、DCA 或 USC/ISI 是否进行了审查、存在何种补救措施，或者申请人是否拥有可强制执行的权益。

能够确立的，是 NIC 发布的通用处理路径。域名申请人提供联系人、服务器信息、网络地址和其他操作细节。NIC 人员检查提交材料的完整性及其与适用层级结构的一致性。接受后，授权便被纳入注册处和根服务器数据中。号码申请人向互联网注册处寻求标识符，分配创建了一个被认可的条目，但其本身并不提供互联互通。

RFC 1020 明确作出了后一种区分。它记录了连接到研究或运营互联网的网络以及独立 IP 网络的号码分配。独立网络的管理员仍然需要寻求单独的许可才能互联。标识符分配、注册处发布和网络访问是不同的决策。

因此，莱斯大学的材料既不能证明强制，也不能证明无关紧要。它展示了一个教育机构在中央注册处中拥有对互操作性至关重要的标识符。但它并没有显示莱斯大学进入的法律关系，或者 DDN-NIC 对其行使有争议权力的情形。

缺乏公开补救条款的监督

档案记录表明存在采购方管理记录，但本文审查的公开材料并未披露完整的补救结构。

计算机历史博物馆的检索工具描述了按编号排列、再按文件类型排列的合同，包括工作说明、建议书、修改条款、电子邮件和信函。它标识了正式的月度进度报告和合同交付物报告，并称 1987 年的工作被划分为多项任务，配有单独的负责人和预算。这些都是对档案类别的描述，并非对每份文件内容或法律效力的调查结果。

它们没有说明服务水平不达标的后果。经审查的公开文件中，没有一份能确立相关 SRI 安排下的纠正期、扣款权、费用调整、终止标准、过渡协助条款或损害赔偿补救措施。SRI 在 1988 年声称所有交付物均已达成且未超支，这无法填补这一空白。那是承包商的绩效陈述，而非 DCA 签署的验收决定。

该检索工具还概括了涉及文件制作、与 VOID 数据库相关的支出以及 SAM 个人电脑邮件项目的事件。这些概括表明档案中含有关于资金问题、政府关切以及影响 SRI 工作的决策的材料。但相关的信函、合同修改、预算决策和合同官员的行动尚未经过审查。因此，这些事件不能被呈现为经核实的审计、正式的执法行动或注册申请人可获得的补救措施。

同样的限制也适用于该检索工具提及的一起与 SAM 相关的匿名投诉。档案管理员的概括可以指明一个研究线索，但它不能确立投诉的确切指控、涉及的合同任务、接收者的权限、DCA 的回应或工作停止或恢复的条件。无论如何，这都不是一份由域名或号码申请人提交的记录在案的申诉。

即使采购方的控制措施被完整记录，它们也只能回答问责问题的一部分。政府客户可能拥有针对其供应商的合同补救措施。使用公开可访问服务的外部网络并不会自动获得同样的权利，其地位将取决于协议、被认可的受益者身份、行政承诺或其他权利来源。

RFC 1032 提供了邮箱、电话热线和与 Hostmaster 的通信。它提供技术指导，并预见了完成申请所需的交流，但它并未描述一个针对被拒请求的独立裁决机构。其将本地名称争议留给当事方的政策是对 NIC 决策权的一种边界限制，而非上诉系统。经审查的公开文件中，没有一份能确立因 SRI 注册决策而受影响的海外或商业网络享有损害赔偿、服务积分或正式审查权利。

这种不确定性是双向的。缺乏公开的上诉条款并不能证明不存在投诉程序，同时它也阻止了外部用户享有合同连续性或程序保护的主张。公众的依赖性可能比现存记录中可见的正式权利增长得更快。

技术政策确实包含了分配责任的机制。RFC 920 允许将注册商角色重新分配给更合适的实体。RFC 1032 将管理权沿 DNS 层级下放，并拒绝将本地争议集中化。RFC 1174 提议进一步委托号码注册和更广泛地复制注册数据。这些并非合同补救措施或司法审查，但它们表明该架构并不要求一个承包商无限期地作为唯一的运营中心。

1990 年对覆盖范围的重新考量

到 1990 年，互联网的人口构成已不再与早期的程序所设计的政府和研究社区相匹配。RFC 1174 描述了向工业界、学术界和非美国网络的扩展，并提议对标识符分配以及“已连接”状态的含义进行修改。

该文件并未建议废除中央协调。它提议保留 IANA 和互联网注册处，同时将标识符块分配给其他合格的注册机构。DDN-NIC 将继续作为主要和默认的注册处，聚合数据仍将集中进行更新，副本将被共享。这是对中央管理的一次改革，而非否认 DDN-NIC 拥有运营权力。

它对已连接状态的处理同样重要。早期的实践将互联网连接与美国政府资助组织的批准相关联。RFC 1174 建议从注册表单和数据库中移除此状态，允许已注册的网络在无需考虑单一连接分类的情况下进入 DNS，并记录每个网络的访问、传输和可接受使用政策。

该提案承认了仅凭采购无法管理的边界。网络号可以是全球唯一的，但并不赋予其持有者使用特定骨干网的权利。域名可以出现在 DNS 中，而不要求每个运营者向其路由流量。联邦资助的网络可以对穿越其设施的流量执行其访问标准，而其他网络则可以自行做出互联和传输决策。

RFC 1174 还指出，要求每个非美国网络都遵循美国的访问和使用标准是不合适的。联邦标准可以管理使用联邦资助网络的流量。这直接回应了国际增长：对所提供的设施的控制并不会自动变为对所有已注册网络的控制。

注册处仍然行使着重要的权力。它决定标识符请求是否符合其程序、记录分配情况、维护数据库并提供其他运营者使用的信息。DNS 包含的重要性足以让 IAB 建议将其与政府资助的连接状态分离。如果注册处的决定没有效果，这项建议就毫无必要。

外部依赖并非无摩擦意义上的自愿行为。一个希望广泛互操作的组织面临着巨大的压力，需要获取唯一的号码和被认可的 DNS 授权。选择一个冲突的地址或未被承认的根，可能会使其与想要连接的系统隔离开来。公共注册处具有网络效应、积累了专业知识，并得到了有影响力的政府和技术机构的支持。

这些影响并非全部源于 SRI 与 DCA 的合同关系。号码注册的桥梁是 IANA 的授权以及申请人对公共标识符系统的参与。域名注册的桥梁是 IAB 和 DARPA 的政策结构、DCA 的记录在案的指定、DNS 层级结构以及申请人的纳入请求。DDN 操作规则的桥梁是对 DDN 的使用以及相关的政府关系。流量承载的桥梁是所使用的网络的政策。经审查的公开文件中，没有一份能证明 SRI 的采购合同将这些关系融合为对每个依赖运营者的普遍权力。

缺失的年份与 1991 年的交接

时间线的最后阶段既包含了最清晰的连续性证明，也包含了最大的采购不确定性。

SRI 报告的 DCA200-87-C-0020 合同期于 1989 年 1 月 31 日结束。同期的 RFC 显示 SRI 在 1990 年和 1991 年初继续运营 DDN-NIC。档案指南描述了贯穿 1991 年的进度报告。经审查的公开文件中，没有一份能指明支持该项延续的合同、选择权、修改或过渡授予。因此，从 1989 年 2 月到 1991 年移交之间的采购基础仍未解决。

1991 年 6 月 25 日，DCA 变更为 DISA。同年 9 月，RFC 1261 宣布网络信息中心将从门洛帕克的 SRI International 迁至尚蒂伊的 Government Systems Inc.，自 10 月 1 日起生效。它标识了当时向 DDN 和互联网用户提供的服务：网络和用户注册、网络号和顶级域名分配、在线信息服务、帮助台运营以及 RFC 和互联网草案的存档与分发。

这份通知由 Network Solutions 的 Scott Williamson 和 Leslie Nobile 撰写。它指出 SRI 将继续接听电话和处理请求，直至 9 月 30 日。在 9 月 26 日至 30 日期间，WHOIS 数据库将不作更改，同时注册活动暂停，主数据库转移至 GSI。邮件和传真请求需使用新的 GSI 地址；发送至熟悉的 Hostmaster 和 Registrar 邮箱的电子信息将继续接收，并酌情进行重定向。注册活动将于 10 月 1 日恢复。新的 NIC 使用一台运行 SunOS 4.1 的 Sun 470 SPARCserver，取代了先前的 TOPS-20 环境。

这些细节确立了运营提供商的交接。数据发生了迁移。地址、电话号码和计算基础设施发生了变化。请求被暂停、重定向和恢复。该通知还确定 DISA 和 GSI 与该过渡公开关联，并且 Network Solutions 人员参与了后续服务的实施或沟通。

1998 年的一份联邦地区法院意见书Thomas v. Network Solutions提供了后来的法律陈述。法院报告称，Network Solutions 根据 DISA 授予 GSI 的采购合同获得了一份分包合同，其职责包括域名注册和 IP 号码分配。另一份 2000 年的联邦意见书引用了一份由国家科学基金会官员 George Strawn 提供的宣誓陈述，该陈述将 Network Solutions 描述为 GSI 的分包商，根据 DISA 合同为 DDN 和互联网提供支持。

后来的这些陈述支持了一种高层次的业主与分包商描述：DISA 为政府机构，GSI 为采购关系持有者，Network Solutions 为执行注册工作的分包商。但它们并未披露授予编号、招标书、甄选记录、已签署的主合同或分包合同。它们还包含回顾性摘要，这些摘要不应取代 RFC 1261 对 10 月 1 日运营转移的同期描述。

经审查的公开文件中，没有一份能确定 GSI 的选定是源于重新竞争、普通的后续授予还是其他采购机制。没有一份能提供 SRI 的终止条款、过渡协助义务、政府对注册数据的所有权、软件许可条款、服务水平、迁移成本或外部用户持有的权利。主数据库的迁移表明转移确实发生了，但这并不能证明要求或许可该转移的合同规则。

不应让这场交接承载超出其证据所能允许的法律意义。它表明运营提供商发生了变化，而服务、邮箱、主记录和公众期望得以延续，但它并未说明为什么 SRI 在法律上必须予以配合、谁拥有每个软件组件、哪一方承担了过渡成本，或者如果交接失败，外部注册人将拥有何种补救措施。

服务对象的构成也需要审慎对待。RFC 1261 同时面向 DDN 和互联网用户，证明运营过渡是围绕一个比军事设施更广泛的社区设计的。但这一陈述并未确定所有这些用户都是合同受益者。政府可以购买公开提供的服务，而不赋予每位用户强制履行采购合同的权利。

可观察到的成就是实质性的。注册活动在规定的期限内暂停，而非被放弃。主数据库被转移，通信渠道被重定向，服务计划在新运营商下恢复。这场过渡使依赖性变得可见，因为连续性需要刻意的技术工作，也证明了运营可以从 SRI 移交给另一个提供商。

能够从移交中幸存下来的东西，并不能自信地归因于任何单一的法律来源。服务名称幸存了下来。熟悉的电子地址被重定向。注册数据被向前承继。用户被告知预期影响将最小化。然而，经审查的公开文件中，没有一份能确定这些结果是遵循了合同过渡义务、政府财产权、为此场合谈判达成的合作、专业惯例还是它们的某种组合。

因此，采购记录所引发的反事实推理必须保持精确。如果 DCA 或 DISA 在外部网络继续依赖注册处的情况下替换了 SRI，那么现存文件显示，运营的连续性将需要数据的迁移、请求的重定向、与用户的沟通以及被认可标识符记录的保存。但它们并未确定哪一方可以依法强制执行这些行动、哪些数据或软件属于政府财产、移交伴随何种付款，或者哪些用户可以要求履行。

不同的证据可能会改变这一答案。SRI 的合同及其修改条款可能会指明政府提供的财产、数据交付要求、终止协助或持续义务。后续的招标书和 GSI 的授予可能会定义服务对象、过渡里程碑和验收条件。Network Solutions 的分包合同可能会指明实际的分工。这些条款无一能从交接成功这一事实中推断出来。

尽管如此，RFC 1261 仍很重要，因为它表明外部依赖是一个运营方面的关切，而非抽象的可能性。该通知面向 DDN 和互联网用户，预见到中断，保留了熟悉的电子请求路径，并安排了一次短暂的数据库冻结。即使该通知未披露每个外部用户的法律地位，该服务也正作为共享基础设施被管理。

实际依赖及其局限

到 1980 年代末，DDN-NIC 处于几种依赖形式的交叉点。有些是政府操作规则的直接后果，另一些则来源于技术授权、层级结构和普遍采用。

对于受覆盖的 DDN、ARPANET 或 MILNET 用户而言，相关义务可能在操作规范或管理指令中明确表述。主机可能必须注册其正式名称、为更改获得批准或提供准确的用户信息，因为网络的政府管理者要求如此。SRI 处理记录，但约束关系是通过政府管理的设施运作的。

对于该人群之外的域名申请人而言，直接的后果来自共享命名空间。完整的申请和符合要求的名称服务器设置是在相关顶级域名下获得授权的条件。DDN-NIC 的角色得到了 IAB 和 DARPA 政策、DCA 对 DDN 和 DARPA 部分的指定，以及分配给注册机构和域名管理员的层级权力的支持。申请人的动机是通过公共系统获得可识别的解析。

对于号码申请人而言，RFC 1174 指明了一座不同的桥梁：USC/ISI 的 IANA 职能已将网络号和自治系统注册责任交给了 SRI 的互联网注册处。分配的价值源于唯一性以及在参与系统间的可识别性，但其本身并不创建路由、连接或使用联邦资助骨干网的许可。

对于查阅注册处记录的运营者而言，依赖可能是间接的。运营者使用已发布的号码、名称和联系人信息，因为协调减少了冲突并使通信可行。这种依赖可能使得注册处的错误产生严重后果，即使运营者与 SRI 之间并无直接合同。但这仍不意味着运营者的每项政策决策都已委托给了注册处。

这些关系并非可互换的。正式范围关乎政府安排所确定的人群和任务。技术依赖关乎系统在没有公共记录的情况下是否能便捷或可靠地运行。互操作惯例关乎独立系统据以识别标识符的共享实践。制度接受度关乎运营者对已建立技术机构所认可的分配所赋予的分量。继承性依赖关乎因早期参与者围绕该服务构建而积累起来的依赖性。

当证据指明了确切的桥梁时，其证明力最强。RFC 810 将注册与国防部主机交换流量的条件绑定。RFC 920 将域名建立与 ARPA- 互联网和 DARPA 研究社区的政策及层级结构绑定。RFC 1032 将授权与完整的申请以及域名管理的责任绑定。RFC 1174 将号码注册与 IANA 授权绑定，同时将注册与已连接状态和路由政策分离。RFC 1261 表明，DDN 和互联网用户的服务连续性需要一次有管理的运营转移。

经审查的公开文件中，没有一份能确定这些桥梁中的某座隐含着所有其他的桥梁。域名申请并非同意遵守每一条 DDN 规则的普遍协议。网络号分配并非使用每个骨干网的许可。对 WHOIS 的依赖并未使查询的运营者成为合同受益者。在共享数据库中的发布并未将对组织内部网络的控制权转移给 SRI。

反之亦然。没有普遍的采购条款，并不意味着 NIC 的决定在任何实际意义上都是可选的。一个寻求在 NIC 管理的顶级域名下获得可识别域名的组织，不能简单地无视注册机构的程序，并期望相同的授权出现在共享层级中。一个从被授权的互联网注册处寻求唯一号码的网络，必须服从其分配流程。权力是狭窄的，但在服务边界真实存在的地方，它也是真实的。

这就是为什么承包商地位既不构成指责，也不是一个完整的解释。SRI 可以在政府资助下提供胜任、可信且被广泛依赖的服务。其员工可以在检查申请、维护数据、协调联系和运营服务器方面行使实质性判断。治理问题不在于这项工作是否重要，而在于哪个委托人授权了每项行动，哪些用户受到该委托人规则的覆盖，以及哪些额外的机构将该服务与采购链条之外的人群连接起来。

该标题的可靠含义

证据支持对三个独立问题给出有边界的答案。

在 DDN 和国防部链条内部，DCA 拥有记录在案的政府角色，SRI 是记录在案的承包商。操作规范和手册要求对特定的 DDN、ARPANET 和 MILNET 活动进行注册或审批。DDN-NIC 代表 DCA 处理记录、维护服务和传达程序。这些行动的效力来源于 DCA 对网络的管理以及受覆盖设施的义务。由于相关的工作说明和补救条款仍不可得，确切的合同边界无法被重建。

在该采购人群之外，组织接受并依赖于若干服务。它们从互联网注册处寻求唯一标识符、在共享层级中申请域名、查询 WHOIS、获取 RFC 并依赖根服务器数据。它们的理由包括 IANA 授权、IAB 和 DARPA 政策、DCA 的有限指定、申请人对注册程序的遵守、技术互操作性、累积的信任以及脱离一个被广泛使用的系统所带来的实际成本。这些桥梁赋予了 DDN-NIC 对特定注册决策的实际权力。

对注册条目的权力并非对每个相关机构或网络的权力。域名管理员在其域名内保留责任。IANA 仍与互联网注册处相区别。DCA 和 DARPA 具有不同的制度角色。标识符分配并不提供互联互通。DNS 包含并不命令每条路由。骨干网的可接受使用政策通过使用该骨干网来适用，而不仅仅是通过在中央数据库中的出现。

经审查的公开文件中，没有一份能确立一座普遍的桥梁，使得 DCA 购买 SRI 服务这一行为本身就能约束每一个使用由此产生的记录的非合同网络。同样，缺乏这样的文件也并未抹去由 IAB 政策、DARPA 资助、IANA 授权、层级规则和申请人参与所提供的较窄范围的权力。

采购记录过于不完整，无法支持更广泛的法律结论。实际的合同可能揭示更多信息：更广泛的购买人群、跨机构承诺、数据权利、过渡要求或明确规定的补救措施。一份外部申请档案可以显示有争议的决定是如何被处理的。在这些文件被提交之前，义务、权利和补救措施不能从 RFC、档案摘要或后来的制度历史中反向推断。

在这种严谨意义上，DDN-NIC 是承包商，不是宪法。这句话并不意味着该中心缺乏权威或合法性，而是指承包商地位解释了政府支持服务提供的依据以及在采购链条内行使的部分权力，而其他地方的权力必须通过额外的、服务特定的关系来追溯。

这一叙述赋予了 DDN-NIC 应有的赞誉。SRI 在制度和技术快速变革的时期运营了重要的基础设施。其员工维护的注册处、目录、出版物、支持渠道和服务器，其服务对象超出了最狭窄的军事人群。这些服务价值如此之高，以至于 1991 年的移交需要暂停注册活动、迁移主数据库、重定向请求以及协调变更主机基础设施。

治理的教训在于成就与不完整记录的这种结合。成功的管理可以在每个依赖方的权利在公开记录中可见之前，就成为公共基础设施。技术依赖可以赋予承包商巨大的实际影响力，但这并不能消除对以下事项进行识别的需要：委托人、被授予的职能、受覆盖的人群、审查机制以及超出之后则需要另一个机构提供权力的边界。

来源