idnits 2.17.1 draft-kang-keyword-requirement-level-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 122 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 43 has weird spacing: '... use of frequ...' == Line 44 has weird spacing: '...d track docum...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOUD NOT", "RECOMMENDED", "MAY", "MAY NOT", "CAN", "CANNOT", and the absence of these key words in this document are to be interpreted as described in . -- 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 (March 11, 1998) is 9543 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Deukyoon Kang, Shin Fang 2 KT / NIST 3 March 11, 1998 5 Guide lines for Key words use to indicate requirement levels in RFCs 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 This internet draft expires on September 11, 1998. 31 Abstract 33 In many IETF documents several key words are used to signify the 34 requirements in the spefcification. This document defines the 35 requirement levels imposed by these words as they should be 36 interpreted in IETF documments. The requirement levels are basically 37 equivalent to the ones proposed by RFC 2119[1]. But easier to 38 understand the strength of key words and to introduce new key words 39 to the hierarchy of requirement levels if ever there's a need. 41 1. Introduction 43 RFC 2119 addresses the use of frequently used Key words in Internet 44 standard track documents such as MUST, MUST NOT, SHOULD, SHOULD 45 NOT, REQURIED, SHALL, SHALL NOT, and RECOMMENDED. It makes a very 46 good guide to Internet standards developers and Implementers in that 47 it leads more consistent interpretation of RFCs and Drafts than 48 without it resulting into more interoperable implementations. 50 However, note that most of statements in Standards documents have no 51 key word at all. More consistent interpretation of standards track 52 documents will be possible if we agree on the interpretation of 'no 53 key word'. 55 In this document, the requirement level is classified into three 56 levels which are basically equivalent to the ones proposed by RFC 57 2119[1]. But easier to understand the strength of key words and to 58 introduce new key words to the hierarchy of requirement levels if 59 ever there's a need. In fact, three new key words, NEVER, CAN and 60 CANNOT are introduced in this memo as well as 'no key word'. 62 Note that the force of key words defined in this document is 63 modified by the requirement level of the document in which they are 64 used. 66 Authors who follow these guidelines should incorporate this phrase 67 near the beginning of their document. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 70 NOT", "SHOULD", "SHOUD NOT", "RECOMMENDED", "MAY", "MAY NOT", 71 "CAN", "CANNOT", and the absence of these key words in this 72 document are to be interpreted as described in 73 . 75 2. Requirement Levels 77 Requirement and Prohibition are simply referred to as Requirement in 78 this document. For instance, MUST and SHALL NOT indicate the same 79 requirement level. 81 Requirement levels are classified into three levels Level 1, 2 and 82 3 as follows: 84 - Level 1: Absolute requirements of the specification 85 * The requirements shall be satisfied without exception 86 * Key words: MUST, MUST NOT, SHALL, SHALL NOT, NEVER, CANNOT 87 - Level 2: Recommended requirements of the specification 88 * There may exist valid reasons in particular circumstances to 89 ignore a particular item. But the full implications must be 90 understood and carefully inspected before choosing a different 91 course. 92 * Key words: RECOMMENDED, SHOULD, SHOULD NOT, 'No key word' 93 - Level 3: Optional Requirements 94 * The indicated requirement may be implemented or not depending 95 on the flavor of vendors. An implementation which does not 96 include a particular option must be prepared to interoperate 97 with another implementation which does include the option, 98 though perhaps with reduced functionality and vice versa. 99 * Key words: OPTIONAL, CAN, MAY, MAY NOT 101 3. References 103 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 104 Levels", RFC 2119, Harvard University, March 1997. 106 4. Authors' addresses 108 Deukyoon Kang 109 Korea Telecom, Korea 110 Phone: +1 301 975 5352 111 E-mail: dykang@snad.ncsl.nist.gov 113 Shin Fang 114 National Institute of Standards and Technology, MD, USA 115 Phone: +1 301 975 4294 116 E-mail: shin@snad.ncsl.nist.gov 118 * This internet draft expires on September 11, 1998.