Summary

  • The IETF Executive Director’s report dated 1 September says the 2025 Sponsorship Report has been published and distributed to sponsors, with JMAP and L4S case studies at its centre.
  • The report says the information and content used for those case studies form a core part of the “Living Case for Support” requested by the IETF LLC Board.
  • The public success-stories page makes concrete adoption statements, including more than 10 million users on L4S-capable access networks by the end of 2025 and a list of JMAP implementations or rollouts.
  • Those statements combine several distinct propositions: a specification exists, code implements it, a product ships it, a capability is enabled, people actively use it, and users receive a measurable benefit. One proposition does not prove the next.
  • RFC 8711 places fundraising with the IETF LLC but gives the LLC no authority over standards development. RFC 3935 likewise says an IETF standard does not mandate its own use.
  • A public, append-only adoption ledger should preserve the specification version, claim class, date, unit, denominator, method, source relationship, uncertainty and corrections cited by each fundraising release.

A case study becomes an operating input

The IETF Executive Director’s public report for the 3 September LLC Board meeting contains a short fundraising update with a long institutional consequence. It says the 2025 Sponsorship Report has been published and distributed to sponsors. The second edition includes case studies about JMAP and L4S, improves on the presentation of the first edition, and supplies information and content that are a core part of the “Living Case for Support” requested by the Board.

This is more than a new brochure. A living case is designed to be reused, refreshed and carried into future conversations. A protocol story can begin on a technical page, appear in a sponsorship report, enter a donor presentation and later be quoted as evidence that support produced public value. Each reuse increases the distance between the reader and the original observation.

The IETF has good reasons to tell that story. Its adopted 2026 budget lists US$1.58 million in sponsorship revenue and US$140,000 in in-kind sponsorship within total revenue of about US$14.01 million. Those are budget figures rather than actual receipts, but they show that sponsorship is a material administrative line. The LLC is expected to explain why an open standards institution is worth supporting, and examples of technology in use are more intelligible than a catalogue of meeting and publication costs.

The governance obligation begins at the same point. A vivid case study can compress several kinds of evidence into one word—success. The compression is useful for communication and dangerous for accountability. If the underlying propositions are not preserved before the story travels, later readers cannot tell whether they are seeing a measured deployment, a product announcement, an implementation list, an estimate or a projected benefit.

This is not an argument against fundraising. It is an argument for keeping the evidence strong enough to survive fundraising.

One story can contain six different claims

The IETF’s public success-stories page illustrates the problem without proving that anything on it is wrong. It says that more than 10 million Internet users were on L4S-capable access networks by the end of 2025, with growth expected in 2026 and 2027. It also says JMAP was in production at several named mail services or servers in 2025, while Thunderbird was rolling out support and other projects were extending its use.

These are useful signals. They are not one uniform measurement.

An RFC publication is a document event. An implementation is evidence that somebody wrote compatible code. A product release shows that code is available to a customer. Default enablement shows that the capability can affect ordinary traffic without a special switch. Active use requires an observation of behaviour. User exposure counts people, accounts, devices, access lines or sessions, depending on the system. Measured benefit asks whether latency, reliability, cost or some other outcome changed against a declared baseline.

The distinctions matter even when every sentence is accurate. A server can implement JMAP without every hosted account using it. A client can announce support while deployment remains staged. An access network can be L4S-capable while individual devices, applications or flows do not negotiate the feature. Ten million eligible users, ten million provisioned lines and ten million observed active users are different denominators. A forecast for 2027 is not an observation from 2025.

The checked success-stories page does not attach a dated method, denominator, dataset or claim-level evidence note to each of those statements. That absence is not proof that no source exists. Operators may hold commercially sensitive measurements, and the sponsorship report may contain references that the public page does not. The narrower finding is that a reader of the public claim cannot reconstruct its evidentiary class from the page itself.

The IETF’s own technical record offers a better vocabulary. RFC 5218 distinguishes a protocol’s purpose from its scale and defines success through both meeting original goals and wide deployment. RFC 8170 asks transition planners to understand existing deployment, explain incentives, identify phases, define measurement and plan for contingencies. It explicitly notes that methods differ with protocol design. These documents do not certify JMAP or L4S. They show why a word such as “adopted” needs more structure than a list of names or a single reach figure.

Funding may describe the work; it does not own the result

