Summary

  • A DISCUSS is a legitimate quality backstop. It can stop a document that is not implementable, would not interoperate, creates serious security or operational harm, violates required process, or lacks wider IETF consensus despite working-group agreement.
  • Blocking authority should be auditable as a controlled decision: every issue needs a precise claim, supporting evidence, scope, affected requirement, response owner, release condition, review deadline, and public disposition. A preference, stylistic edit, unexplained concern, or copied external review does not qualify.
  • The 2025 ballot procedures reduce the possibility of a permanent personal veto by allowing an unsupported single DISCUSS to be overridden at a second telechat. That is useful, but accountability should begin when the position is posted, not only when delay becomes serious enough to trigger an override.

The stop belongs in the standards process

An Internet standard can fail quietly. Two implementers may read the same sentence and build incompatible state machines. A congestion-control choice may appear local until widespread deployment transfers cost to networks that did not participate in the working group. A mandatory behavior may contradict an older RFC. A security property may be asserted but not supplied. An allocation rule may leave a registry unable to distinguish legitimate use from collision. These are not cosmetic faults. Once a specification becomes an archival reference and deployment begins, correction becomes slower, more expensive, and less complete.

The IETF therefore needs a point at which someone with a wider view can say that a document is not ready. RFC 2026 placed that responsibility clearly. A standards action must be approved by the Internet Engineering Steering Group, and the IESG must determine whether the specification meets the applicable criteria and whether its technical quality and clarity are appropriate for the proposed maturity level. RFC 2026 also says there is no algorithmic guarantee that a document will enter or advance along the standards track. Experienced collective judgment is an essential component of the decision.

That design is defensible. Working-group consensus is powerful evidence because the group has usually invested the most time and domain expertise. It is not conclusive evidence that every cross-area risk has been found. Entities can share assumptions that are invisible in the text. The group can optimize for its protocol and underweight effects on transport, operations, security, applications, or the architecture as a whole. It can become accustomed to wording whose history is known to insiders but whose meaning is unclear to an implementer arriving later.

Final review is valuable precisely because it introduces informed readers who are not fully socialized into those assumptions.

The governance difficulty is equally clear. If a final reviewer can block publication, the reviewer holds consequential power over years of volunteer work, vendor plans, deployment schedules, research, procurement, and interoperability. That power should not be weakened until it cannot prevent harm. It should be disciplined so that the community can distinguish a technical backstop from a preference, a resolvable question from an open-ended objection, and a short quality intervention from an unmeasured delay.

The right objective is not fewer DISCUSS positions in the abstract. A low count could mean excellent early review, or it could mean that serious defects are waved through. A high count could mean vigilant review, or it could mean that blocking has become routine. The objective is a reliable decision system: serious issues are stopped, weak objections do not hold the queue, valid blocks clear when the stated condition is met, and the record permits later evaluation of whether the system behaved consistently.

What a DISCUSS does now

The name can sound softer than the mechanism. Under the active IESG ballot procedures for documents, a DISCUSS can mean that an Area Director cannot in good conscience send the document forward unless specified issues are fixed, or that an important matter needs discussion. The explanatory text must be entered in the Datatracker when the position is posted and communicated to affected parties. For a Standards Track or Best Current Practice document under the normal procedure, approval requires at least one Yes, support from at least two-thirds of non-recused Area Directors through Yes or No Objection positions, and no DISCUSS position.

This makes a DISCUSS operationally different from a Comment. A Comment may identify an improvement, ambiguity, or concern, but it is non-blocking. An Abstain records that an Area Director cannot support publication while not preventing the rest of the IESG from proceeding. A Defer asks for more review time. A Recuse addresses conflict of interest. The categories matter because they attach different consequences to the reviewer's judgment. Calling every concern a discussion would erase the difference between advice and compulsory correction.

The current procedure also limits the endurance of an isolated block. If a document returns for a second IESG telechat, only one DISCUSS remains, no other Area Director has expressed support for it, and the document otherwise has enough approving positions, the Single Discuss procedure allows the document to be approved. Another Area Director can prevent that result by recording support for the DISCUSS with explanatory text. The IESG Chair may also invoke an alternate procedure in a deadlock, although the procedure is deliberately demanding.

