[Lsr] Re: GREEN: Data Accuracy [Re: Re: Adoption of draft-many-lsr-power-group]

[Christian Hopps <[e-mail]>]

Marisol <[e-mail]> 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 <[e-mail]> wrote:
>
>     Marisol <[e-mail]> 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