Internet Protocol Police

greybeard@stupid.domain.name

Internet Protocol Police

oldfart@stupid.domain.name

Google

harald@alvestrand.no

internet protocol police 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 .

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 () 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

• .  Introduction
• .  Conventions and Definitions
• .  Schedule of Punishments
• .  Percussive Persuasion During Protocol Development
• .  Recidivism Studies
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction The Internet Protocol Police (IPP) 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.

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 when, and only when, they appear in all capitals, as shown here. In addition, the key words defined in MIGHT apply.

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 .

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.

Percussive Persuasion During Protocol Development While a protocol is being developed, random greybeards may perform actions resembling the punishments defined in 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.

"This part needs elaboration." This guidance needs no elaboration.

"You may have failed to consider ..." I see a way to attack your protocol, and you have no defense against it.

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

"This may work in the lab, but ..." Operational considerations are either missing or hopelessly naive.

"You have not thought this through." Go home and start over.

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%) . 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.

Security Considerations Due to the nature of this memo, it establishes an Epimenides Paradox Field for its subject matter, thereby preventing any harm to the Internet from being caused by its publication.

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 , so the situation is not unsalvageable.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior. This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police. Informative References American Journal of Mathematics, Volume 30, Number 3, pages 222-262 City University of New York - John Jay College of Criminal Justice It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. This memo provides information for the Internet community. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226.

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:

Authors' Addresses Internet Protocol Police

greybeard@stupid.domain.name

Internet Protocol Police

oldfart@stupid.domain.name

Google

harald@alvestrand.no