RFC 4041

RFC 4041: Requirements for Morality Sections in Routing Area Drafts 💖

• Network Working Group 🫶
• Request for Comments: 4041 🎀
• Author: A. Farrel, Old Dog Consulting ✨
• Category: Informational 🌸
• Date: 1 April 2005 👀
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🦋

---

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 🎀

Okay so this one is a little sad, bestie 😭. Morality has often not gotten proper love when protocols are designed and specified in the Routing Area. That has led to a decline in moral values across the Internet, and trying to retrofit a moral code onto protocols that are already implemented and deployed 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 ✨

Everyone's saying it, and other reliable metrics agree: moral values are declining and degeneracy is increasing 💀. Young people are especially at risk from the rising depravity in society, and a lot of the blame can be squarely placed at the door of the Internet. If you don't feel safe on the streets at night, what do you think it's like on the Information Superhighway? 🙈

When new protocols or protocol extensions are developed in the Routing Area, it's giving "not enough consideration" a lot of the time. The impact on the moral fiber of the Internet gets overlooked. So the moral consequences only become clear once the protocols have been implemented, and sometimes not until after they've been deployed. Not ideal, bestie. 😩

The resulting attempts to restore appropriate behavior and purge the community of improper activities are not always easy or architecturally pleasant. On top of that, certain protocol designs might make morality particularly hard to achieve. 🥲

Here's the thing: moral issues are fundamental to the utility and success of protocols designed within the IETF. Simply making a wishy-washy liberal-minded statement doesn't necessarily give adequate guarantees of a correct and proper outcome for society, so this document defines requirements for including Morality Considerations sections in all Internet-Drafts produced within the Routing Area. Meeting these requirements will make sure moral issues get proper consideration at every stage of protocol development, from Requirements and Architecture through to Specification and Applicability. Main character energy for ethics 👑.

The rest of this document describes the necessary subsections of the Morality Considerations sections, and gives guidance about what information belongs 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. 💅

2. 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. That doesn't get them out 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 them by the Area and the appropriate Working Group. They need to make sure they give full consideration to their actions and reflect long and hard on the consequences of their writing and the value of their life. Deep breath, bestie. 🫠

On the other hand, some authors are well known to have the highest moral pedigree. You can tell from the company they keep, the Working Groups they attend, and their eligibility for NomCom. It's clearly unnecessary for such esteemed people to waste effort on Morality Considerations sections. It's inconceivable that anything they write would have anything other than a beneficial effect on the Routing Area and the Internet in general. Icon behavior, honestly 👑.

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, so it's only fitting that we give them as much support as 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 they MUST contain a full rebuttal of this deviant thought. 🫶

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

3. 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 make sure services are delivered in a timely and reliable way. Emphasis should be placed on Quality of Service (QoS) and on 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 don't 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'll find that "packets of color" (as we must now refer to them) tend to avoid your points of presence, and you'll no longer be troubled by them. Literally no drama 🫧.

3.2.2. Jumbo Packets 🍓

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

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's the role of the IMM to determine when protection is required, and the role of the IESG bulldogs to make sure we're all protected. 🐶

However, protection is only one way to prevent unplanned outages. 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's 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. 😭

4. 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. 💸

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]. 🍓🔥

Full Copyright Statement 💅

Okay so bestie, the copyright bit: 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 on whether any Intellectual Property Rights or other rights that someone might claim for the technology in this document are valid or how far they reach, and it doesn't say whether licenses for those rights are available or not. ✨ It also doesn't claim it has done any independent work to find out whether such rights exist. 🧚 If you want to learn how rights work for RFC documents, check BCP 78 and BCP 79. 📚

Copies of IPR disclosures made to the IETF Secretariat are available, along with any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this specification. 💜 You can find all of that in 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 needed to implement this standard. 🔥 Send that info to the IETF at ietf-ipr@ietf.org. 💌

---

Acknowledgement 🫶

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