RFC 1916：重编号程序之前的现场日志

摘要

RFC 1900 刚刚把问题说清：重编号昂贵、繁琐、容易出错，而聚合路由又会让某些网络更可能面临地址更换。PIER 需要尽快拿出实用材料。但 RFC 1916 没有用紧迫感替代知识，它把核心动作写成“征集”。

文档明确属于 Informational，不制定互联网标准。征集重点是已经发生或正在发生的 IPv4 工作，尤其是最常见的单宿主、非中转网络。未来协议也许会改善环境，但那不是这次调查的对象。工作组需要的是 1996 年现有设备、软件和组织真正经历了什么。

PIER 章程也限制了自身角色。它负责识别流程、技术、工具与硬编码地址的位置，若发现协议需要改进，则向相应工作组提出建议；PIER 本身不开发这些协议。工作组能够设计问题与编辑材料，却不能替运营者经历迁移，也不能替供应商修理产品。

事后报告需要重建环境、准备、执行、奏效之处和意外失败，还要说明为何选择这条路径、放弃了哪些备选方案、事前怎样做会更容易、下次会如何改变。

进行中的日记保留另一种事实。故障发生时的一行记录，会留下先后顺序、当时判断和临时绕路。项目结束后，团队很容易把它压缩成“夜间出现小问题，随后解决”。成功结局会把原本不确定的岔路修饰成必然步骤。

复盘能提供较完整的因果解释，却容易合理化；日记保留惊讶，也会保留当时的误判。两者并列，读者才可能比较“当时看到什么”和“后来认为为什么”，而不是把一种叙述当作全部现实。

RFC 1916 不满足于工具名称。提交者要说明从哪里取得、用于什么、怎样使用、优势和限制。若工具是临时写成的脚本，还应交代它如何获得机器清单、检查哪些文件、用何种规则寻找地址。

征集列出的任务从发现对象一直延伸到外部系统、依赖关系、通知、配置生成、协调、执行、验证、排障、维持服务和告知用户。每个环节都可能有不同控制者。一个扫描器完成其中一步，不等于掌握整场迁移。

更重要的是，PIER 也征集“本来需要却不存在的工具”，以及表面有用、实际制造新问题的工具。失败与空白若不进入目录，工具清单就只剩成功展示，人工成本和风险反而消失。

对于嵌入地址的应用和硬件，征集字段更具体：应用名称、版本、平台、供应商、操作系统及其版本、解决步骤和所需提前量。地址可能被绑定到安全密钥或许可证，也可能写入需要重新制造的硬件。供应商若已停业，网络可能只能更换产品或采用专门办法。

“某软件不支持重编号”只是一句传闻。限定为某版本、某平台、某支持流程和某等待周期，另一个运营者才知道自己的环境是否可比。精确字段也防止供应商品牌被当作统一结论。

证据仍有边界。供应商能说明支持方案，运营者能报告一次安装的结果，PIER 能编辑发表。三者都不能单独证明所有版本和网络都会得到同样结果。

PIER 接受非正式材料。若要把经历公开为案例，需要提交者许可；人员、机构和网络名称也可隐藏。文档甚至邀请关于政治与文化敏感性的实证建议。

这是证据设计的一部分。组织若不必公开承认昂贵失误、停产设备或困难谈判，可能更愿意交出真实细节。但匿名也会削弱外部核验规模、拓扑和时间线的能力。披露数量与可复核性并不总能同时增加。

截止日期让征集能够行动，却也会选择样本。耗时较长的迁移、没有写作余力的团队，以及几个月后才触发的低频系统，都可能落在窗口之外。收集到的信息可以很有用，却不能因此自称完整互联网样本。

当前 IETF Datatracker 把 PIER 标为已结束，并列出 RFC 1916、RFC 2071 与 RFC 2072 三份关联 RFC。另一方面，章程曾列出工具目录、案例史、地址使用位置等更多里程碑。

这两项官方记录回答不同问题。文档页证明三份 RFC 被保留为 PIER 成果，不能证明每项里程碑都变成终稿、每类投稿都足够丰富，或后来某句话源自哪位匿名运营者。目录能说明它现在装有什么，不能替缺失材料生成出处。

RFC 2071 后来界定重编号及其原因，同时明确不讨论方法、技术和工具。RFC 2072 给出以路由器为中心的详细规划，又提醒读者：所述功能并非每种实现都具备，外部合作方的地址也不受企业控制。

2010 年的 RFC 5887 再次审视机制和缺口。2011 年批准的 6RENUM 章程仍从现有实践、能力清单、场景和运营者输入开始，再讨论未来解决方案。这不证明十四年毫无进展，而是说明运行系统不断产生地方差异，中央文本不可能预先拥有全部知识。

RFC 1916 留下了一种少见的制度克制：可以公开问题，可以规定证据格式，但不能用文档编号把尚未观察的结果变成事实。程序的可信度，从现场日志开始。