Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
Extracted elements (30)
SMIv2 OBJECT IDENTIFIER assignments (intermediate OID tree nodes) are translated to smiv2:alias statements rather than YANG data nodes because they carry only OID namespace structure and do not represent data objects accessible via NETCONF.
SMIv2 read-write and read-create objects are translated to read-only (config false) YANG objects because SNMP and NETCONF persistence models are fundamentally incompatible: SNMP uses per-object or StorageType-controlled persistence, while NETCONF persistence is datastore-driven, and NETCONF provides no standard operation to modify operational state.
YANG modules generated from SMIv2 modules should not be modified directly; changes must be made in the original SMIv2 module (updating LAST-UPDATED and REVISION) and the translation rerun. YANG augments and deviations on generated modules remain fully valid.
For SMIv2 objects whose SNMP and NETCONF persistence semantics are consistent, implementations may use YANG deviation statements in a separate module to promote config false to config true; such deviations must be advertised in the NETCONF hello capability list alongside the base generated module.
SMIv1 modules cannot be translated directly to YANG; they must first be converted to SMIv2 by following the coexistence rules in RFC 3584, after which the rules in this document apply.
The SMIv2 IMPORT mechanism imports specific named symbols, whereas YANG import statements import all symbols of the referenced module; translation rules must carefully filter SMIv2 imports to avoid generating spurious YANG dependencies on modules not actually needed.
An OCTET STRING type with an associated DISPLAY-HINT MUST be formatted according to the DISPLAY-HINT as described in RFC 2579 and maps to the YANG string type; without a DISPLAY-HINT it maps to the YANG binary type.
Implementations MUST add any additional import statements required by the type mapping in Appendix A, potentially importing ietf-yang-types, ietf-inet-types, or ietf-yang-smiv2.
In the rare case that a scalar object's parent node has multiple names (OID tree ambiguity), the automatic translation MUST fail with an error; if a previous unambiguous revision existed, that revision's name MUST be used.
Invocations of the NOTIFICATION-TYPE macro MUST be translated into YANG notification statements; each entry in the OBJECTS clause becomes a numbered container 'object-<n>' containing leafref leaves for INDEX objects and the notified object.
Invocations of the OBJECT-IDENTITY macro MUST be translated into YANG identity statements using smiv2:object-identity as the base identity, with STATUS, DESCRIPTION, REFERENCE, and OID value preserved.
Invocations of the OBJECT-TYPE macro MUST be translated into YANG statements: scalars and columnar objects become YANG leaf statements; non-augmenting conceptual tables become container+list structures; augmenting tables become smiv2:alias plus YANG augment statements.
Invocations of the SMIv2 TEXTUAL-CONVENTION macro MUST be translated into YANG typedef statements; if an implementation cannot derive proper length restrictions for string types, the YANG length statement MUST be omitted.
SMIv2 IMPORT clause items MUST be processed using seven specific rules: ignore SNMPv2-SMI and SNMPv2-CONF entirely, ignore well-known textual conventions covered in Appendix A, and generate YANG import statements only for items used in SYNTAX, OBJECTS, or INDEX/AUGMENTS clauses.
The generated YANG module name MUST be the same as the SMIv2 module name.
The top-level YANG container generated from a MODULE-IDENTITY macro invocation MUST be config false, making all translated SMIv2 objects read-only accessible via NETCONF.
The YANG namespace MUST be constructed from the IANA-registered prefix 'urn:ietf:params:xml:ns:yang:smiv2:' followed by the SMIv2 module name; since SMIv2 module names are unique, this guarantees a unique YANG namespace.
A non-augmenting SMIv2 conceptual table translates to a YANG container (table name) containing a YANG list (row name); the SMIv2 INDEX clause maps to the YANG key statement, and external INDEX objects referenced from another table become leafref leaves.
An augmenting SMIv2 conceptual table translates to an smiv2:alias statement (preserving the table and row OIDs) plus a YANG augment statement targeting the augmented table's list path and containing the additional columnar leaf statements.
The ietf-yang-smiv2 YANG module (namespace urn:ietf:params:xml:ns:yang:ietf-yang-smiv2, prefix smiv2) defines the object-identity base identity, the opaque typedef, and the seven YANG extensions (display-hint, max-access, defval, implied, alias, oid, subid) used throughout SMIv2-to-YANG translations.
The smiv2:alias YANG extension introduces an SMIv2 descriptor name for OBJECT IDENTIFIER assignments and augmenting conceptual table definitions that have no direct YANG data-node equivalent; its body MUST contain an smiv2:oid substatement.
The smiv2:defval YANG extension records an SMIv2 DEFVAL value in the SMIv2 value space, not the YANG value space, because the two spaces may differ for the same data type.
The smiv2:display-hint YANG extension records the SMIv2 DISPLAY-HINT format string within typedef and leaf statements for OCTET STRING-derived types, enabling display-layer formatting of binary values.
The smiv2:implied YANG extension records the name of an IMPLIED INDEX object from an SMIv2 INDEX clause, signaling that the last variable-length index has an implied rather than explicit length in OID encoding.
The smiv2:max-access YANG extension preserves the SMIv2 MAX-ACCESS value (e.g., 'read-only', 'read-write', 'not-accessible', 'accessible-for-notify') as metadata; it has no impact on NETCONF access control.
The smiv2:oid YANG extension captures the numeric object identifier assigned to an SMIv2 definition, expressed in decimal dotted notation (e.g., '1.3.6.1.2.1.2.1'), and is embedded in translated leaves, lists, containers, alias statements, and notifications.
The smiv2:subid YANG extension takes the last sub-identifier of an SMIv2 OID as its argument and may only appear as a substatement to a node whose parent already carries an smiv2:oid or smiv2:subid annotation.
This document registers the YANG module 'ietf-yang-smiv2' in the YANG Module Names registry (namespace urn:ietf:params:xml:ns:yang:ietf-yang-smiv2, prefix smiv2, reference RFC 6643) and registers two XML namespace URIs in the IETF XML registry: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 and urn:ietf:params:xml:ns:yang:smiv2.
The mechanical translation of SMIv2 MIB modules to YANG modules has no direct security impact on the Internet; the translation itself introduces no new attack surfaces.
Users of YANG modules generated from SMIv2 modules should consult the security considerations of the originating RFCs to identify sensitive objects, and should employ the NETCONF access control model (RFC 6536) to enforce access restrictions on potentially sensitive data.