Summary

  • RFC 6643 translates SMIv2 MIB modules into YANG for read-only NETCONF access. A source object labelled writable does not automatically become configurable through the new interface.
  • The obstacle is semantic, not merely syntactic: SNMP can attach persistence to individual objects or rows, whereas NETCONF configuration uses datastore rules.
  • Selected compatible nodes can be made configurable through documented deviations. That exception does not establish that an entire management workflow, or its restart behaviour, has migrated.

The easy acceptance test

Imagine a migration review in which a new controller retrieves every object on an agreed inventory. Names resolve, values appear, and the team can demonstrate the new management interface. The result is useful. It may also be entirely consistent with the old control path remaining indispensable.

This is an illustrative acceptance problem, not a reported deployment. Its technical basis is unusually clear. RFC 6643, published in July 2012, defines a route from SMIv2 MIB modules to YANG that deliberately stops at read-only access. The conversion opens a different way to see managed information. It does not automatically supply an equivalent way to change it.

A programme can therefore count converted objects accurately and still answer the wrong commercial question. The count measures representation coverage. Retiring a management system requires a different inventory: the changes people and applications depend on, their prerequisites, their persistence, and the route through which each remains possible.

These inventories can overlap heavily without becoming identical. An operator might want only a consolidated observation surface and retain its existing configuration tools by design. In that case the bridge has delivered its purpose. Trouble starts when the same result is accepted as evidence that the old management dependency has disappeared.

The old access label survives as a label

SMIv2 describes managed objects using a vocabulary that includes MAX-ACCESS. Some objects are readable and writable; others permit creation of instances. A mechanical converter can preserve those declarations without implementing the operations they once described.

RFC 6643 does exactly that distinction. The source access declaration becomes an smiv2:max-access extension statement. The generated top-level container for managed objects is nevertheless config false. The presence of familiar access metadata inside a familiar-looking tree cannot reverse the configuration classification of the resulting model.

Nor is the translation simply throwing the old contract away. It maps descriptions, references, types and object identifiers into corresponding YANG structures or extensions. Information can remain available for interpretation even where it is not a native instruction to the target configuration machinery. A record of a source capability and an implemented target capability are different assets.

That difference changes how acceptance should be phrased. “The new model preserves the old access declaration” is a testable statement about an artifact. “The new controller can perform the old authorized change” is a statement about a workflow and an implementation. Neither statement can be substituted for the other because the object names match.

Persistence lives in a different place

The reason for the default boundary is not that the standards authors overlooked writable objects. Section 11 identifies a mismatch between the persistence models of SNMP and NETCONF. On the SNMP side, an object's description or the properties of its conceptual row can determine what survives. A row may also use the StorageType textual convention. On the NETCONF side, the properties of a configuration datastore determine the relevant persistence behaviour.

StorageType in RFC 2579 shows how much meaning can sit below an apparently simple value. A volatile row is lost on reboot. Several other storage classes are backed by stable storage. Yet stable storage does not make their modification rules identical: a permanent row can be changed but not deleted, while a read-only row can be neither changed nor deleted. The convention also constrains changes to the storage-type object itself.

Those distinctions matter before a converter knows anything about a particular controller. A field's type, current value and write label do not by themselves describe its lifetime. Even the word permanent needs a defined object: a permanent row is not necessarily an immutable collection of every column value.

NETCONF's configuration model in RFC 6241 starts elsewhere. Its base model includes the running configuration. Additional datastores are capability-dependent. Direct writes to running depend on the corresponding capability; a distinct startup datastore has its own update rule. Where that startup capability is supported, a running change is not automatically copied into the boot configuration.

It would therefore be wrong to replace one shortcut with another and say that moving a value to NETCONF makes it durable. The destination datastore and supported operation still matter. A clean schema conversion cannot choose a persistence policy merely by making the value look at home in another language.

