Summary

  • ICANN's own public-comment materials say submissions are public, that proceedings generally stay open for at least forty days, that ICANN org summarizes submissions and identifies themes, and that the group that opened the proceeding reviews the submissions and summary report before deciding next steps. That design makes the summary a governing document, not a mere clerical convenience.
  • The accountability gap is not that comments are hidden. The stronger concern is that an official summary can compress disagreement into categories chosen by the same institution that is preparing, advising or defending the decision. Without a visible coding table, readers cannot tell whether a recurring objection, a specialized technical warning or a minority institutional position was weighed or merely paraphrased away.
  • The .org renewal proceeding illustrates the structural issue. The proceeding page identified the removal of price-cap provisions as a material change, collected public comments, promised a summary and analysis for board consideration, and linked both comments and a report. The public can see the consultation architecture, but reconstructing how each objection affected the final decision requires more than a theme narrative.
  • A publishable public-comment summary should include a transparent issue codebook, counts that separate unique arguments from duplicate signatures, minority and dissent sections, a decision-response table, and specific reasons for rejecting objections. The aim is not to bind the board to every comment; it is to prevent a public consultation from becoming consent by compression.

The summary is where consultation becomes power

A public comment period looks democratic because it invites many voices. In ICANN, it is also a formal part of how legitimacy is produced. The public page for the program describes Public Comment as a mechanism for stakeholders to have opinions and recommendations formally and publicly documented. The same page says proceedings are open for a minimum of forty days unless an exception applies, that submissions and summary reports are published, and that comments are visible to the public.

The "About Public Comment" page goes further: ICANN org summarizes submissions, identifies themes, and the group that opened the proceeding reviews the submissions and the summary report, addresses the input, and proposes next steps.

That sequence matters. A comment is the raw democratic act; the summary is the institutional translation. The board, staff, supporting organization, advisory committee or other initiating group will rarely read thousands of pages of comments as the public sees them. Even when individual decision makers read widely, they rely on staff or committee materials to know what the record contains. The summary therefore becomes the practical gate through which a comment enters the decision. A badly made summary can honor the filing requirement while weakening the effect of the filing.

This is not a theory about bad faith. Large public consultations need compression. A board cannot turn every submission into a separate resolution. Staff must identify themes, merge repeated arguments, ignore abusive material, and point decision makers toward the issues that require judgment. The difficulty is that compression is itself judgment. The person who decides that two comments raise the same issue has already shaped the record. The person who classifies an objection as out of scope has already affected the available remedy.

The person who treats an objection as a request for future monitoring rather than a reason to change a contract has already narrowed the choice.

ICANN's bylaws make that judgment problem important because they do not treat transparency as simple posting. Article 3 requires procedures for detailed explanations of the basis for decisions, including how comments influenced policy considerations, and public disclosure of the rationale for board and community decisions. That language does not require every comment to prevail. It does require a traceable explanation. If a public-comment summary says only that comments were received, themes were considered and a proposal will proceed, it may satisfy a filing habit while failing the stronger accountability promise.

The governance question is therefore not whether ICANN publishes comments. It often does. The more serious question is whether the official summary gives an outsider enough evidence to test how the comments were converted into reasons. A legitimate summary should allow a reader to ask: who made this claim, how many distinct arguments support it, what evidence was attached, how did ICANN classify it, which decision point did it touch, and why was it accepted or rejected? Without that chain, public comment becomes public noise followed by private sorting.

Comments are not votes, but they are evidence

The first error in reading a public-comment record is to treat it as a plebiscite. ICANN is not a legislature elected by the global Internet public. A thousand identical messages do not automatically defeat a specialized technical objection, and a small number of high-quality comments can identify a defect that a large petition misses. Public comment is not vote counting.

The opposite error is just as damaging: treating comments as ambience. A public comment period is not a ceremonial listening tour. When ICANN asks affected parties to spend time on a proposal, it creates a duty to explain how that time affected the decision. Comments supply evidence about operational consequences, legal reliance, cost incidence, implementation risk, user expectation, market structure and unintended effects. They also reveal whether the proposal has been understood by the people who must live with it.

