摘要

  • RFC 9519 将多组 SSH 参数的普通登记政策由 IETF Review 改为 Expert Review，同时保留 Standards Action 和 Private Use 的不同边界。
  • 专家批准解决的是公共命名空间中的分配与冲突，不证明软件已经实现、两端能够协商、策略允许启用或安全结论仍然有效。
  • 可审计的证据链必须把申请、专家理由与 IANA 更新，同代码、版本、协商记录、互操作、部署和退役分开保存。

想象一项 SSH 扩展刚获得唯一名称。产品表、日志与规范从此可以指向同一个符号，两个团队也不必抢占相同字符串。组织很容易在这一刻把“已登记”读成“可采购”“可启用”甚至“已获得安全认可”。RFC 9519 真正改变的却只是一道制度门：谁可以批准一个名称进入登记表，以及批准需要经过什么公开记录。

改变的是分配权，不是事实层

RFC 9519 在 2024 年成为 Proposed Standard，并更新 RFC 4250、RFC 4716、RFC 4819 与 RFC 8308。对其列明的普通范围，政策由 IETF Review 变为 Expert Review；原本要求 Standards Action 的狭窄范围仍需更重程序，Private Use 仍是允许局部意义重复的独立空间。

这不是把审查取消，而是把首轮判断委托给指定专家池。RFC 8126 要求专家依据登记表的具体指引审查足够文档；IESG 可以任命或更换专家，利益冲突应披露并回避，困难案件可以引入更多专业意见，争议决定仍处在申诉与制度问责范围内。RFC 9519 又把申请渠道、专家池和通知 IANA 的节奏写进 SSH 的操作安排。

IANA SSH 参数登记表 展示了这种分工：一些消息编号仍要求 Standards Action，许多算法名称范围则标注 Expert Review、专家与申请入口。登记表不是“技术成熟度排行榜”，而是一张决策权地图。

名称被分配后，支持证据才开始生成

SSH 协议自己已经说明为何不能把登记行当成部署证书。RFC 4253 让客户端与服务器通过有序名称列表选择双方都支持的算法。登记表中存在一个名称，并不能使它自动出现在任一端的列表里；两端都列出它，也不能证明实现正确、默认策略开启或连接满足风险要求。

RFC 8308 引入密钥交换后的扩展信令，因为对端是否声称支持某项扩展必须在真实会话中观察。此后仍需互操作测试来确认两份代码赋予名称相同语义，再由生产遥测说明它在真实策略、失败与回退条件下如何运行。RFC 9142 还表明，历史上已经登记的机制后来可以被弃用。登记表需要保留名称以解释旧流量，但保留不等于继续推荐。

两本账应当永远分开

分配账记录具体登记表与范围、申请者、名称或数值、变更控制者、支持文档、提交时间、公开讨论、专家身份、冲突与回避、问题、修订、决定理由、批准时间及 IANA 发布。执行账记录仓库提交、首个版本、测试向量、支持角色、协商抓包、默认配置、策略门、互操作伙伴、运营启用、失败遥测、维护责任与退役方案。

把两本账混在一起会产生相反的误判：供应商可以借 IANA 行号暗示产品已经可靠，批评者也可能因登记表不含生产证据而否定专家审查的命名价值。正确评价是：制度是否无冲突地分配名称、统一应用标准并留下可问责理由；软件是否有代码与运行证据。

这里还有一个容易漏掉的时间差。申请材料可以描述预期语义，专家也可以判断描述是否足够清晰，却无法预先保证每个实现都会忠实遵循它。第一份代码可能只支持客户端角色，第二份代码可能使用不同的失败默认值，第三个产品可能把功能藏在实验开关之后。因而“首个实现”也不是采用终点；至少要知道支持哪一端、在哪个版本出现、默认是否开启、同谁完成互操作，以及维护者是否承诺跟进规范澄清。

同样，专家审查的成功不能只用批准数量表示。若申请在私下反复修改、公开列表没有留下关键问题，或批准后长时间没有更新登记表，高吞吐率会掩盖可审计性下降。相反，一项被拒绝或撤回的申请可能说明制度正在阻止模糊名称占据永久位置。决定质量需要分母：总申请、等待时间、修订、回避、撤回、拒绝和实际更新都应同时可见。

登记范围本身也决定了证据含义。Standards Action 保留下来的位置通常承载更敏感或更稀缺的协议空间，不能因为相邻范围改为 Expert Review 就推定门槛同步下降。Private Use 则允许组织在封闭环境中试验，却可能与另一组织使用相同数值表达不同语义；一旦跨越边界互联，私有值不能凭使用年限自动获得公共权利。审核材料必须写清申请落在哪个范围、为何适用该政策，以及是否存在更合适的扩展机制。

变更控制者的存在同样关键。一个名称可能由最初申请者提出，却在多年后由不同团队维护。若参考文档失联、联系人离职或实现停止更新，登记表仍需要说明谁能澄清语义、如何标注状态变化、是否允许替代引用。否则永久标识符会把暂时的组织承诺冻结成外部依赖。定期复核联系信息和参考资料，不是重新审批准入，而是维持登记项可解释性。

这也意味着“无人反对”不能代替积极证据。公开讨论可能很安静，但安静只说明没有记录到异议；它不说明多个实现团队已经阅读、理解并承诺采用相同语义。专家可以据此完成命名判断，部署委员会却必须等待后续事实。

原始轨迹可以复核。RFC Editor 保留信息页、纯文本、XML与勘误查询，IETF Datatracker 保留RFC 历史和最终草案修订。这些材料能重建政策如何形成，却不能替代之后的实现事实。

分析框架来自三篇独立文章：运行代码优先、最小初始规范与自愿采用以及现实层与符号权力。它们在这里指向同一条边界：制度符号可以协调行动，但不能冒充尚未发生的运行结果。