摘要

  • 截至 2026 年 8 月 27 日，DAWN 仍被 Datatracker 标为拟议工作组；其第一版章程处于 IESG/IAB 内部审议，表决问题只是“是否已准备好进入外部审议”，不是最终批准成立。
  • NETCONF 已经是活跃工作组，但 20-02 只是重订章程提案。页面明确写明：当前获批章程仍是第 20 版，新文本尚未替代它。
  • RFC 2418 把章程称为 IETF 与工作组之间、针对一组具体任务的制度性契约。拟任主席与区域主管协商，IAB 提供意见，社群参与审议，IESG 作出章程决定，秘书处登记并公告获批文本。
  • 章程获批只建立有限的工作范围；它不采纳某份 Internet-Draft，不证明文件内容已有共识，不批准 RFC，也不要求运营者部署成果。

最新文本为何可能最不具权威

普通文档通常鼓励读者阅读最新版。错字被修正、论证被补充，旧版自然让位。这种阅读习惯一旦套在章程上，就会漏掉第二条时间线：文本更新时间与制度生效时间不是同一件事。

章程提案可以多次改版，拥有公开编号、完整目标、拟任主席、邮件列表、交付物和里程碑，却仍只是一项请求。权威不从文字成熟度自动产生，而从程序指定的决定产生。版本号回答“大家正在审什么”，生效标记回答“工作组现在获准做什么”。

初始章程与重订章程之间还有更深一层差异。初始章程获批前，提议中的制度容器尚不存在；重订章程获批前，现有工作组没有消失，它继续受已批准旧文本约束。只保留 latest 的系统会把前者从无变有，也会把后者从旧变新，两次都跳过决定者。

这种错误会改变现实。议程时间开始倾斜，作者把个人草案描述成工作组方向，相邻工作组让出问题空间，外部标准组织等待 IETF，企业把尚在讨论的范围写进产品叙事。日后即使章程缩窄，已经形成的投入和依赖也不会随着页面标签一同消失。

可靠记录必须同时保留“最新提案”和“现行章程”。对于初始提案，现行章程应明确为空；对于重订过程，它应继续指向旧版，直到一项可归属的批准与公告完成交接。空值不是数据缺失，而是“权威尚未产生”的真实状态。

DAWN：内部审议不是成立证明

DAWN 页面在观察日写的是“Proposed WG Discovery of Agents With Names”，工作组状态为 Proposed。charter-ietf-dawn-00-00 处于 Start Chartering/Rechartering (Internal Steering Group/IAB Review)。

这份提案已经相当具体。它描述如何发现 AI 代理及资源，列出可能采用的 DNS、mDNS 等机制，划定本地、组织内部与组织之间的场景，并把大规模能力传输、全网代理索引、稳定标识符以及若干信任管理任务排除在初始范围之外。它还写有拟任主席、交付物和目标日期。

IETF 126 的 DAWN 议程把那次会议明确写成“Working Group Forming BoF”，并为拟议章程与工作组范围讨论预留 55 分钟。BoF 证明问题已经获得了可组织的关注，也证明参与者正在检验范围；它没有把“准备建立工作组”自动变成“工作组已经成立”。

具体是审议能够成立的前提，不是授权已经成立的证据。章程表决页把问题限定得很清楚：这份章程是否已经准备好进入外部审议？记录中有一个 Yes、一个 BLOCK，其余列名成员没有表态；摘要说，在阻挡意见解决后，已有足够位置通过这一关。

提出 BLOCK 的意见并不反对研究方向，而是要求澄清发现动作由什么触发、不同运营模型是否需要不同方案、跨组织场景的信任边界以及是否应预设单一协议。这是一份范围审查意见。它不是最终技术否定，也不是某个人可以永久阻止工作的证明。

同理，一个 Yes 只回答当前问题。把“可以送外审”改写成“工作组获批”，就等于删掉表决对象后放大决定。会议参与、BoF、邮件列表收敛和拟任主席的投入都能提供专业知识与可行性证据；它们不能自行代替 IESG 的最终建组决定。

DAWN 在 8 月 27 日之后可能推进、修订或停止。文章不预测结果。它只坚持按日期保存每一步的权威：将来的批准可以从那一刻向前生效，不能倒过来把准备阶段变成已获授权的工作组行为。

NETCONF：旧章程不会因新提案出现而失效

NETCONF 的起点不同。工作组页面把它标为 Active。它已有围绕 NETCONF、RESTCONF、YANG、遥测与网络管理的正式工作空间。

