9. 流程变更 (Varying the Process)
本文档阐述了互联网标准和相关文档制定的规则和程序,它本身是互联网标准化流程的产物 (作为BCP,如第5节所述).它替代了以前的版本,并且随着时间的推移,它本身也可能被替代.
虽然在发布时,本文档代表了社区对遵循的适当和正确流程以及满足的要求的看法,以实现最佳的互联网标准和BCP,但不能假设这将始终如此.有时可能希望通过用新版本替换它来更新它.更新本文档使用与任何其他BCP相同的开放程序.
此外,可能存在遵循程序导致关于特定规范的僵局的情况,或者可能存在程序不提供指导的情况.在这些情况下,调用下面描述的变更程序可能是适当的.
9.1 变更程序 (The Variance Procedure)
根据负责的IETF工作组的建议 (或者,如果没有组建工作组,根据特设委员会的建议),即使本文档的某些要求未得到或将不会得到满足,IESG也可以将特定规范进入或在标准跟踪中推进.然而,IESG只有在首先确定互联网社区的可能利益可能超过不遵守本文档要求对互联网社区造成的任何成本时,才可以批准此类变更.在行使此自由裁量权时,IESG至少应考虑 (a) 规范的技术优点,(b) 在不授予变更的情况下实现互联网标准化流程目标的可能性,(c) 授予变更的替代方案,(d) 授予变更的附带和先例影响,以及 (e) IESG制定尽可能狭窄的变更的能力.在确定是否批准变更时,IESG有权将变更的范围限制在本文档的特定部分,并施加其认为适当的保护互联网社区利益的额外限制或限制.
拟议的变更必须详细说明感知到的问题,解释本文档的哪个精确条款导致需要变更,以及IESG考虑的结果,包括考虑前一段中的 (a) 到 (d) 点.拟议的变更应作为互联网草案发布.然后,IESG应发出不少于4周的延长最终呼吁,以允许社区对提案发表意见.
在最终呼吁期到期后的及时方式内,IESG应做出是否批准拟议变更的最终决定,并应通过电子邮件向IETF公告邮件列表通知IETF其决定.如果变更被批准,它应转发给RFC编辑,请求将其作为BCP发布.
此变更程序用于当认为需要一次性放弃本文档某些规定时.对本文档的永久更改应通过正常的BCP流程完成.
第6.5节中的上诉流程适用于此流程.
9.2 排除事项 (Exclusions)
使用此程序不得降低任何指定的延迟,也不得豁免任何提案的开放性,公平性或共识要求,也不得免除保持会议和邮件列表讨论的适当记录的需要.
具体而言,本文档的以下部分不得成为变更的主题: 5.1,6.1,6.1.1 (第一段),6.1.2,6.3 (第一句),6.5和9.