9. 变更流程 (VARYING THE PROCESS)

变更流程 (VARYING THE PROCESS)

本文档规定了制定 Internet Standards 及相关文档的规则和过程, 它本身也是 Internet Standards Process 的产物 (如第 5 节所述, 作为 BCP). 它替代了先前版本, 并且随着时间推移, 它本身也很可能被替代.

本文档发布时, 代表社区对于为产生尽可能好的 Internet Standards 和 BCP 而应遵循的适当且正确流程以及应满足要求的看法, 但不能假设这种情况会永远保持不变. 人们可能会不时希望通过新版本替代它来更新本文档. 更新本文档使用与任何其他 BCP 相同的开放过程.

此外, 可能出现遵循这些过程会导致某个具体规范陷入僵局的情况, 也可能出现这些过程没有提供指导的情况. 在这些情况下, 调用下文描述的差异程序可能是合适的.

9.1 差异程序 (The Variance Procedure)

根据负责的 IETF Working Group 的建议 (如果没有成立 Working Group, 则根据临时委员会的建议), 即使本文档的某些要求尚未或将不会得到满足, IESG 也可以将某个具体规范纳入标准轨道, 或在标准轨道内推进它. 但是, 只有在 IESG 首先认定, 对 Internet 社区的可能收益很可能超过因不遵守本文档要求而给 Internet 社区带来的任何成本时, IESG 才可以批准这种 variance (差异). 在行使这种裁量权时, IESG 至少应考虑: (a) 该规范的技术价值, (b) 不授予差异而实现 Internet Standards Process 目标的可能性, (c) 授予差异以外的替代方案, (d) 授予差异的附带影响和先例影响, 以及 (e) IESG 构造尽可能窄的差异的能力. 在决定是否批准差异时, IESG 有权将差异范围限制到本文档的特定部分, 并施加其认为适合保护 Internet 社区利益的额外限制或约束.

拟议差异必须详细说明所感知的问题, 解释本文档中导致需要差异的确切条款, 以及 IESG 的考虑结果, 包括对上一段 (a) 到 (d) 各点的考虑. 拟议差异应作为 Internet Draft 发布. 随后 IESG 应发起不少于 4 周的延长 Last-Call, 以允许社区对该提案发表评论.

Last-Call 期满后, IESG 应及时就是否批准拟议差异作出最终决定, 并通过发送到 IETF Announce 邮件列表的电子邮件通知 IETF 其决定. 如果差异获得批准, 应将其转发给 RFC Editor, 并请求将其作为 BCP 发布.

当认为需要对本文档某项条款作一次性豁免时, 使用此差异程序. 对本文档的永久性更改应通过正常 BCP 流程完成.

第 6.5 节中的上诉流程适用于本流程.

9.2 排除事项 (Exclusions)

使用本程序不得缩短任何规定的延迟期, 不得使任何提案免于开放, 公平或共识要求, 也不得免于妥善保存会议和邮件列表讨论记录的需要.

具体而言, 本文档以下章节不得成为差异对象: 5.1, 6.1, 6.1.1 (第一段), 6.1.2, 6.3 (第一句), 6.5 和 9.