章程页面展示了 8 月 12 日更新的 20-02，同样处于内部审议。页面同时给出关键限定：以下内容是重订章程提案，当前批准的章程是第 20 版。

单独保存的第 20 版让旧文本在审议期间仍可核验。NETCONF 表决页问的同样只是新文本是否准备好进入外部审议；记录中的剩余 BLOCK 指向缺少里程碑，而其他早先的阻挡意见已转为无异议。这是修改提案的证据，不是新版已经生效的证据。

这句话避免把三个对象揉成一个。NETCONF 工作组是正在运行的制度容器；第 20 版是现行范围；20-02 是请求改变范围的文本。审阅新文本并不暂停旧文本的效力，也不让新增任务提前获得普通工作组任务的地位。

如果提案被退回修改，真正可能获批的是后来的版本；如果提案撤回，第 20 版继续有效；如果 IESG 批准，则应在决定和公告所标明的时点，清楚记录新版取代旧版。任何一种结果都不需要假装 20-02 一发布就已生效。

提前覆盖旧章程会改变举证责任。本来应由扩权者解释为何新任务属于这个组；一旦新范围被当作既成事实，审阅者反而要解释为何“收回”参与者已经依赖的权限。程序从审查申请，滑成批准沉没成本。

因此，“章程待定”不是足够的状态。记录必须先回答这是初始建组还是重订。前者在请求创造容器，后者在请求修改容器。只有这个动作类型，才能说明等待期间究竟是没有章程，还是旧章程继续有效。

RFC 2418 所给的是有限工作契约

截至观察日，已发布的基础仍是 RFC 2418，即 BCP 25 的组成部分。它把工作组描述为 IETF 研发规范与指南的主要机制，通常围绕具体问题与交付物建立，并在任务完成后结束或重新界定。

RFC 2418 规定，章程主要由拟任主席与相关区域主管协商，IESG 在 IAB 提供意见后作最终批准。文本把章程称为 IETF 与工作组之间、完成一组任务的契约，并要求列明行政信息、方向、目标、路径与里程碑。

这里的“契约”是制度性边界，不是条约，也不是全球网络对工作组作出的政治委托，更不是带有损害赔偿的普通商业合同。它的作用是把集体注意力、程序管理与任务范围结合起来：这些问题可以在这个容器内进入公开、可复核的技术工作。

范围因此具有操作意义。RFC 2418 允许主席在兼顾开放与进度时推迟章程范围之外的输入；当任务完成或基础假设变化，区域主管可以与工作组协商重订章程、更换主席或解散工作组。专家聚集不会自动把有限权限扩成一般权限。

边界也保护外部主体。相邻组可以判断重叠，其他标准组织可以判断是否需要联络，潜在参与者可以决定是否投入，IESG 可以检验 IETF 是否真的适合介入、是否存在足够多的独立贡献者，以及提案是否只是请求 IETF 为外部已经定型的技术“背书”。

章程并不预先决定技术答案。它批准审问题的场所，而不是批准某个答案。把“可以研究”写成“方案已经正确”，会让工作组尚未开始就失去粗略共识与运行代码应有的检验作用。

审议提供证据，IESG 承担决定

RFC 3710把角色分开。建组倡议可来自社群，也可来自区域主管；区域主管与有关社群协商章程，IESG 与 IAB 参与审阅，拟议章程在最终决定前向更广泛社群公告；最终是否建立工作组，由 IESG 决定。

每一层都重要，但没有一层拥有全部权限。拟任主席把问题变成可执行计划；参与者证明专业能力、兴趣与异议；IAB 检查架构影响；其他标准组织指出重叠；公众审议揭示隐私、安全、运营与范围后果；区域主管协调这些界面；IESG 对制度容器作决定。

说“参与不是授权”不等于说参与无用。没有审议的决定会缺少事实基础，也难以取得技术信任。审议可以迫使决定者回答一个关键异议，可以缩窄任务，也可以证明工作组尚不成熟。它的正当性在于提供证据和可追责记录，而不是假装每位参与者都代表所有受影响者。

当重要工作落在现有章程之外时，RFC 3710 也没有要求无所作为。区域主管可以推动重订、放入其他工作组、安排组外工作或建立新组。制度提供了行动路径，却不允许用习惯替代选路决定。

这正是“利益相关者”与“授权主体”的差别。前者会受结果影响，也可能拥有最好的知识；后者是程序明确指定可以作出某项决定的人或机构。多方参与只有在不抹掉这条线时，才不会把出席人数包装成不存在的委托。

