摘要

  • RFC 790 直接表明,几个号码系列被维护为现行的操作参考,并指示开发者联系 Jon Postel 获取分配,但并未发布通用的网络资格规则或分配权限划分。
  • RFC 820 增加了研究、国防和商业类别,建议了网络号码空间的分配方案,提出了针对研究申请者的网关准备条件,并展望了机构间的职责划分。
  • RFC 820 还指出,其建议尚未完全实施,Postel 仍在协调所有分配,因此协议、拟议政策和工作实践不能被视为相同的制度状态。
  • 发布的表格揭示了分配、过渡及内部不一致性,而非申请者群体。没有请求、拒绝、撤回、使用情况及同期通信记录,就无法确定申请者待遇、分配动机或隐藏决策的意图。

将两份等宽字体文档的第一页放在同一盏阅读灯下。在日期为 1981 年 9 月的RFC 790的第 1 页上,引言段指出,当前信息可以从 Jon Postel 处获得,并补充道:“号码的分配也由 Jon 处理。”在审查的RFC 820文本的相应段落中,保留了人称语法,但插入了一个限定条件:分配由同一位协调员负责,但须遵守附录 A 所记载的 DARPA/IPTO 与 DDN/PMO 之间的协议。

这增加的字句小到足以淹没在满是数字列的文件中。附录 A 并不小。它报告了 1982 年 9 月一次会议达成的协议,建议将网络号码空间分配给研究与开发、国防部及商业用途,指定了拟议的机构职责,提出了研究网络的资格条件,并在最后承认该安排尚未完全实施。

这一并列提出了一个精确的问题。后来的文件是否揭示了之前清单中不可见的权力?它是宣布了一项新的分配政策,记录了一种在实践中已然形成的安排,管理向不同网络架构的过渡,还是仅仅为一直需要协调的工作提供了更完整的编辑说明?其页面允许对其中一些可能性进行检验,但无法仅凭排版就做出抉择。

因此,这并非声称技术表格秘密地为互联网立法。它探究的是,在一个条目能够成为共享操作记录的一部分之前,必须发生什么。答案因号码系列而异。选择一个未使用的协议代码,与决定一个网络应归属于哪个类别和行政范畴,并非相同的操作。记录一个端口,不等同于决定一个实验性网络是否已投入运营。公布一个联系人不等于确定申请人、裁决者或受益人。核心任务是先将这些功能分离,再询问文件支持何种制度假设。

两份文献,一项目录差异

RFC 790 是一份 15 页的网络工作组文档,归属于南加州大学信息科学研究所的 J. Postel,日期为 1981 年 9 月。它说明其记录了网络协议实现中使用的几个系列的当前分配值。需要链接、套接字、端口、协议或网络号码的开发者被指示联系 Postel 以获取分配。

该文件依次列出已分配的网络号码、互联网版本号、互联网协议号、端口或套接字号以及 ARPANET 链路号。之后是参考文献和负责人目录。条目旁边的方括号代码指向文档或具名联系人。这种形式至少有三个直接目的:避免数字冲突、告知实现者某个值的含义,并在简洁的行信息不足时提供可联系的人。

RFC 790 还声明其将定期更新。这一承诺对于其地位至关重要。它并非旨在保持最终定论。它取代了早期的分配号码文件,而自身也将被取代。它所声称的“当前性”针对的是特定的操作时刻,而非永久的权威或不可改变的历史真相。

网络号码部分占据第 2 至 4 页。它解释了三个地址类别并印出了它们的位布局。A 类使用一个前导零、七个网络号码位和一个 24 位本地字段。B 类使用高位模式10、十四个网络号码位和一个 16 位本地字段。C 类使用110、二十一个网络号码位和一个 8 位本地字段。这些是具有截然不同容量的技术类别,但不同容量的存在本身并不能确立申请是如何被评估的,也不能说明节约是任何分配的原因。

具名的 A 类行构成了一幅混合且不完整的快照。它们包括研究网络、分组无线实验、军事设施、公共数据网络、大学、承包商以及多个国家的商业运营商。该表格并未确定这些条目出自何处。它不是一份需要标识符的网络普查,也不是申请人名单或未导致公布分配的申请记录。

审查的 RFC 820 文献更长,共 22 页。其文本标题显示 J. Postel 和 J. Vernon,并写有 1983 年 1 月。而当前的RFC 编辑器目录条目则将 RFC 820 标注为“分配号码,1982 年 8 月”,且仅列出 J. Postel。本分析根据审查文本的标题和页码指称段落,同时保留目录差异。现有来源并不足以证明应当默然选择其中一种日期与作者惯例作为对另一种的更正。

