Summary

  • draft-ietf-procon-2026bis-11, posted on 1 July 2026, remained in Working Group Last Call on 27 August. It carries forward the variance architecture in RFC 2026, but it is still a consolidation draft rather than an approved replacement for BCP 9.
  • A responsible working group, or an ad hoc committee where no responsible group exists, may recommend a variance for one specification facing a deadlock or a gap in procedural guidance. That recommendation opens review; it does not grant the exception.
  • The IESG must weigh technical merit, the ordinary process, alternatives, costs, collateral effects, precedent effects and the narrowest possible scope. The proposal becomes its own Internet-Draft, receives an extended Last Call of at least four weeks and, if approved, is sent for publication as a BCP. Appeal remains available.
  • Specified delays, openness, fairness, consensus, proper meeting and mailing-list records, and several core process mechanisms cannot be waived. A defensible variance is therefore a versioned receipt bound to one specification, not a silent general amendment, an automatically inherited precedent or an order to deploy.

The row that outlived its case

A policy register likes a single answer. A requirement is mandatory or optional. A document passed or failed. A gate is open or closed. A variance resists that convenience because it requires two propositions to remain true at once: the requirement continues to govern the ordinary case, and a named specification has been allowed to proceed despite not meeting it in the ordinary way.

Collapse those propositions into one field and the exception starts legislating. An administrator marks the requirement waived. A template copies the value. A later specification enters the same workflow and finds the requirement already disabled. No responsible working group recommended a variance for the later text. No alternatives were tested. No extended Last Call exposed its collateral effects. No IESG decision belongs to it. Yet the operational system behaves as if the general rule had changed.

Human memory makes the same mistake. A difficult decision becomes a familiar practice; the practice becomes a precedent; the precedent is retold without its conditions; the shortened story enters a checklist. The formal BCP remains untouched, but the institution's working model now applies a different rule. That is governance drift by data loss.

The proper model keeps two objects. The general process rule has its own text, version, authority and revision path. The variance record names the target specification and revision, the exact provision, the recommending body, the analysis, the consultation period, the restrictions, the decision and any appeal. The second object may inform a later case. It may not decide the later case merely because a database can find it.

This is also the right way to understand precedent. RFC 2026 tells the IESG to consider the precedent effects of a proposed variance. That instruction recognizes that one case can alter expectations, bargaining positions and future costs. It does not create a self-executing permission for the next specification. Precedent effect is a risk to assess, not an inheritance function.

A bounded exception is therefore not a failure of procedural stability. It is one of stability's conditions. A rule without any exit may break against a case its authors did not anticipate. An exit that changes the default whenever it is used destroys the rule. Separate records preserve both judgment and boundary.

The status label is part of the evidence

The current consolidation work illustrates why state cannot be summarized carelessly. The Datatracker document page lists draft-ietf-procon-2026bis-11 as an active Internet-Draft in the PROCON working group. Its Intended RFC status field shows None, while the draft text's own header names Best Current Practice as the intended status. Those are two recorded facts, not proof that a final status decision has already been made.

Revision -11 was posted on 1 July 2026 and is scheduled to expire on 2 January 2027 if it is not updated or advanced. The history records the move into Working Group Last Call on 21 May, when the document was at revision -08. On 27 August the working-group state remained In WG Last Call; the IESG state was I-D Exists, with no telechat date. These facts show a serious working-group draft under review. They do not show IESG approval, RFC publication or an effective successor BCP.

If completed and approved, 2026bis would consolidate and obsolete several process RFCs, including RFC 2026, and update RFC 7475. The PROCON charter explains the maintenance problem: more than twenty RFCs have updated the two foundational texts, RFC 2026 and RFC 2418, dispersing the process across a long chain. The working group is chartered to combine that chain and verified errata into readable successors. Only two additional families of non-editorial change are named; other substantive additions require rechartering.

Section 11 of revision -11 retains the variance architecture. It does not invent a new authority in 2026. Section 9 of the published RFC 2026, part of BCP 9, has contained the essential structure since 1996. The new draft consolidates, renumbers and modernizes terminology; its change log does not present variance as a new policy experiment.

