4.11. 使用已知的注册策略

由于已知策略受益于社区经验和广泛理解，因此鼓励使用它们，而创建新策略需要附带合理的理由。

引用一个或多个已知策略并包含关于审查过程应考虑哪些因素的额外指南也是可以接受的。

例如，对于媒体类型注册 [RFC6838]，涵盖了许多不同的情况，涉及使用 IETF Review 和 Specification Required，同时还包括指定专家应遵循的特定附加标准。这并不意味着代表一个注册程序，而是展示在需要覆盖特殊情况时可以做什么的示例。

从 "First Come First Served" 到 "Standards Action" 的已知策略按严格程度递增的顺序指定了一系列策略（使用第 4 节完整列表中的编号）：

4. First Come First Served (先到先得)

• 无需审查，最少文档。

5 和 6（严格程度相同）

• 5. Expert Review (专家审查)：专家审查，需要足够的文档供审查。
• 6. Specification Required (需要规范)：足够的稳定公开文档以实现互操作性。

7. RFC Required (需要 RFC)

• 任何 RFC 发布，IETF 或非 IETF 流。

8. IETF Review (IETF 审查)

• RFC 发布，仅限 IETF 流，但不必是标准轨道。

9. Standards Action (标准行动)

• RFC 发布，IETF 流，仅限标准轨道或 BCP。

可能需要 IETF Review 或 Standards Action 的情况示例包括以下内容：

• 当资源受限时，例如一个字节（或两个字节，或四个字节）中的比特，或有限范围内的数字。在这些情况下，允许未经仔细审查和社区共识同意的注册可能会过快耗尽允许的值。

• 当需要彻底的社区审查时，以避免以可能造成损害的方式扩展或修改协议。一个例子是定义新的命令代码，而不是使用现有命令代码的选项：前者可能需要严格的策略，而后者可能适合较宽松的策略。另一个例子是定义改变现有操作语义的协议元素。

• 当存在安全影响时，需要彻底审查以确保新用途是合理的。这方面的例子包括可接受的哈希和加密算法列表，以及系统范围内传输端口的分配。

当审查要求 IANA 创建新注册表或将注册策略更改为比 Expert Review 或 Specification Required 更严格的任何策略的文档时，IESG 应该要求提供理由，以确保已考虑更宽松的策略，并且更严格的策略是正确的选择。

因此，文档开发人员需要预见这一点，并记录他们选择指定策略的考虑因素（理想情况下在文档本身中；如果做不到，则在牧羊人总结中）。同样，文档牧羊人应确保在将文档发送给 IESG 之前已证明所选策略的合理性。

当规范修订时，应根据策略设定以来的经验审查注册策略。