Summary

  • RFC 9547 is a report on an IAB workshop, not a carbon-accounting standard or deployment certificate. It records 26 accepted position papers and 73 participants while explicitly declining to turn every discussion into IAB or IETF consensus.
  • The report identifies real measurement problems: energy is not carbon, offered load may not be energy-proportional, vendor metrics can conflict, and a local optimization can move impact elsewhere.
  • A defensible reduction claim still needs an executable change, adoption scope, service denominator, energy and carbon factors, lifecycle boundary, counterfactual, rebound analysis and an absolute outcome with uncertainty.

A workshop can count submissions, sessions and participants more readily than it can close a carbon ledger. RFC 9547 does the first task carefully. It says the IAB's December 2022 online workshop accepted 26 position papers and involved 73 people in at least one session. It links the papers, recordings and meeting material. It also states the limit that turns those facts into useful evidence: this is a report of proceedings; participant views do not necessarily represent the IAB or IETF, and the report did not try to find consensus on every subject.

That caveat is not institutional modesty around the edges. It defines the document. RFC 9547 can prove that a question entered a durable public record, that particular mechanisms were discussed, and that further work had a recognizable community. It cannot prove that operators adopted a common metric, that a proposed protocol change reached production, or that any named intervention reduced absolute emissions.

The missing unit is not the only problem

The workshop recognized that environmental measurement is broader than reading watts from a network device. Manufacturing consumes materials and energy. End-user equipment, access networks, data centres and shared facilities sit inside different administrative boundaries. Purchased electricity carries a carbon intensity that changes by place and time. Packaging, replacement cycles and demand induced by applications can sit outside the operator's neat dashboard while remaining inside the environmental outcome.

Even operational energy resists a universal shortcut. The report discusses energy proportionality: some systems' consumption changes with offered load; others maintain a high baseline. A ten-percent reduction in bytes therefore does not imply a ten-percent reduction in electricity. If fixed cooling, idle chassis or reserved capacity dominates, the meter may barely move. If a workload shifts to another region or endpoint, the local graph can improve while total work remains unchanged.

This is why contradictory vendor metrics matter. A number is not comparable merely because both vendors call it efficiency. One may divide facility energy by delivered traffic; another may report device power at a selected load; a third may convert electricity to carbon with a yearly national average. Their numerators, denominators, allocation rules and grid factors answer different questions.

Telemetry opens the ledger; it does not balance it

RFC 9547 sees metrics, telemetry and management as practical areas for IETF work. That is a credible boundary. A common schema can expose device state, energy use or a protocol choice. Stable names and transport mechanisms can reduce ambiguity between implementations. But telemetry occupies only part of the evidence chain.

An outcome claim begins with a decision receipt: who authorized what change, for which system and period? It then needs the executable input—code, configuration, hardware state, routing policy, workload-placement rule or procurement decision. Adoption must be shown by version, deployment population and evidence that real work traversed the changed path. A service denominator must say what was held constant: delivered traffic, completed transactions, latency, availability, video quality or another useful output.

Only then do the energy and carbon receipts become interpretable. Where was energy measured? How was idle power allocated? Which grid factor, timestamp and geography converted electricity into emissions? Which embodied and upstream effects were included or excluded? What credible counterfactual describes the same workload without the intervention? Did demand rebound, or did computation move to a customer device, another network or another hour?

The final receipt must report an absolute outcome with uncertainty and duration, alongside any intensity improvement. “Less energy per transaction” is valuable, but total emissions can still rise if transaction volume grows faster. “Carbon-aware” placement can be useful, but moving a job is not proof of additional clean generation, avoided fossil production or lower system-wide emissions.

Examples are mechanisms, not verdicts

The workshop considered efficient binary encodings, multicast, routing, sleeping, constrained systems and time- or carbon-aware operation. Each can alter a resource path. None should be promoted from mechanism to universal environmental result.

CBOR may make one representation smaller than JSON, yet the lifecycle result depends on parsers, compute, retries, storage, hardware and demand. Multicast can avoid duplicate delivery on one segment while imposing state or changing behavior elsewhere. A sleep feature matters only if equipment enters the state, stays there long enough, wakes safely and does not displace work. Carbon-aware scheduling needs the provenance and granularity of the signal, as well as the counterfactual grid response. RFC publication does not supply those deployment receipts.

The report is unusually useful because it does not pretend otherwise. It records open questions, possible actions and a bounded IETF role in measurement mechanisms and protocol design. It says no conclusion was reached on how environmental impact should be documented in every new RFC. A follow-on programme and working-group activity prove continued attention, not uniform implementation.

Heng Lu's running-code principle supplies the correct transition rule. A written record belongs to the documentary layer. It becomes executable reality when a named actor changes a real input, adopts it and validates behavior. It becomes an outcome only when the affected system is measured against a credible alternative. The common specification can stay narrow; energy procurement, hardware replacement, workload policy and acceptance remain local decisions. Voluntary adoption is not a defect to conceal with inflated language.

The leadership question is therefore not whether RFC 9547 “solved” sustainable networking. It is whether an organization can preserve the chain from discussion to decision, from decision to running change, and from running change to a result that survives boundary and counterfactual tests.