摘要

  • draft-ietf-nmop-network-incident-yang-14 把网络事件实例的 raised、updated、cleared 与操作人员的 acknowledged、diagnosed、resolved 分成两条生命周期，并允许一次 RPC 指向多个事件。
  • 成功结果随后通过独立异步通知上报。8 月 31 日的 YANG Doctors 审查明确指出，模型没有办法把结果通知与产生它的具体 RPC 对应起来。
  • 运营方应保留一份命令到清除状态回执，连接请求、权限、目标集合、动作、通知、工单映射与服务验证。这是编辑提出的控制办法，不是 IETF 草案要求。

状态知道“发生了什么”，却不知道“因何发生”

第 14 版草案试图把不同层次的告警、性能指标和异常归并为可处置的网络事件。它给事件客户端三类操作：确认、诊断、处置。这样做能减少重复工单，也能让跨层故障具有统一的观察对象。

问题出在异步边界。incident-resolve 接受一组 incident-no。服务器若成功处置某个事件，之后会另发通知，把该事件的状态改为 cleared。草案明确把“具体如何处置”留在范围之外。

通知携带事件编号，因此接收者知道是哪条事件记录发生变化。但事件编号不是本次调用的编号。若两个控制器先后发出操作，若服务器自己完成修复，若监测对象自行恢复，或者拓扑刷新改变了事件的归并方式，合法的 cleared 通知也未必能证明是哪一次命令产生了它。

这不是词语问题。它决定了“状态已经变绿”能否升级为“某个获准动作已经成功”的证据。

两条生命周期本来就在提醒我们不要合并

草案有一个值得保留的设计：网络状态与人的工作状态不是一条线。事件实例会经历 raised、updated、cleared；操作侧会经历 acknowledged、diagnosed、resolved。

故障信号消失时，调查可能尚未完成。值班人员认为处置完毕时，监测仍可能观察到影响。绕行可以恢复业务而不消除根因。自动修复也可能在人工批准之前生效。两个状态机让这些差异有地方落笔，而不是强迫“清除”和“解决”互为同义词。

草案又要求把事件模型接入 OSS 工单，并建议建立确定性的状态翻译层，避免网络侧已经关闭而工单仍开放，或工单已解决而网络事件仍存在的“分裂视图”。这是必要的工程约束。

但确定性翻译只保证同样输入总得到同样输出，不保证输入背后的因果关系成立。如果系统总把 cleared 翻译为 Resolved，两个界面会迅速一致，也可能迅速共享同一个未经证明的结论。

正式审查点名了缺失的连接线

8 月 31 日的早期 YANG Doctors 审查给出 Almost Ready 结论，同时指出：RPC 的结果通过通知传递，却没有办法判断哪条通知来自哪次 RPC。审查还追问，诊断客户端如何识别某次诊断调用对应的通知，并要求澄清通知来源与去向、事件标识、空目标列表、错误结构和双状态机。

这份审查不是最终否决。它特别说明作者和文档负责人希望下一份尚未发布的版本再接受审查。因而，可靠写法只能说已发布接口存在一个公开提出的关联问题，不能断言后续文本没有解决，更不能杜撰某家运营商因此误关事件。

IETF 126 的 NMOP 会议纪要也记录了围绕列表键、事件编号和事件 ID 的讨论。这说明标识设计确实处于审视之中，却不等于会议已经给出最终答案。

鉴权解决入口，关联解决后果

该模型预期通过安全的 NETCONF 或 RESTCONF 使用，并要求双向认证。NACM 可以限制某个用户能够读取的数据和调用的操作。处置失败还可返回根因未解决、权限不足、超时或资源不可用等原因。

这些机制都不可缺少。双向认证确认管理对端，NACM 表明某个主体能否调用 incident-resolve，错误结构说明同步边界为何没有完成。它们却不自动回答一条稍后到达的 cleared 通知究竟属于哪次调用。

授权、请求受理、实际执行、状态观察和业务恢复是五个不同事实。用一个事件编号把它们全都概括成“系统已经处置”，相当于让标识符承担它从未声明的因果证明功能。

草案还警告，事件数据可能暴露网络的受损状态，大量恶意或错误的诊断、处置操作会消耗资源。因此，补充回执不能成为公开拓扑和动作细节的借口。完整记录应留在受控证据域，公开层只需要动作类别、时间、授权结果、相关性质量和恢复状态。

批量操作让模糊归因产生分配后果

一次 RPC 可以包含多个事件编号，这有利于处理共同根因，却会放大部分成功的解释成本。假设请求包含 71、72、73：71 因预定动作清除；72 由本地保护机制恢复；73 因新拓扑数据而重新归并。三者后来都可能不再报警，但只有第一项能归因于原命令。

若系统把三项都计入自动化成功率，控制器获得了并不属于它的功劳；若值班人员曾因业务影响过大而拒绝直接操作，这个谨慎决定也会被抹去。草案已经承认处置可能影响运行中的服务，客户端可以在影响不可忽略时选择不执行。是否执行、选择何种替代方案，本身就是治理决定。

另一项边界来自数据新鲜度。草案说明，跨层拓扑发现若中断或过时，会直接降低根因和服务影响分析的准确度。事件状态的变化有时反映“我们现在如何理解网络”，不一定反映“刚才的命令修好了网络”。

零错误不是端到端证明

Datatracker 页面显示，第 14 版是 NMOP 工作组的活跃 Internet-Draft，拟走标准轨道。工作组最后征求意见于 9 月 3 日结束；冻结证据时页面仍是 In WG Last Call，没有负责 AD 和 IESG 电话会议日期。9 月 7 日的 YANG 验证为零错误、零警告。

这证明模块通过了重要的结构检查，不证明它已经成为 RFC、形成最终共识、部署运行或实现跨系统关联。语法能否编译与一次获准命令能否被追到业务恢复，是不同层级的证据。

真正有说服力的运行测试可以同时发出两次目标重叠、权限不同的处置请求，再制造一次自主恢复和一次延迟通知。随后要求系统逐条说明：哪个状态源自哪个请求，哪个独立发生，哪个无法判断。允许回答“未知”，比强行让所有绿色结果都有一个成功主人更可靠。

在协议之外保存命令到结果的回执

一份命令到清除状态回执不必修改 YANG 模型。请求发出前，它为本次调用生成唯一身份，冻结目标事件及其版本，记录认证主体、角色、NACM 与变更政策版本、预期动作、业务影响、批准人以及因风险选择的替代方案。

执行阶段记录 RPC 的受理或失败、逐事件错误、服务器与模型版本、拆分、重试和回退。通知到达后，记录事件修订与发生时间，并明确标为“由本次调用产生”“独立变化”或“关联未知”。

关闭阶段再连接 OSS 的翻译规则、工单状态和操作者、服务级验证、残余根因或绕行、回滚责任人与更正历史。敏感命令、客户和拓扑不必公开，但在权限域中必须可重建。

The Policy Mirror要求找到真正写入权力的位置：NACM 写权限，RPC 写意图，事件库写观察，工单写组织结论，服务测试写外部现实。Running-Code Primacy要求这些记录在执行中相遇。Reality, Not Advocacy则约束结论：草案提供了有价值的事件语言；运营方仍需证明，自己依赖的绿色状态究竟由什么产生。

来源