Summary

  • IETF participation is individual and rough consensus is not a vote. Counting employers in a room can reveal access imbalance, but it cannot establish who controlled the resulting specification or whether objections changed the design.
  • A serious capture assessment compares four linked concentrations over time: authors and editorial authority; patents and licensing leverage; independent code and protocol-library ancestry; and enabled deployment across products, networks, and defaults. Each ledger answers a different question and none proves capture alone.
  • The remedy should match the mechanism. Concentrated authorship calls for independent review and editor balance; concentrated rights call for early licensing analysis and alternatives; shared code ancestry calls for another implementation root; deployment dependence calls for migration, open test suites, and supplier portability. The objective is contestable implementation, not a quota for meeting microphones.

The room is where influence is visible, not where control necessarily resides

Standards observers often begin with a photograph of the meeting: how many people attended, which employers appear on badges, who took the microphone, and which side produced the loudest hum. These facts are easy to count. They can reveal travel inequality, employer sponsorship, regional exclusion, or a coordinated influx. They are worth preserving.

They are not the same as control of an outcome. A entity from a small company may edit the central text used by every implementation. Ten attendees from one vendor may speak on unrelated details while an independent design prevails. A company absent from the meeting may own the only mature code, hold relevant patents, set the dominant product default, or control a service on which every implementation depends. A large open-source community may appear under dozens of individual names while inheriting one code root.

Capture is therefore a longitudinal question. Did one aligned interest gain durable capacity to define the available choices, make alternatives expensive, and carry its preferred behavior into implementation and deployment? The answer cannot be read from a registration list. It emerges across the life of the specification.

This distinction protects both criticism and legitimacy. It prevents a vendor from pointing to a diverse room as conclusive proof that no capture occurred. It also prevents critics from treating employer headcount as proof that engineers acted under instruction or that the resulting protocol lacks independent support. The evidence must follow the result.

The 1992 maxim was about engineering authority, not a census

The period beginning in the early 1990s is often summarized by the 1992 formulation later repeated in RFC 7282: "rough consensus and running code." The phrase rejects decision by a ruler, a formal vote, or theory detached from practice. It does not say that code wins because a company can fund the most developers, nor that consensus exists because the largest employer group fills the room.

RFC 3935, the IETF mission statement, identifies individuals as the fundamental unit of participation and says the process works best when focused on people rather than organizations, companies, governments, or interest groups. It also locates a standard's value in interoperability among multiple products that deliver useful functions to Internet users.

These principles create a productive tension. Individuals speak and reason for themselves, but organizations supply salaries, travel, patents, code, equipment, cloud capacity, product distribution, and deployment authority. Ignoring organizations would make economic power invisible. Treating each entity as a corporate vote would destroy the individual and technical character of the process.

An implementation-centered capture test resolves the tension. It does not presume that an employee's contribution belongs politically to an employer. It asks observable questions about outputs: who authored and could merge the text, who controlled rights, which independently developed code realized the design, and who could turn support on for users. Organizational power is measured where it becomes technically consequential.

Working-group rules already recognize the single-vendor risk

RFC 2418, the working-group guidelines published in 1998, tells Area Directors and the IESG to consider whether interest is broad enough that a proposed group would not be seen as merely the activity of a single vendor. It asks whether there is a base of interested end users, whether known intellectual-property issues are understood, and whether the effort is genuinely open rather than an attempt to obtain IETF approval for technology on which IETF input can have little effect.

Those questions are more sophisticated than an attendance quota. A group can have enough names to satisfy a numerical threshold while one vendor supplies the problem statement, draft, editors, implementation, test environment, and expected customer base. Conversely, a narrow specialist field may begin with few implementers because the expertise is rare. The relevant issue is whether the work can become contestable and whether input can still change it.

RFC 2418 also requires decisions reached in a meeting on matters not adequately considered on the mailing list to be reviewed there. Email was recognized as allowing wider participation than travel. The principle has survived newer tools: no single venue's population defines the whole group.

The single-vendor question should therefore be asked repeatedly, not only at chartering. At adoption, last call, implementation review, and major deployment, the group should examine whether independence increased or narrowed. A group that began around one contribution may diversify. A nominally broad effort may converge on one supplier's code and operational model.

Rough consensus deliberately refuses to count corporate blocs

