Network Working Group M. Farah Request for Comments: nnnn T.I.A. WCP: FFFFFFF2 1 April 2001 Obsoletes: 2119 Category: Worst Current Practice New meaning of Keywords for use in RFCs to Indicate Requirement Levels draft-farah-new-keywords-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document specifies an Internet Worst Current Practices for the Internet Community, and does not request discussion and suggestions for any improvements whatsoever. Distribution of this memo is unlimited. ABSTRACT This memo defines new meanings for the keywords that indicate requirement levels. Introduction The author of this document believes the current meaning of keywords to indicate requirement levels are ill-defined, as they have been the direct source of several headaches and many many hours of extra work. This document defines new meanings for these keywords, and thus obsoletes RFC 2119. Oddly, 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, even after it becomes obsolete. 9. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition of the specification SHOULD be as closely followed as the implementor cares, or is able to grasp, or as the time, energy and other constraints permit. 8. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition of the specification SHOULD be avoided by the implementor, as long as it won't cause too much trouble programming-time-wise, money-wise or mood-wise. 7. SHOULD This word, or the adjective "RECOMMENDED", mean that there MAY exist particular items to implement as the specification definition states, as long as the implementor wants to, and there's no noticeable use of expensive resources (e.g. it won't take more than a few minutes to add). 6. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", mean the very same as "SHOULD" or "RECOMMENDED", respectively. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is completely expendable and that the implementor MUST ignore it. Vendors MUST NOT mention it and users MUST NOT complain about it. Farah Experimental [Page 1] New meaning of Keywords for use in RFCs 1 April 2001 4. Guidance in the use of these Imperatives Imperatives of the type defined in this memo MUST be used generously (specially the word "MAY"). In particular, they MUST be used everywhere the grammar allows. 3. Security Considerations These terms are frequently used to specify behavior with security implications. They SHOULD NOT be used again, EVER. The effects on security of implementing definitions the way this document proposes are not subtle at all. Document authors SHOULD take the time to find proper synonyms for the former meanings of the keywords in discussion. 2. Miscellaneous Considerations It SHOULD be noted that other definitions for these keywords were proposed in RFC2549 (limited to that document only). That definition set is actually a subset of the definitions here proposed, so this document does NOT obsolete RFC2549 in any way. 1. Acknowledgments The completely unfair yellings this author had to take from all his fifteen former bosses (whose names deserve not be recorded here), plus him being fired as many times, resulted in a terrible bitterness and resentment feeling that proved to be a huge motivation into writing this document. 0. References Waitzman, D., "IP over Avian Carriers with Quality of Service." RFC 2549, 1 April 1999. -1. Author's Address Miguel Farah Regina Pacis 1305 (Providencia) Santiago, Chile phone - +56 2 205 2208 email - miguel@webhost.cl Farah Experimental [Page 2]