摘要

  • RFC 1550 邀请所有相关方陈述 IPng 必须满足的需求，却暂时不接收针对具体候选方案的评议。
  • 清晰度审阅、可行性审阅和公开保存各司其职；文稿被审阅或发布，并不等于观点获采纳。
  • 后来的记录显示共收到 21 份白皮书，它们参与形成技术准则，但推荐协议与网络实际采用仍是另外两次行动。

先把答案请出房间

1993 年 12 月，Scott Bradner 与 Allison Mankin 发布 RFC 1550。RFC Editor 信息页和 IETF 文档页都把它列为 Informational；它不规定任何 Internet Standard。

它做的是搭建一个入口。所有 interested parties 都可以提交白皮书，说明 IPng 必须满足的特定要求，或可能影响选择的因素。第一页举的例子很不“协议”：电力公司代表可以解释大量电表接入后需要怎样的寻址与规模；另一位作者可以讨论未来无线连接对 IPng 的影响。

这两个例子把后果放在设计之前。一张包头图能说明字段，却不能独自说明运营者的迁移成本、移动设备的间歇连接、企业防火墙的现实或行业采用的激励。若这些问题等到候选方案已经形成才出现，最容易被称为例外，或者被解释成通往既定答案必须支付的代价。

当时还不准替候选方案辩护

RFC 1550 明确划了一条时间线：当前不接收评价特定 IPng proposal 的白皮书。等各方案文档被认为清楚、完整之后，才进入那一阶段。

这不是永远拒绝比较，而是防止答案反过来塑造问题。候选名称一旦进入讨论，移动性需求很容易被写成某种机制的卖点，迁移困难会被写成某个赢家的暂时缺陷，安全顾虑也可能只剩“以后修补”。先收需求，让作者有机会只说“这个环境有这项约束”，不必立刻附带“所以应选我的设计”。

今天知道 IPv6 后，很容易把所有旧文件排成必然前史。但 1993 年 12 月的人并不知道终点。RFC 1550 保存的正是答案尚未获得回溯特权的时刻。

开放投稿不是全民授权

所有相关方都能投稿，扩大了证据入口，却没有产生一个投票体。文档没有说每份白皮书是一票，也没有说提交者能够代表没有到场的同业、用户或网络。

审阅程序同样克制。第一轮只查清晰度：IPng directorate 与 external review board 的成员可以指出含义含混之处，并建议作者重看。第二轮另做技术可行性审阅，而且明确不做 value judgment。作者自己决定是否修改，也可以撤稿。完成这些步骤的文稿先成为 Internet-Draft，经过一段时间再以 Informational RFC 保存，构成 IPng 的历史记录。

因此，读懂、可行、发表、接受是四件事。RFC 1667、RFC 1669、RFC 1675 与 RFC 1678 都提醒读者：发表不代表 IPng area 接受其中观点。

行业名义也有边界。RFC 1674 从蜂窝行业视角提出需求，同时声明这不构成整个行业、CDPD 联盟或成员公司的背书与承诺。RFC 1686 对 Cable TV 行业作出相近限定。标题可以交代作者所处的现实，但不能替整个行业签字。

半页摘要，十页正文

投稿的 executive summary 最长半页，全文不超过十页；参考版本采用 ASCII 并遵循 RFC 格式。文章要聚焦，还要给出支持论点的具体数据出处。不同问题若确有展开需要，同一作者可以分别投稿。

统一外形并不会让各种证据变成同一单位。市场预测不能直接和故障容忍度相加，运营经验也不是实验室性能数据。但半页摘要迫使主张露面，十页上限让材料成为可处理的证据单元，明确出处则给后来的准则编写者留下核验路径。

格式还能限制一种注意力垄断：资源最多的参与者不能仅靠篇幅占满全部档案。不过它没有补齐缺席者。没看见征集、来不及在 1994 年 2 月 1 日前回应，或无法把经验写成规定格式的人，仍然不会凭空出现在记录中。

十六个问题不是十六项评分

