摘要

  • RFC 6643 允许通过 NETCONF 读取由 SMIv2 MIB 转换而来的 YANG 对象，但不会自动把原先可写的对象变成新系统中的配置节点。
  • 障碍不只是模型语法。SNMP 的持久化规则可能落在对象说明、概念行或 StorageType 上；NETCONF 配置则受到目标数据存储及其能力的约束。
  • 对语义能够保持一致的部分对象，可以用单独的偏差模块明确提供配置能力。这个例外不能证明整套写入流程都已迁移，更不能单凭读取覆盖率批准旧系统退役。

最后一条写入路径，可能不在验收表里

管理迁移有一种很容易展示的成绩：原先通过旧工具看到的对象，现在都能在新平台查到了。清单可以逐项勾选，页面可以现场演示，项目也能形成一个不断上升的覆盖率。负责验收的人终于有了一组整齐的数字。

难展示的是另一类工作。某项配置一年只改一次，某个控制动作只在特殊维护时使用，某种状态需要重启以后才知道是否保留。它们在日常查询里不显眼，却可能决定旧管理系统能不能真正关闭。没有把这些职责列入验收，查询覆盖率再高，也无法替它们作出回答。

这里讨论的是一个假设性的验收场景，并非某家运营商已经发生的事故。RFC 6643 的转换规范提供了明确的技术依据：它把 SMIv2 MIB 模块转换为 YANG，使 NETCONF 能够只读访问其中的数据对象。该规范并没有把“换一种方式读取”包装成“已经迁走全部控制能力”。

因此，采购方首先需要说清楚买的是什么。若目标只是统一观察入口，保留原配置工具完全可能是合理设计；若目标包括撤掉旧管理通道，就必须另外证明原来依赖那条通道的动作有了去处。两种项目可以使用相同模型，完成条件却不能相同。

可写标签还在，不代表新接口已经可写

SMIv2 用 MAX-ACCESS 说明对象的访问性质。旧定义中的某个对象可以标为 read-write，另一个可以允许创建实例。转换之后，这些信息不必消失：RFC 6643 把它们保存在 smiv2:max-access 扩展语句中。

但新模型还有自己的配置分类。规范要求，为受管对象生成的顶层容器是 config false。旧访问说明被保留下来，并不意味着它获得了推翻这一分类的执行效力。模型里仍能看到“原来可写”，与控制器现在能够通过配置操作写入，是两件不同的事。

这也不是说转换把旧语义全部丢掉了。描述、引用、类型以及对象标识符都有相应的转换规则。一部分信息成为新语言可以直接处理的结构，一部分以扩展或说明的形式保留。保留下来的知识仍然有用，只是不能把每一项知识都当成新接口已经实现的动作。

在验收报告中，这个差别应当具体到表述。“原对象的访问说明得到保留”可以通过检查模型证明；“原有配置任务可以经新通道完成”需要检查实现、操作和结果。若把两项都简写为“支持该对象”，后续人员便很难知道究竟验收了哪一层。

重启以后留下什么，不由字段名称决定

RFC 6643 第 11 节说明了默认只读的原因。SNMP 与 NETCONF 的持久化模型并不相同。前者可能在对象的描述文字中定义一个值的保存方式，也可能通过概念行的属性约束它；有些行还使用 StorageType。后者则把配置的持久化问题放在数据存储的性质之中。

这意味着，转换器即使已经识别出名称、类型和当前值，也未必知道应该为这个值选择什么样的保存承诺。把它放进一个新模型，并不会自动补齐这份承诺。真正缺少的不是一个能解析的字段，而是两端对同一项变化承担相同后果的依据。

RFC 2579 的 StorageType 定义把问题拆得很细。易失行会在重启后丢失；若干其他类型由稳定存储支持。但后者并非同一种修改规则：permanent 行可以修改，却不能删除；readOnly 行既不能修改，也不能删除。存储类型对象本身的取值变更还有额外限制。

所以，“永久”也不能脱离它修饰的对象来理解。永久存在的一行，不等于其中每个值都绝对不可改变。稳定存储也不等于任何管理者都拥有修改权。把这些性质合并成一个“持久化支持”勾选框，会先在管理语言中删掉差别，再在运行时为差别付钱。

NETCONF 的 RFC 6241从另一套结构出发。基础模型包含运行配置，其他配置数据存储需要对应的能力支持。直接修改运行配置也有其能力要求。如果设备支持独立的启动配置，改变运行配置不会自动更新启动配置；把运行配置显式复制过去，是另一项操作。

这里尤其不能产生一个反向误解：既然 SNMP 的保存语义需要逐项核对，那么改用 NETCONF 就会自动解决。目标是什么数据存储，设备公开支持什么能力，操作究竟改变哪份配置，仍然必须明确。协议名称本身不是“重启以后仍然有效”的证明。

