[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                Deukyoon Kang, Shin Fang
                                                             KT / NIST
                                                        March 11, 1998

 Guide lines for Key words use to indicate requirement levels in RFCs


Status of this Memo

     This document is an Internet-Draft.  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."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
     (US West Coast).

     This internet draft expires on September 11, 1998.


   In many IETF documents several key words are used to signify the
   requirements in the spefcification. This document defines the
   requirement levels imposed by these words as they should be
   interpreted in IETF documments. The requirement levels are basically
   equivalent to the ones proposed by RFC 2119[1]. But easier to
   understand the strength of key words and to introduce new key words
   to the hierarchy of requirement levels if ever there's a need.

1. Introduction

   RFC 2119 addresses the use of  frequently used Key words in Internet
   standard track  documents such as MUST, MUST NOT, SHOULD, SHOULD
   good guide to Internet standards developers and Implementers in that
   it leads more consistent interpretation of RFCs and Drafts than
   without it resulting into more interoperable implementations.

   However, note that most of statements in Standards documents have no
   key word at all. More consistent interpretation of standards track
   documents will be possible if we agree on the interpretation of 'no
   key word'.

   In this document, the requirement level is classified into three
   levels which are basically equivalent to the ones proposed by RFC
   2119[1]. But easier to understand the strength of key words and to
   introduce new key words to the hierarchy of requirement levels if
   ever there's a need. In fact, three new key words, NEVER, CAN and
   CANNOT are introduced in this memo as well as 'no key word'.

   Note that the force of key words defined in this document is
   modified by the requirement level of the document in which they are

   Authors who follow these guidelines should incorporate this phrase
   near the beginning of their document.

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        "CAN", "CANNOT", and the absence of these key words in this
        document are to be interpreted as described in

2. Requirement Levels

   Requirement and Prohibition are simply referred to as Requirement in
   this document. For instance, MUST and SHALL NOT indicate the same
   requirement level.

   Requirement levels are classified into three levels Level 1, 2 and
   3 as follows:

   - Level 1: Absolute requirements of the specification
      * The requirements shall be satisfied without exception
   - Level 2: Recommended requirements of the specification
      * There may exist valid reasons in particular circumstances to
        ignore a particular item. But the full implications must be
        understood and carefully inspected before choosing a different
      * Key words: RECOMMENDED, SHOULD, SHOULD NOT, 'No key word'
  - Level 3: Optional Requirements
      * The indicated requirement may be implemented or not depending
        on the flavor of vendors. An implementation which does not
        include a particular option must be prepared to interoperate
        with another implementation which does include the option,
        though perhaps with reduced functionality and vice versa.
      * Key words: OPTIONAL, CAN, MAY, MAY NOT

3. References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, Harvard University, March 1997.

4. Authors' addresses

   Deukyoon Kang
   Korea Telecom, Korea
   Phone: +1 301 975 5352
   E-mail: dykang@snad.ncsl.nist.gov

   Shin Fang
   National Institute of Standards and Technology, MD, USA
   Phone: +1 301 975 4294
   E-mail: shin@snad.ncsl.nist.gov

*  This internet draft expires on September 11, 1998.