Establishing the Protocol Policegurshabad@cis-india.orgmail@nielstenoever.netcorinnecath@gmail.comshivankaulsahib@gmail.comLaw and OrderDo the Right ThingOne 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.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) 2021 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
. Definitions
. Composition of the Protocol Police
. Recognizing the Protocol Police
. Recruitment
. Support for the Protocol Police
. Punishable Offenses
. Protocol-Layer Violations
. Deliberate Non-Interoperability
. Disobeying RFCs
. Reporting Offenses
. Punishment
. Traffic Imprisonment
. Morality Considerations
. Oversight
. IANA Considerations
. Security Considerations
. Privacy Considerations
. Human Rights Considerations
. Conclusion
. Informative References
Acknowledgments
Authors' Addresses
IntroductionIETF 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.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.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.The Protocol Police, as defined in this document, are responsible for enforcing all IETF standards and best
practices.DefinitionsFor possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this document in their real
and enforceable sense.Composition of the Protocol PoliceThe Protocol Police shall be selected by the IETF Nominating Committee (NomCom) as laid out in in a manner similar to
that used to select the IAB and IESG .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.Recognizing the Protocol PoliceWhen 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.RecruitmentIf 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.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 .If you have nothing to hide, you have nothing to fear.Support for the Protocol PoliceSupport 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.Punishable OffensesProtocol-Layer ViolationsSome 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.Deliberate Non-InteroperabilityThe 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
), and will be reachable via the Extensible Messaging and Presence Protocol (XMPP) until at least era 2147483649.Disobeying RFCsIn 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.Reporting OffensesSend 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.PunishmentTraffic ImprisonmentThe 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.If this work is standardized, IANA is requested to register the list
of addresses (see ).
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.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.Morality ConsiderationsThis section contains morality considerations consistent with the demands of .
We reject: kings, presidents and voting.
We believe in: rough consensus and running code.
We only bow down to: the Protocol Police.
Woop-woop! This is the Protocol Police!
Woop-woop! That's the packet of the beast!
OversightAll 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.IANA ConsiderationsIf 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.Security ConsiderationsBefore the Protocol Police, there was no security. The Police have arrived. All your networks are belong to us.Privacy ConsiderationsNone.Human Rights ConsiderationsThere are none for you to worry about. The Police will see to it.ConclusionCase closed.Informative ReferencesThe Security Flag in the IPv4 HeaderFirewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.Publicly Verifiable Nominations Committee (NomCom) Random SelectionThis document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable. As an example, the selection of the voting members of the IETF Nominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. This memo provides information for the Internet community.Requirements for Morality Sections in Routing Area DraftsIt 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.Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall CommitteesThe process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.This document obsoletes RFC 7437 and RFC 8318.AcknowledgmentsMembers of the Protocol Police MUST salute and ACK all network traffic from , , and .Authors' Addressesgurshabad@cis-india.orgmail@nielstenoever.netcorinnecath@gmail.comshivankaulsahib@gmail.com