RFC 820 保留了早期的编目功能,但扩大了范围。它提到了从 ARPANET 环境向 ARPA 互联网的过渡,增加了自治系统号码,纳入了以太网号码和公共数据网络映射,并大幅扩展了网络表。这里最重要的是,第 1 页将号码分配置于 DARPA/IPTO–DDN/PMO 协议之下,而第 19 至 22 页则再现了由此产生的建议和实施说明。

两份 RFC 现均被归类为 Legacy 流中的 Historic。RFC 790 被 RFC 820 淘汰,RFC 820 被 RFC 870 淘汰。这些当前的分类并不意味着文档在使用时无效或不相关。一份定期发布的注册出版物会因分配和实践的变化而过时。后来的淘汰是其文档生命周期的一部分,而非对先前快照的追溯性废除。

后来的比较有助于界定范围。RFC 943于 1985 年 4 月发布,明确将自己描述为 ARPA- 互联网社区中协议所用号码的官方状态报告。它还区分了连接至 ARPA 或 DDN 互联网的网络与使用互联网协议的独立网络。这种后来的表述不能被移植到 RFC 790 中。它表明语言和分类机制在持续发展。

两份主要文献之间的决定性差异可以加以归纳,而无需假设每个差异都只有一个原因:

特征RFC 790,1981 年 9 月审查的 RFC 820 文本,1983 年 1 月支持结论
分配联系第 1 页称分配由 Jon Postel 处理。第 1 页保留 Postel,但使分配受 DARPA/IPTO–DDN/PMO 协议约束。两者都将分配呈现为有组织的职能;后一份文本承认了一项机构安排。
网络分类第 2–4 页使用技术地址类别,无行政用途代码。第 2–6 页增加 R、D 和 C,分别代表研究与开发、国防部及商业。后一份网络表既记录了地址类别,也记录了行政类别。
过渡未解释等效的过渡标记。第 2 页解释说,在变更期间,旧的网络号码以 T 标记保留。连续性可能要求旧标识符与新标识符在发布记录中共存。
前瞻性分配权限未印制多机构分配方案。附录 A,第 19–21 页,为不同使用类别推荐了职责。共享的跟踪功能在概念上可与所有实质分配决策分离。
资格条件未印制通用网络申请标准。第 20 页建议研究申请者提供有关网关的证据。建议的研究政策涉及的不仅仅是冲突检查。
实施未出现可比的附录。第 22 页称建议尚未完全实施,Postel 目前在协调所有分配。建议、协议和工作实践仍彼此分离。
决策记录未发布请求总数、理由或例外记录。扩展后的政策仍未发布这些内容。文件显示的是成功或存续的条目,而非完整的决策总体。

比较确定了文件的变化。下一个问题是,每一个词语和表格需要怎样的行政管理。

“分配”、“注册”、“当前”和“官方”并非同义词

RFC 790 开头的指示不仅仅邀请开发者报告一个自选值。它要求联系 Postel “以获取号码分配”。在一个新值能够安全地出现在共享列表中之前,必须有人得知请求、检查冲突、选择或确认一个值、沟通结果并更新记录。这个最基本的顺序就是协调式行政管理。

但这并不意味着每个系列都涉及同等重大的决策。对于许多协议或端口请求,关键行为可能只是找到一个未使用的代码点并维护互操作性。文本并未提供依据来声称每个开发者的机构价值都被评估过。“分配”一词表示一项操作,但仅凭其出现并不能揭示背后的标准或判断深度。

网络号码则不同,因为 RFC 820 将其与行政用途类别及一项推荐的资格条件相关联。附录 A 说,在研究与开发社区内,网络标识符将仅授予那些提供证据表明他们正在获取标准 BBN 网关软件,或已实现或正在获取满足外部网关协议要求的网关的申请者。并补充说,获取 Berkeley BSD 4.2 UNIX 软件可能算作后者的证据。

此措辞比单纯的唯一性检查更强。它以技术准备证据为条件来推荐授予。但它仍是推荐政策的一部分,而非已普遍实施的运行规则。附录并未规定完整的证据标准、裁决方法、上诉程序或在该条件下评估过的申请记录。最后一页明确表示,该建议尚未完全实施。

“当前”执行另一种功能。两份文件都声称描述当前分配的值,并告知读者当前信息可从何处获得。在此背景下,当前性是关于同步的一种声明:实现者应能查阅一份维护中的参考,而不是依赖于不兼容的私有列表。这并不意味着每个条目的初始理由、机构历史或当前持有者都已完整记录。

RFC 820 在其自治系统部分使用了“注册”一词。外部网关协议提供了一个 16 位字段来标识自治系统,其值在文档中注册。初始表格几乎是空的:零被保留,一标识 BBN 网关,二至 65,534 未分配,65,535 被保留。此处,注册描述了标识符系列在早期阶段的共同记录。它不能不加区分地应用于网络附录,因为那里有分类和推荐申请者证据,增添了不同的考量。