RFC 2418 says dominance is not established by volume or persistence, and that message count alone is not a reliable indicator of consensus. RFC 7282 develops the point: rough consensus depends on whether technical objections have been considered and answered, not whether a majority prefers one option. Humming is meant to expose where disagreement remains, not conduct an election.

This matters when a company recruits many employees to express the same position. RFC 7282 uses an extreme example involving sales and marketing staff to show that repeated objections without technical engagement need not control the decision. The chair should ask what problem remains and whether the answer is adequate. A new engineer with direct implementation evidence may raise a decisive issue; fifty identical statements may add no new information.

Attendance metrics can still reveal procedural risk. If every active editor and most speakers share an employer, a chair should seek independent review. If an affected operator class is absent, the group may not hear a cost. If newcomers appear only for one contentious call, coordination deserves examination. But the legitimacy test remains reasoned treatment of evidence and objections.

A capture assessment that simply reintroduces voting by employer would contradict this design. It would also be easy to manipulate through subsidiaries, contractors, acquired companies, universities funded by a vendor, or unaffiliated contributors dependent on the same code. Control has to be traced functionally, not guessed from the seating chart.

Capture is the durable narrowing of contestable choice

Vendor influence is normal and often indispensable. Companies bring difficult problems, experienced engineers, interoperable products, test facilities, and deployment scale. A specification can be written largely by one vendor and still become open, independently implemented, restriction-free, and broadly useful. Concentration is not misconduct by itself.

Capture begins when concentration hardens into control that the nominally open process cannot effectively contest. One interest can define which problem counts, keep the only usable implementation, make alternatives incompatible with installed systems, attach rights that raise entry cost, control key operational dependencies, or deploy a default so widely that later consensus has little practical effect.

The core is not intent. A vendor may achieve this position through technical excellence, first-mover advantage, customer demand, or the inability of others to fund work. The governance consequence can be the same: the standards body ratifies choices after the practical option set has narrowed. Motive matters for accountability, but structural dependence matters for design.

Capture is also feature-specific. A protocol may have five independent implementations but one optional extension controlled by one supplier. The base protocol can be contestable while the extension becomes a gateway to the dominant market. A common open-source library can diversify applications but concentrate parser behavior. Measurement should be granular enough to find the control surface without branding an entire protocol.

The first ledger is authorship and editorial authority

RFC metadata names authors and editors. Draft histories, issue records, and version control can show who supplied text and reviewed changes. These are useful starting points because document control determines how abstract consensus becomes normative language. A chair may declare a decision, but editors choose the wording that implementers encounter.

Simple author counts are weak. A name on the front page may reflect years of design, late editorial help, historical credit, or a formal limit on listed authors. A company can employ one editor while many independent contributors shape the text. Several listed authors can all share one design lineage. Affiliations can change between initial draft and publication.

The stronger measures follow substantive authority. Who authored the initial architecture? Who served as editor during adoption, last call, and final resolution? Who could merge changes? Which people proposed text for mandatory behavior, defaults, extensibility points, and error handling? How many design issues were resolved with independent review? Were alternatives documented and compared, or did the group refine one inherited implementation?

An authorship ledger should preserve time and role. Employer affiliation belongs to the date of the contribution, with later changes recorded rather than rewritten. Contractors, acquired entities, and dual roles need bounded notes. The goal is not to assign every sentence to a corporate principal. It is to see whether the normative core could be revised without one aligned group doing all the translation from consensus to text.

Git history improves visibility but does not define consensus

RFC 8874 explains how working groups can use GitHub for document editing, issues, pull requests, and traceable decisions. It requires policies, distinguishes editorial from design issues, and makes clear that work on GitHub has no special status. Contentious decisions and consensus still require the wider working-group process, including the mailing list.

This distinction should shape capture metrics. Commit counts measure activity, not authority. A contributor can make hundreds of formatting changes while another decides a single mandatory default. A repository owner may hold technical permissions that are constrained by chairs and public consensus. A merged pull request can reflect a decision taken elsewhere. An unmerged proposal may have transformed the final design indirectly.

Useful repository measures therefore weight issue type and decision effect. Who opened and resolved design issues? Who reviewed changes from outside the editor group? How long did independent objections remain open? Did a proposed alternative receive a stable draft and tests? Were late substantive changes exposed to the mailing list? Did one organization hold both editor and repository administration roles without independent chair oversight?

Tool selection creates its own sample bias. Entities who follow the mailing list may not monitor every issue, while software developers may prefer repository discussion. RFC 8874 warns that GitHub alone cannot be assumed to reach all interested entities. A capture review should compare venues and ask whether the decisive reasoning remained visible across them.

