<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-protocolpolice-af-01" number="8962" submissionType="independent" category="info" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
    <title abbrev="The Protocol Police">Establishing the Protocol Police</title>
    <seriesInfo name="RFC" value="8962"/>
    <author initials="G." surname="Grover" fullname="Gurshabad Grover">
      <address>
        <email>gurshabad@cis-india.org</email>
      </address>
    </author>
    <author initials="N." surname="ten Oever" fullname="Niels ten Oever">
      <address>
        <email>mail@nielstenoever.net</email>
      </address>
    </author>
    <author initials="C." surname="Cath" fullname="Corinne Cath">
      <address>
        <email>corinnecath@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Sahib" fullname="Shivan Kaul Sahib">
      <address>
        <email>shivankaulsahib@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="April" day="1"/>
    <keyword>Law and Order</keyword>
    <keyword>Do the Right Thing</keyword>
    <abstract>
      <t>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.</t>
      <t>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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>IETF participants are often confronted with circumstances where developers or deployers choose to not obey the sacrosanct
          words of an RFC.  This can lead to outcomes that are widely agreed to be unexpected, unwarranted, or undesirable.</t>
      <t>Some are of the opinion that IETF participants should come to a consensus and declare what protocol behavior is
          unacceptable, and that the maintainers and developers of non-compliant protocols should be chastised.  Others
          (especially working group chairs) non-gracefully fall back on the undocumented mantra, "We [or the IETF] are not
          the Protocol Police."  Understandably, this has led to confusion about who should make judgments about proper
          interpretation of protocol specifications.</t>
      <t>This document formally establishes the Protocol Police, hitherto undocumented at the IETF.  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.</t>
      <t>The Protocol Police, as defined in this document, are responsible for enforcing all IETF standards and best
          practices.</t>
    </section>
    <section anchor="definitions" numbered="true" toc="default">
      <name>Definitions</name>
      <t>For possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this document in their real
          and enforceable sense.</t>

    </section>
    <section anchor="composition-of-the-protocol-police" numbered="true" toc="default">
      <name>Composition of the Protocol Police</name>
      <t>The Protocol Police shall be selected by the IETF Nominating Committee (NomCom) as laid out in <xref target="RFC3797" format="default"/> in a manner similar to
          that used to select the IAB and IESG <xref target="RFC8713" format="default"/>.</t>
      <t>However, the members of the Protocol Police shall not be publicly named.  This will enable them to operate more
          effectively and without interference or unwarranted pressure from members of the community.  The first rule of the
          Protocol Police is $CIPHERTEXT.</t>
      <section anchor="recognizing-the-protocol-police" numbered="true" toc="default">
        <name>Recognizing the Protocol Police</name>
        <t>When more than one person says, "We are not the Protocol Police," at least one of them is not telling the truth.</t>
        <t>The Protocol Police love company and are never alone.</t>
        <t>You are not the Protocol Police: we are.  We are not the Protocol Police: you are.</t>
      </section>
      <section anchor="recruitment" numbered="true" toc="default">
        <name>Recruitment</name>
        <t>If you are 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
             to be true to the scripture, NomCom will of course be instructed to induct you to the ranks.  But if you have
             transgressed, any information the investigation produces MAY be used against you in future proceedings.</t>
        <t>In making an assessment of your suitability for membership of the Protocol Police, contact may be made on your behalf
             with the Internet Moral Majority <xref target="RFC4041" format="default"/>.</t>
        <t>If you have nothing to hide, you have nothing to fear.</t>
      </section>
    </section>
    <section anchor="support-for-the-protocol-police" numbered="true" toc="default">
      <name>Support for the Protocol Police</name>
      <t>Support for the existence and operation of the Protocol Police is essential to the concept of "policing by consent."
          Fortunately, the IETF community and all stakeholders may now consider themselves served by this document which, by
          dint of its existence, warrants adherence.</t>
    </section>
    <section anchor="punishable-offenses" numbered="true" toc="default">
      <name>Punishable Offenses</name>
      <section anchor="protocol-layer-violations" numbered="true" toc="default">
        <name>Protocol-Layer Violations</name>
        <t>Some boundaries must not be crossed.  There are no acceptable layer violations.  Even though layers, like
             borders, are ambiguous abstractions only serving to uphold the legitimacy and identity of the institutions
             that produce them, they shall be observed and defended because the Protocol Police exist to defend them.</t>
      </section>
      <section anchor="deliberate-non-interoperability" numbered="true" toc="default">
        <name>Deliberate Non-Interoperability</name>
        <t>The Protocol Police are sanctioned to gain access to any walled garden that undermines interoperability.  At
             the same time, the Protocol Police will defend legacy interoperability options in all NTP eras (see
             <xref target="RFC5905" section="6" sectionFormat="of"/>), and will be reachable via the Extensible Messaging and Presence Protocol (XMPP) until at least era 2147483649.</t>
      </section>
      <section anchor="disobeying-rfcs" numbered="true" toc="default">
        <name>Disobeying RFCs</name>
        <t>In the beginning was the RFC, and the network was with the RFC, and the RFC was with the network.  Through
             the RFC all things were made; without the RFC nothing was made that has been made.  In the network was life,
             and that life was the light of all the INTERNET.  Thou shalt not deviate from the path set out in the RFCs or
             else thou shall be scattered over the data plane.</t>
      </section>
    </section>
    <section anchor="reporting-offences" numbered="true" toc="default">
      <name>Reporting Offenses</name>
      <t>Send all your reports of possible violations and all tips about wrongdoing to /dev/null.  The Protocol Police
          are listening and will take care of it.</t>
    </section>
    <section anchor="punishment" numbered="true" toc="default">
      <name>Punishment</name>
      <section anchor="traffic-imprisonment" numbered="true" toc="default">
        <name>Traffic Imprisonment</name>
        <t>The Protocol Police will maintain a list of hosts and clients that have demonstrated their inability to
             comprehend simple commandments contained in RFCs, which all IETF participants know to be precise and
             accessible even to a general audience.</t>

        <t>If this work is standardized, IANA is requested to register the list
  of addresses (see <xref target="iana-considerations" format="default"/>).
             For a period specified in an official notification, all other networks SHALL drop all network packets originating
             from or intended for such addresses.  This will result in effective and forced confinement of criminal networks.</t>
        <t>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 in this way will be disciplined by the Protocol Police with TCP RSTs.  Let it be known: the
             Protocol Police always shoot from the HIP.</t>
      </section>
    </section>
    <section anchor="morality" numbered="true" toc="default">
      <name>Morality Considerations</name>

      <t>This section contains morality considerations consistent with the demands of <xref target="RFC4041" format="default"/>.</t>

      <blockquote quotedFrom="My friend Dave">
	<t>
             We reject: kings, presidents and voting.<br/>
             We believe in: rough consensus and running code.<br/>
             We only bow down to: the Protocol Police.
	</t>
      </blockquote>

	  <blockquote quotedFrom="KRS-ZERO (after spotting an evil bit [RFC3514])">
	    <t>
             Woop-woop! This is the Protocol Police!<br/>
             Woop-woop! That's the packet of the beast!
	    </t>
	  </blockquote>

      <section anchor="oversight" numbered="true" toc="default">
        <name>Oversight</name>
        <t>All police forces must be accountable and subject to oversight.  The Protocol Police take full responsibility for oversight
             of their actions and promise to overlook all activities.</t>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>If this work is standardized, IANA shall set up a registry for criminal networks and addresses.  If the IANA does not comply with these orders, the Protocol
         Police shall go and cry to ICANN before becoming lost in its bureaucracy.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Before the Protocol Police, there was no security.  The Police have arrived.  All your networks are belong to us.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
        <name>Privacy Considerations</name>
        <t>None.</t>
    </section>
    <section anchor="human-rights-considerations" numbered="true" toc="default">
      <name>Human Rights Considerations</name>
      <t>There are none for you to worry about.  The Police will see to it.</t>
    </section>
    <section anchor="conclusion" numbered="true" toc="default">
      <name>Conclusion</name>
      <t>Case closed.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Informative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3514.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3797.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4041.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8713.xml"/>
    </references>
    <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Members of the Protocol Police MUST salute and ACK all network traffic from <contact fullname="Daniel Kahn Gillmor"/>, <contact fullname="Mallory Knodel"/>, and <contact fullname="Adrian Farrel"/>.</t>
    </section>
  </back>
</rfc>
