摘要

  • John Moy 以编辑或作者身份出现在 OSPF 协议分析、OSPF Version 2 标准化记录和优雅重启文件中。RFC 1245 把带宽、内存、CPU、规模与运行经验纳入协议分析；RFC 2328 把拓扑数据库、最短路径计算、区域、认证交换与等价路径写成明确规则；RFC 2329 又以实现、部署和安全记录说明标准化不能只靠规范自述。
  • RFC 3623 所描述的连续性不是无条件保持转发，而是在邻居愿意提供帮助、拓扑假设仍成立时暂时保留路径，并在支持安全转发的条件消失时回到正常重启。由此可见，路由记录必须准确且同步，运行中的代码与真实状态必须独立核验，运营连续性只能建立在可观察、可撤销的条件之上。

从公开协议记录，而不是人物神话，理解 John Moy

技术人物文章很容易把一段共同完成的协议历史压缩成“某个人发明了某项技术”。John Moy 的公开记录不支持这种写法。1991 年 7 月的 RFC 1245 将 J. Moy 列为 OSPF 协议分析的编辑；1998 年 4 月的 RFC 2328 将他列为 OSPF Version 2、STD 54 的作者；同月的 RFC 2329 将他列为 OSPF 标准化报告的作者；2003 年 11 月的 RFC 3623 则将他列为优雅 OSPF 重启的共同作者之一。

这条时间线可以证明署名、日期和文件主题，也能呈现一组持续存在的工程问题。协议分析关注成本与适用范围，协议标准关注拓扑状态和计算规则，标准化报告关注实现与部署依据，重启机制关注连续性能够维持到什么边界。四类文件彼此关联，却不能被改写成由单个人控制所有 OSPF 实现或实际网络的故事。

准确的人物画像应把贡献放在文档允许的范围内。Moy 是这些公开 OSPF 记录的重要署名者，但文件本身来自标准化共同体，也需要实现者与运营者在现实网络中执行。尊重署名和拒绝独占叙事并不冲突；前者保存可核对的贡献，后者防止归因超出事实。

1991 年 7 月：先把协议代价列进分析

RFC 1245 的价值首先在于它没有把 OSPF 只写成一组理想规则。这份历史性的协议分析评估链路带宽、内存、CPU、扩展限制、适用环境与已有运行经验。也就是说，协议是否有清楚的算法并不是唯一问题；算法在设备和链路上需要消耗什么，同样属于技术判断的一部分。

这种写法把架构承诺转化为可以分别核对的对象。带宽涉及状态交换占用的链路资源，内存涉及路由器为协议状态保留的容量，CPU 涉及处理变化和计算路径所需的工作，规模则要求说明这些成本随网络环境变化时是否仍然可接受。分析报告并没有让这些对象自动变得安全，但它避免用一个笼统的“可扩展”结论遮住不同资源约束。

对运营者而言，重要的不是把 1991 年的数据直接搬到今天，而是保留这种问题结构。任何实现都需要在自己的设备、拓扑和变化频率下重新观察资源代价。历史记录提供了应当测量什么的公开先例，不能替代当前环境中的测量结果。

链路带宽把控制面带回有限资源

链路状态协议需要交换足以描述拓扑的信息。RFC 1245 将链路带宽列为分析对象，说明控制面通信不是没有代价的背景活动。网络状态发生变化时，相关信息需要传播；传播是否可靠、是否落在可承受范围内，必须由实际环境中的记录回答。

带宽代价不能脱离时间和范围理解。稳定时期的交换与变化密集时期的交换并非同一状态，小范围内可接受的行为也不能直接推到更大拓扑。公开分析能够说明带宽值得被单独评估，却没有为所有年代、所有链路或所有实现提供一个永久数值。

因此，运营记录应把协议流量与拓扑变化放在同一时间线上。看到控制面流量增加时，需要知道是否同时发生了状态变化；看到链路利用率稳定时，也不能据此宣布数据库一定同步。带宽只是证据链的一层，必须与邻接、数据库和路径计算状态共同解释。

内存与 CPU 揭示设备边界

RFC 1245 同时分析内存与 CPU，表明链路状态路由并不只依赖网络传输。路由器需要保存拓扑状态，并在相关变化后执行计算。状态量和计算工作都落在具体设备上，因此协议设计最终会遇到设备容量、实现方式和运行负载的边界。