There is another limit in the same argument. RFC 6241's configuration-editing operations do not supply a general operation for changing arbitrary operational state. Some things a management interface exposes are not configuration inputs to be replayed. A migration planner must establish what kind of thing each proposed write actually changes.

A narrow exception, not an automatic upgrade

RFC 6643 does allow a way beyond read-only access. For selected objects whose persistence semantics are consistent across the two systems, an implementation may expose generated nodes as configuration. The deviation should be recorded in a separate YANG module. Changing config false to true without other semantic changes receives a specific compliance allowance in that conversion contract.

The qualification does the important work. It is not an instruction to change every flag in a generated file. It requires a reason why selected objects can cross the boundary without acquiring a different meaning. A converter can locate a node; it cannot automatically establish that the consequences of writing it remain equivalent.

The RFC illustrates the approach with an RMON2 control table and a separate deviation module. Its example addresses the relevant hierarchy and selected nodes individually, and shows the deviations advertised with module and revision information. The document cautions that a deviation affects its target node rather than serving as an undifferentiated downward promotion.

That example should not be confused with ordinary YANG defaults. The later YANG 1.1 specification, RFC 7950, describes inheritance when a config statement is absent, prohibits configuration nodes beneath a state-only node, and requires the resulting model to remain valid after advertised deviations are applied. A client needs the effective schema, not one isolated line taken from the base file.

This makes the exception useful precisely because it is local. A team can keep the unmodified conversion as a reproducible baseline and document the limited writable surface it has actually implemented. It need not pretend that all old objects have the same persistence semantics in order to make progress with a few that do.

Conversion needs a source of truth

RFC 6643 advises against hand-editing the generated YANG module. Necessary changes should normally be made to the original SMIv2 module, with its update and revision information adjusted, and then regenerated. Separate augmentations and deviations remain available.

This is more than housekeeping. If the generated artifact quietly becomes the only maintained version, a later regeneration can discard a local assumption. If the old source remains authoritative but the shipped deviations are not retained with it, a reader can reconstruct the wrong effective model. Both arrangements make maintenance depend on knowledge that is absent from the named artifact.

The public correction history provides a small, bounded example. Verified technical erratum 4786, reported and verified in August 2016, corrects a notification translation rule that could otherwise generate a duplicate leaf when the current object was already an index object. It does not grant write access or change persistence guarantees.

A correction to generated structure should therefore trigger the relevant conversion checks. It should not be narrated as proof that the management migration has become complete. The RFC Editor record establishes the document's publication context; neither that record nor the erratum demonstrates the behaviour of any deployed device.

Two products hiding in one migration budget

An observation bridge and a replacement control system may share tooling, schemas and staff, but they produce different acceptance evidence. The first makes information available through a chosen interface. The second must preserve or deliberately change the operational contract of actions that used to run elsewhere.

Keeping both paths can be a rational intermediate or permanent design. It can also create an obligation that a project has stopped funding. If the old path remains responsible for occasional changes, somebody still needs to maintain its credentials, operating knowledge, access controls and recovery arrangements. Read coverage does not determine the size of that residual obligation.

The budgetary inference is that a migration's completion criterion should name which product was purchased. A deliberately read-only bridge is not a defective write system. Conversely, an observation success cannot quietly release the people responsible for a control dependency that still exists.

Read-only access also has its own security boundary. RFC 6643 directs users to the sensitivity of the original MIB objects and to access controls. An inability to write through the converted model does not make the information harmless to disclose. Reading and changing need separate assessments, not a single safety label.

Evidence and interpretation

This analysis applies Lu Heng's distinction between symbolic claims and executable power and his argument about control detached from consequences. The application to management migration is Daniel Kade's inference. These essays do not establish that Lu Heng evaluated this protocol or that any supplier has acted improperly.

The sources establish language rules, a conversion design and a correction. They do not establish a named implementation, a completed migration, adoption rates, measured savings or an incident. No device was reconfigured or tested for this report. A real acceptance decision would need evidence specific to the source model, destination implementation and changes the operator actually intends to retire.