跳到主要内容

1. 引言 (Introduction)

Request for Comments (RFC) Series 是一个归档系列, 专门用于记录 Internet 技术规范, 包括 Internet 研究和工程社区的一般贡献以及标准文档. 任何人都可以通过 Internet 免费获得 RFC. 如 [RFC8700] 所述, RFC 自 1969 年以来一直持续发布.

RFC 由多个文档流生成并批准. 虽然每个流的 stream approving body [RFC8729] 负责该流的内容, 但 RFC Editor 功能负责所有 RFC 的制作和分发. 现有 4 个流在 [RFC8729] 中描述. 本文档指定第 5 个流, 即 Editorial Stream, 用于发布治理整个 RFC Series 的政策.

RFC Series 和 RFC Editor 功能的总体框架在 [RFC8729] 中描述, 并由本文档更新. 本文档定义 RFC Editor Model 的版本 3. 在此版本下, RFC Editor 功能的各种职责由 RFC Series Working Group (RSWG), RFC Series Advisory Board (RSAB), RFC Production Center (RPC), RFC Series Consulting Editor (RSCE) 和 IETF Administration Limited Liability Company (IETF LLC) [RFC8711] 单独或联合执行. 这些实体共同构成 RFC Editor 功能. 其意图是基于专家实现, 清晰管理和方向, 以及适当社区输入 [RFC8729] 等原则, 确保 RFC Series 的可持续维护和支持.

本文档通过为 Editorial Stream 定义 boilerplate text 来更新 [RFC7841]. 本文档通过用 RSWG, RSAB 和 RSCE 替换 RFC Editor 角色来更新 [RFC8729]. 本文档还通过移除对 IAB 和 RFC Series Editor (RSE) 指定的某些政策的依赖来更新 [RFC8730]. 关于 RFC Editor Model 版本 2 以来变化的更详细信息见第 9 节.

1.1. 对 RFC 9280 的更改​

本节详细说明 RSWG 自 2022 年起对 [RFC9280] 所做的更改. 如果你不关心本文档是如何被修改的, 可直接跳到第 2 节.

[RFC9280] 对 RFC 发布模型作出了重大改变. 这些改变为 RFC 发布创建了新的结构和新的流程. 随着这些结构和流程投入使用, 社区发现了一些可以改进之处. 此外, 某些流程中也发现了缺口. 本文档基于这些发现更新 [RFC9280].

为保持章节编号与 [RFC9280] 一致, 本 RFC 的组织方式不同于典型 RFC. 为保持章节编号相同, Introduction 节更长, 并包含若干指向正文的子节.

本引言剩余部分列出对 [RFC9280] 的更改. 这些更改在文档其余部分实例化, 并在更改列表和正文之间提供交叉引用.

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 在且仅在它们以此处所示全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.

1.2. RPC 角色和职责​

[RFC9280] 为 RFC Editor 功能创建了新的结构. 它建立了 RFC Series Working Group (RSWG) 和 RFC Series Approval Board (RSAB), 并赋予 RFC Production Center (RPC) 新职责. 概括而言, 它规定 RSWG 为 Editorial Stream 编写政策, RSAB 批准这些政策, RPC 实施这些政策. 然而, [RFC9280] 没有说明哪个组织负责定义或构建用于实施该流程中达成政策的具体代码和工具. 本节其余部分更新 [RFC9280], 以处理此事项及其他相关事项.

1.2.1. 用于发布 RFC 的工具和代码​

[RFC9280] 第 2 节指出: 通过发布构成 RFC Series 的所有流中的 RFC 来实施政策. 这主要是 RFC Production Center (RPC) 的职责, 由 IETF Administration Limited Liability Company (IETF LLC) [RFC8711] 通过合同监督.

同一节还指出: RPC 在其日常编辑和发布所有流的 RFC 时实施 Editorial Stream 定义的政策.

[RFC9280] 没有定义任何其他负责实施政策的组织.

在 [RFC9280] 全文中, RSWG 一贯被赋予编写政策的职责, 而不是决定实现方式. RPC 一贯被赋予实施政策决策的职责, 但所给示例通常描述的是单个文档层面的决策. [RFC9280] 没有覆盖设计和构建用于发布文档的工具与代码的任何具体职责.

[RFC9280] 两次提到工具开发者. [RFC9280] 第 3.1.1.2 节鼓励"用于撰写或编辑 RFC 和 Internet-Drafts 的工具的开发者"参与 RSWG. [RFC9280] 第 3.2.1 节指出, "RSAB members should consult with their constituent stakeholders (e.g., authors, editors, tool developers, and consumers of RFCs) on an ongoing basis".