This is an important change in the institutional picture. A single Area Director can stop approval under the normal ballot, but not necessarily forever and not without the possibility that peers will test the objection. The system contains both a brake and a release path. Yet a formal override is an expensive late control. It asks the full steering group to spend attention on a conflict that may have begun as an unclear sentence, an unstated acceptance test, or a response that sat unread. Good governance should make most valid blocks resolvable before an override question arises.

The IESG's guidance on handling ballot positions describes the intended working relationship. The authors drive the discussion; the DISCUSS-holding Area Director must review and respond in a timely way; and the responsible Area Director helps. Needed changes generally lead the reviewer to change the position after a revised draft or public working copy is available. Sometimes the outcome is education of the reviewer rather than a text change. That description is constructive, but it still relies heavily on human follow-through. Auditability is the means by which a reliance on good conduct becomes a dependable procedure.

Why the backstop is technically valuable

The strongest case for a blocking position is not institutional tradition. It is the cost of avoidable technical error. A protocol specification is an instruction to many independent actors who may never speak to one another. Ambiguity does not remain on the page; it becomes divergent code. A security omission does not remain a drafting defect; it becomes an attack surface. An operational blind spot can shift troubleshooting and failure costs to people who did not design the mechanism. A standards body that cannot stop a consequential defect before publication is not protecting implementation freedom. It is exporting uncertainty.

The active DISCUSS criteria statement identifies the types of problem that justify blocking a Protocol Action. They include specifications that are impossible to implement, technical or clarity flaws likely to prevent correct operation, vagueness likely to defeat interoperability, widespread harm through congestion or scalability, serious security holes, serious operational problems, unexplained architectural departures, failures against document requirements, missing normative references, failure to meet the designated standards-track criteria, failures in required advancement process, and the absence of IETF-wide consensus on the technical approach.

These categories are substantial. They concern whether the document can perform its function, whether independent implementations can cooperate, whether deployment harms shared infrastructure, and whether the document has passed the process that gives an IETF standard legitimacy. A reviewer who identifies such a problem is not overturning consensus merely by personal taste. The reviewer is showing that the decision record lacks a necessary answer.

Cross-area review is particularly important because many costs are external to the originating group. A routing optimization may alter transport behavior. An application convention may create operational or privacy consequences. A seemingly narrow registry action may constrain future protocol design. A security mechanism may depend on deployment assumptions that operators cannot meet. The working group can be entirely competent within its domain and still need a reviewer who asks what the design does elsewhere.

Freshness also has value. IETF guidance notes that an Area Director often sees a document for the first time near telechat review and may not know the long history behind a negotiated phrase. That lack of context can be frustrating to authors, but it approximates the position of a future implementer. If the specification works only when accompanied by years of mailing-list memory, it is not yet a sufficient archival instruction. A well-grounded DISCUSS can therefore reveal that social knowledge has not been converted into public technical text.

None of this requires reverence for the reviewer. The value lies in the question and the evidence, not in the office holder's status. An Area Director can misunderstand the protocol, miss prior discussion, overestimate a risk, or propose a cure that introduces a different defect. The backstop becomes stronger when the objection can be tested and, where wrong, cleared without loss of face.

The published criteria already reject personal preference

The same statement that authorizes blocking also draws a boundary around it. It says that disagreement with an informed working-group choice among technically sound approaches is not a DISCUSS criterion. Nor are stylistic issues, pedantic corrections to non-normative text, requests for additional informational references, or a feature whose motivation is not clear enough but whose behavior is technically sound. An Area Director should not simply repeat an issue already considered unless it was not properly addressed.

The statement also rejects two practices that are especially relevant to accountability. First, an unfiltered external review cannot simply be pasted into a blocking position. The Area Director is expected to evaluate, understand, and concur with the issue. Delegated expertise may inform the decision, but the accountable office holder must own the claim. Second, an "IOU" DISCUSS is not appropriate. A reviewer cannot block now and promise to explain later. If more time is needed to identify the issue, Defer is the relevant tool.