此外，RFC 6241 的配置编辑与复制操作并不是任意修改运行状态的通用接口。一个能够读取的管理值，可能描述设备正在发生什么，而不是一个应该被原样回放的配置指令。迁移写入之前，必须先弄清楚准备迁移的究竟是哪一种对象。

例外必须有自己的边界

默认只读并非拒绝所有配置用途。RFC 6643 允许实现者挑选持久化语义能够保持一致的对象，将相应节点作为配置提供。规范要求这种偏离生成基线的做法通过单独的 YANG 偏差模块正式说明。仅改变配置属性、而不改变其他语义的情况，在这份转换合同中有明确的符合性安排。

关键不在于能不能把 false 改成 true，而在于凭什么认为改变后仍是同一项操作。一个脚本很容易找到全部标志；它不会因为找到了标志，就知道对象在旧系统中的保存期限、修改条件和依赖关系是否与目的端一致。

规范用 RMON2 的一张控制表展示了选择性处理。例子并不是宣告整个模型突然都可写，而是分别列出有关层级与节点的偏差，并在能力通告中携带模块、版本和偏差信息。它还提醒，偏差作用于目标节点，不能将一次偏差当成笼统向下传播的修改指令。

这条提醒也不应与 YANG 通常的属性继承混为一谈。后来的 RFC 7950规定了省略 config 时如何采用父节点值，也规定状态节点之下不能出现配置节点；应用公开声明的偏差以后，整个模型仍须有效。判断一个节点能做什么，需要看有效模型，而不是只从某个文件里摘取一行。

选择性例外的价值，就在于允许局部完成。对确实能够保持语义的节点，可以建立明确的配置支持；其他部分仍可继续只读，或留在原通道。项目不必为追求一个整齐的百分比，强迫不同对象接受同一套未经证明的承诺。

再生成时，谁有权改写事实

转换结果还涉及维护权。RFC 6643 建议不要直接修改生成出来的 YANG；需要变化时，应当在原始 SMIv2 中作出适当修改，更新相关修订信息，再运行转换。独立的扩展和偏差仍然可以使用。

这个安排使基线与例外各有出处。如果生成文件被悄悄改成唯一权威版本，下一次再生成就可能抹掉本地假设；如果原始模块仍然保留，而设备实际采用的偏差没有随版本一起记录，维护人员拿到的则可能是一份形式完整、实际不适用的模型。

两种情况都会把一部分控制合同藏到文件之外：某个人记得为什么这样改，某个工具恰好保留了补丁，某次交付碰巧没有触发再生成。它们可能暂时正常工作，却难以支持人员交接，也无法说明下一次升级应该保留什么。

公开勘误提供了一个范围很小、却很有用的提醒。技术勘误 4786在 2016 年 8 月获得验证，修正的是通知转换规则：当当前对象本身已经是索引对象时，不应再为它多生成一个索引叶节点。这个修正针对重复节点，不是赋予写权限，也不是增强持久化保证。

应当随之复核的是相应的生成结果，而不是宣布迁移从此完成。RFC Editor 的文档记录说明规范的发表背景；文档与勘误都不证明某台设备已经实施了这些规则。标准文本的变化、交付模型的变化与运行设备的变化，需要分别确认。

一笔迁移预算，其实可能购买两种能力

观察入口和控制替代品可以共用工具、数据模型与工程团队，但它们不是同一种交付。观察入口让信息能够通过新的方式呈现；控制替代品则必须承接旧动作的含义，或者把主动改变含义这件事说清楚。

保留旧写入路径不是天然失败。在一些安排中，这正是成本可控的选择。真正容易失控的是：业务仍然依赖它，预算和人员安排却已经把它当成退役。罕见的写入任务、凭据维护、权限审核、异常操作知识，都不会因为日常查询换了平台而自动消失。

因此，项目关闭前的一个实用问题是：如果明天必须执行一项不常发生的管理变更，谁知道该用哪条路径，谁能够使用它，谁对它留下的状态负责？如果答案仍指向旧工具，旧工具就仍承担一项现实职责。迁移报告应保留这项职责，而不是把它解释成无关紧要的技术尾项。

只读入口本身也不是零风险入口。RFC 6643 提醒读者检查原始 MIB 对象的敏感性，并使用访问控制。不能通过模型修改设备，不代表读出的管理信息适合向所有人公开。读取和修改都需要边界，只是边界不同。

本文推论的范围

本文沿用 Lu Heng 对象征性表述与可执行力量的区分，以及他在控制权与后果脱节一文中提出的责任视角。将这些视角用于管理迁移，是 Daniel Kade 的分析，不代表 Lu Heng 评价过这项协议，也不能据此认定任何供应商存在不当行为。

资料支持的是规范设计、语义差别与已验证的勘误，不是具名迁移案例、采用比例、节省金额或事故报告。本文没有执行设备配置或互操作测试。对某个真实项目是否可以关闭旧系统的判断，仍需要该项目的模型、实现、操作职责和验收证据。