6. Internet 标准流程 (THE INTERNET STANDARDS PROCESS)

6. Internet 标准流程 (THE INTERNET STANDARDS PROCESS)

Internet Standards Process 的机制涉及 IESG 作出的决定: 将规范提升到 标准轨道上, 或将标准轨道规范从一个成熟度级别移到另一个成熟度级别. 虽然有若干相当客观的标准 (如下文和第 4 节所述) 可指导 IESG 决定将 规范移入, 沿着或移出标准轨道, 但不存在算法式保证, 能确保任何规范被 提升到标准轨道或沿标准轨道推进. IESG 对拟提升到标准轨道或在标准轨道 中推进的规范之技术质量所作的有经验的集体判断, 是决策流程的基本组成 部分.

6.1 标准行动 (Standards Actions)

"standards action" (标准行动), 即将某个具体规范纳入标准轨道, 在标准 轨道内推进它, 或将其从标准轨道中移除, 必须由 IESG 批准.

6.1.1 行动发起 (Initiation of Action)

打算进入 Internet 标准轨道或在其中推进的规范, 除非自作为 RFC 发布后 未发生变化, 否则应首先作为 Internet-Draft 发布 (见第 2.2 节). 它应 作为 Internet-Draft 保持一段时间, 不少于两周, 以允许进行有用的社区 审查; 之后可以发起行动建议.

标准行动由负责该规范的 IETF Working Group 向其 Area Director 提出 建议而发起, 并抄送 IETF Secretariat; 对于不隶属于 Working Group 的 规范, 则由个人向 IESG 提出建议.

6.1.2 IESG 审查与批准 (IESG Review and Approval)

IESG 应确定根据第 6.1.1 节提交给它的规范是否满足建议行动适用的标准 (见第 4.1 和 4.2 节), 并且还应确定该规范的技术质量和清晰度是否符合 其被建议达到的成熟度级别的预期.

为获得作出这些判断所需的全部信息, 特别是当 IESG 认为某规范就其对 Internet 或 Internet 协议族的潜在影响而言极其重要时, IESG 可以自行 决定委托对该规范进行独立技术审查.

IESG 会向 IETF 发出通知, 说明 IESG 即将审议该文档, 以允许一般 Internet 社区进行最终审查. 这种 "Last-Call" (最后征求意见) 通知应 通过电子邮件发送到 IETF Announce 邮件列表. Last-Call 的评论可由任何 人提交, 并应按 Last-Call 公告中的指示发送.

Last-Call 期限不得短于两周, 但拟议标准行动并非由 IETF Working Group 发起的情况除外; 在这种情况下, Last-Call 期限不得短于四周. 如果 IESG 认为允许更多评论时间符合社区利益, 它可以决定采用更长的 Last-Call 期限, 或明确延长当前 Last-Call 期限.

IESG 不受规范提交时所建议行动的约束. 例如, IESG 可以决定考虑以不同 于请求类别的类别发布该规范. 如果 IESG 在发出 Last-Call 前作出这种 判断, 则 Last-Call 应反映 IESG 的观点. IESG 也可以基于对 Last-Call 的回应决定更改发布类别. 如果该决定会导致规范以比原 Last-Call 所针对 的类别更 "高" 的级别发布, 则应发出新的 Last-Call 来说明 IESG 建议. 此外, 对于并非源自 IETF Working Group 的规范, 如果 Last-Call 回应中 出现重大争议, IESG 可以决定建议成立新的 Working Group.

Last-Call 期满后, IESG 应及时就是否批准该标准行动作出最终判断, 并 通过发送到 IETF Announce 邮件列表的电子邮件通知 IETF 其决定.

6.1.3 发布 (Publication)

如果标准行动获得批准, 则向 RFC Editor 发送通知并抄送 IETF, 指示将该 规范作为 RFC 发布. 此时, 该规范应从 Internet-Drafts 目录中移除.

已完成和待完成标准行动的官方摘要应出现在 Internet Society 新闻简报的 每一期中. 这构成 Internet 标准行动的 "publication of record" (正式 记录出版物).

