跳到主要内容

4. 策略实施 (Policy Implementation)

4.1. 角色和流程 (Roles and Processes)

RFC 的发布由 RFC 生产中心 (RFC Production Center, RPC) 处理.

以下若干一般性考虑适用:

  • RPC 的一般角色和职责由 Editorial Stream 发布的 RFC 定义 (即, 不是由 RSWG, RSAB 或 RSCE 直接定义), 也由适用于 RPC 且尚未被 Editorial Stream RFC 取代的现有 RFC 以及必要合同定义.

  • RPC 接受 RSCE 和 RSAB 的建议, 并且在特定情形下有义务向它们咨询, 例如第 4.4 节所述与作者和 RPC 之间分歧相关的情形.

  • RPC 由 IETF LLC 监督, 以确保其按照现行合同履行职责.

所有预算, 时间表以及对其绩效目标影响的事项, 均由 RPC 和 IETF LLC 处理.

RPC 应定期向 IETF LLC, RSAB, RSWG 以及更广泛社区提供报告, 说明其活动以及影响它的任何关键风险或问题.

如果 RPC 被要求在通常值得咨询但无法咨询的情况下作出决定, 或者作出与 RSAB 建议相反的决定, RPC 必须通知 RSAB.

本文档不规定 IETF LLC 与 RPC 之间的确切关系; 例如, RPC 的工作可以由与 IETF LLC 签约的独立法人实体执行, 可以由 IETF LLC 的员工执行, 也可以由 IETF LLC 就此类工作的部分或全部方面与独立承包商合作. 确切关系由 IETF LLC 决定.

IETF LLC 负责 RPC 聘用方式及其管理. 因此, IETF LLC 有权为 RPC 协商绩效目标, 并负责确保这些目标得到实现. 此类绩效目标根据 RPC 的发布负载以及实施相关策略所需的额外工作设定; 这些策略来自 Editorial Stream RFC, 适用于 RPC 且尚未被 Editorial Stream RFC 取代的现有 RFC, 以及必要合同. IETF LLC 可以就这些目标咨询社区. IETF LLC 有权任命一名经理或召集一个委员会来完成这些活动.

如果社区中的个人或群体对 RPC 的绩效有疑虑, 他们可以请求 IETF LLC 董事会, IETF 执行主任或 IETF LLC 董事会指定的联络点调查此事. 即使 IETF LLC 选择委派此项活动, 相关疑虑也应提交给 IETF LLC. IETF LLC 最终通过 [RFC8711] 所述机制向社区负责.

4.2. 工作实践 (Working Practices)

在缺少 RFC 中记录的高级策略时, 或者为了规定此类策略实施细节时, RPC 可以记录关于 RFC 编辑准备, 最终发布和传播的工作实践. 示例包括:

  • 维护一份定义 RFC 编辑标准的风格指南; 具体而言, RFC Style Guide 由 [RFC7322] 以及 [STYLEGUIDE] 中列出的其他文档和资源组成.

  • 关于编辑和发布流程接受哪些文件格式作为输入的说明.

  • 关于已发布文档最终结构和版式的指导原则. 在 XML 词汇表 [RFC7991] 的上下文中, 此类指导原则可以包括对用于捕获 RFC 语义内容的首选 XML 元素和属性的澄清.

4.3. RPC 职责 (RPC Responsibilities)

RPC 的核心职责是通过发布 RFC 来实施 RFC Series 策略 (包括文档质量, 发布及时性以及结果可访问性等维度), 同时考虑社区通过 RSWG 以及流批准机构提出的问题. 更具体地说, 在撰写本文档时, RPC 的职责包括以下各项:

  1. 编辑来自所有 RFC 流的文档, 以确保它们符合 RFC Style Guide 中规定的编辑标准.

  2. 创建并保存对文档所作编辑的记录.

  3. 识别哪些编辑变更可能产生技术影响, 并寻求必要澄清.

  4. 通过与作者, IANA 或特定流联络人的沟通确定每份文档是否已准备好发布, 必要时由 RSAB 和 RSCE 补充协助.

  5. 创建并保存与文档作者对话的记录.

  6. 按需向 RSAB 和 RSCE 请求建议.

  7. 按需向 RSAB 和 RSCE 提供建议.

  8. 在 RSWG 内参与创建会影响 RPC 的新 Editorial Stream RFC, 特别是针对 RPC 可能预见到的拟议策略实施挑战.

  9. 在处理文档或履行本列表中其他职责时, 识别其缺乏足够专业知识的主题和问题, 并按需识别相关专家且与其协商.

  10. 向社区提供关于其绩效和计划的报告.

  11. 就其计划咨询社区.

  12. 与 IETF LLC 协商其具体计划和资源.

  13. 提供足够资源, 以支持 IETF LLC 对 RPC 绩效的审查.

  14. 与 IANA 协调, 确保 RFC 准确记录 IANA 注册表的注册流程和已分配值.

  15. 分配 RFC 编号.

  16. 按需与流批准机构以及其他流代表联络.

  17. 发布 RFC, 这包括:

    • 将副本以单篇和合集两种形式发布到 RFC Editor 网站

    • 将副本存放到外部档案库

    • 创建目录和目录条目

    • 向相关各方宣布发布

  18. 提供 RFC 在线访问.

  19. 提供一个在线系统, 以便利 RFC 勘误的提交, 管理和展示.

  20. 维护 RFC Editor 网站.

  21. 为 RFC 提供备份.

  22. 确保记录的存储和保存.

  23. 为法律程序认证 RFC.