RFC 1550 列出十六组工程考量，并特意说没有先后次序：规模；选定、开发与部署所需时间；迁移与部署；安全；配置、管理和日常运营；移动主机；流与资源预留；基于政策的路由；拓扑灵活性；适用环境与市场；尽力而为的 datagram 服务；计费；对各种通信介质的支持；鲁棒性与容错；技术拉力；以及应交给 directorate、工作组或其他参与者的行动项。

运营者被直接写进问题：网络越大越复杂，IPng 应包含或避免什么，才能减少对日常运维的影响？鲁棒性一项则承认一种重要无知：IPv4 互联网也许因为尚未理解的缺陷而仍能工作，新协议不能在优化显眼指标时无意中丢掉这种韧性。

这张表不是总分表。作者可以选答，也能提出清单外的相关问题。涉及时间的材料会送往 ALE，迁移材料会送往 TACIT。它安排证据去向，却不假装路线本身已经决定权重。

二十一份文稿，二十一种位置

后来的 RFC 1752 记录，征集共收到 21 份白皮书，并试图触及传统 IETF 圈子内外。留存的文稿说明“外部”不是一个声音。

RFC 1667 从分布式国防建模与仿真出发，提出实时响应、multicast 与资源预留要求。RFC 1669 讨论市场可行性，拒绝把技术优越自动等同于采用。RFC 1673 带来电力行业观点，正好回应征集第一页的电表例子。RFC 1674 强调移动性以及偶尔才连网的主机。

RFC 1675 提出一条安全底线：下一代协议至少不能让情况更糟。RFC 1678 从承载关键业务的大型企业网络出发，并把所需能力与具体解决方案分开。RFC 1686 依照征集框架逐项呈现 Cable TV 网络的条件。

迁移意见尤其揭示本地控制。RFC 1671 判断迁移将持续多年，每个 site 都要制定自己的分阶段计划，只有最小型的网络才可能想象一次性 flag day。RFC 1710 是 SIPP 白皮书，它直言：若无法让现有 IPv4 系统实际迁移，再好的新协议也不够；互联网规模太大，不可能实行统一受控 rollout。

“21”不是代表性比例。资料不能证明所有受影响者都能投稿，也不能证明每份稿件影响相同。它证明的是，多种现实已被变成带作者、带保留条件、能被引用和反驳的公开主张。

证据进入准则，但准则不替人决定

RFC 1752 说明，这些白皮书、一次 requirements BOF、IPng Area Directorate 的讨论以及 big-internet 邮件列表，共同参与修改后来发表为 RFC 1726 的技术准则。信息页把它保存为另一份独立文件。

RFC 1726 没有把决策包装成算术。它不为准则排序加权，并尽量描述目标而非强制某种工程办法。比如，路由可扩展才是需求，route aggregation 只是可能的手段之一。作者也承认，准则可以帮助识别严肃候选，却不足以自动解决性能与功能之间的全部取舍。

责任仍需落到具体角色。RFC 1719 把提出 IPng recommendation 的责任交给 IESG，要求程序提前公开，并在最终推荐前留出充分的 community comment。意见约束判断，但不能让判断者消失在“community”这个词后面。

RFC 1752 信息页所对应的是较晚的推荐行动。正文评价 CATNIP、SIPP、TUBA，并推荐以修订后的 SIPP 为 IPng 基础。RFC 1550 自己没有选中任何方案。

三张收据

Heng Lu 对多利益相关方幻象的批评提供了一条当代边界：参与可以带来证据、专长、警告与反对，却不因此获得约束实际承担损失者的权力。

以此观察 RFC 1550，它的可贵之处不是“所有人共同决定”，而是广泛入口没有冒充主权。文稿有作者，行业名义有限定，技术审阅不等于采纳，最终推荐由另一个有名的责任主体作出。

最小初始规范、本地化未来决策与自愿采用又区分文件与实际运行。Running-Code Primacy要求变化接受实现检验；现实层要求请求、推荐、部署和观察分别留证。

这些是后来形成的语言，不能倒推为 1993 年作者的主观理论。但它们帮助保留史料中本来就存在的三张收据：被听见，获选定，被采用。

电表没有为 IPv6 投票，无线链路也没有授予任何机构永久权力。它们完成的是更窄、更难替代的工作：在候选方案能够替自己定义问题之前，让未来协议先面对别人的后果。

来源