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


. 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.

. 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


. 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].

. 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].

. 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].

. 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.

. 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.

. 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.

. 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.)

. 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.

. 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.]

. Author's Address

Keith Moore <moore@cs.utk.edu>

University of Tennessee
 Ayres Hall
Knoxville, TN 37996-1301
USA


. 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 <draft-iesg-iana-



K. Moore                Expires 23 September 1998               [Page 5]

RFC Checklist                INTERNET-DRAFT                23 April 1998


     considerations-03.txt>, 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 <draft-iab-secwks-sec-guidelines-00.txt>,
     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]