Even a comment based on a mistaken premise can be valuable if many affected parties share the same misunderstanding, because that misunderstanding may itself create implementation risk.

This means that a good summary should distinguish at least four things. First, it should identify factual evidence. A comment may point to an operational dependency, a contractual reliance point, a security risk or a cost that was not visible in the proposal. Second, it should identify normative positions. A commenter may say that a rule is unfair, inconsistent with ICANN's commitments or contrary to a community expectation. Third, it should identify remedy preferences. A commenter may support the objective but ask for a narrower clause, a longer notice period, a transition path or a later review.

Fourth, it should identify pure support or opposition. A statement of support is useful, but it should not be confused with evidence or a remedy.

The summary should then tell the reader which role each issue played. Did the evidence change the text? Did the objection fail because it was unsupported? Did ICANN agree with the risk but locate the remedy elsewhere? Did the board reject a fairness argument because it prioritized contract uniformity, competition, security, stability or another stated value? These are different outcomes. A theme summary that says "some commenters raised concerns" hides the decision that actually matters.

The danger is greatest when the decision maker or its staff already has a preferred path. In many ICANN proceedings, staff has spent months preparing a proposed contract, bylaw amendment, operating plan or implementation design before comments open. That is not improper; complex governance requires drafting. But the same preparation creates an incentive to read comments as refinements rather than vetoes. A comment summary written by the drafter must therefore be held to a higher evidentiary standard than a neutral transcript.

It must show the public how institutional investment in a proposal was separated from classification of objections to that proposal.

The .org renewal proceeding shows the compression risk

The 2019 proposed renewal of the .org registry agreement is a useful case because the public record shows the architecture of consultation. The proceeding opened on 18 March 2019 and closed on 29 April 2019. ICANN's page identified the Global Domains Division as the originating organization and named a staff contact. It described the current agreement, the proposed renewal, the base registry agreement comparison, and the material differences. One listed change was the removal of pricing provisions that had limited registration prices and allowed increases under the prior agreement.

The page also stated the next step plainly: after reviewing public comments, ICANN would prepare and publish a summary and analysis, and the report would be available for the board in its consideration of the proposed renewal. That sentence is the whole problem in miniature. The summary was not being prepared for a museum. It was being prepared for a decision. Once a report becomes part of the board's consideration, the quality of the report affects the quality of the decision.

The .org record also shows why comment classification cannot be reduced to a headline. A price-cap objection can mean several things. One commenter may argue that .org is relied upon by noncommercial users and therefore has a public-interest character. Another may argue that a legacy registry has market power because registrants face switching costs. A third may argue that the base registry agreement is an inappropriate comparator. A fourth may accept price flexibility but ask for more notice, a narrower cap, a staged increase or a separate review. A fifth may entity to the bilateral nature of the negotiation.

All of these can be summarized as "concerns about pricing," but they are different arguments touching different decision points.

If a board later approves the renewal, the rejection reasons should therefore be separated. ICANN might reject an affordability argument because the contract framework treats legacy registries like other operators. It might reject a market-power argument because it believes competition or registrant protections are sufficient. It might reject a procedural argument because the renewal clause limits renegotiation. It might defer a public-interest concern to a later contractual-compliance or policy forum. Each reason is contestable, but at least it is visible.

Without that visibility, the public sees only that concerns existed and the decision proceeded.

The reference available for this article does not support an independent recount of every .org comment or a full coding of the report against each submission. That limit is important. The point is not to invent a numerical imbalance or to quote a hidden file. The point is to identify the governance standard that would make such a recount possible. A public proceeding page that links to comments and a report is a start. A public summary that exposes its classification method is the next step.

The missing codebook

