idnits 2.17.1 draft-farrel-rtg-morality-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 323. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 350), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2004) is 7066 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 54, but not defined Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel 2 IETF Internet Draft Olddog Consulting 3 Proposed Status: Informational 4 Expires: April 2004 December 2004 6 draft-farrel-rtg-morality-requirements-01.txt 8 Requirements for Morality Sections in Routing Area Drafts 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 It has often been the case that morality has not been given proper 39 consideration in the design and specification of protocols produced 40 within the Routing Area. This has led to a deline in the moral 41 values within the Internet and attempts to retrofit a suitable 42 moral code to implemented and deployed protocols has been shown to 43 be sub-optimal. 45 This document specifies the requirement for all new Routing Area 46 Internet-Drafts to include a "Morality Considerations" section, and 47 gives guidance on what that section should contain. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 The key words "SHALT", "SHALT NOT", "SMITE", and "PILLAR OF SALT" in 56 this document are to be interpreted as expected. 58 1. Introduction 60 It is well accepted by popular opinion and other reliable metrics 61 that moral values are in decline and that degeneracy is on the 62 increase. Young people are particularly at risk from the rising 63 depravity in society and much of the blame for this can be placed 64 squarely at the door of the Internet. If you do not feel safe on the 65 streets at night, what do you think it is like on the Information 66 Superhighway? 68 When new protocols or protocol extensions are developed within the 69 Routing Area, it is often the case that not enough consideration is 70 given to the impact on the moral fiber of the Internet that the 71 protocols cause. The result is that moral consequences are only 72 understood once the protocols have been implemented, and sometimes 73 not until after they have been deployed. 75 The resultant attempts to restore the appropriate behavior and purge 76 the community of improper activities are not always easy or 77 architecturally pleasant. Further, it is possible that certain 78 protocol designs make morality particularly hard to achieve. 80 Recognising that moral issues are fundamental to the utility and 81 success of protocols designed within the IETF, and that simply 82 making a wishy-washy liberal-minded statement does not necessarily 83 provide adequate guarantees of a correct and proper outcome for 84 society, this document defines requirements for the inclusion of 85 Morality Considerations sections in all Internet-Drafts produced 86 within the Routing Area. Meeting these requirements will ensure that 87 proper consideration is given to moral issues at all stages of the 88 protocol development process from Requirements and Architecture, 89 through Specification and Applicability. 91 The remainder of this document describes what subsections are needed 92 within a Morality Considerations section, and gives advice and 93 guidance about what information should be contained in those 94 subsections. 96 2. Presence and Placement of Morality Considerations Sections 98 2.1. Null Morality Considerations Sections 100 It may be the case that the authors of Internet-Drafts have no or few 101 morals. This does not relieve them of the need to understand the 102 consequences of their actions. 104 The more likely an author is to say that a null Morality 105 Considerations section is acceptable, the more pressure must be 106 exerterd on him by the Area and the appropriate Working Group to 107 ensure that he gives full consideration to his actions, and reflects 108 long and hard on the consequences of his writing and the value of his 109 life. 111 On the other hand, some authors are well known to have the highest 112 moral pedigree: a fact that is plainly obvious from the company they 113 keep, the Working Groups they attend, and their eligibility for 114 NomCom. It is clearly unnecessary for such esteemed persons to waste 115 effort on Morality Consideration sections. It is inconceivable that 116 anything that they write would have anything other than a beneficial 117 effect on the Routing Area and the Internet in general. 119 2.2. Mandatory Subsections 121 If the Morality Considerations section is present, it MUST contain at 122 least the following subsections. The content of these subsections is 123 surely self-evident to any right-thinking person. Further guidance can 124 be obtained from your moral guardian, your household gods, or from any 125 member of the IMM (Internet Moral Majority). 127 - Likelihood of misuse by depraved or sick individuals. This 128 subsection must fully address the possiblity that the proposed 129 protocols or protocol extensions might be used for the distribution 130 of blue, smutty or plain disgusting images. 131 - Likelihood of misuse by misguided individuals. There is an obvious 132 need to protect minors and people with misguided thought processes 133 from utilising the protocols or protocol extensions for purposes 134 that would inevitably do them harm. 135 - Likelihood of misuse by large, multi-national corporations. Such a 136 thought is, of course, unthinkable. 137 - Availablity of oversight facilities. There are those who would 138 corrupt our morals motivated as they are by a hatred of the freedom 139 of Internet access with which we are graced. We place a significant 140 burden of responsibility on those who guard our community from 141 these evil-doers and it is only fitting that we give them as much 142 support as is possible. Therefore, all encryption and obfuscation 143 techniques MUST be excluded - no-one who has nothing to hide need 144 fear the oversight of those whose morals are beyond doubt. 146 - Inter-SDO impact. We must allow for other moral frameworks and 147 fully respect other people's right to subscribe to other 148 belief systems. Such people are, however, wrong and doomed to 149 spend eternity in a dark corner with only dial-up access. So 150 it has been written. 151 - Care and concern for avian carriers. A duck may be somebody's 152 mother. 154 In the event that one or more of these subsections is considered to 155 be not relevant, it MUST still be present, and MUST contain a full 156 rebuttal of this deviant thought. 158 2.3. Optional Subsections 160 Additional subsections may be added to accommodate zealots. 162 2.4. Placement of Morality Considerations Sections 164 The Morality Considerations section MUST be given full prominence in 165 each Internet Draft. 167 3. Applicability Scenarios 169 This section outlines, by way of example, some particular areas which 170 are in dire need of reform and where a short, sharp shock could make 171 a really big difference. 173 3.1. Provision of Services 175 We must do our utmost to ensure that services are delivered in a 176 timely and reliable way. Emphasis should be placed on Quality of 177 Service (QoS) and meeting the needs of the consumer of the service. 179 Arrangements should be made for regular provision of services and 180 sermons should be to the point and contain a strong moral message. 182 3.2. Political Correctness (PC) 184 Political correctness has gone too far. This problem can be traced 185 way back to the 1970s when the desktop PC was invented. It is 186 necessary that Internet Drafts observe the form of political 187 correctness, but note that you do not always have to mean what you 188 say. 190 3.2.1. Differentiated Services 192 Segregation of packets on the grounds of color has now been banned 193 and Internet Drafts must not make use of this technique. 195 If you follow all of the reccomendations in this document, you will 196 find that "packets of color" (as we must now refer to them) tend to 197 avoid your points of presence, and you will no longer be troubled by 198 them. 200 3.2.2. Jumbo Packets 202 It is no longer appropriate to refer to "jumbo packets". Please use 203 the term "capacitorially challenged". 205 3.2.3. Byte Ordering 207 Note that within Internet Drafts bytes (and bits) progress from the 208 left to the right. This is how things should be. 210 3.3. Protection or Abstenance 212 Much has been made recently of the need to provide protection within 213 the Internet. It is the role of the IMM to determine when protection 214 is required, and the role of the IESG bulldogs to ensure that we are 215 all protected. 217 However, protection is only one way to prevent unplanned outages and, 218 as we all know, the ready availability of protection schemes such as 219 1:1 (one-on-one) or 1:n (orgy-mode) have lead to a belief that it is 220 acceptable to switch (or swing) at will. It should be noted that 221 protection can fail, and under no circumstances should extra traffic 222 be countenanced. 224 In reality the only safe way to avoid passing data to your friends is 225 to agree pledge to have no control plane before marriage. Join our 226 campaign and sign up for the SONET Ring Thing. 228 3.4. Promiscuity 230 Various disgusting protocols indulge in promiscuity. This appears to 231 happen most often when an operator is unwilling to select a single 232 partner and wants to play the field. 234 Promiscuous modes of operation are an abomination only exceeded by 235 multicast. 237 4. Terminology 239 Admission Control 240 The caring investigative arm of the IMM. 242 Doom 243 Port 666. Need we say more? 245 ECMP 246 What is this? Some kind of Communism? 248 Money 249 The root of all evil. 251 MPLS 252 What is with this "layer two-and-a-half" nonsense? The world is 253 flat, just accept the fact. 255 Packet Switching 256 Sounds like fraud to me. 258 Path 259 The route of all LSPs. 261 Policy Control 262 The adminstrative arm of the IMM. 264 Random Walk 265 Substance abuse is to be avoided. 267 Rendezvous Point 268 Poorly lit street corner. Not to be confused with the root of all 269 multicast. 271 Standard Body 272 What we should all strive for. 274 Strawberry Icecream 275 Something that wills the void between rational discussion and all-out 276 thermo nuclear war. [SCREAM] 278 5. Morality Considerations 280 The moral pedigree of the author of this draft places him and his 281 writings beyond question. 283 6. IANA Considerations 285 IANA should think carefully about the protection of their immortal 286 souls. 288 7. Security Considerations 290 Security is of the utmost important. 292 A secure Internet community will ensure the security of all of its 293 members. 295 8. Acknowledgements 297 I would like to thank my guru Alex Dipandra-Zinin. 299 Jozef Wroblewski, who clearly knows promiscuous behavior when he 300 sees it, pointed out some of the dangers in promiscuous operation. 302 No avian carriers were harmed in the production of this document. 304 9. Intellectual Property Considerations 306 Property is theft. What is yours is mine. What is mine, you keep 307 your hands off. 309 The IETF takes no position regarding the validity or scope of any 310 Intellectual Property Rights or other rights that might be claimed to 311 pertain to the implementation or use of the technology described in 312 this document or the extent to which any license under such rights 313 might or might not be available; nor does it represent that it has 314 made any independent effort to identify any such rights. Information 315 on the procedures with respect to rights in RFC documents can be 316 found in BCP 78 and BCP 79. 318 Copies of IPR disclosures made to the IETF Secretariat and any 319 assurances of licenses to be made available, or the result of an 320 attempt made to obtain a general license or permission for the use of 321 such proprietary rights by implementers or users of this 322 specification can be obtained from the IETF on-line IPR repository at 323 http://www.ietf.org/ipr. 325 10. Normative References 327 I don't need to be told how to formulate my morals. 329 11. Informative References 331 To be frank, I don't find many other documents informative. 333 [SCREAM] Farrel, A., "Observations on Proposing Protocol 334 Enhancements that Address Stated Requirements but also go 335 Further by Meeting more General Needs", 336 draft-farrel-problem-protocol-icrm-00.txt, June 2003, work 337 in progress. 339 12. Author's Address 341 Adrian Farrel 342 Old Dog Consulting 343 Email: adrian@olddog.co.uk 344 Phone: I'm not telling you that. Why do you ask, anyway? 346 13. Full Copyright Statement 348 Copyright (C) The Internet Society (2004). This document is subject 349 to the rights, licenses and restrictions contained in BCP 78, and 350 except as set forth therein, the authors retain all their rights. 352 This document and the information contained herein are provided on an 353 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 354 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 355 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 358 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.