Thanks Chris, You are absolutely right that building or room-level power measurement is simpler and more accurate for generating a report.
What GREEN is chartered to do is energy management at the component, device, and network level, specifically "optimizing energy efficiency across the network via configurable energy efficiency capabilities." That is a real-time control problem, not just a reporting problem, and it is where the accuracy signal becomes operationally necessary. A controller making live decisions: whether to power down a line card, consolidate traffic onto fewer chassis, or wake a sleeping interface, is consuming component-level power values from the YANG model and acting on them. If the value it is reading is a sensor measurement, the decision is grounded in reality. If the value is a nominal figure from a 2019 datasheet, the controller may be acting on stale or incorrect data, potentially making the network less efficient or less reliable. There is no building-level meter that can resolve that ambiguity at component granularity. This is why the accuracy signal belongs in the model: not for reporting, but to give the controller the minimum context it needs to decide how much to trust the data it is acting on. The simplified boolean that you suggested, estimated (true or false) might be that minimum signal. I take your point that adding a leaf later is not a breaking change, and I appreciate that. My concern is that deploying controllers against a model that mixes sensor data with datasheet estimates creates an operational problem that is hard to diagnose after the fact. Getting the signal is "lower cost" than correlating anomalies in production. Thank you again for the engagement. Best regards, Marisol On Sat, Aug 22, 2026 at 1:18 AM Christian Hopps <[email protected]> wrote: > 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
