摘要

  • 拟议的 IETF 工具服务级别协议只覆盖系统性能与可用性，明确不评价工具团队表现，也不决定团队工作的排期与规划。
  • 同期的用户体验咨询处理界面、无障碍、访问控制、客户端要求以及网页、命令行、插件、API、MCP 和离线模式；系统性能因由另一项咨询处理而被排除。
  • 两项咨询应保留各自的决策时钟，但可以共享一份版本化反馈—决策回执，逐项写明适用服务、指标与测量点、排除项、决策权、实施责任、优先级与时间状态，以及后续报告和复核路径。

同一开场日，不同治理对象

2026 年 9 月 17 日，IETF LLC 同时向社区征询有关 IETF 工具的两类意见。两项咨询都在 10 月 12 日截止，也都允许向 LLC 董事会和执行主任私下反馈，或在 tools-discuss 邮件列表公开讨论。形式相似，不等于权责相同。

SLA 文件要建立的是可观察的系统行为标准。它讨论可用性、网页响应、邮件延迟和事故响应，给服务划分等级，为部分降级设置权重，列出不计入测量的情形，并设计月度报告与年度复核。它试图把长期的“尽力而为”变成可以核验的系统期望。

UX 文件处理的是产品与访问方式。它把工具使用分为网页、命令行、插件、API、模型上下文协议和离线场景，并询问无障碍、身份验证、客户端要求、静态链接以及功能丰富界面与简洁界面之间的选择。文件明确把系统性能留给并行的 SLA 咨询。

这条分界不是编辑上的便利，而是治理事实。SLA 能说明哪个服务在什么测量点、按什么目标被观察；一次未达标却不能自动证明工具团队表现不佳，更不能替代工作优先级和排期决策。UX 决策可以确认某种使用方式值得支持，却不能因为需求被接受，就推定相关服务已经达到可用性或延迟目标。

服务时钟可以证明什么

拟议 SLA 对自身边界的表述很直接：它只适用于系统性能和可用性，不适用于工具团队的表现，也不适用于团队工作的排期和规划。后两类议题可能同样需要讨论，但不应借这份协议作出结论。

在边界以内，草案提供了相当具体的测量结构。自动监控将成为可用性判断的权威来源；完全中断权重为 1，重大降级为 0.5，轻微降级为 0.25，纯外观问题为 0。服务等级区分关键基础设施、一般业务系统以及由第三方提供的服务。网页响应目标在服务器侧测量，并排除客户端渲染、最终用户网络和指定的外部依赖。

排除项与目标值同样重要。计划维护、第三方故障、不可抗力、用户自身网络或设备，以及有意采取的安全缓解措施，不计入相同口径；紧急维护和滥用或过量流量造成的中断，则不会自动从记录中消失。如果报告只给百分比而不保留分母、测量点和排除原因，不同服务之间的比较就会失真。

草案也没有设置惩罚性承诺。未达目标后的动作是复核与改进，而非赔偿或处罚。文件承认运营依靠规模不大的分布式团队，按常规工作时段运行，并非全天候运维中心。社区面对的是服务期望、投入与运营取舍，而不是一次人员绩效打分。

历史数据的限制更不能被写成故障证据。咨询文件说系统此前一直有性能监控，但数据只保留七天，也没有定期导出，所以无法进行历史分析。这支持建立更好的测量制度，却不能据此宣称当前工具正在失效。

体验时钟需要决定什么

UX 咨询从另一项制度缺口出发。IETF 工具长期以自然演进方式形成，界面决定通常由开发者作出；新的 rfc-editor.org 引入了专业用户体验与无障碍支持，但整个工具组合此前没有正式流程系统收集并纳入社区意见。

这里的问题不是阈值，而是选择：是否应让更多工具支持命令行或离线方式？JavaScript 依赖应达到什么程度？单点登录与自助式访问控制应覆盖到哪里？未来是否需要直接支持 AI 或 MCP？哪些无障碍工作需要外部专家？功能丰富的界面应提供多少个性化能力？

这些选择会产生服务后果。离线能力可能把依赖从托管网页转移到需要维护的容器或数据集；更强的身份验证会引入新的身份系统依赖；API 或 MCP 模式会改变访问负载，也可能提高密钥或限流的必要性；无障碍改造能够显著改变客户端结构，却未必影响服务器响应时钟。后果需要被测量，但指标不能代替产品决策。

因此，两项咨询不应被压缩成一张总分表。用户完全可能在所有可用性目标均达标时，仍然无法顺利完成一个工作流程；另一项很受欢迎的界面需求，也可能改变服务等级、运维成本或资源计划。两类意见都是真实证据，只是进入不同的决策通道。

一条共同链路，而不是一只共同秒表

IETF LLC 的《社区参与政策》已经规定了最低要求：反馈应被追踪；被采纳，或明确说明未被采纳的理由；作出决定后应告知社区。两项工具咨询同时进行，为把这一义务做成可跨流程核验的记录提供了机会。

每条重要反馈都应生成一份版本化公开回执，至少保留八类信息：反馈原文或准确摘要；适用的服务或使用模式；如适用，指标及测量点；相关排除项；作出决定的机构或角色；实施责任方；优先级与时间状态；以及进入报告或复核的路径。SLA 条目与 UX 条目可以互相引用，但不能合并成同一个状态。

以“会议期间可靠离线使用”为例。UX 记录应说明离线需求是接受、拒绝还是延期，由谁作出产品决定，考虑什么实现方式。关联的服务记录则标识可下载数据集、同步端点或容器镜像，说明在何处测量，并列出不受控制的外部依赖。“UX 需求已接受”不代表服务目标已经达成；一份绿色可用性报告也不能证明离线问题已经解决。

版本控制至关重要，因为两项咨询不会始终同步。UX 方向可能早于实施计划确定；新使用模式改变负载或依赖后，SLA 指标也可能需要修订。回执应保留旧决定，标明新版本，并分别写出每次变化的授权来源。

最终产物不应是一条包揽全部工具工作的总队列，而应是一条带明确交接点的决策链。服务测量仍然只描述系统，UX 处置仍然只说明使用选择，排期仍由规划流程承担。问责来自公开一项反馈何时跨过边界，也来自公开它没有跨过哪些边界。

来源