Marisol <[email protected]> writes:
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.
Adding a leaf is not a breaking change, and that fact was part of my saying you could easily add it later; however,
Also with regards to the use cases, I need to disagree on your opinion:
It sounds like you have a use case that people are trying to solve today. Further you indicate exact percentages are required, so it sounds like you need the data.
That said, for generating a report about actual power use I can't imagine why
the operator wouldn't just measure their actual room/building level power use,
something vastly simpler and more accurate than trying to build it from
measurements and estimates from the components all the way up using this YANG
model. :)
Thanks,
Chris.
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]
