Summary

  • 11 月 2 日的 YANG-Push v2 第 01 版规定：按变化推送时，update 里没带上的子节点保留旧值；要删掉它，发送方必须给出指向该节点的 delete。
  • 周期采集和重新同步只发送更新，不发送删除。接收方要等整份订阅范围内的快照结束，才能根据缺项推断节点已经消失。

采集器的台账里有一个父节点和三个子节点，新消息只带来其中两个。第三个去哪了？答案写在消息类型里。若这是局部变更，它仍在台账中；若这是完整快照的最后一片，它可能已经离开。把差别交给界面猜，界面就会成为一位没有记录的编辑。IETF 第 01 版原文把接收规则写进事件结构；第 00 版还没有新增的 7.2.1 节，未对 presence container 和 leaf-list 的处理给出这组细则。IETF 文档记录显示它是 NETCONF 工作组的活跃草案。

一次变更通知含有 updates 列表。每条记录指明目标路径，并在 update 与 delete 两种操作中选一。已经给出的叶节点值取代旧值；容器与有键列表递归更新。局部载荷没提到的子节点保持原样。若确实要删，发送方必须另给一条指向子节点路径的 delete。它可以与父节点更新放进同一通知，但同一个目标在一份通知里不能出现两次，不能既更新又删除。

leaf-list 的规则更有意思。只要列表删改后仍非空，发送方就要在列表或其祖先的更新中交出当前完整且有序的序列；接收方用它替换旧序列。协议不允许单独对某一个列表成员发更新或删除。最后一个成员离开时，发送方得显式删除整个列表或其祖先。若列表只是没有出现在较大子树的局部更新里，旧列表照样留着。presence container 即便为空也代表存在；按变化推送时要使它消失，同样需要显式删除。

周期快照反过来处理缺项。采集可能拆成几条通知，消息中不使用 delete。接收方只有看到 complete 或 update-complete，才把整份快照里缺席的订阅数据视为已删除。在结束标记到来前，那个节点可能还在下一片里。RFC 8641给出此前的 YANG-Push 基础，RFC 8639定义订阅通知的框架；新草案把接收方更新台账时该做什么说得更具体。

官方文件没有给出一条具名设备到采集器的完整轨迹，能同时展示 leaf-list 变动、显式删除、分段快照和处理前后台账。拿到这条轨迹，就能检验真实解码器是否遵守上述规则。