3. 策略定义 (Policy Definition)
本节定义 RFC Editor Model 中涉及 RSWG, RSAB, RPC, RSCE, IETF LLC, Editorial Stream, 申诉, 策略实施, 以及 RFC Series 历史属性的职责和流程.
规范正文
3. 策略定义 (Policy Definition)
管辖整个 RFC Series 的策略通过以下高层流程定义:
1. 提案必须提交给 RFC Series Working Group (RSWG), 由其采纳,
并在其中讨论.
2. 提案必须在工作组中通过征求意见的 Last Call, 并通过面向社区的
征求意见 (见第 3.2.3 节).
3. 提案必须由 RFC Series Approval Board (RSAB) 批准.
RSWG 和 RSAB 职权范围内的策略可能包括但不限于文档格式, RFC 的发布
和传播流程, 以及 RFC Series 的整体管理.
(下一段文字由第 1.4 节添加.)
此类策略不会包括详细的技术规范, 例如文本或图形格式或 XML grammar
的具体细节. 这些事项将由 RPC 结合其其他工作实践来决定并记录, 如第
4.2 节所述, 同时会像 IETF LLC [RFC8711] 支持的其他工具和服务一样
进行社区咨询.
3.1. 结构和角色 (Structure and Roles)
3.1.1. RFC Series Working Group (RSWG)
3.1.1.1. 目的 (Purpose)
RFC Series Working Group (RSWG) 是社区成员就管辖 RFC Series 的策略
进行协作的主要场所.
3.1.1.2. 参与 (Participation)
欢迎所有感兴趣的个人参与 RSWG; 参与者受第 3.2.5 节所述反骚扰策略
约束. 这包括但不限于 IETF 和 IRTF 的参与者, IAB 和 IESG 的成员,
实现 RFC 的软件或硬件系统开发者, RFC 和 Internet-Draft 的作者,
用于编写或编辑 RFC 和 Internet-Draft 的工具开发者, 在采购决策中使用
RFC 的个人, 学术研究人员, 以及 IETF 和 IRTF 以外的标准制定组织代表.
在任何相关 IETF LLC 策略允许的范围内, 邀请 IETF LLC Board 成员,
工作人员和承包商 (特别是 RFC Production Center 的代表), 以及 IETF
Executive Director 作为社区成员参与 RSWG. 也期望 RSAB 成员积极参与.
3.1.1.3. 主席 (Chairs)
RSWG 有两名主席, 一名由 IESG 任命, 另一名由 IAB 任命. IESG 和 IAB
分别确定自己的任命流程, 并确保考虑任何潜在利益冲突. 如果社区成员
对某位 RSWG Chair 的履职情况有顾虑, 应将反馈提交给相应的任命机构.
IESG 和 IAB 可以随时酌情移除其任命的主席, 并指定替任者完成原主席
剩余任期.
主席的职责是在 RSWG 内促进粗略共识 (rough consensus), 并在决策中
遵循该共识, 例如关于接受新提案以及将提案推进给 RSAB 的决策.
3.1.1.4. 运作方式 (Mode of Operation)
其意图是 RSWG 应当以类似 IETF 工作组的方式运作. 因此, 所有 RSWG
会议和讨论场所都应向所有感兴趣的个人开放, 所有 RSWG 贡献都应受
知识产权策略约束, 这些策略必须与 [BCP78] 和 [BCP79] 中规定的 IETF
策略保持一致.
RSWG 中的所有讨论都应在一个开放的电子邮件讨论列表上进行, 该列表
应公开归档.
RSWG 有权举行面对面会议, 仅在线会议, 或混合会议. 此类会议应提前
充分通知, 以便广泛参与; IESG 关于面对面和在线临时会议的指导
(https://datatracker.ietf.org/doc/statement-iesg-
guidance-on-in-person-and-online-interim-meetings-20230814/) 提供了
合理基线. 面对面会议应为无法亲自出席者提供有效在线参与的安排.
RSWG 应以粗略共识方式运作, 这种运作方式在 [RFC2418] 中有非正式描述.
只要与本文档以及 [RFC2418] 或其后继文档保持一致, RSWG 可以通过粗略
共识决定使用额外工具 (例如 [RFC8874] 中规定的 GitHub), 通信形式和
工作方法 (例如设计团队).
如果本文档没有就 RSWG 的运作给出具体指导, 则应认为 [RFC2418] 第 6
节提供的一般指导是适用的.
请求 IETF LLC 提供必要工具, 以支持 RSWG 的通信, 决策流程和策略.
3.1.2. RFC Series Approval Board (RSAB)
3.1.2.1. 目的 (Purpose)
RFC Series Approval Board (RSAB) 包括所有流的代表, 应作为 RSWG 内
生成提案的批准机构, 从而为 RSWG 的产出提供适当的制衡机制. RSAB 唯一
的策略制定角色是审查 RSWG 生成的策略提案; 它没有自行制定策略的独立
权限. 期望 RSAB 在可能的情况下尊重 RSWG 的粗略共识, 同时不放弃其审查
RSWG 提案的职责, 如第 3.2.2 节进一步所述.
3.1.2.2. 成员 (Members)
RSAB 主要由以下有投票权成员组成:
* IETF Stream 的流代表: IESG 成员或由 IESG 任命的人
* IAB Stream 的流代表: IAB 成员或由 IAB 任命的人
* IRTF Stream 的流代表: IRTF Chair 或由 IRTF Chair 任命的人
* Independent Stream 的流代表: Independent Submissions Editor (ISE)
[RFC8730] 或由 ISE 任命的人
* RFC Series Consulting Editor (RSCE)
如果以及当创建新的流时, 创建该流的文档应说明是否还应向 RSAB 添加代表
该流的有投票权成员, 并说明与该代表相关的任何规则和流程 (例如该代表
是负责该流的机构成员, 还是该机构任命的代表).
RFC Series Consulting Editor (RSCE) 是 RSAB 的有投票权成员, 但不作为
Editorial Stream 的代表.
为确保 RFC Series 平稳运作, RSAB 应包括以下无投票权的当然成员:
* IETF Executive Director 或其代表 (理由是 IETF LLC 对管辖 RFC
Series 的策略实施负责)
* 由 RPC 指名的 RPC 代表 (理由是 RPC 负责实施管辖 RFC Series 的策略)
此外, RSAB 可以酌情包括其他无投票权成员; 这些无投票权成员可以是当然
成员, 或来自 RSAB 认为有必要正式协作或协调的团体或组织的联络员.
3.1.2.3. 有投票权成员的任命和移除 (Appointment and Removal of Voting Members)
任命机构 (即 IESG, IAB, IRTF Chair 和 ISE) 应确定各自任命 RSAB 成员
的流程 (注意, 与 RSCE 相关的流程见第 5 节). 每个任命机构都有权随时
酌情移除其任命的 RSAB 成员. 任命机构应确保始终有有投票权成员就位,
并应在必要时以临时方式尽快填补任何空缺.
如果 IRTF Chair 或 ISE 丧失行为能力, 或因其他原因无法任命另一人作为
代表, 则 IAB (作为 IRTF Chair 和 ISE 的任命机构) 应作为这些流的临时
任命机构, 并任命一名临时 RSAB 成员, 直到 IAB 任命 IRTF Chair 或 ISE.
随后该 IRTF Chair 或 ISE 可以作为 RSAB 成员行事, 或通过正常流程任命
一名代表.
3.1.2.4. 空缺 (Vacancies)
如果有投票权成员出现空缺, RSAB 应按以下方式运作:
* 与实施已生效策略相关的活动应照常继续.
* 对 RSWG 产生的策略文档进行批准投票应推迟到一个或多个空缺被填补,
最长推迟三 (3) 个月. 如果在此三个月期间又出现空缺, 延迟时间应再
延长最多三个月. 延迟期届满后, RSAB 应按下文所述继续处理文档. 注意,
这种处理空缺的方法不适用于 RSCE 角色空缺; 它仅适用于第 3.1.2.2
节列举的流代表空缺.
3.1.2.5. 主席 (Chair)
RSAB 应每年使用其选择的方法从其成员中选出一名主席. 如果主席职位在
主席任期内空缺, RSAB 从其成员中选择一名新主席.
3.1.2.6. 运作方式 (Mode of Operation)
期望 RSAB 通过电子邮件讨论列表, 面对面会议, 电话会议系统, 以及其认为
必要的任何额外工具运作.
RSAB 应保留其议事程序的公开记录, 包括所有会议的纪要和所有决策记录.
RSAB 使用的主要电子邮件讨论列表应公开归档, 但需要保密的话题 (例如
人事事项) 可以从此类归档中省略或私下讨论. 同样, 会议纪要可以排除闭门
会议中讨论的话题的详细信息, 但应注明讨论过此类话题.
RSAB 应至少在会议前一周, 在 RFC Editor 网站上并通过电子邮件向 RSWG
宣布会议计划和议程. 会议应开放公众旁听, RSAB 可以考虑允许开放参与.
如果 RSAB 需要在闭门会议中讨论保密事项, 该部分会议应仅对 RSAB 私下
进行, 但必须在议程中注明, 并在保密要求允许的范围内尽可能详细地记录
在会议纪要中.
请求 IETF LLC 提供必要工具和工作人员, 以支持 RSAB 的通信, 决策流程和
策略.
IAB 于 2022 年召集 RSAB, 以正式化 IAB 对 RFC Editor Model 权限的移交.
3.2. 流程 (Process)
本节规定 RFC Series Policy Definition Process, 在生成所有 Editorial
Stream RFC 时都应遵循该流程.
3.2.1. 意图 (Intent)
其意图是提供一个开放论坛, 用于定义和演进与 RFC Series 相关的策略.
一般期望是所有感兴趣方都将参与 RSWG, 并且只有在极端情况下 RSAB 成员
才需要持有 CONCERN 立场 (如第 3.2.2 节所述).
由于策略问题可能困难且有争议, 强烈鼓励 RSWG 参与者和 RSAB 成员本着
善意和相互理解的精神共同工作, 以达成粗略共识 (见 [RFC2418]). 特别是,
鼓励 RSWG 成员认真对待 RSAB 的顾虑, 并鼓励 RSAB 成员在流程早期清楚
表达自己的顾虑, 且对社区作出回应. 鼓励所有各方尊重每个流的价值以及
RFC Series 的长期健康和可持续性.
该流程旨在成为持续咨询过程. RSAB 成员应持续咨询其所代表的利益相关方
(例如 RFC 的作者, 编辑, 工具开发者和使用者), 这样在需要考虑批准某项
提案时就不应出现意外. 期望任命机构建立其认为适当的任何流程, 以促进
实现这一目标.
3.2.2. 工作流 (Workflow)
应使用以下流程来制定或修改与 RFC Series 相关的策略:
1. 一个个人或一组个人以 Internet-Draft 的形式生成提案 (该提案必须
完全符合 [BCP78] 和 [BCP79] 的规定提交), 并请求 RSWG 将该提案
作为工作组事项采纳.
2. 如果主席确定 (通过遵循工作组的粗略共识程序) 对该提案有足够兴趣,
RSWG 可以将该提案作为工作组事项采纳; 这类似于 IETF 工作组的运作
方式 (见 [RFC2418]).
3. 随后 RSWG 应进一步讨论和发展该提案. 所有参与者, 尤其是 RSAB 成员,
应特别关注提案中任何可能显著修改第 7 节所述 RFC Series 长期策略
或历史特征的方面. 期望 RSAB 成员以个人身份参与所有与 RSWG 提案
相关的讨论. 这应有助于确保他们在 RFC Series Policy Definition
Process 的早期就充分了解提案. 这也应有助于确保 RSAB 成员在提案
发展期间提出任何问题或顾虑, 而不是等到 RSAB 审查期. 也期望 RSWG
Chairs 以个人身份参与.
4. 在某个时点, 如果 RSWG Chairs 认为推进该提案可能存在粗略共识,
他们将在工作组内发起征求意见的 Last Call.
5. 在适当长度的意见期之后, RSWG Chairs 将确定该提案是否存在粗略共识
(将他们自己作为个人的反馈与其他参与者的反馈一并考虑). 如果已经
收到意见并进行了实质性修改, 可能需要额外的 Last Call. 一旦主席
确定已经达成共识, 他们应在 RSWG 电子邮件讨论列表上宣布其决定,
并将文档转交给 RSAB.
6. 一旦 RSWG 中确立共识, RSAB 应按第 3.2.3 节进一步描述发起社区
征求意见. 如果收到针对社区征求意见的实质性意见, RSAB 可以将提案
退回 RSWG, 以考虑这些意见并进行修订来处理收到的反馈. 在社区征求
意见并行期间, RSAB 本身也应考虑该提案.
7. 如果上一步所作修订的范围是实质性的, RSAB 应发起额外的社区征求
意见, 并且 RSWG 应考虑收到的反馈.
8. 一旦 RSWG Chairs 确认在一次或多次社区征求意见期间收到的顾虑已
得到处理, 他们应通知 RSAB 该文档已准备好由 RSAB 进行投票表决.
9. 在合理时间内, RSAB 将询问其成员对提案的立场. 立场可以如下:
* YES: 该提案应被批准
* CONCERN: 该提案提出了必须处理的实质性顾虑
* RECUSE: 持有该立场的人存在利益冲突
任何持有 CONCERN 立场的 RSAB 成员都必须向社区详细说明其顾虑.
尽管如此, RSWG 可能无法就能够处理该 RSAB 成员顾虑的修改达成共识.
RSAB 成员可以提交 CONCERN 立场有三个原因:
* RSAB 成员认为该提案会对一个或多个单独流造成严重问题.
* RSAB 成员认为该提案会对整个 RFC Series 造成严重损害, 包括对
RFC Series 长期健康和可持续性的损害.
* RSAB 成员基于一次或多次社区征求意见 (第 3.2.3 节) 的结果认为,
缺乏推进该提案的粗略共识.
由于期望 RSAB 成员参与 RSWG 内的讨论, 并在这些讨论期间提出任何
顾虑和问题, 大多数 CONCERN 立场对 RSWG 来说不应是意外. 尽管如此,
如果在 RSAB 审查或一次或多次社区征求意见期间识别出问题, 较晚提出
CONCERN 立场始终是可能的.
10. 如果存在 CONCERN, 将在 RSWG 内进行讨论. 同样, 期望所有 RSAB 成员
都参与. 如果为了处理 CONCERN 立场而进行了实质性修改, 可能需要额外
的社区征求意见.
11. 没有任何 CONCERN 立场的提案即获批准.
12. 如果经过适当时间后仍有任何 CONCERN 立场, 则进行 RSAB 投票. 如果
至少三名有投票权成员投 YES, 该提案即获批准.
13. 如果提案未获批准, 则退回 RSWG. RSWG 随后可以考虑作出进一步修改.
14. 如果提案获批, 则向社区发送通知, 文档进入队列, 等待作为 Editorial
Stream 中的 RFC 发布.
15. 策略可以在 RSAB 批准后立即生效, 且可在相关 RFC 发布之前生效,
除非由于 IETF LLC 解决待处理资源或合同问题而延迟.
3.2.3. 社区征求意见 (Community Calls for Comment)
RSAB 负责对已在 RSWG 内获得共识的提案发起和管理社区征求意见. RSAB
应主动寻求广泛输入. RSAB 至少通过向 [email protected]
(mailto:[email protected]) 电子邮件讨论列表, 或其后继者或
未来等效列表发送通知来寻求此类输入. RSAB 成员也应向其直接代表的社区
(例如 IETF 和 IRTF) 发送通知. 通知还应在 RFC Editor 网站上提供并归档.
此外, 可以为通知建立其他通信渠道 (例如通过 RSS feed 或发布到社交媒体
场所).
如果某项提案可能显著修改第 7 节所述 RFC Series 的长期策略或历史特征,
RSAB 应格外谨慎地联系使用 RFC 的非常广泛的社区 (如第 3.1.1.2 节所述),
因为此类社区可能并未直接积极参与 RSWG. RSAB 应与流批准机构和 IETF LLC
合作, 在 RSCE 特别协助下识别并建立与此类社区的联系.
RSAB 应维护一份在征求意见期间被联系社区的公开列表.
社区征求意见通知包含以下内容:
* 以 'Call for Comments:' 开头的主题行
* 清晰, 简洁的提案摘要
* 指向定义该提案的 Internet-Draft 的 URL
* RSAB 认为必要的任何解释或面向社区的问题 (使用其通常的决策程序)
* 关于如何提供公开意见的清晰说明
* 意见提交截止日期
意见期将不少于两周, 如果需要广泛外联, 则应更长. 意见将在 RFC Editor
网站上公开归档.
RSAB 负责考虑在社区征求意见期间收到的意见. 如果 RSAB 成员认为此类意见
提出了需要处理的重要问题, 他们应通过在 RSWG 内讨论这些问题, 或者
(如果这些问题符合第 3.2.2 节步骤 9 中规定的标准) 在 RSAB 投票表决
期间提交 CONCERN 立场来处理.
3.2.4. 申诉 (Appeals)
对 RSWG Chair 决定的申诉应提交给 RSAB. 只有在未能遵循正确流程的理由
下, 才能对 RSWG Chairs 的决定提出申诉. 申诉应在任何行动后三十 (30) 天
内提出, 或者在未采取行动的情况下, 应在已向 RSWG Chairs 发出通知后三十
(30) 天内提出. 随后 RSAB 将决定是否遵循了流程, 并指示 RSWG Chairs 需要
采取哪些程序性行动.
可以基于未能遵循正确流程的理由对 RSAB 的决定提出申诉. 此外, 如果 RSAB
为解决作者与 RPC 之间的分歧而作出决定 (如第 4.4 节所述), 可以基于 RSAB
误解已批准策略的理由提出申诉. 除这两种情况外, 关于 RSAB 行事方式的分歧
不受申诉约束. 对 RSAB 决定的申诉应提交给 IAB, 并且应在相关 RSAB 决定
公开通知后三十 (30) 天内提出 (通常是会议纪要发布时). IAB 应决定是否
发生了流程失败, 以及应采取何种 (如有) 纠正行动.
3.2.5. 反骚扰策略 (Anti-Harassment Policy)
IETF anti-harassment policy
(https://www.ietf.org/about/groups/iesg/statements/anti-harassment-
policy/) 也适用于 RSWG 和 RSAB. 它们努力创建并维护一个环境, 使具有许多
不同背景的人都受到有尊严, 得体和尊重的对待. 期望参与者按照专业标准
行事, 并表现出适当的职场行为. 有关这些策略的更多信息, 见 [RFC7154],
[RFC7776] 和 [RFC8716].
3.2.6. RFC 样板文本 (RFC Boilerplates)
RFC boilerplates (见 [RFC7841]) 是 RFC Style Guide 的一部分, 如第 4.2
节所定义. 在 RFC Editor Model version 3 下考虑的新增或修改后的样板文本
必须由以下各方批准, 每一方对样板文本都有单独的责任领域:
* 适用的流, 其批准该样板文本满足自身需要
* RSAB, 其批准该样板文本不与其他流中使用的样板文本冲突
* RPC, 其批准该样板文本的语言与 RFC Style Guide 保持一致
* IETF Trust, 其批准该样板文本正确表述 Trust 关于权利和所有权的立场
3.3. RFC 使用者 (RFC Consumers)
(本节文字由第 1.2.3 节添加.)
IETF 使命声明 [RFC3935] 清楚表明, 它产生的文档旨在由任何希望实现 IETF
协议或运维建议的人使用:
| 产生高质量, 相关的技术和工程文档, 这些文档影响人们设计, 使用和管理
| Internet 的方式, 从而使 Internet 更好地工作.
第 3.2.1 节引入术语 "RFC 使用者 (consumers of RFCs)", 将其称为
"所代表的利益相关方 (constituent stakeholders)", RSAB 在批准 Editorial
Stream 策略文档时应考虑这些利益相关方.
"RFC 使用者 (Consumers of RFCs)" 现在定义为阅读 RFC 以理解, 实现, 评析
和研究 RFC 中协议, 运维实践及其他内容的人.
RFC publication streams 和 RFC Editor 在 RFC 使用者方面应遵循的策略如下:
* RFC 使用者必须 (MUST) 被视为不同于 IETF/IRTF 参与者的单独所代表的
利益相关方. 虽然 IETF/IRTF 参与者和其他参与 RFC 开发与生产的人可能
是 RFC 使用者, 但二者是不同且有重叠的集合.
* RFC Editor 网站 (https://www.rfc-editor.org) 必须 (MUST) 主要聚焦于
RFC 使用者.
* 禁止 (MUST NOT) 要求或期望 RFC 使用者成为 IETF/IRTF 参与者, 除非
他们希望扩展, 更新或修改某个 RFC.