Summary

  • RFC 9948 is an authentic Informational RFC published on 1 April 2026 in the Independent Stream. Its own boilerplate says it is not Standards Track, carries no RFC Editor judgment about implementation or deployment value, and cannot become an Internet Standard.
  • The comic punishment schedule deliberately imitates institutional authority. Capitalised MUST language, a permanent identifier and an official host remain real features of the document, but none turns a raised eyebrow, frown or finger wag into an IETF enforcement act.
  • Consequential reuse should carry a compact genre-and-authority receipt joining immutable identity, stream, status, date, standards relationship, IANA effect, lineage and contextual genre evidence. The aim is to preserve the RFC and its humour, not to censor it or invent a new approval gate.

The metadata should arrive before the gavel

Imagine RFC 9948 reaching a compliance meeting as a single search result. The title says “Internet Protocol Police (IPP) — Schedule of Punishments.” The page lives on the RFC Editor's official domain. The document invokes the familiar vocabulary of MUST, SHOULD and MAY. Someone has extracted the section headed “Schedule of Punishments” and placed it in a briefing pack.

Nothing in that chain is forged. The RFC exists. The number is correct. The quotation may be exact. The archive is authoritative about what was published.

The conclusion can still be nonsense.

RFC 9948 was published on 1 April 2026 as an Informational document in the Independent Stream. Its status text says, before the punishment list begins, that it is not an Internet Standards Track specification. It says the contribution stands independently of the other RFC streams. It says the RFC Editor makes no statement about its value for implementation or deployment. It says documents approved by the RFC Editor in this stream are not candidates for any level of Internet Standard.

Those sentences are not small print added to rescue a badly classified text. They are the authority boundary of the publication. A permanent RFC number authenticates the archival object. The stream identifies the process that produced it. The status limits what kind of result it is. The boilerplate prevents the archive's prestige from silently becoming standards authority.

The safe reading order is therefore metadata, text, use. Reversing it—extract a command, notice the RFC number, infer a mandate—turns an archival identifier into a costume for power.

A joke can be official without becoming policy

The punishment schedule is not coy. Lesser infractions receive the Raised Eyebrow. More serious drafting sins attract the Frown or the Shaking of the Head. A Finger Wag is reserved by reference to another April document. The Head-in-Hand Gesture has achieved mythical status. During protocol development, greybeards may utter warnings such as “This part needs elaboration” or “The threat model seems underdeveloped,” but the RFC says those utterances are not, by themselves, punishments. It also retires the rumour that a wet noodle is an acceptable instrument of persuasion.

The text continues RFC 8962, the 2021 Independent Stream RFC that purported to establish the Protocol Police. That earlier publication carries the same Informational, non-Standards-Track and no-deployment-value boundary. Its impossible recruiting instructions and self-overseeing police force make the institutional parody explicit.

RFC 8700's history of the Series supplies the genre context. It describes April 1 RFCs as a special part of the Independent Stream and calls them humorous RFCs. It records a tradition in which only a few were selected and in which recognition could be delayed until a reader had travelled some distance into the text. The humour depends on disciplined resemblance. A parody of standards writing must look enough like standards writing to expose its habits.

That resemblance is an asset. The RFC Series is not merely a bin of commands. It is a permanent record of standards, research, procedures, experiments, history and other Internet-relevant expression. Removing the joke because a classifier might misunderstand it would impoverish the archive and reward the classifier's error.

The correct response is not to make satire unofficial. It is to keep “officially archived” separate from “institutionally binding.”

Capital letters have a jurisdiction

RFC 9948 says its capitalised requirement terms are to be interpreted under BCP 14 when, and only when, they appear in capitals. That sentence is part of the joke's exact construction. It gives invented punishments the grammar of a protocol specification.

BCP 14 vocabulary does real work in a document that has authority to specify a particular behaviour. It distinguishes obligation, recommendation and permission within that document's scope. It does not decide the scope, the stream, the document status, the adopter or the enforcement institution. Typography cannot promote an Independent Informational RFC to Standards Track. Nor can it create a police force that the IETF does not operate.

RFC 3935 makes the underlying boundary unusually clear. Even an IETF standard describes how to do something if an implementer claims to follow it; the status does not imply an attempt to mandate use or police usage. RFC 9592 repeats the community saying that the IETF is not the protocol police. If Standards Track language itself does not create a general enforcement service, an Independent Stream parody cannot acquire one by capitalising a verb.

This matters beyond humour. Downstream systems often rank short tokens by apparent strength. MUST looks stronger than a paragraph of boilerplate. A number looks more sortable than a stream. A DOI looks more durable than a genre judgment. Each signal is genuine, yet the hierarchy among them is wrong if document identity is allowed to outrank document authority.

A requirement word should therefore travel with at least three questions: required by which document, within what declared status and stream, and binding on whom through what voluntary or contractual adoption? Without those joins, extraction produces syntax without jurisdiction.

Informal correction is not fictional enforcement

The joke also catches something true about technical communities. Engineers do raise eyebrows. Reviewers do frown at dead-end state machines, unregistered code points, ambiguous terminology and underdeveloped threat models. Repeated objections can slow a draft, alter a design or persuade implementers not to deploy it.

Influence, review and enforcement are different states.

A reviewer can identify a flaw and support it with evidence. A working group can decide whether rough consensus exists for text within its charter. The IESG can perform roles assigned by the IETF process. An implementer can reject behaviour that does not interoperate with the code it runs. A buyer can write a particular RFC into a contract. A regulator can incorporate an external specification through an act of public law. None of those effects comes from an imaginary punishment schedule merely because all of them may cite RFCs.

