A YANG Data Model for Hardware Management
Extracted elements (26)
The 'class' leaf uses YANG identity (identityref) rather than an enumeration so that vendors can extend the hierarchy by deriving their own identities from IANA-defined ones, providing extensibility without requiring changes to the base module.
The hardware data model uses a flat list of components (rather than a nested tree) where hierarchy is expressed via 'parent' and 'contains-child' leafrefs. This design mirrors the ENTITY-MIB flat table approach and simplifies mapping between the YANG model and the MIB.
The model is designed to be NMDA-compliant (RFC 8342), allowing configuration and operational state to be represented in separate datastores. A temporary 'ietf-hardware-state' module (all nodes config false) is provided for implementations that do not yet support NMDA, rather than making NMDA mandatory.
Each entry in '/hardware/component' in the operational state maps to one EntPhysicalEntry in ENTITY-MIB (RFC 6933). Writable MIB objects map to 'config true' YANG nodes, except entPhysicalSerialNum which is writable in the MIB but 'config false' in the YANG module.
Each entry in '/hardware/component' where 'sensor-data' exists maps to one EntPhySensorEntry in ENTITY-SENSOR-MIB (RFC 3433). Each entry where the 'state' container exists maps to one EntStateEntry in ENTITY-STATE-MIB (RFC 4268).
The 'ietf-hardware-state' module (Appendix A) is a temporary non-NMDA solution where all nodes are 'config false'. Implementations not yet supporting NMDA (RFC 8342) should use this module; if they also support hardware configuration, they SHOULD also implement 'ietf-hardware' in the configuration datastores.
For sensor-value-type of 'percentRH', the sensor-value node MUST contain a number ranging from 0 to 100. For 'truth-value', it MUST contain either 1 (true) or 2 (false).
If the '/hardware/component' list in the intended configuration is modified, the system MUST behave as if it re-initializes itself and follows the component-initialization procedure (matching by class, parent, and parent-rel-pos).
In the event that a physical component is contained by more than one physical component (e.g., double-wide modules), an implementation MUST use the same name every time the 'parent' node is instantiated for that component.
The 'physical-index' leaf MUST contain the value of the corresponding entPhysicalEntry's entPhysicalIndex when the device implements ENTITY-MIB.
When a new 'revision' is added to the 'iana-hardware' YANG module, it must be added in front of the existing revision statements, keeping the most recent revision first.
When the 'oper-state' node cannot be accurately reported because admin-state has a value other than 'unlocked', it MUST have a value of 'unknown'.
The 'alarm-state' typedef is a YANG bits type with bits: unknown (0), under-repair (1), critical (2), major (3), minor (4), warning (5), and indeterminate (6). When no bits are set, no active alarms are known and the component is not under repair.
The 'class' leaf in each component entry is an identityref whose base is 'ianahw:hardware-class'. Vendors are encouraged to use or derive from IANA-defined identities in 'iana-hardware' to describe component types such as chassis, module, port, sensor, fan, cpu, battery, and storage-drive.
The 'ietf-hardware' module defines a flat list of hardware components under '/hardware/component', each identified by a mandatory 'name' key and a mandatory 'class' leaf (identityref based on 'ianahw:hardware-class'). Components may reference parent/child relationships and carry identification, revision, sensor, and state sub-containers.
The 'sensor-data' container (feature 'hardware-sensor', present only for components of class 'ianahw:sensor') holds value, value-type, value-scale, value-precision, oper-status, units-display, value-timestamp, and value-update-rate leaves, all config false and mapped to ENTITY-SENSOR-MIB objects.
The 'sensor-value-precision' typedef is int8 ranging from -8 to 9. Positive values indicate the number of decimal places in the fractional part; negative values indicate the number of accurate digits; zero indicates the value is not a fixed-point number.
The 'sensor-value' typedef is int32 in the range -1000000000 to +1000000000. The extreme values -1000000000 and +1000000000 indicate underflow and overflow errors, respectively; interpretation depends on the associated sensor-value-type, sensor-value-scale, and sensor-value-precision nodes.
The 'standby-state' typedef enumerates: unknown (1), hot-standby (2), cold-standby (3), and providing-service (4). Hot-standby means immediate takeover without initialization; cold-standby requires initialization activity before takeover.
The 'state' container (feature 'hardware-state') holds admin-state (writable), oper-state, usage-state, alarm-state, and standby-state leaves, all mapped to corresponding ENTITY-STATE-MIB objects. The 'state-last-changed' leaf records when any of these state values last changed.
Three YANG notifications are defined: 'hardware-state-change' (fires when /hardware/last-change changes), 'hardware-state-oper-enabled' (fires when a component transitions to 'enabled' oper-state), and 'hardware-state-oper-disabled' (fires when a component transitions to 'disabled' oper-state). The latter two carry name, admin-state, and alarm-state leaves.
This document establishes the IANA-maintained 'iana-hardware' YANG module (namespace urn:ietf:params:xml:ns:yang:iana-hardware), which mirrors the 'IANA-ENTITY-MIB' IANAPhysicalClass textual convention as YANG identities derived from 'ianahw:hardware-class'. New hardware classes are added by updating this module.
Three YANG modules are registered in the 'YANG Module Names' registry: 'iana-hardware' (prefix ianahw), 'ietf-hardware' (prefix hw), and 'ietf-hardware-state' (prefix hw-state), all referencing RFC 8348. Three corresponding URIs are registered in the IETF XML Registry.
Read-sensitive nodes include '/hardware/component' (exposes vendor, model, version, and device-identification information), '/hardware/component/sensor-data/value' (physical sensor readings), and '/hardware/component/state' (reveals active and standby resource configuration). Read access should be controlled via NACM.
The YANG modules are accessed via NETCONF (mandatory secure transport: SSH per RFC 6242) or RESTCONF (mandatory secure transport: TLS per RFC 5246). The NETCONF Access Control Model (RFC 8341) must be used to restrict access to authorized users.
Writable node '/hardware/component/admin-state' is sensitive: setting it to 'locked' or 'shutting-down' can cause service disruption ranging from a single port to an entire device. Write operations via NETCONF/RESTCONF must be protected using NACM (RFC 8341).