module openconfig-platform-transceiver {

    yang-version 1;

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

    prefix oc-transceiver;

    import ietf-yang-types {
      prefix yang;
    }
    import openconfig-platform {
      prefix oc-platform;
    }
    import openconfig-platform-types {
      prefix oc-platform-types;
    }
    import openconfig-platform-port {
      prefix oc-port;
    }
    import openconfig-interfaces {
      prefix oc-if;
    }
    import openconfig-transport-types {
      prefix oc-opt-types;
    }
    import openconfig-types {
      prefix oc-types;
    }
    import openconfig-extensions {
      prefix oc-ext;
    }
    import openconfig-yang-types {
      prefix oc-yang;
    }
    import openconfig-alarm-types {
      prefix oc-alarm-types;
    }

    organization "OpenConfig working group";

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

    description
      "This module defines configuration and operational state data
    for transceivers (i.e., pluggable optics).  The module should be
    used in conjunction with the platform model where other
    physical entity data are represented.

    In the platform model, a component of type=TRANSCEIVER is
    expected to be a subcomponent of a PORT component.  This
    module defines a concrete schema for the associated data for
    components with type=TRANSCEIVER.

    A transceiver will always contain physical-channel(s), however
    when a line side optical-channel is present (i.e. ZR+ optics)
    the physical-channel will reference its optical-channel.
    In this case, the optical-channels components must be
    subcomponents of the transceiver. The relationship between the
    physical-channel and the optical-channel allows for multiple
    optical-channels to be associated with a transceiver in addition
    to ensuring certain leaves (i.e. output-power) are not duplicated
    in multiple components.

    If a transceiver contains a digital signal processor (DSP), such
    as with ZR+ optics, the modeling will utilize hierarchical
    components as follows:
    PORT --> TRANSCEIVER --> OPTICAL_CHANNEL(s)
    The signal will then traverse through a series of
    terminal-device/logical-channels as required. The first
    logical-channel connected to the OPTICAL_CHANNEL will utilize the
    assignment/optical-channel leaf to create the relationship. At the
    conclusion of the series of logical-channels, the logical-channel
    will be associated to its host / client side based on:
    * If the TRANSCEIVER is directly within a router or switch, then
      it will use the logical-channel ingress leaf to specify the
      interface it is associated with.
    * If the TRANSCEIVER is within a dedicated terminal (Layer 1)
      device, then it will use the logical-channel ingress leaf to
      specify a physical-channel within a TRANSCEIVER component
      (i.e. gray optic) that it is associated with.";

    revision "2023-08-30" {
      description
        "Clarify transceiver module threshold for input-power.";
      reference
        "0.14.0";

    }

    revision "2023-08-30" {
      description
        "Add transceiver module temperature thresholds";
      reference
        "0.13.0";

    }

    revision "2023-06-27" {
      description
        "Add tx bias and voltage thresholds";
      reference
        "0.12.0";

    }

    revision "2023-05-03" {
      description
        "Increase max length of vendor-rev to 4.";
      reference
        "0.11.0";

    }

    revision "2023-02-10" {
      description "Fixing linting issues.";
      reference
        "0.10.1";

    }

    revision "2023-01-12" {
      description
        "Add laser power and temperature thresholds";
      reference
        "0.10.0";

    }

    revision "2021-07-29" {
      description
        "Add several media-lane-based VDM defined by CMIS to physical channel";
      reference
        "0.9.0";

    }

    revision "2021-02-23" {
      description
        "Add leafref to an optical channel from a physical channel.";
      reference
        "0.8.0";

    }

    revision "2020-05-06" {
      description
        "Ensure that when statements in read-write contexts reference
      only read-write leaves.";
      reference
        "0.7.1";

    }

    revision "2018-11-25" {
      description
        "Add augment for leafref to transceiver component;
      Correct paths in physical channels leafref.";
      reference
        "0.7.0";

    }

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

    }

    revision "2018-11-16" {
      description
        "Added transceiver FEC configuration and state";
      reference
        "0.6.0";

    }

    revision "2018-05-15" {
      description
        "Remove internal-temp state leaf, since we prefer
      the generic /components/component/state/temperature
      container for temperature information.";
      reference
        "0.5.0";

    }

    revision "2018-01-22" {
      description
        "Fixed physical-channel path reference";
      reference
        "0.4.1";

    }

    revision "2017-09-18" {
      description
        "Use openconfig-yang-types module";
      reference
        "0.4.0";

    }

    revision "2017-07-08" {
      description
        "Adds clarification on aggregate power measurement data";
      reference
        "0.3.0";

    }

    revision "2016-12-22" {
      description
        "Adds preconfiguration data and clarified units";
      reference
        "0.2.0";

    }

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