The most practical reform is a codebook. Public-comment summaries should publish the categories used to classify submissions before or with the report. The categories do not need to be complicated. They should identify the issue, the decision point, the type of claim and the proposed response. The codebook should be stable enough that a reader can compare proceedings, but flexible enough to capture unexpected arguments.

For example, a registry-agreement proceeding could use issue codes such as pricing, renewal rights, service continuity, abuse obligations, registrant protection, competition, transition, legal authority and implementation timing. It could use claim-type codes such as factual evidence, operational risk, legal interpretation, policy principle, proposed textual edit, support, opposition and out-of-scope material.

It could use response codes such as accepted in final text, accepted in explanation only, rejected with reason, deferred to another forum, not within ICANN authority, already addressed, not supported by evidence, or requires later implementation work.

The value of the codebook is not mathematical elegance. It forces the summary writer to make classification choices visible. If a public-interest objection is treated as a competition argument, readers can see that move. If a technical security warning is merged with general opposition, the merge can be challenged. If a minority position is marked "out of scope," the report can say why. The board can then rely on the summary with a clearer understanding of what it is relying on.

Coding also separates quantity from weight. A thousand form submissions may all carry the same issue code and count as one recurring argument with many supporters. A single expert comment may carry a technical-risk code that deserves attention even if no one else raised it. A stakeholder group comment may represent a formal community position and should be marked as such, but it should not erase individual objections. The codebook lets the summary show both breadth and substance.

This is especially important for ICANN because public participation is uneven. Some stakeholders have full-time policy staff. Others are volunteers, registrants, small network operators, civil-society groups or users who appear only when a specific decision affects them. A summary that weights polished institutional comments more heavily without saying so can reproduce participation inequality. A summary that counts every short objection equally can lose expertise. Transparent coding does not solve that distributional problem, but it makes it visible.

Minority views need a named place

Consensus institutions often fear minority sections because they can make disagreement look larger than it is. That fear is understandable but misplaced. Suppressing minority views does not create consensus; it creates an opaque record. A board can still choose the majority or staff recommendation. The issue is whether it can show what it declined to adopt.

Minority views should be preserved when they meet one of several tests. They should be preserved when they identify a plausible operational harm, even if only a few commenters saw it. They should be preserved when they come from a class of affected parties that is underrepresented in the comment record. They should be preserved when they challenge the legal authority for the decision. They should be preserved when they propose a narrower remedy that would achieve the stated aim at lower cost. They should be preserved when they reveal that a proposal is understood differently by different communities.

The summary should not bury such views under "other comments." It should say what the view is, who raised it in general terms, what evidence supports it, and why it did or did not change the outcome. If the view is weak, the report can say so. If the view is outside ICANN's mission, the report can say so. If the view is valid but belongs in a later policy forum, the report can say what forum and why the current decision should not wait. What the report should not do is convert dissent into a texture of concern without a decision response.

Minority treatment is also the test for capture. A system may be open in form while dominated by repeat entities, funded actors or organized constituencies. A summary that shows only the dominant theme can make capture look like consensus. A summary that records minority objections lets readers see whether the decision depended on expertise, bargaining power, endurance or actual agreement.

This does not mean every lonely objection becomes a veto. The board is entitled to reject bad arguments. Staff is entitled to say that a comment misunderstands a contract. ICANN is entitled to protect stability, security and interoperability against popular but unworkable demands. The point is that rejection must be reasoned. The minority view is not honored by being allowed to speak; it is honored when the reason for not following it is visible.

Reasons for rejection are governance assets

A reasoned rejection is often more valuable than an accepted edit. Accepted edits are easy to see because the text changes. Rejections require explanation. They show the real hierarchy of values: contract uniformity over bespoke protection, stability over speed, privacy over publication, competition over price control, security over convenience, mission limits over public demand. Without rejection reasons, the public cannot tell which value carried the day.

ICANN's bylaws already point in this direction by requiring detailed explanations of decision bases and how comments influenced policy considerations. The phrase "how comments influenced" should not be read as "whether comments changed the final text." Influence can include confirming a choice, narrowing a clause, producing a monitoring commitment, exposing a misunderstanding, generating a later review, or failing because the board found the argument unpersuasive. The summary should show that full range.