“官方”在 RFC 943 中变得明确,而非在 RFC 790 或 RFC 820 的起始状态语言中。那种后来的表述描述了在 ARPA- 互联网社区内的认可。它既不使每一项早期的列表维护行为等同于正式的政府决策,也不确立某个条目在该报告所服务的社区之外具有同等的重要性。

因此,这些词语标识了重叠但可分离的功能。分配可以包括选择或确认。注册记录一个值。当前性表达维护。官方状态标识在特定操作社区中的公认地位。它们在分配号码谱系中的接近性,并未将其压缩为一种通用权威。

一份出版物包含几个不同的注册表

“分配号码”这一标题将多个系列汇集到一份文档中,但它们的冲突问题和机构利害关系并非可互换。

互联网协议号占用了 IP 头中的一个 8 位字段,并标识数据包承载的下一层协议。协调该号码允许不同实现一致地解释该字段。RFC 820 的附录 A 提议为国防部标准、研究用途以及商业、国家或国际标准保留协议号码空间的部分。这是针对协议标识符的协调,而非向某个组织分配主机地址容量。

端口号标识了逻辑连接末端的一个服务联系点。RFC 790 仍同时讨论 AHHP 套接字和 TCP 端口,而 RFC 820 展示了一份以 TCP 为中心并在可能时与 UDP 复用的端口列表。分配一个知名端口可使服务在不同实现间互操作。这并未使署名的协议作者或服务联系人成为网络地址块的持有者。

网络号码扮演了不同的角色。它们在互联网寻址架构中标识网络。所选类别决定了本地地址字段的宽度:A 类为 24 位,B 类为 16 位,C 类为 8 位。因此,网络分配不仅作为标签不同,而且在地址容量和路由处理上也不同。RFC 820 中的类别代码、过渡标记和网关准备建议适用于这一更具机构差异性的操作。

自治系统号码是另一个不同的系列。其目的是为外部网关协议标识网关组。它们在 RFC 820 中的出现记录了域间协调的早期发展;它并未为网络号码资格提供一般性信条。

ARPANET 链路号属于主机/IMP 接口环境。RFC 820 的附录建议消除不必要的使用,并研究接口间的互操作性问题。该项任务涉及另一个协议字段和另一组操作依赖关系。

名称注册不应仅仅因为端口表包含名称相关服务就被推断出来。RFC 790 将端口 42 分配给名称服务器,端口 43 分配给 Whois。RFC 820 包含这些服务联系,并增加了主机名或邮箱名称服务器端口。这些是用于访问服务的条目,而不是主机名或域名的注册表。人员部分同样是一份责任联系人目录,而非名称注册表或申请者分类账。

计算机历史博物馆关于 SRI ARC/NIC 记录的检索工具强化了这一机构区分。它将 SRI 网络信息中心对 ARPANET 主机表的维护及后来的命名过渡描述为一项独立活动。它还指出,分配号码及全局地址分配的管理于 1987 年从 USC-ISI 转至 SRI NIC 合同。该检索工具是后来的档案背景,而非证据表明 SRI 运营了两份 RFC 中描述的 1981–1983 年分配职能。

将各个系列汇于一份参考出版物中具有操作意义。开发者可以在一处找到相关的常量和联系方式。然而,共同的格式并未使每一个列出的号码成为同类的授予。从网络号码附录中得出的治理结论必须仍依附于该附录,除非其他部分提供了其自身的证据。

行政类别并未取代技术类别

RFC 820 叠加了两种不同的分类。第一种是架构上的:A、B 和 C 类定义了地址格式。第二种是行政上的:RDC标识研究与开发、国防部及商业用途。混淆二者会产生错误的比较。

在审查的 RFC 820 文本第 2 页,正确描述了 A 类具有一个前导零,B 类具有前导模式10。其散文将 C 类的三个最高阶位描述为1-0-0,但相邻图表显示为1 1 0,且其 C 类范围始于 192,其高序位为110。RFC 790 也将 C 类模式印为110。因此,RFC 820 中的1-0-0短语属于内部文本错误,而非不同地址架构的证据。

在扣除保留的端点和其他排除项之前,三个技术类别分别包含 128、16,384 和 2,097,152 个可能的网络号码值。它们的本地字段每个网络分别包含 (2^{24})、(2^{16}) 和 (2^8) 个数值地址值。这些差异使得类别的选择具有后果性,但两份 RFC 均未提供其列出网络的主机利用率测量数据。

行政代码回答的是一个不同的问题:文件将已分配的标识符与哪个使用类别相关联。一个研究代码并不意味着类别小或大。一个商业组织可能参与一个研究项目,而一个承包商的网络可能根据网络用途而非机构的法律性质来分类。联系人的雇主、网络描述和类别代码不能被视为可互换的证据。

附录 A 建议将可用的类别空间分配给三种用途。对于 A 类,它给出 8 个网络用于研究与开发,24 个用于国防部,94 个用于商业用途。对于 B 类,它给出 1,024、3,072 和 12,286。对于 C 类,附录印出研究用 65,536,国防部用 458,725,商业用 1,572,862。

这些是拟议的分配,而非对已完成的分布描述。第 6 页的工作表报告了 26 个已分配的研究类 A 标识符、4 个国防类及 1 个商业类。这 26 个研究条目是附录推荐分配 8 个的 3.25 倍。若干条目被标记为旧的过渡号码。这一不匹配与该文件明确声明实施仍不完整是一致的。

该文件还包含一个数字不一致之处。第 6 页的“最大允许”摘要将 C 类国防部分配额列为 458,752,而第 20 页的附录 A 印出的却是 458,725。相差 27 个标识符。

使用第 6 页的数字,拟议的 C 类类别总和为:

  • 65,536 个研究标识符;
  • 458,752 个国防标识符;以及
  • 1,572,862 个商业标识符;

总计 2,097,150。这与保留首尾值后的 2,097,152 值 C 类网络号码空间相吻合。

若使用附录 A 印出的 458,725,则得到 2,097,123,比第 6 页的总数少 27 个。文件未提供解释。重建时应保留两种印出的说法,而非默不作声地修正其中之一。

附录 A 进一步建议,当实验网络变为可运行状态时,若重新编号会造成困难,则无需重新编号。它们的标识符可以改为从研究状态移入国防或商业状态。总的类别分配应保持不变,而具体标识符则改变状态。因此,附录建议不要将各类别作为简单的连续分区分配,并推荐在各负责机构间追踪特定分配。

这是一项关于分类、连续性和协调的政策建议。它并未证明任何特定网络是如何获得其现有行项目的。类别代码记录的是表格中所印的结果;它并非一份现存的原因说明。

建议、协议与工作实践同处于一个附录

附录 A 开篇即称,它总结了 DDN/PMO 与 DARPA 在 1982 年 9 月一次会议上达成的协议。随后,它反复使用建议性的语言。

就网络标识符而言,叙述建议研究、国防和商业用途的分配分别交由 DARPA、DCA PCCO/DDN 及国家标准局负责。然而,数字表格中却将 ARPA 列为研究分配者,并为国防和商业分配者印上了TBD

因此,三种机构状态可见一斑。各机构达成的协议足以被总结。文件推荐了未来的职责分配。重要的办公室层面职责在表格中仍悬而未决。

第四种状态出现在第 22 页:工作实践。实施说明称,政策建议尚未完全实施,Postel 目前正作为所有号码分配的协调员。无论附录预期了何种机构划分,申请者和实施者仍会遇到一个中心协调点。

网关准备的相关措辞必须置于此序列中理解。它表述了在推荐安排下研究社区内“将施行什么政策”。它是拟议资格条件的直接证据。它并非直接证据表明 RFC 790 中每个更早的条目、RFC 820 中每个条目或每种号码请求都已在该条件下处理。

同样,关于困难的条款是一项推荐的过渡规则。它表明政策设计者认识到了重新编号的操作成本。它并未标明哪些带有T标记的变更是自发的、强制的、经协商的、抑或出于与新类别分配无关的原因。

尽管如此,该附录支持了一项重要的机构发现。其作者能够区分实质分配与中心追踪。不同机构可以在不同类别中做出分配,而 DDN/PMO 或一名指定人员则追踪综合记录,以确保分配不超出建议范围。共同的记录保管者不必是每个决策的唯一来源。

该架构也携带了未解决的问题。如果一个网络改变了类别,必须有人更新类别余额。如果一个分配者超出了其额度,就需要一个修正或例外程序。如果两个机构将同一请求视为属于各自的管辖范围,系统就需要一种解决重叠的方法。RFC 820 推荐了跟踪,但并未发布一份完全的管辖守则。

因此,这份文件包含了一个部分形式的行政管理理论:差别化的池、多个可能的分配者、中心协调、连续性保护以及针对一个类别的技术资格。它还包含证据表明,该理论与实际的分配接口尚未合流。

清点清单,而不将行项目变为申请人

网络表格可以检验文件变化如何在发布的分配中呈现,但前提是三个观察单元保持分离。

一个印发行是文件中出现的某一行或范围条目。它可以描述一个标识符、成百个标识符或一个在过渡期间保留的旧号码。重复的行仍是印发行。

一个展开的网络标识符是指一个印出的范围展开后所代表的一个有类网络号码。例如,RFC 820 的范围192.001.xxx192.004.xxx代表四个第二组值乘以 256 个第三组值,即 1,024 个 C 类标识符。

一个唯一的字面标识符字符串是去重后展开的标识符,即移除相同的印发地址字符串后得到的结果,而不去猜测一个表观序列原本要表达什么。这个单元保留了转录冲突,而不是隐匿地修正它们。

