摘要

  • 私有候选配置草案第 10 版为每个 NETCONF 会话提供独立工作区，并在运行配置变化后以原子方式执行 update。每次提交都隐式采用 revert-on-conflict，未解决的冲突会让提交失败，而不是暗中选出赢家。
  • 后续选择会明确制造损失：prefer-candidate 保留私有值，使它能在下一次提交时覆盖运行值；prefer-running 则从私有候选中抹去冲突编辑。NACM 权限、身份认证和能力通告都不能说明本次选择为什么获得组织授权。
  • 运营者需要一份提交授权书，把分支基点、冲突集合、所选模式、被覆盖或丢弃的值、责任人、批准范围、验证、确认提交条件和回退目标固定在一起。这是 Daniel Kade 的治理建议，不是 IETF 要求。

分开工作，仍会在合并处相遇

RFC 6241 的共享候选配置允许客户端先准备完整变更，再一次性激活。但“共享”意味着其他会话也能改动同一工作区。一个客户端最终提交的内容，可能夹带另一个客户端留下且自己并未察觉的编辑。锁可以减少这种事故，却会阻塞并行工作。RFC 5717 的局部锁也不能保证一次提交只含单个客户端的改动，更无法化解对同一配置树的并发编辑，而且操作者还必须理解模型依赖。

draft-ietf-netconf-privcand-10 正面处理了这个问题。它在 2026 年 8 月 24 日发布，目前是 NETCONF 工作组进入 Working Group Last Call 的有效 Internet-Draft，目标为 Proposed Standard；它还不是 RFC，也不能被写成已经部署的事实。

NETCONF 双方协商相应能力后，私有模式覆盖整个会话。首个相关操作从当前 running 复制出会话专属候选配置，其他 NETCONF 配置会话看不到也不能访问其中编辑。会话正常关闭或意外断开时，私有候选及未提交变更一并销毁。

这项机制真正解决了一个治理事故：甲不再会无意替乙提交尚未完成的工作。它也让并发准备不必以全局锁为默认代价。可是生产状态不会因为分支私有就停住。只要 running 在分支存续期间变化，问题就从“谁写了这些内容”转成“重新相遇时谁应当保留自己的值”。

私有空间证明编辑归属，并不授予服务优先权。

冲突不只是值不同，而是起点改变

草案定义的 update 会以最新 running 替换私有候选的旧基点，再重放客户端的变更。操作具有原子性，不应留下半套合并结果。

它对冲突的判断包含意图因素：准备期间，running 与私有候选都改动了同一个配置节点，而且如果客户端一开始看到新的起点，其行动可能不同。值、存在性、用户排序、presence container、leaf-list、leaf 与 YANG 元数据都可能形成冲突。服务器还能增加本地检查，并利用事务标识辅助判断。

冲突在节点上以内置 in conflict 状态标记，具体标记机制不在草案范围内，也不会自动向所有祖先节点传播。服务器应通过 XPath 和相关值报告位置，让客户端重新评估自己的意图。

这套语义比文本差异更接近真实配置管理，却也显露边界。设备知道哪一个节点重叠，却不知道运行值是否来自事故处置，不知道私有分支是否对应已批准迁移，也不知道一个叶节点是否牵动更大的共享服务。两个主体都可能通过认证并拥有写权限，但它们的临时任务范围仍可能互相冲突。

服务器能够证明“存在分歧”，不能凭配置树推导“谁有最终决定权”。

三种模式分配的是三种损失

revert-on-conflict 是必须支持的默认模式。只要有任何冲突，更新就失败且不执行合并。提交无论系统自动更新默认值如何，都先隐式使用这一模式。失败后，客户端必须修改、放弃，或明确选择另一种模式执行手动更新，再尝试提交。暂停并非效率缺陷；它为审议保留了一个尚未造成损失的时刻。

prefer-candidate 在冲突节点保留私有值，同时吸收 running 中不冲突的变化。以后提交时，私有值将覆盖运行配置。被牺牲的是分支创建后进入生产的意图。

prefer-running 把当前运行值写回私有候选，覆盖其中冲突编辑，同时保留其余不冲突工作。被牺牲的是分支作者准备的那部分意图。

“候选”不等于业务上更新、更重要或审查更充分；“运行”也不等于下一阶段仍然正确。运行值可能只是紧急临时措施，私有分支可能是早已批准的维护；反过来也完全可能。数据存储位置描述技术状态，不提供制度等级。

草案还允许服务器在 running 变化后触发自动更新，并为此选择非默认解决模式。非默认系统选择必须通告；如果并非三种模式全都支持，也要通告支持集合。通告让行为可发现，却不记录为何某类设备采用该政策、谁承担被覆盖结果、授权何时到期。

