module openconfig-platform {

    yang-version 1;

    namespace
      "http://openconfig.net/yang/platform";

    prefix oc-platform;

    import openconfig-platform-types {
      prefix oc-platform-types;
    }
    import openconfig-extensions {
      prefix oc-ext;
    }
    import openconfig-alarm-types {
      prefix oc-alarm-types;
    }
    import openconfig-yang-types {
      prefix oc-yang;
    }
    import openconfig-types {
      prefix oc-types;
    }

    include openconfig-platform-common;

    organization "OpenConfig working group";

    contact
      "OpenConfig working group
www.openconfig.net";

    description
      "This module defines a data model for representing a system
component inventory, which can include hardware or software
elements arranged in an arbitrary structure. The primary
relationship supported by the model is containment, e.g.,
components containing subcomponents.

It is expected that this model reflects every field replacable
unit on the device at a minimum (i.e., additional information
may be supplied about non-replacable components).

Every element in the inventory is termed a 'component' with each
component expected to have a unique name and type, and optionally
a unique system-assigned identifier and FRU number.  The
uniqueness is guaranteed by the system within the device.

Components may have properties defined by the system that are
modeled as a list of key-value pairs. These may or may not be
user-configurable.  The model provides a flag for the system
to optionally indicate which properties are user configurable.

Each component also has a list of 'subcomponents' which are
references to other components. Appearance in a list of
subcomponents indicates a containment relationship as described
above.  For example, a linecard component may have a list of
references to port components that reside on the linecard.

This schema is generic to allow devices to express their own
platform-specific structure.  It may be augmented by additional
component type-specific schemas that provide a common structure
for well-known component types.  In these cases, the system is
expected to populate the common component schema, and may
optionally also represent the component and its properties in the
generic structure.

The properties for each component may include dynamic values,
e.g., in the 'state' part of the schema.  For example, a CPU
component may report its utilization, temperature, or other
physical properties.  The intent is to capture all platform-
specific physical data in one location, including inventory
(presence or absence of a component) and state (physical
attributes or status).";

    revision "2022-12-19" {
      description
        "Update last-high-watermark timestamp documentation.";
      reference
        "0.21.1";

    }

    revision "2022-09-26" {
      description
        "Add state data for base-mac-address.";
      reference
        "0.21.0";

    }

    revision "2022-08-31" {
      description
        "Add new state data for component CLEI code.";
      reference
        "0.20.0";

    }

    revision "2022-07-28" {
      description
        "Add container for controller card component";
      reference
        "0.19.0";

    }

    revision "2022-07-11" {
      description "Add switchover ready";
      reference
        "0.18.0";

    }

    revision "2022-06-10" {
      description
        "Specify units and epoch for switchover and reboot times.";
      reference
        "0.17.0";

    }

    revision "2022-04-21" {
      description
        "Add platform utilization.";
      reference
        "0.16.0";

    }

    revision "2022-02-02" {
      description
        "Add new state data for component reboot and
switchover.";
      reference
        "0.15.0";

    }

    revision "2021-08-13" {
      description
        "Add container for PCIe error statistics";
      reference
        "0.14.0";

    }

    revision "2021-01-18" {
      description
        "Add container for software module component";
      reference
        "0.13.0";

    }

    revision "2019-04-16" {
      description
        "Fix bug in parent path reference";
      reference
        "0.12.2";

    }

    revision "2018-11-21" {
      description
        "Add OpenConfig module metadata extensions.";
      reference
        "0.12.1";

    }

    revision "2018-06-29" {
      description
        "Added location description for components";
      reference
        "0.12.0";

    }

    revision "2018-06-03" {
      description
        "Added parent reference, empty flag and preconfiguration
for components";
      reference
        "0.11.0";

    }

    revision "2018-04-20" {
      description
        "Added new per-component state data: mfg-date and removable";
      reference
        "0.10.0";

    }

    revision "2018-01-30" {
      description
        "Amended approach for modelling CPU - rather than having
a local CPU utilisation state variable, a component with
a CPU should create a subcomponent of type CPU to report
statistics.";
      reference
        "0.9.0";

    }

    revision "2018-01-16" {
      description
        "Added new per-component common data; add temp alarm;
moved hardware-port reference to port model";
      reference
        "0.8.0";

    }

    revision "2017-12-14" {
      description
        "Added anchor containers for component data, added new
component types";
      reference
        "0.7.0";

    }

    revision "2017-08-16" {
      description
        "Added power state enumerated type";
      reference
        "0.6.0";

    }

    revision "2016-12-22" {
      description
        "Added temperature state variable to component";
      reference
        "0.5.0";

    }

    oc-ext:openconfig-version "0.21.1";
    oc-ext:regexp-posix;
    oc-ext:catalog-organization "openconfig";
    oc-ext:origin "openconfig";
  }  // module openconfig-platform