跳到主要内容

14. 相对于 BCP 26 早期版本的变化

14.1. 2016: 本文档相对于 RFC 5226 的变化​

重要新增:

  • 移除了 RFC 2119 关键词、样板文本和引用, 更倾向于使用平实的英文 -- 这不是一份协议规范.

  • 新增第 1.1 节, 将 IANA Considerations 留给 IANA

  • 新增第 1.2 节, 获取更新信息

  • 新增第 2.1 节, 注册表的组织

  • 在第 4 节中新增了选择合适策略的最佳实践.

  • 新增第 4.12 节, 组合使用多个策略

  • 新增第 2.3 节, 为注册表指定变更控制

  • 新增第 3.4 节, 早期分配

  • 将每个知名策略移至第 4 节的单独子节.

  • 新增第 5.4 节, 专家审查与文档生命周期

  • 新增第 7 节, IANA 注册表中的文档引用

  • 新增第 8 节, 在"bis"文档中应该做什么

  • 新增第 9.5 节, 联系人与被分配者或所有者

  • 新增第 9.6 节, 关闭或废弃注册表/注册项

澄清及其他:

  • 进行了一些重组 -- 为了让文本更清晰、更易读而调整了内容位置.

  • 对 IANA 注册表的标识以及为其使用 URL 做了澄清.

  • 澄清了"Unassigned"与"Reserved"之间的区别.

  • 在"Expert Review"中就对指定专家的指示做了一些澄清.

  • 在"Specification Required"中就该策略如何声明做了一些澄清.

  • 通篇进行了各种小幅澄清和编辑性修改.

14.2. 2008: RFC 5226 相对于 RFC 2434 的变化​

变化包括:

  • 对文本进行了大幅重新排序, 以扩展描述并更好地归类诸如"更新注册表"与"创建新注册表"之类的主题, 从而使作者更容易找到最适合其需求的文本.

  • 进行了大量编辑性修改以提高可读性.

  • 将术语"IETF Consensus"改为"IETF Review"并增加了更多澄清. 历史表明, 人们看到"IETF Consensus"这个词 (而不查阅实际定义) 就很快对该术语在 IANA Considerations 语境中的含义做出错误假设.

  • 将"RFC Required"加入已定义策略列表.

  • 关于"RFC 中应放入什么"的指示和示例要明确得多.

  • "Specification Required"现在意味着使用指定专家来评估规范是否足够清晰.

  • 新增了一节描述临时注册.

  • 大幅修改了"Designated Experts"一节的措辞. 主要目的是明确专家评审者对社区负责, 并为默认情况下的审查标准提供一些指导.

  • 修改了措辞以移除任何特殊申诉路径. 使用正常的 RFC 2026 申诉路径.

  • 新增了一节关于回收未使用值的内容.

  • 新增了一节关于事后注册的内容.

  • 新增了一节, 说明用于评估可能分配 (例如由指定专家进行) 的邮件列表受正常 IETF 规则约束.