These are sound rules because the burden of a block is not merely emotional inconvenience. It changes the status of the document, creates work for authors and chairs, consumes review capacity, and may delay dependencies. The stronger the procedural effect, the more precise the reason should be. The criteria correctly reserve DISCUSS for defects that bear on implementability, interoperability, security, operations, architecture, status, process, or IETF-wide consensus.

There remains a wide zone of judgment inside those categories. How serious must an ambiguity be before multiple implementations are unlikely to interoperate? How probable must widespread damage be? When is an architectural departure satisfactorily explained? When does a Last Call comment remain substantively unresolved? When does area consensus fail to represent IETF consensus? No list can eliminate these questions, and it should not try. Technical governance would become brittle if every risk were reduced to a mechanical threshold.

But discretion is not the opposite of auditability. A discretionary decision can show the facts considered, the inference drawn, the severity assigned, the alternatives evaluated, and the condition that would change the result. That record allows peers to assess consistency without pretending that two protocols present identical facts. It also allows the working group to respond to the actual concern rather than reverse-engineering the reviewer's state of mind.

The criteria should therefore be treated as a classification system, not merely a citation. A DISCUSS should state which criterion is implicated and why. If several are implicated, each should be separated. A sentence that says "security needs more work" is not enough. A useful record says which property is missing, the deployment condition under which it matters, the consequence, the normative text involved, and the evidence or analysis supporting the conclusion.

Consensus is about answering issues, not exhausting objectors

RFC 7282 provides an important standard for judging the relationship between working-group consensus and a late objection. Rough consensus does not require unanimity. It requires that issues be addressed, though every preferred remedy need not be accommodated. Counting supporters is not a substitute for understanding objections. Even a concern whose original proponent has left the conversation does not become irrelevant if the technical issue remains unanswered.

This principle supports both sides of the DISCUSS boundary. It supports the Area Director who identifies a serious issue that a popular working-group decision overlooked. A large hum cannot make an unsafe field size valid or an unspecified state transition interoperable. It also protects the working group from a reviewer who repeats a concern without engaging the answer already developed. Once the group has addressed the technical issue with sufficient evidence and reasoning, continued personal disagreement is not automatically a reason to block.

The key distinction is between an objection and an open issue. An objection belongs to a person; an issue belongs to the specification. The identity, seniority, persistence, or rhetorical force of the objector should not determine the result. The question is whether the document contains or creates a defect that remains material after the response. A good DISCUSS record makes that distinction visible by tracking the technical proposition rather than the interpersonal dispute.

This also means that clearing a DISCUSS should not require the objector to declare that the working group's design is now their favorite. The relevant release condition is that the serious issue has been corrected, adequately explained, bounded, or shown not to exist. The Area Director may continue to prefer another design and post an Abstain or Comment where appropriate. Blocking authority should end when the blocking criterion no longer applies.

Conversely, capitulation by authors is not proof of resolution. Authors may accept text simply to escape delay, even when the change is technically unnecessary or harmful. The accountable reviewer should explain why the adopted revision satisfies the issue and check for side effects. If the change merely repeats a phrase without supplying implementable behavior, the issue remains. If it introduces ambiguity elsewhere, clearance should wait. The objective is not assent to the office holder; it is a stronger public specification.

An auditable process therefore records the issue across revisions. What did the draft say when the position was posted? What technical outcome was feared? What response did the working group provide? What text or analysis changed? Why did that change meet the condition? This is more useful than a binary history showing only that a DISCUSS appeared and later disappeared.

A blocking reason should be a structured technical claim

The minimum unit of accountability is one separable claim. A ballot position can contain several points, but each blocking point should be stated independently so that one resolved issue does not remain hidden inside a paragraph with another. Combining a security defect, a missing normative reference, and a non-blocking editorial suggestion in one block makes ownership and release unnecessarily difficult.

Each claim should contain seven elements. First is the affected draft version and section, including the precise normative behavior where possible. Second is the applicable DISCUSS criterion. Third is the technical proposition: what the text requires or fails to require. Fourth is the consequence under a described implementation or deployment condition. Fifth is the evidence, which may be a contradiction, a protocol trace, an architectural rule, an operational example, a security analysis, an unresolved Last Call record, or another reproducible basis. Sixth is the severity and scope.