Rejection reasons also protect ICANN from unfair criticism. If a public-comment record contains strong opposition but the legal agreement gives ICANN no power to impose the demanded condition, saying so is better than pretending the objection was merely considered. If a comment asks for a remedy that would destabilize a registry, the report should explain the stability risk. If a comment raises a legitimate concern already handled by another contract clause, the report should point to the clause. These explanations may not satisfy opponents, but they create a record that can be reviewed.

The absence of rejection reasons creates the opposite incentive. Critics assume the institution ignored them. Supporters assume the institution had reasons that need not be shown. Staff learns that a broad theme narrative is safer than a detailed response because detailed reasons create targets. That is the wrong lesson. In a legitimacy system, reasons are not liabilities; they are the currency of authority.

Timing decides whether comments can matter

A public-comment summary can be perfectly written and still arrive too late to matter. If a board is already committed, if a contract must be signed before a deadline, or if staff has negotiated terms that cannot realistically be reopened, the summary becomes a defensive document. It explains why the prior path survived. It does not create an opportunity for change.

The .org proceeding again shows why timing needs more explicit treatment. The public page explained that the current agreement would expire on 30 June 2019 and that the comment report was due on 3 June 2019. That schedule left a narrow window between the report and the expiry date. A compressed window does not prove bad process. Renewal clocks are real. But when the decision window is short, the summary should disclose what options remained open when comments were reviewed. Could the text be renegotiated? Could the term be extended temporarily? Could a controversial clause be deferred? Could the board approve with conditions?

Could staff reopen discussion with the registry operator? A reader cannot evaluate public influence without knowing the option set.

Timing also matters before comments open. If the proposal reflects a bilateral negotiation, public comments may be negotiating against a term already accepted by the counterparty. If the proposal reflects a community policy process, comments may be reviewing implementation rather than policy. If the proposal reflects a budget or operating plan, changes may affect dependent projects. Summaries should state the procedural posture. A comment cannot be judged fairly unless readers know whether it is trying to change policy, implementation, contract text, timing or oversight.

This is why the phrase "following review of public comments" is limited public evidence by itself. Review can mean anything from "we read and adjusted the proposal" to "we read and proceeded." A transparent summary should describe the remaining degrees of freedom. It should say which issues were still open, which were constrained by prior commitments, and which would require another forum. That candor may disappoint commenters, but it prevents false expectations.

The decision maker should not be the only narrator

In ICANN's public-comment model, ICANN org summarizes submissions and identifies common themes. That may be efficient, but it concentrates narrative power. The organization that prepares the proposal, negotiates the contract or advises the board often writes the summary that explains the objections to that proposal. Even if staff acts carefully, the appearance of self-review is unavoidable.

There are several ways to reduce that risk without creating a new bureaucracy for every proceeding. One is to publish the classification table alongside the narrative report. Another is to let commenters see preliminary issue categories and flag misclassification before the final report.

A third is to allow the originating group to add a response column separate from the staff summary, so readers can distinguish "what comments said" from "what decision makers think about them." A fourth is to require an independent review of classification for high-impact proceedings involving contracts, fees, core governance documents, accountability mechanisms or identifier stability.

The key separation is between summary and response. A summary should describe the comment record as fairly as possible. A response should explain what ICANN will do. When the two are merged, there is a temptation to describe comments in the language of the planned response. A strong objection becomes "concern addressed by existing safeguards." A request for a different decision becomes "preference for alternative policy." A legal objection becomes "comment regarding authority." These phrases may be accurate, but they need support.

Separating summary from response would also help the board. Directors need to know when they are being told what the record contains and when they are being advised how to decide. Staff recommendations are legitimate. The problem is not advice; the problem is advice disguised as neutral compression. A board that receives a coded summary, a response table and the original comments can ask better questions.

