RFC 8962

Establishing the Protocol Police

📅 published April 2021, from ietf

Establishing the Protocol Police 🚨

RFC 8962, "Establishing the Protocol Police" 🎀
Category: Informational 💖
Stream: Independent Submission ✨
ISSN: 2070-1721
Date: 1 April 2021 🌸
Authors: G. Grover, N. ten Oever, C. Cath, and S. Sahib 👑

Abstract ✨

Okay so the IETF has this iconic mantra, "We are not the Protocol Police." 💅 But bestie, if we want every protocol to be implemented and deployed in full compliance with the IETF's standards, we need a body that's responsible for checking and enforcing correct protocol behavior. 🔥

This document officially establishes the Protocol Police 🚔. It defines the body and spells out which parts of IETF protocols they'll police. It's a reference point for networking engineers, law enforcement officials, government reps, and literally everyone else 🫶. It also gives advice on how to report issues to the Protocol Police.

Status of This Memo ✨

Quick vibe check: this document is not an Internet Standards Track specification. It's published just for info 🦋.

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment 🙈. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 7841 for the receipts.

For the current status, errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc8962 💜.

Copyright Notice ✨

This document 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, because they spell out your rights and restrictions for this document 📜.

Table of Contents 🧚

1.  Introduction
2.  Definitions
3.  Composition of the Protocol Police
  3.1.  Recognizing the Protocol Police
  3.2.  Recruitment
4.  Support for the Protocol Police
5.  Punishable Offenses
  5.1.  Protocol-Layer Violations
  5.2.  Deliberate Non-Interoperability
  5.3.  Disobeying RFCs
6.  Reporting Offenses
7.  Punishment
  7.1.  Traffic Imprisonment
8.  Morality Considerations
  8.1.  Oversight
9.  IANA Considerations
10. Security Considerations
11. Privacy Considerations
12. Human Rights Considerations
13. Conclusion
14. Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🌈

Okay so IETF folks keep running into situations where developers or deployers just... don't follow the sacred words of an RFC 💀. That can lead to outcomes everyone agrees are unexpected, unwarranted, or just plain undesirable.

Some people think IETF participants should reach consensus on which protocol behavior is unacceptable, and that the maintainers and developers of non-compliant protocols should get called out 😤. Others (especially working group chairs) kinda rudely fall back on the undocumented mantra, "We [or the IETF] are not the Protocol Police." Honestly? That's led to a ton of confusion about who gets to judge proper interpretation of protocol specs 🙃.

So this document formally establishes the Protocol Police, which has been totally undocumented at the IETF until now 🦋. It defines the body and spells out which aspects of IETF protocols they'll police. It's a reference point for networking engineers, law enforcement officials, government representatives, and others. It also gives advice on how to report issues to the Protocol Police.

The Protocol Police, as defined here, are responsible for enforcing all IETF standards and best practices 💅.

2. Definitions 💖

For possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this document in their real and enforceable sense 🔥.

3. Composition of the Protocol Police 👑

The Protocol Police shall be selected by the IETF Nominating Committee (NomCom) as laid out in [RFC3797], in a manner similar to the one used to select the IAB and IESG [RFC8713].

Here's the tea though: the members of the Protocol Police shall not be publicly named 🙈. That lets them operate more effectively, without interference or unwarranted pressure from the community. The first rule of the Protocol Police is $CIPHERTEXT 🔐.

3.1. Recognizing the Protocol Police 🕵️‍♀️

When more than one person says, "We are not the Protocol Police," at least one of them is not telling the truth 👀.

The Protocol Police love company and are never alone 🫶.

You are not the Protocol Police: we are. We are not the Protocol Police: you are. 🌀

3.2. Recruitment 🎀

If you're interested in joining the Protocol Police, contact your localhost 💻. Your behavior will be monitored, and your implementation will be analyzed for full RFC compliance. If your deeds, both now and in the past, are recognized as true to the scripture, NomCom will of course be instructed to induct you into the ranks ✨. But if you've transgressed, any information the investigation produces MAY be used against you in future proceedings 😭.

When your suitability for Protocol Police membership is being assessed, contact may be made on your behalf with the Internet Moral Majority [RFC4041] 📣.

If you have nothing to hide, you have nothing to fear 🫣.

4. Support for the Protocol Police 💜

Support for the existence and operation of the Protocol Police is essential to the concept of "policing by consent." Luckily, the IETF community and all stakeholders can now consider themselves served by this document, which, just by existing, warrants adherence 👑.

5. Punishable Offenses 🚨

5.1. Protocol-Layer Violations 🧱

