摘要

  • John Day 在口述访谈中把 OSI 参考模型描述为组织后续标准化工作的框架，而不是要求实现固定协议栈的命令。
  • RINA 后来提出递归式进程间通信架构，ProtoRINA 则测试了有限实现；现有引述材料既不能证明广泛生产采用，也不能证明完全无人使用。

七层图没有给出部署顺序

七层图熟悉到近乎自明，因而容易让人误以为：网络必须按层逐步建造，先实现底层，再向上扩展。John Day 的回忆指向另一种用途。Computer History Museum 在 2010 年录制的口述史中，Day 把 OSI 参考模型称为后续标准化工作的框架，而非实施文档。这是 Day 的回忆，不是标准文本的原句，也不能代替会议记录；但它提示了一个重要边界：共同模型能够为功能命名、帮助委员会讨论，却不必然规定每家厂商的产品架构，更不能替运营商排定部署日程。

Day 确实参与了相关标准工作。Boston University 对他的访谈记载，他担任过 OSI 参考模型报告人，并主持 ANSI 的 OSI 架构委员会。博物馆的口述史还记录了他对美国代表团和早期模型讨论的回忆。这些材料把他放回集体过程之中，却没有把他变成 OSI 的唯一作者，更没有把委员会框架变成面向所有网络的强制命令。

这一区分关乎标准能够产生什么权威。参考模型可以建立共同词汇，把复杂问题拆成可讨论的功能，并让不同机构更容易协调提案。它却不会自动提供工程预算、迁移路径、与既有设备的兼容性，也无法创造运营商改变现网的商业动机。实施和运维团队必须在这些约束下作出选择。若把描述误读为指令，标准化看起来就像发布命令，部署也会被误写成必然结果。

RINA 把递归 IPC 作为架构主张

Day 后来的工作并非给 OSI 增加一个新层。2008 年，他与 Ibrahim Matta、Karim Mattar 合写《Networking is IPC》，提出用进程间通信（IPC）理解网络：应用进程使用 IPC 设施，而该设施本身又可以向下层 IPC 设施请求服务。递归重复是这套架构的关键。这是作者提出的设计，不是关于已有网络采用状况的统计。

Boston University 的 RINA 项目把分布式 IPC 设施（DIF）描述为重复出现的网络单元，并说明策略可以配置其运作方式。这是研究团队对自身模型的解释，有助于理解其设计意图；它不是独立性能评估，也不能证明 RINA 已取代其他网络架构或解决了所有运行问题。

ProtoRINA 让模型与实现之间的距离具体化。Wang、Matta、Esposito 与 Day 在 2014 年的论文中介绍一个用户空间原型，并报告在 Boston University 校园和 GENI 研究测试床进行试验。文章明确称自己是未经同行评审的编辑说明，还说明实现尚未完整、零级连接使用 TCP shim。它的价值正是范围有限：研究人员确实构建并测试了设计的一部分，但环境和功能都有边界。它不能证明普遍商业部署、对公共互联网的替换，或相对其他方案的优势。

因此需要分开回答三个问题：模型定义了什么？某个具体实现实际运行了什么？哪些独立网络在何时、以多大规模、持续多久地选择了它？Day 的口述史有助于回答第一个问题；RINA 论文提出了架构；ProtoRINA 报告有限的实验。本文查阅的来源没有给出第三个问题的完整普查。既不能据此说“RINA 无处不在”，也不应反过来断言“RINA 从未被使用”。

标准能协调，但不会替人决定

Day 这段经历的意义，不在于宣布七层模型或递归 IPC 哪个应成为终极地图，而在于明确共同规范与本地决策之间的界线。标准化能让组织之间的接口更易理解。运营商仍须判断架构是否适配自己的设备、服务、人员技能、风险承受度与更新窗口。原型可以降低“代码能否在测试床运行”的不确定性；只有采用证据才能说明哪些网络承担了运营成本，以及某种能力是否在生产中长期可用。

基础设施决策者应为每种主张索取不同的证据。模型要说明范围和预期用途；原型要记录代码状态、测试环境、条件和未完成部分；部署主张则要列明网络、日期、用途，并区分短期试验与持续服务。缺少这些记录时，投影片上的图就可能获得任何委员会、论文或试验都没有授予它的权威。

来源