The second ledger is patents, licensing, and controlled technology

Code can be public while implementation rights remain concentrated. RFC 8179 connects IETF participation to rights reasonably and personally known to contributors, employers, and sponsors. Its purpose is to give working groups enough information about potential intellectual-property constraints to compare technical choices. It does not ask the IETF to decide validity or infringement.

For capture analysis, the relevant measures are concentration and timing. How many material disclosures attach to the mandatory core? Are they controlled by one rights holder or aligned group? Were licensing terms clear while alternatives were still feasible? Can two unrelated implementers use the licensing route on workable terms? Does an open-source implementation face a condition that product vendors can absorb but community projects cannot?

A raw patent count can mislead. One broad claim may matter more than a large defensive portfolio. A disclosure may identify possible rights without proving that a license is required. Royalty-free terms may reduce leverage; vague reasonable-terms language may leave small implementers uncertain. A rights holder may support broad implementation, while a third party outside the group creates the constraint.

The ledger should therefore connect each disclosed position to the affected feature, requirement status, rights holder, disclosure date, licensing posture, and evidence of separate successful use. It should preserve uncertainty. The finding is not "vendor owns patents, therefore capture." It is whether rights materially narrow who can implement or give one interest leverage after the group and market have committed.

The third ledger is code ancestry, not product count

RFC 7942 allows Internet-Drafts to describe known implementations, including the responsible organization, maturity, coverage, version compatibility, licensing, implementation experience, and interoperability testing. The section is voluntary and normally removed before publication, although separate maintained records can be used.

This guidance recognizes that running code improves specification maturity, but it does not make every implementation independent. Ten products can embed the same protocol library. A vendor can publish client and server variants from one repository. Two teams can use a shared parser, test oracle, cryptographic library, or reference state machine that carries the same interpretation and defect. A fork can have a different name while receiving nearly all upstream changes.

RFC 5657 supplies the sharper test. Its guidance on implementation reports says independent implementations should ordinarily come from different people, organizations, code, and protocol libraries. Where only two implementations exist, their genealogy should be identified. The purpose is to show that interoperability follows from the specification rather than private understanding or common code.

That genealogy is the correct unit for capture measurement. The question is not how many packages advertise support. It is how many independently reasoned code roots implement the normative behavior, can interoperate without a shared hidden assumption, and can continue if one maintainer or vendor withdraws.

A code-root map should measure control at several layers

Implementation ancestry is not binary. Two products may have independent application code but share a transport library. Separate protocol stacks may rely on one cryptographic provider. Independent open-source projects may use a single conformance test suite maintained by the original vendor. A cloud service may expose a protocol through many clients while keeping the decisive server behavior proprietary.

A useful map starts with the parser and state machine: are packet formats, transitions, errors, and negotiation independently implemented? It then tracks security-critical libraries, generated code, code generators, reference algorithms, and test vectors. It records fork relationships and the share of changes taken upstream. It identifies who can approve releases and security fixes.

The map should also distinguish reference influence from control. A high-quality reference implementation can reduce ambiguity and accelerate adoption. That is beneficial. Dependence becomes risky when the written specification cannot support another implementation without copying the reference, when tests encode undocumented behavior, or when every deployed product waits for one maintainer's release.

Measures can include independent root count, dependency concentration, maintainer concentration, reviewer diversity, test-suite independence, and substitution time. None should become a mechanical pass score. A small, carefully reviewed cryptographic library may be safer than many poor reinventions. The governance question is whether the standard remains implementable and maintainable without permission or unique knowledge held by one aligned interest.

Interoperability must test disagreement, not just successful demos

Two implementations can communicate because their authors coordinated privately, copied the same example, or avoided difficult features. A public demonstration proves something worked in one configuration. It does not prove the specification is complete, the implementations are independent, or optional branches interoperate.

RFC 5657 recommends enough feature detail to establish meaningful coverage without drowning the report in every normative statement. It values deployment evidence and encourages reports to identify unimplemented or problematic features. That candor is important for capture analysis: a feature supported only by the proposing vendor may remain in the standard despite no independent demand.

Tests should target places where interpretations could diverge: invalid input, version negotiation, fallback, extension ordering, error handling, security boundaries, resource exhaustion, and optional combinations. Independent teams should derive expectations from the specification before comparing behavior. When the reference implementation and test suite disagree with the text, the resolution should be public.