RFC Editor 应定期发布 "Internet Official Protocol Standards" RFC [1], 汇总所有 Internet 协议和服务规范的状态.

6.2 在标准轨道中推进 (Advancing in the Standards Track)

对于伴随规范沿标准轨道推进的每个行动, 均遵循第 6.1 节描述的过程.

规范应在 Proposed Standard 级别保持至少六 (6) 个月.

规范应在 Draft Standard 级别保持至少四 (4) 个月, 或直到至少召开过 一次 IETF 会议, 两者取较晚者.

这些最短期限旨在确保社区有充分审查机会, 同时不严重影响及时性. 这些 间隔应自相应 RFC 发布日期起计算; 如果该行动没有导致 RFC 发布, 则自 IESG 批准该行动的公告日期起计算.

规范在标准轨道中推进时可以 (事实上很可能会) 被修订. 在每个阶段, IESG 应确定对规范修订的范围和重要性, 并在必要且适当时修改建议行动. 小修订是预期之内的, 但重大修订可能要求该规范在当前成熟度级别积累更多 经验后才能继续推进. 最后, 如果规范发生了非常重大的更改, IESG 可以 建议将该修订视为新文档, 从头重新进入标准轨道.

状态变更应导致该规范作为 RFC 重新发布, 除非在少见情况下, 该规范自上 次发布以来完全没有变化. 通常, 期望的更改会被 "batched" (成批处理), 以便在标准轨道的下一级别中纳入. 但是, 将更改推迟到该规范的下一次标准 行动并不总是可行或可取; 例如, 重要排印错误, 或不代表规范整体功能变化 的技术错误, 可能需要立即更正. 在这种情况下, 可以请求 IESG 或 RFC Editor 用新编号重新发布带有更正的 RFC, 且这不会重置该级别的最短停留 时间计时.

当某个标准轨道规范尚未达到 Internet Standard 级别, 但已在同一成熟度 级别保持二十四 (24) 个月, 并且此后每十二 (12) 个月直到状态改变之前, IESG 应审查负责该规范的标准化工作的可行性以及该技术的有用性. 每次 这种审查后, IESG 应批准终止或继续该开发工作; 同时, IESG 应决定将该 规范保持在同一成熟度级别, 或将其移到 Historic 状态. 该决定应通过发送 到 IETF Announce 邮件列表的电子邮件传达给 IETF, 以允许 Internet 社区 有机会发表评论. 这项规定并非意在威胁合法且活跃的 Working Group 工作, 而是提供一种行政机制, 用于终止停滞不前的工作.

6.3 修订标准 (Revising a Standard)

已确立 Internet Standard 的新版本必须像完全新的规范一样, 经历完整的 Internet 标准化流程. 一旦新版本达到 Standard 级别, 它通常会替代先前 版本, 而先前版本会被移到 Historic 状态. 但是, 在某些情况下, 为尊重 已安装基础的要求, 两个版本都可以继续作为 Internet Standards 保留. 在这种情况下, 先前版本和新版本之间的关系必须在新版本文本中或另一份 适当文档中明确说明 (例如 Applicability Statement; 见第 3.2 节).

6.4 废止标准 (Retiring a Standard)

随着技术变化和成熟, 新的 Standard 规范可能在技术上明显优越, 以至于 一个或多个用于同一功能的现有标准轨道规范应被废止. 在这种情况下, 或在 因其他原因认为某个现有标准轨道规范应被废止时, IESG 应批准将旧规范的 状态更改为 Historic. 该建议应使用与任何其他标准行动相同的 Last-Call 和通知过程发布. 废止现有标准的请求可以来自 Working Group, Area Director 或其他相关方.

6.5 冲突解决与上诉 (Conflict Resolution and Appeals)

IETF 流程的各个阶段都可能出现争议. 该流程尽可能设计为可以达成妥协并 形成真正共识, 但有时即便最理性且知识最充分的人也无法达成一致. 为实现 开放和公平的目标, 这类冲突必须通过公开审查和讨论过程解决. 本节规定 应遵循的过程, 用于处理无法通过 IETF Working Groups 和其他 Internet Standards Process 参与者通常达成共识的正常流程来解决的 Internet 标准 问题.

6.5.1 Working Group 争议 (Working Group Disputes)

个人 (无论是否为相关 Working Group 的参与者) 可以基于以下信念不同意 Working Group 建议: (a) 他或她自己的观点未被 Working Group 充分考虑, 或 (b) Working Group 作出了错误的技术选择, 从而使 Working Group 产物 的质量和/或完整性处于重大危险之中. 第一个问题是 Working Group 流程 困难; 后者是技术错误主张. 这两类分歧非常不同, 但都通过同一审查过程 处理.

不同意 Working Group 建议的人应始终首先与 Working Group 主席讨论该 事项, 主席可以让 Working Group 的其他成员 (或整个 Working Group) 参与讨论.

如果分歧不能以这种方式解决, 任何相关方都可以将其提交给该 Working Group 所属领域的 Area Director. Area Director 应尝试解决争议.

如果 Area Director 不能解决该分歧, 任何相关方随后都可以向整个 IESG 上诉. IESG 随后应审查该情况, 并以其自行选择的方式尝试解决.

如果该分歧在 IESG 层面未能使各方满意地解决, 任何相关方都可以向 IAB 上诉该决定. IAB 随后应审查该情况, 并以其自行选择的方式尝试解决.

关于是否遵循了 Internet 标准过程的问题, 以及所有技术价值问题, IAB 的 决定是最终决定.

6.5.2 流程失效 (Process Failures)

本文档提出必须遵循的过程, 以确保 Internet Standards Process 的开放性 和公平性, 以及所创建标准的技术可行性. IESG 是 IETF 为此目的设置的 主要代理机构, 并负责确保所要求的过程已经被遵循, 且任何标准行动所需的 必要前提已经得到满足.

如果个人不同意 IESG 在此流程中采取的行动, 该人应首先与 IESG Chair 讨论该问题. 如果 IESG Chair 无法使投诉人满意, 则整个 IESG 应结合 投诉人的意见重新审查所采取的行动, 并确定是否需要进一步行动. IESG 应 向 IETF 发布其对投诉审查的报告.

如果投诉人对 IESG 审查结果不满意, 可以向 IAB 提出上诉. IAB 随后应 审查该情况, 以其自行选择的方式尝试解决, 并向 IETF 报告其审查结果.

如果情况需要, IAB 可以指示废止 IESG 决定, 局面随后应恢复到作出 IESG 决定之前. IAB 也可以向 IESG 建议一项行动, 或作出其认为适合的其他 建议. 但是, IAB 不得通过发布只有 IESG 才有权作出的决定来预先取代 IESG 的角色.

关于是否遵循了 Internet 标准过程的问题, IAB 的决定是最终决定.

6.5.3 适用过程问题 (Questions of Applicable Procedure)

只有在声称过程本身 (即本文档描述的过程) 不足以或不充分保护公平开放的 Internet Standards Process 中所有各方权利的情况下, 才可进一步寻求 救济. 基于此理由的主张可以提交给 Internet Society Board of Trustees. Internet Society 主席应在两周内确认收到此类上诉, 并在确认时告知申请 人 Trustees 对该上诉审查的预计持续时间. Trustees 应以其自行选择的 方式审查该情况, 并向 IETF 报告其审查结果.

Trustees 完成审查后的决定, 对争议的所有方面均为最终决定.

6.5.4 上诉过程 (Appeals Procedure)

所有上诉都必须包含对争议事实的详细且具体的描述.

所有上诉都必须在拟挑战行动或决定成为公众知悉事项后的两个月内发起.

在上诉流程的所有阶段, 负责作出决定的个人或机构有权定义其在作出决定 过程中将遵循的具体过程.

在所有情况下, 关于争议处理的决定以及向相关方传达该决定, 都必须在合理 时间内完成.

[NOTE: 这些过程有意且明确地不建立一个固定最长时间, 来规定所有情况下 应视为 "reasonable" (合理) 的期限. Internet Standards Process 重视 共识以及达成共识的努力, 并有意放弃确定性且快速的过程执行, 以保留一定 余地, 使更真实的技术协议能够达成.]

---