A YANG Data Model for SNMP Configuration
Extracted elements (26)
The USM YANG model does not include the MIB objects for changing authentication and privacy keys (e.g., usmUserAuthKeyChange). Instead, only the localized key can be set directly. This implies that if the engine ID changes, all user keys must be reconfigured, which is a deliberate simplification over the MIB's key-change protocol.
The VACM YANG model restructures the flat vacmSecurityToGroupTable and vacmAccessTable into a hierarchical group → member/access nesting, and collapses vacmViewTreeFamilyTable into per-view include/exclude leaf-lists. This is described as a more compact and readable representation than the equivalent MIB flat tables.
The YANG model is split into submodules rather than a flat module to preserve SNMP's own modularity, keeping the number of namespaces manageable while allowing additional SNMP features to be added independently. This mirrors how SNMP MIB modules are structured without forcing consumers to deal with multiple YANG namespaces.
The YANG model omits the 'StorageType' and 'RowStatus' Textual Convention columns present in the corresponding SNMP MIBs. In NETCONF, persistency is determined by the datastore rather than per-row annotations, and row creation/deletion is handled by the protocol rather than the data model. This eliminates these MIB-specific constructs from the YANG representation.
Implementations supporting concurrent SNMP and NETCONF write access must ensure that SNMP spin lock objects (snmpTargetSpinLock, usmUserSpinLock, vacmViewSpinLock) are incremented whenever corresponding data is modified via NETCONF. This allows cooperating SNMP management applications to detect concurrent modifications.
The persistency models of NETCONF (datastore-based) and SNMP (StorageType per row) are incompatible, making simultaneous NETCONF and SNMP write access to the same data challenging. Configuration data may exist across up to three NETCONF datastores (running, candidate, startup) and must be mapped to SNMP table rows with appropriate StorageType values; no single recommended solution is provided.
When a device implements :startup, entries present in 'running' but not 'startup' should be mapped with StorageType 'volatile', while entries in 'startup' but not 'running' should not appear in the default SNMP context. This asymmetry requires special handling to correctly reflect datastore state over SNMP.
If the /snmp/engine/engine-id leaf is not set, the device MUST automatically calculate an engine ID as described in RFC 3411. A server MAY initialize this leaf with the automatically created value.
The ietf-snmp-community submodule defines /snmp/community with a 'name' choice (text-name string or binary-name binary), security-name, optional engine-id, context, and target-tag. Both the name choice and security-name leaf carry nacm:default-deny-all annotations to protect community string confidentiality.
The ietf-snmp-engine submodule defines /snmp/engine with leaves: enabled (boolean), listen list (name, transport choice defaulting to UDP with ip and port), version container (v1/v2c/v3 as empty leaves), engine-id, and enable-authen-traps. The transport choice is extensible via augmentation for SSH, TLS, and DTLS.
The ietf-snmp module is organized as a top-level module that includes eleven submodules: ietf-snmp-common, ietf-snmp-engine, ietf-snmp-target, ietf-snmp-notification, ietf-snmp-proxy, ietf-snmp-community, ietf-snmp-usm, ietf-snmp-tsm, ietf-snmp-vacm, ietf-snmp-tls, and ietf-snmp-ssh. All submodules share a single namespace (urn:ietf:params:xml:ns:yang:ietf-snmp) and contribute configuration nodes under the top-level /snmp container.
The ietf-snmp-notification submodule defines /snmp/notify (name, tag, type enum trap|inform) and /snmp/notify-filter-profile (name, include/exclude wildcard-object-identifier leaf-lists). It augments /snmp/target-params with a notify-filter-profile leafref, representing the MIB's sparse relationship between snmpTargetParamsTable and snmpNotifyFilterProfileTable.
The ietf-snmp-proxy submodule defines /snmp/proxy (name, type enum read|write|trap|inform, context-engine-id, context-name, target-params-in, single-target-out for read/write types, multiple-target-out for trap/inform types). It is gated by the 'proxy' YANG feature.
The ietf-snmp-ssh submodule augments /snmp/target and /snmp/engine/listen with an 'ssh' transport case carrying ip, port, and username fields. It is gated by the 'sshtm' YANG feature and corresponds to SNMP-SSH-TM-MIB.
The ietf-snmp-target submodule defines /snmp/target (keyed by name, with transport choice, tag leaf-list, timeout in centiseconds, retries, and target-params reference) and /snmp/target-params (keyed by name, with an open 'params' choice augmented by security-model-specific submodules). Entries correspond 1-1 to snmpTargetAddrEntry and snmpTargetParamsEntry.
The ietf-snmp-tls submodule defines /snmp/tlstm/cert-to-name (id uint32, fingerprint tls-fingerprint, map-type identityref, conditional name string) and augments /snmp/target and /snmp/engine/listen with 'tls' and 'dtls' transport cases carrying ip, port, client-fingerprint, server-fingerprint, and server-identity fields. It is gated by the 'tlstm' feature.
The ietf-snmp-tsm submodule defines /snmp/tsm with a single 'use-prefix' boolean leaf, and augments /snmp/target-params/params with a 'tsm' case carrying security-name and security-level. It is gated by the 'tsm' YANG feature.
The ietf-snmp-usm submodule defines /snmp/usm with a 'local' user list and a 'remote' list keyed by engine-id. Each user entry has optional 'auth' presence container (protocol choice md5|sha, each with a hex-string key) and optional 'priv' presence container (protocol choice des|aes, each with a hex-string key).
The ietf-snmp-vacm submodule maps vacmSecurityToGroupTable and vacmAccessTable to nested lists: /snmp/vacm/group contains a 'member' sublist (security-name, security-model) and an 'access' sublist (context, context-match, security-model, security-level, read-view, write-view, notify-view). MIB views are defined in /snmp/vacm/view with include/exclude wildcard-OID leaf-lists.
The ietf-x509-cert-to-name module defines a cert-to-name grouping used to map X.509 certificates to names. Each list entry (keyed by uint32 id) specifies a fingerprint, a map-type identityref (one of: specified, san-rfc822-name, san-dns-name, san-ip-address, san-any, common-name), and an optional name string active when map-type is 'specified'.
IANA registered two YANG modules in the 'IETF XML Registry': ietf-x509-cert-to-name (namespace urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name) and ietf-snmp (namespace urn:ietf:params:xml:ns:yang:ietf-snmp). Both are registered per RFC 3688 procedures.
The cert-to-name list controls which X.509 certificates are authorized and how they map to security names. Misconfiguration (e.g., mapping a CA fingerprint too broadly) could allow unintended certificates to authenticate. Administrators are encouraged to use subjectAltName-based mappings and per-certificate fingerprints rather than CA-level fingerprints where possible.
The community name and security-name leaves in ietf-snmp-community carry nacm:default-deny-all annotations, meaning NETCONF access control must be explicitly granted before these values can be read or written. This prevents inadvertent exposure of community strings through NETCONF.
USM authentication and privacy keys stored in /snmp/usm/local/user and /snmp/usm/remote are sensitive credentials. Implementations must ensure these values are protected by appropriate NETCONF access control (NACM) rules to prevent unauthorized disclosure or modification.
The engine-id typedef is a hex-string with pattern requiring 5 to 32 colon-separated hexadecimal octets (e.g., '80:00:02:b8:04:61:62:63'). This corresponds to the 5-32 octet SNMP-FRAMEWORK-MIB.snmpEngineID.
The tls-fingerprint typedef is a hex-string with pattern matching 1-octet hash algorithm identifier (from IANA TLS HashAlgorithm Registry per RFC 5246) followed by the fingerprint octets, encoded as colon-separated hexadecimal pairs (e.g., '01:ab:cd:...'). Defined in ietf-x509-cert-to-name.