A practical public-comment audit trail

The minimum public-comment audit trail would contain six layers. The first is the original submission archive, with timestamps, submitter names as published under the rules, attachments and any later corrections. ICANN already provides much of this. The second is a machine-readable index connecting each submission to issue codes. That index should not require readers to scrape web pages or manually open every attachment.

The third layer is a theme summary that explains the main arguments in ordinary prose. This is the familiar public report, but it should be built on the coded index rather than replacing it. The fourth layer is a minority and dissent section. This section should identify arguments that did not dominate the record but were important because of evidence quality, affected-party status, legal authority, operational risk or remedy design.

The fifth layer is a response table. Each major issue should receive a decision response: accepted, partly accepted, rejected, deferred, outside authority, already addressed, or requiring later work. The table should include a reason, not only a label. The sixth layer is a board-use statement. If the board relies on the report, the resolution or rationale should identify the report and the decisive issues. If the board rejects a major objection, it should say why.

None of these layers requires the board to surrender discretion. They simply make the exercise of discretion reviewable. A public-comment system that cannot be reviewed becomes a legitimacy ritual. A public-comment system that shows its classifications becomes evidence.

The board record cannot repair a weak summary

It is tempting to say that the board rationale is the real accountability document and that the public-comment summary is only one input. That answer is limited public evidence. By the time a board resolution is drafted, the summary has already shaped the universe of visible issues. A board rationale can explain why directors approved a decision, but it often cannot reveal what was never placed before them as a distinct question.

This matters because board materials are not neutral containers. They are prepared for a decision meeting. They must be concise, legally careful and aligned with the proposal being considered. If the public-comment report has already grouped a set of objections under a broad heading, the board paper may refer to the broad heading rather than the underlying differences. The decision record then repeats the compression instead of testing it. The public sees consistency between the report and the rationale, but consistency may only mean that both documents inherited the same classification.

A stronger summary reduces that risk before the board meets. Directors should be able to see not only the staff conclusion but the contested map underneath it. If a proposal raises pricing, service continuity, market power, public-interest reliance and procedural-authority concerns, those concerns should appear as separate rows. A director can then decide that only one matters, that all have been answered, or that one requires delay. What should not happen is that the director is asked to approve a conclusion after objections have been blended into a single theme.

The same point applies when a board member reads original submissions personally. Individual diligence is useful, but it is not a control. Public governance cannot depend on the reading habits of particular directors. A summary method should work even when directors rotate, when the docket is heavy, when attachments are long and when a decision is urgent. The method should make the record legible without trusting any single person to notice what the report omitted.

Duplicate comments should not erase distinct harms

High-volume proceedings often attract repeated messages. ICANN must be able to handle form comments, campaign text and repeated objections without pretending that every identical sentence adds a new argument. Yet duplicate management can create its own distortion. If repeated comments are treated only as a mass campaign, the summary may miss the fact that different submitters attach the same objection to different harms.

Consider a pricing objection in a registry-agreement proceeding. A nonprofit registrant, a registrar, a consumer advocate, a security researcher and a domain investor may all oppose price-cap removal, but for different reasons. The nonprofit may fear mission budgets. The registrar may fear customer anger and renewal friction. The consumer advocate may fear lock-in for public-interest sites. The security researcher may fear abandoned domains becoming abuse targets. The investor may fear uncertainty in domain valuation. The top-line sentence is the same, but the risk map is not.

A good summary should therefore count duplicates in two ways. It should identify repeated text or campaign submissions so readers do not confuse volume with independent analysis. It should also preserve distinct harm theories attached to repeated positions. A thousand comments saying "do not approve" may contain five reasons, and those reasons must be separated. The legitimacy problem is not solved by saying that many commenters opposed the proposal; it is solved by showing which risks opposition actually raised.

This is particularly important for affected-party classes with different capacity to write formal submissions. A small organization may submit a short objection because it lacks policy counsel. A large stakeholder group may submit a detailed letter with citations and proposed text. If the summary values only polish, the large stakeholder dominates. If it values only count, the campaign dominates. The right method records both, then asks which arguments bear on the decision.

Out-of-scope findings need reasons too

"Out of scope" is one of the most powerful phrases in a public-comment report. It can be correct. ICANN's mission is limited, and not every grievance connected to the Internet belongs in an ICANN decision. A registry contract cannot solve every problem of market concentration, speech, privacy, competition law or national regulation. A summary should not force the board to decide matters beyond its authority.

But an out-of-scope label can also hide the hardest boundary questions. Whether a comment is outside the proceeding often depends on how the proceeding was framed. If a proposed agreement removes a pricing constraint, affordability may be central rather than peripheral. If a proposed policy affects publication of contact data, privacy and law-enforcement access may be central rather than collateral. If a proposed accountability change affects who can challenge a decision, cost and access may be central rather than merely procedural.

For that reason, out-of-scope findings should carry reasons. The report should say whether the issue is outside ICANN's mission, outside the authority of the initiating group, outside the specific text under review, already settled by an earlier policy decision, or reserved for another proceeding. Those are different statements. A mission limit means ICANN lacks power. A proceeding limit means ICANN may have power but chose not to reopen that question here. A prior-decision limit means the comment is late, not irrelevant. A forum limit means the commenter should know where to go next.

Reasoned scope findings also reduce resentment. Commenters may accept that they chose the wrong venue if the report explains the right one. They are less likely to accept a summary that records their concern and then says nothing. In a multistakeholder institution, participation failures compound. A person who spends time on one proceeding and sees no visible response is less likely to return for the next one. The cost is not only fairness in that proceeding; it is future evidence loss.

Technical objections should not be flattened into policy preferences

ICANN proceedings often mix policy values with technical claims. A comment may say that a proposed change threatens DNS stability, weakens abuse response, complicates registry transition, undermines data accuracy, or creates operational ambiguity. Such a comment may also express opposition as a policy preference. A weak summary can merge the technical claim and the preference, then reject the whole package as disagreement.

The better method separates the parts. If a commenter says a proposed contract change will weaken emergency transition, the summary should identify the specific transition claim. ICANN can then answer it: the existing emergency provisions remain sufficient, the risk is addressed elsewhere, the claim is unsupported, or the text has been revised. If the same commenter also says the board should reject the agreement because of public-interest symbolism, that is a separate claim. Separating them prevents a technical warning from being lost because the broader position did not prevail.

This distinction is central to number-resource issues. Technical facts about uniqueness, registry accuracy, reverse DNS, routing-security reliance or allocation eligibility may be raised by a small number of operators. They may not come with polished public-policy language. A summary that prioritizes broad themes can miss them. The codebook should therefore mark technical evidence separately from institutional preference, even when the same submission contains both.

The board should not need to become the final technical reviewer of every claim. It should need to know whether a technical claim was raised, who was competent to assess it, what answer was given, and whether the answer changed the decision. That is enough to make the decision reviewable without turning a public-comment report into an engineering treatise.

The public needs negative findings, not only positive change

Many public-comment reports emphasize what changed after comments. That is useful, but it can create a distorted record. If a report lists accepted edits in detail and rejected objections in general terms, readers see responsiveness where the real dispute may lie elsewhere. The public needs negative findings as much as positive ones.

A negative finding says: this objection was understood, classified and rejected for this reason. It is the equivalent of a judicial court saying why an argument fails, without turning ICANN into a court. It disciplines the decision maker because the reason can be tested later. If ICANN says an affordability objection failed because the contract does not regulate retail prices, future critics can challenge that premise. If ICANN says a timing objection failed because the agreement was expiring, future reviewers can ask whether an interim extension was possible.

If ICANN says a technical concern was already addressed, future incidents can test that claim.

Negative findings also create institutional memory. The next proceeding can see which arguments were rejected before and why. Staff cannot simply say a concern is new when it has appeared repeatedly. Commenters cannot simply repeat an argument without engaging the prior rejection reason. The quality of debate improves because the record becomes cumulative.

