Summary
- RFC 3933 created a middle path between informal IESG procedure changes and permanent BCP revision: a scoped experiment, public Last Call, Experimental RFC and explicit sunset.
- Its clock was stronger than its evidence contract. A problem statement, evaluation criteria and a written explanation of success or failure were desirable, but not required.
The deadline was the hard part
In November 2004, RFC 3933 described an institutional problem in engineering terms. The IETF had two ways to change its own machinery. The IESG could act informally under the discretion associated with RFC 2026, gaining speed but sometimes losing alignment with the wider community. Or the IETF could use the same heavy consensus machinery used for permanent process rules, with the working-group structure described in documents such as RFC 2418. That second route supplied review, but demanded commitment before anyone had operational experience.
RFC 3933 proposed a third state: try the rule as a bounded experiment. The official RFC Editor record identifies the memo as BCP 93. Its ancestry reached back to the 1992 organizational changes recorded in RFC 1396, but its mechanism was new enough to matter. A draft would describe a proposed procedure. The IESG would decide whether it was plausible and plausibly useful. A four-week IETF Last Call would expose it to the community. A revised draft would identify and answer issues raised. The temporary procedure would then be announced and published as an Experimental RFC.
The proposal had to carry an explicit sunset, normally no more than a year after adoption. The errata record contains a verified punctuation correction to that sentence, not a change in the rule. At or before the timeout, the IESG would cause the procedure to become a BCP or let it expire. The trial could be limited to selected areas or working groups, containing the blast radius while experience accumulated.
That was the strongest control in the design. A temporary exception could not quietly claim permanence merely because people had become accustomed to it. The clock forced a disposition.
The experiment could begin without a measurable question
The evidentiary side was looser. RFC 3933 called a statement of the problem “desirable but not required.” It treated specific evaluative criteria the same way. The IESG could conclude at sunset that the community generally believed the situation was better or worse. A document describing why the experiment succeeded or failed was desirable, but the authors said it could not realistically be mandatory.
This was not an accidental omission. It was the price of the middle path. Requiring a full research design before every temporary procedural change could reproduce the very weight RFC 3933 wanted to avoid. But the choice created an asymmetry that matters to historical evidence. The procedure had to say when it ended. It did not have to say exactly what observation would count as success, preserve a comparable baseline, or publish the reasoning that connected experience to the final disposition.
A sunset can prevent an experiment from becoming an unreviewed permanent rule. It cannot distinguish among several possibilities after the fact: the mechanism was never used; it was used and worked; it was used and caused harm; it solved a temporary problem; participants routed around it; or institutional attention simply moved elsewhere. The date is evidence about duration. It is not evidence about effect.
RFC 3933 retained important authority boundaries. The IESG's judgment was expected to reflect rough consensus and could be appealed through ordinary procedures. The experiment did not have to apply across the entire IETF. The security section warned against reducing the quality of protocol security review and asked for early detection and correction if such degradation was possible. Yet those safeguards still described admission, scope and correction. They did not guarantee a public outcome ledger.
The ION clock stopped before the document record caught up
RFC 4693 made the tension unusually visible. It proposed IETF Operational Notes, or IONs: documents more durable and referenceable than a random web page but lighter and more changeable than RFCs. The experiment was expected to run for twelve months from publication of the first ION. At the end, the community would be asked whether the series should become permanent, be abandoned, or continue.
The author explicitly rejected objective metrics as not worthwhile, expecting success or failure to be apparent in community attitudes. That was permitted by RFC 3933. It also meant that the experiment's evidentiary contract depended on collective memory and a later interpretation of sentiment rather than a precommitted measurement.
The IESG terminated the ION experiment in March 2008. The RFC record did not close at the same moment. RFC 6393, published in September 2011, later moved RFC 4693 to Historic and obsoleted it. That three-year interval is not proof of operational harm or institutional neglect. It demonstrates something narrower: stopping a procedure and cleaning up the status of the document that authorized it are separate actions. A reader who saw only the old Experimental RFC during the interval needed another source to know the operative decision.
The lesson is not that IONs “failed.” RFC 6393 records termination and documentary closure, while directing readers elsewhere for the motivation. The historical trace can prove the disposition without preserving a full account of the result.
Later experiments wrote stronger evidence contracts
RFC 3933 set a minimum, not a ceiling. RFC 5111 used the model for an eighteen-month Exploratory Group experiment. It capped the trial at three groups and named indicators: progress on charter milestones, positive review leading to IESG formation of a working group, and mailing-list activity as evidence of continuing engagement. Those measures were imperfect, but they made later evaluation less dependent on an unstructured feeling that matters had improved.
RFC 4633 used another eighteen-month window for long-term suspensions from IETF mailing lists. It limited what could persist beyond the trial, required public statements for approved procedures and preserved appeal paths. The document addressed a contested authority over participation. Its date bounded the delegated power, but its continuing Experimental status also shows why a reader must distinguish a procedure's time limit from the current label on the RFC. Later administrative terminology updates in other documents do not themselves supply an experiment report.
The sharpest contrast came during the pandemic. RFC 8713 tied NomCom volunteer eligibility to attendance patterns built around physical meetings. Six consecutive fully online plenary meetings disrupted that proxy. RFC 8989 authorized a fixed-duration experiment for one, or at most two, NomCom cycles.
RFC 8989 did more than set a date. It required the IESG to consult successive NomCom chairs, publish a report, and open a community discussion. It named questions: Was the volunteer pool large and diverse enough? Did enough qualified people volunteer? Did the resulting committee retain useful knowledge of IETF work? Could the new eligibility paths be checked mechanically? It also listed the possible decisions—amend the permanent rule, extend once, run a different experiment, or revert.
In 2023, RFC 9389 incorporated eligibility paths derived from that experiment into BCP 10 and obsoleted RFCs 8788 and 8989. The later BCP is solid evidence of a later normative decision. It is not proof that every experimental effect was quantified, or that RFC 8989 alone caused the change. The stronger claim is enough: an experiment with an explicit reporting obligation left a more inspectable bridge between temporary rule and permanent text.
Expiry, evidence and archival status are three different facts
RFC 3933's durable contribution was not a promise that institutions could discover truth by trying things. It was a way to avoid treating every procedural proposal as either an invisible exception or a permanent constitution. The model localized scope, exposed the trial to Last Call, gave the decision an appeal path, and installed a deadline.
Its weakness was also instructive. Without a required problem definition, baseline, metric and final report, a temporary process may produce experience that never becomes portable evidence. People who participated may know why a rule ended or survived. Later operators, historians and affected parties may see only an Experimental RFC, a sunset sentence and a later status change.
That is where the editorial discipline in Heng Lu's essays on minimum initial specification and voluntary adoption and running-code primacy becomes useful without becoming primary historical evidence. Publication, institutional authorization, adoption and operational effect must remain separate. A process document can authorize a trial. A decision can close or promote it. Only preserved observations show what happened between those points.
The history is therefore more precise than “the IETF experimented with its process.” RFC 3933 made temporary authority legible in time. It did not guarantee that the reason for the final decision would be equally legible in evidence.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