A trustworthy governance ledger must therefore carry three states without overwriting any of them. RFC 2026 is the current published baseline. 2026bis-11 is a proposed consolidation under working-group review. A future successor RFC, if approved and published, would change the baseline at that attributable publication event. A draft can show direction. It cannot be used as evidence that the journey is already complete.

Recommendation, review and decision belong to different actors

The variance procedure begins close to the specification but does not end there. The working group responsible for a specification may recommend a variance. If no working group is responsible, an ad hoc committee may make the recommendation. That origin matters: the body most familiar with the technical problem must explain the deadlock or the place where the process supplies no guidance.

Proximity does not turn recommendation into authorization. The working group cannot convert its own difficulty into an approved exit by changing a label. Its recommendation sends the question to the IESG. The IESG then considers whether the expected benefits to the Internet community exceed the costs of failing to comply with the procedural requirement.

The required inquiry is wider than whether the specification is technically good. It includes technical merit, whether the goals of the ordinary process can still be met without a variance, other alternatives, the costs of each path, collateral consequences, precedent effects and whether a narrower exception would work. The IESG may grant relief from only some provisions and may add restrictions.

That architecture blocks several shortcuts. Years of useful engineering do not prove that ordinary review has become impossible. A near-term milestone does not by itself justify less public scrutiny. Strong working-group support does not identify every external effect. A superficially similar earlier case does not discharge the new case's burden of proof. Technical quality is relevant; it is not a substitute for process analysis.

Authority remains bounded at every step. The working group owns the recommendation. The IESG owns the assessment and decision. Participants own their arguments. A later appeal has its own applicant, question and disposition. None of these roles can be reconstructed accurately from a single status called exception granted.

That distinction reflects a broader discipline in Internet governance. Participation supplies knowledge and evidence; it does not automatically create authority. Voting or rough consensus authorizes only within the body's actual remit. Competence and restraint, rather than the size of a room, make a technical decision credible. A variance does not expand those remits. It makes their boundaries more important.

Publicity is a chain of custody

An exceptional decision is easy to announce and hard to audit. RFC 2026 reduces that gap by distributing the record across a series of public acts.

The proposed variance must describe the perceived problem, identify the exact provision creating the difficulty and set out the IESG's consideration. It is issued as an Internet-Draft, giving the proposal a public identifier, text and version history. The IESG then announces an extended Last Call of no less than four weeks. After that period, it makes a final determination and announces the outcome to the IETF. If approved, the variance is forwarded for publication as a BCP. The appeal procedures continue to apply.

Each step proves something different. The working-group recommendation shows who asked for review and for which specification. The Internet-Draft fixes what was proposed. The Last Call proves that a minimum public review window existed; it does not prove consent by silence. The IESG announcement attributes the decision. Publication stabilizes the approved case. An appeal, where brought, creates another record with its own claim, reviewer and result.

The four-week minimum is not ceremonial waiting time. It gives people outside the immediate drafting circle an opportunity to inspect the precise departure, test the alternatives and identify spillovers. The more urgent an exception appears, the more important it is that urgency not become a device for removing review of the urgency claim itself.

RFC 7282 adds a useful warning about rough consensus. The number of supportive messages is not the decisive fact. The substance of objections and the way they were addressed matter. Ten brief endorsements do not automatically answer one structural objection; one objection does not create an automatic veto. A variance receipt should preserve the argument and its disposition, not merely the message count.

This public chain is intentionally costly. If the exceptional route is cheaper than the ordinary route, it will become a parallel normal process. Versioned text, a long review window, stated reasons, a final announcement and the possibility of appeal make applicants show both why an exit is necessary and why it stops where they say it stops.

The floor an exception cannot remove

The strongest part of a variance mechanism is not the discretion it provides. It is the floor that discretion cannot cross.

RFC 2026 says a variance may not reduce a delay that the process expressly specifies. It may not waive openness, fairness or consensus. It may not remove the requirement to keep proper records of meetings and mailing-list discussions. It also protects named core provisions dealing with BCP review, initiation of action, IESG review, publication, conflict resolution, appeals and the variance mechanism itself. 2026bis-11 carries that protected floor into its renumbered structure.

