Network Working Group                                      Scott Bradner
Internet-Draft                                        Harvard University
                                                            January 1999

        Secret Handshakes: How to get RFCs published in the IETF


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 (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (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 (1999).  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               January 1999

   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 separate, 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. (BCP 09, 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 [RFC 2223] and every April Fools Day one or
   more RFCs are published that are meant as parody or attempts at
   humor.  The RFC Editor also periodically publishes a new version of
   the Internet Official Protocol Standards RFC (also known as STD 1)
   that describes the state of standardization of protocols.  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. 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 BCP 11 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

Bradner                                                         [Page 2]

Internet-Draft              Secret Handshakes               January 1999

   decide that the document does not meet the quality or other standards
   for publication which the IESG is charged with maintaining, or that
   deployment of the technology described in the document could harm the
   Internet. In these cases the IESG can recommend that the RFC Editor
   not publish the document.

8. Internet Drafts
   Documents to be published as Internet-Drafts should be emailed to  The documents must be formatted according
   to the instructions in "The Guidelines to Authors of Internet-Drafts"
   ( and should be sent as
   plain text, not as a word processor enclosure. ([BCP 09] section 2.2)
   In addition all documents submitted as Internet-Drafts must include
   the header in the latest version of "The Guidelines to Authors of
   Internet-Drafts."  Authors should always retrieve the current version
   of the guidelines document 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
   As detailed in [BCP 25] section 3.3, such a request should only be
   made after ascertaining that there is working group consensus on the
   document.  This may involve a working group Last-Call.  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.
   ([BCP 09], sections 4 and 5) The copy of the email to iesg- is to ensure that a record of the request is
   entered in a tracking database.  The request is then reviewed by the
   Area Director and processed as described in [BCP 09] section 6.1.2
   including, for standards track documents, an IETF-wide Last-Call.

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
   (  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. ([BCP 09], section

Bradner                                                         [Page 3]

Internet-Draft              Secret Handshakes               January 1999

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 (
   with a copy of the email to  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.
   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 [BCP 09]
   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. ([BCP 09] section
   4.2.4)  This can be a source of delay in publishing a document even
   after IESG review since the RFC Editor must wait until all documents
   referenced in a normative way have been published at the appropriate
   standards level.

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

Bradner                                                         [Page 4]

Internet-Draft              Secret Handshakes               January 1999

   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.

   In some cases there can also be delay in the RFC Editor's office.
   This can happen when a document requires complex formatting, has many
   references, or if the RFC Editor's queue is full.

   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.  The use of change bars can also be helpful.

   The RFC Editor will only publish the specific version of an Internet
   Draft that the IESG has reviewed.  Specifically authors can not make
   changes, editing or otherwise, after the IESG review without the
   document being returned to the IESG to ensure that no sustentative
   changes were introduced.  Authors who have a few typos that need to
   be fixed can send a request to the RFC Editor to make specific
   editorial corrections.

14. Intellectual property rights
   It is important for every one who is publishing any IETF document to
   read and understand the intellectual property rights section of [BCP
   09] (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 [BCP 09].  Authors should particularly
   note the copyright provisions.

15. Acknowledgements
   Thanks to Vern Paxson for contributing to section 13.

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
   [BCP 09]: S. Bradner (Ed) - "The Internet Standards Process --
      Revision 3", October 1996
   [BCP 11]: R. Hovey, S. Bradner - "The Organizations Involved in the
      IETF Standards Process", October 1996
   [BCP 25]: S. Bradner (Ed) - "IETF Working Group Guidelines and
      Procedures:, September 1998

18. Author's Address

Bradner                                                         [Page 5]

Internet-Draft              Secret Handshakes               January 1999

   Scott Bradner
   Harvard University
   1350 Mass Ave, rm 876
   Cambridge, MA

   phone: +1 617 495 3864

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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
   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

   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

Bradner                                                         [Page 6]