Seventh is the condition under which the reviewer will clear or narrow the position.

Consider an interoperability concern. "This is ambiguous" is a conclusion. A structured claim would identify two reasonable readings of a requirement, show that each leads to a different wire behavior, explain why peers following those readings cannot interoperate, and state that the position will clear when the state transition and error handling are made unambiguous. The working group can then correct the text, demonstrate that one reading is impossible, or show that both behaviors are deliberately interoperable.

The same discipline applies to security. A general demand to "strengthen security considerations" can expand without a stopping point. A structured claim identifies the protected asset, adversary capability, failed assumption, exploitable behavior, and required property. The release condition might be a normative validation rule, a downgrade prohibition, a threat boundary, or evidence that the alleged attack is outside the protocol's stated scope. The exact remedy can remain open to the working group; the property that must be supplied should not.

For process objections, the record should be equally concrete. Which Last Call issue remains unresolved? How is the document outside charter? Which required review did not occur? Process cannot be invoked as atmosphere. It must identify the missing step and why that omission is substantive enough to block advancement.

Structured claims do not force every Area Director to write a legal brief. They reduce total work. Authors spend less time guessing. The responsible Area Director can triage accurately. Peers can decide whether they support the block. A successor can evaluate an inherited position. Later reviewers can see whether similar issues were treated similarly. Precision at posting is cheaper than ambiguity sustained over several telechat cycles.

The release condition is part of the decision, not an afterthought

The power to block is only half of a quality-control mechanism. The other half is the rule for release. A gate with no observable opening condition is not a technical control; it is continuing discretion. The active ballot guidance says explanatory text must be self-contained, and the handling guidance describes clearance after a new draft or public working copy contains the necessary changes. That practice should be made explicit for every material point.

A release condition should describe the result required, not dictate wording unless exact wording is essential. An Area Director can properly require that independent implementations derive the same behavior, that a downgrade path be closed, that a registry action be defined, or that a conflict with another RFC be resolved. The working group normally retains authority to choose among technically sufficient solutions. This preserves the IESG's backstop role without turning final review into individual editorship.

Conditions should also be divisible. If three issues are posted and two are fixed, the public record should show that two are cleared and one remains. The remaining point should be restated against the latest draft. This prevents a resolved concern from continuing to cast an undefined shadow over the whole document and makes the actual work queue visible.

The reviewer should state whether clearance requires revised text, a working-group consensus call, additional expert review, an implementation demonstration, a liaison response, an IANA confirmation, or only an explanation. Different evidence types have different lead times. Authors should not discover after providing a detailed explanation that only a new draft can clear the position, or after publishing a revision that a new security review is also required.

Release conditions can evolve when new facts appear, but the change must be explained. If a proposed correction reveals a second defect, that is a legitimate new issue. It should be posted as such, with its own evidence and clock, rather than silently expanding the original condition. If the reviewer changes their theory of harm, the record should distinguish refinement from replacement. Otherwise the working group experiences a moving target even when the technical investigation is sincere.

Clearance should include a short disposition. "Resolved by version 14" is better than nothing, but a useful note says what changed or what explanation established. If no change was needed because the Area Director misunderstood the text, the record should say so without embarrassment. A system that can publicly correct its reviewers is more credible than one that erases mistakes through a ballot flip.

Time is a technical governance variable

Delay is not proof of abuse. Some issues deserve sustained work. A cryptographic flaw, a congestion risk, or a cross-protocol interaction may require experiments, expert review, and working-group reconsideration. The 2014 criteria statement acknowledged that DISCUSS positions can take weeks or months when revisions and rechecking are necessary. Sparing use is recommended because the work is real.

Yet elapsed time changes the effect of even a valid decision. A one-week block with an active exchange is different from a three-month block waiting for a response that no one has been assigned to provide. Dependencies accumulate. Authors leave. Implementations diverge around an unpublished draft. Other documents wait for a normative reference. Operational need may be met through proprietary behavior while the open specification stalls. Time is therefore part of the impact mechanism and should be measured.

The correct measure is not a crude deadline after which every DISCUSS expires. Automatic expiration could release a serious flaw simply because it was difficult. Instead, the record should distinguish active technical time from administrative waiting. Useful timestamps include posting, first author acknowledgment, first substantive response, reviewer reply, revised text, expert input requested and received, working-group decision, clearance, and any telechat reconsideration.

Service expectations can then be modest and fair. The Area Director should acknowledge a substantive response within a stated interval or identify when review will occur. Authors should acknowledge the position and name the person coordinating the response. The responsible Area Director should intervene when either side is silent. Long-running issues should receive a periodic public status note that identifies the open technical question and next action.

Age should trigger attention, not automatic blame. A 60-day security analysis with weekly work may be healthier than a 10-day ambiguity that spent nine days without an owner. Metrics should expose queue state so that the IESG can allocate help. They should not reward reviewers for clearing positions prematurely or authors for accepting bad text.

The Single Discuss procedure supplies a backstop when an unsupported position remains at the second telechat. Its effectiveness depends on the quality of the record. Other Area Directors cannot responsibly support or decline to support an issue if the claim, response, and release condition are unclear. Better auditability therefore strengthens the override procedure without making override routine.

The responsible Area Director is the procedural bridge

A DISCUSS is often described as a conversation between the holding Area Director and the authors, but the responsible Area Director has a crucial institutional role. They brought the document forward, know the working-group history better than most peers, and can translate between a late cross-area concern and the group's prior reasoning. The handling guidance expressly expects the responsible Area Director to help.

That role should not become automatic advocacy for publication. The responsible Area Director may conclude that the concern exposes a real defect and should help the group address it. Nor should the role become deference to the blocking colleague. If the issue is outside the criteria, already answered, or supported by incorrect facts, the responsible Area Director should say so and help assemble the record.

The bridge function has four parts. First, ensure every blocking point reaches the authors, chairs, shepherd, and working group where appropriate. Second, identify an owner and response path. Third, connect the concern to earlier discussion so the reviewer sees whether an issue was considered and on what evidence. Fourth, escalate stalled or moving conditions to IESG attention before delay becomes institutional drift.

Working-group chairs and document shepherds also matter. RFC 4858 formalized document shepherding as a way to improve communication and follow issues during publication. A shepherd can maintain the claim-by-claim response, verify that proposed revisions reflect working-group consensus, and distinguish blocking changes from optional edits. The shepherd should not privately negotiate away a substantive design issue that belongs before the group.

This division of labor limits bilateral capture. If only the author and one Area Director negotiate, the working group may not know that its consensus text changed or why. If every detail must return to a full consensus call, trivial clarifications can become slow. The responsible Area Director and shepherd can identify which changes are technical corrections within established consensus and which change the decision enough to require renewed group review.

Auditability does not require publishing every tentative email. It requires that consequential decisions return to a durable public record: the issue, the response, the accepted correction, the reason for clearance, and any renewed consensus step. Private conversation can accelerate understanding; it should not be the only place where the governing reason exists.

Reviewer networks extend capacity but do not transfer accountability

Area Directors necessarily rely on directorates, review teams, subject-matter experts, IANA staff, liaisons, and experienced entities. Modern protocols cross too many domains for a small steering group to possess every relevant expertise. The review network is a strength when it finds a problem before deployment and broadens the evidence available to the responsible decision maker.

But a network can obscure the source and ownership of a block. An expert review may use "major issue" according to one team's taxonomy. That label does not automatically make the point DISCUSS-worthy. The criteria statement is explicit that an Area Director should not paste an external review without understanding and defending it. The office holder converts advice into a blocking decision and remains accountable for that conversion.

The public record should therefore identify the provenance of the technical analysis without turning expertise into a vote. If a security directorate review raised the concern, link it. If the Area Director's concern differs from the reviewer’s wording, state the adopted claim. If experts disagree, summarize the point of disagreement and the evidence used. A reviewer who asked not to own a decision should not be represented as having made it.

Conflicts also need visibility. Recuse exists for an Area Director who is an author, chair, or otherwise an interested party. External reviewers can have relevant interests too: they may maintain a competing technology, work for an implementer, or have participated in the disputed design. Such experience may be precisely why their analysis is valuable. Disclosure allows the claim to be judged with context; it does not automatically disqualify the evidence.

