摘要

  • 旧 SLA 自 2016 年以来只在 42.5% 的已测季度达标，且曾把等待作者回复的时间算在 RPC 身上、遗漏等待分配编辑等状态，已经不足以支持公平问责。
  • 新方案按页数分档，以滚动一年统计 RPC 可控时间，并同时收紧覆盖比例和最长处理时间；这是一项合理的承包服务边界，却不是完整出版结果。
  • 典型 30 至 50 页 RFC 目前从接收到发布约需 245 个日历日。制度应在 RPC 指标之外保留可归责的交接账本，分别呈现 RPC、其他参与方与端到端三种时间。
  • 方案假定资源和工作范围不变，预计三年仅减少约 20% 积压、七至十二年清零。这是需要持续验证的情景，不是已兑现的结果。

队列中缺少一个名字，就少了一项可治理事实

旧 SLA 的问题不只是目标太难。征询文件给出的历史结果是：自 2016 年以来，它只在 42.5% 的已测季度达到要求。一个大多数时候失败的指标无法区分异常与常态，也很难告诉管理者应改变人力、流程还是目标。

更深的问题在状态定义。2025 年第二季度调整测量方式以前，制作中心明明在等作者回复，记录却可能仍显示 RPC 的钟在走。系统也没有“等待分配编辑”的独立状态。到了 AUTH48，作者对编辑后的最终文字进行确认，一部分真正花掉的日历时间又可能不在被观察的 RPC 时钟里。于是，同一套记录可以一边多算 RPC 的责任，一边漏掉作者实际经历的等待。

新方案选择只考核 RPC 能控制的时间。这比把所有停顿压给一个承包服务公平得多。作者没有回答问题、IESG 需要处理技术事项、IANA 注册动作尚未完成，制作中心未必有权推动结果。可归责性要求把改变某段等待的权力与对那段等待的责任放在一起。

然而，责任边界不能替代服务全貌。作者不会在日历上体验“可控日”和“不可控日”，只会看到文档何时获准制作、何时收到编辑问题、何时进入最终确认、何时成为可以引用的 RFC。对实施者和读者而言，稳定文本出现的日期同样只有一个。

征询估计，一份 30 至 50 页的典型 RFC 目前从接收到出版约需 245 个日历日。现有积压大约给这一状态增加 115 天；如果没有积压，模型约为 130 天。文件还称，作者、IESG、IANA 等 RPC 控制之外的时间平均约 97 天，且与页数大致无关。这几组数字描述的是总体或模型化状态，彼此有交叠，不能简单相加成 457 天。

页数主要影响制作中心能够左右的部分。方案估计每增加一页，RPC 工作时间平均增加约 0.34 天。由此按文档大小设档是合理的，否则短文比例变化就能令总体指标看似改善，长文集中出现则会令它看似恶化。但是，大小校正只能解释工作量，不能解释一份具体文档为何在某个环节停止。

两道棘轮如何收紧承诺

拟议协议使用滚动一年数据，以免一个季度的偶发组合决定评价。它同时看吞吐量、最大活动积压和按文档大小校正的处理时间分位数。第一季度基线要求至少 75% 的文档落在 RPC 可控时限内：15 页及以下为 130 天，16 至 40 页为 170 天，40 页以上为 190 天。

之后有两道棘轮。达标文档比例每季度增加一个百分点，直至 85%；第一年以后，各档最长处理时间每年再下降 5%。前者扩大被承诺覆盖的文档，后者缩短其等待。比起一条多年不变、最后只能通过解释来维持的静态目标，这种安排确实更可检验。

积压却不会很快消失。在编辑资源与工作内容保持不变的前提下，模型预计三年减少约 20%，全部清理需要七至十二年。这个时间跨度把一项治理选择暴露得很清楚：方案选择在现有资源基线上渐进改善，而不是购买一次快速清零。

这不是技术预测可以代替的决定。到稿量上升、文档复杂度变化、编辑人员流动、某一 RFC 文档流突然增加，都会改变路径。征询也直接询问社区，是否应为零积压投入短期资金、作者满意度应怎样衡量、是否应该为速度减少工作，以及质量要如何保护。所谓“七至十二年”只能是当前假设下的基准线。

AUTH48 证明：计时必须带着责任人一起移动

RFC 9280 描述 RFC Editor Model 中政策、批准和制作角色的区分；RFC 8711 规定相关行政支持结构。作者指南、公开队列说明和面向工作组主席的材料则展现了实际旅程：初检、分配、编辑、问题往返、引用依赖、IANA 协作、AUTH48 与正式发布。多环节不是天然浪费，恰恰是 RFC 作为长期技术记录能够保持质量的一部分。

