IETF RFC 4041 - Requirements for Morality Sections in Routing Area Drafts

Network Working Group

A. Farrel Request for Comments: 4041

Old Dog Consulting

Category: Informational

1 April 2005

Requirements for Morality Sections in Routing Area Drafts

Status of This Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2005).

Abstract

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.

  1. Introduction

    It is well accepted by popular opinion and other reliable metrics that moral values are declining and that degeneracy is increasing. Young people are particularly at risk from the rising depravity in society and much of the blame can be squarely placed at the door of the Internet. If you do not feel safe on the streets at night, what do you think it is like on the Information Superhighway?

    When new protocols or protocol extensions are developed within the Routing Area, it is often the case that not enough consideration is given to the impact of the protocol on the moral fiber of the Internet. The result is that moral consequences are only understood once the protocols have been implemented, and sometimes not until after they have been deployed.

Farrel Informational [Page 1]

RFC 4041 Routing Morality Section Requirements 1 April 2005

The resultant attempts to restore appropriate behavior and purge the community of improper activities are not always easy or architecturally pleasant. Further, it is possible that certain protocol designs make morality particularly hard to achieve.

Recognising that moral issues are fundamental to the utility and success of protocols designed within the IETF, and that simply making a wishy-washy liberal-minded statement does not necessarily provide adequate guarantees of a correct and proper outcome for society, this document defines requirements for the inclusion of Morality Considerations sections in all Internet-Drafts produced within the Routing Area. Meeting these requirements will ensure that proper consideration is given to moral issues at all stages of the protocol development process, from Requirements and Architecture, through Specification and Applicability.

The remainder of this document describes the necessary subsections of the Morality Considerations sections, and gives guidance about what information should be contained in those subsections.

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

The key words "SHALT", "SHALT NOT", "SMITE", and "PILLAR OF SALT" in this document are to be interpreted as expected.

  1. Presence and Placement of Morality Considerations Sections

2.1. Null Morality Considerations Sections

It may be the case that the authors of Internet-Drafts have no or few morals. This does not relieve them of their duty to understand the consequences of their actions.

The more likely an author is to say that a null Morality Considerations section is acceptable, the more pressure must be exerted on him by the Area and the appropriate Working Group to ensure that he gives full consideration to his actions, and reflects long and hard on the consequences of his writing and the value of his life.

On the other hand, some authors are well known to have the highest moral pedigree: a fact that is plainly obvious from the company they keep, the Working Groups they attend, and their eligibility for NomCom. It is clearly unnecessary for such esteemed persons to waste

Farrel Informational [Page 2]

RFC 4041 Routing Morality Section Requirements 1 April 2005

effort on Morality Considerations sections. It is inconceivable that anything that they write would have anything other than a beneficial effect on the Routing Area and the Internet in general.

2.2. Mandatory Subsections

If the Morality Considerations section is present, it MUST contain at least the following subsections. The content of these subsections is surely self-evident to any right-thinking person. Further guidance can be obtained from your moral guardian, your household gods, or from any member of the IMM (Internet Moral Majority).

  • Likelihood of misuse by depraved or sick individuals. This subsection must fully address the possibility that the proposed protocols or protocol extensions might be used for the distribution of blue, smutty, or plain disgusting images.

  • Likelihood of misuse by misguided individuals. There is an obvious need to protect minors and people with misguided thought processes from utilising the protocols or protocol extensions for purposes that would inevitably do them harm.

  • Likelihood of misuse by large, multi-national corporations. Such a thought is, of course, unthinkable.

  • Availability of oversight facilities. There are those who would corrupt our morals motivated as they are by a hatred of the freedom of Internet access with which we are graced. We place a significant burden of responsibility on those who guard our community from these evil-doers and it is only fitting that we give them as much support as is possible. Therefore, all encryption and obfuscation techniques MUST be excluded - individuals who have nothing to hide need to fear the oversight of those whose morals are beyond doubt.

  • Inter-SDO impact. We must allow for other moral frameworks and fully respect other people's right to subscribe to other belief systems. Such people are, however, wrong and doomed to spend eternity in a dark corner with only dial-up access. So it has been written.

  • Care and concern for avian carriers. A duck may be somebody's mother.

    Even if one or more of these subsections are considered irrelevant, they MUST all still be present, and MUST contain a full rebuttal of this deviant thought.

Farrel Informational [Page 3]

RFC 4041 Routing Morality Section Requirements 1 April 2005

2.3. Optional Subsections

Additional subsections may be added to accommodate zealots.

2.4. Placement of Morality Considerations Sections

The Morality Considerations section MUST be given full prominence in each Internet Draft.

  1. Applicability Scenarios

    This section outlines, by way of example, some particular areas that are in dire need of reform and where a short, sharp shock could make a really big difference.

3.1. Provision of Services

We must do our utmost to ensure that services are delivered in a timely and reliable way. Emphasis should be placed on Quality of Service (QoS) and meeting the needs of the consumer of the service.

Arrangements should be made for regular provision of services, and sermons should be to the point and contain a strong moral message.

3.2. Political Correctness (PC)

Political correctness has gone too far. This problem can be traced way back to the 1970s when the desktop PC was invented. It is necessary for Internet-Drafts to observe a form of political correctness, but note that you do not always have to mean what you say.