The constitutional boundary is already available. RFC 8711 makes the IETF LLC responsible for operations, finances and fundraising. The same document says the LLC has no authority over IETF standards-development activities. That separation lets a legal entity sign contracts, manage budgets and speak to sponsors without turning an administrative need into a technical vote.

RFC 3935 supplies the complementary limit. An IETF standard tells implementers how to do a thing if they claim conformance; it does not mandate use or police adoption. Running code and deployment experience inform engineering judgment, but deployment remains a choice made by operators, vendors and users.

That means a success story can legitimately support the LLC’s fundraising case without becoming a claim of ownership over adoption. The LLC may say that open IETF work helped enable an implementation. It should not imply that the institution ordered a market to deploy, that sponsorship purchased the result, or that adoption confers new standards authority on the fundraiser.

The same restraint applies in the other direction. A company that implements a protocol, supplies measurement data or donates to the IETF does not thereby acquire ownership of the standard. A donor relationship is relevant evidence about provenance, not proof of capture. A vendor-supplied count can be valuable and accurate while still needing a label that tells readers who produced it, what the unit was and whether an independent observer reproduced it.

Earlier IETF support material emphasizes that no company can buy control of the IETF or its technical outcomes. A claim ledger would reinforce that position. It would show that money, implementation, measurement and standards decisions remain separate records even when they concern the same organisation.

Build the ledger before the narrative travels

The practical answer is not to burden a sponsorship report with raw telemetry. It is to give every material adoption claim a stable public identifier and let the narrative cite a frozen ledger snapshot.

The record should name the exact specification and version. It should classify the claim as implementation, interoperability test, shipped capability, enabled capability, active use, user exposure or measured outcome. It should give the observation date and measurement window; the unit, numerator and denominator; geographic and product scope; method and data owner; independent reproduction status; material caveats; and the correction or supersession history.

One field should disclose the source relationship without turning it into a verdict. Was the evidence supplied by an implementer, a sponsor, a donor, a beneficiary, an independent measurement project or IETF staff? Several roles may apply. The purpose is not to disqualify interested sources. Much of the best deployment knowledge sits with the people operating the system. The purpose is to let the reader interpret the evidence without guessing at the relationship.

Another field should preserve uncertainty. A calculated reach estimate may be the best available measure, but it should say whether it counts capable access lines, subscriber accounts, active endpoints or measured flows. A product roadmap can be reported as a roadmap rather than silently aging into a deployment fact. A named implementation can remain valuable without being inflated into a market-share claim.

Corrections must be append-only. If a denominator changes, a vendor clarifies an enablement state or a forecast becomes an observation, the old record should remain visible with a superseding link. The sponsorship report should retain the snapshot it used, so a future update cannot make yesterday’s claim appear to have been based on today’s data.

The ledger must remain thin. It should not approve products, certify conformance, rank donors or decide whether a protocol deserves standards promotion. It should not demand confidential customer data. Aggregation and redaction can protect commercial information while preserving method, unit and relationship. Its only authority is evidentiary: it tells readers what proposition the IETF chose to repeat and what public record supported that choice.

Lu Heng’s distinction is useful here. Evidence can inform a decision without becoming authority. Publication does not create deployment, and participation does not create a mandate over absent parties. Applied to fundraising, the discipline is straightforward: the LLC may make the case for support, while operators create the running reality and the standards process retains its own bounded authority.

A living case for support should improve as evidence changes. That is exactly why it needs a ledger. Without one, “living” can mean that the narrative keeps moving while its factual ancestry disappears. With one, the IETF can tell a compelling story and still let a reader follow every important claim back to its date, method and proper owner.

Sources

  1. IETF — Executive Director report for the 3 September 2026 LLC Board meeting
  2. IETF — Success stories
  3. IETF — Why we need your support
  4. IETF — Supporting the technical foundations of business
  5. IETF — Financial supporters
  6. IETF Administration LLC — 2026 budget
  7. RFC 8711 — Structure of the IETF Administrative Support Activity, Version 2.0
  8. RFC 3935 — A Mission Statement for the IETF
  9. RFC 5218 — What Makes for a Successful Protocol?
  10. RFC 8170 — Planning for Protocol Adoption and Subsequent Transitions
  11. IETF — Endowment Case for Support, November 2023
  12. IETF — Case for Support, September 2023
  13. Lu Heng — The Multi-Stakeholder Mirage