The test remains technical. Can the alleged behavior be reproduced? Is the cited architectural constraint applicable? Does the deployment scenario fit the protocol's scope? Are the security assumptions stated? A network of respected names cannot substitute for this analysis. Conversely, a valid defect does not disappear because the person who found it has an interest. Provenance and reproducibility together produce a stronger record than either status or suspicion.

Override is peer accountability, not a rebuke

Some standards communities treat override as a constitutional crisis. That makes a formal safeguard harder to use and can leave pressure to operate informally. The current Single Discuss procedure offers a more proportionate design. An unsupported single block at the second telechat can be overridden if the document otherwise has enough support; another Area Director can preserve the block by explicitly supporting it.

This rule converts a personal position into a collective test after time for discussion. It does not prove the holding Area Director was irresponsible. Peers may conclude that the concern is valid but not blocking, that the working group answered it, that the residual risk is acceptable, or that continued delay is not justified. Equally, one peer's documented support can show that the issue deserves continued blocking analysis.

For this to work, support should attach to the technical claim rather than collegial instinct. An Area Director who supports the DISCUSS should indicate which point they support and why it remains unresolved. A statement of support should not merely preserve more time. If more review time is the need, the procedure should identify that need and its expected output.

The holding Area Director should have a final opportunity to update the issue against the current draft and response before the second telechat. The responsible Area Director should summarize the disposition. The chair should ensure that conflicts and recusals are visible. The resulting record should show whether the block was cleared by correction, withdrawn after explanation, supported by peers, or overridden under procedure.

An override should not erase the concern. The published history can preserve the minority technical view, especially where deployment experience may later prove it important. Standards governance must decide under uncertainty. Recording a reasoned dissent is not the same as allowing it to control the outcome indefinitely.

The same norm should apply when an Area Director voluntarily changes to Abstain. That position can state that the reviewer cannot support publication but accepts that the IESG may proceed. The transition from DISCUSS to Abstain is not capitulation. It is a precise judgment that the concern no longer meets, or cannot sustain, the threshold for blocking collective action.

Appeals are necessary but too late for routine control

RFC 2026 provides a path for disputes. Working-group disagreements begin with chairs, can move to Area Directors, then to the IESG, and ultimately to the Internet Architecture Board on procedure and technical merit. Process complaints about IESG action can be raised with the IETF Chair, considered by the IESG, and appealed further. These routes protect openness and fairness when normal resolution fails.

But appeal is a poor substitute for a clear ballot record. It is costly, adversarial, and slow. An appellant must reconstruct what happened, identify the decision being challenged, and argue that ordinary discussion has failed. If the release condition was never stated or changed privately, the dispute becomes partly about facts of process rather than technical merit.

The better model is appeal-ready without appeal-dependent. Every DISCUSS should already contain enough information for a neutral reader to identify the criterion, issue, evidence, response, and status. That discipline may prevent escalation because misunderstandings become visible earlier. If appeal remains necessary, the reviewing body receives a bounded record rather than competing narratives.

Appeal data can also improve governance without ranking individuals. How many disputes concerned moving conditions, unexplained delay, criterion classification, or disagreement over technical evidence? Which procedural points recur? Are certain document classes more likely to produce late cross-area issues? These questions help refine review systems while preserving the independence needed for hard judgments.

Transparency must not turn appeal into a popularity contest. The IETF does not decide technical validity by the number of supporters. Public records should enable reasoned participation, not campaigns against a reviewer. Personal attack would make Area Directors less willing to raise difficult risks and would weaken the very backstop that accountability is meant to preserve.

A practical audit record

A useful public record can be compact. For each blocking point, the Datatracker or linked ballot note should show a stable issue identifier; draft version and section; criterion; concise technical claim; evidence or analysis; severity and affected scope; date posted; holding Area Director; responsible Area Director; response owner; release condition; required form of evidence; status; last substantive action; next action and expected date; and final disposition.

The record should distinguish states such as awaiting author response, awaiting reviewer response, revised draft needed, working-group decision needed, expert review pending, external dependency pending, ready for clearance, supported for continued block, and cleared. "AD follow-up" alone can conceal very different conditions. A small vocabulary makes delay diagnosable without imposing a rigid solution.

