components client port transceiver tied to optical transport

[earies]

The client port transceiver hierarchy currently contains verbiage and ties to the optical transport domain

module: openconfig-platform
  +--rw components
     +--rw component* [name]
        +--rw oc-transceiver:transceiver
           +--ro oc-transceiver:state
              +--ro oc-transceiver:form-factor?                 identityref
              +--ro oc-transceiver:connector-type?   identityref

And if we dissect some of this verbiage and identities, this appears that it should be a looser type design to account for non fiber-optic cases. e.g. COPPER/RJ45

The base identity of FIBER_CONNECTOR_TYPE is an example where there is already one such case of including a child identity for DAC_CONNECTOR. If other identities need to be added to extend this, it becomes a slightly unnatural extension at this point.

One consideration could be to create a generic base identity of CONNECTOR_TYPE in openconfig-platform-types and nest the FIBER_CONNECTOR_TYPE identity to base off this new identity and split off the optic domain. From a payload/instance-data perspective we can achieve backwards compatibility with this approach however it is likely some codegen would be affected.

I wanted to raise this issue to discuss possible design patterns prior to issuing a PR

[earies]

@robshakir @dplore - can someone PTAL? thx

[dplore]

It does seem odd that DAC connector is in the optical module as a FIBER_CONNECTOR_TYPE.

Agreed that adding CONNECTOR_TYPE to platform-types as the 'root' sounds ok and adding DAC_CONNECTOR as a child of that is ok.

So do you intend to leave FIBER_CONNECTOR_TYPE in optical-transport?

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.