Skip to main content

6. 互联网标准化流程 (The Internet Standards Process)

互联网标准化流程的机制涉及IESG关于将规范提升到标准跟踪或将标准跟踪规范从一个成熟度级别移动到另一个成熟度级别的决策.尽管有许多相当客观的标准 (如下所述和第4节所述) 可用于指导IESG决定将规范移至,沿着或移出标准跟踪,但对于任何规范,都没有提升到标准跟踪或沿标准跟踪前进的算法保证.IESG关于提议提升到标准跟踪或在标准跟踪中推进的规范的技术质量的经验丰富的集体判断是决策过程的重要组成部分.

6.1 标准行动 (Standards Actions)​

"标准行动"——将特定规范进入,在其中推进或从标准跟踪中移除——必须由IESG批准.

6.1.1 行动的发起 (Initiation of Action)​

打算进入或在互联网标准跟踪中推进的规范应首先作为互联网草案发布 (参见第2.2节),除非自作为RFC发布以来未更改.它应作为互联网草案保留一段时间,不少于两周,以允许有用的社区审查,之后可以发起行动建议.

标准行动由负责规范的IETF工作组向其区域主任提出建议来发起,并抄送给IETF秘书处,或者在规范与工作组无关的情况下,由个人向IESG提出建议.

6.1.2 IESG审查和批准 (IESG Review and Approval)​

IESG应确定根据第6.1.1节提交给它的规范是否满足建议行动的适用标准 (参见第4.1和4.2节),并应另外确定规范的技术质量和清晰度是否与建议的成熟度级别一致.

为了获得做出这些决定所需的所有信息,特别是当IESG认为规范在其对互联网或互联网协议族的潜在影响方面极其重要时,IESG可以自行决定委托对规范进行独立技术审查.

IESG将向IETF发出通知,通知IESG即将考虑该文档,以允许一般互联网社区进行最终审查.此"最终呼吁" (Last-Call) 通知应通过电子邮件发送到IETF公告邮件列表.任何人都可以对最终呼吁发表意见,并应按照最终呼吁公告中的指示发送.

最终呼吁期不得少于两周,除非在拟议的标准行动不是由IETF工作组发起的情况下,最终呼吁期不得少于四周.如果IESG认为允许更多时间进行评论将有利于社区利益,则可以决定更长的最终呼吁期或明确延长当前的最终呼吁期.

IESG不受规范提交时建议的行动约束.例如,IESG可以决定考虑将规范发布在与请求不同的类别中.如果IESG在发出最终呼吁之前确定这一点,则最终呼吁应反映IESG的观点.IESG也可以根据对最终呼吁的响应决定更改发布类别.如果此决定将导致规范以比原始最终呼吁更"高"的级别发布,则应发出新的最终呼吁,指示IESG的建议.此外,IESG可以决定建议在对与非IETF工作组发起的规范的最终呼吁的响应中存在重大争议的情况下组建新的工作组.

在最终呼吁期到期后的及时方式内,IESG应做出是否批准标准行动的最终决定,并应通过电子邮件向IETF公告邮件列表通知IETF其决定.

6.1.3 发布 (Publication)​

如果标准行动被批准,则向RFC编辑发送通知并抄送给IETF,指示将规范作为RFC发布.此时,规范应从互联网草案目录中删除.

标准行动完成和待处理的官方摘要应出现在互联网协会通讯的每一期中.这应构成互联网标准行动的"发布记录".

RFC编辑应定期发布"互联网官方协议标准" RFC [1],总结所有互联网协议和服务规范的状态.

6.2 在标准跟踪中推进 (Advancing in the Standards Track)​

第6.1节中描述的程序适用于伴随规范沿标准跟踪推进的每个行动.

规范应在提议标准级别保留至少六 (6) 个月.

规范应在草案标准级别保留至少四 (4) 个月,或直到至少一次IETF会议发生,以较晚者为准.

这些最短期限旨在确保有足够的机会进行社区审查,而不会严重影响及时性.这些间隔应从相应RFC的发布日期开始计算,或者如果行动不导致RFC发布,则从IESG批准行动的公告日期开始计算.

规范在沿标准跟踪推进时可能 (实际上很可能) 被修订.在每个阶段,IESG应确定对规范的修订的范围和重要性,并在必要和适当时修改建议的行动.预期会有小的修订,但重大修订可能需要规范在当前成熟度级别积累更多经验后再推进.最后,如果规范已被非常显著地更改,IESG可能建议将修订视为新文档,从标准跟踪的开始重新进入.

状态的更改应导致规范作为RFC重新发布,除非在极少数情况下自上次发布以来规范根本没有任何更改.通常,期望的更改将被"批处理"以在标准跟踪的下一个级别进行合并.然而,将更改推迟到规范的下一个标准行动并不总是可能或可取的; 例如,重要的排版错误或不代表规范整体功能更改的技术错误可能需要立即更正.在这种情况下,可能会要求IESG或RFC编辑重新发布RFC (使用新编号) 并进行更正,这不会重置最短时间级别时钟.