Failure can be evidence of independence. Two genuinely separate implementations often expose ambiguities that one shared code root hides. A process that rewards only polished demonstrations can push teams toward common libraries and suppress negative results. The better metric is whether independent disagreement improved the text and whether the resulting behavior became reproducible.

The fourth ledger is deployment, enablement, and default power

Implementation is only one step. RFC 5218 distinguishes implementation, deployment, and use when evaluating protocol success. Code can exist without being installed; installed support can remain disabled; enabled support can carry no meaningful traffic. A standards capture analysis must make the same distinctions.

Deployment power is the capacity to turn a design into the default environment faced by others. A browser, operating system, router platform, cloud edge, mobile network, or widely embedded library can establish behavior at enormous scale. That may produce rapid security and interoperability benefits. It can also make later alternatives technically conformant but commercially irrelevant.

Metrics should identify enabled endpoints, traffic share where measurable, product classes, administrative domains, and default status. They should separate one centrally controlled service from many independent operators. A million instances under one release authority are scale, not governance diversity. A protocol used by many networks through one hosted intermediary may have broad use and narrow operational control.

The ledger also needs dependency direction. Can a smaller implementer interoperate directly, or must it pass through a dominant service? Can operators change providers without changing protocol identity, credentials, or data format? Are extension points openly usable, or does the dominant deployment decide which extensions become viable? Capture often resides in these switching costs rather than the base packet format.

Defaults are standards power even when the text says MAY

Normative requirement levels do not fully describe deployment. An optional feature enabled by the dominant implementation can become de facto mandatory for services seeking reach. A mandatory feature disabled by most products may have little effect. A vendor-specific extension can shape traffic before the working group decides whether to standardize it.

Capture assessment should therefore compare text and default. Who selected the shipping behavior? Was it discussed as a design issue? Can operators change it safely? Does negotiation favor the vendor's mode? Do tests and documentation make the alternative equally viable? Does a service refuse clients that choose another conformant option?

Defaults can create beneficial coordination. Users gain protection when secure behavior is enabled without configuration. Performance improvements spread quickly. The concern is not that one popular implementation must avoid leadership. It is whether the standards process can still evaluate and alter the behavior after deployment creates dependence.

A transparent default ledger records version, date, product class, operator configurability, fallback, and the relationship to normative text. It also records when a proprietary default later enters the standard. That history helps distinguish independent consensus from recognition of a fait accompli.

Four concentrations need to be combined, not averaged away

Authorship, rights, code, and deployment each reveal a different form of control. A broad author group cannot cancel a patent bottleneck. Multiple patent holders cannot compensate for one code root. Several code roots do not prevent one deployment platform from setting the effective default. A diverse market does not cure a specification whose normative text can be changed only through one editor group.

The strongest capture concern appears when concentrations align. The same vendor or coordinated interest authors the mandatory core, holds material rights, maintains the reference and test code, and operates the dominant deployment. Each position reinforces the others. The installed base validates the design, the design favors the code, the code embodies undocumented behavior, and rights or switching costs deter alternatives.

The opposite pattern supports legitimacy. Concentrated initial authorship is followed by independent editorial review. Rights are absent or available on terms used by unrelated implementers. Several code genealogies interoperate. Deployment spans independent operators and products. No single layer needs perfect equality if the combined system remains contestable.

For that reason, a capture review should use a matrix rather than one composite score. Averages hide veto points. The report can rate each layer's concentration, evidence quality, trend, and consequence, then identify cross-layer alignments. A red patent cell is not cured by a green attendance cell.

Affiliation data must be dated and interpreted cautiously

Employer affiliation is useful but unstable. Engineers change jobs, companies acquire one another, open-source maintainers receive grants, consultants serve several clients, and academic work can be commercially sponsored. Rewriting historical contributions under a current employer can invent coordination that did not exist. Ignoring later acquisition can conceal consolidation that now affects maintenance.

The record should preserve affiliation at contribution time, publication time, and review time where relevant. It should distinguish employment, sponsorship, contracting, repository authority, patent control, and deployment authority. These relationships overlap but are not identical.

Self-declared affiliation is generally the appropriate starting point. Public corporate and project records can clarify ownership and maintenance roles. The process should not speculate about personal loyalty or demand private employment information. The purpose is to map observable control, not investigate beliefs.