因此，最终提交记录可能看起来毫无冲突，因为真正的取舍早在一次自动 update 中完成。提交日志能回答谁激活了结果，却不能回答谁授权系统提前删除其中一个意图。

NETCONF 会话与 RESTCONF 请求不是同一时间边界

NETCONF 客户端和服务器会为整个会话协商私有候选能力。如果客户端提出而服务器不支持，服务器可能为兼容旧实现而忽略，也可能关闭会话；草案更建议新实现选择关闭。因此，客户端“想用私有模式”不能证明实际获得了隔离，运营侧必须检查协商结果。

RESTCONF 没有客户端能力通告。服务器一旦通告 private-candidate 支持，对数据资源的写请求会使用请求专属候选配置并自动提交，以维持不知情客户端所期待的即时语义。这不是一个跨多次操作长期存在的 NETCONF 式会话工作区。

治理控制必须适应真实时钟。NETCONF 分支可能跨越生产变化、权限更新和维护窗口，原有批准会过期。RESTCONF 将准备和激活压缩到单次请求，无法原样插入“编辑后、提交前”的人工环节。共同名称不意味着共同审批模型。

协议权限不等于本次变更授权

RFC 8341 的 NACM 可以分别限制用户对特定内容的读、写和执行。草案明确提醒 update 是敏感操作，未授权访问可能造成非预期候选变更。相互认证与安全传输当然必不可少。

但最棘手的冲突常发生在两名“有权限”的参与者之间。平台账户或许可以写接口子树，却只获准轮换地址，未获准撤销事故团队的关闭措施。资深工程师权限很宽，也未必能越过服务所有者决定共享依赖。自动化主体仍在 NACM 名单里，其维护窗口却可能已经结束。

访问控制回答“这个身份能否调用该操作并触碰该内容”。变更治理回答“这个工作流此刻能否让这个值压过另一个有效意图”。把前一个答案当作后一个答案，会把长期凭据变成永久表决权。

比较同样只是证据。草案扩展 RFC 9144，在服务器支持时，可将私有候选与 running、创建点或上次更新点比较。差异和时间关系因此更清楚，却仍不能判断服务安全性、依赖覆盖是否完整，或决定者是否拥有当前授权。

提交授权书应当保留什么

不必再造一个协议数据存储。缺少的是一次性、会过期的提交授权书。

首先记录设备、datastore、NETCONF 会话或 RESTCONF 请求、认证主体和自动化所有者；固定创建点、上次更新点及稳定的运行修订标识。没有这些基点，事后差异没有可靠起点。

随后保存精确候选增量和服务器报告的完整冲突集合。本地政策还应补充祖先与服务依赖，因为逐节点标记可能低估影响。授权书列出服务器通告的默认值和支持模式，说明更新是自动还是显式，并记录实际所选模式。

损失必须写明。若为 prefer-candidate，列出以后会被覆盖的运行值；若为 prefer-running，列出已从私有候选删除的编辑；若为 revert-on-conflict，保留未解决集合和下一项获准行动，而不是把失败当作噪声。

NACM 政策版本用于证明权限环境，却不能代替批准。具名的人或自动化决策者须给出理由、服务范围、维护窗口、爆炸半径上限和有效期。比较结果、配置验证和代表性服务检查与决定绑定。

最后写清确认提交、超时、适用的持久化标识、健康观察信号和精确回退目标。提交完成后保存新的运行状态指纹。任何前提变化——新的 running、过期窗口、政策变更或观察者缺失——都会让授权书失效并要求重新判断。

提交授权书是 Daniel Kade 的场外治理建议，不是 IETF 规范、NETCONF RPC 或 YANG 节点。它的作用是在会话和冲突标记消失以后，仍能回答为什么一个合法意图有权消灭另一个。

能回退，不代表起初选得正当

确认提交是可靠的安全装置。私有候选执行 confirmed commit 时，若客户端会话断开，草案保留立即回退 running 并丢弃拟议变更的行为。这能约束失联带来的风险。

但可恢复性回答的是“失败后能否返回”，不是“最初的胜者是否有权胜出”。一个越权选择也可能有完美回退；一次合法紧急行动也可能缺乏可接受回退，后者应当阻止执行，而不是反向制造授权。

discard-changes 也不能随意解释为“回到当前生产”。它把私有候选恢复到创建点或上次更新点，以较新者为准；这个状态未必等于当下 running。

隔离保存作者边界，冲突检测保存分歧，回退保存归路。要保存胜者的制度依据，只能在取舍发生时把授权、证据与损失一并留下。

来源