这些单元中没有一个是申请人、接收者、组织、活跃路由、主机或财产权益。

RFC 790 的 A 类表印出了从 001 至 044 的命名分配行,但 013 被明确列为未分配。这产生了 43 个命名分配行。它并未产生 43 个无争议的已分配标识符。值为 044 的行名称为 AMPRNET,但紧接其后的未分配范围同样始于 044 并延续至 126。因此,该文件提供了 42 个明确的命名标识符,外加一个内部冲突的标识符 044。

RFC 790 中 B 类不含命名分配,C 类亦然。这一陈述描述的是表格,而非世界上每一个小规模网络的缺失。列出的 A 类网络包括多项实验、相关设施和测试网络。一个命名行并非一名法律上独立的受益人的证据。

RFC 820 在第 6 页提供了一份印出的“网络总计”摘要:

RFC 820 印出的摘要A 类B 类C 类总计
研究26191,0331,078
国防45716
商业1023
总计31241,0421,097

依据该印出的摘要,研究类别占 (1,078 / 1,097),即 98.267%,四舍五入后为 98.3%。这是印出摘要的结果,并非发现 98.3% 的申请者或组织是研究机构。

主要贡献来自与 BBN 本地网络相关的一个单一范围。展开192.001.xxx192.004.xxx得出 (4 \times 256 = 1,024) 个 C 类标识符。这 1,024 个标识符占该 RFC 印出分配总数的 (1,024 / 1,097),即 93.345%,四舍五入后为 93.3%。

该分母是明确的:按印出摘要代表的 1,097 个展开的分配。这一比率并不意味着 BBN 提交了 1,024 份单独的申请、收到了 1,024 项独立的决定,或将每个网络都用作一个外部路由单元。文件将一个范围与“BBN 本地网络”相关联,但并未解释其背后的请求历史或运行拓扑。

字面去重产生了一个不同的结果。在 C 类表中,192.005.022被印出给 BRLNET2、BRLNET3、BRLNET4 和 BRLNET5。这些名称暗示了一个预期的序列,且下一个未分配范围始于 192.005.026,但字面重建不能在不标记为修正的情况下替换为 023、024 和 025。

将四次出现的192.005.022去重,从印出的 C 类总数中移除三个重复项:

重建A 类B 类C 类总计
RFC 820 印出的摘要31241,0421,097
唯一字面标识符31241,0391,094

由于重复的 BRL 行是国防编码,唯一字面类别总数变为研究 1,078、国防 13 和商业 3,总计 1,094。研究计数保持 1,078;国防计数由 16 降至 13。

与 BBN 范围相比,这一差异虽小,但对于方法而言却是决定性的。印出的摘要可以作为来源的声称被复制。唯一字符串计数可以作为单独的字面解读被复制。两者不应被相互替代。

过渡条目增添了另一层复杂性。RFC 820 解释说,旧号码可能仍以T标记列出以方便变更。因此,一个网络可以在一个旧的 A 类标识符和较新的 B 类标识符下出现,而不代表两个独立情境的接收者。计算二者对于操作识别可能是正确的,而对于接收者分析却是错误的。

文档间的变动仍是可见的。RFC 790 仅在 A 类表中包含命名行。RFC 820 根据其摘要,包含了 31 个 A 类、24 个 B 类和 1,042 个 C 类分配的混合,并伴有明确的过渡标记。一些较大的早期标识符已被替换、放弃或临时保留,而较小类别的标识符则出现了。

这一变化与更具差异的分配规模相一致。它并非匮乏导致每次变更的证明。表格中不包含主机利用率序列、预测、申请表或决策理由。一个 A 类标识符的容量说明的是地址格式允许什么,而非被命名网络使用了多少地址,或管理员为何在有关时刻选择了该类别。

BBN 范围是一项重要的反证,反驳了对于可用最大类别的一致偏好的简单说法。一个主要参与者通过 1,024 个小 C 类标识符以及其他条目出现。这些表格并未解释此安排是否反映了实验、局部分段、路由实践、行政便利或其他目的。它们确实表明,机构的显著地位并非在每种情况下都机械地产生一种地址类别。

印出的商业计数也十分容易被误读。在第 6 页的摘要中,仅有三个分配被编码为商业,而附录 A 却提出了一个庞大的前瞻性商业分配。这种对比可能反映了一项早期政策过渡、工作互联网的有限范围、编码惯例、需求的构成,或实施不完整。没有申请与通信记录,就无法确立排斥或优待。

后来的分配数据能修补什么,不能修补什么

CAIDA 的IPv4 分配可视化历史提供了地址空间变动的有用重建。它也表明了为何后来的可视化无法提供缺失的申请者分母。

