RFC 9945 needs a visible activation receipt

Summary

RFC 9945 is a published Best Current Practice and establishes an IETF-wide moderation framework, but it says its changes take effect only after the IESG approves the procedures developed under Section 4; until those procedures are established, the previous processes remain in effect.
Publication, RFC Editor “obsoletes” metadata, appointment of a six-person team, a procedure repository and actual moderation are different evidence states. A compact activation receipt should join the approved revision, approval act, effective time, superseded rules, covered fora, accountable roles and migration of pending cases without exposing private reports.

A bibliographic label cannot tell time

Open the RFC Editor page for RFC 3934 and the relationship looks complete: the 2004 document has been obsoleted by RFC 9945. Open RFC 9945 and the headline is equally clear. It became BCP 245 in February 2026 and replaces older moderation arrangements while extending the policy across public online IETF fora.

That is an accurate account of the document series. It is not yet a complete answer to a time-specific operational question.

RFC 9945 contains its own switch. The new changes take effect when procedures described in Section 4 have been approved by the IESG. Those procedures and criteria must be developed with community input, approved before taking effect and made public, although they need not become another RFC. Until they are established, the previous processes referenced by the new document remain in effect.

The distinction is easy to lose because ordinary publication often is the effective event. A standards relationship is displayed as a clean edge: this text updates that one; this RFC obsoletes those RFCs. The procedure described here has more states. The framework can be published while the operating layer is still being made. A moderator team can be appointed before its new common procedures become authoritative. A repository can contain useful instructions without proving that a particular revision passed the required approval gate.

This is not a drafting defect that makes RFC 9945 unreal. It is a deliberate two-stage design. The BCP establishes the institution, limits and accountability path. A more adaptable public procedure layer supplies operational criteria. The design avoids freezing every working instruction in the RFC Series. Its cost is that the activation event lives outside the document whose status readers are most likely to inspect.

The July appeal exposed the transition predicate

A real dispute made the difference concrete within four months of publication. On 30 June 2026, Andrew Lee appealed moderation during a TLS Working Group Last Call. Among several claims, the appeal argued that RFC 3934 could no longer supply authority because RFC 9945 had obsoleted it.

The IESG responded on 9 July. It chose to consider the merits and denied the appeal. On the narrow authority question, its answer was explicit: RFC 3934 remained in force. The IESG pointed to Section 4 of RFC 9945, under which previous processes continue until the new procedures and criteria are established. It also observed that a reference to BCP 9 did not itself grant moderation authority, without treating that extra citation as fatal to the action.

This article does not reopen that case. The appeal contained other arguments about technical discussion, recusal, selective enforcement and the treatment of minority positions. The IESG answered them. The public record does not license an inference that a chair censored legitimate work, that the appellant acted in bad faith or that the decision endorses every past or future moderation act.

Its value here is narrower. The applicable rule could not be determined by reading the word “obsoleted” on one metadata page. The responsible body had to apply an embedded transition clause to a dated event. The difference was not academic: it determined which process supplied authority and which conflict-resolution path was relevant.

The response proves the IESG’s interpretation and the state it recognised on 9 July. It does not prove that the state remained unchanged two months later. As of 11 September, I could not locate a later public IESG approval act for the new Section 4 procedures among the official materials cited here. Absence from a search is not proof that an act does not exist. It is proof of a discovery problem when the regime depends on readers being able to identify that act.

A team is a principal, not a procedure version

The Datatracker now presents an active IETF Moderator Team with six members. Its description tracks RFC 9945: moderators establish procedures for public IETF fora, serve as a community resource, administer plenary fora and otherwise unassigned fora, and operate under IESG appointment and responsibility.

That page is valuable evidence. It identifies a current institutional principal and a roster. It does not say which immutable procedure revision the IESG approved, the date that approval took effect, or how old restrictions and pending reports crossed the boundary.

A second public surface makes the inference risk visible. The ietf/Moderators GitHub repository calls itself a home for guidelines, procedures and templates. Its pinned snapshot says the team fosters discussion on the IETF’s general discussion list under RFC 9245. The SOP lists three people rather than the six on Datatracker, requires agreement by at least two moderators and describes a three-level escalation ladder. A statistics file records counts of actions by level.

Nothing in that mismatch proves failure. The repository can be a legacy operating surface for the general discussion list. Its roster can lag, or the new team can be incorporating older materials while writing a broader set. Some procedures may legitimately vary by forum within a common framework. The statistics can accurately describe a narrower practice.

The point is that a reader should not have to choose among those explanations in order to know what has force. “There is a team” proves appointment. “There is an SOP” proves that text is publicly available at a revision. “There are action counts” proves that a categorisation was used in reporting. None alone proves the joined proposition: this exact text was approved by this authorised body and governed this forum at this time.

RFC 9945 deliberately distributes authority

The new framework does not create one moderation sovereign. It assigns different responsibilities to several actors.

Participants are responsible for conduct and may report disruption. Forum administrators remain primarily responsible for their own spaces. In a Working Group, chairs are administrators by default. They may delegate operational work but must accept, acknowledge and track complaints. Administrators may amend or rescind moderation actions, including actions by moderators, after consulting the team.

The moderator team develops common procedures and helps apply them consistently. It may act when administrators fail to respond in time or when disruption spans several fora, but it should normally contact the responsible administrators first. It directly administers IETF plenary fora and public fora without another administrator. Area Directors resolve disagreements at the first institutional level. The IESG appoints and recalls moderators, approves procedures, evaluates the team and hears later appeals while staying out of daily management.

The IAB sits further along the appeal chain. The Ombudsteam retains a distinct anti-harassment role. The IETF Administration LLC holds a separate, rare emergency power tied to serious legal risk and legal advice, with its own notice limits and Board review route. IRTF, IAB, the RFC Series bodies and the Independent Submission stream are outside RFC 9945’s automatic scope unless they explicitly agree.

