Default value for pmd-kind-cur

[PrathibaJee]

In wire-interface status , we have an attribute pmd-kind-cur.

pmd-kind-cur is a leafref referencing the /core-model:control-construct/…/wire-interface:supported-pmd-kind-list/wire-interface:pmd-name. This means , the value for pmd-kind-cur will be chosen from the supported-pmd-kind-list.

leaf pmd-kind-cur {
      type leafref {
        path "/core-model:control-construct/core-model:logical-termination-point/core-model:layer-protocol/wire-interface:wire-interface-pac/wire-interface:wire-interface-capability/wire-interface:supported-pmd-kind-list/wire-interface:pmd-name";
        require-instance false;
      }
      config false;
      description
        "Indicates the kind of Physical Medium Dependent (PMD) currently operated at this interface";
    }

grouping pmd-kind {
    leaf pmd-name {
      type string;
      config false;
      description
        "To be chosen from the following list of PMD names according to IEEE 802.3 '10BASE5', 'FOIRL', '10BASE2', '10BROAD36', '10BASE-T', '10BASE-FP', '10BASE-FB', '10BASE-FL', '100BASE-T4', '100BASE-TX', '100BASE-BX10D', '100BASE-BX10U', '100BASE-FX', '100BASE-LX10', '100BASE-T2', '1000BASE-X', '1000BASE-BX10D', '1000BASE-BX10U', '1000BASE-LX', '1000BASE-LX10', '1000BASE-SX', '1000BASE-CX', '1000BASE-KX', '1000BASE-T', '10GBASE-X', '10GBASE-LX4', '10GBASE-KX4', '10GBASE-R', '10GBASE-ER', '10GBASE-LR', '10GBASE-SR', '10GBASE-LRM', '10GBASE-KR', '10GBASE-T', '10GBASE-PR-D1', '10GBASE-PR-D2', '10GBASE-PR-D3', '10GBASE-PR-D4', '10GBASE-PR-U1', '10GBASE-PR-U2', '10GBASE-PR-U3', '10GBASE-PR-U4', '40GBASE-R', '40GBASE-KR4', '40GBASE-CR4', '40GBASE-SR4', '4x10GBASE-SR', '40GBASE-LR4', '40GBASE-ER4', '40GBASE-FR', '100GBASE-R', '100GBASE-CR4', '100GBASE-KR4', '100GBASE-KP4', '100GBASE-CR10', '100GBASE-SR4', '100GBASE-SR10', '2x40GBASE-SR', '10x10GBASE-SR', '12x10GBASE-SR', '100GBASE-LR4', '100GBASE-ER4' and 'NOT_YET_DEFINED'. Some PMDs are distinguishing Full Duplex and Half Duplex. '_FD' and '_HD' are to be attached to the respective PMD name accordingly.";
    }
    leaf speed {
      type string;
      default "NOT_YET_DEFINED";
      description
        "Line speed of the PMD. Value to be chosen from '2Mbit/s', '10Mbit/s', '100Mbit/s', '1000Mbit/s', '10Gbit/s', '40Gbit/s', '100Gbit/s' or 'NOT_YET_DEFINED'. This field is not for calculation purposes, but for supporting selection of the correct PMD on application layer.";
    }
    leaf duplex {
      type duplex-type;
      default "DUPLEX_TYPE_NOT_YET_DEFINED";
      description
        "To be expressed, whether the PMD is full duplex or just half duplex. This field is not for configuration purposes, but for supporting selection of the correct PMD on application layer.";
    }
    description
      "none";
  }

Queries : Query#1 : If a device doesn’t able to provide a value for the attribute pmd-kind-cur(lets say if the interface status is down) , then the device cannot be able to define a value for this attribute. In this case , whether

1. pmd-kind-cur should be 'NOT_YET_DEFINED' ?
2. pmd-kind-cur should be “” empty string ?
3. should not display the attribute itself ?

Query#2 : Pmd-kind/Pmd-name can hold values as per the description or it can hold any values ? (Apart from attaching _FD and _HD)

[PrathibaJee]

Discussion made on 5G-XHaul call on 6th of July 2022 :

For query#1 : If a device doesn’t able to provide a value for the attribute pmd-kind-cur (lets say if the interface status is down) , then the management interface cannot be able to define a value for this attribute.

In this case , whether

1. pmd-kind-cur should be 'NOT_YET_DEFINED' ?
2. pmd-kind-cur should be “” empty string ?
3. should not display the attribute itself ?

Since already we have a value 'NOT_YET_DEFINED' defined in the description of the attribute pmd-name.

• 'NOT_YET_DEFINED' should be listed in the supported-pmd-kind-list/pmd-name.
• pmd-kind-cur should refer the 'NOT_YET_DEFINED' pmd-name.

Options 2 and 3 don't suit for this scenario.

[openBackhaul]

Decision for Query#2 on the 5G-xhaul call on 10th of August 2022: Comment shall be complemented by the following statement: "If IEEE 802.3 would publish new PMD specifications, the vendor could also chose representing the official names of the new PMD according to IEEE STD 802.3 or its amendments.".

[openBackhaul]

Superseded by decision in issue #46