摘要
- 9 月 9 日 08:59 UTC，作者以“Call for Adoption”为主题，请求 DNSOP 采纳一份 DNS 解析延迟测量草案。10:37 UTC，主席 Benno Overeinder 说明采纳征集由主席发起，作者公告与邮件列表讨论属于此前步骤。
- 这次回复不是拒稿。截稿时，00 版仍是处于
I-D Exists状态的个人 Internet-Draft；没有工作组采纳记录，也没有 IETF 背书。 - 草案在技术层面提出了相似的证据要求：所谓“DNS 延迟”可能包含不同链路与处理阶段。程序标题不能赋予发件人机构权限，指标名称也不能赋予数字可比性。
先还原 98 分钟内真正发生的事
Jishuang Wang 在第一封邮件中直截了当地请求工作组采纳 A Framework for DNS Resolution Latency Measurement。正文提出三个可供讨论的问题：这个问题是否适合 DNSOP；测量框架和术语是否有用；工作组是否愿意以采纳作为后续讨论与完善的起点。
这些问题本身没有越界。任何参与者都可以介绍工作、争取关注、邀请反对意见。歧义来自主题行：它没有写“请求发起采纳征集”，而是直接写成“采纳征集”。脱离正文后，这个标题很容易被搜索索引、会议简报或自动摘要理解为正式窗口已经打开。
10:37 UTC，DNSOP 主席 Benno Overeinder 在公开回复中给出顺序。DNSOP 的采纳征集由主席发起。在此之前，草案必须先在邮件列表讨论，最好还在 DNSOP 工作组会议上介绍。作者已经完成的，是第一步公告；但标题不应写“Call for Adoption”。可以先询问问题是否属于 DNSOP、框架是否有用。之后根据讨论和工作组兴趣，主席才可能把采纳征集作为第三步启动。
主席没有否定草案价值，没有终止讨论，也没有断言未来不会发起征集。他只是把档案中的现在时校正回来：作者提出了请求；正式征集尚无证据。
Datatracker 记录的是“个人草案”
Datatracker 当前页面把 00 版列为活跃的个人 Internet-Draft，IESG 状态为 I-D Exists。页面还有标准提示：任何人都可以提交 I-D；这份草案未获 IETF 背书，在标准流程中不具有正式地位。
历史记录只显示 9 月 9 日提交初版，并没有工作组采纳事件。草案页眉写有预期的 Informational 状态，失效日为 2027 年 3 月 13 日；Datatracker 的正式“Intended RFC status”字段则为空。作者在文件中声明的方向，与流程数据库已经赋予的状态，不是同一件事。
因此，新闻记录必须保留完整状态链：
作者公告并请求 ≠ 主席发起征集 ≠ 主席评估工作组兴趣 ≠ 工作组采纳 ≠ 文件继续推进 ≠ RFC 发布。
未来事件可以改变状态。过去的主题行不能提前替未来盖章。
开放参与需要清晰的权限边界
把“谁能发起征集”说清楚，并不是把标准制定封闭起来。恰恰相反，开放系统要允许所有人发言，同时让读者知道哪一种发言会改变机构状态。
RFC 2418把邮件列表置于工作组工作的中心，并由主席管理流程、判断粗略共识。它特别提醒，邮件数量本身不能证明共识。RFC 7282进一步强调，关键在于技术异议是否得到认真处理，而不是赞成者人数。即使一百个人回复“支持”，一个未被回答的实质问题也不会因此消失。
这两份 RFC 没有逐字规定主席邮件里所说的 DNSOP 三步做法；那项本地流程的直接证据就是主席回复。RFC 提供的是更大的治理逻辑：正式征集必须有可问责的发起人、明确的目标版本与时间窗口，之后还要有人把异议和结论区分开。
若每个参与者只凭主题行就能创建正式状态，同一档案可能同时出现多个“采纳征集”，各自指向不同版本和截止时间。权限边界没有削弱作者的提议权，而是阻止提议借用工作组的名义。
“DNS 延迟”也只是一个未经展开的标题
00 版草案不定义新 DNS 协议行为、不修改报文格式，也不强制采用某种测量算法。它试图解决的是语义：两条都标为“DNS 延迟”的记录，究竟测了哪一段。
草案把时间分成三个概念组件。TC1 是客户端与递归解析器之间的通信；TC2 是递归解析器内部处理，可能包含缓存查找、政策判断、DNSSEC 验证和响应构造；TC3 是递归解析器同一个或多个权威服务器之间的交互。
端到端测量可能覆盖 TC1、TC2 和 TC3。解析器内部性能可能只看 TC2。客户端到递归解析器的数字可能只有 TC1。RFC 9499让这些 DNS 角色的称谓稳定下来，但仍不能替一条具体记录说明计时器从哪里开始、在哪里结束。
上下文还会改变含义：缓存命中或未命中、传输协议、查询类型、网络连通、地理位置、解析器配置、部署架构，都可能影响结果。RFC 7858涉及 DNS over TLS 的连接建立与复用，RFC 9250定义 DNS over QUIC。这些 RFC 并不证明哪一种传输更快；它们说明传输和连接状态为什么必须写进测量说明。
于是，两组中位数都可以计算正确，却回答不同的问题；两个 P95 也可能因为采样方法、观察区间、查询群体和测量范围不同而不可直接比较。小数位数增加的是外观精度，不是证据兼容性。
先给测量办“护照”，再做排名
草案提出一套可复用描述模板：测量标识、目标、范围、测点、所含时间组件、上下文、观察区间、采样方法、统计表达和备注。
其示例明确只是演示。它描述从递归解析器观察 TC3：缓存未命中，使用 DNS over QUIC 与 IPv6，目标是 anycast 权威服务，时间为 2026 年第一季度，采用被动观察，给出中位数 14.2 毫秒和 P95 27.6 毫秒，并注明启用 DNSSEC 验证。
草案没有要求每个使用场景填满所有字段，也允许渐进采用。但它说明遗漏相关信息会降低可解释性与可比性。这里的互操作，是不同实现的结果能被一致理解，而不是不同系统必须测出同一个数。
这套最小描述不会替运营者选择探针，却能让排行榜先证明自己比较的是同类对象。若一张图无法显示范围、测点和样本来源，它只能证明图表存在，不能证明排名公平。
把程序记录与测量记录装进同一来源信封
这一事件暴露的共同风险，是外包装从名称所指对象那里“借来”权威。主题行借用工作组权限；指标名借用统计可比性。
我建议使用一个状态—测量来源信封。这是编辑性提议，不是 IETF、DNSOP 或草案规定。
程序部分记录草案名称、版本和不可变摘要；作者公告的消息 ID、时间、角色与所请求动作。若主席后来正式发起征集，那应当是另一条事件，拥有自己的消息 ID、起止时间和目标版本。讨论材料按实质问题关联，而不是按“赞成”数量折算。主席声明的结果再创建下一状态；只有真实发生后，才加入 shepherd、RFC stream、IESG 或 RFC 标识。
测量部分则保留目标、范围、测点、TC1/TC2/TC3 组合、环境、区间、采样、统计和备注。原始数据可以因隐私、安全或商业原因由保管人控制，但公开结论要留下可核验的引用。
两部分需要关联，却不能彼此替权。一份草案未来被采纳，不会认证任何性能数据；一项测量做得完整，也不会让描述它的草案自动获得工作组地位。
Heng Lu 的 The Policy Mirror要求把行动者、规则和与状态相称的证据留在镜中。Minimum Initial Specification支持窄小的共同核心，把实现选择留给本地。Why BTW Media Exists则划定新闻边界：请求就是请求，不能升级为征集；数值就是带条件的观察，不能自行升级为比较。
主席回复篇幅很短，却及时阻止了一个标题沉淀成错误的机构记忆。草案对测量的要求同样朴素：今天保留语境，明天的数字就不会被迫承担它从未测量过的含义。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance