Internet DRAFT - draft-farah-new-keywords

draft-farah-new-keywords



Network Working Group                                           M. Farah
Request for Comments: nnnn                                        T.I.A.
WCP: FFFFFFF2                                               1 April 2000
Obsoletes: 2119
Category: Worst Current Practice

 New meaning of Keywords for use in RFCs to Indicate Requirement Levels

                       draft-farah-new-keywords-01.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 2000


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

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]