摘要

  • IAB 于9月10日启动调查，询问未来选择 Independent Submissions Editor 时应考虑的能力、特质和期待，截止日为10月11日。
  • 调查采用匿名模式，邀请来自多张可能重叠的名单，也直接发给活跃 Internet-Draft 作者及过去15年经 Independent Stream 发表 RFC 的人士；通知承认有人可能收到多次，并允许转发。
  • RFC 8730 已列出六组资格要求，并规定 IAB 在收集社区意见后作出选择。调查可以细化这套基线，却不会把任命权变成交给答卷数量。
  • 在未来候选人接受评估前，应发布一份保护隐私的解读规则：说明招募边界、主题编码方法、冲突意见的处理，以及每条标准相对 RFC 8730 是保留、澄清、新增还是删去。

答卷总数没有天然分母

根据IETF 的调查说明，这份问卷大约需要十分钟。IETF 和 IRTF 的公告名单、IETF 工作组主席名单、RFC Interest、RFC Series Working Group 都会收到邀请。另有两类人被直接联系：目前有活跃 Internet-Draft 的人士，以及过去十五年通过 Independent Stream 发表过 RFC 的人士。

这些入口不是互斥样本。一位工作组主席可能同时维护草案，也可能早已在 Independent Stream 发表过文稿。相同的人还可能订阅数张名单。通知因此预先为“可能不止收到一次”致歉，并欢迎收件人把链接转给更广的 RFC／Independent Stream 相关人士。

作为开放征询，这样设计有明显价值。角色会影响作者、审稿人、RFC Series 治理和不在 IETF 核心圈内的技术贡献者；只向一份封闭名单发问，反而可能错过最需要听见的经验。可是，当链接可以越过已知名单继续流动时，公开资料就无法说明究竟有多少独立个体被邀请。

调查以匿名模式运行，说明称不会收集 IP 地址等资料。这有助于减少不必要的数据，也有助于参与者坦白表达。匿名并不证明有人重复作答，更不证明平台没有内部控制；重复收到邀请也不等于重复提交。能够确定的边界只有一条：公开记录不足以把答卷数除以一个稳定人口，再把所得百分比解释成代表性授权。

因此，调查结束后最容易发布的数字也许最不应该主导结论。“共有多少人完成”只能描述活动量，不能说明这些人占哪个群体的多少比例。IAB 主席 Dhruv Dhody 的公告已经把制度边界写清：回答将帮助 IAB 形成未来评估标准；这不是对现任或历任 ISE 的评价，不是对 Independent Stream 模式的表决，ISE 的任命仍由 IAB 决定。

问卷之前已有六项公开基线

未来标准并非从空白纸开始。RFC 8730提出六组理想资格：跨越多种互联网技术的广泛能力；对 RFC Series 的深入熟悉；组织咨询与文稿审查的能力；在 IETF 内外技术社群中的良好声誉；编辑技巧、英语能力及处理他人技术文本的经验；以及在权力与责任分散的多主体环境中有效工作的能力。

同一份 RFC 还列出职务工作。ISE 负责 Independent Submission stream 的技术质量，审查、批准并处理投稿，把进入出版阶段的文稿交给制作方，发展这条出版流的范围，处理勘误，与 RFC Series 的共同政策协调，并按要求提供统计和文件。ISE 可以组织咨询委员会；IAB 则在收集社区意见后选择任职者。

2026年的调查完全可以让这些表述更准确。新的 RFC Editor 模型可能要求不同的协作经验；技术领域扩展可能改变寻找合格审稿人的难度；实际工作也可能暴露旧文本没有明确命名的能力。另一种同样合理的结果，是调查证明旧表述已经足够。

治理问题不在于标准能否变化，而在于变化能否被追溯。若下一次征集候选人时只出现一张重新润色的条件清单，公众便无法分辨：哪一项来自 RFC 8730，哪一项是现有工作的经验，哪一项来自调查主题，哪一项是 IAB 自己的判断。大家知道问卷发生过，却不知道它产生了什么作用。

这个职位守护的是一条不同的出版路径

RFC Editor 对 Independent Submissions 的说明强调，这条出版流位于 IETF、IAB 和 IRTF 的正式流程之外。通过它发表的 RFC 不需要、也不携带社区共识，并非互联网标准或最佳实践。它可以容纳协议实践、厂商专用协议、尚未成熟到适合标准化的想法、对 IETF 流程的批评、历史资料乃至幽默作品。

