Hi Chris, Thank you for the feedback, fresh eyes are exactly what the GREEN work needs at this stage, and the KISS critique is fair to engage with directly.
You are right that 'unavailable' is vacuous and should go. We should take that out. Where I would push back gently is on removing the accuracy concept entirely, and here is why: the real problem it solves is not distinguishing between two types of measurement, it is distinguishing between a measured value and a value that was never measured at all under normal operations. All the estimated values are processed under a benchmarking/lab environment, where I would say it is far from ideal. In current deployments, many devices report power figures that come from a database or a manufacturer's datasheet, not from a sensor. The device might not have a PSU power sensor; it just knows "this line card model nominally draws 80W" and reports that. From a YANG leaf perspective it looks identical to a sensor reading: a number in Watts. An operator consuming that value for carbon reporting or energy efficiency decisions has no way to know whether they are looking at a real measurement or a vendor spec from we dont know which year. That is the problem the accuracy signal solves. Without it, the model gives consumers false confidence in the data quality. That said, your KISS point is well taken on the complexity of the current hierarchy (unknown / estimated / measured-bronze / silver / gold). That five-level classification may indeed be premature. A simpler path that preserves the essential signal would be a single boolean leaf: estimated true | false where 'true' means the value is derived from nominal or lookup data, and 'false' (or absent) means it comes from a physical sensor. That is the minimal signal an operator might need to decide whether to trust the number for regulatory reporting. We will be happy to revisit in that direction if the WG agrees the binary distinction is worth keeping. I would rather have that conversation now than discover post-deployment that operators cannot distinguish sensor data from estimates and have to retrofit a breaking model change. Also with regards to the use cases, I need to disagree on your opinion: The accuracy leaf is not premature optimization — it is the *machine-readable signal that enables CSRD/ESRS E1 compliance*. A telecom operator consuming GREEN YANG telemetry for their sustainability report needs to know, for each power value they receive, whether it is primary data (sensor) or secondary data (datasheet estimate), because: 1. ESRS E1 requires them to report the percentage of GHG calculations based on primary vs secondary data 2. Misclassifying estimated values as measured ones is an explicit *assurance risk* under CSRD, auditors should flag it 3. Without the accuracy leaf in GREEN YANG, the operator has no standard way to make that distinction at scale across thousands of network device Similar for ITU L.1450 (December 2025) For ICT specifically, the normative reference is *ITU-T L.1450* (revised December 2025), which defines three assessment tiers: Tier-1 (detailed, ICT-specific primary data, full LCA), Tier-2 (simplified mix of primary and secondary data), Tier-3 (screening using secondary/proxy data) and explicitly states that if primary data are not sufficient secondary or published data must be used as a fallback, and the proportion of each must be reported. Best regards, Marisol On Thu, Aug 20, 2026 at 8:47 PM Christian Hopps <[email protected]> wrote: > Marisol <[email protected]> writes: > > > GREEN WG is considering accuracy and units for power in watts. > > > > leaf data-source-accuracy { > > type identityref { > > base data-source-accuracy; > > } > > default accuracy-like-parent; > > description > > "The accuracy of the power data source. Indicates whether > > the data source is a direct measurement, an estimate, or > > unavailable and also the accuracy level of the data > source. > > By default, the accuracy is inherited from the parent > energy > > object, facilitating hierarchical accuracy definitions > > without the need to specify accuracy at every level. > > This metadata is crucial for network management > > applications to assess the reliability and accuracy of the > > power data."; > > } > > Hi Marisol, GREEN, et al. > > FWIW unfortunately I don't have the time available to get into this > (GREEN) work; however since this crossed my screen due to the LSR adoption > call I have a chance to comment here. > > What I see here, as someone with fresh eyes looking at it, seems like > you've gotten yourself into the weeds as far as over-design and complexity. > Include data in the model if you want people to use it. If you want people > to use an estimate then you include it, otherwise don't. "unavailable" is a > vacuous option, you have no data to include. Direct measurement you just > include. There are no more options left here. > > I suggest you KISS this whole accuracy leaf/concept and get rid of it > making your model data more straight-forward to comprehend and use. > > FWIW, if someday a real user actually needs to have both estimates and > direct measurements and wants to treat them differently, then you add an > estimate value leaf (or flag) to the model; however, currently this seems > like a classic example of over-optimizing a solution before you have proof > there's a problem to solve. Again, suggest you take a look around your > current model and see if it needs to be whacked some more with the KISS > stick. :) > > Thanks, > Chris. > > > > > hth, > > Marisol >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
