Summary

  • At IETF 126, the PROCON Working Group agreed to propose a charter sentence saying its outcome documents would accurately document current policy. The public Datatracker record still showed only the approved 2025 charter at the research cutoff, so the new sentence was a proposal, not operative authority.
  • The approved charter already permits more than editorial cleanup. It authorises narrow non-editorial changes around Working Group milestones and draft adoption, as well as a separate delegation and temporary-succession BCP. It requires rechartering for additional items.
  • The current drafts contain unlike changes: deletion of RFC 2418’s 51%/99% consensus shorthand, treatment of support roles, moderation across public online fora, reversible draft adoption, and revisions to examples or terminology. They cannot all be evaluated with one label.
  • “Current policy” can mean text already approved, operational practice that has outgrown the text, or a policy choice the group now wants to normalise. Those are different sources of legitimacy even when they produce sensible wording.
  • A lightweight change-classification ledger should join each consequential diff to its baseline, claimed source of present practice, charter clause or recharter path, rationale, objections, Working Group disposition, later IETF state and final text.
  • The ledger would not create a veto or force editorial fixes through rechartering. It would preserve the difference between publication of a BCP and its later uptake in tooling and Working Group behaviour.

A sentence that cannot classify its own drafts

PROCON exists because two foundational process documents have accumulated age, amendments and operational distance. Its approved charter directs the group to produce bis documents for RFC 2026 and RFC 2418, incorporating later RFC updates and verified or held-for-update errata. The aim is intelligibility without reopening every institutional bargain.

Yet the charter was never limited to typographical repair. The approved PROCON charter expressly permits non-editorial changes in areas including Working Group milestones and the adoption of Internet-Drafts. It also authorises a separate BCP concerning delegation by the IETF Chair and temporary succession. For additional work, it says the group must recharter.

That architecture gives PROCON three legitimate kinds of movement before any disputed edge is reached. It may consolidate policy already scattered across later RFCs. It may correct obsolete mechanics where the written process no longer describes the infrastructure it names. And it may deliberately revise the rules in the areas the charter itself identifies. A fourth kind—turning common conduct into normative text—can overlap any of the first three but demands its own evidence. A practice may be widespread without already carrying the authority of a BCP.

The chair presentation at IETF 126 made the tension explicit. It described the programme’s understood goal as accurately and clearly documenting current process while deferring extensions and policy changes, then observed that a strict charter reading could exclude some editorial fixes and alignment with changed operational reality. The slides proposed a longer amendment referring to relevant RFCs, IESG statements and tooling changes.

The meeting minutes record a shorter outcome. The Working Group agreed to propose: “The outcome documents shall document current policy accurately.” The minutes identify themselves as AI-drafted, then reviewed and updated by the chairs and participants. They are therefore a reviewed meeting record, not a verbatim transcript.

At the 2 September research cutoff, Datatracker still exposed charter-ietf-procon-01, last updated on 9 July 2025, as the approved charter. The nine-word sentence must consequently be described with procedural restraint. It is language the Working Group agreed to propose to the IESG. It is not yet a published successor charter, and it cannot retroactively settle whether a particular earlier diff fell within the existing charter.

Four edits, four possible authority stories

The scope question becomes concrete in draft-ietf-procon-2418bis-04. Consider four changes that appear in the draft and IETF 126 materials.

First, the draft removes RFC 2418’s familiar paragraph saying that 51% support is not necessarily consensus and 99% support may still conceal a substantive objection. The 2418bis presentation describes the percentage examples as confusing rules of thumb. The minutes record a decision to keep their removal, without adding a proposed reference to RFC 7282.

That deletion plausibly corrects a misleading teaching device rather than weakening rough consensus. But plausibility is not classification. A reader should be able to see the baseline paragraph, the reason it is obsolete or confusing, the group’s disposition, and the replacement text that carries the operative principle. Otherwise “current policy” risks being inferred from the editor’s explanation rather than shown through an authority trail.

Second, revision 04 says chairs and Area Directors may appoint or dismiss people in support roles. It also says those roles neither alter consensus decision-making nor diminish the underlying responsibilities of chairs and Area Directors. The meeting record shows that the group wanted the accountability safeguard retained while the role language was revised.

This may be a faithful description of how design teams, secretaries, shepherds or other helpers function around many groups. It may also make a dispersed practice more legible and constrain ambiguity by declaring what support roles cannot do. But the fact that a practice occurs is not by itself proof that it is already normative policy. A public Working Group message said that many groups do not formally appoint a Document Editor and asked whether the document should reflect that experience. The message is valuable provenance for a proposed practice claim; it is not a census of all Working Groups or an IETF-wide decision.

Third, the draft updates a chair’s moderation surface. RFC 2418 was written around mailing-list language. Revision 04 describes public fora including email, chat groups and other collaborative tools, while requiring outcomes on those fora to be summarised and well documented. This could be obsolete-mechanics correction: the same publicity and recordkeeping obligation applied to media that did not appear in the 1998 vocabulary. It could also become policy revision if the new words expand a chair’s discretion, change which spaces count for consensus, or alter what must be preserved.

The text alone does not tell the reader which claim the group is making.

