This document defines a YANG data model for the management of hardware on a single server.
This document defines a YANG ^RFC7950^ data model for the management of hardware on a single server.
The data model includes configuration and system state (status information and counters for the collection of statistics).
The data model in this document is designed to be compliant with the Network Management Datastore Architecture (NMDA) ^I-D.ietf-netmod-revised-datastores^. For implementations that do not yet support NMDA, a temporary module with system state data only is defined in ^hw-state^.
The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14, ^RFC2119^ ^RFC8174^ when, and only when, they appear in all capitals, as shown here.
The following terms are defined in ^I-D.ietf-netmod-revised-datastores^ and are not redefined here:
- client
- server
- configuration
- system state
- operational state
- intended configuration
Tree diagrams used in this document follow the notation defined in ^I-D.ietf-netmod-yang-tree-diagrams^.
This section describes some of the design objectives for the hardware model.
- There are many common properties used to identify hardware components, which need to be supported in the hardware data model.
- There are many important information and states about the components, which needs to be collected from the devices which support the hardware data model.
- The hardware data model should be suitable for new implementations to use as is.
- The hardware data model defined in this document can be implemented on a system that also implements ENTITY-MIB, thus the mapping between the hardware data model and ENTITY-MIB should be clear.
- The data model should support pre-provisioning of hardware components.
This document defines the YANG module “ietf-hardware”, which has the following structure:
!! include-figure ietf-hardware.tree
The data model for hardware presented in this document uses a flat list of components. Each component in the list is identified by its name. Furthermore, each component has a mandatory “class” leaf.
The “iana-hardware” module defines YANG identities for the hardware types in the IANA-maintained “IANA-ENTITY-MIB” registry.
The “class” leaf is a YANG identity that describes the type of the hardware. Vendors are encouraged to either directly use one of the common IANA-defined identities, or derive a more specific identity from one of them.
If the device implements the ENTITY-MIB ^RFC6933^, each entry in the “/hardware/component” list in the operational state is mapped to one EntPhysicalEntry. Objects that are writable in the MIB are mapped to “config true” nodes in the “/hardware/component” list, except “entPhysicalSerialNum” which is writable in the MIB, but “config false” in the YANG module.
The “physical-index” leaf MUST contain the value of the corresponding entPhysicalEntry’s entPhysicalIndex.
The “class” leaf is mapped to both entPhysicalClass and entPhysicalVendorType. If the value of the “class” leaf is an identity that is either derived from or is one of the identities in the “iana-hardware” module, then entPhysicalClass contains the corresponding IANAPhysicalClass enumeration value. Otherwise, entPhysicalClass contains the IANAPhysicalClass value “other(1)”. Vendors are encouraged to define an identity (derived from an identity in “iana-hardware” if possible) for each enterprise-specific registration identifier used for entPhysicalVendorType, and use that identity for the “class” leaf.
The following tables list the YANG data nodes with corresponding objects in the ENTITY-MIB.
– YANG Data Nodes and Related ENTITY-MIB Objects
| YANG data node in /hardware/component | ENTITY-MIB object |
|---|---|
| name | entPhysicalName |
| class | entPhysicalClass entPhysicalVendorType |
| physical-index | entPhysicalIndex |
| description | entPhysicalDescr |
| parent | entPhysicalContainedIn |
| parent-rel-pos | entPhysicalParentRelPos |
| contains-child | entPhysicalChildIndex |
| hardware-rev | entPhysicalHardwareRev |
| firmware-rev | entPhysicalFirmwareRev |
| software-rev | entPhysicalSoftwareRev |
| serial-num | entPhysicalSerialNum |
| mfg-name | entPhysicalMfgName |
| model-name | entPhysicalModelName |
| alias | entPhysicalAlias |
| asset-id | entPhysicalAssetID |
| is-fru | entPhysicalIsFRU |
| mfg-date | entPhysicalMfgDate |
| uri | entPhysicalUris |
| uuid | entPhysicalUUID |
If the device implements the ENTITY-SENSOR-MIB ^RFC3433^, each entry in the “/hardware/component” list where the container “sensor-data” exists is mapped to one EntPhySensorEntry.
– YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects
| YANG data node in /hardware/component/sensor-data | ENTITY-SENSOR-MIB object |
|---|---|
| value | entPhySensorValue |
| value-type | entPhySensorType |
| value-scale | entPhySensorScale |
| value-precision | entPhySensorPrecision |
| oper-status | entPhySensorOperStatus |
| units-display | entPhySensorUnitsDisplay |
| value-timestamp | entPhySensorValueTimeStamp |
| value-update-rate | entPhySensorValueUpdateRate |
If the device implements the ENTITY-STATE-MIB ^RFC4268^, each entry in the “/hardware/component” list where the container “state” exists is mapped to one EntStateEntry.
– YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects
| YANG data node in /hardware/component/state | ENTITY-STATE-MIB object |
|---|---|
| state-last-changed | entStateLastChanged |
| admin-state | entStateAdmin |
| oper-state | entStateOper |
| usage-state | entStateUsage |
| alarm-state | entStateAlarm |
| standby-state | entStateStandby |
!! include-figure ietf-hardware.yang extract-to=”ietf-hardware@2018-01-15.yang”
!! include-figure iana-hardware.yang extract-to=”iana-hardware@2018-01-15.yang”
This document defines the initial version of the IANA-maintained “iana-hardware” YANG module.
The “iana-hardware” YANG module is intended to reflect the “IANA-ENTITY-MIB” MIB module so that if a new enumeration is added to the “IANAPhysicalClass” TEXTUAL-CONVENTION, the same class is added as an identity derived from “ianahw:hardware-class”.
When the “iana-hardware” YANG module is updated, a new “revision” statement must be added in front of the existing revision statements.
This document registers three URIs in the IETF XML registry ^RFC3688^. Following the format in RFC 3688, the following registrations are requested to be made.
URI: urn:ietf:params:xml:ns:yang:iana-hardware Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-hardware Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-hardware-state Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.
This document registers three YANG modules in the YANG Module Names registry ^RFC6020^.
name: iana-hardware namespace: urn:ietf:params:xml:ns:yang:iana-hardware prefix: ianahw reference: RFC XXXX
name: ietf-hardware namespace: urn:ietf:params:xml:ns:yang:ietf-hardware prefix: hw reference: RFC XXXX
name: ietf-hardware-state namespace: urn:ietf:params:xml:ns:yang:ietf-hardware-state prefix: hw-state reference: RFC XXXX
The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF ^RFC6241^ or RESTCONF ^RFC8040^. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) ^RFC6242^. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS ^RFC5246^.
The NETCONF access control model ^RFC6536^ provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
There are a number of data nodes defined in the YANG module “ietf-hardware” that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
= /hardware/component/admin-state: Setting this node to ‘locked’ or ‘shutting-down’ can cause disruption of services ranging from those running on a port to those on an entire device, depending on the type of component.
Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
= /hardware/component: The leafs in this list expose information about the physical components in a device, which may be used to identify the vendor, model, version, and specific device-identification information of each system component. = /hardware/component/sensor-data/value: This node may expose the values of particular physical sensors in a device. = /hardware/component/state: Access to this node allows one to figure out what the active and standby resources in a device are.
The authors wish to thank the following individuals, who all provided helpful comments on various draft versions of this document: Bart Bogaert, Timothy Carey, William Lupton, Juergen Schoenwaelder.
*! start-appendix
This non-normative appendix contains a data model designed as a temporary solution for implementations that do not yet support the Network Management Datastore Architecture (NMDA) defined in ^I-D.ietf-netmod-revised-datastores^. It has the following structure:
!! include-figure ietf-hardware-state.tree
!! include-figure ietf-hardware-state.yang extract-to=”ietf-hardware-state@2017-12-18.yang”
{{document: name ; ipr trust200902; category std; references back.xml; title “A YANG Data Model for Hardware Management”; abbreviation “YANG Hardware Management”; contributor “author:Andy Bierman:YumaWorks:andy@yumaworks.com”; contributor “author:Martin Bjorklund:Tail-f Systems:mbj@tail-f.com”; contributor “author:Jie Dong:Huawei Technologies:jie.dong@huawei.com”; contributor “author:Dan Romascanu::dromasca@gmail.com”; }}