3.2.1. Differentiated Services

Segregation of packets on the grounds of color is now banned and Internet-Drafts must not make use of this technique.

If you follow all of the recommendations in this document, you will find that "packets of color" (as we must now refer to them) tend to avoid your points of presence, and you will no longer be troubled by them.

3.2.2. Jumbo Packets

It is no longer appropriate to refer to "jumbo packets". Please use the term "capacitorially challenged".

Farrel Informational [Page 4]

RFC 4041 Routing Morality Section Requirements 1 April 2005

3.2.3. Byte Ordering

Note that within Internet-Drafts, bytes (and bits) progress from the left to the right. This is how things should be.

3.3. Protection or Abstinence

Much has been made recently of the need to provide protection within the Internet. It is the role of the IMM to determine when protection is required, and the role of the IESG bulldogs to ensure that we are all protected.

However, protection is only one way to prevent unplanned outages and, as we all know, the ready availability of protection schemes such as 1:1 (one-on-one) or 1:n (orgy-mode) have lead to a belief that it is acceptable to switch (or swing) at will. It should be noted that protection can fail, and under no circumstances should extra traffic be countenanced.

In reality, the only safe way to avoid passing data to your friends is to agree to pledge to have no control plane before marriage. Join our campaign and sign up for the SONET Ring Thing.

3.4. Promiscuity

Various disgusting protocols indulge in promiscuity. This appears to happen most often when an operator is unwilling to select a single partner and wants to play the field.

Promiscuous modes of operation are an abomination, exceeded only by multicast.

  1. Terminology

    Admission Control The caring investigative arm of the IMM.

    Doom Port 666. Need we say more?

    ECMP What is this? Some kind of Communism?

    Money The root of all evil.

Farrel Informational [Page 5]

RFC 4041 Routing Morality Section Requirements 1 April 2005

MPLS What is with this "layer two-and-a-half" nonsense? The world is flat, just accept the fact.

Packet Switching Sounds like fraud to me.

Path The route of all LSPs.

Policy Control The administrative arm of the IMM.

Random Walk Substance abuse is to be avoided.

Rendezvous Point Poorly lit street corner. Not to be confused with the root of all multicast.

Standard Body What we should all strive for.

Strawberry Ice Cream Something that wills the void between rational discussion and all-out thermo nuclear war [SCREAM].

  1. Morality Considerations

    The moral pedigree of the author of this document places him and his writings beyond question.

  2. IANA Considerations

    IANA should think carefully about the protection of their immortal souls.

  3. Security Considerations

    Security is of the utmost importance.

    A secure Internet community will ensure the security of all of its members.

Farrel Informational [Page 6]

RFC 4041 Routing Morality Section Requirements 1 April 2005

  1. Acknowledgements

    I would like to thank my guru Alex Dipandra-Zinin.

    Jozef Wroblewski, who clearly knows promiscuous behavior when he sees it, pointed out some of the dangers in promiscuous operation.

    No avian carriers were harmed in the production of this document.

  2. Intellectual Property Considerations

    Property is theft. What is yours is mine. What is mine, you keep your hands off.

  3. Normative References

    I don't need to be told how to formulate my morals.

    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

    Requirement Levels", BCP 14, RFC 2119, March 1997.
  4. Informative References

    To be frank, I don't find many other documents informative.

    [SCREAM] Farrel, A., "Observations on Proposing Protocol

    Enhancements that Address Stated Requirements but also go
        Further by Meeting more General Needs", Work in Progress,
        June 2003.

Author's Address

Adrian Farrel Old Dog Consulting

Phone: I'm not telling you that. Why do you ask, anyway? EMail: adrian@olddog.co.uk

Farrel Informational [Page 7]

RFC 4041 Routing Morality Section Requirements 1 April 2005

Full Copyright Statement

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

Farrel Informational [Page 8]

Protocol Police: The RFC

Independent Submission G. Grover Request for Comments: 8962
Category: Informational N. ten Oever ISSN: 2070-1721
C. Cath

S. Sahib
                                                        1 April 2021


                Establishing the Protocol Police

Abstract

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.

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/rfc8962.

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

    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.

    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.

  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 that used to select the IAB and IESG [RFC8713].

    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.

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

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

  1. Support for the Protocol Police

    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.

  2. Punishable Offenses

5.1. Protocol-Layer Violations

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.

5.2. Deliberate Non-Interoperability

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 Section 6 of [RFC5905]), and will be reachable via the Extensible Messaging and Presence Protocol (XMPP) until at least era 2147483649.

5.3. Disobeying RFCs

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.

  1. Reporting Offenses

    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.

  2. Punishment

7.1. Traffic Imprisonment

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.

If this work is standardized, IANA is requested to register the list of addresses (see Section 9). 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.

  1. 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 oversight of their actions and promise to overlook all activities.

  1. IANA Considerations

    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.

  2. Security Considerations

    Before the Protocol Police, there was no security. The Police have arrived. All your networks are belong to us.

  3. Privacy Considerations

    None.

  4. Human Rights Considerations

    There are none for you to worry about. The Police will see to it.

  5. Conclusion

    Case closed.

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

via