“独立”不是免审。RFC 4846描述的价值，是让有意义的材料进入同一公共档案，同时不冒充 IETF 的正式批准。ISE 在审稿人和 Independent Submissions Editorial Board 的帮助下决定个别投稿；IESG 的冲突审查则帮助区分独立出版与现有标准工作。

选任标准还会影响 RFC Series 的共同治理。按照现行 RFC 9920，Independent Stream 在 RFC Series Approval Board 的投票代表，是 ISE 本人或由 ISE 指派的人。候选人所需的判断力，不仅作用于一篇文稿能否出版，也作用于这条出版流如何参与全系列政策批准。

这不意味着 ISE 能创造 IETF 共识。恰恰相反，职位需要持续守住界线：既能参与共同出版规则，又不让这些规则抹去独立流的用途；既能判断技术质量，又不把出版决定包装成标准化授权。

IAB 任命页面目前列出 Eliot Lear 的任期为2022—2028，并说明每个 ISE 任期为两年。新调查没有公布候选人、替换计划或绩效结论。既然公告明确排除了对现任和历任者的评价，分析也不应越过这条线。

一份可执行的解读说明

第一部分记录范围：目的、起止日期、公开的邀请渠道、直接联系的资格范围、可能重复收到邀请以及可转发政策。这些信息证明触达方式，却不能合成一个“独立受邀者总数”。

第二部分记录分析方法。自由文本是否按主题编码？同一观点出现多次，是频率、重要性、风险线索，还是经验趋同？互相冲突的建议怎样同时保留？少数但技术上具体的回答，是否能揭示多数人没有遇到的职责缺口？方法无须假装成统计抽样研究，但每张图表必须说明它表示什么。

第三部分建立基线矩阵：左侧逐项放入 RFC 8730 的六组资格和核心职责，右侧放入未来实际使用的条件。每一项标记为“保留、澄清、新增、删去”，附上简短理由，并区分证据来自调查、运行经验、RFC 模型变化还是 IAB 判断。

第四部分给标准加版本和日期，而且必须在评估未来候选人之前冻结。后来若发现新要求，应形成下一次修订记录，不能悄悄改变已经用来比较人的尺子。

第五部分保留未知。问卷可能无法可靠说明工时、稀缺审稿能力、行政支持或下一轮制度变化。明确写出“不知道”，比让一个高比例回答替代证据更可信。

公开转换规则，不公开匿名者

问卷的线上入口不应变成公开答卷仓库。即使没有姓名和 IP，把角色、资历和具体经历拼在一起，也可能重新识别个人。公开候选人评分表、私人推荐、个人评论或冲突细节，同样不是这篇文章所要求的问责方式。

真正需要公开的对象更小：解释方法、标准变化和最终版本。The Policy Mirror追问真正支配决定的文件。在这里，问卷是意见入口；未来冻结的条件和 IAB 对条件的应用才支配任命。若入口高调可见而转换过程始终隐形，咨询界面便会借走决策文件的权威。

这条规则也能保护少数意见。一个罕见回答可能指出某类作者长期无法获得合适审稿，或揭示只在特殊案件中出现的利益冲突。按票数排序会让它沉底；按结构化意见解读，IAB 可以说明为什么低频风险改变了一条要求，也可以说明为什么高频偏好没有成为硬条件。

证据止于结果之前

公开来源能够证明调查何时开始和结束、为何启动、如何发出邀请、采用何种匿名声明，以及谁保留任命权。它们也能证明现有资格基线、职责、任期公开记录和 Independent Stream 的制度位置。

来源没有提供完整静态问卷、答卷集合、分析计划、新版标准、候选名单或下一次任命时间表。没有证据表明 IAB 会把计数当投票，也没有证据表明任何人会重复提交或现有框架失效。本文不作这些推断。

最小初始规范的意义，是在未知尚多时先固定一段最关键的程序；现实而非倡议则要求结果出现后继续分清：观察到的主题、没有被证明的代表性、IAB 的制度判断和 IAB 自己承担的任命决定。

来源

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. IETF — Survey to gather input on ISE selection criteria
  5. IETF 公告存档 — IAB Survey on Future ISE Selection Criteria
  6. ISE Selection Criteria Survey
  7. RFC 8730 — Independent Submission Editor Model
  8. RFC 4846 — Independent Submissions to the RFC Editor
  9. IAB — Appointments & Confirmations
  10. RFC Editor — Independent Submissions
  11. RFC 9920 — RFC Editor Model (Version 3)