RFC 9948

Internet Protocol Police (IPP) - Schedule of Punishments

📅 published April 2026, from ietf

RFC 9948: Internet Protocol Police (IPP) - Schedule of Punishments ✨

  • Stream and category: Independent Submission, Informational 🎀
  • Authors: G.R. Beard and O.F. Art (Internet Protocol Police), and H. Alvestrand, Ed. (Google) 💜
  • Date: 1 April 2026 🌸
  • ISSN: 2070-1721
  • Obsoletes or updates: the header doesn't list any RFCs that this one obsoletes or updates 🙈

Abstract

okay so the Internet Protocol Police (IPP) is the group in charge of punishing willful infractions of the Collected Wisdom of the IETF community 👑. this doc lays out the schedule of punishments for those infractions 💅

Status of This Memo

this one is not an Internet Standards Track spec, it's just published for info purposes 🧚

it's a contribution to the RFC Series, and it's independent of any other RFC stream. the RFC Editor picked to publish it at their discretion and makes zero statements about whether you should implement or deploy it 💀. docs approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🫶

for current status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9948 ✨

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, bestie, because they explain your rights and restrictions for this doc 📜

Table of Contents

1.  Introduction
2.  Conventions and Definitions
3.  Schedule of Punishments
4.  Percussive Persuasion During Protocol Development
5.  Recidivism Studies
6.  Security Considerations
7.  IANA Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🦋

the Internet Protocol Police (IPP) [RFC8962] has been a unifying force for ages, keeping the Internet Architectural Principles and the Rules of Sanity intact 🔥. the IPP has a harsh schedule for punishing infractions of those Principles and Rules. the schedule has worked well for the IETF community when used informally, but people have complained that the punishments get handed out indiscriminately and unaccountably 😭. so this doc publishes the schedule for everyone in the IETF community, especially newcomers 🍓

2. Conventions and Definitions 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

in addition, the key words defined in [RFC6919] MIGHT apply.

3. Schedule of Punishments ⚖️

these punishments get handed out after due consideration of infractions of the Principles and Rules. reaching consensus in the IPP about whether a punishment is needed takes time, so punishments usually land late in the process, often because flawed earlier efforts get brought up as examples to follow for new work 🙈

The Raised Eyebrow 🤨 this is for lesser infractions, like bad grammar, dangling participles, and inconsistent terminology.

The Frown 😬 this one is saved for more dire infractions, like using a codepoint from an IANA-managed namespace without registering it, state tables that have dead ends, or ABNF that describes syntax no parsing technology known in the year 1993 could parse.

The Shaking of the Head 🫠 this one is for infractions where complexity gets swept under the carpet, like invoking the case-fold operation without a Unicode considerations section, or marking critical parts as "implementation defined".

The Finger Wag ☝️ this one is reserved for the infractions described in [RFC4041].

The Head-in-Hand Gesture 🤦 this mythical punishment is rumored to have been invoked by the first greybeard who fully understood the implications of HTML/HTTP. the gravity of the gesture has kept it from being used on more common cases 💀

4. Percussive Persuasion During Protocol Development 🥊

while a protocol is being developed, random greybeards might do stuff that looks like the punishments in Section 3, trying to steer misguided younglings onto the Path of Wisdom 🧙. but this guidance is usually given as verbal utterances, and some examples are in the subsections below. newcomers should definitely pay attention when these happen during protocol development, but these utterances are not, by themselves, punishments 👀

rumors aside, the percussive application of a wet noodle has never been considered an appropriate part of persuasive measures 🍜🚫

4.1. "This part needs elaboration."

this guidance needs no elaboration. 💅

4.2. "You may have failed to consider ..."

I see a way to attack your protocol, and you have no defense against it. 😈

4.3. "The threat model seems underdeveloped."

if you explain the whole thing again, maybe you'll understand why it's totally unworkable without me having to understand it 🙃

4.4. "This may work in the lab, but ..."

operational considerations are either missing or hopelessly naive. 🥀

4.5. "You have not thought this through."

go home and start over. 🧳💔

5. Recidivism Studies 📊

studying repeat offenders is hard, partly because excitable people tend to abandon the IETF after repeated percussive persuasion. still, recidivism is believed to compare reasonably with that of the US prison system (66%) [RECIDIVISM] 😭

one thing that might explain this relatively low observed rate is the educative value of footguns 🦶🔫. once people realize that the hole in their foot came from ignoring percussive persuasion, they may be more inclined to listen to advice in later iterations 🧠✨

6. Security Considerations 🚨

okay this one is serious, bestie. because of the nature of this memo, it sets up an Epimenides Paradox Field [EPIMENIDES] for its subject matter, which prevents any harm to the Internet from being caused by its publication 🛡️💜

7. IANA Considerations 🏛️

this document has no IANA actions. 🎀

unfortunately, IANA procedures don't include trips to the imaginary plane, so there's no way to consult the IPP before assigning controversial numbers. the IPP does have good relationships with multiple designated experts [RFC8126], so it's not hopeless 🫶

8. References 📚

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC6919]  Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
           for Use in RFCs to Indicate Requirement Levels", RFC 6919,
           DOI 10.17487/RFC6919, April 2013,
           <https://www.rfc-editor.org/info/rfc6919>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8962]  Grover, G., ten Oever, N., Cath, C., and S. Sahib,
           "Establishing the Protocol Police", RFC 8962,
           DOI 10.17487/RFC8962, April 2021,
           <https://www.rfc-editor.org/info/rfc8962>.

8.2. Informative References

[EPIMENIDES]
           Russell, B., "Mathematical Logic as Based on the Theory of
           Types", American Journal of Mathematics, Volume 30, Number
           3, pages 222-262, July 1908.

[RECIDIVISM]
           Latzer, B., "Does the United States Have High Recidivism
           Rates? New Data Raise Questions About Prevailing Beliefs",
           DOI 10.2139/ssrn.5029176, 15 November 2024,
           <https://papers.ssrn.com/sol3/
           papers.cfm?abstract_id=5029176>.

[RFC4041]  Farrel, A., "Requirements for Morality Sections in Routing
           Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005,
           <https://www.rfc-editor.org/info/rfc4041>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgments 🫶

the development of this doc was hugely helped by a comfy keyboard and a bout of insomnia 😴☕. but a few contributors deserve a shoutout, listed here alphabetically:

  • Aaron Falk 💖
  • Adrian Farrel 💖
  • John Klensin 💖
  • Craig Partridge 💖
  • Martin Thomson 💖

Authors' Addresses 💌

Graham Reuben Beard
Internet Protocol Police
Email: greybeard@stupid.domain.name


Oldham F. Art
Internet Protocol Police
Email: oldfart@stupid.domain.name


Harald T. Alvestrand (editor)
Google
Email: harald@alvestrand.no
📦 where this page comes from