Re: New Draft: draft-besleaga-green-sustainability-wellknown-00 (Addressing Out-of-Band Environmental Reporting)

Hi,

Thank you for the constructive feedback on the initial 00 proposed
concept. I have published an updated version,
draft-besleaga-green-sustainability-wellknown-01, which incorporates
these suggestions to move the proposal toward a more robust
specification.

Specifically, the new version addresses the following:

Architecture: I outlined the out-of-band .well-known approach to avoid
the "rebound effect" of per-request headers.

Reporting Periods: Added standardized support for quarterly periods
(YYYY-QX) and defined a "Basic" mandatory service level (previous
month aggregate) to ensure a minimum baseline of reporting
consistency.

Methodology Disclosure: Introduced mandatory methodology-type (e.g.,
hardware-metered, cloud-billing) and methodology-uri fields. This
ensures transparency regarding whether data is measured or estimated
(and addressing "greenwashing" concerns).

Array/Trend Support: The payload format and CDDL schema now explicitly
support returning an array of objects. By using the new granularity
parameter, a researcher can request a monthly or quarterly period and
receive a trend of daily "slices" in a single efficient response.

Granularity & Privacy: I agree with the feedback regarding timezone
spread; the draft now normatively recommends a minimum aggregation of
one day (24 hours) to protect against traffic-inference attacks while
remaining useful for researchers.

Expanded Examples: Added explicit examples for the mandatory "No
Parameter" root request and the resource-specific "target" parameter,
with standard and optional extended examples.
The formal CDDL schema has been verified to support both single-object
and array-based responses with scaled units (Wh to GWh).

I look forward to know if these "Basic" and "Extended" capabilities
meet the needs of the working groups.

Link to Draft: https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-wellknown/
Link to GitHub of optional further resources (schema, validation):
https://github.com/andreibesleaga/rfc-sustainability-wellknown


Best regards,
Andrei Besleaga


On Sun, Mar 15, 2026 at 5:11 PM Michael Sweet <msweet@msweet.org> wrote:
>
> Andrei,
>
> Some quick (perhaps uninformed) feedback:
>
> 1. This does seem like a better, more feasible approach (vs. per-response) headers.
> 2. The current query support for reporting periods seems a little underspecified - no minimum aggregate requirements and no standardized range support, and no support for quarterly reporting periods.
> 3. The response JSON could include a pointer (URL) to an "explainer" page or specification so you can know how the values were calculated, i.e., are these measured values or calculated/estimated?
> 4. It would be interesting/more efficient to support returning an array of JSON objects, e.g., daily energy usage for the month of January, vs. just the aggregate values for the reporting period for researchers/planners that are looking for trends.
> 5. There are no examples for the "no parameter" request or the "target" parameter.
>
> I *do* think limiting the granularity to days makes sense since cloud services and clients are usually spread over multiple timezones so overall carbon emissions and energy usage should not vary significantly throughout the day like you might see for more localized services.
>
>
> > On Mar 15, 2026, at 2:54 AM, Andrei Besleaga <andrei.besleaga@ieee.org> wrote:
> >
> > Hi GREEN Working Group,
> > Following discussion regarding the feasibility of per-request carbon accounting, I have published a new significantly revised version of my draft: draft-besleaga-green-sustainability-wellknown-00.
> > As discussed, I have moved away from the per-response header requirement to eliminate protocol overhead and the "rebound effect." This version focuses exclusively on an out-of-band reporting mechanism via the /.well-known/sustainability URI.
> > Key updates in this version include:
> >     • Discovery Model: Historical aggregated sustainability metrics asynchronously (as per RFC 8615).
> >     • Query Parameters: Support for ?target= and ?period= to allow for granular reporting (e.g., specific API endpoints or daily/monthly aggregates) within a flat well-known namespace.
> >     • Standardized Units: Standardized on kWh for energy and gCO2e for carbon metrics to ensure interoperability.
> >     • Formal Schema: Included a CDDL definition to allow for automated parsing and validation of the JSON payload.
> >     • Operational & Security: Added specific considerations for caching, rate-limiting to prevent DoS, and fuzzing to mitigate hardware fingerprinting risks.
> > I believe this approach gives the right balance between environmental transparency and architectural efficiency. I would appreciate feedback on the new schema and proposed registration of the "sustainability" suffix.
> > Link to the draft: https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-wellknown/
> > Best regards,
> > Andrei Besleaga
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 3, 2026 at 11:24 AM Andrei Besleaga <andrei.besleaga@ieee.org> wrote:
> > Hi Mark and Roy,
> > Thanks for taking the time to review the draft and provide such detailed feedback.
> >
> > I see the consensus that per-request accounting is infeasible and that an out-of-band approach via .well-known URIs is preferred for historical/aggregated data.
> > I will revise/change the draft to focus on making the aggregated data discoverable via .well-known and remove the per-response header requirement, except perhaps for a very narrow, measurable metric if one remains viable.
> >
> > Will follow up once I have a new version.
> >
> > Best regards,
> > Andrei
> >
> > On Mon, Mar 2, 2026 at 5:15 AM Roy T. Fielding <fielding@gbiv.com> wrote:
> >> On Feb 27, 2026, at 9:03 AM, Andrei Besleaga <andrei.besleaga@ieee.org> wrote:
> >>
> >> Hello dear members of working group,
> >> I have just submitted a new Internet-Draft proposing the "Sustainability" HTTP response header field.
> >> Draft: https://datatracker.ietf.org/doc/draft-besleaga-green-sustainability-header/
> >> As regulatory frameworks increasingly require transactional traceability for carbon accounting, there is a growing need to stamp a precise environmental cost onto digital transactions.
> >> This draft defines a structured mechanism for servers to report environmental impact metrics (such as Scope 2 and Scope 3 emissions) associated with processing an HTTP request. To ensure high parsing reliability and compatibility with modern HTTP/2 and HTTP/3 header compression (HPACK/QPACK), the header is defined strictly as a Structured Field Dictionary (RFC 8941 / RFC 9651).
> >> I am aware that previous proposals for carbon-emission headers (e.g., draft-martin-http-carbon-emissions-scope-2) faced valid pushback regarding the "rebound effect"—the concern that adding metadata to trillions of HTTP requests could consume more energy than it saves. To address this, the current draft mandates HPACK/QPACK compression, an opt-in behavior using the Prefer header, and proxy aggregation where per-thread calculations are prohibitive.
> >> My primary question for the community is: Does this technical approach successfully solve the rebound-effect concerns raised in previous carbon header proposals?
> >> I would appreciate any feedback on the suitability of this work within the GREEN WG, or any other technical help or suggestions.
> >> Best regards,
> >> Andrei Nicolae Besleaga
> >
> > I would not implement such a thing. Per-request carbon accounting is impossible. It cannot be measured or estimated with any accuracy whatsoever. To ship such a thing through additional HTTP overhead would be grossly irresponsible.
> >
> > Carbon accounting requires actual measurements that are auditable. The vast majority of server-side carbon cost is spent providing for the availability of resources, not individual responses. Cost information is therefore inherently periodic and dependent on actual energy choices. The actual cost of a given request is the total cost of maintaining that resource over time, divided by the number of successful responses over that same time period.
> >
> > Hence, what you are looking for is an information resource. The Web is already capable of supplying that. Estimates based on actual (per-day/month/year) costs can be supplied as its own resource (per site) or as a parallel resource tree (e.g., "/my/resource" --> "/.well-known/carbon/my/resource"). No changes to HTTP required.
> >
> > ....Roy
> >
>
> ________________________
> Michael Sweet
>

Received on Monday, 16 March 2026 10:41:24 UTC