摘要

  • 第 10 版草案提出会话专属候选数据存储、原子化 update、以节点重叠为核心的冲突检测、三种解决模式，以及对创建点或最后更新点的可选比较。
  • 这些机制能把编辑分开，却不能独自证明基线持续新鲜、所有并发变化均可见、自动解决符合操作者意图、提交后的配置已实际应用，或客户与业务结果成立。

私有分支保管编辑，却不能冻结时间

draft-ietf-netconf-privcand-10 要避免的错误很具体：多个客户端共享候选配置时，一个客户端可能无意间把另一个客户端尚未完成的修改一起提交。草案让第一次需要候选存储的操作复制当时的 running，此后由创建它的 NETCONF 会话或 RESTCONF 客户端单独编辑。

这种隔离有价值，但复制发生后，running 仍会被其他会话改变。草案明确承认，长时间打开的私有候选可能与运行配置严重失步。只有显式 update、服务器宣告的自动更新，或提交前的隐式更新，才会重新接触当前基线。

Datatracker 页面显示，第 10 版是 NETCONF 工作组处于 Working Group Last Call 的活跃 Internet-Draft，目标为 Proposed Standard；历史记录将本版日期列为 2026 年 8 月 24 日。它不是 RFC，也不是任何设备已经实现或部署的证明。

第一份回执：分支起于哪一个基线

仅记录“候选已创建”还不够。基线回执应包含设备身份、running 的精确修订号或内容摘要、YANG 库与模式状态、默认值处理、创建时间、最后一次手动或自动更新，以及服务器是否宣告 trigger=all-updates。

因为 creation-point、last-update 和当前 running 回答的是三个不同问题。discard-changes 也只回到创建或最近更新后的状态；草案特别指出，该状态可能仍不等于当前运行配置。

第二份回执：谁真正拥有这些编辑

NETCONF 会话只有在客户端与服务器双方宣告新能力后，才进入私有候选模式。若服务器不支持，草案允许它忽略客户端能力并继续普通会话，或直接关闭会话。因此，看到服务器支持这项能力，并不能证明某个具体会话已经获得隔离。

归属回执要把认证后的会话、用户、协商能力、候选生命周期、每次编辑与一个不可变的变更集摘要绑定起来。草案只约束 NETCONF/RESTCONF 表面，并把设备经其他接口暴露候选的情况留在范围之外。“私有”不是覆盖所有管理通道的保证。

RFC 8040 下的 RESTCONF 没有客户端能力交换。草案要求宣告支持的服务器对数据资源编辑使用私有候选，并自动提交，以维持旧客户端对即时提交的预期。NETCONF 与 RESTCONF 的“私有”证据不能混用。

第三份回执：所谓“无差异”究竟比较了什么

草案扩展 RFC 9144，可把当前私有候选与 running、创建点或最后更新点比较，但参考点扩展是可选能力。RFC 9144 又允许子树或 XPath 过滤，并严格区分“过滤器没有命中、什么也没比较”与“确实比较后没有差异”。

可信的空结果必须同时保存源、目标、参考点、过滤器、all 参数、模式、默认值处理和可读节点集合。RFC 8341 对操作与内容分别执行访问控制；无权读取的节点可以被静默省略。对当前权限视图而言完全正确的空比较，仍可能不足以支持更广泛的变更决定。

第四份回执：并发检测覆盖到哪里

第 10 版主要把冲突定义为同一配置节点被重叠修改。值、存在性、按用户排序的列表顺序、presence container、leaf、leaf-list 与 YANG 元数据都可进入检测。服务器还可以添加检查，也可以考虑事务 ID。

这是清晰的最小规则，却不是全部语义冲突。两个客户端可以修改不同节点，合起来才造成容量越界、冗余消失、路由策略破坏或业务组合非法；这些变化不一定触发同节点冲突。并发回执必须列出所有写入者和提交窗口，并在协议检测之外验证跨节点不变量。

第五份回执：谁决定保留哪一边

手动 update 有三种模式：revert-on-conflict 遇到任一冲突就整体失败；prefer-candidate 保留候选侧冲突值，同时吸收运行侧非冲突变化；prefer-running 用运行侧值覆盖候选侧冲突编辑。

系统默认模式只在服务器自动更新私有候选时生效。若开启自动更新，客户端可能不知道自己的分支已经变化，之后的手动更新甚至只是空操作。算法按规则解决冲突，不等于操作者授权了结果。回执必须记录触发源、模式、冲突节点、前后值、被丢弃的意图与承担决定责任的人。

第六份回执：提交到底确认了什么

私有候选提交先执行使用 revert-on-conflict 的原子隐式更新；成功后才把候选复制到 running。若检测到冲突，提交必须失败。这个设计避免用绿色返回掩盖尚未解决的节点重叠。

但 RFC 6241 中的 <ok> 只表示协议操作没有产生错误。应保存消息 ID、候选摘要、隐式更新结果、冲突报告和新的运行修订号，而不能把它翻译成“设备行为正确”。confirmed commit 的定时器、持久令牌与回滚属于配置进入运行态后的另一条证据边界，BTW 已有专篇处理。

第七份回执：配置是否进入真实运行态

RFC 8342 把 running、intended 和 operational 分开。模板或转换可改变 intended；资源缺失会让 intended 中的配置无法应用；删除后也可能暂留运行痕迹。RFC 8526 提供访问这些 NMDA 数据存储的 NETCONF 操作，却不会把它们合成一个状态。

提交后应在明确时间、明确设备和稳定观察窗口中，把新的 running 修订与 intended、operational 分别比较，并记录资源或应用例外。候选没有冲突，仍可能落成部分无效的配置。

第八份回执：业务结果由谁观察

最后的观察者应独立于配置事务。先核验相关控制会话、接口、路由、队列、安全策略或转发行为，再验证受影响的客户、SLA 或业务总体，并保留回滚条件与残余风险。设备状态不自动等于流量行为，流量行为也不自动等于客户恢复。

私有候选的意义正在于它只缩小一种意外耦合，而不冒充整个结果。

来源与审查边界

草案要求安全传输、双向认证与敏感操作访问控制。针对第 06 版的历史 OPSDIR 早期审查提出参考点存档、数据存储定义与安全指南问题；同版 YANG Doctors 审查给出“Almost ready”。两者都不是对第 10 版的新审查结论。

协议背景还包括 RFC 6241、RFC 8040、RFC 8341、RFC 8342、RFC 8526 与 RFC 9144。这些材料定义协议、访问、数据存储与比较语义，没有记录某个命名部署。