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

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.¶

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

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