当标准跟踪规范尚未达到互联网标准级别但在相同成熟度级别保持了二十四 (24) 个月,并且此后每十二 (12) 个月直到状态更改,IESG应审查负责该规范的标准化工作的可行性和技术的有用性.在每次此类审查之后,IESG应批准终止或继续开发工作,同时IESG应决定将规范保持在相同成熟度级别或将其移至历史性状态.此决定应通过电子邮件传达给IETF公告邮件列表,以允许互联网社区有机会发表意见.此规定并非旨在威胁合法和积极的工作组工作,而是为终止垂死的努力提供行政机制.

6.3 修订标准 (Revising a Standard)​

已建立的互联网标准的新版本必须经过完整的互联网标准化流程,就像它是全新的规范一样.一旦新版本达到标准级别,它通常会替换先前的版本,先前的版本将移至历史性状态.然而,在某些情况下,两个版本都可能保留为互联网标准,以尊重已安装基础的要求.在这种情况下,先前版本和新版本之间的关系必须在新版本的文本中或在另一个适当的文档中 (例如,适用性声明; 参见第3.2节) 明确说明.

6.4 退役标准 (Retiring a Standard)​

随着技术的变化和成熟,新的标准规范在技术上可能如此明显优越,以至于应退役一个或多个现有的同一功能的标准跟踪规范.在这种情况下,或者当出于某些其他原因认为应该退役现有的标准跟踪规范时,IESG应批准将旧规范的状态更改为历史性.此建议应使用与任何其他标准行动相同的最终呼吁和通知程序发出.退役现有标准的请求可以来自工作组,区域主任或其他利益相关方.

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

在IETF流程的各个阶段都可能发生争议.尽可能地设计流程以便可以做出妥协并实现真正的共识,但是有时即使是最合理和最有知识的人也无法达成一致.为了实现开放性和公平性的目标,此类冲突必须通过公开审查和讨论的流程来解决.本节规定了应遵循的程序,以处理无法通过IETF工作组和其他互联网标准化流程参与者通常达成共识的正常流程解决的互联网标准问题.

6.5.1 工作组争议 (Working Group Disputes)​

个人 (无论是否是相关工作组的参与者) 可能不同意工作组的建议,理由是他或她认为 (a) 他或她自己的观点未得到工作组的充分考虑,或 (b) 工作组做出了错误的技术选择,使工作组产品的质量和/或完整性面临重大危险.第一个问题是工作组流程的困难; 后者是技术错误的断言.这两种类型的分歧是完全不同的,但都由相同的审查流程处理.

不同意工作组建议的人应始终首先与工作组主席讨论此事,工作组主席可能会让工作组的其他成员 (或整个工作组) 参与讨论.

如果分歧无法以这种方式解决,任何相关方都可以将其提请工作组所在区域的区域主任注意.区域主任应尝试解决争议.

如果区域主任无法解决分歧,任何相关方都可以向整个IESG上诉.IESG应审查情况并尝试以其自己选择的方式解决.

如果分歧在IESG级别未得到各方满意的解决,任何相关方都可以向IAB上诉.IAB应审查情况并尝试以其自己选择的方式解决.

IAB的决定对于是否遵循互联网标准程序的问题以及所有技术优点问题都是最终的.

6.5.2 流程失败 (Process Failures)​

本文档提出了必须遵循的程序,以确保互联网标准化流程的开放性和公平性,以及所创建标准的技术可行性.IESG是IETF为此目的的主要代理,IESG负责确保已遵循所需的程序,并且已满足标准行动的任何必要先决条件.

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

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

如果情况需要,IAB可以指示撤销IESG决定,情况应回到IESG决定之前的状态.IAB也可以向IESG推荐行动,或做出其认为合适的其他建议.然而,IAB不能通过发布只有IESG有权做出的决定来抢占IESG的角色.

IAB的决定对于是否遵循互联网标准程序的问题是最终的.

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

只有在声称程序本身 (即本文档中描述的程序) 不足以保护公平和开放的互联网标准化流程中所有各方的权利的情况下,才可以进一步求助.基于此基础的索赔可以向互联网协会理事会提出.互联网协会主席应在两周内确认此类上诉,并应在确认时告知请愿人理事会审查上诉的预期期限.理事会应以其自己选择的方式审查情况,并向IETF报告其审查的结果.

理事会在完成审查后的决定对于争议的所有方面都是最终的.

6.5.4 上诉程序 (Appeals Procedure)​

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

所有上诉必须在要挑战的行动或决定的公开知识后两个月内发起.

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

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

[注意: 这些程序故意且明确地没有建立在所有情况下都应被视为"合理"的固定最长时间段.互联网标准化流程重视共识和实现共识的努力,并故意放弃程序的确定性快速执行,以支持可以达成更真实技术协议的自由度.]

Last updated on