Network Working Group Scott Bradner
Internet-Draft Harvard University
December 1998
Secret Handshakes: How to get RFCs published in the IETF
<draft-bradner-handshake-02.txt>
1. 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 inappropriate 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).
This document will expire before June, 1999. Distribution of this
draft is unlimited.
2. Abstract
There is confusion over how to get an RFC published in the IETF.
Recently a long time IETF participant asked me what "secret
handshake" was need to get documents published as RFCs since he had
been trying unsuccessfully to get that done. This memo is the result
of that query and describes the procedures required, gives the proper
references and the required email addresses.
3. Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
4. RFCs
RFC once meant "Request for Comment" but "RFC" is no longer viewed as
an acronym but as a stand-alone term. RFCs make up the publication
series of the IETF. All major IETF documents are published as RFCs.
The series started in April, 1969 as a way to communicate between a
few people who were working on the early ARPANET. Early RFCs were
Bradner [Page 1]
Internet-Draft Secret Handshakes December 1998
designed to convey specific information such as the minutes of
meetings or to solicit comments on ideas or proposals. In the years
since 1969 RFCs mutated into being more of a way to publish specific
information than a way to propose new ideas. A seperate, temporary
series for publications called "Internet-Drafts" was established to
take over the original requesting comments function.
5. Types of RFCs
RFCs can be the product from an IETF working group or of an
individual or group of individuals. RFCs can also be targeted for
the IETF standards track or not. Each case is handled differently
but there are four basic categories: RFC Editor and IANA documents,
IETF working group documents, standards track documents not from IETF
working groups, and non-standards track documents not from IETF
working groups. (RFC 2026, section 2.1)
6. RFC Editor and IANA documents
From time to time the RFC Editor publishes an RFC which describes how
RFCs should be formatted (currently RFC 2223) and every April Fools
Day one or more RFCs are published that are meant as parody or
attempts at humor. In addition every 100 RFCs the RFC Editor
publishes a summary document of the 99 preceding RFCs. These RFCs are
published at the discretion of the RFC Editor.
Also from time to time the IANA publishes a new version of the
Assigned Numbers RFC to provide a record of protocol number and
parameter assignments. The IANA also periodically publishes a new
version of the Internet Official Protocol Standards RFC that
describes the state of standardization of protocols. These RFCs are
published by the RFC Editor at the request of the IANA.
7. Common process features for other RFCs
All documents proposed as RFCs other than those mentioned in section
6 must first exist as Internet-Drafts. IETF working group documents
are reviewed by the IESG as part of the normal IETF process prior to
publication. (See RFC 2028 for a list of organizations involved in
the IETF standards process) In addition the RFC Editor asks the IESG
to review all other documents proposed to be published as RFCs (other
than those mentioned in section 6.) The IESG has the responsibility
to review each of these documents and make a recommendation to the
RFC Editor about publication. The IESG can recommend a document for
publication as-is or it can recommend publication only if an "IESG
note" is added to the beginning of the document describing any
particular IESG concern with the document. The IESG can also
recommend referring a non-working group document to a working group
for consideration or refer, with comments, a working group document
back to the working group for additional work. Finally the IESG can
decide that the document does not meet the quality or other standards
Bradner [Page 2]
Internet-Draft Secret Handshakes December 1998
for publication which the IESG is charged with maintaining in which
case it can recommend that the RFC Editor not publish the document.
8. Internet Drafts
Documents to be published as Internet-Drafts should be emailed to
internet-drafts@ietf.org. The documents must be formatted according
to the instructions in "The Guidelines to Authors of Internet-Drafts"
(ftp://ftp.ietf.org/ietf/1id-guidelines.txt) and should be sent as
plain text, not as a word processor enclosure. (RFC 2026 section 2.2)
In addition all documents submitted as Internet-Drafts must include
the boilerplate in the latest version of "The Guidelines to Authors
of Internet-Drafts." Authors should always retrieve the current
version of the boilerplate since it changes from time to time.
9. IETF working group documents
An IETF working group requests publication of a working group
document by sending email to the Area Directory responsible for the
working group, with a copy of the email to iesg-secretary@ietf.org.
The document(s) to be published must already be published as
Internet-Drafts or, in the case of changing the status of an existing
RFC without changing the contents, as an RFC. The letter should list
the file names of the Internet-Drafts or the numbers of the RFC and
what type of RFC each document is being offered for. The current
standards track RFC types are: Proposed Standard, Draft Standard,
Standard and Best Current Practice (BCP). The current non-standards
track RFC types are: Informational, Experimental, and Historic. (RFC
2026, sections 4 and 5) The copy of the email to iesg-
secretary@ietf.org is to ensure that a record of the request is
entered in a tracking database. The request is then processed as
described in RFC 2026 section 6.1.2.
10. Non-working group, non standards track documents
An individual requests the publication of a document as a non-
standards track RFC by sending an email request to the RFC Editor
(rfc-editor@rfc-editor.org). The document(s) to be published must
already be published as Internet-Drafts and the email request must
include the filename of the Internet-Draft. The RFC Editor will
inform the IESG of the publication request and ask that the IESG
review the document within a reasonable time. (RFC 2026, section
4.2.3)
11. Non-working group standards track documents
An individual requests the publication of a document as a standards
track RFC by sending an email request to the IESG (iesg@ietf.org)
with a copy of the email to iesg-secretary@ietf.org. The document(s)
to be published must already be published as Internet-Drafts and the
email request must include the filename of the Internet-Draft or RFC
number and the type of RFC that each document is being offered for.
Bradner [Page 3]
Internet-Draft Secret Handshakes December 1998
In order for a non-working group document to be published in the IETF
standards track an IESG member must agree to "champion" the document
within the IESG. In general it would be a good idea for anyone
wanting to publish a standards track document without an IETF working
group to line up such a "champion" on the IESG before submitting
their request. The request is then processed as described in RFC 2026
section 6.1.2.
12. The Importance of Proper Formatting and References
Improperly formatted Internet-Drafts create additional work for the
RFC Editor which can delay RFC publication. All authors must read,
understand and follow RFC 2223 "Instructions to RFC Authors."
Particularly note that RFCs should not right-justified or hyphenated.
The RFC Editor will verify the references in any document that will
be published as an RFC and will communicate with the authors or the
IESG in the case of confusion. Since this can also delay RFC
publication it is in the best interest of the author to be sure that
all references are correct. Authors should note that standards track
RFCs may not make normative references to Internet-Drafts or
documents at a lower status in the standards track. (RFC 2026 section
4.2.4)
13. Additional notes
Documents are often reviewed by readers who are not as familiar with
the subject matter as the authors. Consequently, it helps to clearly
define all subject-specific terms, and can also help a great deal to
begin the document with an overview that discusses how the different
pieces fit together both internally and with respect to other
Internet elements. This will also benefit future readers of the
document, who may well approach it from a different context than did
the authors or as was originally envisioned.
There are two main sources of delay in the process: Area Director and
IESG review of documents and their revisions, and document authors
addressing review comments. As a document author, you control the
latter; you can endeavor to influence the former by judicious but
persistent use of polite email to the AD asking where the Area
Director or IESG review currently stands. It's part of the AD's job
to listen to such email, so feel free to send it.
If you are making minor revisions to a document in response to
comments form an AD or the IESG, you can expedite review of the
changes by sending a list of the specific differences between a new
and an earlier version of the document. This can be done with the
UNIX "diff" program.
14. Intellectual property rights
Bradner [Page 4]
Internet-Draft Secret Handshakes December 1998
It is important for every one who is publishing any IETF document to
read and understand the intellectual property rights section of RFC
2026 (section 10). The act of submitting a document for publication
by the IETF implies the acceptance of the intellectual property
rights terms and conditions in RFC 2026. Authors should particularly
note the copyright provisions.
15. Acknowledgements
Thanks to Vern Paxson for the contents of section 11.
16. Security Considerations
This type of non-protocol document does not directly affect the
security of the Internet.
17. References
RFC 2223: J. Postel, J. Reynolds - "Instructions to RFC Authors",
October 1997
RFC 2026: S. Bradner (Ed) - "The Internet Standards Process --
Revision 3", October 1996
RFC 2028: R. Hovey, S. Bradner "The Organizations Involved in the
IETF Standards Process", October 1996
18. Author's Address
Scott Bradner
Harvard University
1350 Mass Ave, rm 876
Cambridge, MA
02138
USA
phone: +1 617 495 3864
sob@harvard.edu
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Bradner [Page 5]
Internet-Draft Secret Handshakes December 1998
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bradner [Page 6]