Attribution should allow uncertainty. A contributor may act independently despite employment. A foundation may host a project while one company supplies most maintainers. A nominally unaffiliated expert may have no material tie at all. Conclusions should be phrased at the layer supported: "three editors shared an employer" is a fact; "the employer directed their votes" requires different evidence and may be false.

Attendance remains useful as an early-warning denominator

Rejecting attendance as the final metric does not make it worthless. Meeting and list participation can show who had access to information, which stakeholder classes were absent, whether one employer mobilized abruptly, and whether independent reviewers stayed engaged. These are procedural health indicators.

The denominator must be honest. Registered attendees are not active contributors. Microphone appearances are not unique objections. Mailing-list addresses are not verified people or employers. Repository accounts can be automated or duplicated. One entity can contribute across venues. Employer totals can omit contractors or count subsidiaries inconsistently.

Better attendance reporting separates registration, session presence, substantive contribution, document authorship, issue participation, and consensus response. It shows method and uncertainty. It avoids publishing sensitive personal profiles or turning participation into surveillance.

Most importantly, attendance findings should trigger a question, not a verdict. If one vendor dominates a session, seek an independent implementation review. If operators are absent, solicit deployment evidence. If the room is diverse but code is concentrated, do not declare the problem solved. The metric's job is to direct attention toward the layers where control can harden.

Patents and code can pull in opposite directions

Capture is not always a single-vendor story. A protocol can have independent open-source implementations but face a rights portfolio that makes commercial deployment uncertain. Another protocol can be free of known claims yet depend almost entirely on one open-source code base controlled by a small maintainer group. The remedies differ.

For rights concentration, the group can compare unencumbered alternatives, seek early licensing clarity, test whether unrelated implementers can use the terms, or avoid making the affected feature mandatory. It should not ask implementers to infer safety from the absence of a disclosure, because IETF policy does not perform a universal patent search.

For code concentration, licensing may be permissive and still leave operational dependence. The remedy can fund or encourage another code root, improve specification completeness, create independent test vectors, document undocumented behavior, and distribute review authority. Fork count alone is not enough if every fork follows upstream immediately.

Cross-layer analysis prevents category mistakes. Open code does not neutralize a patent. Royalty-free rights do not create a second implementation. Multiple products do not prove multiple roots. Many operators do not prove they can switch away from one hosted service. Each claim needs its own evidence.

Market share is relevant but should not become competition adjudication

Standards groups are not competition courts, and a capture review should not decide whether a company has violated antitrust law. Market share can nevertheless be technical evidence. It helps explain why a default becomes unavoidable, why an extension receives implementation attention, or why independent suppliers cannot test at meaningful scale.

The record should use the narrowest measure needed: share of observed protocol traffic, enabled endpoints in a product class, server reach, client capability, or dependence on a hosted intermediary. Broad corporate revenue or unrelated market power adds heat without clarifying the standard.

Measurement sources have bias. Traffic observers see only their vantage points. Vendor telemetry may exclude other products. Download counts do not show active use. Public scans miss private networks and can raise ethical concerns. Surveys overrepresent engaged operators. A report should state method, date, denominator, and blind spots.

High share is not proof of capture. A superior implementation can win adoption in an open field. The concern increases when share combines with a closed dependency, undocumented behavior, restrictive rights, or the practical inability of conformant alternatives to interoperate. The standards remedy focuses on portability and contestability rather than punishing success.

A repeatable capture review can use seven tests

The first test is changeability. Could an independent technical objection still alter mandatory behavior, or has deployment made the answer effectively irreversible? The second is implementability. Can a competent unrelated team implement from the specification without copying one reference code base or relying on private explanation?

The third is rights usability. Are known material rights and licensing positions visible early enough for alternatives, and have unrelated implementations exercised any required licensing route? The fourth is interoperability independence. Have different code and library genealogies tested difficult features, errors, and extensions rather than only a common happy path?

The fifth is deployment plurality. Are enabled deployments controlled by several independent operators and suppliers, or does apparent scale come from one release authority? The sixth is substitutability. Can a user or operator change implementation or service without losing identity, data, credentials, reach, or critical extensions?

The seventh is maintenance plurality. Can security fixes, errata, and future versions proceed if the leading vendor withdraws staff? Are editors, reviewers, test maintainers, and release authorities distributed enough to preserve the standard?

These tests produce a reasoned profile, not an accusation. A weak result identifies the control point and the evidence needed. The review should state whether the risk is current, emerging, declining, or unknown.