The logic is practical. If an exception could waive the publicity, recordkeeping and review needed to assess the exception, it would destroy evidence at the point of greatest institutional risk. The organization could still claim to have used a formal variance procedure, but an outsider could no longer distinguish bounded judgment from an opaque exercise of power.

The floor does not guarantee agreement. It does not strip the IESG of judgment, and it does not turn every participant into a principal with a veto. It promises something narrower and more useful: the exercise of judgment will be visible, attributable, recorded and challengeable, and the exception cannot erase the means by which it is checked.

The current draft's exclusions should therefore be treated as executable requirements, not scene-setting language. A workflow should refuse to finalize a variance if its Last Call was shorter than the required minimum, if the target provision is not named, if the record omits the responsible recommendation, or if the proposal attempts to waive one of the protected elements. A prose promise without a corresponding state check is vulnerable to the same silent drift as the exception itself.

The variance receipt

A useful variance record should survive copying, indexing and later citation without losing its scope. That requires more than a title and an outcome.

The identity layer should record a variance identifier and version; the target specification's name, revision and content hash; the responsible working group or ad hoc committee; the recommendation text and date; and the exact BCP provision at issue. It should distinguish whether the problem is a deadlock or a gap in guidance, name the unmet requirement and explain why the ordinary route cannot resolve it.

The reasoning layer should preserve the technical-merit assessment, the expected benefits and costs, alternatives considered and rejected, collateral consequences, precedent effects, the chosen scope and any extra restrictions. Without the rejected alternatives, a later reader cannot tell whether the departure was necessary or merely convenient.

The public-process layer should include the variance Internet-Draft identifier and hash, the start and end of Last Call, material objections and their dispositions. The decision layer should record the IESG determination and announcement, the published BCP identity if approved, appeal status and decisions, the one-case boundary and any terminating condition.

Two negative statements should travel with the receipt. First, it does not authorize another specification. Second, it does not prove that any operator, vendor, public authority or open-source project has adopted or deployed the technology.

Publication as a BCP can otherwise cause confusion. The publication form makes an approved variance stable, public and citable. It does not enlarge the substance from the named specification into a reusable general rule. A permanent revision of the general process follows the ordinary BCP process. The approved case is a BCP-shaped receipt, not a stealth replacement for the process BCP.

The receipt also preserves the possibility of honest reform. If multiple, genuinely comparable variances accumulate, the pattern may be evidence that the general rule needs amendment. That conclusion requires separate records. When every exception has already changed the default, the institution loses both the rule and the evidence needed to decide whether the rule should change.

IETF process state is not network adoption

A variance addresses how one specification may enter or advance within the IETF standards process. It does not make deployment decisions for operators, enterprises, public agencies, software projects or users.

RFC 9281 describes the roles of working groups, the IESG and other participants in standards work. Those roles do not give an outside actor power to infer a new document state from a variance. In the other direction, RFC 3935 explains that an IETF standard specifies how to do something when a party claims compliance; the IETF does not seek to mandate or police universal use.

The internal process receipt and the external adoption receipt must therefore remain separate. A deployment record needs its own named decision-maker, implemented version, test evidence, rollout scope, date, fallback condition and operating results. A variance can inform that later judgment. It cannot make the judgment or prove that it occurred.

Heng Lu's framework of minimum initial specification, localized future decision and voluntary adoption provides a compatible governance lens. Common coordination should specify the minimum shared boundary; later actors retain ownership of their local decisions and evidence. The framework is used here to interpret authority, not to replace the IETF's procedural sources.

The distinction prevents mandate laundering. Describing a procedural variance as technical endorsement may overstate the IETF's judgment. Describing it as a deployment requirement invents power the IETF does not claim. Describing downstream implementation as proof that the variance was legitimate reverses the evidence chain. Running code can test technical reality; it cannot retroactively supply a missing recommendation, review window or decision.

Sources