(以下两段文本由第 1.2.1 节添加.)

在缺少包含具体要求的 RFC 时, RPC 负责开发用于实施 Editorial Stream 策略的工具和流程. RPC 负责详细技术规范, 例如文本或图形格式或 XML 语法的具体细节. RPC 可以指定一个由志愿者和/或员工组成的团队来实施这些运营决策. RPC 在作出实施决策时应征求专家和社区成员的意见. RPC 必须在公开可用的位置记录实施决策, 最好附带理由.

如果 RPC 对如何解释 Editorial Stream 文档中的策略有疑问, 它们应按照第 4.4 节所述流程请求 RSAB 提供策略解释指导.

4.4. 作者与 RPC 之间分歧的解决 (Resolution of Disagreements between Authors and the RPC)

在编辑准备和发布过程中, 待发布 RFC 的作者与 RPC 之间可能出现分歧. 如果现有策略明确适用, 此类分歧通常通过作者和 RPC 之间的直接咨询以直接方式处理, 有时也会与特定流联络人协作.

但是, 如果不清楚现有策略是否适用, 或者不清楚如何解释现有策略, 各方可能需要咨询其他个人或机构 (例如 RSAB, IESG, IRSG 或流批准机构), 以帮助达成解决方案. 以下要点旨在提供更具体的指导.

  • 如果与特定流的策略存在冲突, 为帮助达成解决方案, RPC 应咨询相关流批准机构 (例如 IESG 或 IRSG), 并酌情咨询相关流的其他代表.

  • 如果与跨流策略存在冲突, RPC 应咨询 RSAB 以达成解决方案.

  • 该分歧可能提出一个现有策略未覆盖的新问题, 或者如上所述无法通过 RPC 与其他相关个人和机构之间的咨询来解决的问题. 在这种情况下, RSAB 负责 (a) 必要时及时解决分歧, 以便相关流文档能在定义新策略之前发布, 并且 (b) 将该问题提交给 RSWG, 以便定义新策略.

(以下一段文本由第 1.2.2 节添加.)

如果 RPC 负责在文档层面和编辑流程工具层面解释策略决策, 则任一层面的冲突都会涉及对书面策略的解释 (或承认不存在覆盖给定情形的策略). 无论如何, 冲突解决现在都将使用同一条申诉路径: 向 RSAB 申诉.

4.5. 联络点 (Point of Contact)

IETF 以及更广泛 RFC Series 社区之外的个人或组织, 有时可能会对 RFC Series 有疑问. 此类咨询应发送到 [email protected] (mailto:[email protected]) 电子邮件别名, 或发送到其后继或未来等效地址, 然后由适当机构 (例如 RSAB 和 RPC) 或个人 (例如 RSWG 主席和 RSCE) 处理.

4.6. 行政实施 (Administrative Implementation)

此处所述行政和合同活动的确切实施是 IETF LLC 的职责. 本节就此类活动的若干方面提供一般性指导.

4.6.1. RPC 的供应商选择 (Vendor Selection for the RPC)

供应商选择与各流协作完成, 并由 IETF LLC 拥有最终权力.

IETF LLC 为 RPC 制定工作定义 (Statement of Work), 并管理供应商选择流程. 工作定义在 IETF LLC 预算范围内创建, 并考虑 RPC 职责 (如第 4.3 节所述), 各流的需求以及社区输入.

选择 RPC 及其他 RFC 相关服务并与其签约的流程如下:

  • IETF LLC 建立合同流程, 包括必要时发布征求建议书 (Request for Proposal, RFP) 所需的步骤, 时机和签约程序.

  • IETF LLC 建立一个选择委员会, 该委员会将由 IETF 执行主任以及 IETF LLC 在咨询流批准机构后选定的其他成员组成. 该委员会应从其成员中选择一名主席.

  • 选择委员会选择供应商, 前提是成功协商出一份经 IETF LLC 批准的合同. 如果无法签署合同, 此事应提交选择委员会采取进一步行动.

4.6.2. 预算 (Budget)

本文档中讨论的大多数费用并非新费用. 它们过去一直是, 并且仍然是 IETF LLC 预算的一部分.

IETF LLC 预算中的 RFC Series 部分应包括用于支持 RSCE, RFC Production Center 和 Independent Stream 的资金.

IETF LLC 有责任批准 RFC Editor 总预算 (并有权拒绝该预算). 所有相关方都必须在 IETF LLC 预算流程内开展工作.