idnits 2.17.1 draft-bradner-key-words-02.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-20) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 an Authors' Addresses Section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 36: '...1. MUST This word, or the adjectives...' RFC 2119 keyword, line 39: '...2. MUST NOT This phrase, or the phra...' RFC 2119 keyword, line 42: '...3. SHOULD This word, or the adjectiv...' RFC 2119 keyword, line 47: '...4. SHOULD NOT This phrase means that...' RFC 2119 keyword, line 53: '...5. MAY This word, or the adjective "...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 1996) is 10110 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: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard University 4 August 1996 6 Key words for use in RFCs to Indicate Requirement Levels 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 29 In many standards track documents several words are used to signify 30 the requirements in the specification. These words are often 31 capitalized. This document defines these words as they should be 32 interpreted in IETF documents. Note that the force of these words is 33 modified by the requirement level of the document in which they are 34 used. 36 1. MUST This word, or the adjectives "REQUIRED" or "SHALL", means that 37 the definition is an absolute requirement of the specification. 39 2. MUST NOT This phrase, or the phrase "SHALL NOT", means that the 40 definition is an absolute prohibition of the specification. 42 3. SHOULD This word, or the adjective "RECOMMENDED", means that there 43 may exist valid reasons in particular circumstances to ignore a 44 particular item, but the full implications must be understood and 45 carefully weighed before choosing a different course. 47 4. SHOULD NOT This phrase means that there may exist valid reasons in 48 particular circumstances when the particular behavior is acceptable 49 or even useful, but the full implications should be understood and 50 the case carefully weighed before implementing any behavior described 51 with this label. 53 5. MAY This word, or the adjective "OPTIONAL", means that an item is 54 truly optional. One vendor may choose to include the item because a 55 particular marketplace requires it or because the vendor feels that 56 it enhances the product while another vendor may omit the same item. 57 An implementation which does not include a particular option MUST be 58 prepared to interoperate with another implementation which does 59 include the option, though perhaps with reduced functionality. In the 60 same vein an implementation which does include a particular option 61 MUST be prepared to interoperate with another implementation which 62 does not include the option.(except, of course, for the feature the 63 option provides) 65 6. Guidance in the use of these Imperatives 67 Imperatives of the type defined in this memo must be used with care 68 and sparingly. In particular, they must only be used where it is 69 actually required for interoperation or to limit behavior which has 70 potential for causing harm (e.g., limiting retransmisssions) For 71 example, they must not be used to try to impose a particular method 72 on implementors where the method is not required for 73 interoperability. 75 6. Security Considerations 76 These terms are frequently used to specify options or behavior in a 77 way that can effect security risks. Careful consideration should be 78 taken to understand the security implications of any use of these 79 imperatives. 81 7. Acknowledgments 82 The definitions of these terms are an amalgam of definitions taken 83 from a number of RFCs. In addition, suggestions have been 84 incorporated from a number of people including Robert Ullmann, Thomas 85 Narten, and Robert Elz. 87 8. Author's Address 88 Scott Bradner 89 Harvard University 90 1350 Mass. Ave. 91 Cambridge, MA 02138 93 phone - +1 617 495 3864 95 email - sob@harvard.edu