This allocation is a safeguard. It avoids treating a local chair, a cross-forum team, an oversight body, an anti-harassment function and an organisation protecting itself from legal risk as interchangeable. But distributed authority makes version evidence more important. A complaint can move from a forum administrator to a moderator, Area Director, IESG and IAB. Each reviewer must know which procedure governed the original act rather than applying today’s document retrospectively.

“Previous processes remain” is not a blank cheque

The prior regime was itself plural. RFC 3934 gave Working Group chairs a process for controlling disruptive posting on a Working Group mailing list. RFC 3683 described a community and IESG route for withdrawing posting rights. RFC 9245 defined the general IETF discussion list and a specialised moderator arrangement. RFC 2418 assigned chairs wider Working Group responsibilities. RFC 2026 supplied procedural appeals.

RFC 9945 was created because this collection did not fit the contemporary participation surface well. Criteria varied, older processes could be slow, cross-list patterns were hard to see, and work had expanded into chat, remote-meeting systems, wikis, issue trackers and code repositories. A common policy and cross-forum team respond to real institutional needs.

Yet a transition clause preserving earlier processes does not turn every old text into unlimited authority. Scope, forum, duration, notice and appeal still matter. A Working Group mailing-list procedure cannot silently become authority to remove a Datatracker account. RFC 9945 expressly keeps account removal, meeting exclusion, content deletion and private or non-IETF communication outside ordinary moderator action.

Nor does publication of RFC 9945 mean that all its policy statements are irrelevant until activation. The July exchange showed why people can disagree about that boundary. Bibliographic status, framework policy and operational procedure are different layers. The safest institutional response is not to compress them into a slogan but to expose the state transition the RFC itself defines.

The smallest useful activation receipt

An activation receipt need not be a dossier or a new standards process. It can be a signed, versioned index joining public facts that already exist.

First, identify the exact procedure set: immutable revision, cryptographic digest, public location and covered forum classes. A mutable main branch is useful for current reading but inadequate for a historical authority claim. The receipt should identify the revision that received approval.

Second, preserve the authority act: the community-input interval, a compact disposition index, the IESG decision reference, decision time and effective time. Approval and effectiveness may be simultaneous, but they should not be assumed to be. If a staged rollout or implementation condition exists, record it.

Third, provide a supersession map. Name the prior RFC sections, IESG statements and local procedures that stop governing; identify any part that remains for a particular forum or earlier action. RFC 9945 already says an indefinite suspension imposed before the new process is reconsidered under the process in place when it was imposed. That is a real grandfathering rule, not clerical trivia.

Fourth, keep appointment separate. List moderator role intervals and the appointing act, but do not let the roster stand in for procedure approval. Record acknowledgements by forum administrators and implementation owners so that a centrally approved rule does not look operational everywhere merely because one page changed.

Fifth, cover the live boundary: pending complaints, current restrictions, open appeals, reinstatement clocks and correction history. This need not expose names. A protected record can retain case identity; the public receipt can publish counts and rule-version classes. A case initiated under one procedure and decided under another needs an explicit choice, not a silent migration.

Finally, show exceptions. The ordinary moderation policy, Ombudsteam work, LLC emergency legal action and out-of-scope organisations should not share one undifferentiated status. A scope map prevents a clear rule for one institution from being mistaken for power over another.

Transparency does not require publishing the complaint

Moderation evidence is sensitive. A report can identify a complainant, expose a target before a decision, repeat harmful language, reveal private context or amplify the disruption under review. Legal advice may impose further limits. A demand for raw public case files would undermine the privacy balance RFC 9945 expressly seeks.

The activation receipt concerns rules, authority and time, not allegations. Its public fields can be limited to a procedure digest, approval link, effective date, supersession table, scope, accountable roles, aggregate migration counts and corrections. Individual action records can use protected identifiers and role-based access. Periodic public reporting can remain aggregate.

This distinction also protects due process. An aggregate count is not evidence that a particular decision was fair. A properly activated procedure is not proof that every administrator applied it correctly. An action notice is not proof that the underlying conduct occurred as described. Each proposition requires its own record and review path.

The receipt does one modest job: it tells a participant, chair, moderator and appellate body which rules had authority when an act occurred.

Evidence limits

The sources establish RFC 9945’s status and transition language, the IESG’s 9 July interpretation, the public team roster at the research cutoff, and the content of a pinned repository snapshot. They do not establish that the current team has acted improperly, that the repository is supposed to be the final RFC 9945 procedure home, or that no later approval exists outside the locations examined.

Repository activity is not IESG approval. A team page is not an effective-date notice. An RFC Editor relationship is not a case decision. Conversely, a documentation mismatch is not proof of institutional bad faith.

Heng Lu’s writing supplies a diagnostic discipline here, not evidence about the IETF. A label belongs to one layer; an executable decision belongs to another; observation belongs to a third. The minimum initial specification should expose the join while allowing later procedure choices to evolve under the actor authorised to make them.

RFC 9945 made an important governance choice: wider coverage, explicit limits, layered roles, appeal and reconsideration without locking operating detail permanently into an RFC. That choice deserves a visible completion event. The team can exist before it. The procedures can be drafted before it. The bibliographic relationships can be published before it. The activation receipt is the point at which those facts become a time-specific mandate.

RFC 9945’s Moderator Team Is Not Its Activation Receipt

Summary

A bibliographic label cannot tell time

The July appeal exposed the transition predicate

A team is a principal, not a procedure version

RFC 9945 deliberately distributes authority

“Previous processes remain” is not a blank cheque

The smallest useful activation receipt

Transparency does not require publishing the complaint

Evidence limits

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing