摘要

  • 服务器接受带 <confirmed/> 的提交时，候选配置已经进入 running；确认窗口延迟的是“最终成立”，不是“开始执行”。窗口内没有完成确认，服务器便承担恢复提交前配置的义务。
  • 普通确认提交把命运绑定在发起会话上，会话提前终止就回退；持久确认提交则能跨越会话，由持有匹配 persist-id 的另一会话继续、确认或取消。
  • <ok>、YANG 校验、complete 通知和 running 一致分别只证明很窄的一层。startup 是否同步、intended 是否落实为 operational、数据包是否可达、多个设备是否共同恢复，都要另取证据。

真正危险的不是失败，而是过早宣布成功

一名工程师通过远程管理链路修改设备地址。他先在 candidate 中完成配置，再发送确认提交。服务器返回 <ok>，新地址随即进入 running。几秒后，原来的管理会话断开，新地址也无法建立连接。

普通提交会留下一个棘手问题：变更究竟落下去了没有，谁还能把它撤回？确认提交把答案提前放进服务器。若它是普通、非持久形式，发起会话在确认前终止，服务器必须恢复提交前配置；若计时器耗尽，同样恢复；若设备在确认前重启，也同样恢复。工程师不必重新穿过已经被自己切断的通道，才能发出回滚命令。

这项能力很实用，但它最容易被一句“提交成功”误读。服务器返回 <ok> 时，新配置不是停在门外等第二次批准。它已经进入 running，已经可能改变路由、接口、访问控制与管理路径。尚未最终成立的是它的存续权。协议同时保存了两个事实：变更已经执行；服务器仍有义务在指定条件下撤销它。

因此，确认提交不是无害的试运行，也不是网络版审批流。它是一种带回退义务的临时执行。只要把这三个词说清楚，后续的权限边界便不再神秘。

candidate、running 与确认窗口各管一件事

RFC 6241 定义了 NETCONF 的基本操作。设备声明 :candidate 后，客户端可以在候选数据存储中组合一份完整配置，而不立刻改变当前运行配置。普通 <commit> 把 candidate 复制到 running。依赖 :candidate 的 :confirmed-commit:1.1 则在这一复制完成后，加上一条有期限的恢复条件。

若请求没有指定 confirm-timeout，默认期限为 600 秒。后续普通确认提交可以结束这段临时状态；再次发送确认形式可以延长它，并按规则给出新的期限；<cancel-commit> 会终止流程并恢复之前的配置；超时也会触发恢复。

这几种动作不能都塞进“应用”一词里：

  • 校验回答候选配置是否满足当前模型约束；
  • 提交回答 candidate 是否已经成为 running；
  • 确认回答服务器是否不再因本次窗口而自动恢复；
  • 取消、超时、失联或重启回答何时必须恢复旧态；
  • 写入 startup 回答下次启动加载什么；
  • 观察 operational 回答设备当下真正采用了什么。

任何控制台若只给出一个绿色“Change succeeded”，都在把本来可区分的事实重新压扁。

RFC 6470 为确认提交通知规定了 start、extend、complete、cancel 和 timeout 等事件，开始与延长还可携带期限。这些事件能还原流程，比笼统的成功日志更有用。但通知不是决定本身。收集器可能离线，事件可能延迟，complete 也可能发生在硬件尚未完成应用之时。可靠审计必须把 RPC、用户、会话、候选配置指纹、旧 running 指纹、期限、后续事件与最终状态串在一起。

十分钟不是风险答案

默认 600 秒是互操作默认值，不是 IETF 替所有网络做出的风险评估。修改一条访问规则、重建一块线卡、调整大规模路由策略，所需观测时间完全不同。窗口过短，慢故障尚未显现便触发回退；窗口过长，有害状态可以存续更久，也给并发写入留下更大空间。

真正需要设计的是观测预算。什么时候开始计时——客户端发送 RPC、服务器接受 RPC，还是控制器收到 <ok>？哪些证据必须在窗口内出现——管理通道恢复、邻居稳定、路由安装、真实流量、业务探针？谁可以延长？延长多少次以后必须中止？

多设备变更尤其不能只显示一个倒计时。调用有先后，网络有延迟，每台服务器保存自己的计时原点和旧态。控制器屏幕上的统一“剩余八分钟”，可能掩盖第一台设备只剩两分钟。时钟一旦影响最终性，它本身就是权限与证据对象。

失去会话何时等于回退，何时什么也不代表

普通确认提交依附于发起它的 NETCONF 会话。会话在确认前终止，服务器必须恢复。这种设计把管理链路连续性变成一个信号：提出风险的人若无法继续留在现场，设备就撤销风险。

但自动化平台未必希望一个 TCP/SSH 会话掌握全部命运。发起任务的进程可能结束，检查任务可能在别处运行，事故处置人员也可能需要从新会话接手。持久形式为此引入 persist。发起方提供一个不透明值后，确认提交不再因原会话终止而自动回退。另一会话可在相应 RPC 中提供匹配的 persist-id，完成、延长或取消这段流程。

持久令牌搬运的是流程能力，不是人类身份。协议只比较两个不透明值是否相符，并不证明持有人是第二位审批者，不证明他读过变更，也不证明组织授权他作最终决定。同一个自动化服务完全可以创建令牌、发起提交，再换一条会话自行确认。技术上有两个会话，治理上仍只有一个权力中心。

令牌的保管也不能含糊。若它只存在发起进程内存中，进程故障后可能无人能接管仍在运行的临时状态；若它被原样散落在日志、工单与聊天中，审计材料反过来成了可用权限。可以保存经过保护的指纹做关联，把可用值留在受控保管链中。谁可读取、谁可使用、谁可紧急取消，必须单独回答。

回滚恢复的是旧状态，不是你脑中的反向补丁

人们常把回滚想成“只撤销我刚改的几行”。确认提交的恢复边界更接近提交前的配置状态。RFC 6241 明确提醒：若在确认窗口中又发生其他配置修改，后来恢复旧状态时，那些修改可能被改变或删除。

假设 A 在五分钟窗口中改变访问策略。两分钟后，B 通过另一个作业更新遥测配置。A 的会话随后终止。设备掌握的是 A 之前的恢复基线，而不是企业内部关于“B 与 A 无关”的知识。若没有更窄且经过验证的合并语义，B 可能随恢复一起消失。

锁因此成为回滚安全的一部分。NETCONF 全局锁可阻止其他会话修改被锁定的数据存储。RFC 5717 定义部分锁，允许缩小排他范围，同时揭示了一个重要冲突：running 上存在未完成的确认提交时，服务器必须拒绝新的部分锁，因为它可能需要恢复更广的 running 状态。

锁只证明其实际覆盖范围内的排他性。它不证明配置正确，不证明所有写入路径都服从它，也不证明 RESTCONF 或厂商内部作业共享同一锁语义。安全记录至少要保留锁的类型、范围、所有者、取得与释放原因、其他写入尝试，以及恢复前后指纹。没有这些，“我们支持回滚”只是一个功能名。

另一个协议可能替你做出最终决定

RFC 8040 描述 RESTCONF 与同址 NETCONF 服务器的概念数据存储关系。服务器使用 candidate 时，RESTCONF 编辑会自动把编辑后的 candidate 提交出去。

若此时存在普通、非持久的 NETCONF 确认提交，这次 RESTCONF 提交会充当确认提交。也就是说，RESTCONF 客户端哪怕只是来修改另一个对象，也可能关闭 NETCONF 操作者原本期待的回退窗口。组织架构里“NETCONF 团队”和“RESTCONF 团队”的分界，并不会自动出现在设备的数据存储里。

持久形式的结果不同。RESTCONF 没有位置提交 persist-id。若未完成流程要求该标识，RESTCONF 编辑必须以 HTTP 409 in-use 失败，不能暗中确认或覆盖。NETCONF 锁阻止相关数据存储时，也可能产生 409。此时 409 不是普通应用噪声，而是“最终决定权或写入排他权仍在别人手中”的信号。

startup 还展示了路径差异。RFC 8040 规定，同址服务器若支持 startup，成功的 RESTCONF 编辑会自动更新 startup。NETCONF 的普通 <commit> 本身却不证明 running 已经复制到 startup。相同意图通过不同协议写入，可能产生不同的重启证据。审计若只保存最终配置文本，便看不见这一差别。

SSH 身份、NACM 权限与 YANG 有效性是三道门

RFC 6242 规定 NETCONF over SSH。加密通道与对端认证是基础，却没有自动回答该用户能否调用 <commit>、能否改某个接口或能否读取确认通知。

RFC 8341 的 NACM 分别处理协议操作、数据节点与通知访问。一名已认证用户可以被拒绝某项 RPC；一项获准的操作也可能触及不允许修改的数据节点；恢复会话还可能获得实现特有的绕过能力。身份正确、操作获准、节点获准必须分别记录。

候选配置通过 YANG 校验，又只是下一层。RFC 7950 定义类型、结构、引用与约束。一个地址可以在模型上完全有效，却属于错误站点；一项策略可以满足所有引用，却切断重要流量。模式有效性证明声明内部一致，不证明业务意图正确。

RFC 8525 的 YANG Library 让客户端发现模块、feature、deviation、数据存储的模式关联，以及服务器特有的 content-id。验证证据应绑定这个精确状态。若准备与提交之间启用了一个 feature 或改变了 deviation，“同一个候选”可能已进入不同解释环境。

running 最终成立，设备仍可能没有照做

RFC 8342 的 NMDA 把 running、intended 与 operational 分开。running 保存当前完整配置。系统可能经过模板展开、无效节点移除、系统值注入等转换，形成 intended。operational 则显示观察时设备实际使用的配置和状态。

一段针对缺失资源的配置可以留在 running 与 intended 中，却不作为已应用配置出现在 operational。物理容量、内部依赖、异步流程或协议状态都可能让实际应用延迟或偏离。确认提交流程可以已经 complete，设备仍处于部分旧态、部分新态。

所以验证必须跟着变更对象走。接口变更要看接口实际状态与数据包；路由策略变更要看邻居、候选路由、选择、安装与转发；管理地址变更要证明新通路可用并保留恢复通路。对比 running 文本只能证明配置层，不是数据面证据。

这形成一条现实阶梯：工单批准、SSH 对端认证、NACM 授权、YANG 校验、running 最终成立、intended 形成、operational 应用、网络行为符合目标。前一层为真时，后一层完全可能为假。

同一个 RPC 调用十次，也不会长成分布式事务

RFC 6244 把 NETCONF 与 YANG 放在更完整的网络管理架构中。控制器当然可以把确认提交作为多设备变更的构件，但构件不会因重复调用自动提供全网原子性。

每台服务器保存自己的旧态，启动自己的时钟，声明自己的能力，并受自己的锁、权限、重启与硬件应用约束。控制器可能收到九个 <ok> 和一个错误。若先确认九台，再发现第十台失败，它已经使不完整拓扑最终成立；若取消九台，仍要证明九台的 operational 与真实转发回到了旧态。

上层编排必须自行定义事务标识、逐设备基线、调用与确认顺序、终止条件、观测门槛、补偿动作与最终对账。它可以选择严格全有或全无、金丝雀分阶段，或按服务能力作决策。无论选哪种，不能把一排绿色 RPC 当作共同的最终时刻。

能够经得起追问的最小结论

IANA 的 NETCONF 能力 URN 注册表 让独立实现用同一名字声明 candidate、confirmed commit、startup、validate 与其他能力。共同规范保持精简，是为了互操作，而不是替本地组织决定谁能确认、观察多久、如何锁定或何时宣布成功。

一条经得起追问的记录会这样说：这台服务器在这个模式与权限状态下，由这个会话把这份候选配置送入 running；它保存了这个旧态，使用这个期限和会话/令牌规则；流程最终以这个事件结束，running 和 startup 分别形成这些指纹；intended 与 operational 呈现这些差异；这些数据包与服务探针验证了这个范围内的结果；多设备交易已逐台对账。

实际权力属于能发起 RPC、掌握令牌、延长期限、执行确认、写入 startup、选择监控门槛的人和系统，而不是流程图上被写成“审批人”的名字。把这些执行权公开拆开，才是确认提交从技术功能变成可信治理的起点。

资料来源