Some boundaries must not be crossed. There are no acceptable layer violations 🙅‍♀️. Layers, like borders, are ambiguous abstractions that only exist to uphold the legitimacy and identity of the institutions that produce them. Even so, they shall be observed and defended, because the Protocol Police exist to defend them 🛡️.

5.2. Deliberate Non-Interoperability 🚫

The Protocol Police are sanctioned to get into any walled garden that undermines interoperability 🌷. At the same time, they'll defend legacy interoperability options in all NTP eras (see Section 6 of [RFC5905]), and they'll be reachable via the Extensible Messaging and Presence Protocol (XMPP) until at least era 2147483649 📱. Iconic commitment.

5.3. Disobeying RFCs 📜

Back in the beginning, there was the RFC, and the network was with the RFC, and the RFC was with the network. Through the RFC, everything was made, and nothing that was made came to be without it. Inside the network was life, and that life was the light of the INTERNET ✨. The commandment is simple: thou shalt not stray from the path set out in the RFCs, or else thou shalt be scattered across the data plane 💀.

6. Reporting Offenses 📮

Send all your reports of possible violations and all your tips about wrongdoing to /dev/null 🕳️. The Protocol Police are listening and will take care of it 🫡.

7. Punishment ⚡

7.1. Traffic Imprisonment ⛓️

The Protocol Police will keep a list of hosts and clients that have shown they can't understand simple commandments in RFCs. Those commandments are, as all IETF participants know, precise and accessible even to a general audience 🙃.

If this work gets standardized, IANA is requested to register the list of addresses (see Section 9). For a period set out in an official notification, all other networks SHALL drop all network packets originating from or intended for such addresses 🚫. This results in effective and forced confinement of criminal networks. Period 🔒.

Using powerful machine-learning mechanisms for threat analysis, the Protocol Police will identify networks that are likely to fail to comply with this requirement 🤖. This process is known as Heuristic Internet Policing (HIP). Networks identified this way will be disciplined by the Protocol Police with TCP RSTs 💥. Let it be known: the Protocol Police always shoot from the HIP 🎯.

8. Morality Considerations 💅

This section contains morality considerations consistent with the demands of [RFC4041] 🌸.

|  We reject: kings, presidents and voting.
|  We believe in: rough consensus and running code.
|  We only bow down to: the Protocol Police.
|
|  -- My friend Dave

|  Woop-woop!  This is the Protocol Police!
|  Woop-woop!  That's the packet of the beast!
|
|  -- KRS-ZERO (after spotting an evil bit [RFC3514])

8.1. Oversight 👁️

All police forces must be accountable and subject to oversight. The Protocol Police take full responsibility for overseeing their own actions, and they promise to overlook all activities 🫡.

9. IANA Considerations 🗂️

If this work gets standardized, IANA SHALL set up a registry for criminal networks and addresses. If IANA doesn't comply with these orders, the Protocol Police shall go and cry to ICANN before getting lost in its bureaucracy 😤.

10. Security Considerations 🔐

Before the Protocol Police, there was no security. Then the Police arrived. All your networks are belong to us 😈💀.

11. Privacy Considerations 🫥

None.

12. Human Rights Considerations 🌷

There are none for you to worry about. The Police will see to it 👮‍♀️.

13. Conclusion 🎀

Case closed. 🔨

14. Informative References 📚

[RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header",
           RFC 3514, DOI 10.17487/RFC3514, April 2003,
           <https://www.rfc-editor.org/info/rfc3514>.

[RFC3797]  Eastlake 3rd, D., "Publicly Verifiable Nominations
           Committee (NomCom) Random Selection", RFC 3797,
           DOI 10.17487/RFC3797, June 2004,
           <https://www.rfc-editor.org/info/rfc3797>.

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

[RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
           "Network Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
           <https://www.rfc-editor.org/info/rfc5905>.

[RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
           Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
           Confirmation, and Recall Process: Operation of the IETF
           Nominating and Recall Committees", BCP 10, RFC 8713,
           DOI 10.17487/RFC8713, February 2020,
           <https://www.rfc-editor.org/info/rfc8713>.

Acknowledgments 🫶

Members of the Protocol Police MUST salute and ACK all network traffic from Daniel Kahn Gillmor, Mallory Knodel, and Adrian Farrel 🫡🌟.

Authors' Addresses 💌

Gurshabad Grover
Email: gurshabad@cis-india.org

Niels ten Oever
Email: mail@nielstenoever.net

Corinne Cath
Email: corinnecath@gmail.com

Shivan Kaul Sahib
Email: shivankaulsahib@gmail.com

📦 where this page comes from

ietf: rfc8962 2021-04
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms