摘要

  • BBF 说 WT-477i2 的 YANG 模型依赖 IETF BGP 模型，并询问目标发布日期。这证明了依赖关系和信息请求，不构成 IETF 的发布日期承诺。
  • IDR 在 8 月 1 日的回应说，相关草案处于 Working Group Last Call；在进入 RFC Editor 发布队列前，还需经过 Area Director 审查、全 IETF Last Call 和 IESG 审查。
  • 负责 Routing 区域的 Area Director 在 8 月 21 日明确写道，WGLC 仍然开放；沉默不能当作草案可发布的证据，判断共识需要积极支持和完成的审查。
  • 第 21 版页面仍把文档列为 Internet-Draft，WG 状态为 “Waiting for Implementation”，IESG 状态为 “I-D Exists”，没有 telechat 日期。
  • 需要的不是猜测日期，而是一张按版本连接 BBF 依赖、WGLC、共识、后续 IETF/IESG 状态、队列和 RFC 的状态收据。

BBF 说的是自己的依赖，不是 IETF 的承诺

2025 年 12 月的 BBF 后续联络声明 有清楚的边界。它说 WT-477i2 中的 YANG 模型完全依赖当时 draft-ietf-idr-bgp-model-18 所列的 ietf-bgp 模块及其关联模块；它附上自己的工作版本，说明该工作接近完成，并请 IETF 提供 BGP 模型的目标发布日期信息。

这是一项可用的公开事实。它说明哪份 BBF 文档引用哪一版本 IETF 草案，以及 BBF 想知道什么。它没有说明 IDR 接受了任何日期，没有预留 RFC 编号，也没有证明这套模型已被设备、运营商或 BBF 的成品采用。外部文档的依赖可以非常紧密，但不会把上游草案的审查权转给依赖方。

这种区分并不反对跨机构协作。相反，RFC 2418 要求工作组在有重叠时了解其他标准机构的相关工作，并保持恰当的 liaison。这样做能够避免重复造出不兼容的技术词汇；它不意味着外部机构可以替 IETF 宣布审查结束。

IDR 回答的是程序状态，而不是交付日期

IDR 的回应 说 draft-ietf-idr-bgp-model 当时进入 Working Group Last Call。它随后逐项列出之后的链条：Area Director review、IETF-wide Last Call、全面的 IESG review，之后才可能进入 RFC Editor 的 publication queue。回应还建议感兴趣的 BBF 人员加入 IDR 邮件列表，提供技术反馈、参与讨论并明确表达支持。

这条参与路径很重要，但它的作用不能被夸大。BBF 的技术人员可以帮助发现问题、说明外部依赖，或者提交支持意见；这些都是审查中的材料，不是自动形成的共识，不是 IESG 的决定，也不是发布时间表。IDR 没有因收到请求而给出日期，恰恰保留了审查与日历之间的边界。

8 月 21 日的邮件记录使这个边界更具体。Area Director 写明 v21 已发布，但 WGLC 仍继续；由于文档很大、又经历会议周和北半球暑期，他将寻找积极支持和已经完成的审查来判断共识，不能把沉默理解为准备发表。邮件还说明 IDR 的三位 chairs 是共同作者，因此由 Area Director 为这次 WGLC 进行共识判断，并有指定的 shepherd 协助审查。

这里展示的不是程序拖延，而是可归属的角色分工。草案版本、作者身份、审查意见、沉默、共识判断，各自回答不同的问题。没有任何一项可以代替另一项。

草案页面没有把未来 RFC 提前变成现在

第 21 版的 Datatracker 记录 写明它是 2026 年 8 月 14 日的 Internet-Draft，并提醒 Internet-Drafts 是可更新、替换或废止的工作文件，只适合被引用为 work in progress。页面所列的 “Waiting for Implementation”、“I-D Exists” 和没有 telechat，并不是 RFC Editor 队列，更不是 RFC 已发布。

IDR charter 将为 IPv4 和 IPv6 开发、维护 BGP 作为工作组的优先目标。它定义的是工作范围，不是每份草案的完成证明。RFC 2026 所述的标准轨道要求 IESG 的特定行动才能进入 Proposed Standard；后续经验仍可能令文档变化或撤回。

因此，应保留至少五类记录：BBF 文档及其依赖的 IETF 版本；WGLC 的开启、延续或关闭；已完成的审查与共识处置；后续的 Area Director、IETF 和 IESG 状态；RFC Editor 队列以及最终 RFC。一条依赖说明不能填满这些栏位。一份未来 RFC 也不能单独证明 WT-477i2 的互操作性、厂商支持或运营商部署。

一张小收据足以阻止状态借用

建议的公开收据只需连结：WT-477i2 版本、IETF 草案版本、请求日期和内容、WGLC 状态、审查和共识处置、之后的 IETF/IESG 状态、队列记录、最终 RFC。每行还应写清“它不证明什么”：依赖不是承诺；开放 WGLC 不是拒绝，也不是日期预测；队列不是出版；RFC 不是运行采用。

这些来源没有提供实现测试、运营商使用、供应商支持、商业影响或延误责任的证据，也不证明双方存在争议、否决或失职。它们只严谨地说明：审查当时仍是开放状态，BBF 所询问的日期没有被转化为标准决定。

来源