CAIDA 解释说,可视化的早期部分源自分配号码 RFC,而后期则使用 IANA 数据。该表示以/8粒度运行,将较小的分配置于包含它们的较大地址块中。它指出,RFC 790 与 RFC 820 之间已分配的地址空间有所减少,部分原因是某些组织用大块换成了较小的分配。

这一说法与 RFC 820 的过渡标记以及命名 A 类条目的减少是相容的。它并非独立的接收者层面的佐证,因为其早期重建依赖于正在审查的 RFC 系列。公开的日期序列从 1977 年 11 月推移至 1983 年 1 月,而相关的桑基数据按/8聚合流量。它们无法独立重建 RFC 790 与 RFC 820 之间的每个请求、分配决策或接收者过渡。

后来的注册记录引入了其他问题。CAIDA 关于 IPv4 消耗方法论的单独说明指出,1993 年的一次更新将许多旧有分配的日期指定为 1993 年 8 月,因为此前的确切日期已不可得。后续的记录也可能继承组织更名、管理职责移交、修正和状态变化。

因此,一条当前的注册记录是一个存续行政状态的证据,而非一份关于申请者在 1981 年请求了什么的未触动记录。它可能有助于追踪之后的连续性,但无法仅凭自身恢复产生早期行的原因、日期或决策单元。

表格可以在不越界的情况下支持几项实证发现:

  • RFC 790 印出 43 个 A 类命名分配行,其中 42 个明确无误,一个与后续的未分配范围相冲突。
  • RFC 820 的印出摘要报告了 1,097 项分配,但字面去重产生 1,094 个唯一地址字符串。
  • 研究占印出总数的 98.3%,很大程度上是因为一个 BBN 范围展开为 1,024 个研究编码的 C 类标识符。
  • 仅 BBN 范围就占 1,097 印出摘要总数的 93.3%。
  • 新旧标识符可以共存,因为过渡行保留了运营连续性。
  • 工作表尚无法匹配附录 A 所推荐的类别分配。
  • 文件中不包含请求、拒绝、撤回或被劝阻申请的直接影响分母。

这些发现表明,该清单是行政化产生的。类别、变更、预留和过渡必须被记录。它们并未揭示境况相似的申请者是否受到相似对待,因为相关总体和决策文件缺失。

四种解释经得起文本差异的检验

从 RFC 790 到 RFC 820 的演变至少有四种在当期可行的解释。

第一种是政策发展。1982 年 9 月的会议可能产生了一个对于日益增长且多样化的互联网更为明确的回应。新的类别代码、建议的池大小、网关准备条件以及提议的机构职责划分支持这一解读。附录 A 直接将它们呈现为与机构协议相关的推荐政策。

第二种是实施管理。从 ARPANET 环境向 ARPA 互联网的过渡、MILNET 的发展以及网络的重新编号或重新分类,可能即便在没有全新分配哲学的情况下也需要一份更详尽的运营文件。T标记、较小类的分配和困难条款符合这种解释。

第三种是文件清理。之前通过通信或工作关系已理解的做法,可能被更清晰地写了下来。总数、管理代码和实施说明可能反映的是一种更佳的出版物,而非它们所描述的每项实践的开端。

第四种是起草偏好。审查的 RFC 820 标题显示了一个额外的名字 J. Vernon,尽管当前的目录仅列出 Postel。不同的起草过程可能产生了更明确的机构性文辞,却未伴随日常决策的相应变化。目录与标题的差异使作者身份和编辑传承成为不确定性的一部分,而非归因某项特定政策角色的基础。

这些替代解释并非互相排斥。该附录可以同时记载一项协议、指导一场过渡、将现有期望正式化,并反映一种更为详尽的编辑风格。

同期信件往来可以区分它们。计算机历史博物馆的检索工具指明了会议笔记本、NIC 进展报告、命名与寻址文件、按时间排序的电子邮件、工作组记录以及从承包商收集来的互联网月度报告。它表明 NIC 工作人员、网络用户、工作组和联邦机构之间的潜在相关通信保存于档案收藏中。

该检索工具并未披露特定 RFC 790 请求的内容、1982 年 9 月的会议记录或针对附录 A 的起草通信。它证明了收藏的存在和范围,而非未开封的记录将确立什么。

一次聚焦的档案审查将会询问:谁起草了附录,类别代码是否已在内部使用,网关证据是如何被评估的,为何某些分配权限仍为TBD,以及特定的重新编号是由网络还是管理员提出的。在底层记录回答这些问题之前,文本差异支持多种解释。

联系人暴露了责任,但未界定决策链

两份 RFC 都将大量篇幅用于责任人。协议或网络旁的方括号代码指向人员部分中的名称、所属机构和邮箱。这使简洁的条目在操作上可用。开发者可以询问某人某个未编档协议的含义,或就某个命名网络联系谁。

然而,“负责”一词是弹性的。此人可能是协议作者、实现者、站点联系人、工程师、文档来源或注册表维护者。该列并未说明此人是否申请了该号码、批准了它、控制了网络,还是仅仅足以回答技术问题。