把内存与 CPU 分开记录很重要。数据库能够被保存，不代表设备可以在所需时间内完成处理；处理能力充足，也不代表状态存储没有压力。两个指标都正常，还不能自动证明邻接关系、数据库内容或最终路径正确。资源指标说明系统能否承担工作，状态证据说明系统实际上处理了什么。

这一层次区分也限制了过度推断。历史分析可以证明当时的报告认真考察了资源成本，不能证明今天的任一产品具有相同表现，更不能证明某个网络因为采用 OSPF 就获得了特定效率。当前结论必须来自当前设备和当前运行状态。

扩展性必须绑定到适用环境

RFC 1245 将规模限制和适用环境放在同一分析范围内。这种组合避免把“可以扩展”写成没有条件的标签。一个协议在某种拓扑、设备容量和变化模式下可用，不代表它在所有规模或所有运营条件下都表现相同。

规模不仅是路由器数量。状态对象增加、关系变多、变化传播范围扩大，都会改变数据库、带宽和计算负担。公开材料没有给本文提供一个可以套用到当前网络的统一阈值，因此更谨慎的结论是：扩展判断必须说明对象、范围、时间与测量方法，而不能只引用协议名称。

适用环境也是连续性判断的一部分。如果一个设计超出被验证的环境，运营者需要把未知明确标记出来。未知不等于一定失败，但它不能被包装成已经证明的安全。把边界写清楚，才能决定继续观察、限制范围或停止变化。

历史运行经验不是今天的部署基准

RFC 1245 记录了当时的测量与运行经验，这使文件比纯粹的架构描述更接近现实。但历史性正是它的边界。设备能力、链路条件和实现状态会变化，旧记录不能被改写成当前生产环境的性能数据。

合理的使用方式，是从历史材料中提取需要核对的关系：协议状态如何占用资源，拓扑变化如何触发处理，规模如何改变负担，什么环境被认为适合。随后，当前运营者必须使用当前观察填入这些关系，而不是沿用旧数值或旧结论。

这种时间边界也保护技术史。若把旧测量当作永恒事实，后来的差异会被误认为协议偏离；若完全忽略旧测量，又会失去标准化过程曾经如何面对现实成本的记录。正确做法是保留日期、范围和用途，让历史证据发挥参照作用而不冒充现状。

OSPF 的对象是自治系统内部的链路状态

RFC 1245 将 OSPF 描述为自治系统内部的链路状态协议。这个范围很重要，因为它说明本文讨论的是域内拓扑状态和相应路径计算，不能把结论扩张到所有路由协议、所有网络边界或所有跨域决策。

链路状态方法要求参与计算的路由器对拓扑拥有可比较的表示。这里的核心不是某个中央名册替所有设备作决定，而是分布式参与者围绕明确记录形成足够一致的状态，再依据共同规则计算路径。记录的准确性和同步性因此直接影响计算输入。

域内范围并不降低连续性要求。相反，只要多个设备共同依赖一组拓扑事实，状态差异就可能产生不同计算。运营者需要知道哪些关系属于当前范围、哪些记录已经同步、哪些变化仍在传播。协议名称不能替代这些具体问题。

1998 年 4 月：OSPF Version 2 把状态规则写成标准

RFC 2328 将 J. Moy 列为 OSPF Version 2 的作者，并记录为 STD 54。文件把相同的链路状态拓扑数据库、最短路径计算、区域、认证交换与等价多路径等对象写进公开标准。相较于只描述设计意图，这种标准记录让参与者能够对对象和处理规则建立共同理解。

共同语义仍然不是部署证明。标准可以说明一项状态应如何表达、路径应依据什么计算、范围应如何划分，却不能证明某台设备已经正确实现，也不能证明某一时刻的真实数据库完全一致。标准负责定义可核对的约束，运行证据负责说明约束在具体环境中是否成立。

Moy 的署名可以支持他与这份 OSPFv2 标准之间的公开关系。它不能支持“所有 OSPF 行为均由他独自决定”，也不能把后来每种实现、配置或运营结果归于个人。把作者、标准、实现与部署分层，是技术归因和路由运营共同需要的准确性。