The distinction protects criticism rather than weakening it. When every stern technical comment is described as enforcement, the evidence behind the comment disappears into status. When a genuine contractual or regulatory duty is described as “the RFC requires it,” the actor who chose to adopt the text disappears too.

RFC 9948 itself gives the clue: familiar development utterances are not punishments by themselves. The important word is not “punishment” but “by themselves.” Consequence needs a second act and a real actor. A comment may inform a consensus decision. A standards clause may become a product claim. A procurement term may create a supplier obligation. The citation does not perform those hand-offs on its own.

Context loss is a risk, not a proven incident

There is no evidence in this source packet that an AI system, search engine, procurement department or compliance scanner has mistaken RFC 9948 for a binding rule. Inventing a cautionary incident would repeat the very failure under examination: a plausible narrative would be promoted into recorded fact.

The narrower risk is enough. Documents are increasingly encountered as fragments: search snippets, vector-store passages, knowledge-graph nodes, generated summaries, spreadsheet cells and links in policy controls. A fragment may be accurate and still be unsafe for the question being asked. The RFC number survives because it is compact. The status block disappears because it is several sentences. The joke loses because classification systems reward tokens that look stable.

Date alone cannot repair this. RFC Series guidance has long warned that not every document dated 1 April is satirical. A binary rule—April date equals joke—would misclassify serious work and reduce genre to a calendar trick. Content alone is also insufficient for automated high-consequence use: successful satire is designed to sustain a straight face.

The decision should be evidence-based. RFC 9948 combines the date, Independent Stream, Informational status, explicit no-deployment-value boilerplate, lineage to RFC 8962, manifestly fictional institution, impossible sanctions and the RFC Series' documented April tradition. Together these signals support a genre conclusion much more strongly than any one of them.

The genre-and-authority receipt

A receipt should accompany a consequential citation when the receiving system will recommend, score, purchase, audit, block or punish. It need not alter the RFC archive. It can be generated by the party reusing the citation and remain independently checkable against official sources.

The first group of fields establishes identity:

  1. RFC number, title, DOI and immutable content hash.
  2. Publication date and the RFC Editor information-page snapshot used.
  3. Stream, status and stream approver.
  4. Update, obsolescence and errata state at the time of use.

The second group establishes authority:

  1. Whether the RFC belongs to the IETF Standards Track, a BCP subseries, or neither.
  2. The exact boilerplate describing consensus and implementation or deployment value.
  3. Any IANA action; for RFC 9948, there is none.
  4. The actor and instrument that make the citation consequential in the present setting—implementation declaration, contract, procurement rule, organisation policy or law.

The third group establishes genre and use:

  1. Evidence supporting a genre classification, with date never used alone.
  2. Lineage to related documents, here RFC 8962 and the April 1 history in RFC 8700.
  3. The quoted passage plus enough surrounding text to preserve the joke or qualification.
  4. A human-review flag where satire, irony, cultural reference or ambiguous quotation affects the conclusion.

The final group establishes limits: what the receipt does not prove, who made the classification, when it should be reviewed, and how a correction propagates to downstream users.

This is a receipt, not a genre police force. It does not authorise a central committee to decide which ideas may be indexed. It makes the reuser expose the chain from official text to practical consequence.

The IETF link must not swallow the stream

RFC 9948 talks about IETF practices and lives in the RFC Series ecosystem. This article therefore links the IETF as directory context. That link must not be read as authorship or approval. The RFC Editor's current guide says the Independent Stream publishes outside the official IETF, IAB and IRTF processes. RFC 8729 likewise gives each stream its own approval path and places Independent submissions outside the other streams' scope.

The distinction is not cosmetic institutional genealogy. If a catalog flattens every RFC under “IETF standard,” it changes the actor, process and authority in one move. A correct record should be able to say: official RFC Series artifact; Independent Stream; Informational status; content about IETF culture; no IETF Standards Track standing.

Those four statements fit together. Databases that permit only one institutional label force a false choice between hiding the RFC's official home and overstating IETF ownership. The receipt keeps the relationships typed.

Preserve the raised eyebrow

Humour is a form of institutional memory. The Protocol Police papers capture how a standards community worries about pedantry, informal hierarchy, newcomers, overclaiming and the gap between written rules and social correction. Their exaggerated authority makes those tensions discussable.

The archive should not sand that material down into a warning label. Nor should an automated intermediary quote it deadpan and make the parody perform the power it criticises.

The minimum repair is simple: whenever a citation will cause a real consequence, carry the fields that explain what kind of RFC it is and where the consequence actually comes from. A permanent number can then do its proper job—identify the document—without being recruited as a badge, a warrant or a gavel.

The Raised Eyebrow remains official history. It still cannot issue a fine.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — RFC 9948 information record
  5. RFC 9948 — Internet Protocol Police (IPP): Schedule of Punishments
  6. RFC Editor — RFC 8962 information record
  7. RFC 8962 — Establishing the Protocol Police
  8. RFC 8700 — Fifty Years of RFCs
  9. RFC Editor — What Is an RFC?
  10. RFC 8729 — The RFC Series and RFC Editor
  11. RFC 7841 — RFC Streams, Headers, and Boilerplates
  12. RFC 3935 — A Mission Statement for the IETF
  13. RFC 9592 — Retiring the Tao of the IETF