This is where public-comment summaries can become a real accountability instrument. Not by turning every comment into a command, but by turning every serious objection into a reasoned public finding. ICANN does not need more ritual consultation. It needs consultation records that can be reused, audited and improved.

Source limits and what cannot be inferred

This article relies on ICANN's current public-comment description, the ICANN bylaws, and the public proceeding page for the proposed .org renewal agreement. Those sources show the formal consultation model, the minimum public period, the role of summary reports, the promise that the report would be available for board consideration, and the material pricing issue in that specific proceeding.

The sources reviewed here do not establish a complete statistical audit of every .org submission against every line of the report. They do not prove that a specific staff member intentionally minimized an objection. They do not prove that every board member relied only on the summary rather than the original comments. They do not prove that a different summary would have changed the final decision. The evidence supports a structural claim: the public-comment summary has enough influence that its classification method should be visible.

That distinction matters. A critique of summary design should not become an accusation about motive. The stronger institutional argument is simpler. When the same institution writes the proposal, receives comments, summarizes them and proceeds to a decision, the public needs a traceable bridge from comment to response. That bridge is the missing safeguard.

What a better ICANN report would look like

A stronger ICANN public-comment report would begin with the proposal and the remaining choices. It would state whether the initiating group could change text, reopen negotiation, defer a clause, approve with conditions, reject the proposal or only make implementation adjustments. It would then publish an issue codebook. Readers would see exactly how comments were classified.

The report would distinguish unique arguments from repeated endorsements. It would avoid implying that a petition is the same as a technical analysis or that a technical analysis is the same as community legitimacy. It would record affected-party type without giving privileged status to polished institutional writing. It would preserve minority arguments in a separate section. It would explain which objections were rejected and why.

The board paper would then connect the decision to the report. If a price-cap objection was rejected, the rationale would identify the governing reason. If a security warning was accepted, the text change or monitoring commitment would be visible. If a legal authority objection was outside the proceeding, the report would explain the available route for raising it. If a comment asked for a delay and the board declined, the timeline reason would be public.

The result would not eliminate disagreement. It might sharpen disagreement because losing arguments would be named more clearly. But it would improve institutional legitimacy because losers could see the reason they lost. In a multistakeholder setting, that is often the difference between disagreement and alienation.

Why this matters beyond names

Although the .org example comes from the domain-name side of ICANN, the public-comment summary problem affects number-resource governance too. ICANN's mission includes coordination of the top-most level of Internet Protocol numbers and AS numbers, along with facilitation of global number registry policies by the affected community and tasks agreed with the RIRs. When ICANN seeks comments on governance documents, global policies, accountability mechanisms or IANA-related arrangements, the same summary mechanics can decide whether operators' objections remain visible.

Number-resource decisions often involve small affected groups, complex technical dependencies and low public salience. A few comments may carry more operational information than a large general-interest proceeding. If a summary compresses those comments into bland themes, the cost may be invisible until a registry, allocation, reverse-DNS or continuity decision fails under stress. The summary method should therefore be strongest precisely where participation is thin and expertise is specialized.

The lesson is not that public comment should govern by headcount. It is that public comment should leave a usable record. ICANN's legitimacy depends less on how often it invites comments than on whether it can show how comments changed, narrowed or failed to change a decision. A summary written by the decision-making system can be trusted only when its classifications are open to inspection.

Conclusion

Public comment is not self-executing accountability. It becomes accountability when the public can trace a submission into a classified issue, a preserved minority view, a response and a reasoned decision. ICANN already publishes comments and summary reports as part of its governance model. The next standard should be traceability inside the summary itself.

The decision maker may need to summarize. It may even be the only practical body able to produce a timely report. But when it writes the summary, it must show its work. Otherwise the most important act in the consultation is not the public filing of comments. It is the quiet institutional act of deciding what those comments meant.

Sources reviewed