这种模糊性在JBP(Postel 的代码)的使用中可见一斑。它出现在已保留和未分配的范围旁,也出现在已分配的协议值旁。在这些位置,它不可能表示一个受益人。它标志着对注册状态或技术定义的责任。其他代码指向与命名网络相关的人员。因此,一种标记代表了多种关系。

这个联系机制支持了一个有限的机构性主张:早期的协调依赖于可识别的专家和可达的邮箱。它不支持个人声望是分配标准的主张。它也未显示初步讨论是通过电子邮件、电话、纸质函件还是会议进行的。

在共享列表中发布,使得分配具有了操作可见性。依赖此参考的实现者可以避免重复并识别相关联系人。这种实际重要性并不确立该列表创造了每个网络的技术存在或赋予了财产权益。相反,附录 A 所提议的多分配者模型表明,分配决策可以源自多个机构,并被整合起来以供追踪。

更完整的分户账是可行的,但并非没有成本

想象一下,如果 RFC 820 的网络号码部分保留了五种额外的信息:适用的资格标准、简短的原因代码、每次修订的来源、汇总的请求处理情况,以及被授权裁定例外的办公室。

这并不需要一个现代的公共申请系统。一个当期可行的设计本可以使用一个单独的固定宽度附录、纸质表格、电子邮件模板和汇总的月度总数。原因代码或可用于区分网关准备就绪、实验、过渡、类别变更和修正。修订列可以记录先前的标识符和生效日期。敏感细节可以继续保存在受限档案中,而公共列表只携带最低限度的代码。

此类记录将使若干历史问题可以被检验。研究者可以将完成的分配与撤回或拒绝进行比较,区分申请者请求的重新编号与行政启动,并确定网关标准是否被一致应用。一个具名的例外权限将显示提议的职责划分止于何处。

额外的记录也会带来负担。工作人员需要一致地保存接收数据、维护原因词汇表,并在连续出版物间协调修订。实验性或与国防相关的请求可能包含不适合公开发布的细节。编辑规则将创造进一步的决策。RFC 820 中的TBD条目表明,确定例外权限本身亦未完成。

SRI NIC 检索工具描述了更广泛时期内的介质不兼容、印刷生产困难以及迅速过时的参考资料出版物。由于分配号码的管理直到 1987 年仍留在 USC-ISI,该证据无法确立 RFC 790 和 RFC 820 的确切制作流程或成本。它是时期背景,表明更丰富的文档会与实际的技术和出版限制相互作用。

因此,这一反事实改变了留存的证据,而非必然改变机构的正当性。标准可能设计不佳,理由可能公式化,汇总计数可能遗漏了那些从未得知如何申请的人。即便如此,成功条目列表与附理由的决策记录之间的区别,本会使后来关于待遇的声称大大更容易检验。

现在反转设计。唯一性是否可以在没有一个中心办公室决定每次分配的情况下得到协调?

RFC 820 自身的建议在原则上回答了可以。研究、国防和商业标识符可以由不同的机构分配,而一名指定的协调员则追踪综合记录。该时期已支持电子邮件、电话协调和定期更新的文件。有几种可行的安排是可以设想的。

一种选择是将特定分配报告给一个共同的追踪者,附录 A 优先考虑这一点,因为标识符可以更改类别。另一种是划分的池,每个分配者控制一个确定的范围并定期发布更新。第三种是一套分布式的可问责列表,按计划进行协调,并通过临时预留消息防止不同版本之间的冲突。

每种替代方案都有代价。简单的划分使类别变更更难,并可能将未使用的标识符搁浅在一个池中。定期协调会引入延迟。分布式列表有状态冲突的风险。通过共同追踪器的特定分配减少了一些冲突风险,但使追踪器在操作上变得重要。

重点并非去中心化就一定更优。而是说,冲突控制、实质资格与发布是可以分离的。共同追踪在操作上是有价值的,且 RFC 820 的架构中明确推荐了它,但单一的通用清单并非唯一逻辑上可能的设计。

在解释协调员角色时,这种区分很重要。如果指定的类别分配者未确定或不可用,那么维护共同记录的人可能在实践中继续处理请求。这种扩展可能源于实施不完整,而非对排他性权力的主张。RFC 820 恰好记载了这样一个缺口:分散负责被推荐,而一名协调员仍在处理所有分配。

联邦支持解释了能力,而非每个规则

政府背景只能在两份文件确立了其自身的条件之后才能加入。

一项2016 年政府问责局的法律意见指出,后来被归入 IANA 名称下的功能始于 Postel 在 UCLA 领导的工作,并于 1977 年随他迁至 USC-ISI。GAO 将该工作描述为在美国国防部资助的研究项目下执行,并通过后来的 DARPA 合同得以延续。