AUTH48 是最清楚的责任交接。编辑工作接近完成，作者和指定审阅者要批准最终文本。如果作者迟迟不答，把这段时间判作 RPC 未达标是不公正的；如果为了保护 RPC 指标而让这段日历时间从公共叙事中消失，同样不诚实。它是真实等待，有下一行动人，也可能有提醒与升级路径。正确做法是注明归属，而不是删除。

“等待分配编辑”也说明同一件事。没有编辑正在处理，不代表这段时间没有制度所有者。如果数据只识别“正在编辑”，等待室就会被排除在工作之外，队列看起来比实际短。为停顿命名的意义在于：命名以后才能比较年龄、设升级规则、观察资源是否足够。

因此，SLA 旁边需要一份可归责交接账本。每次状态变化至少应保留进入与离开时间、责任角色、下一行动方、所用时钟、原因、升级状态以及后来是否更正。公开数据可以汇总，毋须披露编辑往来内容。由同一组状态事实，可以生成 RPC 可控时间、其他主体可控时间和端到端日历时间三项互不替代的总数。

更正也必须留下历史。一次错误归类可以修复，但要记录原值、新值、更改日期、理由与授权方。否则，绩效曲线可能仅因过去的时间被重新挪到边界之外而改善。审计轨迹不是禁止纠错，而是使纠错无法冒充服务进步。

看见交接，不等于制造授权

RFC 9280 把 RFC Series 政策制定交给 RSWG，并由 RSAB 承担相应批准职能；RPC 负责落实出版制作。RFC 8711 赋予 IETF Administration LLC 行政、运营与财务责任，却没有把 IETF 标准权力一并转交。它们是彼此分开的权限，不是一条上下级命令链。

交接账本不会改变这套分工。它只证明文档何时进入或离开某一机构所负责的区段、下一步由谁行动，以及事后如何更正。证据可以跨越机构边界，管理员、制作中心或指标本身却不能因此取得边界另一侧的权力。

一套指标要服务五种不同问题

RPC 需要知道自己能改变什么；IETF Administration LLC 需要监督合同；作者要知道谁应该做下一步；各文档流管理者要识别流程摩擦；社区要判断资源、范围和质量共同造成的出版结果。读者最后只关心稳定 RFC 何时出现。这些问题不可能由一个数字同时回答。

拟议 SLA 作为承包服务控制工具是有力的。风险只在于把它的绿色结果叙述成整个 RFC 出版系统健康。只要外部等待、IANA 依赖、AUTH48 停顿或分配前积压不在同一边界内，RPC 分位数就可能改善而端到端日历不动。

解决办法也不是把全部天数重新算给 RPC。那会诱使制作中心为了保护成绩而催促无权控制的主体，甚至压缩必要审阅。细颗粒归责同时避免两种错误：既不让 RPC 为别人负责，也不让 IETF 所拥有的完整系统因跨出合同边界而变得不可见。

公开的个人意见表明，社区正在测试这些假设。Mirja Kühlewind 的来信追问拟议时限的意义和效用，Acee Lindem 则从实际速度与预期作出回应。两者都是个人意见，不代表 IETF 共识。它们的制度价值在于，在指标成为日常绩效语言以前，逼迫方案解释其边界。

9 月 6 日以前真正需要决定的事

不同 RFC 文档流是否需要不同目标，看似是精度问题，也可能制造碎片化问责。作者满意度能揭示摩擦，也可能奖励“不提出困难编辑问题”的顺滑体验。短期资金能够清积压，却不能在到稿持续高于产能时阻止队列重建。减少服务范围会令速度数字变好，同时把工作转给志愿者或牺牲档案质量。

因此，每项优化都应说明成本落到谁身上。速度之外，还应单列实质性返工、出版后重要更正、作者争议与编辑一致性。RFC Series 的使命是留下可长期依赖的技术记录，不是最大化完成件数。一份快速通过但编辑价值被削弱的文档，不是同一种服务。

在征询结束以前，最稳健的选择不是反对 RPC 拥有清晰 SLA。恰恰相反，它应拥有一项只覆盖自身可控时间的公平承诺。与此同时，采纳决定应保留完整旅程视图和不可静默改写的状态历史。一项负责合同问责，另一项防止机构把合同边界误认作用户体验边界。

来源

  1. RFC 编辑与出版服务等级协议征询文件
  2. IETF Administration LLC 征询公告
  3. RFC 9280：RFC Editor Model（第三版）
  4. RFC 8711：IETF 行政支持活动结构 2.0
  5. 面向作者的 RFC 出版流程
  6. RFC Editor 队列运作说明
  7. 面向工作组主席的 RPC 流程资料
  8. RFC Series 关于出版时间与流程状态的讨论
  9. Mirja Kühlewind 的个人征询回应
  10. Acee Lindem 的个人征询回应