Proper structure for defining transponders and 3R regenerators

[aguoietf]

Currently the following structure is used for defining starting, terminating and 3R regenerator transponders:

    +--rw path-in-transceiver
    |  +--rw transponder-id?   uint32
    |  +--rw transceivers* [lane-id]
    |     +--rw lane-id                       uint8
    |     +--rw transceiver-id?               uint32
    |     +--rw operational-modes*            string
    |     +--rw tx-tune-constraints
    |     |  +--rw min-central-frequency?    frequency-thz
    |     |  +--rw max-central-frequency?    frequency-thz
    |     |  +--rw transceiver-tunability?   frequency-ghz
    |     +--rw line-coding-bitrate*          identityref
    |     +--rw tx-channel-power?             l0-types:power-dbm
    |     +--rw preferred-rx-channel-power?   l0-types:power-dbm
    +--rw path-out-transceiver
       +--rw transponder-id?   uint32
       +--rw transceivers* [lane-id]
          +--rw lane-id                       uint8
          +--rw transceiver-id?               uint32
          +--rw operational-modes*            string
          +--rw tx-tune-constraints
          |  +--rw min-central-frequency?    frequency-thz
          |  +--rw max-central-frequency?    frequency-thz
          |  +--rw transceiver-tunability?   frequency-ghz
          +--rw line-coding-bitrate*          identityref
          +--rw tx-channel-power?             l0-types:power-dbm
          +--rw preferred-rx-channel-power?   l0-types:power-dbm

Italo's concern:

• whether we need a new hop type for the 3R function where to put this information
• should the container be named 'path-in-transponder' and 'path-out-transponder'?
• how to provide constraints on the transponders at the ingress/egress of the tunnel?

We need to look into use cases to check if the above constructs still stand for describing the ERO and RROs for WDM tunnel.