Fourth, revision 04 says Working Group adoption makes a draft the basis for a work item, does not establish consensus on its contents, and can later be reversed to a non-adopted state. Here the existing charter matters decisively: draft adoption is one of the named areas where non-editorial change is allowed. The provision should not be portrayed as an illicit departure merely because the old RFC does not contain the same custody model. It may be a deliberate, charter-authorised revision—and ought to be labelled as such.

The same need appears in the 2026bis update. The meeting decided to revert revision 09 language concerning non-public appeal discussions. A public scope exchange preserved competing arguments: one participant treated the wording as policy change beyond the charter, while a reply grounded it in RFC 2026 and current practice. The later decision to revert disposes of that text for the next revision; it does not make the earlier classification disagreement imaginary.

The meeting also chose to replace Unicode with IEEE 802 Ethernet as an example of an external standard, while a question about replacing “expired” with “inactive” was deferred. In the public terminology discussion, a participant explicitly noted that the newer term could match Datatracker reality without being clearly editorial. Even small words can sit on the border between correcting a user interface reference and changing the process state that the rule recognises.

“Current” is a claim about time; “policy” is a claim about authority

The phrase “current policy” compresses two questions. Current as of when? Policy made by whom, through which act?

For consolidation, the answer may be a list of RFCs that update the baseline plus accepted errata. For an obsolete-mechanics correction, it may be a traceable change in the tools or media through which an unchanged duty is performed. For current-practice codification, it requires evidence that a practice is sufficiently established and a decision that writing it into the BCP is appropriate. For deliberate revision, it requires the charter clause that allows the choice—or the successor charter that adds the authority—followed by the ordinary IETF review chain.

These categories are not accusations. They help a group say what it is doing. Nor must every comma receive a jurisprudential dossier. The trigger should be consequence: a diff that changes who may act, which record counts, how consensus is described, when custody begins or ends, what appeal surface exists, or which institutional actor remains accountable.

The categories can overlap. Replacing a mailing-list-only description may both correct obsolete mechanics and codify a broader practice. A new adoption paragraph may consolidate scattered guidance while exercising chartered revision authority. The ledger should permit multiple classifications, but it should not permit an unexplained blank.

The minimum useful change-classification ledger

A ledger can remain thin if it is designed as an index rather than a second standards process. Each consequential entry needs twelve fields:

  1. the immutable draft revision and exact section or diff;
  2. the RFC, erratum, IESG statement or other baseline being consolidated;
  3. the claimed present practice or tooling state, with public evidence;
  4. one or more classifications: consolidation, obsolete-mechanics correction, current-practice codification or deliberate revision;
  5. the approved charter clause, proposed recharter text or explanation that no added authority is needed;
  6. the editor’s rationale;
  7. material objections and their attributed sources;
  8. the Working Group disposition and date;
  9. later Working Group Last Call changes;
  10. IETF Last Call and IESG disposition;
  11. the final published text, if any; and
  12. a separate note on operational or tooling adoption.

The fourth and fifth fields do the essential work. They prevent “current practice” from becoming a magic phrase that upgrades observation into authority, while also preventing every modernisation from being treated as a constitutional crisis. The seventh field preserves dissent without converting an individual objection into an institutional ruling. The final field preserves a different boundary: publication changes the normative corpus, but does not prove that tools, chairs or participants have adopted the new behaviour.

This design follows a modest governance principle. Establish a stable minimum baseline; localise later choices to the body authorised to make them; keep operational adoption visible as a further act. Heng Lu’s Note 64 supplies that design lens. It is not evidence about PROCON or IETF procedure. Its value here is diagnostic: a system loses clarity when baseline, later decision and adoption are made to look like one event.

Existing review is necessary but does not preserve the explanation by itself

The strongest counterargument is procedural sufficiency. A Working Group can judge scope through consensus. Working Group Last Call can expose bad edits. IETF Last Call, Area Director review and IESG evaluation can reject or refine a draft. The Area Director at IETF 126 said 2026bis would be in scope with the proposed update, while acknowledging that he had not yet examined the 2418bis diffs deeply. Those are real checks, not decorative stages.

The PROCON document inventory also matters. At the cutoff, it listed 2026bis revision 11 in Working Group Last Call and 2418bis revision 04 as a Working Group document. Neither status is IESG approval or BCP publication. The drafts remain amendable, and later review may supply exactly the distinctions missing today.

But a sequence of approvals does not automatically retain the reason each consequential change was considered consolidation, correction, codification or revision. Mailing-list threads, slide decks, minutes and change logs are individually searchable yet collectively fragile. A final reviewer may know that the group reached consensus without being able to reconstruct whether an operational-practice claim was verified, merely asserted or rendered unnecessary by a different rationale.

The ledger therefore competes with no decision-maker. It makes the existing decision chain legible across time. If a reviewer changes the classification, that change becomes part of the record. If the group deletes the diff, the ledger records the disposition rather than preserving a zombie proposal. If a claim proves wrong, the error remains visible without contaminating the final text.

Sources

  1. Approved PROCON charter
  2. PROCON document inventory
  3. IETF 126 PROCON meeting minutes
  4. IETF 126 PROCON chair slides
  5. IETF 126 2026bis update slides
  6. IETF 126 2418bis slides
  7. Heng Lu Note 64
  8. Public PROCON scope discussion
  9. Public PROCON Document Editor practice discussion
  10. Public PROCON inactive-versus-expired discussion
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418