相同拓扑数据库是一项持续条件

RFC 2328 所描述的相同链路状态拓扑数据库，是路由器依据共同事实进行计算的基础。这里的“相同”不应被当作一次性完成的标签，而是一项需要在状态变化中持续维护和核验的条件。拓扑一旦变化，参与者必须处理新的记录，数据库之间也需要重新达到一致。

数据库相同并不意味着设备的所有状态都相同。不同设备仍处于不同位置，也可能承担不同范围内的关系。共同之处是参与某一计算范围的拓扑事实应具有可比较含义。若对象身份、内容或新旧状态发生分歧，后续算法即使各自执行正确，也可能得到不同结果。

因此，运营观察不能只显示“数据库存在”。更有意义的问题是记录属于哪个范围、对应什么拓扑对象、何时更新、相邻参与者是否接受，以及计算所见是否与预期一致。记录数量本身不是准确性的替代品。

链路状态通告让拓扑变化拥有可追踪对象

链路状态通告把拓扑事实拆成可以传播和处理的记录。RFC 1245 与 RFC 2328 所形成的公开记录说明，OSPF 的运行判断需要面对带宽、传播可靠性、数据库状态与计算规则，而不是把“网络已经知道拓扑”当作不可见前提。

可追踪对象至少要保持身份、内容和范围的关联。若一项记录被误认为另一个对象，数据库可能形式完整却语义错误；若记录离开适用范围后仍被当作当前事实，路径计算就可能使用过期输入。唯一、准确和可更新不是行政要求，而是路由计算的前置条件。

通告进入数据库也不是事实链的终点。实现必须正确处理它，计算必须使用当前状态，最终转发还要由设备行为证明。协议记录为调查提供语言，却不能代替运行中的观察。

邻接状态把数据库同步落到具体关系

拓扑数据库的同步不是抽象的全网事件，而要通过具体路由器关系发生。来源记录把邻接状态和数据库同步列为可检查对象，这意味着运营者不能只问“OSPF 是否开启”，还要问哪些参与者建立了关系、哪些状态在这些关系之间被接受，以及当前差异是否已经消除。

邻接存在并不自动证明双方数据库一致。关系可能已经形成，而状态仍在变化；双方也可能各自拥有记录，却对新旧时间或适用范围存在差异。可靠观察需要把邻接、交换、数据库和路径计算串在同一对象链上，而不是用单个绿色状态概括全部过程。

当关系撤回或重新建立时，连续性问题会更明显。运营者需要区分设备仍在运行、邻接是否有效、数据库是否同步和路径是否可用。这些状态彼此相关，却没有任何一个可以无条件替代其他状态。

最短路径计算只会忠实处理它看到的状态

RFC 2328 明确最短路径计算在 OSPFv2 中的位置。算法按照已有拓扑状态得出路径，这使计算过程具备共同规则和可解释入口。但算法正确并不等于输入一定正确；它只会对自己看到的数据库执行规则。

如果两个路由器看到不同拓扑，分别运行同一计算仍可能得到不同结果。如果数据库中的对象错误或已经过期，计算可以在形式上成功，却把错误带入路由决定。由此可见，算法核验必须与输入核验分开，不能用“计算完成”证明拓扑事实正确。

这也是运行现实优先的直接体现。规范描述算法应当怎样工作，实现代码决定设备实际上怎样执行，当前数据库提供本次计算输入，转发观察说明结果是否落地。四者需要关联，任何一层都不能宣布其余层已经正确。

拓扑变化与可靠传播必须一起观察

链路状态路由需要面对拓扑变化。来源所列约束包括变化、传播可靠性、设备资源和区域边界，说明一次变化的影响不能只从发起点判断。记录是否到达相关参与者、数据库何时更新、计算何时反映新状态，都会影响过渡过程。

传播可靠并不等于瞬间完成。分布式系统在变化期间会经历中间状态，因此运营者需要保留时间顺序。若不同时间采集的邻接、数据库和路径记录被拼成一个没有时间边界的画面，报告可能展示一个从未真实存在过的组合。

变化观察还必须允许失败显现。缺失记录、未同步状态或无法确认的关系不应被自动填成正常。明确未知和受限范围，才能防止一项局部状态被误写成全局连续性。

