One document matched: draft-bradner-handshake-00.txt

Network Working Group                                      Scott Bradner
Internet-Draft                                        Harvard University
                                                            October 1998


        Secret Handshakes: How to get RFCs published in the IETF

                    <draft-bradner-handshake-00.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 February, 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. 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
   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



Bradner                                                         [Page 1]

Internet-Draft              Secret Handshakes             September 1998


   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.

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

5. 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.  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 at the discretion of the IANA.

6. Common process features for other RFCs
   All documents proposed as RFCs other than those mentioned in section
   5 must first exist as Internet-Drafts and are reviewed by the IESG
   prior to publication.  The IESG has the responsibility to review each
   document that is put forth for publication as an RFC.  The IESG can
   approve a document for publication as-is or it can approve
   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 refer 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 for publication which the IESG is charged with maintaining.

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




Bradner                                                         [Page 2]

Internet-Draft              Secret Handshakes             September 1998


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

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

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

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



Bradner                                                         [Page 3]

Internet-Draft              Secret Handshakes             September 1998


   note the copyright provisions.

12. Security Considerations

   This type of non-protocol document does not directly effect the
   security of the Internet.

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

14. Author's Address

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

   phone: +1 617 495 3864
   sob@harvard.edu



























Bradner                                                         [Page 4]