这一后来的叙述与 RFC 820 直接提及 DARPA/IPTO、DDN/PMO 及 1982 年 9 月会议的内容一致。它有助于解释为何一项全球技术清单拥有一个美国行政中心,以及为何提议的政策区分了研究、国防和商业用途。

GAO 还表示,它无法获得 1970 年代至 1990 年代相关的 DARPA 合同。其更详细的合同证据涉及后来的时期,其法律问题则在 RFC 790 和 RFC 820 数十年后才出现。

因此,该意见无法确立一份缺失的 1981 年合同的条款、适用于特定请求的标准,或每个参与者理解的权限范围。联邦赞助解释了机构能力和背景。它本身并不能证明标识符的所有权、普遍同意或每项行政选择的正当性。

主要证据仍然更窄。RFC 790 指定了一名分配协调员。RFC 820 增加了一项机构协议、推荐的号码空间划分、前瞻性的机构职责、一项提议的研究资格条件以及一份实施不完整的说明。后来的政府历史证实了环境,但未将这些陈述变为一份全面的宪章。

各列最终支持什么

地址列表中的政治并非仅仅因为该列表分配了具有不同技术容量的标识符而显现。当文件展现出分类、资格、过渡、机构责任以及依赖一份维护中的共同记录所带来的后果时,它们才变得可见。

RFC 790 确立了一个集中的协调接口。若干号码系列被一同发布,开发者被导向一位具名的分配联系人,所产生的值则作为当前操作信息呈现。其网络表记录了一组混合的研究、政府、军事、公共数据及商业网络,但未给出通用的申请者标准或分配职责的划分。

RFC 820 增加了一个更为清晰的行政层。它按用途对网络标识符进行分类,在过渡期间保留旧号码,印出分配总数,并规定了建议的类别分配。它为研究申请者提出了与网关相关的证据,允许网络在会造成困难时不重新编号而改变类别,并设想在共享追踪安排下由多个机构做出分配。

同一份文件又防止这些建议被误认为是已完成的实践。国防和商业分配者在数字表格中仍为TBD。工作中的分配并不匹配推荐的 A 类分布。最后的实施说明称,Postel 仍在协调所有分配。

这些表格也抗拒一种简单的分配叙事。RFC 790 的值 044 存在内部冲突。RFC 820 将一个字面 C 类地址重复了四次,并印出了不相容的国防类 C 分配总数。其 1,097 分配摘要被一个 1,024 标识符的 BBN 范围所主导。过渡条目可使同一网络被计在旧号和新号下。这些是可识别编辑与计数问题的操作记录,而非干净的申请者数据集。

因此,文件支持以下推论:网络号码协调涉及的不仅仅是消极的转录。技术唯一性必须被保护,但类别分配、过渡处理以及提议的准备就绪条件都需要行政判断。这种判断在一个联邦支持下的机构环境中运行,并且,在审查的 RFC 820 文本中,仍然通过一位工作中的协调员进行。

它们也支持一个不那么集中的推论。RFC 820 并未将共享追踪等同于排他性的实质分配权力。其推荐的架构允许决策源自多个机构,而由一个机构监控合并后的分配。这一设计尚不完整,但概念上的区分是存在的。

余下的不确定性并非一个微小的限定。公共列表中没有申请总体、拒绝计数、撤回历史、利用率序列或每项分配的理由。可用的检索工具确定了可能相关的通信,但未揭示其内容。这些文件无法表明,紧凑的格式是源于便利、出版限制、沿袭惯例、刻意极简还是其他原因。

这些表格也未确立一套成熟的稀缺性学说。它们显示了有限的类别空间、保留值、类别分配及地址规模间的移动。它们并未表明稀缺性驱动了某项特定分配,或某位申请者因此被拒绝。后来的地址枯竭加重了早期分配的影响,但并未重建它们最初的动机。

留存下来的是具有真实操作效果的文献化行政能力。这些列表协调了数值,使某些分配可见,对网络进行了分类,并在变化中帮助保持了连续性。对该记录的依赖可能使其维护变得举足轻重,即便记录者并未声称要为每个网络的正当性背书。

在阅读灯下,两份文件之间的重大区别因此并非政治于 1983 年突然进入了表格。而是 RFC 820 使更多的行政机制变得清晰易读:一项协议、使用类别、前瞻性的分配者、一项资格推荐、过渡规则,以及一项承认,即实施滞后于设计。

这一机制可以在不将其操作者归因于隐藏动机的情况下被描述。其分配后果可以在不将范围变为申请人的情况下被衡量。其权威可以在不假设一列整齐的数字即是合法性或隐匿的证明的情况下被审视。这份双文件考古学最持久的教益是,一份技术清单可能是协调系统认可了什么不可或缺的证据,却仍是不完整的证据,无法说明认可如何、为何以及由谁决定。