doc: Add RFC documents

1 files changed, 3363 insertions, 0 deletions

diff --git a/doc/rfc/rfc8348.txt b/doc/rfc/rfc8348.txt
new file mode 100644
index 0000000..110d4cb
--- /dev/null
+++ b/doc/rfc/rfc8348.txt
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        A. Bierman
+Request for Comments: 8348                                     YumaWorks
+Category: Standards Track                                   M. Bjorklund
+ISSN: 2070-1721                                           Tail-f Systems
+                                                                 J. Dong
+                                                     Huawei Technologies
+                                                            D. Romascanu
+                                                              March 2018
+
+
+               A YANG Data Model for Hardware Management
+
+Abstract
+
+   This document defines a YANG data model for the management of
+   hardware on a single server.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8348.
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 1]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+      1.2. Tree Diagrams ..............................................3
+   2. Objectives ......................................................4
+   3. Hardware Data Model .............................................4
+      3.1. The Components Lists .......................................5
+   4. Relationship to ENTITY-MIB ......................................6
+   5. Relationship to ENTITY-SENSOR-MIB ...............................8
+   6. Relationship to ENTITY-STATE-MIB ................................8
+   7. Hardware YANG Modules ...........................................9
+      7.1. "ietf-hardware" Module .....................................9
+      7.2. "iana-hardware" Module ....................................34
+   8. IANA Considerations ............................................38
+      8.1. URI Registrations .........................................38
+      8.2. YANG Module Registrations .................................39
+   9. Security Considerations ........................................39
+   10. References ....................................................40
+      10.1. Normative References .....................................40
+      10.2. Informative References ...................................41
+   Appendix A.  Hardware State Data Model ............................42
+     A.1.  Hardware State YANG Module ................................43
+   Acknowledgments ...................................................60
+   Authors' Addresses ................................................60
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 2]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+1.  Introduction
+
+   This document defines a YANG data model [RFC7950] 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) [RFC8342].  For
+   implementations that do not yet support NMDA, a temporary module with
+   system state data only is defined in Appendix A.
+
+1.1.  Terminology
+
+   The key words "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 [RFC8342] and are not redefined
+   here:
+
+   o  client
+
+   o  server
+
+   o  configuration
+
+   o  system state
+
+   o  operational state
+
+   o  intended configuration
+
+1.2.  Tree Diagrams
+
+   Tree diagrams used in this document follow the notation defined in
+   [RFC8340].
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 3]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+2.  Objectives
+
+   This section describes some of the design objectives for the hardware
+   data model.
+
+   o  The hardware data model needs to support many common properties
+      used to identify hardware components.
+
+   o  Important information and states about hardware components need to
+      be collected from devices that support the hardware data model.
+
+   o  The hardware data model should be suitable for new implementations
+      to use as is.
+
+   o  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.
+
+   o  The data model should support pre-provisioning of hardware
+      components.
+
+3.  Hardware Data Model
+
+   This document defines the YANG module "ietf-hardware", which has the
+   following structure:
+
+   module: ietf-hardware
+     +--rw hardware
+        +--ro last-change?   yang:date-and-time
+        +--rw component* [name]
+           +--rw name              string
+           +--rw class             identityref
+           +--ro physical-index?   int32 {entity-mib}?
+           +--ro description?      string
+           +--rw parent?           -> ../../component/name
+           +--rw parent-rel-pos?   int32
+           +--ro contains-child*   -> ../../component/name
+           +--ro hardware-rev?     string
+           +--ro firmware-rev?     string
+           +--ro software-rev?     string
+           +--ro serial-num?       string
+           +--ro mfg-name?         string
+           +--ro model-name?       string
+           +--rw alias?            string
+           +--rw asset-id?         string
+           +--ro is-fru?           boolean
+           +--ro mfg-date?         yang:date-and-time
+
+
+
+Bierman, et al.              Standards Track                    [Page 4]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           +--rw uri*              inet:uri
+           +--ro uuid?             yang:uuid
+           +--rw state {hardware-state}?
+           |  +--ro state-last-changed?   yang:date-and-time
+           |  +--rw admin-state?          admin-state
+           |  +--ro oper-state?           oper-state
+           |  +--ro usage-state?          usage-state
+           |  +--ro alarm-state?          alarm-state
+           |  +--ro standby-state?        standby-state
+           +--ro sensor-data {hardware-sensor}?
+              +--ro value?               sensor-value
+              +--ro value-type?          sensor-value-type
+              +--ro value-scale?         sensor-value-scale
+              +--ro value-precision?     sensor-value-precision
+              +--ro oper-status?         sensor-status
+              +--ro units-display?       string
+              +--ro value-timestamp?     yang:date-and-time
+              +--ro value-update-rate?   uint32
+
+     notifications:
+       +---n hardware-state-change
+       +---n hardware-state-oper-enabled {hardware-state}?
+       |  +--ro name?          -> /hardware/component/name
+       |  +--ro admin-state?   -> /hardware/component/state/admin-state
+       |  +--ro alarm-state?   -> /hardware/component/state/alarm-state
+       +---n hardware-state-oper-disabled {hardware-state}?
+          +--ro name?          -> /hardware/component/name
+          +--ro admin-state?   -> /hardware/component/state/admin-state
+          +--ro alarm-state?   -> /hardware/component/state/alarm-state
+
+3.1.  The Components Lists
+
+   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.
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 5]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+4.  Relationship to ENTITY-MIB
+
+   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 either is 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 table lists the YANG data nodes with corresponding
+   objects in the ENTITY-MIB.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 6]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+   +--------------------------------+----------------------------------+
+   | YANG data node in              | ENTITY-MIB object                |
+   | /hardware/component            |                                  |
+   +--------------------------------+----------------------------------+
+   | 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                  |
+   +--------------------------------+----------------------------------+
+
+              YANG Data Nodes and Related ENTITY-MIB Objects
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 7]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+5.  Relationship to ENTITY-SENSOR-MIB
+
+   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.
+
+   The following table lists the YANG data nodes with corresponding
+   objects in the ENTITY-SENSOR-MIB.
+
+   +-------------------------------------+-----------------------------+
+   | YANG data node in                   | ENTITY-SENSOR-MIB object    |
+   | /hardware/component/sensor-data     |                             |
+   +-------------------------------------+-----------------------------+
+   | value                               | entPhySensorValue           |
+   | value-type                          | entPhySensorType            |
+   | value-scale                         | entPhySensorScale           |
+   | value-precision                     | entPhySensorPrecision       |
+   | oper-status                         | entPhySensorOperStatus      |
+   | units-display                       | entPhySensorUnitsDisplay    |
+   | value-timestamp                     | entPhySensorValueTimeStamp  |
+   | value-update-rate                   | entPhySensorValueUpdateRate |
+   +-------------------------------------+-----------------------------+
+
+           YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects
+
+6.  Relationship to ENTITY-STATE-MIB
+
+   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.
+
+   The following table lists the YANG data nodes with corresponding
+   objects in the ENTITY-STATE-MIB.
+
+   +------------------------------------------+------------------------+
+   | YANG data node in                        | ENTITY-STATE-MIB       |
+   | /hardware/component/state                | object                 |
+   +------------------------------------------+------------------------+
+   | state-last-changed                       | entStateLastChanged    |
+   | admin-state                              | entStateAdmin          |
+   | oper-state                               | entStateOper           |
+   | usage-state                              | entStateUsage          |
+   | alarm-state                              | entStateAlarm          |
+   | standby-state                            | entStateStandby        |
+   +------------------------------------------+------------------------+
+
+           YANG Data Nodes and Related ENTITY-SENSOR-MIB Objects
+
+
+
+
+Bierman, et al.              Standards Track                    [Page 8]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+7.  Hardware YANG Modules
+
+7.1.  "ietf-hardware" Module
+
+   This YANG module imports typedefs from [RFC6991].
+
+   <CODE BEGINS> file "ietf-hardware@2018-03-13.yang"
+
+  module ietf-hardware {
+    yang-version 1.1;
+    namespace "urn:ietf:params:xml:ns:yang:ietf-hardware";
+    prefix hw;
+
+    import ietf-inet-types {
+      prefix inet;
+    }
+    import ietf-yang-types {
+      prefix yang;
+    }
+    import iana-hardware {
+      prefix ianahw;
+    }
+
+    organization
+      "IETF NETMOD (Network Modeling) Working Group";
+
+    contact
+      "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+       WG List:  <mailto:netmod@ietf.org>
+
+       Editor:   Andy Bierman
+                 <mailto:andy@yumaworks.com>
+
+       Editor:   Martin Bjorklund
+                 <mailto:mbj@tail-f.com>
+
+       Editor:   Jie Dong
+                 <mailto:jie.dong@huawei.com>
+
+       Editor:   Dan Romascanu
+                 <mailto:dromasca@gmail.com>";
+
+    description
+      "This module contains a collection of YANG definitions for
+       managing hardware.
+
+       This data model is designed for the Network Management Datastore
+       Architecture (NMDA) defined in RFC 8342.
+
+
+
+Bierman, et al.              Standards Track                    [Page 9]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+       Copyright (c) 2018 IETF Trust and the persons identified as
+       authors of the code.  All rights reserved.
+
+       Redistribution and use in source and binary forms, with or
+       without modification, is permitted pursuant to, and subject
+       to the license terms contained in, the Simplified BSD License
+       set forth in Section 4.c of the IETF Trust's Legal Provisions
+       Relating to IETF Documents
+       (https://trustee.ietf.org/license-info).
+
+       This version of this YANG module is part of RFC 8348; see
+       the RFC itself for full legal notices.";
+
+    revision 2018-03-13 {
+      description
+        "Initial revision.";
+      reference
+        "RFC 8348: A YANG Data Model for Hardware Management";
+    }
+
+    /*
+     * Features
+     */
+
+    feature entity-mib {
+      description
+        "This feature indicates that the device implements
+         the ENTITY-MIB.";
+      reference
+        "RFC 6933: Entity MIB (Version 4)";
+    }
+
+    feature hardware-state {
+      description
+        "Indicates that ENTITY-STATE-MIB objects are supported";
+      reference
+        "RFC 4268: Entity State MIB";
+    }
+
+    feature hardware-sensor {
+      description
+        "Indicates that ENTITY-SENSOR-MIB objects are supported";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base";
+    }
+
+    /*
+     * Typedefs
+
+
+
+Bierman, et al.              Standards Track                   [Page 10]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+     */
+
+    typedef admin-state {
+      type enumeration {
+        enum unknown {
+          value 1;
+          description
+            "The resource is unable to report administrative state.";
+        }
+        enum locked {
+          value 2;
+          description
+            "The resource is administratively prohibited from use.";
+        }
+        enum shutting-down {
+          value 3;
+          description
+            "The resource usage is administratively limited to current
+             instances of use.";
+        }
+        enum unlocked {
+          value 4;
+          description
+            "The resource is not administratively prohibited from
+             use.";
+        }
+      }
+      description
+        "Represents the various possible administrative states.";
+      reference
+        "RFC 4268: Entity State MIB - EntityAdminState";
+    }
+
+    typedef oper-state {
+      type enumeration {
+        enum unknown {
+          value 1;
+          description
+            "The resource is unable to report its operational state.";
+        }
+        enum disabled {
+          value 2;
+          description
+            "The resource is totally inoperable.";
+        }
+        enum enabled {
+          value 3;
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 11]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "The resource is partially or fully operable.";
+        }
+        enum testing {
+          value 4;
+          description
+            "The resource is currently being tested and cannot
+             therefore report whether or not it is operational.";
+        }
+      }
+      description
+        "Represents the possible values of operational states.";
+      reference
+        "RFC 4268: Entity State MIB - EntityOperState";
+    }
+
+    typedef usage-state {
+      type enumeration {
+        enum unknown {
+          value 1;
+          description
+            "The resource is unable to report usage state.";
+        }
+        enum idle {
+          value 2;
+          description
+            "The resource is servicing no users.";
+        }
+        enum active {
+          value 3;
+          description
+            "The resource is currently in use, and it has sufficient
+             spare capacity to provide for additional users.";
+        }
+        enum busy {
+          value 4;
+          description
+            "The resource is currently in use, but it currently has no
+             spare capacity to provide for additional users.";
+        }
+      }
+      description
+        "Represents the possible values of usage states.";
+      reference
+        "RFC 4268: Entity State MIB -  EntityUsageState";
+    }
+
+    typedef alarm-state {
+
+
+
+Bierman, et al.              Standards Track                   [Page 12]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+      type bits {
+        bit unknown {
+          position 0;
+          description
+            "The resource is unable to report alarm state.";
+        }
+        bit under-repair {
+          position 1;
+          description
+            "The resource is currently being repaired, which, depending
+             on the implementation, may make the other values in this
+             bit string not meaningful.";
+        }
+        bit critical {
+          position 2;
+          description
+            "One or more critical alarms are active against the
+             resource.";
+        }
+        bit major {
+          position 3;
+          description
+            "One or more major alarms are active against the
+             resource.";
+        }
+        bit minor {
+          position 4;
+          description
+            "One or more minor alarms are active against the
+             resource.";
+        }
+        bit warning {
+          position 5;
+          description
+            "One or more warning alarms are active against the
+             resource.";
+        }
+        bit indeterminate {
+          position 6;
+          description
+            "One or more alarms of whose perceived severity cannot be
+             determined are active against this resource.";
+        }
+      }
+      description
+        "Represents the possible values of alarm states.  An alarm is a
+         persistent indication of an error or warning condition.
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 13]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         When no bits of this attribute are set, then no active alarms
+         are known against this component and it is not under repair.";
+      reference
+        "RFC 4268: Entity State MIB - EntityAlarmStatus";
+    }
+
+    typedef standby-state {
+      type enumeration {
+        enum unknown {
+          value 1;
+          description
+            "The resource is unable to report standby state.";
+        }
+        enum hot-standby {
+          value 2;
+          description
+            "The resource is not providing service, but it will be
+             immediately able to take over the role of the resource to
+             be backed up, without the need for initialization
+             activity, and will contain the same information as the
+             resource to be backed up.";
+        }
+        enum cold-standby {
+          value 3;
+          description
+            "The resource is to back up another resource, but it will
+             not be immediately able to take over the role of a
+             resource to be backed up and will require some
+             initialization activity.";
+        }
+        enum providing-service {
+          value 4;
+          description
+            "The resource is providing service.";
+        }
+      }
+      description
+        "Represents the possible values of standby states.";
+      reference
+        "RFC 4268: Entity State MIB - EntityStandbyStatus";
+    }
+
+    typedef sensor-value-type {
+      type enumeration {
+        enum other {
+          value 1;
+          description
+            "A measure other than those listed below.";
+
+
+
+Bierman, et al.              Standards Track                   [Page 14]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        }
+        enum unknown {
+          value 2;
+          description
+            "An unknown measurement or arbitrary, relative numbers";
+        }
+        enum volts-AC {
+          value 3;
+          description
+            "A measure of electric potential (alternating current).";
+        }
+        enum volts-DC {
+          value 4;
+          description
+            "A measure of electric potential (direct current).";
+        }
+        enum amperes {
+          value 5;
+          description
+            "A measure of electric current.";
+        }
+        enum watts {
+          value 6;
+          description
+            "A measure of power.";
+        }
+        enum hertz {
+          value 7;
+          description
+            "A measure of frequency.";
+        }
+        enum celsius {
+          value 8;
+          description
+            "A measure of temperature.";
+        }
+        enum percent-RH {
+          value 9;
+          description
+            "A measure of percent relative humidity.";
+        }
+        enum rpm {
+          value 10;
+          description
+            "A measure of shaft revolutions per minute.";
+        }
+        enum cmm {
+          value 11;
+
+
+
+Bierman, et al.              Standards Track                   [Page 15]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "A measure of cubic meters per minute (airflow).";
+        }
+        enum truth-value {
+          value 12;
+          description
+            "Value is one of 1 (true) or 2 (false)";
+        }
+      }
+      description
+        "A node using this data type represents the sensor measurement
+         data type associated with a physical sensor value.  The actual
+         data units are determined by examining a node of this type
+         together with the associated sensor-value-scale node.
+
+         A node of this type SHOULD be defined together with nodes of
+         type sensor-value-scale and type sensor-value-precision.
+         These three types are used to identify the semantics of a node
+         of type sensor-value.";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base -
+                   EntitySensorDataType";
+    }
+
+    typedef sensor-value-scale {
+      type enumeration {
+        enum yocto {
+          value 1;
+          description
+            "Data scaling factor of 10^-24.";
+        }
+        enum zepto {
+          value 2;
+          description
+            "Data scaling factor of 10^-21.";
+        }
+        enum atto {
+          value 3;
+          description
+            "Data scaling factor of 10^-18.";
+        }
+        enum femto {
+          value 4;
+          description
+            "Data scaling factor of 10^-15.";
+        }
+        enum pico {
+          value 5;
+
+
+
+Bierman, et al.              Standards Track                   [Page 16]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "Data scaling factor of 10^-12.";
+        }
+        enum nano {
+          value 6;
+          description
+            "Data scaling factor of 10^-9.";
+        }
+        enum micro {
+          value 7;
+          description
+            "Data scaling factor of 10^-6.";
+        }
+        enum milli {
+          value 8;
+          description
+            "Data scaling factor of 10^-3.";
+        }
+        enum units {
+          value 9;
+          description
+            "Data scaling factor of 10^0.";
+        }
+        enum kilo {
+          value 10;
+          description
+            "Data scaling factor of 10^3.";
+        }
+        enum mega {
+          value 11;
+          description
+            "Data scaling factor of 10^6.";
+        }
+        enum giga {
+          value 12;
+          description
+            "Data scaling factor of 10^9.";
+        }
+        enum tera {
+          value 13;
+          description
+            "Data scaling factor of 10^12.";
+        }
+        enum peta {
+          value 14;
+          description
+            "Data scaling factor of 10^15.";
+        }
+
+
+
+Bierman, et al.              Standards Track                   [Page 17]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        enum exa {
+          value 15;
+          description
+            "Data scaling factor of 10^18.";
+        }
+        enum zetta {
+          value 16;
+          description
+            "Data scaling factor of 10^21.";
+        }
+        enum yotta {
+          value 17;
+          description
+            "Data scaling factor of 10^24.";
+        }
+      }
+      description
+        "A node using this data type represents a data scaling factor,
+         represented with an International System of Units (SI) prefix.
+         The actual data units are determined by examining a node of
+         this type together with the associated sensor-value-type.
+
+         A node of this type SHOULD be defined together with nodes of
+         type sensor-value-type and type sensor-value-precision.
+         Together, associated nodes of these three types are used to
+         identify the semantics of a node of type sensor-value.";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base -
+                   EntitySensorDataScale";
+    }
+
+    typedef sensor-value-precision {
+      type int8 {
+        range "-8 .. 9";
+      }
+      description
+        "A node using this data type represents a sensor value
+         precision range.
+
+         A node of this type SHOULD be defined together with nodes of
+         type sensor-value-type and type sensor-value-scale.  Together,
+         associated nodes of these three types are used to identify the
+         semantics of a node of type sensor-value.
+
+         If a node of this type contains a value in the range 1 to 9,
+         it represents the number of decimal places in the fractional
+         part of an associated sensor-value fixed-point number.
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 18]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         If a node of this type contains a value in the range -8 to -1,
+         it represents the number of accurate digits in the associated
+         sensor-value fixed-point number.
+
+         The value zero indicates the associated sensor-value node is
+         not a fixed-point number.
+
+         Server implementers must choose a value for the associated
+         sensor-value-precision node so that the precision and accuracy
+         of the associated sensor-value node is correctly indicated.
+
+         For example, a component representing a temperature sensor
+         that can measure 0 to 100 degrees C in 0.1 degree
+         increments, +/- 0.05 degrees, would have a
+         sensor-value-precision value of '1', a sensor-value-scale
+         value of 'units', and a sensor-value ranging from '0' to
+         '1000'.  The sensor-value would be interpreted as
+         'degrees C * 10'.";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base -
+                   EntitySensorPrecision";
+    }
+
+    typedef sensor-value {
+      type int32 {
+        range "-1000000000 .. 1000000000";
+      }
+      description
+       "A node using this data type represents a sensor value.
+
+        A node of this type SHOULD be defined together with nodes of
+        type sensor-value-type, type sensor-value-scale, and
+        type sensor-value-precision.  Together, associated nodes of
+        those three types are used to identify the semantics of a node
+        of this data type.
+
+        The semantics of a node using this data type are determined by
+        the value of the associated sensor-value-type node.
+
+        If the associated sensor-value-type node is equal to 'voltsAC',
+        'voltsDC', 'amperes', 'watts', 'hertz', 'celsius', or 'cmm',
+        then a node of this type MUST contain a fixed-point number
+        ranging from -999,999,999 to +999,999,999.  The value
+        -1000000000 indicates an underflow error.  The value
+        +1000000000 indicates an overflow error.  The
+        sensor-value-precision indicates how many fractional digits
+        are represented in the associated sensor-value node.
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 19]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        If the associated sensor-value-type node is equal to
+        'percentRH', then a node of this type MUST contain a number
+        ranging from 0 to 100.
+
+        If the associated sensor-value-type node is equal to 'rpm',
+        then a node of this type MUST contain a number ranging from
+        -999,999,999 to +999,999,999.
+
+        If the associated sensor-value-type node is equal to
+        'truth-value', then a node of this type MUST contain either the
+        value 1 (true) or the value 2 (false).
+
+        If the associated sensor-value-type node is equal to 'other' or
+        'unknown', then a node of this type MUST contain a number
+        ranging from -1000000000 to 1000000000.";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base -
+                   EntitySensorValue";
+    }
+
+    typedef sensor-status {
+      type enumeration {
+        enum ok {
+          value 1;
+          description
+            "Indicates that the server can obtain the sensor value.";
+        }
+        enum unavailable {
+          value 2;
+          description
+            "Indicates that the server presently cannot obtain the
+             sensor value.";
+        }
+        enum nonoperational {
+          value 3;
+          description
+            "Indicates that the server believes the sensor is broken.
+             The sensor could have a hard failure (disconnected wire)
+             or a soft failure such as out-of-range, jittery, or wildly
+             fluctuating readings.";
+        }
+      }
+      description
+        "A node using this data type represents the operational status
+         of a physical sensor.";
+      reference
+        "RFC 3433: Entity Sensor Management Information Base -
+                   EntitySensorStatus";
+
+
+
+Bierman, et al.              Standards Track                   [Page 20]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+    }
+
+    /*
+     * Data nodes
+     */
+
+    container hardware {
+      description
+        "Data nodes representing components.
+
+         If the server supports configuration of hardware components,
+         then this data model is instantiated in the configuration
+         datastores supported by the server.  The leaf-list 'datastore'
+         for the module 'ietf-hardware' in the YANG library provides
+         this information.";
+
+      leaf last-change {
+        type yang:date-and-time;
+        config false;
+        description
+          "The time the '/hardware/component' list changed in the
+           operational state.";
+      }
+
+      list component {
+        key name;
+        description
+          "List of components.
+
+           When the server detects a new hardware component, it
+           initializes a list entry in the operational state.
+
+           If the server does not support configuration of hardware
+           components, list entries in the operational state are
+           initialized with values for all nodes as detected by the
+           implementation.
+
+           Otherwise, this procedure is followed:
+
+             1. If there is an entry in the '/hardware/component' list
+                in the intended configuration with values for the nodes
+                'class', 'parent', and 'parent-rel-pos' that are equal
+                to the detected values, then the list entry in the
+                operational state is initialized with the configured
+                values, including the 'name'.
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 21]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+             2. Otherwise (i.e., there is no matching configuration
+                entry), the list entry in the operational state is
+                initialized with values for all nodes as detected by
+                the implementation.
+
+           If the '/hardware/component' list in the intended
+           configuration is modified, then the system MUST behave as if
+           it re-initializes itself and follow the procedure in (1).";
+        reference
+          "RFC 6933: Entity MIB (Version 4) - entPhysicalEntry";
+
+        leaf name {
+          type string;
+          description
+            "The name assigned to this component.
+
+             This name is not required to be the same as
+             entPhysicalName.";
+        }
+
+        leaf class {
+          type identityref {
+            base ianahw:hardware-class;
+          }
+          mandatory true;
+          description
+            "An indication of the general hardware type of the
+             component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalClass";
+        }
+
+        leaf physical-index {
+          if-feature entity-mib;
+          type int32 {
+            range "1..2147483647";
+          }
+          config false;
+          description
+            "The entPhysicalIndex for the entPhysicalEntry represented
+             by this list entry.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
+        }
+
+        leaf description {
+          type string;
+          config false;
+
+
+
+Bierman, et al.              Standards Track                   [Page 22]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "A textual description of the component.  This node should
+             contain a string that identifies the manufacturer's name
+             for the component and should be set to a distinct value
+             for each version or model of the component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalDescr";
+        }
+
+        leaf parent {
+          type leafref {
+            path "../../component/name";
+            require-instance false;
+          }
+          description
+            "The name of the component that physically contains this
+             component.
+
+             If this leaf is not instantiated, it indicates that this
+             component is not contained in any other component.
+
+             In the event that a physical component is contained by
+             more than one physical component (e.g., double-wide
+             modules), this node contains the name of one of these
+             components.  An implementation MUST use the same name
+             every time this node is instantiated.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalContainedIn";
+        }
+
+        leaf parent-rel-pos {
+          type int32 {
+            range "0 .. 2147483647";
+          }
+          description
+            "An indication of the relative position of this child
+             component among all its sibling components.  Sibling
+             components are defined as components that:
+
+               o share the same value of the 'parent' node and
+
+               o share a common base identity for the 'class' node.
+
+             Note that the last rule gives implementations flexibility
+             in how components are numbered.  For example, some
+             implementations might have a single number series for all
+             components derived from 'ianahw:port', while some others
+             might have different number series for different
+
+
+
+Bierman, et al.              Standards Track                   [Page 23]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+             components with identities derived from 'ianahw:port' (for
+             example, one for registered jack 45 (RJ45) and one for
+             small form-factor pluggable (SFP)).";
+
+          reference
+            "RFC 6933: Entity MIB (Version 4) -
+                       entPhysicalParentRelPos";
+        }
+
+        leaf-list contains-child {
+          type leafref {
+            path "../../component/name";
+          }
+          config false;
+          description
+            "The name of the contained component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalChildIndex";
+        }
+
+        leaf hardware-rev {
+          type string;
+          config false;
+          description
+            "The vendor-specific hardware revision string for the
+             component.  The preferred value is the hardware revision
+             identifier actually printed on the component itself (if
+             present).";
+          reference
+            "RFC 6933: Entity MIB (Version 4) -
+                       entPhysicalHardwareRev";
+        }
+
+        leaf firmware-rev {
+          type string;
+          config false;
+          description
+            "The vendor-specific firmware revision string for the
+             component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) -
+                       entPhysicalFirmwareRev";
+        }
+
+        leaf software-rev {
+          type string;
+          config false;
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 24]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "The vendor-specific software revision string for the
+             component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) -
+                       entPhysicalSoftwareRev";
+        }
+
+        leaf serial-num {
+          type string;
+          config false;
+          description
+            "The vendor-specific serial number string for the
+             component.  The preferred value is the serial number
+             string actually printed on the component itself (if
+             present).";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalSerialNum";
+        }
+
+        leaf mfg-name {
+          type string;
+          config false;
+          description
+            "The name of the manufacturer of this physical component.
+             The preferred value is the manufacturer name string
+             actually printed on the component itself (if present).
+
+             Note that comparisons between instances of the
+             'model-name', 'firmware-rev', 'software-rev', and
+             'serial-num' nodes are only meaningful amongst components
+             with the same value of 'mfg-name'.
+
+             If the manufacturer name string associated with the
+             physical component is unknown to the server, then this
+             node is not instantiated.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalMfgName";
+        }
+
+        leaf model-name {
+          type string;
+          config false;
+          description
+            "The vendor-specific model name identifier string
+             associated with this physical component.  The preferred
+             value is the customer-visible part number, which may be
+             printed on the component itself.
+
+
+
+Bierman, et al.              Standards Track                   [Page 25]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+             If the model name string associated with the physical
+             component is unknown to the server, then this node is not
+             instantiated.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalModelName";
+        }
+
+        leaf alias {
+          type string;
+          description
+            "An 'alias' name for the component, as specified by a
+             network manager, that provides a non-volatile 'handle' for
+             the component.
+
+             If no configured value exists, the server MAY set the
+             value of this node to a locally unique value in the
+             operational state.
+
+             A server implementation MAY map this leaf to the
+             entPhysicalAlias MIB object.  Such an implementation needs
+             to use some mechanism to handle the differences in size
+             and characters allowed between this leaf and
+             entPhysicalAlias.  The definition of such a mechanism is
+             outside the scope of this document.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalAlias";
+        }
+
+        leaf asset-id {
+          type string;
+          description
+            "This node is a user-assigned asset tracking identifier for
+             the component.
+
+             A server implementation MAY map this leaf to the
+             entPhysicalAssetID MIB object.  Such an implementation
+             needs to use some mechanism to handle the differences in
+             size and characters allowed between this leaf and
+             entPhysicalAssetID.  The definition of such a mechanism is
+             outside the scope of this document.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalAssetID";
+        }
+
+        leaf is-fru {
+          type boolean;
+          config false;
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 26]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          description
+            "This node indicates whether or not this component is
+             considered a 'field-replaceable unit' by the vendor.  If
+             this node contains the value 'true', then this component
+             identifies a field-replaceable unit.  For all components
+             that are permanently contained within a field-replaceable
+             unit, the value 'false' should be returned for this
+             node.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalIsFRU";
+        }
+
+        leaf mfg-date {
+          type yang:date-and-time;
+          config false;
+          description
+            "The date of manufacturing of the managed component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalMfgDate";
+        }
+
+        leaf-list uri {
+          type inet:uri;
+          description
+            "This node contains identification information about the
+             component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalUris";
+        }
+
+        leaf uuid {
+          type yang:uuid;
+          config false;
+          description
+            "A Universally Unique Identifier of the component.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalUUID";
+        }
+
+        container state {
+          if-feature hardware-state;
+          description
+            "State-related nodes";
+          reference
+            "RFC 4268: Entity State MIB";
+
+          leaf state-last-changed {
+            type yang:date-and-time;
+
+
+
+Bierman, et al.              Standards Track                   [Page 27]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+            config false;
+            description
+              "The date and time when the value of any of the
+               admin-state, oper-state, usage-state, alarm-state, or
+               standby-state changed for this component.
+
+               If there has been no change since the last
+               re-initialization of the local system, this node
+               contains the date and time of local system
+               initialization.  If there has been no change since the
+               component was added to the local system, this node
+               contains the date and time of the insertion.";
+            reference
+              "RFC 4268: Entity State MIB - entStateLastChanged";
+          }
+
+          leaf admin-state {
+            type admin-state;
+            description
+              "The administrative state for this component.
+
+               This node refers to a component's administrative
+               permission to service both other components within its
+               containment hierarchy as well other users of its
+               services defined by means outside the scope of this
+               module.
+
+               Some components exhibit only a subset of the remaining
+               administrative state values.  Some components cannot be
+               locked; hence, this node exhibits only the 'unlocked'
+               state.  Other components cannot be shut down gracefully;
+               hence, this node does not exhibit the 'shutting-down'
+               state.";
+            reference
+              "RFC 4268: Entity State MIB - entStateAdmin";
+          }
+
+          leaf oper-state {
+            type oper-state;
+            config false;
+            description
+              "The operational state for this component.
+
+               Note that this node does not follow the administrative
+               state.  An administrative state of 'down' does not
+               predict an operational state of 'disabled'.
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 28]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+               Note that some implementations may not be able to
+               accurately report oper-state while the admin-state node
+               has a value other than 'unlocked'.  In these cases, this
+               node MUST have a value of 'unknown'.";
+            reference
+              "RFC 4268: Entity State MIB - entStateOper";
+          }
+
+          leaf usage-state {
+            type usage-state;
+            config false;
+            description
+              "The usage state for this component.
+
+               This node refers to a component's ability to service
+               more components in a containment hierarchy.
+
+               Some components will exhibit only a subset of the usage
+               state values.  Components that are unable to ever
+               service any components within a containment hierarchy
+               will always have a usage state of 'busy'.  In some
+               cases, a component will be able to support only one
+               other component within its containment hierarchy and
+               will therefore only exhibit values of 'idle' and
+               'busy'.";
+            reference
+              "RFC 4268: Entity State MIB - entStateUsage";
+          }
+
+          leaf alarm-state {
+            type alarm-state;
+            config false;
+            description
+              "The alarm state for this component.  It does not
+               include the alarms raised on child components within its
+               containment hierarchy.";
+            reference
+              "RFC 4268: Entity State MIB - entStateAlarm";
+          }
+
+          leaf standby-state {
+            type standby-state;
+            config false;
+            description
+              "The standby state for this component.
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 29]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+               Some components will exhibit only a subset of the
+               remaining standby state values.  If this component
+               cannot operate in a standby role, the value of this node
+               will always be 'providing-service'.";
+            reference
+              "RFC 4268: Entity State MIB - entStateStandby";
+          }
+        }
+
+        container sensor-data {
+          when 'derived-from-or-self(../class,
+                                     "ianahw:sensor")' {
+            description
+              "Sensor data nodes present for any component of type
+               'sensor'";
+          }
+          if-feature hardware-sensor;
+          config false;
+
+          description
+            "Sensor-related nodes.";
+          reference
+            "RFC 3433: Entity Sensor Management Information Base";
+
+          leaf value {
+            type sensor-value;
+            description
+              "The most recent measurement obtained by the server
+               for this sensor.
+
+               A client that periodically fetches this node should also
+               fetch the nodes 'value-type', 'value-scale', and
+               'value-precision', since they may change when the value
+               is changed.";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorValue";
+          }
+
+          leaf value-type {
+            type sensor-value-type;
+            description
+              "The type of data units associated with the
+               sensor value";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorType";
+          }
+
+
+
+Bierman, et al.              Standards Track                   [Page 30]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          leaf value-scale {
+            type sensor-value-scale;
+            description
+              "The (power of 10) scaling factor associated
+               with the sensor value";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorScale";
+          }
+
+          leaf value-precision {
+            type sensor-value-precision;
+            description
+              "The number of decimal places of precision
+               associated with the sensor value";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorPrecision";
+          }
+
+          leaf oper-status {
+            type sensor-status;
+            description
+              "The operational status of the sensor.";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorOperStatus";
+          }
+
+          leaf units-display {
+            type string;
+            description
+              "A textual description of the data units that should be
+               used in the display of the sensor value.";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorUnitsDisplay";
+          }
+
+          leaf value-timestamp {
+            type yang:date-and-time;
+            description
+              "The time the status and/or value of this sensor was last
+               obtained by the server.";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorValueTimeStamp";
+          }
+
+
+
+Bierman, et al.              Standards Track                   [Page 31]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          leaf value-update-rate {
+            type uint32;
+            units "milliseconds";
+            description
+              "An indication of the frequency that the server updates
+               the associated 'value' node, represented in
+               milliseconds.  The value zero indicates:
+
+                - the sensor value is updated on demand (e.g.,
+                  when polled by the server for a get-request),
+
+                - the sensor value is updated when the sensor
+                  value changes (event-driven), or
+
+                - the server does not know the update rate.";
+            reference
+              "RFC 3433: Entity Sensor Management Information Base -
+                         entPhySensorValueUpdateRate";
+          }
+        }
+      }
+    }
+
+    /*
+     * Notifications
+     */
+
+    notification hardware-state-change {
+      description
+        "A hardware-state-change notification is generated when the
+         value of /hardware/last-change changes in the operational
+         state.";
+      reference
+        "RFC 6933: Entity MIB (Version 4) - entConfigChange";
+    }
+
+    notification hardware-state-oper-enabled {
+      if-feature hardware-state;
+      description
+        "A hardware-state-oper-enabled notification signifies that a
+         component has transitioned into the 'enabled' state.";
+
+      leaf name {
+        type leafref {
+          path "/hardware/component/name";
+        }
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 32]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        description
+          "The name of the component that has transitioned into the
+           'enabled' state.";
+      }
+      leaf admin-state {
+        type leafref {
+          path "/hardware/component/state/admin-state";
+        }
+        description
+          "The administrative state for the component.";
+      }
+      leaf alarm-state {
+        type leafref {
+          path "/hardware/component/state/alarm-state";
+        }
+        description
+          "The alarm state for the component.";
+      }
+      reference
+        "RFC 4268: Entity State MIB - entStateOperEnabled";
+    }
+
+    notification hardware-state-oper-disabled {
+      if-feature hardware-state;
+      description
+        "A hardware-state-oper-disabled notification signifies that a
+         component has transitioned into the 'disabled' state.";
+
+      leaf name {
+        type leafref {
+          path "/hardware/component/name";
+        }
+        description
+          "The name of the component that has transitioned into the
+           'disabled' state.";
+      }
+      leaf admin-state {
+        type leafref {
+          path "/hardware/component/state/admin-state";
+        }
+        description
+          "The administrative state for the component.";
+      }
+      leaf alarm-state {
+        type leafref {
+          path "/hardware/component/state/alarm-state";
+        }
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 33]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        description
+          "The alarm state for the component.";
+      }
+      reference
+        "RFC 4268: Entity State MIB - entStateOperDisabled";
+    }
+
+  }
+
+   <CODE ENDS>
+
+7.2.  "iana-hardware" Module
+
+   <CODE BEGINS> file "iana-hardware@2018-03-13.yang"
+
+   module iana-hardware {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:iana-hardware";
+     prefix ianahw;
+
+     organization "IANA";
+     contact
+       "        Internet Assigned Numbers Authority
+
+        Postal: ICANN
+                12025 Waterfront Drive, Suite 300
+                Los Angeles, CA  90094-2536
+                United States of America
+
+        Tel:    +1 310 301 5800
+        E-Mail: iana@iana.org>";
+
+     description
+       "IANA-defined identities for hardware class.
+
+        The latest revision of this YANG module can be obtained from
+        the IANA website.
+
+        Requests for new values should be made to IANA via
+        email (iana@iana.org).
+
+        Copyright (c) 2018 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject
+        to the license terms contained in, the Simplified BSD License
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 34]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        set forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (https://trustee.ietf.org/license-info).
+
+        The initial version of this YANG module is part of RFC 8348;
+        see the RFC itself for full legal notices.";
+     reference
+       "https://www.iana.org/assignments/yang-parameters";
+
+     revision 2018-03-13 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8348: A YANG Data Model for Hardware Management";
+     }
+
+     /*
+      * Identities
+      */
+
+     identity hardware-class {
+       description
+         "This identity is the base for all hardware class
+          identifiers.";
+     }
+
+     identity unknown {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is unknown
+          to the server.";
+     }
+
+     identity chassis {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is an
+          overall container for networking equipment.  Any class of
+          physical component, except a stack, may be contained within a
+          chassis; a chassis may only be contained within a stack.";
+     }
+
+     identity backplane {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of device for aggregating and forwarding networking traffic,
+          such as a shared backplane in a modular ethernet switch.  Note
+
+
+
+Bierman, et al.              Standards Track                   [Page 35]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          that an implementation may model a backplane as a single
+          physical component, which is actually implemented as multiple
+          discrete physical components (within a chassis or stack).";
+     }
+
+     identity container {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is capable
+          of containing one or more removable physical entities,
+          possibly of different types.  For example, each (empty or
+          full) slot in a chassis will be modeled as a container.  Note
+          that all removable physical components should be modeled
+          within a container component, such as field-replaceable
+          modules, fans, or power supplies.  Note that all known
+          containers should be modeled by the agent, including empty
+          containers.";
+     }
+
+     identity power-supply {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is a
+          power-supplying component.";
+     }
+
+     identity fan {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is a fan or
+          other heat-reduction component.";
+     }
+
+     identity sensor {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of sensor, such as a temperature sensor within a router
+          chassis.";
+     }
+
+     identity module {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of self-contained sub-system.  If a module component is
+          removable, then it should be modeled within a container
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 36]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+          component; otherwise, it should be modeled directly within
+          another physical component (e.g., a chassis or another
+          module).";
+     }
+
+     identity port {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of networking port capable of receiving and/or transmitting
+          networking traffic.";
+     }
+
+     identity stack {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of super-container (possibly virtual) intended to group
+          together multiple chassis entities.  A stack may be realized
+          by a virtual cable, a real interconnect cable attached to
+          multiple chassis, or multiple interconnect cables.  A stack
+          should not be modeled within any other physical components,
+          but a stack may be contained within another stack.  Only
+          chassis components should be contained within a stack.";
+     }
+
+     identity cpu {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of central processing unit.";
+     }
+
+     identity energy-object {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of energy object, i.e., it is a piece of equipment that is
+          part of or attached to a communications network that is
+          monitored, it is controlled, or it aids in the management of
+          another device for Energy Management.";
+     }
+
+     identity battery {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of battery.";
+
+
+
+Bierman, et al.              Standards Track                   [Page 37]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+     }
+
+     identity storage-drive {
+       base ianahw:hardware-class;
+       description
+         "This identity is applicable if the hardware class is some sort
+          of component with data storage capability as its main
+          functionality, e.g., hard disk drive (HDD), solid-state device
+          (SSD), solid-state hybrid drive (SSHD), object storage device
+          (OSD), or other.";
+     }
+   }
+
+   <CODE ENDS>
+
+8.  IANA Considerations
+
+   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.
+
+8.1.  URI Registrations
+
+   This document registers three URIs in the "IETF XML Registry"
+   [RFC3688].  Per the format in RFC 3688, the following registrations
+   have been 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.
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 38]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+8.2.  YANG Module Registrations
+
+   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 8348
+
+     name:         ietf-hardware
+     namespace:    urn:ietf:params:xml:ns:yang:ietf-hardware
+     prefix:       hw
+     reference:    RFC 8348
+
+     name:         ietf-hardware-state
+     namespace:    urn:ietf:params:xml:ns:yang:ietf-hardware-state
+     prefix:       hw-state
+     reference:    RFC 8348
+
+9.  Security Considerations
+
+   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 [RFC8341] 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.
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 39]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+   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.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3433]  Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor
+              Management Information Base", RFC 3433,
+              DOI 10.17487/RFC3433, December 2002,
+              <https://www.rfc-editor.org/info/rfc3433>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC4268]  Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268,
+              DOI 10.17487/RFC4268, November 2005,
+              <https://www.rfc-editor.org/info/rfc4268>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <https://www.rfc-editor.org/info/rfc6020>.
+
+
+
+Bierman, et al.              Standards Track                   [Page 40]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
+              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+              <https://www.rfc-editor.org/info/rfc6242>.
+
+   [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
+              Chandramouli, "Entity MIB (Version 4)", RFC 6933,
+              DOI 10.17487/RFC6933, May 2013,
+              <https://www.rfc-editor.org/info/rfc6933>.
+
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <https://www.rfc-editor.org/info/rfc6991>.
+
+   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+              RFC 7950, DOI 10.17487/RFC7950, August 2016,
+              <https://www.rfc-editor.org/info/rfc7950>.
+
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
+              Access Control Model", STD 91, RFC 8341,
+              DOI 10.17487/RFC8341, March 2018,
+              <https://www.rfc-editor.org/info/rfc8341>.
+
+   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
+              and R. Wilton, "Network Management Datastore Architecture
+              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
+              <https://www.rfc-editor.org/info/rfc8342>.
+
+10.2.  Informative References
+
+   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
+              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
+              <https://www.rfc-editor.org/info/rfc8340>.
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 41]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+Appendix A.  Hardware State Data Model
+
+   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
+   [RFC8342].  It has the following structure:
+
+   module: ietf-hardware-state
+     x--ro hardware
+        x--ro last-change?   yang:date-and-time
+        x--ro component* [name]
+           x--ro name              string
+           x--ro class             identityref
+           x--ro physical-index?   int32 {entity-mib}?
+           x--ro description?      string
+           x--ro parent?           -> ../../component/name
+           x--ro parent-rel-pos?   int32
+           x--ro contains-child*   -> ../../component/name
+           x--ro hardware-rev?     string
+           x--ro firmware-rev?     string
+           x--ro software-rev?     string
+           x--ro serial-num?       string
+           x--ro mfg-name?         string
+           x--ro model-name?       string
+           x--ro alias?            string
+           x--ro asset-id?         string
+           x--ro is-fru?           boolean
+           x--ro mfg-date?         yang:date-and-time
+           x--ro uri*              inet:uri
+           x--ro uuid?             yang:uuid
+           x--ro state {hardware-state}?
+           |  x--ro state-last-changed?   yang:date-and-time
+           |  x--ro admin-state?          hw:admin-state
+           |  x--ro oper-state?           hw:oper-state
+           |  x--ro usage-state?          hw:usage-state
+           |  x--ro alarm-state?          hw:alarm-state
+           |  x--ro standby-state?        hw:standby-state
+           x--ro sensor-data {hardware-sensor}?
+              x--ro value?               hw:sensor-value
+              x--ro value-type?          hw:sensor-value-type
+              x--ro value-scale?         hw:sensor-value-scale
+              x--ro value-precision?     hw:sensor-value-precision
+              x--ro oper-status?         hw:sensor-status
+              x--ro units-display?       string
+              x--ro value-timestamp?     yang:date-and-time
+              x--ro value-update-rate?   uint32
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 42]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+     notifications:
+       x---n hardware-state-change
+       x---n hardware-state-oper-enabled {hardware-state}?
+       |  x--ro name?          -> /hardware/component/name
+       |  x--ro admin-state?   -> /hardware/component/state/admin-state
+       |  x--ro alarm-state?   -> /hardware/component/state/alarm-state
+       x---n hardware-state-oper-disabled {hardware-state}?
+          x--ro name?          -> /hardware/component/name
+          x--ro admin-state?   -> /hardware/component/state/admin-state
+          x--ro alarm-state?   -> /hardware/component/state/alarm-state
+
+A.1.  Hardware State YANG Module
+
+   <CODE BEGINS> file "ietf-hardware-state@2018-03-13.yang"
+
+   module ietf-hardware-state {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:ietf-hardware-state";
+     prefix hw-state;
+
+     import ietf-inet-types {
+       prefix inet;
+     }
+     import ietf-yang-types {
+       prefix yang;
+     }
+     import iana-hardware {
+       prefix ianahw;
+     }
+     import ietf-hardware {
+       prefix hw;
+     }
+
+     organization
+       "IETF NETMOD (Network Modeling) Working Group";
+
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/netmod/>
+        WG List:  <mailto:netmod@ietf.org>
+
+        Editor:   Andy Bierman
+                  <mailto:andy@yumaworks.com>
+
+        Editor:   Martin Bjorklund
+                  <mailto:mbj@tail-f.com>
+
+        Editor:   Jie Dong
+                  <mailto:jie.dong@huawei.com>
+
+
+
+Bierman, et al.              Standards Track                   [Page 43]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+        Editor:   Dan Romascanu
+                  <mailto:dromasca@gmail.com>";
+
+     description
+       "This module contains a collection of YANG definitions for
+        monitoring hardware.
+
+        This data model is designed as a temporary solution for
+        implementations that do not yet support the Network Management
+        Datastore Architecture (NMDA) defined in RFC 8342.  Such an
+        implementation cannot implement the module 'ietf-hardware'
+        properly, since without NMDA support, it is not possible to
+        distinguish between instances of nodes in the running
+        configuration and operational states.
+
+        The data model in this module is the same as the data model in
+        'ietf-hardware', except all nodes are marked as 'config false'.
+
+        If a server that implements this module but doesn't support NMDA
+        also supports configuration of hardware components, it SHOULD
+        also implement the module 'ietf-hardware' in the configuration
+        datastores.  The corresponding state data is found in the
+        '/hw-state:hardware' subtree.
+
+        Copyright (c) 2018 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject
+        to the license terms contained in, the Simplified BSD License
+        set forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (https://trustee.ietf.org/license-info).
+
+        This version of this YANG module is part of RFC 8348; see
+        the RFC itself for full legal notices.";
+
+     revision 2018-03-13 {
+       description
+         "Initial revision.";
+       reference
+         "RFC 8348: A YANG Data Model for Hardware Management";
+     }
+
+     /*
+      * Features
+      */
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 44]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+     feature entity-mib {
+       status deprecated;
+       description
+         "This feature indicates that the device implements
+          the ENTITY-MIB.";
+       reference
+         "RFC 6933: Entity MIB (Version 4)";
+     }
+
+     feature hardware-state {
+       status deprecated;
+       description
+         "Indicates that ENTITY-STATE-MIB objects are supported";
+       reference
+         "RFC 4268: Entity State MIB";
+     }
+
+     feature hardware-sensor {
+       status deprecated;
+       description
+         "Indicates that ENTITY-SENSOR-MIB objects are supported";
+       reference
+         "RFC 3433: Entity Sensor Management Information Base";
+     }
+
+     /*
+      * Data nodes
+      */
+
+     container hardware {
+       config false;
+       status deprecated;
+       description
+         "Data nodes representing components.";
+
+       leaf last-change {
+         type yang:date-and-time;
+         status deprecated;
+         description
+           "The time the '/hardware/component' list changed in the
+            operational state.";
+       }
+
+       list component {
+         key name;
+         status deprecated;
+         description
+           "List of components.
+
+
+
+Bierman, et al.              Standards Track                   [Page 45]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+            When the server detects a new hardware component, it
+            initializes a list entry in the operational state.
+
+            If the server does not support configuration of hardware
+            components, list entries in the operational state are
+            initialized with values for all nodes as detected by the
+            implementation.
+
+            Otherwise, this procedure is followed:
+
+              1. If there is an entry in the '/hardware/component' list
+                 in the intended configuration with values for the nodes
+                 'class', 'parent', and 'parent-rel-pos' that are equal
+                 to the detected values, then:
+
+              1a. If the configured entry has a value for 'mfg-name'
+                  that is equal to the detected value or if the
+                  'mfg-name' value cannot be detected, then the list
+                  entry in the operational state is initialized with the
+                  configured values for all configured nodes, including
+                  the 'name'.
+
+                  Otherwise, the list entry in the operational state is
+                  initialized with values for all nodes as detected by
+                  the implementation.  The implementation may raise an
+                  alarm that informs about the 'mfg-name' mismatch
+                  condition.  How this is done is outside the scope of
+                  this document.
+
+              1b. Otherwise (i.e., there is no matching configuration
+                  entry), the list entry in the operational state is
+                  initialized with values for all nodes as detected by
+                  the implementation.
+
+            If the '/hardware/component' list in the intended
+            configuration is modified, then the system MUST behave as if
+            it re-initializes itself and follow the procedure in (1).";
+         reference
+           "RFC 6933: Entity MIB (Version 4) - entPhysicalEntry";
+
+         leaf name {
+           type string;
+           status deprecated;
+           description
+             "The name assigned to this component.
+
+              This name is not required to be the same as
+              entPhysicalName.";
+
+
+
+Bierman, et al.              Standards Track                   [Page 46]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         }
+
+         leaf class {
+           type identityref {
+             base ianahw:hardware-class;
+           }
+           mandatory true;
+           status deprecated;
+           description
+             "An indication of the general hardware type of the
+              component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalClass";
+         }
+
+         leaf physical-index {
+           if-feature entity-mib;
+           type int32 {
+             range "1..2147483647";
+           }
+           status deprecated;
+           description
+             "The entPhysicalIndex for the entPhysicalEntry represented
+              by this list entry.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
+         }
+
+         leaf description {
+           type string;
+           status deprecated;
+           description
+             "A textual description of the component.  This node should
+              contain a string that identifies the manufacturer's name
+              for the component and should be set to a distinct value
+              for each version or model of the component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalDescr";
+         }
+
+         leaf parent {
+           type leafref {
+             path "../../component/name";
+             require-instance false;
+           }
+           status deprecated;
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 47]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           description
+             "The name of the component that physically contains this
+              component.
+
+              If this leaf is not instantiated, it indicates that this
+              component is not contained in any other component.
+
+              In the event that a physical component is contained by
+              more than one physical component (e.g., double-wide
+              modules), this node contains the name of one of these
+              components.  An implementation MUST use the same name
+              every time this node is instantiated.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) -
+                        entPhysicalContainedIn";
+         }
+
+         leaf parent-rel-pos {
+           type int32 {
+             range "0 .. 2147483647";
+           }
+           status deprecated;
+           description
+             "An indication of the relative position of this child
+              component among all its sibling components.  Sibling
+              components are defined as components that:
+
+                o share the same value of the 'parent' node and
+
+                o share a common base identity for the 'class' node.
+
+              Note that the last rule gives implementations flexibility
+              in how components are numbered.  For example, some
+              implementations might have a single number series for all
+              components derived from 'ianahw:port', while some others
+              might have different number series for different
+              components with identities derived from 'ianahw:port' (for
+              example, one for RJ45 and one for SFP).";
+
+           reference
+             "RFC 6933: Entity MIB (Version 4) -
+                        entPhysicalParentRelPos";
+         }
+
+         leaf-list contains-child {
+           type leafref {
+             path "../../component/name";
+           }
+
+
+
+Bierman, et al.              Standards Track                   [Page 48]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           status deprecated;
+           description
+             "The name of the contained component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalChildIndex";
+         }
+
+         leaf hardware-rev {
+           type string;
+           status deprecated;
+           description
+             "The vendor-specific hardware revision string for the
+              component.  The preferred value is the hardware revision
+              identifier actually printed on the component itself (if
+              present).";
+           reference
+             "RFC 6933: Entity MIB (Version 4) -
+                        entPhysicalHardwareRev";
+         }
+
+         leaf firmware-rev {
+           type string;
+           status deprecated;
+           description
+             "The vendor-specific firmware revision string for the
+              component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) -
+                        entPhysicalFirmwareRev";
+         }
+
+         leaf software-rev {
+           type string;
+           status deprecated;
+           description
+             "The vendor-specific software revision string for the
+              component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) -
+                        entPhysicalSoftwareRev";
+         }
+
+         leaf serial-num {
+           type string;
+           status deprecated;
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 49]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           description
+             "The vendor-specific serial number string for the
+              component.  The preferred value is the serial number
+              string actually printed on the component itself (if
+              present).";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalSerialNum";
+         }
+
+         leaf mfg-name {
+           type string;
+           status deprecated;
+           description
+             "The name of the manufacturer of this physical component.
+              The preferred value is the manufacturer name string
+              actually printed on the component itself (if present).
+
+              Note that comparisons between instances of the
+              'model-name', 'firmware-rev', 'software-rev', and
+              'serial-num' nodes are only meaningful amongst components
+              with the same value of 'mfg-name'.
+
+              If the manufacturer name string associated with the
+              physical component is unknown to the server, then this
+              node is not instantiated.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalMfgName";
+         }
+
+         leaf model-name {
+           type string;
+           status deprecated;
+           description
+             "The vendor-specific model name identifier string
+              associated with this physical component.  The preferred
+              value is the customer-visible part number, which may be
+              printed on the component itself.
+
+              If the model name string associated with the physical
+              component is unknown to the server, then this node is not
+              instantiated.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalModelName";
+         }
+
+         leaf alias {
+           type string;
+           status deprecated;
+
+
+
+Bierman, et al.              Standards Track                   [Page 50]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           description
+             "An 'alias' name for the component, as specified by a
+              network manager, that provides a non-volatile 'handle' for
+              the component.
+
+              If no configured value exists, the server MAY set the
+              value of this node to a locally unique value in the
+              operational state.
+
+              A server implementation MAY map this leaf to the
+              entPhysicalAlias MIB object.  Such an implementation needs
+              to use some mechanism to handle the differences in size
+              and characters allowed between this leaf and
+              entPhysicalAlias.  The definition of such a mechanism is
+              outside the scope of this document.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalAlias";
+         }
+
+         leaf asset-id {
+           type string;
+           status deprecated;
+           description
+             "This node is a user-assigned asset tracking identifier for
+              the component.
+
+              A server implementation MAY map this leaf to the
+              entPhysicalAssetID MIB object.  Such an implementation
+              needs to use some mechanism to handle the differences in
+              size and characters allowed between this leaf and
+              entPhysicalAssetID.  The definition of such a mechanism is
+              outside the scope of this document.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalAssetID";
+         }
+
+         leaf is-fru {
+           type boolean;
+           status deprecated;
+           description
+             "This node indicates whether or not this component is
+              considered a 'field-replaceable unit' by the vendor.  If
+              this node contains the value 'true', then this component
+              identifies a field-replaceable unit.  For all components
+              that are permanently contained within a field-replaceable
+              unit, the value 'false' should be returned for this
+              node.";
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 51]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalIsFRU";
+         }
+
+         leaf mfg-date {
+           type yang:date-and-time;
+           status deprecated;
+           description
+             "The date of manufacturing of the managed component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalMfgDate";
+         }
+
+         leaf-list uri {
+           type inet:uri;
+           status deprecated;
+           description
+             "This node contains identification information about the
+              component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalUris";
+         }
+
+         leaf uuid {
+           type yang:uuid;
+           status deprecated;
+           description
+             "A Universally Unique Identifier of the component.";
+           reference
+             "RFC 6933: Entity MIB (Version 4) - entPhysicalUUID";
+         }
+
+         container state {
+           if-feature hardware-state;
+           status deprecated;
+           description
+             "State-related nodes";
+           reference
+             "RFC 4268: Entity State MIB";
+
+           leaf state-last-changed {
+             type yang:date-and-time;
+             status deprecated;
+             description
+               "The date and time when the value of any of the
+                admin-state, oper-state, usage-state, alarm-state, or
+                standby-state changed for this component.
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 52]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+                If there has been no change since the last
+                re-initialization of the local system, this node
+                contains the date and time of local system
+                initialization.  If there has been no change since the
+                component was added to the local system, this node
+                contains the date and time of the insertion.";
+             reference
+               "RFC 4268: Entity State MIB - entStateLastChanged";
+           }
+
+           leaf admin-state {
+             type hw:admin-state;
+             status deprecated;
+             description
+               "The administrative state for this component.
+
+                This node refers to a component's administrative
+                permission to service both other components within its
+                containment hierarchy as well as other users of its
+                services defined by means outside the scope of this
+                module.
+
+                Some components exhibit only a subset of the remaining
+                administrative state values.  Some components cannot be
+                locked; hence, this node exhibits only the 'unlocked'
+                state.  Other components cannot be shut down gracefully;
+                hence, this node does not exhibit the 'shutting-down'
+                state.";
+             reference
+               "RFC 4268: Entity State MIB - entStateAdmin";
+           }
+
+           leaf oper-state {
+             type hw:oper-state;
+             status deprecated;
+             description
+               "The operational state for this component.
+
+                Note that this node does not follow the administrative
+                state.  An administrative state of 'down' does not
+                predict an operational state of 'disabled'.
+
+                Note that some implementations may not be able to
+                accurately report oper-state while the admin-state node
+                has a value other than 'unlocked'.  In these cases, this
+                node MUST have a value of 'unknown'.";
+             reference
+               "RFC 4268: Entity State MIB - entStateOper";
+
+
+
+Bierman, et al.              Standards Track                   [Page 53]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           }
+
+           leaf usage-state {
+             type hw:usage-state;
+             status deprecated;
+             description
+               "The usage state for this component.
+
+                This node refers to a component's ability to service
+                more components in a containment hierarchy.
+
+                Some components will exhibit only a subset of the usage
+                state values.  Components that are unable to ever
+                service any components within a containment hierarchy
+                will always have a usage state of 'busy'.  In some
+                cases, a component will be able to support only one
+                other component within its containment hierarchy and
+                will therefore only exhibit values of 'idle' and
+                'busy'.";
+             reference
+               "RFC 4268: Entity State MIB - entStateUsage";
+           }
+
+           leaf alarm-state {
+             type hw:alarm-state;
+             status deprecated;
+             description
+               "The alarm state for this component.  It does not
+                include the alarms raised on child components within its
+                containment hierarchy.";
+             reference
+               "RFC 4268: Entity State MIB - entStateAlarm";
+           }
+
+           leaf standby-state {
+             type hw:standby-state;
+             status deprecated;
+             description
+               "The standby state for this component.
+
+                Some components will exhibit only a subset of the
+                remaining standby state values.  If this component
+                cannot operate in a standby role, the value of this node
+                will always be 'providing-service'.";
+             reference
+               "RFC 4268: Entity State MIB - entStateStandby";
+           }
+         }
+
+
+
+Bierman, et al.              Standards Track                   [Page 54]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         container sensor-data {
+           when 'derived-from-or-self(../class,
+                                      "ianahw:sensor")' {
+             description
+               "Sensor data nodes present for any component of type
+                'sensor'";
+           }
+           if-feature hardware-sensor;
+           status deprecated;
+
+           description
+             "Sensor-related nodes.";
+           reference
+             "RFC 3433: Entity Sensor Management Information Base";
+
+           leaf value {
+             type hw:sensor-value;
+             status deprecated;
+             description
+               "The most recent measurement obtained by the server
+                for this sensor.
+
+                A client that periodically fetches this node should also
+                fetch the nodes 'value-type', 'value-scale', and
+                'value-precision', since they may change when the value
+                is changed.";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorValue";
+           }
+
+           leaf value-type {
+             type hw:sensor-value-type;
+             status deprecated;
+             description
+               "The type of data units associated with the
+                sensor value";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorType";
+           }
+
+           leaf value-scale {
+             type hw:sensor-value-scale;
+             status deprecated;
+             description
+               "The (power of 10) scaling factor associated
+                with the sensor value";
+
+
+
+Bierman, et al.              Standards Track                   [Page 55]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorScale";
+           }
+
+           leaf value-precision {
+             type hw:sensor-value-precision;
+             status deprecated;
+             description
+               "The number of decimal places of precision
+                associated with the sensor value";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorPrecision";
+           }
+
+           leaf oper-status {
+             type hw:sensor-status;
+             status deprecated;
+             description
+               "The operational status of the sensor.";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorOperStatus";
+           }
+
+           leaf units-display {
+             type string;
+             status deprecated;
+             description
+               "A textual description of the data units that should be
+                used in the display of the sensor value.";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorUnitsDisplay";
+           }
+
+           leaf value-timestamp {
+             type yang:date-and-time;
+             status deprecated;
+             description
+               "The time the status and/or value of this sensor was last
+                obtained by the server.";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorValueTimeStamp";
+           }
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 56]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+           leaf value-update-rate {
+             type uint32;
+             units "milliseconds";
+             status deprecated;
+             description
+               "An indication of the frequency that the server updates
+                the associated 'value' node, represented in
+                milliseconds.  The value zero indicates:
+
+                 - the sensor value is updated on demand (e.g.,
+                   when polled by the server for a get-request),
+
+                 - the sensor value is updated when the sensor
+                   value changes (event-driven), or
+
+                 - the server does not know the update rate.";
+             reference
+               "RFC 3433: Entity Sensor Management Information Base -
+                          entPhySensorValueUpdateRate";
+           }
+         }
+       }
+     }
+
+     /*
+      * Notifications
+      */
+
+     notification hardware-state-change {
+       status deprecated;
+       description
+         "A hardware-state-change notification is generated when the
+          value of /hardware/last-change changes in the operational
+          state.";
+       reference
+         "RFC 6933: Entity MIB (Version 4) - entConfigChange";
+     }
+
+     notification hardware-state-oper-enabled {
+       if-feature hardware-state;
+       status deprecated;
+       description
+         "A hardware-state-oper-enabled notification signifies that a
+          component has transitioned into the 'enabled' state.";
+
+       leaf name {
+         type leafref {
+           path "/hardware/component/name";
+
+
+
+Bierman, et al.              Standards Track                   [Page 57]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         }
+         status deprecated;
+         description
+           "The name of the component that has transitioned into the
+            'enabled' state.";
+       }
+       leaf admin-state {
+         type leafref {
+           path "/hardware/component/state/admin-state";
+         }
+         status deprecated;
+         description
+           "The administrative state for the component.";
+       }
+       leaf alarm-state {
+         type leafref {
+           path "/hardware/component/state/alarm-state";
+         }
+         status deprecated;
+         description
+           "The alarm state for the component.";
+       }
+       reference
+         "RFC 4268: Entity State MIB - entStateOperEnabled";
+     }
+
+     notification hardware-state-oper-disabled {
+       if-feature hardware-state;
+       status deprecated;
+       description
+         "A hardware-state-oper-disabled notification signifies that a
+          component has transitioned into the 'disabled' state.";
+
+       leaf name {
+         type leafref {
+           path "/hardware/component/name";
+         }
+         status deprecated;
+         description
+           "The name of the component that has transitioned into the
+            'disabled' state.";
+       }
+       leaf admin-state {
+         type leafref {
+           path "/hardware/component/state/admin-state";
+         }
+         status deprecated;
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 58]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+         description
+           "The administrative state for the component.";
+       }
+       leaf alarm-state {
+         type leafref {
+           path "/hardware/component/state/alarm-state";
+         }
+         status deprecated;
+         description
+           "The alarm state for the component.";
+       }
+       reference
+         "RFC 4268: Entity State MIB - entStateOperDisabled";
+     }
+
+   }
+
+   <CODE ENDS>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 59]
+
+RFC 8348                YANG Hardware Management              March 2018
+
+
+Acknowledgments
+
+   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, and Juergen Schoenwaelder.
+
+Authors' Addresses
+
+   Andy Bierman
+   YumaWorks
+
+   Email: andy@yumaworks.com
+
+
+   Martin Bjorklund
+   Tail-f Systems
+
+   Email: mbj@tail-f.com
+
+
+   Jie Dong
+   Huawei Technologies
+
+   Email: jie.dong@huawei.com
+
+
+   Dan Romascanu
+
+   Email: dromasca@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.              Standards Track                   [Page 60]
+