Network Working Group Keith Moore Internet-Draft University of Tennessee Expires: 23 September 1998 (DRAFT) Checklist for RFC Authors draft-iesg-rfc-checklist-00.txt 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 not appropriate 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). Abstract This is a list of things that often delay processing of RFCs by IESG and/or the RFC Editor, and which are often preventable by RFC authors. The purpose of this document is to list in one place the most frequent causes of unnecessary delay, and thereby help RFC authors mini- mize such delays when possible. This document is emphatically NOT an expression of IESG policy, nor that of the RFC Editor, and is provided merely for informational pur- poses. When appropriate, this document attempts to provide references to other documents, some of which are expressions of IESG, IETF, and/or RFC Editor policy and others which are merely informational. Readers are advised to check the official status of each reference. The RFC Editor's instructions to RFC Authors are in [rfc-instruc- tions]. K. Moore Expires 23 September 1998 [Page 1] RFC Checklist INTERNET-DRAFT 23 April 1998 1. Titles and Apparent Scope of RFCs IESG will be suspicious of any RFCs, especially those published as Informational or Experimental documents, that describe themselves as "requirements" or "policy" for IETF or the Internet. The word "requirements" is often misused to describe design goals for a new protocol. Since an effective solution to a problem usually involves a number of compromises, very few design goals are absolute requirements. Unless the document really does contain (near-)absolute requirements, a more accurate term such as "design goals" or "recommen- dations" should be used. Only Internet standards-track RFCs should describe themselves as "standard", whether in the title or otherwise. Exceptions may be made, at the discretion of IESG and the RFC Editor, for de jure standards doc- uments produced by other recognized standards bodies, which are pub- lished as Informational RFCs to make them more accessible to the Inter- net community. 2. Security Considerations Every RFC must have a security considerations section. It is no longer sufficient to say simply "security considerations are not consid- ered in this document". The security considerations section should doc- ument known vulnerabilities of a protocol, known countermeasures to those vulnerabilities, and which vulnerabilities are not addressed by those countermeasures. If the protocol is considered to have adequate security only when used in certain limited environments (say, behind a firewall), those constraints must be described. Standards-track protocols which by their nature require authentica- tion are expected to provide at least one mandatory-to-implement authen- tication mechanism which provides adequate protection against imperson- ation. This is considered part of the normal requirement for interoper- ability for standards-track protocols. Cleartext passwords, or pass- words which are weakly encrypted, are not acceptable. Standards-track protocols which by their nature require privacy must provide at least one mandatory-to-implement privacy (encryption) algorithm which provides adequate protection against attack. 40-bit keys are extremely unlikely to be considered adequate for any particular application; they're certainly not adequate for general purposes. 56-bit keys are of dubious strength, especially given the expected life- time of a new protocol. For more detailed information and recommendations, see [security- workshop] and [security-considerations]. K. Moore Expires 23 September 1998 [Page 2] RFC Checklist INTERNET-DRAFT 23 April 1998 3. Internationalization All protocols which represent human-readable text must support internationalization. Generally this means that human-readable text must be labelled with the language and charset. New protocols are expected to support the UTF-8 charset [UTF-8] and may support other charsets. See [charset-policy]. 4. Use of Key Words to Indicate Conformance Requirements. RFCs that use upper-cased key words with special meanings, such as MUST [NOT], SHOULD [NOT], etc. must define the meaning of those key words as used in the RFC. For consistency between RFCs, the definitions in RFC 2119 [key-words] should be used (and RFC 2119 should be refer- enced near the beginning of the document) unless there is a compelling reason to do otherwise. The words "must", "should", etc when not written in upper case are assumed to have their normal English-language meaning. An RFC which uses both "must" and "MUST" or both "should" and "SHOULD", should explicity state this in the paragraph that references [key-words]. 5. IANA Considerations Any RFC that defines new IANA registries should include an IANA Considerations section to inform IANA of its new duties. This section will be reviewed by IANA prior to publication as an RFC, and IANA will recommend to IESG whether it should be accepted or whether changes are required. Definitions of new values for existing registries - e.g. port numbers, content-types, OIDs, charsets, etc. will also be reviewed by IANA to ensure that there are no conflicts with existing definitions and, when appropriate, that the new definitions conform to established rules. See [iana-considerations]. 6. References to Other Documents In general, a standards-track document is not allowed to make a normative reference to a non standards-track RFC, or to a standards- track RFC of lesser grade. (A "normative" reference is any reference which is required to implement the protocol.) A document containing such normative references, even if otherwise approved by IESG, will not be published as an RFC until those references are advanced in grade. Exceptions are made in rare cases - such as when the reference is only needed to define some particular constants, or when the reference is not itself a protocol specification and therefore doesn't belong on the standards track. See [standards-process] for the official rules. K. Moore Expires 23 September 1998 [Page 3] RFC Checklist INTERNET-DRAFT 23 April 1998 Internet standards-track documents may also make normative refer- ences to published specifications produced by other standards bodies, or to published de facto standards, provided such references are acceptable to IESG and the RFC Editor. Non-normative references may be made to Informational or Experimen- tal RFCs, or to other published documents. Non-normative references may be made to Internet-Drafts but these must be marked as "Work In Progress". NB: A document containing references to one or more Internet-Drafts which are not referred to as as Work In Progress, will not be published as an RFC, until those referenced Internet-Drafts are also published as RFCs. In general, references to "lower grade" (less mature on the stan- dards track) documents, has been known to delay the publication of stan- dards-track RFCs by months or even years -- especially because each such reference may contain references to other documents which must them- selves be upgraded. 7. Change Log Standards-track RFCs which revise earlier standards-track documents should contain a list of changes from the earlier version in an appro- priate place in the document. It is usually appropriate to include this as an appendix. 8. Implementation Reports for Standards Track Progression RFCs submitted for progression on the standards track (either to Draft Standard or to Standard) must be accompanied by an implementation report which documents that the protocol has been appropriately tested for interoperability. This implementation report need not be part of the RFC itself, but no Last Call announcement will be issued without such a report. 9. Intellectual Property Notices Standards-track documents must include notices of any patents or other intellectual property claims of which the document authors, work- ing group, working group chairs, or IETF Secretariat is aware, and which would encumber technology used in the protocol. This is true regardless of whether those claims are believed to be valid. See [standards-pro- cess] for the official rules. Documents to be published as standards-track or BCP RFCs must include the ISOC copyright notice from [standards-process]. K. Moore Expires 23 September 1998 [Page 4] RFC Checklist INTERNET-DRAFT 23 April 1998 Protocols which employ encumbered technology - including but not limited to algorithms for authentication, compression, encryption, and key exchange algorithms - should, if possible, provide at least one mandatory-to-implement algorithm which is believed to be freely usable. (IETF standards are not forbidden to require use of encumbered technol- ogy. However, in the absence of demonstrated broad community support for such a requirement, the IESG will assume that such a requirement does not have community consensus.) 10. Informational Sections in Standards-Track documents. All sections of a standards-track or BCP document are considered "part of the standard" unless stated otherwise. Additional information which is not part of the standard (for example, documentation of non- standard existing practice) is often useful and may be provided, but must be clearly distinguished from the standard. Such information should usually be placed in appendices or even in a separate document. IESG and the RFC Editor may eventually develop boilerplate language for such sections. 11. Procedural notes [This section is still under construction. It is intended to advise authors of common procedural gaffes that can cause delays or con- fusion, such as publically circulating unpublished intermediate versions of an internet-draft, or revising an internet-draft during its Last Call period.] 12. Author's Address Keith Moore University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA 13. References [charset-policy] Alvestrand, H. IETF Policy on Character Sets and Languages. RFC 2277, January 1998. [iana-considerations] Alvestrand, H., Narten, T. Guidelines for Writing an IANA Consid- erations Section in RFCs. Internet-Draft , March 1998. (work in progress) [key-words] Bradner, S. Key words for use in RFCs to Indicate Requirement Lev- els. RFC 2119, March 1997. [rfc-instructions]. Postel, J., Reynolds, J. Instructions to RFC Authors. RFC 2223, October 1997. [security-considerations] Atkinson, Ran. Guidelines for Writing RFC Text on Security Consid- erations. Internet-Draft , July 1997. (work in progress) [security-workshop] Bellovin, Steve. Report of the IAB Security Architecture Workshop. RFC 2316, April 1998. [standards-process] Bradner, S. The Internet Standards Process -- Revision 3. RFC 2026, October 1996. K. Moore Expires 23 September 1998 [Page 6]