区域既管理范围，也创造边界责任

RFC 2328 将区域纳入 OSPFv2 的标准对象。区域能够为拓扑状态和计算划分范围，但范围划分不会自动消除复杂性；它把部分复杂性转化为边界责任。哪些事实属于当前区域、哪些关系跨越边界、哪些变化影响更大范围，都需要清楚记录。

区域内状态正确，不能单独证明跨边界结果正确。边界两侧可能各自保持一致，却在交接关系上出现差异。运营核验因此既要看每个范围内部，也要看范围之间如何连接。对象在本地可读，还要确保跨界后的含义没有被错误扩大。

这类范围纪律也适用于人物与标准记录。某份 RFC 可以证明特定日期和文档中的署名，不能跨越边界证明当前职位或现实网络权限。无论是路由状态还是公共元数据，准确性都依赖对象停留在自己的适用范围内。

认证交换保护关系，但不替代状态正确性

RFC 2328 把认证交换纳入协议记录，说明参与者之间的交换需要受明确安全规则约束。认证可以帮助处理“谁在参与交换”这一类问题，却不能单独证明参与者提供的每项拓扑状态都最新、完整或与真实转发一致。

安全记录与路由状态因此必须分层。交换满足认证条件，是一项证据；数据库同步，是另一项证据；路径计算和转发结果还需要各自观察。把这些层压成一个“安全”结论，会掩盖认证之外仍然存在的状态和实现风险。

RFC 2329 后来将协议安全证据列入标准化记录，更说明安全不是附属口号。它需要有可核对的规则与事实，同时也要保留边界：标准化材料可以证明安全问题被纳入评估，不能证明所有配置、实现和运营环境都不会出错。

等价多路径要求“等价”有共同依据

RFC 2328 包含等价多路径。这个能力的前提不是路径数量本身，而是参与计算的拓扑状态和代价判断能够支持“等价”这一结论。若数据库不同步，或参与者对对象和范围的理解不同，表面相同的路径标签未必来自同一事实基础。

等价多路径也不能被改写成具体性能承诺。公开材料说明标准定义了这项机制，没有提供某个当前部署的流量分布、容量提升或故障结果。运营者需要分别观察路径计算、安装状态和真实转发，才能对具体环境作出有限结论。

从记录纪律看，“等价”应当能够被重建。调查者需要知道使用了哪些拓扑事实、哪些路径进入计算、何时得到结果，以及后续状态变化是否改变了等价关系。只有结果标签而没有输入关系，无法支持可靠解释。

路由数据库是记录者，不是现实的替身

链路状态数据库保存路由计算所需的拓扑记录。它的重要性来自记录准确、对象可区分并能随变化更新，而不是因为数据库本身可以替现实网络作最终证明。条目存在，不等于相应链路此刻一定按预期转发；条目缺失，也需要进一步判断是现实变化还是状态传播问题。

把数据库视为记录者，可以明确责任。协议和实现负责表达与维护状态，运营观察负责比较数据库、计算、安装与转发。发生冲突时，应先保存冲突本身，再判断哪一层偏离。用记录覆盖观察，或用一次观察抹去全部协议语义，都不能形成可靠诊断。

这种分工也限制权力外延。维护记录的一方对准确性和连续更新负责，不因此拥有对所有运行结果的解释权。路由合法性来自明确机制在边界内工作，而不是来自某一字段、名册或机构名称被赋予无限权威。

运行中的代码优先于协议口号

RFC 2328 可以定义数据库、计算、区域、认证和多路径规则，真正执行这些规则的仍是运行中的实现。若实现行为与规范预期不同，现实偏差必须被记录，不能因为标准写得清楚就宣布偏差不存在。运行中的代码优先，指的是现实判断要从实际行为出发，再用标准定位差异。

这并不意味着规范不重要。没有共同规范，观察到的行为难以判断是正确选择、实现差异还是故障。更成熟的关系是双向核对：规范提供对象和边界，运行代码提供实际处理，设备状态提供当前实例，转发观察提供有限结果。