Thresholds should trigger safeguards, not automatic condemnation

Mechanical limits invite gaming. A rule that no employer may supply more than half the authors encourages decorative names. A requirement for two implementations encourages shallow forks. A patent-count ceiling ignores claim scope and licensing. A deployment-share limit would penalize successful standards and exceed the IETF's role.

Thresholds are better used as review triggers. One employer supplying all current editors can require an independent document review and a second editor search. One code genealogy across all known products can require a public implementation gap statement before last call. Material rights controlled by one interest can require licensing clarity and an explicit alternatives analysis. One deployment authority carrying most observed use can require portability and default documentation.

The safeguard should be proportionate. A specialized protocol with three experts may proceed if the record explains the narrow field and creates review routes. A mature protocol with one remaining maintainer may need succession work rather than rejection. A new extension already deployed by one platform may be standardized if the group can still change it and independent implementations are feasible.

The central discipline is to avoid converting a trigger into proof. Concentration requires explanation and mitigation. Capture requires evidence that concentration has impaired contestable choice or created durable control.

Remedies should target the layer that produced dependence

When authorship is concentrated, add independent reviewers, split editor and design roles, document alternatives, and ensure chairs confirm substantive changes across the wider group. Replacing a capable editor solely to improve a number may reduce quality; adding contestability is the aim.

When rights are concentrated, clarify affected features and terms, seek early disclosures, compare designs, and test whether unrelated implementers can proceed. The group should not make legal findings beyond its competence. It can decide that uncertainty changes the technical preference.

When code is concentrated, produce another independent root, improve the specification, maintain public test material, test failure paths, and disclose genealogy. Funding may be necessary because the missing implementation is a public interoperability asset, not merely a rival product.

When deployment is concentrated, prioritize open interfaces, data and credential portability, extension neutrality, migration paths, and the ability to operate without one hosted intermediary. A standards text that permits alternatives in theory but omits the switching mechanism has not resolved the dependency.

When all layers align, the review may need several safeguards before advancement: independent implementation, rights analysis, broader operational testing, default disclosure, and a maintenance plan. Delay can be justified if publication would otherwise convert a vendor product into an irreversible standard. Delay should remain bounded and tied to concrete evidence, not used to exclude useful technology indefinitely.

Public reporting should expose structure without profiling individuals

A capture report can be rigorous without publishing a dossier on entities. The unit should be role and organizational relationship where relevant: editor affiliation at the time, rights holder, code maintainer, library ancestry, deployment authority, and test sponsor. Personal addresses, compensation, private contracts, and inferred motives are unnecessary.

Small groups require care because aggregation can identify people. Reports can name public authors and maintainers already attached to the work while grouping survey responses from operators. Confidential commercial deployment figures can be expressed as ranges or verified by an independent reviewer. Security-sensitive implementation details can be summarized at the level needed to establish independence.

The report should preserve contrary evidence. If author concentration is high but code diversity is strong, say so. If implementation reports are self-declared and unverified, say so. If market data covers only one region or vantage point, do not generalize. If patent applicability is disputed, distinguish disclosure from legal conclusion.

Accuracy builds legitimacy. Capture language is powerful and can unfairly damage contributors. A finding should identify the mechanism, consequence, and evidence rather than label a company or working group as corrupt.

The assessment must continue after publication

RFC 7942 normally removes the Implementation Status section before RFC publication because the information changes over time. That protects the archival specification from stale claims, but it creates a maintenance challenge. Capture can emerge after publication through acquisition, code convergence, service consolidation, patent assignment, or a dominant default.

A separate living implementation record should preserve snapshots. At adoption it can show proposed code. At last call it can show maturity and interoperability. After publication it can show new roots, forks, deployment, known unsupported features, and changing control. Each snapshot needs a date and method.

Post-publication review should be event-driven. Triggers include one supplier acquiring another implementation, retirement of an independent code base, transfer of material rights, a major deployment crossing a concentration threshold, a previously optional extension becoming necessary for reach, or the departure of all editors outside one interest.

The remedy may be maintenance rather than reversal. A protocol can remain technically sound while its ecosystem becomes fragile. Succession, new test material, specification clarification, and another implementation can restore contestability without changing the wire format.

What a strong finding would look like

A defensible finding avoids slogans. It might say that, at working-group last call, four products claimed support but all derived their protocol state machine from one library maintained by the document's originating vendor; no independent implementation had tested two mandatory error paths; the same vendor held the only repository release authority; and most observed deployment came from its centrally managed service. No conclusion about bad faith is necessary.