Aggregate measures should focus on system health. Median and upper-percentile time to first substantive response can reveal communication failure. Time by waiting state can reveal whether authors, reviewers, external experts, or consensus steps are the bottleneck. The share of positions that clear through text change, explanation, withdrawal, Abstain, peer-supported continuation, or override can show how the mechanism is used. Repeated criterion categories can guide earlier review.

Metrics must be interpreted carefully. A reviewer working on unusually complex security documents may have longer durations. A working group with excellent directorate review may produce few DISCUSS positions because defects were corrected earlier. A high rate of clearance by explanation could indicate useful fresh readers or limited public evidence familiarity. No single measure should become a performance quota.

Qualitative sampling is therefore necessary. Periodically, the IESG and community could review anonymized or ordinary public cases across areas: Was the criterion clear? Did the evidence support blocking? Was the release condition stable? Did the accepted change address the claim? Was the time proportionate? Did the record preserve working-group authority? The purpose is calibration, not reversal of settled standards.

Audit should also look upstream. If the same class of issue repeatedly appears at final review, a directorate, checklist, shepherd question, or cross-area review can move it earlier. Success is not merely resolving blocks faster. It is finding serious issues at the least costly stage while retaining final authority for defects that survive.

Five rules for a defensible technical veto

The first rule is classification before consequence. Every blocking point should name the relevant DISCUSS criterion and explain why a Comment, Defer, or Abstain is limited public evidence. This keeps personal preference and useful but non-essential editing outside the veto channel.

The second is evidence before authority. The position should show the technical path from text to harm: ambiguity to incompatible behavior, missing rule to security failure, design choice to operational damage, procedural omission to unreliable consensus, or area decision to unresolved IETF-wide conflict. Office does not replace analysis.

The third is release condition at posting. The working group should know what property must be demonstrated or corrected and what evidence will be accepted. The reviewer can refine the condition when facts change, but must record why. Resolved points should clear independently.

The fourth is a visible owner and clock. Authors, the holding Area Director, the responsible Area Director, the shepherd, and any expert dependency should have named next actions. Elapsed time should be decomposed into active investigation and waiting. Old positions should receive status review, not automatic expiry.

The fifth is collective review without stigma. A single DISCUSS is a valid initial brake, not a private entitlement to indefinite control. Peer support, clearance, Abstain, the Single Discuss procedure, alternate balloting, and appeal are normal components of a decision system. Their use should preserve the technical record and the dignity of entities.

Together these rules make the veto both stronger and narrower. Stronger, because a serious issue arrives with evidence and cannot be dismissed as personality. Narrower, because the block ends when the stated criterion is met and cannot drift into unrelated improvements. That is the balance required by an institution that values both rough consensus and engineering quality.

Stop the defect, not the institution

The IESG's blocking authority is sometimes framed as a conflict between central review and working-group autonomy. That framing misses the possibility of accountable interdependence. Working groups develop specifications and establish informed consensus. Area Directors contribute cross-area judgment and final process responsibility. Neither can perform the other's role completely.

RFC 2026 was right to preserve experienced collective judgment. RFC 7282 was right to insist that issues, not head counts, determine whether consensus is sound. The DISCUSS criteria were right to reserve blocking for implementability, interoperability, security, operations, architecture, process, status, and wider-consensus failures while excluding taste and style. The current ballot procedures are right to require explanatory text and provide a route past an unsupported single block.

The remaining task is operational accountability. A blocking reason should be precise enough to answer. A release condition should be known before the work begins. The waiting party and next action should be visible. A correction should clear the issue it was meant to correct. A misunderstanding should be acknowledged. A sustained block should attract peer examination before it becomes inherited delay.

These requirements do not make technical review timid. They give the reviewer a defensible record when stopping a dangerous document. They give the working group a fair path to correction. They give peers a basis for support or override. They give future implementers evidence that the standard was not merely popular, but tested at the point where its defects could still be repaired.

A DISCUSS should be able to stop a standard. It should not be able to stop explanation. The legitimacy of the veto lies in that distinction: hold the document when the engineering requires it, state exactly why, and release it when the public condition has been met.

Sources