运行优先也拒绝宣传式因果。某项能力被写入标准，不等于所有实现已经支持；实现宣称支持，不等于当前配置启用；配置启用，不等于数据库与转发符合预期。每一次从“应当”走向“实际”，都需要对应层的证据。

1998 年的标准化报告要求实现与部署事实

RFC 2329 将 J. Moy 列为 OSPF 标准化报告的作者。该报告记录 OSPFv2 如何满足 Full Standard 所需条件，其中包括实现、部署与协议安全方面的依据。这份文件的重要性不在于重复 RFC 2328 的协议文本，而在于标准化判断需要面对已经运行的实现和实际使用记录。

这构成一条清楚的决定、约束与结果链。决定是推进 OSPF 的标准化；约束包括互操作、协议变化、运行经验和安全要求；结果是判断建立在规范之外的可观察记录上，而不是只依据对架构的赞成。

报告本身是信息性记录，不应被当成另一个协议标准。它能够证明标准化过程记录了哪些类别的依据，不能证明今天任一实现的质量，也不能把当年的部署材料扩张为当前采用率。

实现证据把共同语义带到运行层

实现证据回答的是规范能否被不同代码转化为可执行行为。RFC 2329 将实现纳入标准化依据，说明协议文本的完整性必须接受实际执行的检验。若对象只能在文档中成立，却无法在运行系统中得到一致处理，共同语义就没有完成从规则到现实的过渡。

实现存在仍然不是全部答案。需要关注实现处理的版本、范围和状态，也要区分代码支持与当前启用。来源没有提供任何具体产品或版本资料，因此本文不能对某个实现作评价，只能说明实现事实在标准化判断中具有独立位置。

这一边界防止两种错误：一是用协议文本宣布所有代码已经正确，二是用某个实现的行为改写协议对全部参与者的共同含义。标准和实现相互核对，但各自证据范围必须保留。

部署记录说明机制遇到了真实环境

RFC 2329 还记录部署方面的依据。部署使协议面对真实拓扑、设备约束和运营变化，因此比纯粹的设计讨论多了一层现实检验。它可以说明标准化过程没有只停留在纸面，却不能自动证明部署规模、普及程度或长期结果。

部署记录需要日期和范围。某一时期、某些环境中的使用事实，不能无条件推到今天，也不能推到没有被记录的运营者。若要判断当前连续性，仍需当前数据库、邻接、计算和转发证据。

对技术治理而言，部署事实最有价值的作用是暴露约束。标准对象进入实际环境后，带宽、内存、CPU、同步和安全问题会以具体状态出现。把这些状态反馈到判断中，才体现运行代码与现实记录优先于架构宣传。

安全证据必须与协议状态共同解释

RFC 2329 将协议安全纳入 OSPFv2 标准化依据，而 RFC 2328 记录认证交换。这两项公开事实说明，安全不是与路由状态分离的装饰。参与关系、状态交换和后续计算共同构成运行链，任何一层的结论都需要保持自己的对象和边界。

认证通过并不能证明拓扑正确，拓扑数据库一致也不能证明所有安全配置合理。相反，安全核验需要知道交换发生在哪些关系上、对象如何被识别、状态怎样进入数据库，以及异常时系统如何限制影响。单个通过标志不能概括整条链。

来源没有提供现实网络的配置、事件或攻击资料，本文也不据此推测。能得到的有限结论是：协议安全曾作为标准化依据被明确记录；任何当前安全判断仍需当前实现、配置和观察支持。

Full Standard 不是对所有实现的永久担保

RFC 2329 记录 OSPFv2 满足 Full Standard 条件，这是一个有日期、有范围的标准化事实。它不能被解释为所有后来实现都相同，也不能成为所有部署在任何条件下都连续、安全或高效的永久担保。

标准化状态解决共同语义和证据门槛问题，不替运营者维护当前状态。拓扑会变化，设备会重启，代码和配置会更新，邻接与数据库也可能出现差异。每一项现实变化都要求重新观察，不能只引用标准地位。

同样，个人署名也不能因文件地位而无限扩张。Moy 的作者关系应被准确记录，但 Full Standard 是标准化记录，不是个人所有权，也不是对现实网络的当下授权。

2003 年 11 月：优雅重启把连续性写成条件