重订章程需要一张交接凭证

RFC 2418 要求实质性重订遵循初始建组程序。IESG 可以批准、要求修改——包括继续沿用旧章程——或拒绝。既然“继续用旧版”是一个真实结果，提案就不可能在审议开始时已经替代旧版。

RFC 6292是一份关于章程工具需求的 Informational RFC，不是 BCP 25 的替代品，但其状态模型很有解释力：初始路径在批准后才进入 WG exists；重订路径在新文本经过各级审议时仍保留工作组存在的事实。界面名称可以演变，对象分离不应消失。

一张可靠交接凭证应记录：新版标识与文本指纹、被替代旧版、IESG 决定与理由、决定日期、秘书处公告和生效时间。它向前改变权限，却不把新版范围倒写进此前历史。

撤回或失败也应成为正常可表达结果。被修改的提案仍能说明某条边界为何出现；被放弃的文字仍能说明哪些任务未获授权。保留它们不是让无效文本暗中生效，而是让后来者不把曾经被讨论误说成曾经被批准。

现行章程记录应包含什么

身份层至少保存工作组名称与缩写、动作类型 INITIAL_CHARTER 或 RECHARTER、工作组状态、提案标识、版本与精确文本指纹；另一个独立字段保存当前批准章程，初始提案则明确为空。

范围层保存增加、删除与保留的任务，交付物，明确排除项，里程碑政策，相邻工作组与外部协调对象。审议层保存负责区域主管、拟任或现任主席、内部审议起点、表决问题、所有立场、BLOCK 与解除条件、IAB 意见状态、外部公告、审议窗口、接收方及重要异议的处理。

决定层保存 IESG 最终处置、公开理由、日期、秘书处公告、生效时点、被替代章程，以及批准、继续旧版、退回修改、撤回或解散等结果。

每张获批章程还应带着两句否定性说明：它不证明具体文件已有共识；它不要求任何外部主体实施或部署。否定信息不是削弱章程，而是防止后来读者把有限权威膨胀成它从未声称的命令。

2418bis 仍是一份工作中的提案

draft-ietf-procon-2418bis-04发布于 2026 年 8 月 17 日。截至 27 日，它是 PROCON 的活跃工作组 Internet-Draft，IESG 状态为 I-D Exists，没有文档 shepherd、负责区域主管或 telechat 日期。页眉说它将在“获批时”废止 RFC 2418 和 RFC 3934；这个条件不能被删掉。

草案正文更直接地把章程写成范围承诺，并把里程碑设计为可选。它也明确说：工作组采纳一份 Internet-Draft，只表示把它作为工作项目基础，不表示其内容已形成共识。工作组 Last Call、提交 IESG、IESG 审阅与 RFC 发表仍是后续环节。

PROCON 章程本身也展示范围边界：它授权合并 RFC 2026 与 RFC 2418 的更新链，只允许处理列明的额外程序问题；其他事项需要重订。可这并不让其工作草案提前成为 BCP。

完整阶梯是：章程授权问题空间，采纳选择工作底稿，共识确认技术结果，IESG 审阅推进，RFC 出版固定文献身份；流与类别还决定它是否是标准。RFC 9281把这些参与实体分开，RFC 3935则提醒 IETF 不以强制全网采用为使命。

运营者的部署决定仍需另一个责任人、选定版本、测试证据、上线范围、回退方案与运行结果。章程最有力量的地方，恰恰是它只在自己的范围内有力量。

来源

  1. IETF Datatracker：章程制定与重订队列
  2. IETF Datatracker：DAWN 拟议工作组
  3. IETF Datatracker：DAWN 章程表决
  4. IETF Datatracker：DAWN 章程历史
  5. IETF Datatracker：IETF 126 DAWN BoF 议程
  6. IETF Datatracker：NETCONF 重订章程提案
  7. IETF Datatracker：NETCONF 已批准第 20 版章程
  8. IETF Datatracker：活跃的 NETCONF 工作组
  9. IETF Datatracker：NETCONF 章程表决
  10. RFC 2418：IETF 工作组指南与程序
  11. RFC 3710：IESG 章程
  12. RFC 6292：工作组章程工具需求
  13. IETF Datatracker：draft-ietf-procon-2418bis 状态
  14. IETF Datatracker：draft-ietf-procon-2418bis 正文
  15. IETF Datatracker：PROCON 工作组章程
  16. RFC 3935：IETF 使命声明
  17. RFC 9281：IETF 标准流程中的实体