The finding would then record counterevidence. The specification and code license are public. No material rights constraint is known. Independent reviewers changed several normative sections. Another team has begun a separate implementation. Operators can disable the extension, though doing so loses access to a major service feature.

The conclusion could be "high implementation and deployment concentration, moderate current capture risk, no patent bottleneck demonstrated." Safeguards could include independent completion of the two error paths, a portability test, default documentation, and a six-month deployment review. That is more actionable than saying one vendor had 40 percent of the room.

A low-risk finding can be equally specific: concentrated initial authorship, three unrelated code roots using different protocol libraries, interoperable testing across difficult features, no known mandatory rights constraint, deployment among independent operators, and no supplier-specific extension required for reach. The record shows why the standard remains contestable.

What should be published at each decision point

At chartering, publish the origin of the technology, known implementations, expected users, existing rights information, and why the work can be changed through open participation. At adoption, publish authorship roles, alternatives considered, code roots, and whether the draft is being refined from one deployed product.

At working-group last call, update editor affiliations, material design contributors, unresolved objections, implementation genealogy, feature coverage, rights posture, and default behavior. Identify any feature implemented by only one interest. At IETF last call, add broader review and dependent-specification consequences.

At publication, preserve a link to the dated implementation record even if the changing section leaves the archival RFC. State what was demonstrated and what was not. After publication, update deployment plurality, acquisitions, retired code roots, major defaults, and maintenance authority.

For advancement or major revision, apply the RFC 6410 criteria for independent interoperating implementations, widespread deployment, operational experience, errata, unused features, and separate licensing use where controlled technology is required. These are maturity criteria, not a complete capture test, but they align the institution's highest standards status with evidence beyond attendance.

The objective is an ecosystem that can disagree in code

Open discussion matters because it allows objections and alternatives to surface. Individual participation matters because technical reasoning should not be reduced to corporate mandates. Diverse attendance matters because absent experience leaves blind spots. None of those virtues is complete until an independent implementer can read the result, build it without private knowledge, interoperate, and deploy without permission from the dominant contributor.

The ability to disagree in code is a demanding test. It means an alternative implementation can choose a different architecture behind the same wire behavior. It can expose an ambiguity, challenge a default, decline an optional extension, and still participate in the ecosystem. It can survive the withdrawal of a reference vendor. Operators can compare products and services without abandoning the standard.

This is why implementation concentration is the decisive bridge between procedural openness and market reality. If every path leads back to one code root, service, rights holder, or release authority, the standard may be open in text and closed in practice. If independent roots and deployments flourish, a vendor's strong meeting presence has not captured the result.

The measurement is not anti-vendor. It rewards the strongest contribution a vendor can make: technology that others can understand, implement, test, operate, and improve independently. It also gives vendors a fair answer to vague allegations. They can point to separate roots, usable rights, interoperable tests, portability, and distributed deployment rather than defend themselves with attendee totals.

Institutional legitimacy follows the implementation trail

The IETF's legitimacy has never rested on one person, one company, one country, or one vote. It rests on open technical contest, rough consensus that addresses objections, specifications clear enough for independent implementation, and interoperable products that serve users. Vendor resources can strengthen every part of that chain. They can also narrow it if dependence is left unmeasured.

The existing public rules already contain the pieces. RFC 2418 asks whether a group is more than one vendor and whether outside input can affect the technology. RFC 3935 centers individuals and interoperable products. RFC 7282 rejects numerical voting in favor of answered objections. RFC 8179 exposes relevant rights. RFC 7942 records implementation maturity. RFC 5657 asks for different people, organizations, code, libraries, and genealogy. RFC 8874 makes editing traceable without granting repository activity special authority. RFC 5218 distinguishes code from deployment and use.

The missing step is to join these pieces at the point of decision. For each important specification, maintain four dated ledgers: authorship and editorial control; patents and licensing; code and library ancestry; deployment, defaults, and switching. Add attendance as a procedural warning signal, not the conclusion. Examine cross-layer alignments and publish bounded findings with proportionate safeguards.

A standards body cannot guarantee equal commercial outcomes. It can ensure that its own approval is not used to conceal an implementation monopoly behind an open meeting. The most meaningful question is not how many vendors entered the room. It is how many independent paths remained when the specification left it.