idnits 2.17.1 draft-iesg-rfc-checklist-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-24) 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 105: '...MUST [NOT], SHOULD [NOT], etc. must define the meaning of those key...' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'UTF-8' on line 99 looks like a reference -- Missing reference section? 'NOT' on line 105 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet-Draft University of Tennessee 3 Expires: 23 September 1998 5 (DRAFT) Checklist for RFC Authors 7 draft-iesg-rfc-checklist-00.txt 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 areas, and 13 its working groups. Note that other groups may also distribute working 14 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 documents at 18 any time. It is not appropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To view the entire list of current Internet-Drafts, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 This is a list of things that often delay processing of RFCs by 30 IESG and/or the RFC Editor, and which are often preventable by RFC 31 authors. The purpose of this document is to list in one place the most 32 frequent causes of unnecessary delay, and thereby help RFC authors mini- 33 mize such delays when possible. 35 This document is emphatically NOT an expression of IESG policy, nor 36 that of the RFC Editor, and is provided merely for informational pur- 37 poses. When appropriate, this document attempts to provide references 38 to other documents, some of which are expressions of IESG, IETF, and/or 39 RFC Editor policy and others which are merely informational. Readers 40 are advised to check the official status of each reference. 42 The RFC Editor's instructions to RFC Authors are in [rfc-instruc- 43 tions]. 45 1. Titles and Apparent Scope of RFCs 47 IESG will be suspicious of any RFCs, especially those published as 48 Informational or Experimental documents, that describe themselves as 49 "requirements" or "policy" for IETF or the Internet. 51 The word "requirements" is often misused to describe design goals 52 for a new protocol. Since an effective solution to a problem usually 53 involves a number of compromises, very few design goals are absolute 54 requirements. Unless the document really does contain (near-)absolute 55 requirements, a more accurate term such as "design goals" or "recommen- 56 dations" should be used. 58 Only Internet standards-track RFCs should describe themselves as 59 "standard", whether in the title or otherwise. Exceptions may be made, 60 at the discretion of IESG and the RFC Editor, for de jure standards doc- 61 uments produced by other recognized standards bodies, which are pub- 62 lished as Informational RFCs to make them more accessible to the Inter- 63 net community. 65 2. Security Considerations 67 Every RFC must have a security considerations section. It is no 68 longer sufficient to say simply "security considerations are not consid- 69 ered in this document". The security considerations section should doc- 70 ument known vulnerabilities of a protocol, known countermeasures to 71 those vulnerabilities, and which vulnerabilities are not addressed by 72 those countermeasures. If the protocol is considered to have adequate 73 security only when used in certain limited environments (say, behind a 74 firewall), those constraints must be described. 76 Standards-track protocols which by their nature require authentica- 77 tion are expected to provide at least one mandatory-to-implement authen- 78 tication mechanism which provides adequate protection against imperson- 79 ation. This is considered part of the normal requirement for interoper- 80 ability for standards-track protocols. Cleartext passwords, or pass- 81 words which are weakly encrypted, are not acceptable. 83 Standards-track protocols which by their nature require privacy 84 must provide at least one mandatory-to-implement privacy (encryption) 85 algorithm which provides adequate protection against attack. 40-bit 86 keys are extremely unlikely to be considered adequate for any particular 87 application; they're certainly not adequate for general purposes. 88 56-bit keys are of dubious strength, especially given the expected life- 89 time of a new protocol. 91 For more detailed information and recommendations, see [security- 92 workshop] and [security-considerations]. 94 3. Internationalization 96 All protocols which represent human-readable text must support 97 internationalization. Generally this means that human-readable text 98 must be labelled with the language and charset. New protocols are 99 expected to support the UTF-8 charset [UTF-8] and may support other 100 charsets. See [charset-policy]. 102 4. Use of Key Words to Indicate Conformance Requirements. 104 RFCs that use upper-cased key words with special meanings, such as 105 MUST [NOT], SHOULD [NOT], etc. must define the meaning of those key 106 words as used in the RFC. For consistency between RFCs, the definitions 107 in RFC 2119 [key-words] should be used (and RFC 2119 should be refer- 108 enced near the beginning of the document) unless there is a compelling 109 reason to do otherwise. 111 The words "must", "should", etc when not written in upper case are 112 assumed to have their normal English-language meaning. An RFC which 113 uses both "must" and "MUST" or both "should" and "SHOULD", should 114 explicity state this in the paragraph that references [key-words]. 116 5. IANA Considerations 118 Any RFC that defines new IANA registries should include an IANA 119 Considerations section to inform IANA of its new duties. This section 120 will be reviewed by IANA prior to publication as an RFC, and IANA will 121 recommend to IESG whether it should be accepted or whether changes are 122 required. Definitions of new values for existing registries - e.g. port 123 numbers, content-types, OIDs, charsets, etc. will also be reviewed by 124 IANA to ensure that there are no conflicts with existing definitions 125 and, when appropriate, that the new definitions conform to established 126 rules. See [iana-considerations]. 128 6. References to Other Documents 130 In general, a standards-track document is not allowed to make a 131 normative reference to a non standards-track RFC, or to a standards- 132 track RFC of lesser grade. (A "normative" reference is any reference 133 which is required to implement the protocol.) A document containing 134 such normative references, even if otherwise approved by IESG, will not 135 be published as an RFC until those references are advanced in grade. 136 Exceptions are made in rare cases - such as when the reference is only 137 needed to define some particular constants, or when the reference is not 138 itself a protocol specification and therefore doesn't belong on the 139 standards track. See [standards-process] for the official rules. 141 Internet standards-track documents may also make normative refer- 142 ences to published specifications produced by other standards bodies, or 143 to published de facto standards, provided such references are acceptable 144 to IESG and the RFC Editor. 146 Non-normative references may be made to Informational or Experimen- 147 tal RFCs, or to other published documents. Non-normative references may 148 be made to Internet-Drafts but these must be marked as "Work In 149 Progress". 151 NB: A document containing references to one or more Internet-Drafts 152 which are not referred to as as Work In Progress, will not be published 153 as an RFC, until those referenced Internet-Drafts are also published as 154 RFCs. 156 In general, references to "lower grade" (less mature on the stan- 157 dards track) documents, has been known to delay the publication of stan- 158 dards-track RFCs by months or even years -- especially because each such 159 reference may contain references to other documents which must them- 160 selves be upgraded. 162 7. Change Log 164 Standards-track RFCs which revise earlier standards-track documents 165 should contain a list of changes from the earlier version in an appro- 166 priate place in the document. It is usually appropriate to include this 167 as an appendix. 169 8. Implementation Reports for Standards Track Progression 171 RFCs submitted for progression on the standards track (either to 172 Draft Standard or to Standard) must be accompanied by an implementation 173 report which documents that the protocol has been appropriately tested 174 for interoperability. This implementation report need not be part of 175 the RFC itself, but no Last Call announcement will be issued without 176 such a report. 178 9. Intellectual Property Notices 180 Standards-track documents must include notices of any patents or 181 other intellectual property claims of which the document authors, work- 182 ing group, working group chairs, or IETF Secretariat is aware, and which 183 would encumber technology used in the protocol. This is true regardless 184 of whether those claims are believed to be valid. See [standards-pro- 185 cess] for the official rules. 187 Documents to be published as standards-track or BCP RFCs must 188 include the ISOC copyright notice from [standards-process]. 190 Protocols which employ encumbered technology - including but not 191 limited to algorithms for authentication, compression, encryption, and 192 key exchange algorithms - should, if possible, provide at least one 193 mandatory-to-implement algorithm which is believed to be freely usable. 194 (IETF standards are not forbidden to require use of encumbered technol- 195 ogy. However, in the absence of demonstrated broad community support 196 for such a requirement, the IESG will assume that such a requirement 197 does not have community consensus.) 199 10. Informational Sections in Standards-Track documents. 201 All sections of a standards-track or BCP document are considered 202 "part of the standard" unless stated otherwise. Additional information 203 which is not part of the standard (for example, documentation of non- 204 standard existing practice) is often useful and may be provided, but 205 must be clearly distinguished from the standard. Such information 206 should usually be placed in appendices or even in a separate document. 208 IESG and the RFC Editor may eventually develop boilerplate language 209 for such sections. 211 11. Procedural notes 213 [This section is still under construction. It is intended to 214 advise authors of common procedural gaffes that can cause delays or con- 215 fusion, such as publically circulating unpublished intermediate versions 216 of an internet-draft, or revising an internet-draft during its Last Call 217 period.] 219 12. Author's Address 221 Keith Moore 223 University of Tennessee 224 107 Ayres Hall 225 Knoxville, TN 37996-1301 226 USA 228 13. References 230 [charset-policy] 231 Alvestrand, H. IETF Policy on Character Sets and Languages. RFC 232 2277, January 1998. 234 [iana-considerations] 235 Alvestrand, H., Narten, T. Guidelines for Writing an IANA Consid- 236 erations Section in RFCs. Internet-Draft , March 1998. (work in progress) 239 [key-words] 240 Bradner, S. Key words for use in RFCs to Indicate Requirement Lev- 241 els. RFC 2119, March 1997. 243 [rfc-instructions]. 244 Postel, J., Reynolds, J. Instructions to RFC Authors. RFC 2223, 245 October 1997. 247 [security-considerations] 248 Atkinson, Ran. Guidelines for Writing RFC Text on Security Consid- 249 erations. Internet-Draft , 250 July 1997. (work in progress) 252 [security-workshop] 253 Bellovin, Steve. Report of the IAB Security Architecture Workshop. 254 RFC 2316, April 1998. 256 [standards-process] 257 Bradner, S. The Internet Standards Process -- Revision 3. RFC 258 2026, October 1996.