We still in process for checking and changing part of the algorithm. Standard behavior shall be : attenuation associated with a span is provided through RESTCONF interface. This is the attenuation stored in a specific database. It is then stored in topology as span loss-base (span-attribute). Then during discovery of the link, the controller calculates the span-loss from PMs (inputPowerNode(N)-outputPowerNode(N-1). Then it populates topology with this calculated value (spanloss-current) and refreshes the value on the ots-interfaces of the device.

I don't fully understand the proposed behavior. When you say "attenuation associated with a span is provided through RESTCONF interface" it sounds like something coming from an external system like the operator's fiber database. I think the engineered-spanloss attribute in the network topology model is meant for such pre-deployment data. In my understanding from the network model whitepaper and descriptions in the YANG files, the spanloss-base attribute should be based on measurement (or calculation based on PMs) during degree turn-up (or link discovery). The spanloss-current attribute should be updated periodically if auto-spanloss is set to true.

You are right. Sorry, we participated to that modeling but it is a bit far away.I made a confusion. The value coming from data base is used to populate engineered-spanloss. Spanloss base is the value that is measured first time the link is discovered. Span-loss current is associated with last measured value.