[RFC9280] 第 4.2 节在讨论 RPC 工作实践时提到一个具体实现: 在缺少记录于 RFC 中的高层政策时, 或者为了说明其对这些政策的实施细节, RPC 可以记录已发布文档最终结构和布局的指南. 在 XML vocabulary [RFC7991] 上下文中, 这些指南可以包括关于用于捕获 RFC 语义内容的首选 XML 元素和属性的澄清.

[RFC7991] 是 [RFC9280] 中唯一提到的与编辑实现相关的 RFC.

本文档第 4.3 节新增以下内容: 在不存在具有具体要求的 RFC 时, RPC 负责开发用于实施 Editorial Stream 政策的工具和流程. RPC 负责详细技术规范, 例如文本或图形格式或 XML grammar 的具体细节. RPC 可以指定由志愿者和/或雇员组成的团队来实施这些操作决策. RPC 在作出实现决策时应征求专家和社区成员的输入. RPC 必须在公开可用的位置记录实现决策, 最好附带理由.

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

1.2.2. 实现决策的冲突解决​

[RFC9280] 第 4.4 节提供了 RPC 与特定文档作者之间冲突的解决路径. 对于适用于整个编辑流程而不只是单个文档的实现决策发生冲突时可能出现的问题, 该文档没有给出申诉路径.

以下段落反映在本文档第 4.4 节中: 如果 RPC 负责在文档层面和编辑流程工具层面解释政策决策, 则两个层面的冲突都会涉及对书面政策的解释, 或者承认不存在覆盖给定情况的政策. 无论哪种情况, 冲突解决现在都使用同一路径申诉: 向 RSAB 申诉.

1.2.3. RFC 消费者​

以下文字反映在本文档第 3.3 节中:

IETF mission statement [RFC3935] 明确指出, 其生成的文档旨在由任何希望实现 IETF 协议或操作建议的人使用: 生成高质量, 相关的技术和工程文档, 影响人们设计, 使用和管理 Internet 的方式, 从而使 Internet 更好地工作.

第 3.2.1 节引入术语 "consumers of RFCs", 指称他们为 RSAB 在批准 Editorial Stream 政策文档时应考虑的 "constituent stakeholders".

"Consumers of RFCs" 现在定义为阅读 RFC 以理解, 实现, 批评和研究 RFC 中协议, 操作实践和其他内容的人.

RFC 发布流和 RFC Editor 关于 RFC 消费者应遵循的政策如下:

  • RFC 消费者必须被视为与 IETF/IRTF 参与者不同的独立 constituent stakeholders. 虽然 IETF/IRTF 参与者以及参与 RFC 开发和制作的其他人也可能是 RFC 消费者, 但二者是不同且有重叠的集合.
  • RFC Editor 网站 (https://www.rfc-editor.org) 必须主要面向 RFC 消费者.
  • 除非 RFC 消费者希望扩展, 更新或修改某个 RFC, 否则不得要求或期望他们成为 IETF/IRTF 参与者.

1.3. 对 RFC 9720 的更新​

[RFC9720], "RFC Formats and Versions", 更新 [RFC9280]. 本文档更新 [RFC9720].

1.3.1. RFC 可以重新发布​

[RFC9280] 第 7.6 节指出: 一旦发布, RFC Series 文档不会被更改.

该句在本文档第 7.6 节中替换为: 一旦发布, RFC 可以重新发布, 但发布版本的语义内容应尽最大可能保留, 如 [RFC9720] 第 2.2 节所述.

1.3.2. 一致性政策​

本文档第 7 节新增一项政策:

7.8. 一致性​

RFC 会经过文字编辑, 格式化, 然后发布. 它们可以重新发布以保持一致的呈现.

1.4. RSWG 和 RSAB 的管辖范围​

[RFC9280] 第 3 节指出: RSWG 和 RSAB 管辖下的政策可能包括但不限于文档格式, RFC 发布和分发流程, 以及 RFC Series 的总体管理.

本文档第 3 节在该句后立即新增以下内容: 此类政策不包括详细技术规范, 例如文本或图形格式或 XML grammar 的具体细节. 这些事项将由 RPC 与其其他工作实践一起决定并记录, 如第 4.2 节所述, 并按 IETF LLC [RFC8711] 支持的其他工具和服务的方式进行社区咨询.

1.5. 对 RFC 7991 到 RFC 7997 的更新​

[RFC7991], [RFC7992], [RFC7993], [RFC7994], [RFC7995], [RFC7996] (已由 [RFC9896] 废弃) 和 [RFC7997] 中所有 "RFC Editor" 或 "RFC Series Editor" 实例均替换为 "RFC Production Center (RPC)".

1.6. 改写以废弃 RFC 9280​

[RFC9280] 的许多部分讨论了将要进行的更改. 由于本文档废弃 [RFC9280], 这些部分已更新为表明这些更改已经完成.

最后于 更新