Independent Submission G.R. Beard Request for Comments: 9948 O.F. Art Category: Informational Internet Protocol Police ISSN: 2070-1721 H. Alvestrand, Ed. Google 1 April 2026 Internet Protocol Police (IPP) - Schedule of Punishments Abstract The Internet Protocol Police (IPP) is in charge of punishing willful infractions of the Collected Wisdom of the IETF community. This document sets out the schedule of punishments for such infractions. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9948. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 long served as an unifying force for maintaining the Internet Architectural Principles and the Rules of Sanity. The IPP has a harsh schedule for punishing infractions of these Principles and Rules. The schedule has served the IETF community well being applied in an informal manner, but the community has complained that the punishments are served indiscriminately and unaccountably. Therefore, this document publishes the schedule for the enlightenment of 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 are meted out after due consideration of infractions of the Principles and Rules. Due to the time required to reach consensus in the IPP about the need for these punishments, the punishments are usually applied late in the process, frequently as previous flawed efforts are brought up as examples to follow for new work. *The Raised Eyebrow* This is a punishment for lesser infractions, such as bad grammar, dangling participles, and inconsistent terminology. *The Frown* This punishment is reserved for more dire infractions, such as using a codepoint from an IANA-managed namespace without registering it, state tables that have dead ends, or ABNF to describe syntax that cannot be parsed by any parsing technology known in the year 1993. *The Shaking of the Head* This punishment is reserved for infractions involving complexity swept under the carpet, such as invoking the case-fold operation without a Unicode considerations section or marking critical parts as "implementation defined". *The Finger Wag* This punishment is reserved for the infractions described in [RFC4041]. *The Head-in-Hand Gesture* This mythical punishment has been rumored to have been invoked by the first greybeard to fully understand the implications of HTML/ HTTP. However, the gravity of the gesture has precluded its application to more common cases. 4. Percussive Persuasion During Protocol Development While a protocol is being developed, random greybeards may perform actions resembling the punishments defined in Section 3 while attempting to steer misguided younglings onto the Path of Wisdom. However, such guidance is more commonly applied in the form of verbal utterances, a sampling of which are described in the following subsections. Newcomers to the process are well advised to take careful notice when these occur during protocol development; however, these utterances are _not_, by themselves, punishments. Despite rumors, 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, perhaps you will 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 The study of repeat offenders has some methodological difficulties, such as the tendency of excitable individuals to abandon the IETF upon repeated percussive persuasion, but recidivism is believed to compare reasonably with that of the US prison system (66%) [RECIDIVISM]. One contributing factor to this relatively low observed incidence may be the educative value of footguns; once people have realized that the hole in their foot is in fact the result of ignoring percussive persuasion, they may be more inclined to heed advice in later iterations. 6. Security Considerations Due to the nature of this memo, it establishes an Epimenides Paradox Field [EPIMENIDES] for its subject matter, thereby preventing any harm to the Internet from being caused by its publication. 7. IANA Considerations This document has no IANA actions. Unfortunately, IANA procedures do not include excursions into the imaginary plane, so the possibility of consulting the IPP before assigning controversial numbers is precluded. However, the IPP enjoys positive relationships with multiple designated experts [RFC8126], so the situation is not unsalvageable. 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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8962] Grover, G., ten Oever, N., Cath, C., and S. Sahib, "Establishing the Protocol Police", RFC 8962, DOI 10.17487/RFC8962, April 2021, . 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, . [RFC4041] Farrel, A., "Requirements for Morality Sections in Routing Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005, . [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, . Acknowledgments The development of this document was greatly facilitated by a comfortable keyboard and a bout of insomnia. However, a few contributing individuals, listed here in alphabetical order, deserve to be called out: * 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