RFC 3623 将 J. Moy 列为优雅 OSPF 重启的共同作者之一。文件所描述的目标是在 OSPF 软件重启期间，在明确条件下让重启路由器继续位于转发路径上。关键不是“重启时永不断流”，而是哪些条件允许暂时维持转发，以及条件失效时如何停止这种安排。

这项机制把控制过程与转发连续性分开观察。软件重启意味着协议状态需要重新建立，而转发路径可能在帮助者支持和拓扑假设成立时暂时保留。两层可以在有限窗口内不同步，但差异必须受边界约束，不能被当作正常稳定状态无限延长。

共同署名边界同样重要。RFC 3623 可以证明 Moy 是共同作者之一，不能把全部机制归为他的独自成果，也不能证明所有 OSPF 网络采用该过程。标准轨道文件提供共同规则，不提供普遍部署事实。

帮助者支持是一项实时关系，不是静态标签

RFC 3623 的连续性依赖邻居提供帮助。帮助者支持不是写在计划中的抽象愿望，而是重启期间必须成立的关系条件。只有相关邻居愿意并能够在规定边界内维持所需状态，继续转发才有依据。

这使连续性从单个路由器属性变成关系属性。重启路由器本身准备就绪，不能证明邻居状态符合要求；邻居具备相关能力，也不能证明本次重启中的帮助关系仍然有效。运营者需要观察当前关系，而不能根据设备名称或历史配置进行推断。

帮助关系还必须允许撤回。当支持安全转发的条件不再存在，继续保持旧路径会扩大风险。显式撤回不是连续性失败的反面，而是有界连续性的一部分：系统知道何时不应继续假装状态仍然可靠。

拓扑保持不变是连续性的核心假设

RFC 3623 将拓扑假设置于优雅重启边界之内。重启期间暂时保留转发，依赖相关拓扑没有发生使旧路径不再安全的变化。若拓扑改变，先前的转发状态可能不再对应当前网络，继续使用就会让连续性从保护机制转成风险来源。

“拓扑未变”必须由当前状态支持，不能只由重启计划声明。邻接、链路状态记录和帮助者观察需要共同提供判断。缺少观察时，应把条件标为未知，而不是把未知当作未变化。

这一要求说明运营连续性不是避免所有中断的绝对目标。更优先的目标是避免在证据失效后继续转发过期状态。必要时回到正常重启，可能带来显式收敛过程，却比在错误拓扑上维持表面连续更可控。

过期转发与环路风险划定停止边界

RFC 3623 的约束包含过期转发环路风险。优雅重启之所以需要帮助者和拓扑条件，正是因为控制状态与保留的转发状态可能在重启窗口内产生差异。若差异失去边界，旧路径可能与当前拓扑冲突。

停止条件因此与启动条件同等重要。只描述何时允许继续转发，而不说明何时必须退出，会把临时机制变成没有期限的例外。运营者需要让拓扑变化、帮助关系失效或其他不再安全的条件能够触发明确行为。

风险记录也应避免过度承诺。RFC 给出需要防范的机制边界，不证明任何具体网络曾经发生或避免了某次环路。没有现实事件资料，就只能讨论条件和失败语义，不能制造事故或成效叙事。

回到正常重启是一种安全动作

当支持优雅重启的假设失败时，RFC 3623 要求回到正常重启过程。这个回退不是设计尴尬，而是机制保持诚实的方式。系统不再拥有继续保留转发的依据，就应停止依赖旧状态，让协议按正常路径重新建立当前关系。

正常重启也需要观察。回退动作发生，不等于数据库已经同步、路径已经重新计算或转发已经恢复。运营者仍需沿邻接、拓扑记录、计算和转发顺序核验，直到各层状态重新对齐。

可撤销性是连续性设计的核心。只有能够退出，临时例外才不会成为永久隐患；只有记录退出原因，后续调查才知道连续性为何停止。明确失败比隐藏失败更有利于长期可靠性。

运营连续性是有条件、可观察、可撤销的

从 RFC 1245 到 RFC 3623，连续性逐步显现为一组具体关系。资源必须能够承担协议工作，数据库需要保持准确与同步，计算需要基于当前状态，帮助者关系需要成立，拓扑假设需要继续有效。缺少任何关键条件，都不能只靠“优雅”这一名称维持结论。

可观察意味着每个条件都能对应到状态，而不是隐藏在口号里。可撤销意味着条件失效时系统有明确退路，而不是继续维护已经失真的绿色结果。有条件并不削弱连续性；它使连续性从宣传承诺变成可以管理的运行合同。

这种合同也要求时间一致。帮助者状态、拓扑状态和转发状态若来自不同时间，组合结论可能错误。运营记录必须说明每项事实何时成立，才能判断它们是否共同支持当前动作。

公开人物页面提供署名边界，不提供当前权限

IETF Datatracker 的 John Moy 人物页面 在 2026 年 7 月 31 日的留存状态中列出 11 份 RFC，主题跨越 OSPF Version 2、OSPF 标准化、用于 IPv6 的 OSPF 与优雅重启。页面在该日期报告没有活跃的 IETF 角色。

这是一项有日期的公开著作元数据，可以连接人物与文档，也可以限制推断范围。它不能证明当前雇主、当前位置、私人联系方式、现实网络权限或对某个运营环境的控制。历史页面上的标识也不能被延伸成今天的组织关系。

“没有活跃角色”同样只能按留存日期和页面含义使用。它不是对人物技术贡献的否定，也不能证明其他未列出的现实活动。人物名录负责记录公开关系，不负责替现实世界授予或撤销全部权威。

署名准确性与路由状态准确性遵循同一纪律

RFC 1245 中的编辑、RFC 2328 和 RFC 2329 中的作者、RFC 3623 中的共同作者，是不同关系。把它们全部压成“独自发明 OSPF”，会像把不同拓扑对象压成一个路由条目一样丢失关键身份。准确归因必须保留角色、日期、文件与共同署名边界。

这种准确性不仅保护个人，也保护技术判断。若一项共同成果被写成个人权威，读者可能跳过对实现和运行状态的核验；若署名被模糊，真实贡献又无法被正确追踪。最稳健的记录既不夸大，也不抹除。

公开元数据和路由数据库都应当是可靠的记录者。它们提供可追踪关系，却不成为现实的主权者。当前行为、当前状态和当前权限仍需当前证据。

三条决定、约束与结果链构成 OSPF 现实层

第一条链来自 RFC 1245 与 RFC 2328。决定是用同步的链路状态数据库表示域内拓扑，并从最短路径树计算路由；约束包括拓扑变化、传播可靠性、内存、CPU、区域边界和认证交换；结果是运营者可以通过通告、邻接、数据库同步和计算规则检查路由决定。结果是可解释性，不是自动正确。

第二条链来自 RFC 2329。决定是以实现和部署事实配合协议文本推进标准化；约束包括互操作、协议变化、运行经验与安全要求；结果是标准化判断必须面对运行代码和现实记录。结果是更强的证据基础，不是对未来所有实现的永久担保。

第三条链来自 RFC 3623。决定是在 OSPF 软件重启期间暂时保持转发；约束是邻居帮助、拓扑不变和过期转发环路风险；结果是连续性只能在条件成立时维持，并在依据消失时回到正常重启。结果是有边界的恢复路径，不是无条件不中断。

五项来源能证明什么，也明确不能证明什么

五项来源能够证明一组有界事实。RFC 1245 记录 Moy 作为编辑参与 OSPF 协议分析，并把带宽、内存、CPU、规模和运行经验列为分析对象；RFC 2328 记录他作为 OSPFv2 标准作者，以及数据库、最短路径、区域、认证和等价多路径等规则；RFC 2329 记录标准化所用的实现、部署和安全依据；RFC 3623 记录共同署名的有条件优雅重启；Datatracker 提供有日期的 11 份 RFC 与无活跃角色元数据。

这些来源不能证明 Moy 独自发明 OSPF 或优雅重启，不能证明任何当前雇主、客户、产品、运营商、部署比例、性能提升或事故结果，也不能证明所有 OSPF 实现都采用 RFC 3623。它们没有提供对现实生产网络的当前控制权信息。

负面边界不是文章之外的附注，而是本文技术方法的一部分。协议状态超出范围会误导路径计算，人物材料超出范围也会误导历史与权责判断。只陈述对象、日期、关系和有限结果，才能让公开记录经得起复核。