5. 当前最佳实践 (BCP) RFC

RFC 系列中的 BCP 子系列旨在作为一种方式, 用于标准化实践以及社区审议的结果. BCP 文档适用与标准轨道文档相同的基本过程, 因而是一种载体, 使 IETF 社区能够定义并批准社区当前对于原则性声明, 或对于执行某些操作或 IETF 流程功能的最佳方式的最佳共识.

从历史上看, Internet 标准通常关注跨互联网络进行计算机通信所需的硬件和软件技术规范. 但是, 由于 Internet 本身由各种组织运营的网络组成, 这些组织具有不同目标和规则, 良好的用户服务要求 Internet 的运营者和管理员在策略与操作方面遵循一些共同准则. 虽然这些准则在范围和风格上通常不同于协议标准, 但其建立同样需要类似的共识构建过程.

虽然 IAB 和 IESG 等实体由个人组成, 这些个人可以以个人身份参与 IETF 的技术工作, 但这些实体本身也作为社区领导者而存在. 作为 Internet 技术社区的领导者, 这些实体应有渠道提出想法, 以推动特定领域的工作, 提高社区对某一问题的敏感度, 作出架构原则声明, 或传达它们对其他事项的看法. BCP 子系列为这些管理实体提供了一种结构顺畅的方式, 使其能够把提案放入 IETF 的共识构建机制中, 同时衡量社区对该问题的看法.

最后, BCP 系列可用于记录 IETF 自身的运作. 例如, 本文档定义 IETF Standards Process, 并作为 BCP 发布.

5.1. BCP 审查流程

与标准轨道文档不同, BCP 中描述的机制并不适合标准轨道三阶段的渐进引入特性, 而通常只有完整且立即生效才有意义.

BCP 流程与提议标准的流程类似. BCP 提交给 IESG 审查 (见第 6.1.1 节), 并适用现有的审查流程, 包括在 IETF Announce 邮件列表上的 Last-Call. 但是, 一旦 IESG 批准了该文档, 流程即告结束, 文档随即发布. 最终产生的文档被视为已获得 IETF 的技术批准.

具体而言, 要取得 BCP 状态的文档必须经历本文档第 6.1 节和第 6.4 节所述的过程. BCP 流程可按第 6.5 节的过程提出上诉.

由于 BCP 旨在表达社区共识, 但其达成速度比标准更快, 因此需要特别谨慎. 具体而言, BCP 不应被简单视为更强的 Informational RFC, 而应被视为内容上不同于 Informational RFC 的文档.

已作为 BCP 获批的一项规范或一组规范会被分配 BCP 系列中的一个编号, 同时保留其 RFC 编号.