Change name for power-in-db data types

[italobusi]

I agree with Julien, the associated l0-types name should be modified

power-in-db         --> ratio-in-db
power-in-db-or-null --> ratio-in-db-or-null

Regarding the missing descriptions, I propose the following. My assumption is that the EDFA is schematically a sequence like this: in-voa | gain stage | out-voa. and the actual gain reports the gain of the gain stage (thus the VOAs are excluded). Does everyone agree?

leaf actual-gain {
type l0-types:power-in-db-or-null;
mandatory true ;
description "The value of the gain Provided by the amplification stage of the optical amplifier.";
}

leaf out-voa {
type l0-types:power-in-db-or-null;
mandatory true;
description "Loss introduced by the Variable Optical Attenuator at the output of the amplification stage of the amplifier, if present. "
}

leaf in-voa {
type l0-types:power-in-db-or-null;
mandatory true;
description "Loss introduced by the Variable Optical Attenuator at the input of the amplification stage of the amplifier., if present.";
}

grouping concentratedloss-params {
description "concentrated loss";
container concentratedloss{
description "concentrated loss";
leaf loss {
type l0-types:power-in-db-or-null;
mandatory true;
description "Loss introduced by the concentrated loss element.";
}
}

Originally posted by @egriseri in https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/141#issuecomment-1614807658

[dieterbeller]

I would prefer:

• a typedef amplifier-gain-in-db-or-null
• a typedef attenuation-in-db-or-null

[EstherLerouzic]

I agree that the Gain should not account for in VOA or out VOA. For the naming of the typedef separating the cases also makes sense but I have no strong opinion though. it must only be clear that the values MUST be positive or zero: there can not be a negative attenuation or a negative gain.

[sergiobelotti]

I like personally to make more explicit in naming in typedef as proposed by Dieter. The proposal could be:

typedef amplifier-gain-in-db { type decimal-2-digits; units "dB"; description "The positive power gain in dB."; } typedef amplifier-gain-in-db-or-null { type union { type amplifier-gain-in-db ; type empty; } description "The positive power gain in dB, when it is known or an empty value when the power gain is not known."; }

typedef attenuation-in-db { type decimal-2-digits; units "dB"; description "The power attenuation in dB."; } typedef attenuation-in-db-or-null { type union { type attenuation-in-db ; type empty; } description "The power attenuation in dB, when it is known or an empty value when the power attenuation is not known."; }

[italobusi]

A range statement would be useful to ensure that the values are positive or zero:

typedef amplifier-gain-in-db {
    type decimal-2-digits {
      range "0..max";
    }
    units "dB";
    description
      "The positive power gain in dB.";
  }
typedef amplifier-gain-in-db-or-null {
      type union {
         type amplifier-gain-in-db  ;
         type empty;
    }
    description
      "The positive power gain in dB, when it is known or an empty 
      value when the power gain is not known.";
  }

 typedef attenuation-in-db {
    type decimal-2-digits {
      range "0..max";
    }
    units "dB";
    description
      "The  power attenuation in dB.";
  }
typedef attenuation-in-db-or-null {
      type union {
         type attenuation-in-db  ;
         type empty;
    }
    description
      "The power attenuation in dB, when it is known or an empty 
      value when the power attenuation is not known.";
  }  

Few additional comments:

1. What about making all the types more generic such as:
   • power-gain-in-db
   • power-gain-in-db-or-null
   • power-loss-in-db (or power-attenuation-in-db)
   • power-loss-in-db-or-null (or power-attenuation-in-db-or-null)
2. Given that there are no different measurements units, we may also consider removing the measurement units from the data type names:
   • power-gain
   • power-gain-or-null
   • power-loss (or power-attenuation)
   • power-loss-or-null (or power-attenuation-or-null)
   • power (instead of power-in-dbm)
   • power-or-null (instead of power-in-dbm-or-null)

[sergiobelotti]

A range statement would be useful to ensure that the values are positive or zero:

Correct. I was just considering to put the constraint just in the description , but the range assure YANG check.

typedef amplifier-gain-in-db {
    type decimal-2-digits {
      range "0..max";
    }
    units "dB";
    description
      "The positive power gain in dB.";
  }
typedef amplifier-gain-in-db-or-null {
      type union {
         type amplifier-gain-in-db  ;
         type empty;
    }
    description
      "The positive power gain in dB, when it is known or an empty 
      value when the power gain is not known.";
  }

 typedef attenuation-in-db {
    type decimal-2-digits {
      range "0..max";
    }
    units "dB";
    description
      "The  power attenuation in dB.";
  }
typedef attenuation-in-db-or-null {
      type union {
         type attenuation-in-db  ;
         type empty;
    }
    description
      "The power attenuation in dB, when it is known or an empty 
      value when the power attenuation is not known.";
  }  

Few additional comments:

1. What about making all the types more generic such as:

   • power-gain-in-db
   • power-gain-in-db-or-null
   • power-loss-in-db (or power-attenuation-in-db)
   • power-loss-in-db-or-null (or power-attenuation-in-db-or-null)
2. Given that there are no different measurements units, we may also consider removing the measurement units from the data type names:

Weekly call 07-04-23:

• power-gain gain-in-db gain-in-db-or-null
• power-loss (or power-attenuation) loss-in-db
• power-loss-or-null (or power-attenuation-or-null) loss-in-db-or-null