INTERNET-DRAFT                                      J. Reynolds, Editor
draft-rfc-editor-rfc2223bis-08.txt                    R. Braden, Editor
Obsoletes: 2223                                              RFC Editor
Category: Informational                                   1 August 2004
Expires: February 2005



           Instructions to Request for Comments (RFC) Authors



Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


   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 a "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


IPR Statement


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


Abstract


   This memo provides information for authors of Request for Comments
   (RFC) documents.  It summarizes RFC editorial policies and formatting
   requirements, addresses frequently-asked questions, and serves as a
   model for constructing a properly formatted RFC.






RFC Editor                   Informational                      [Page 1]


Internet-Draft        Instructions to RFC Authors          1 August 2004



Table of Contents


   1. Introduction ..................................................  3
      1.1 Background on the RFC Document Series .....................  3
      1.2 Introduction to the RFC Publication Process ...............  4
   2.  General RFC Editorial Policies ...............................  7
      2.1 Immutability ..............................................  7
      2.2 Not all RFCs are Standards ................................  8
      2.3 Publication Language ......................................  8
      2.4 Publication Format(s) .....................................  9
      2.5 Consistent Document Style ................................. 10
      2.6 Assignment of RFC Numbers ................................. 10
      2.7 References and Citations .................................. 10
      2.8 URLs in RFCs .............................................. 11
      2.9 Titles .................................................... 11
      2.10 IANA Considerations ...................................... 12
      2.11 Relation to Other RFCs ................................... 12
      2.12 Authors Listed on RFCs ................................... 13
      2.13 April 1 RFCs ............................................. 14
      2.14 Requirement-Level Words .................................. 15
      2.15 Formal Languages in RFCs ................................. 15
   3. General Format Rules for RFCs ................................. 16
      3.1 General Formatting Rules .................................. 16
      3.2 PostScript Format Rules ................................... 19
      3.3 Header and Footer Formats ................................. 20
      3.4 Protocol Data Definitions ................................. 20
   4. Sections in an RFC ............................................ 21
   5. Intellectual Property ......................................... 28
   6. RFC Information and Contacts .................................. 31
   7. Security Considerations ....................................... 31
   8. Acknowledgments ............................................... 31
   Appendix A - IPR Boilerplate ..................................... 32
   Appendix B - RFC Preparation Tools ............................... 34
   Appendix C - Checklist ........................................... 36
   Appendix D - Changes from RFC 2223 ............................... 38
   Normative References ............................................. 39
   Informative References ........................................... 40
   CHANGES (To be removed by RFC Editor before publication) ......... 41
   Authors' Addresses ............................................... 43













RFC Editor                   Informational                      [Page 2]


Internet-Draft        Instructions to RFC Authors          1 August 2004



1.  Introduction


   This memo provides information for authors of Request for Comments
   (RFC) documents.  It summarizes RFC editorial policies and formatting
   requirements, addresses frequently-asked questions, and serves as a
   model for constructing a properly formatted RFC.


   1.1 Background on the RFC Document Series


      The Requests for Comments documents, commonly known as RFCs, form
      an archival series of more than 3800 memos about computer
      communication and packet switching networks.  Included prominently
      in the RFC series are the official technical specifications of the
      Internet protocol suite; these are defined by the Internet
      Engineering Task Force (IETF) under the direction of the Internet
      Engineering Steering Group (IESG).  As a result, RFC publication
      plays a significant role in the Internet standards process
      [RFC2026].


      The RFC series was begun in 1969 as a set of technical and
      organizational notes by the ARPAnet research community.  Since the
      early 1980s, the series has focused on the development of the
      Internet and the TCP/IP protocol suite.  Memos in the RFC series
      discuss many aspects of networking, including protocols,
      procedures, programs, and concepts as well as meeting notes,
      opinions, and sometimes humor.  For more information on the
      history of the RFC series, see RFC 2555, "30 Years of RFCs"
      [Hist99].


      RFCs are numbered (roughly) consecutively, and these numbers
      provide a single unique label space for all RFCs.  RFCs are
      published on-line through a number of repositories (see [RFCed]),
      and there is an online index of RFCs.


      Each RFC is labeled with a category: Standards Track, Best Current
      Practice, Experimental, Informational, or Historic.


           Note on terminology: The Category attribute of an RFC has
           sometimes been called its status, but the term "status" has
           been overloaded.  In the early years, it was used to mean the
           requirement level of a specification, e.g., "Required" or
           "Elective" (see, for example, RFC2400.)  Later this single
           status attribute proved too simplistic, so it was replaced by
           more general Applicability Statements [RFC2026].  More
           recently, we began to refer to the "category" as the
           "status".  However, this attribute is always listed on RFCs
           as the Category (see Section 4.1.)





RFC Editor                   Informational                      [Page 3]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      RFCs in the Standards Track category are published on behalf of
      the IETF, with IESG approval.  The IETF assigns a maturity level
      -- Proposed Standard, Draft Standard, or Standard -- to each Stan-
      dards Track RFC.  The current maturity levels of all Standards
      Track RFCs are specified in STD 1, "Official Internet Protocol
      Standards" [STD1] and in the RFC index; they are not specified on
      the RFCs themselves.


      In addition to the master RFC index, there are secondary indexes
      for useful subsets or "sub-series" of the RFCs.  Three sub-series
      are in use:


      o    STD document -- Category is Standards Track, maturity level
           is Standard [STD92].


      o    BCP document -- Category is Best Current Practice [BCP95]


      o    FYI document (For Your Information) -- Category is
           Informational [FYI90]


      An RFC in a sub-series is labeled with its sub-series number as
      well as its RFC number.


      The RFC series is published by the RFC Editor, under funding
      provided by the Internet Society (ISOC) and under the supervision
      of the Internet Architecture Board (IAB).  The RFC Editor is
      responsible for the final editorial review and the on-line
      publication of RFCs.  The RFC Editor also maintains the official
      RFC archive and the index files and makes these accessible via the
      Web, FTP, and email [RFCed].  The RFC Editor also maintains a list
      of errata for previously-published RFCs.  Since 1977, the RFC
      Editor function has been performed by staff at the Information
      Sciences Institute of the University of Southern California
      (USC/ISI).


      In performing its function, the RFC Editor works closely with the
      IESG and with the Internet Assigned Numbers Authority (IANA).


   1.2 Introduction to the RFC Publication Process


      This section contains a brief overview of the submission, review,
      and publication process for RFCs.  More details, especially for
      standards-track RFCs, will be found in RFC 2026, "The Internet
      Standards Process -- Revision 3" [RFC2026], as amended by later
      IETF policy statements.  RFC 2026 and amendments, or its
      successor, takes precedence in the case of any apparent conflict
      with the following overview.





RFC Editor                   Informational                      [Page 4]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      1.2.1 RFC Submission and Review


         To be considered for publication as an RFC, a document must
         first be submitted as an Internet-Draft (I-D) [RFC2026]. This
         ensures an opportunity for feedback from members of the
         Internet community and from the IESG.  The Internet Draft must
         include boilerplate that allows RFC publication (see
         "Guidelines to Authors of Internet-Drafts" [IDguide]).


         The submission and review procedures for RFCs depend upon the
         document's source.  RFC submissions may come from the IETF,
         from the IAB, from the Internet Research Task Force (IRTF), or
         from an individual.


         o Submissions from the IETF


            RFCs originating in the IETF are submitted to the RFC Editor
            via the IESG, which reviews them for technical quality and
            procedural conformance.  These IESG submissions are
            transmitted to the RFC Editor via official "Protocol Action"
            messages that are recorded at the IETF web site.
            Submissions through the IESG may be in any of the categories
            (Standards Track, Best Current Practice, Experimental,
            Informational, or Historic.)  All submissions in the
            Standards Track or Best Current Practice category must first
            be submitted to the IESG for approval; the IESG will submit
            them to the RFC Editor.


            At IESG request, the RFC Editor will add an "IESG Note" to a
            published RFC, to provide clarification or guidance to
            readers.


         o Submissions from the IAB


            The IAB may submit documents directly to the RFC Editor for
            publication as RFCs in the Informational or Experimental
            category, without IESG approval or review.


         o Independent Submissions


            Individuals may submit documents directly to the RFC Editor
            for publication as RFCs in the Experimental or Informational
            category.


            The RFC Editor reviews each such "independent submission"
            for relevancy and appropriateness as well as general
            compliance with the rules in Sections 2, 3 and 4 of this
            document.  Updates are requested as necessary, sometimes




RFC Editor                   Informational                      [Page 5]


Internet-Draft        Instructions to RFC Authors          1 August 2004



            through several iterations, until an acceptable submission
            document is achieved.


            To maintain the integrity of the RFC document series and to
            avoid wasting scarce publication resources, the RFC Editor
            may reject an indepedent submission because its content is
            uninteresting or irrelevant, or because its editorial
            quality is acceptable.  The RFC Editor will attempt to
            explain as clearly and completely as possible the reasons
            for rejection.  For evaluation of content, the RFC Editor
            may consult individuals expert in the field.


            Once the RFC Editor has determined that an independent
            submission is acceptable, the document is passed to the IESG
            for review for conflict with work in progress in the IETF
            [RFC2026].  When its topic is closely related to an existing
            IETF Working Group, the IESG may request that the author
            coordinate with that working group.  This may result in the
            production of a revised memo that eventually emerges from
            the IETF process as an IETF submission.  The IESG may also
            provide input to the RFC Editor on content problems with the
            document; the RFC Editor will request that the author(s)
            attempt to address these concerns before publication.


            If the IESG feels that the submitted document does conflict
            with the IETF process, they will make a "Do Not Publish"
            recommendation to the RFC Editor.  The RFC Editor may then
            reject the document, or publish it with an "IESG Position"
            statement that defines IESG objections to the document or
            narrows its scope of applicability.  The IESG may
            alternatively ask for deferred publication, via a "Do Not
            Publish Now" recommendation, for a maximum of two six-month
            intervals.  This should allow completion of any conflicting
            working group activity.


            In general, the RFC Editor is charged with the final
            decision about publication of an independent submission.


         o Submission from the IRTF


            RFC submissions from IRTF members are normally treated as
            independent submissions.


         1.2.2 RFC Publication


            A document that is submitted to the RFC Editor enters the
            RFC Editor's queue, which is viewable at the RFC Editor Web
            site [RFCed].  The document (Internet Draft) remains in the




RFC Editor                   Informational                      [Page 6]


Internet-Draft        Instructions to RFC Authors          1 August 2004



            RFC Editor queue until it is published as an RFC, unless (1)
            the author withdraws it, (2) the author is very unresponsive
            in making requested updates, or (3) it is an independent
            submission that is deemed unacceptable by the RFC Editor.


            The RFC Editor ensures that the document follows the
            editorial rules described later in this document.  The RFC
            Editor may make editorial changes to clarify readability and
            to provide a uniform style and format.  If excessive work is
            required to satisfy the rules and/or to bring the RFC up to
            publication quality, the memo may be returned to the author
            or to the IESG for additional work.


            When editing of the document is complete, the RFC Editor
            sends the result to the authors for careful proof-reading.
            This quality control step is critical to maintaining the
            quality of RFCs.  Although this process is traditionally
            called the "Authors' 48 Hours" period, the RFC Editor is
            always willing to give authors reasonable additional time to
            review the document, and a document will not be published
            until all its listed authors agree.  While it is helpful to
            have one principal author during the editing process, all
            listed authors will be considered responsible for the
            correctness of the final document.


            In practice, the editorial process among the IESG, the RFC
            Editor, and the author(s) can be lengthy and convoluted, and
            the time spent in the RFC Editor's queue can vary greatly.
            Sometimes problems are found that require document revisions
            by the authors.  These revisions may require the publication
            of another Internet-Draft, and the result must be re-
            reviewed.  Publication may be held up awaiting IANA
            assignments, or in order to synchronize the publication of
            related RFCs.


2.  General RFC Editorial Policies


   This section summarizes some general editorial and publication
   policies for RFCs.  Individual policies may be modified or new
   policies added before the present document is revised.  RFC authors
   should obtain the latest RFC editorial policy statements from the RFC
   Editor web page [RFCed].


   2.1 Immutability


      Since the RFCs form an archival series, an RFC cannot be altered
      once it is published.  To change the contents of an RFC, a new RFC
      must be written that obsoletes the previous one.  (Early in the




RFC Editor                   Informational                      [Page 7]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      history of RFCs, the Editor did occasionally make small editorial
      changes after publication, but this led to confusion regarding
      which version was correct, and it was a slippery slope.  To avoid
      these pitfalls, the never-change rule is now strictly enforced.)


      Although RFCs are subjected to careful scrutiny by the RFC Editor
      and the authors before publication, errors do sometimes creep in.
      For this reason, the RFC Editor strongly urges the authors to
      thoroughly review the document during the "Authors' 48 hours"
      period.


      The RFC Editor maintains an online list of errata for existing
      RFCs.  If you find what you believe to be an error in an RFC,
      consult the errata page at the RFC Editor web site [RFCed].  If
      the bug is not listed, please send email to the authors of the
      document and to the RFC Editor.


   2.2 Not all RFCs are Standards


      Eager salesmen have been known to imply that all RFCs represent
      official Internet standards.  This is false and misleading.  While
      some RFCs are Standards Track documents, many have other
      categories and do not represent a standard of any kind.


   2.3 Publication Language


      Like the Internet itself, the IETF and the Internet Society are
      international organizations with participation from all areas of
      the world.  However, English is the primary language in which IETF
      business is conducted, and English is the official publication
      language for RFCs.


      RFCs submitted for publication are required to meet a reasonable
      standard for clear and correct English.


      RFC 2026 specifically allows RFCs to be translated into languages
      other than English.  Repositories may exist for RFCs that have
      been translated into particular languages. This is highly
      desirable and useful.  However, it is not possible for the RFC
      Editor to certify that such translations are accurate.  Therefore,
      the function of the RFC Editor, with respect to non-English RFCs,
      is limited to providing pointers to non-English language RFC
      repositories.  Upon request, the RFC Editor will list any such
      repository on its Web page.








RFC Editor                   Informational                      [Page 8]


Internet-Draft        Instructions to RFC Authors          1 August 2004



   2.4 Publication Format(s)


      RFCs are published as plain text files in the [US-]ASCII character
      set, with the file name extension ".txt".


           The continued use of ASCII plain text for RFCs, despite the
           spread of "more modern" formats, is intermittently debated by
           the Internet community.  The consensus continues to be that
           the great advantages of ASCII plain text -- the ability to
           readily edit, cut-and-paste, and search documents, the
           ubiquitous availability of tools for these functions, and the
           longevity of US-ASCII as a character standard -- make ASCII
           plain text the clear winner.


      For the convenience of those whose operating systems have
      difficulty supporting plain ASCII text, the RFC Editor also
      maintains PDF files that are exact facsimiles of the plain text
      versions.


      The ASCII plain text version (and its .txt.pdf facsimile) is
      always the official specification, and it must adequately and
      completely define the technical content.  (A very few exceptions
      have been made over the 30 year history of RFCs, allowing a
      definitive PostScript (.ps) version with no
       .txt version.)  The primacy of the ASCII version typically
      requires that the critical diagrams and packet formats be rendered
      as "ASCII art" in the .txt version.


      However, secondary or alternative versions in PostScript and/or
      PDF are provided for some RFCs, to allow the inclusion of fancy
      diagrams, graphs, or characters that cannot possibly be rendered
      in ASCII plain text.  If there is a PostScript (.ps) or PDF (.pdf)
      version of the document, the author should inform the RFC Editor
      at the time of submission of the .txt version.


      PostScript and PDF versions suffer from a serious flaw: the RFC
      Editor cannot easily make editorial changes in the source file to
      produce a new document in either of these formats.  This can make
      the editorial process for .ps and .pdf versions somewhat painful
      for both the author and editor.  The following procedure is
      followed.  When a .ps (or .pdf) version is submitted with a .txt
      version, the RFC Editor will first edit the .txt version.  The
      final form of the .txt version (or, when feasible, the diffs) will
      be returned to the author.  The author must then update the
      .ps/.pdf files to match, as closely as possible, the content and
      format of the ASCII .txt file.  When the RFC Editor agrees that
      the .ps/.pdf versions are acceptable, they are published
      simultaneously with the .txt version.




RFC Editor                   Informational                      [Page 9]


Internet-Draft        Instructions to RFC Authors          1 August 2004



   2.5 Consistent Document Style


      The RFC Editor attempts to enforce a consistent style of RFCs.  To
      do this, the RFC Editor may choose to reformat a submitted RFC or
      ask the author to reformat it.  Effort is minimized when the
      submitted document matches the style of the most recent RFCs.
      Please read the rules and recommendations that are presented in
      following sections of this memo and look at some recent RFCs, to
      adopt an appropriate style.


      To format most ASCII RFCs for publication, the RFC Editor uses the
      "nroff" program with a simple set of the formatting commands (or
      "requests") from the "ms" macro package (see Appendix B).  If the
      author has an nroff source file, it will be helpful to make this
      available to the RFC Editor when the document is submitted.


      When a .ps version is published, the RFC Editor will also publish
      a matching .pdf version.  When a .txt version is published, the
      RFC Editor will also publish a matching .txt.pdf version.


   2.6 Assignment of RFC Numbers


      RFC numbers are not assigned until very late in the editorial
      process, to avoid gaps in the RFC number series.  Requests for
      early assignment of an RFC number are generally denied unless they
      originate from the IAB or the IESG.


   2.7 References and Citations


      An RFC will generally contain bibliographic references to other
      documents, and the body will contain citations to these
      references.  Section 4.7f specifies the format for the references
      listed at the end of the RFC body, but there is no required format
      for a citation.


      Within an RFC, references to other documents fall into two general
      categories: "normative" and "informative".  Normative references
      specify documents that must be read to understand or implement the
      technology in the new RFC, or whose technology must be present for
      the technology in the new RFC to work.  An informative reference
      is not normative; rather, it provides only additional information.
      For example, an informative reference might provide background or
      historical information.  Material in an informative reference is
      not required to implement the technology in the RFC.


      An RFC must include separate lists of normative and informative
      references (see Section 4.7f below.)  The distinction between
      normative and informative references is often important.  The IETF




RFC Editor                   Informational                     [Page 10]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      standards process and the RFC Editor publication process need to
      know whether a reference to a work in progress is normative.  A
      standards-track RFC cannot be published until all of the documents
      that it lists as normative references have been published.  In
      practice, this often results in the simultaneous publication of a
      group of interrelated RFCs.


      We recommend enclosing citations in square brackets ("[ ]").
      Simple numeric citations ("[53]") can cause confusing gaps when
      the list of references is split between normative and informative.
      A good alternative is to have two separate series, "[n1]", "[n2]",
      ... "[i1]", "[i2]" for citations to normative and informative
      references.  Other choices include author abbreviations, possibly
      a year ("[Smith93]"), and some brief encoding of the title and
      year ("[MPLS99a]").


   2.8 URLs and DNS names in RFCs


      The use of URLs in RFCs is discouraged, because many URLs are not
      stable references.  Exceptions may be made for normative
      references in those cases where the URL is demonstrably the most
      stable reference available.  References to long-lived files on
      ietf.org and rfc-editor.org are generally acceptable.


      DNS names, whether or not in URLs, that as used as generic
      examples in RFCs should use the particular examples defined in RFC
      2606, "Reserved Top-Level DNS Names" [TLD99], to avoid accidental
      conflicts.


   2.9 Titles


      Choosing a good title for an RFC can be a challenge.  A good title
      should fairly represent the scope and purpose of the document
      without being either too general or too specific.


      Abbreviations (e.g., acronyms) in a title (as well as the Abstract
      and the body; see Sections 4.5 and 4.7) must generally be expanded
      when first encountered.  The exception is abbreviations that are
      so common that every participant in the IETF can be expected to
      recognize them immediately; examples include (but are not limited
      to) TCP, IP, SNMP, and FTP.  Some cases are marginal and the
      decision on expansion may depend upon the specific title.  The RFC
      Editor will make the final judgment, weighing obscurity against
      complexity.


      It is often helpful to follow the expansion with the parenthesized






RFC Editor                   Informational                     [Page 11]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      abbreviation, as in the following example:


                               Encoding Rules for the
               Common Routing Encapsulation Extension Protocol (CREEP)


      Authors should be aware that the title of an RFC may be subject to
      policy considerations in addition to the requirement that it
      provide a concise and technically sound summary of the document
      contents.  For example, at various times in the history of the
      IETF, the words "Requirements" and "Policies" as well as the
      phrase "The Directory" have been banned from RFC titles, each for
      its own reason.


      RFCs that document a particular company's private protocol must
      bear a title of the form "XXX's ... Protocol" (where XXX is a
      company name), to clearly differentiate it from an IETF product.


   2.10 IANA Considerations


      Many RFCs define protocol specifications that require the
      assignment of values to protocol parameters, and some define new
      parameter fields.  Assignment of these parameter values is often
      (and sometimes must be) deferred until publication of the defining
      RFC.  The IANA and the RFC Editor collaborate closely to ensure
      that all required parameters are assigned and entered into the
      final RFC text.


      Any RFC that defines a new "namespace" of assigned numbers must
      include an IANA Considerations section specifying how that space
      should be administered.  See "Guidelines for Writing an IANA
      Considerations Section in RFCs" [IANA98] for a detailed discussion
      of the issues to be considered and the contents of this section.


      Current policy (not documented in [IANA98]) is to include an IANA
      Considerations section always, even if it is "null", i.e., even if
      there are no IANA considerations.  This is helpful to IANA.
      However, the RFC Editor may remove any null IANA considerations
      sections before publication.


   2.11 Relation to other RFCs


      Sometimes an RFC adds information on a topic discussed in a
      previous RFC or completely replaces an earlier RFC.  Two terms are
      used for these cases: Updates and Obsoletes, respectively.








RFC Editor                   Informational                     [Page 12]


Internet-Draft        Instructions to RFC Authors          1 August 2004



         Updates


            Specifies an earlier document whose contents are modified or
            augmented by the new document.  The new document cannot be
            used alone, it can only be used in conjunction with the
            earlier document.


         Obsoletes


            Specifies an earlier document that is replaced by the new
            document.  The new document can be used alone as a
            replacement for the obsoleted document.  The new document
            may contain revised information or all of the same
            information plus some new information, however extensive or
            brief that new information may be.


      In lists of RFCs and in the RFC-Index (but not on the RFCs
      themselves) the following are used for older documents that were
      referred to by Obsoletes or Updates relations in newer documents:


         Obsoleted-by


            Used to specify newer document(s) that replace the older
            document.


         Updated-by


            Used to specify newer document(s) that modify or augment the
            older document.


   2.12 Authors Listed on RFC


      The IESG and IETF have ratified a policy of limiting the number of
      authors listed in the first page header of an RFC.  The specific
      policy is as follows:


      (1)  A small set of author names, with affiliations, may appear on
           the front page header.  These should be the lead author(s)
           who are most responsible for the actual text.  When there are
           many contributors, the best choice will be to list the person
           or (few) persons who acted as document editor(s) (e.g.,"Tom
           Smith, Editor").


           There is no rigid limit on the size of this set, but there is
           likely to be a discussion if the set exceeds five authors, in
           which case the right answer is probably to list one editor.


           The RFC Editor will hold all the people listed on the front




RFC Editor                   Informational                     [Page 13]


Internet-Draft        Instructions to RFC Authors          1 August 2004



           page equally responsible for the final form and content of
           the published RFC.  In particular, the "Author's 48 Hours"
           final approval period will require signoff from all listed
           authors.


      (2)  An RFC may include a Contributors section, listing those
           contributors who deserve significant credit for the document
           contents.  The Contributors section is intended to provide a
           level of recognition greater than an acknowledgment and
           nearly equal to listing on the front page.  The choice of
           either, both, or none of Contributor and Acknowledgment
           sections in a particular RFC depends upon the circumstance.


      (3)  The body of an RFC may include an Acknowledgements section,
           in addition to or instead of a Contributors section.  An
           Acknowledgments section may be lengthy, and it may explain
           scope and nature of contributions.  It may also specify
           affiliations.


      (4)  The Author's Address section at the end of the RFC must
           include the authors listed in the front page header.  The
           purpose of this section is to (1) unambiguously define
           author/contributor identity (e.g., the John Smith who works
           for FooBar Systems) and to (2) provide contact information
           for future readers who have questions or comments.


           At the discretion of the author(s), contact addresses may
           also be included in the Contributors section for those
           contributors whose knowledge makes them useful future
           contacts for information about the RFC.


      (5)  The RFC Editor may grant exceptions to these guidelines upon
           specific IESG request or in other exceptional circumstances.


      Finally, it is important to note that the copyright rules
      governing RFC publication [IPC04] require that an RFC must:


           "[acknowledge] all major Contributors.  A major Contributor
           is any person who has materially or substantially contributed
           to the [RFC]."


      The Contributors and Acknowledgment sections fulfill this
      objective.


   2.13 April 1 RFCs


      Many years ago the RFC Editor established the practice of
      publishing one or more satirical documents on April 1 of each




RFC Editor                   Informational                     [Page 14]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      year.  Readers should be aware that many of the RFCs bearing the
      date April 1 are not to be taken seriously.  The RFC Editor
      reviews April 1 RFC submissions for cleverness, humor, and topical
      association with computer networking, and a few of the best are
      published.  Submissions must be made to the RFC Editor in time for
      review and publication.


      Note that in past years the RFC Editor has sometimes published
      serious documents with April 1 dates.  Readers who cannot
      distinguish satire by reading the text may have a future in
      marketing.


   2.14 Requirement-Level Words


      Some standards-track documents use certain capitalized words
      ("MUST", "SHOULD", etc.) to specify precise requirement-levels for
      technical points.  RFC 2119 (BCP 14) [BCP14] defines a default
      interpretation of these capitalized words in IETF documents.  If
      this interpretation is used, RFC 2119 must be cited (as specified
      in RFC 2119) and included as a normative reference.  Otherwise,
      the correct interpretation must be specified in the document.


      Avoid abuse of requirement-level words.  They are intended to
      provide guidance to implementors about specific technical
      features, generally governed by considerations of
      interoperability.  RFC 2119 says, "Imperatives of the type defined
      in this memo must be used with care and sparingly.  In particular,
      they MUST only be used where it is actually required for
      interoperation or to limit behavior which has potential for
      causing harm (e.g., limiting retransmissions).  For example, they
      must not be used to try to impose a particular method on
      implementors where the method is not required for
      interoperability."  To simply specify a necessary logical
      relationship; the normal lower-case words should be used.  On the
      other hand, if the capitalized words are used in a document, they
      must be used consistently throughout the document.


   2.15 Formal Languages in RFCs


      See [Lang01] for IESG guidance on the use of formal languages in
      RFCs.  The RFC Editor will run every MIB through a MIB checker
      before publication, and machine verification of other formal
      languages included in RFCs may be required.









RFC Editor                   Informational                     [Page 15]


Internet-Draft        Instructions to RFC Authors          1 August 2004



3. General Format Rules for RFCs


   This section defines the general rules governing the format of a
   published RFC (as opposed to requirements on submitted documents).
   Authors are requested to come as close to these rules as reasonable,
   but in any case the RFC Editor will ensure they are met before
   publication.  For example, the RFC Editor will supply headers and
   footers, adjust pagination to avoid "widows", and adjust a Table of
   Contents accordingly.


   However, author attention to these rules will streamline the
   publication process and reduce the average publication time.  If
   reaching the final format requires excessive effort by the RFC
   Editor, the author will be asked to assist in the reformatting.
   Authors are admonished to proof-read the final publication form
   carefully, to ensure that no errors accidentally crept in.


   These formatting rules are intentionally incomplete in some details.
   They attempt to define only what is strictly necessary for uniformity
   and simplicity (a virtue).  Some latitude is allowed to accommodate a
   broad range of printers, systems, and evolving requirements.  The
   general objective is to create a series of documents that are
   reasonably uniform and are easy to read, while accommodating a wide
   range of content.


   Note that these rules govern an RFC as published.  During the
   publication process the RFC Editor will verify compliance and will
   repair minor infractions.


   3.1  General Formatting Rules


       (1) Character code


           The character code is US-ASCII [ASCII69] (also known as ISO
           646.IRV).  Only the printable ASCII characters and the three
           control characters CR, LF, and FF are allowed.


                Notes: CR and LF must be used only as provided in rule
                (2), and FF must be used only as provided in rule (3).
                Tab (HT) characters and Backspace (BS) characters are
                never allowed (hence there can be no underlining; see
                (4) below).


       (2) Width


           Each line must be limited to 72 characters followed by the
           character sequence that denotes an end-of-line (EOL).  This
           limit includes any left-side indentation.




RFC Editor                   Informational                     [Page 16]


Internet-Draft        Instructions to RFC Authors          1 August 2004



                Note: A plain-text RFC is expected to be stored on a
                disk file using the EOL sequence of that system.  For
                example, MS DOS-based systems use the two-character
                sequence: CR LF (Carriage Return followed by Line Feed),
                Unix systems use the single character LF for EOL, and
                EBCDIC systems use the single character NL (New Line).


                Whenever an RFC is transmitted across the Internet,
                Internet protocol convention requires that each line of
                text be followed by the two-character EOL sequence CR LF
                (Carriage Return followed by Line Feed).  A user level
                protocol (e.g., FTP, Telnet, HTTP, SMTP, ...) must make
                the appropriate EOL transformation at each line end.
                Note that binary transmission of plain-text RFC files
                can cause the sender's EOL convention to "leak" into the
                receiver, causing confusion.


       (3) Height


           Each page must be limited to 58 lines followed by a Form Feed
           (FF) character, followed by an EOL sequence.  The 58 line
           limit includes the headers and footers specified below.


           All pages, except perhaps the first and last, should have the
           same number of lines when headers and footers are included.
           That is, footers should not "bounce" from page to page.


                Note: The maximum line count includes blank lines.
                However, the first line will normally be the first
                header line and the last line will be the final footer
                line; that is, it will not begin or end with a blank
                line.


                Note: 58 lines is the maximum; 55 is more commonly used
                and may actually produce more readable formatting.  The
                recommended page formatting parameters (see Appendix B)
                produce 55 line pages on many printers, for example.


                Note: The effect of the Height rule is that the
                following character sequence will be used:


                  <Last non-blank line of page p> <EOL> FF <EOL>


                                  <First line of page p+1> <EOL> ...


                As transmitted across the Internet as ASCII text, the
                character sequence is:





RFC Editor                   Informational                     [Page 17]


Internet-Draft        Instructions to RFC Authors          1 August 2004



                  <Last non-blank line of page p> CR LF FF CR LF


                                  <First line of page p+1> CR LF ...


                Finally, note that the sequence FF CR LF has an
                ambiguous effect: on some printers, the FF implies an
                EOL, so this may produce a blank line; on other printers
                it will produce no blank line.  The number 58 and this
                sequence were designed to render this ambiguity
                unimportant, assuming the (once predominant) printer
                standard of 60 lines per page.


       (4) No Overstriking


           No overstriking (or underlining) is allowed.


       (5) No Filling


           Do not fill the text with extra spaces to provide a straight
           right margin.  Do not right justify the text.


       (6) No Hyphenation


           Do not use hyphenation at the right margin to split existing
           words.  However, hyphenated word sequences (e.g., "Internet-
           Draft") may be split at the hyphen across successive lines.


                Note: There are good reasons why the right page margin
                is required to be "ragged", and why hyphenation of words
                at the right margin is prohibited.  Studies have shown
                that text is harder to read when fixed-size spaces are
                inserted to adjust the right margins, regardless of
                which font is used or how smoothly the blank filler is
                inserted.  In addition, when technical text in a fixed-
                width font is hyphenated at the right margin, the
                printed result is not only less readable but also ugly.


       (7) Spaces at the End of a Sentence


           When a sentence ended by a period is immediately followed by
           another sentence, there should be two blank spaces after the
           period.  This rule provides clarity when an RFC is displayed
           or printed with a fixed-width font.


       (8) Footnotes


           Do not use footnotes.  If such notes are necessary, put them
           at the end of a section, or at the end of the document.




RFC Editor                   Informational                     [Page 18]


Internet-Draft        Instructions to RFC Authors          1 August 2004



       (9) Line Spacing


           Use single-spaced text within a paragraph, and one blank line
           between paragraphs.


      (10) Page Numbering


           Pages must be numbered consecutively, starting from 1 on the
           first (cover) page.


      (11) Headers and Footers


           RFCs must have running headers and footers, as defined below
           in Section 3.3.  The headers and footers must be separated
           from the body by at least one and preferably two blank lines.


      (12) Indentation


           Successive indentation of sub-subsections (as in this
           document, for example) is recommended but not required.
           Experience has shown that indentation by multiples of 3
           columns works well.  In any case, the careful use of
           indentation can make a very great improvement in the
           readability of a document.


   3.2  PostScript Format Rules


      (1p) Standard page size is 8 1/2 by 11 inches (216 by 279 mm).


      (2p) Leave a margin of 1 inch (25 mm) on all sides (top, bottom,
           left, and right).


      (3p) Main text should have a point size of no less than 10 points
           with a line spacing of 12 points.


      (4p) Footnotes and graph notations no smaller than 8 points with a
           line spacing of 9.6 points.


      (5p) Three fonts are acceptable: Helvetica, Times Roman, and
           Courier, plus their bold-face and italic versions.  These are
           the three standard fonts on most PostScript printers.


      (6p) Prepare diagrams and images based on lowest common
           denominator PostScript.  Consider common PostScript printer
           functionality and memory requirements.


      (7p) The following PostScript commands should not be used:
           initgraphics, erasepage, copypage, grestoreall, initmatrix,




RFC Editor                   Informational                     [Page 19]


Internet-Draft        Instructions to RFC Authors          1 August 2004



           initclip, banddevice, framedevice, nulldevice or renderbands.


   3.3  Header and Footer Formats


      RFCs must include running headers and footers that obey the
      following rules.


      o Running Headers


         The running header in one line (on page 2 and all subsequent
         pages) has the RFC number on the left (RFC nnnn), the title
         (possibly shortened) in the center, and the publication date
         (Month Year) on the right.


      o Running Footers


         All pages contain a one-line running footer, with the author's
         last name on the left, the category centered, and the page
         number on the right ("[Page nn]").


         If there are two authors, the form "name & name" may be used;
         for more than two authors, use the form "name, et al."


   3.4  Protocol Data Definitions


      Many years ago, the RFC series adopted a pictorial approach to
      representing data structures such as protocol headers.
      Furthermore, the research community adopted a "big-endian"
      convention in which the bits and bytes are shown in network byte
      order, byte zero is the first byte shown, and bit zero is the most
      significant bit in a word or a field [IEN137].


      For example, RFC 791 contains the following definition of the IP
      header format.


















RFC Editor                   Informational                     [Page 20]


Internet-Draft        Instructions to RFC Authors          1 August 2004



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of Service|          Total Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|      Fragment Offset    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |         Header Checksum       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Options                    |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Example Internet Datagram Header


   We strongly recommend that a new RFC follow the same formatting
   conventions, which have been found to work well.  Any alternative
   style must meet the same level of clarity, readability, and lack of
   ambiguity.  An author wishing to use an alternative style should
   discuss it with the RFC Editor.


4.  Sections in an RFC


   A published RFC may contain the sections in the following list.  Some
   of these sections are required, as noted.  The order shown is
   required, except that the order shown for the sub-items 7a-7f within
   Body of Memo is generally recommended but not required.


      1.  First-page header           [Required]
      2.  Status of this Memo         [Required*]
      3.  Copyright Notice            [Required*]
      4.  IESG Note                   [As requested by IESG*]
      5.  Abstract                    [Required]
      6.  Table of Contents           [Required for large documents]
      7.  Body of the Memo            [Required]
       7a.  Contributors
       7b.  Acknowledgments
       7c.  Security Considerations   [Required]
       7d.  IANA Considerations
       7e.  Appendixes
       7f.  References
      8. Author's Address             [Required]
      9. IPR Boilerplate              [Required*]


   Those sections marked with * will be supplied by the RFC Editor




RFC Editor                   Informational                     [Page 21]


Internet-Draft        Instructions to RFC Authors          1 August 2004



   during the editorial process when necessary.


   The rules for each of these sections are described below in
   corresponding subsections.


   The Body of the Memo will normally contain section numbers (or
   Appendix labels).  Sections listed as 1-6 and 8-9 are to be
   unnumbered.


   4.1.  First-Page Header


      Please see the front page of this memo for an example of the front
      page heading.  On the first page there is no running header.  The
      top of the first page has the following items left justified:


      "Network Working Group"


         This traditional title must be left-justified on the first line
         of the heading.  It denoted the ARPAnet research group that
         founded the RFC series.


      "Request for Comments: nnnn"


         Identifies this as an RFC and specifies the RFC number, left-
         justified on the second line.  The actual number is filled in
         at the last moment prior to publication by the RFC Editor.


      "BCP: nn" or
      "FYI: nn" or
      "STD: nn"


         One of these optional left-justified items indicates the sub-
         series number, if the RFC is a member of a sub-series.  The
         actual number is filled in at the last moment prior to
         publication by the RFC Editor.


      "Updates: nnnn" or "Updates: nnnn, ..., nnnn"


         Optional left-justified field, containing an RFC number or a
         comma-separated list of RFC numbers that are updated by this
         RFC.  See Section 2.11.


      "Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"


         Optional left-justified field containing an RFC number or a
         comma-separated list of RFC numbers that are obsoleted by this
         RFC.  See Section 2.11.





RFC Editor                   Informational                     [Page 22]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      "Category: xxxxxxxxx"


         Required left-justified field specifying the category of this
         RFC.  Here xxxxxxxx may be one of:  Standards Track, Best
         Current Practice, Informational, or Experimental.  Will be
         supplied by RFC Editor, according to request of submittor.


      The following information appears right-justified in the header:


      Author


         The author's name (initial of first given name followed by
         family name), right-justified on the first line of the heading.


      Organization


         The author's organization, indicated on the line following the
         Author name.


         For multiple authors, each author name appears right-justified
         on its own line, followed by that author's organization.  When
         more than one author has the same organization, the
         organization can be "factored out" and appear only once
         following the corresponding Author lines.  However, such
         factoring is not necessary if it results in an unacceptable
         reordering of author lines.


         The total number of authors is generally limited; see Section
         2.12.


      Date


         The month and year of the RFC Publication, right-justified on
         the line after the last Organization line.


      The title appears, centered, below the rest of the heading,
      preceded and followed by at least one blank line.  Periods
      ("dots") are not allowed in the title.


      The title should be carefully chosen to accurately reflect the
      contents of the document.  See also Section 2.9.


   4.2. Status of this Memo


      The RFC Editor will supply a "Status of this Memo" section that
      contains two elements: (1) a paragraph describing the category of
      the RFC, and (2) the distribution statement.  The contents of this
      section will be found in Appendix A.




RFC Editor                   Informational                     [Page 23]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      An RFC that is (re-)publishing a specification produced by another
      (non-IETF) standards organization or is publishing a proprietary
      protocol may include the following paragraph in the Status of the
      Memo section [IPC04]:


           "This document may not be modified, and derivative works of
           it may not be created, except to publish it as an RFC and to
           translate it into languages other than English [other than to
           extract section XX as-is for separate use]."


      Here the optional clause delimited by [ ] is for programmatic
      material that is mean to be be extracted, e.g., MIB or PIB
      modules.  The IETF does not have change control over such
      documents, which are published as Informational RFCs.


   4.3  Copyright Notice


      The Copyright Notice section is required.  It contains the
      statement, "Copyright (C) The Internet Society (date)." The full
      copyright statement described in Section 4.9 must also appear at
      the end of the document.


   4.4  IESG Note


      This optional section will appear when the IESG requires a warning
      or clarifying message on an RFC.


   4.5  Abstract


      Every RFC must have an Abstract section following the Copyright
      notice.  An Abstract will typically be 5-10 lines.  An Abstract of
      more than 20 lines is generally not acceptable.


      The Abstract section should provide a concise and comprehensive
      overview of the purpose and contents of the entire document, to
      give a technically knowledgeable reader a general overview of the
      function of the document.  In addition to its function in the RFC
      itself, the Abstract section text will appear in publication
      announcements and in the online index of RFCs.


      Composing a useful Abstract generally requires thought and care.
      Usually an Abstract should begin with a phrase like "This memo
      ..." or "This document ...".  A satisfactory abstract can often be
      constructed in part from material within the Introduction section,
      but a good abstract will be shorter, less detailed, and perhaps
      broader in scope than the Introduction.  Simply copying and
      pasting the first few paragraphs of the Introduction is tempting,
      but it may result in an Abstract that is both incomplete and




RFC Editor                   Informational                     [Page 24]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      redundant.  Note also that an Abstract is not a substitute for an
      Introduction; the RFC should be self-contained as if there were no
      Abstract section.


      An Abstract should be complete in itself; it should not contain
      citations unless they are completely defined within the Abstract.
      Abbreviations appearing in the Abstract should generally be
      expanded in parentheses.  There is a small set of reasonable
      exceptions to this rule; see the discussion under Titles, Section
      2.9.


   4.6  Table of Contents


      A Table of Contents (TOC) section is required in RFCs longer than
      30 pages and recommended for an RFC longer than 15 pages.


      A TOC must be positioned after the Abstract and before the
      Introduction section (i.e., after the "boilerplate" and before the
      body of the RFC.)


      The TOC itself should not be too long or detailed, or it loses
      value.  For example, if many successive TOC entries point to the
      same pages of the memo, the TOC probably needs to be coarser.


      No specific format is required, but the following example
      illustrates a useful format:


   1.  INTRODUCTION ...............................................    5
      1.1  The Internet Architecture ..............................    6
         1.1.1  Internet Hosts ....................................    6
         1.1.2  Architectural Assumptions .........................    7
         1.1.3  Internet Protocol Suite ...........................    8
         1.1.4  Embedded Gateway Code .............................   10
      1.2  General Considerations .................................   12
         1.2.1  Continuing Internet Evolution .....................   12
         1.2.2  Robustness Principle ..............................   12
         1.2.3  Error Logging .....................................   13


   4.7  Body of the Memo


      Following the Table of Contents, if any, comes the body of the
      memo.  Depending upon the length of the TOC, a judicious page
      break can improve readability.


      Each RFC should have an Introduction section that (among other
      things) explains the motivation for the RFC and (if appropriate)
      describes the applicability of the document, e.g., whether it
      specifies a protocol, provides a discussion of some problem, is




RFC Editor                   Informational                     [Page 25]


Internet-Draft        Instructions to RFC Authors          1 August 2004



      simply of interest to the Internet community, or provides a status
      report on some activity.


      All abbreviations that are used in the body must be expanded the
      first time they occur.  A few exceptions will be made for very
      well-known abbreviations; see the discussion under Titles in
      Section 2.9.


      Abbreviation overload is an increasingly common problem in RFCs.
      We recommend that complex RFCs include a brief glossary at the
      end.  On the other hand, a glossary is never a substitute for an
      explanation.


      Cross references within the body of the text should use section
      numbers rather than page numbers, as the RFC Editor generally
      adjusts pagination during final editing.  The only exception is
      the Table of Contents, which necessarily shows page numbers.


      4.7a  Contributors Section


         This optional section lists those contributors who deserve
         significant credit for the document.  When a long author list
         is replaced by a single Editor in the front page header, the
         displaced authors can be properly and fully acknowledged in the
         Contributors section.


         The Contributors section may include brief statements about the
         nature of particular contributions ("Sam contributed section
         3") and it may also include affiliations of listed
         contributors.  At the discretion of the author(s), contact
         addresses (see Author's Address section below) may also be
         included in the Contributors section, for those contributors
         whose knowledge makes them useful future contacts for
         information about the RFC.


      4.7b  Acknowledgment Section


         This optional section may be used instead of, or in addition
         to, a Contributors section, when appropriate.


      4.7c  Security Considerations Section


         All RFCs must contain a section that discusses the security
         considerations relevant to the specification in the RFC; see
         [Secur03] for more information.


      4.7d  IANA Considerations Section





RFC Editor                   Informational                     [Page 26]


Internet-Draft        Instructions to RFC Authors          1 August 2004



         See Section 2.10 above and [IANA98].


      4.7e Appendixes


         Many RFC documents have appendices, some of which may be very
         extensive.  Common practice is to position Appendixes at the
         very end of a document, after the references.  However, a
         significant set of RFCs have large and dense Appendix sections
         for technical details, which are actually an integral part of
         the document.  In this case, it can be difficult to locate the
         references.  We therefore recommend that, in general,
         references follow the Appendixes in an RFC.


      4.7f  References Section


         There are many styles for references, and the RFCs have one of
         their own.  Please follow the reference style used in recent
         RFCs; in particular, see the Reference section of this RFC for
         an example.  (Note:  the ordering of multiple authors is
         intended to be as shown.)  On the other hand, there is no
         required format for a citation; see the discussion in Section
         2.7.


         A reference to an RFC that has been assigned an STD, BCP, or
         FYI subseries number must include the subseries number of the
         document.


         Reference lists must indicate whether each reference is
         normative or informative.  For example, the reference section
         might be split into two sections, e.g.:


                 s. Normative References


                      xxx
                      ...
                      xxx


                s+1. Informative References


                      xxx
                      ...
                      xxx


         Non-normative references to Internet-Drafts are allowed, but
         they must take the following restricted form: the author(s),
         the title, the phrase "Work in Progress", and the date; for
         example:





RFC Editor                   Informational                     [Page 27]


Internet-Draft        Instructions to RFC Authors          1 August 2004



                  [doe13] Doe, J., "The Deployment of IPv6",
                          Work in Progress, May 2013.


         Normative references to Internet Drafts will cause publication
         of the RFC to be suspended until the referenced draft is also
         ready for publication; the RFC Editor will then replace the
         reference by an RFC reference and publish both simultaneously.


         The use of URLs in references in RFCs is discouraged, because
         URLs are often not stable references.  Exceptions will be made
         in certain cases where the World Wide Web is demonstrably the
         most stable reference available.


   4.8 Author's Address Section


      This required section gives the name(s) and contact information
      for the author(s) listed in the first-page header.  Contact
      information must include at least one, and ideally would include
      all, of a postal address, a telephone number and/or FAX number,
      and a long-lived email address.  The purpose of this section is to
      (1) unambiguously define author/contributor identity (e.g., the
      John Smith who works for FooBar Systems) and to (2) provide
      contact information for future readers who have questions or
      comments.  Note that some professional societies offer long-lived
      email addresses for their members.


   4.9  IPR Boilerplate


      The IPR boilerplate is dictated by BCP 78 (RFC 3667) [IPC04] and
      BCP 79 (RFC 3668) [IPT04].  It includes a full notice of copyright
      by the Internet Society, and an IETF disclaimer on intellectual
      property rights over the contents.  The actual text is reproduced
      in Appendix A.


      A specific request from the IAB is required before the RFC Editor
      can include a dual copyright, or for any other variation of the
      standard ISOC copyright notice.


      An RFC should not contain a notice of the existence of relevant
      intellectual property (patents, etc.).  That is, the Intellectual
      Property notice at the end of the document should be *all* that is
      said about IPR in the document.


5. Intellectual Property


   RFC publication is intertwined with issues of intellectual property
   (IP).  The following two distinct kinds of IP issues for RFCs are
   sometimes confused.




RFC Editor                   Informational                     [Page 28]


Internet-Draft        Instructions to RFC Authors          1 August 2004



   o    Rights in Contributions.


        This set of issues concerns copyright protection on the RFC text
        as a document.  The present rules for rights in contributions
        are contained in BCP 78 (RFC 3667) [IPC04].  These rules call
        for a Copyright Statement in every RFC (see Section 4.9 and
        Appendix A).


        BCP 78 specifies the copyright rules applicable to RFCs,
        aligning these rules with modern copyright law.  The resulting
        rules are generally intended to continue the historical RFC
        Editor policy of maximal freedom for distribution of RFCs.  It
        adds safeguards for the integrity, future availability, and
        usefulness of published RFCs but otherwise preserves author
        rights.  For example, a published RFC must be open to reading by
        anybody, and it must be protected against alteration after it is
        published.


   o    Rights to Technology


        An RFC may describe technology -- e.g., a protocol or other
        technical specification -- that is subject to intellectual
        property right (IPR) claims (e.g., through patents).  The
        present rules for this case are contained in BCP 79 (RFC 3668)
        [IPT04].


        The RFC Editor's responsibility is limited to including a
        "Disclaimer of validity" (Section 5 of BCP 79, Appendix A of
        this document) in all IETF submissions and in most independent
        submissions. The RFC Editor may omit this Disclaimer statement
        from independent submissions when it is clear that there are no
        claimed intellectual property rights on the RFC contents, and
        when including the Disclaimer would make little sense.


        Note also that an RFC should *not* contain a notice of the
        existence of specific relevant intellectual property. For
        example, an RFC may not contain a patent number.


   The IETF rules for intellectual property [IPC04, IPT04] have the
   following specific implications for RFC republication.


   5.1 Copying and distributing an entire RFC (including all IPR-related
      boilerplate) without changes:


           1a.  Copying for free redistribution is allowed and
                encouraged.  This validates the widespread mirroring of
                RFCs on many web sites.





RFC Editor                   Informational                     [Page 29]


Internet-Draft        Instructions to RFC Authors          1 August 2004



           1b.  Inclusion of RFC copies within other documents or
                collections that are distributed for a fee is allowed.
                Anyone can take some RFCs, put them in a book, copyright
                the book, and sell it.  This in no way inhibits anyone
                else from doing the same thing, or inhibits any other
                distribution of the RFCs.


                In this case, it is a courtesy to ask the RFC author(s)
                and to provide a copy of the final document or
                collection.


   5.2 Translating RFCs into other languages


           Translation and publication of an entire RFC into another
           language is allowed.  However, it is courtesy to inform the
           RFC author(s) of such translation.


   5.3 Copying and distributing an entire RFC with changes in format,
      font, etc.:


           Changing format, font, etc. is allowed only with permission
           of the author(s).  With this permission, (1) applies.


   5.4 Copying and distributing portions of an RFC:


           This is what the lawyers call "preparation of derivative
           works".  It is allowed under conditions that differ depending
           upon the source of the RFC (see BCP 78 for details and
           definitions.)


           4a.  Preparation of derivative works from an RFC that was an
                IETF or IAB submission is permited, but only for use
                within the IETF standards process.  Proper credit and
                citations must be provided (BCP 78 Section 3.3(a)).


           4b.  Preparation of derivative works from an RFC that was an
                independent submission is permitted.  Proper credit and
                citations must be provided (BCP 78 Section 4.2(a)).














RFC Editor                   Informational                     [Page 30]


Internet-Draft        Instructions to RFC Authors          1 August 2004



6.  RFC Information and Contacts


       ************************************************************
       *                                                          *
       *    RFC Editor Email:  rfc-editor@rfc-editor.org          *
       *                                                          *
       *                                                          *
       *    RFC Editor URL:  http://www.rfc-editor.org            *
       *                                                          *
       *                                                          *
       ************************************************************


   In particular, authors should look for the latest version of this
   document at the URL listed above.


   RFC publication announcements are distributed via two mailing lists:
   the "IETF-Announce" list and the "RFC-DIST" list.  The IETF-Announce
   list announces publication of both Internet Drafts and RFCs;
   instructions for subscription and unsubscription to this list are
   available on the IETF web site www.ietf.org.  The RFC-DIST list
   announces only RFC publication; subscription information is available
   at the RFC Editor URL listed above.


   RFC readers should be aware that the many mirrors of RFCs and RFC
   indexes that appear on other sites vary a great deal in reliability.
   Consulting the official RFC-Editor site listed above is recommended.


7.  Security Considerations


   This RFC describes the Security Considerations sections of an RFC.
   It raises no new security issues itself.


8.  Acknowledgments


   This memo includes wording taken from a draft written by Robert W.
   Shirey of GTE/BBN Technologies, 29 December 1999, with permission.
   Shirey's deconstruction of the formatting rules was very helpful in
   writing Sections 3 and 4 of the present memo.


   We are grateful for the many thoughtful and helpful suggestions made
   by IETF participants during the Last Call on a previous version of
   this document.  We especially acknowledge the thorough analysis by
   John Klensin.









RFC Editor                   Informational                     [Page 31]


Internet-Draft        Instructions to RFC Authors          1 August 2004



APPENDIX A: RFC Boilerplate


   A.1 Status of Memo


      The RFC Editor supplies the appropriate one of the following
      boilerplate paragraphs in the Status of the Memo section (see
      Section 4.2).


      Standards Track


         "This document specifies an Internet standards track protocol
         for the Internet community, and requests discussion and
         suggestions for improvements.  Please refer to the current
         edition of the "Internet Official Protocol Standards" (STD 1)
         for the standardization state and status of this protocol.
         Distribution of this memo is unlimited."


      Best Current Practice


         "This document specifies an Internet Best Current Practices for
         the Internet Community, and requests discussion and suggestions
         for improvements.  Distribution of this memo is unlimited."


      Experimental


         "This memo defines an Experimental Protocol for the Internet
         community.  This memo does not specify an Internet standard of
         any kind.  Discussion and suggestions for improvement are
         requested.  Distribution of this memo is unlimited."


      Informational


         "This memo provides information for the Internet community.
         This memo does not specify an Internet standard of any kind.
         Distribution of this memo is unlimited."


   A.2 IPR Boilerplate


      At the end of each RFC there must be IPR boilerplate including a
      full copyright statement and an IETF disclaimer about rights over
      technology.  There are two forms, depending upon the source of the
      document.


      For a document originating in the IETF, these statements will read
      as follows [IPC04, IPT04]:


      Full Copyright Statement





RFC Editor                   Informational                     [Page 32]


Internet-Draft        Instructions to RFC Authors          1 August 2004



         Copyright (C) The Internet Society (2004).


         This document is subject to the rights, licenses and restrictions
         contained in BCP 78, and except as set forth therein, the authors
         retain all their rights.


         This document and the information contained herein are provided on an
         "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
         REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
         INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


      Intellectual Property


         The IETF takes no position regarding the validity or scope of any
         Intellectual Property Rights or other rights that might be claimed
         to pertain to the implementation or use of the technology
         described in this document or the extent to which any license
         under such rights might or might not be available; nor does it
         represent that it has made any independent effort to identify any
         such rights.  Information on the IETF's procedures with respect to
         rights in IETF Documents can be found in BCP 78 and BCP 79.


         Copies of IPR disclosures made to the IETF Secretariat and any
         assurances of licenses to be made available, or the result of an
         attempt made to obtain a general license or permission for the use
         of such proprietary rights by implementers or users of this
         specification can be obtained from the IETF on-line IPR repository
         at http://www.ietf.org/ipr.


         The IETF invites any interested party to bring to its attention
         any copyrights, patents or patent applications, or other
         proprietary rights that may cover technology that may be required
         to implement this standard.  Please address the information to the
         IETF at ietf-ipr@ietf.org.


      For an independent submission to the RFC Editor, these statements
      take the following form:


      Full Copyright Statement


         Copyright (C) The Internet Society (2004).


         This document is subject to the rights, licenses and restrictions
         contained in BCP 78 and at www.rfc-editor.org, and except as set
         forth therein, the authors retain all their rights.




RFC Editor                   Informational                     [Page 33]


Internet-Draft        Instructions to RFC Authors          1 August 2004



         This document and the information contained herein are provided on an
         "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
         REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
         INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


      Intellectual Property


         The IETF takes no position regarding the validity or scope of any
         Intellectual Property Rights or other rights that might be claimed
         to pertain to the implementation or use of the technology
         described in this document or the extent to which any license
         under such rights might or might not be available; nor does it
         represent that it has made any independent effort to identify any
         such rights.  Information on the ISOC's procedures with respect to
         rights in ISOC Documents can be found in BCP 78 and BCP 79.


         Copies of IPR disclosures made to the IETF Secretariat and any
         assurances of licenses to be made available, or the result of an
         attempt made to obtain a general license or permission for the use
         of such proprietary rights by implementers or users of this
         specification can be obtained from the IETF on-line IPR repository
         at http://www.ietf.org/ipr.


         The IETF invites any interested party to bring to its attention
         any copyrights, patents or patent applications, or other
         proprietary rights that may cover technology that may be required
         to implement this standard.  Please address the information to the
         IETF at ietf-ipr@ietf.org.



APPENDIX B: RFC Preparation Tools


      As indicated earlier, the primary submission format for RFCs is
      ASCII text.  Authors have found various tools to be useful for
      preparing this text in the format required by RFCs and Internet-
      Drafts.  For more complete and uptodate information, see the RFC
      Editor Web page.


      This Appendix surveys some of the possibilities.


      nroff, groff
           The nroff program is widely available for Unix systems, while
           its freeware equivalent groff is available for an even wider
           range of platforms, including Windows.  These programs use
           directives in the text to control the formatting.  The RFC




RFC Editor                   Informational                     [Page 34]


Internet-Draft        Instructions to RFC Authors          1 August 2004



           Editor, in particular, uses nroff for final RFC formatting.
           A template is available as 2-nroff.template.


      XML
           An XML DTD for RFCs has been developed [XMLrf99] and a tool
           to format RFCs from XML source.  There is also an XML-to-
           nroff translator suitable for creating RFC text.  Authors
           have had a generally good experience with these tools.


      Microsoft Word
           Microsoft Word is an important example of a WYSIWYG editor.
           RFC 3285 [14] describes in detail how to configure Word to
           produce an ASCII text file in RFC format.  A version of this
           document as a Word file (2-Word.template.rtf) can be used as
           a template file to initialize this configuration for entering
           and displaying RFCs.  There is also a DOS executable
           (crlf.exe) for a post-processor to establish RFC end-of-line
           conventions in the Word output file.


           Note that these template files are suitable only for fairly
           simple text formatting; they may be incompatible with the
           more advanced features of Word.


      LaTeX
           LaTeX is widely used for text preparation in many academic
           environments.  A convenient LaTeX template is available as
           2-latex.template.  Latex in general does not produce plain
           ASCII text in the RFC format, but there are tools that
           translate LaTeX to nroff; see the RFC Editor web page.























RFC Editor                   Informational                     [Page 35]


Internet-Draft        Instructions to RFC Authors          1 August 2004



APPENDIX C: Checklist


Topic                                                      | Section of
                                                           | this doc.
___________________________________________________________|___________
A. Editorial/Content Issues                                |
                                                           |
    o  Reasonably clear and correct English                |  2.3
            > Also, run spell checker                      |
                                                           |
    o  All abbreviations (with a few exceptions) are       |  4.7
        expanded when they first appear.                   |
                                                           |
    o  References:                                         |  2.7, 4.7f
            > Complete and current                         |
            > Normative and Informative listed separately  |  2.7
            > Internet Drafts correctly referenced         |  4.8
                                                           |
    o  All URLs are suspect: they must be stable.          |  2.8
                                                           |
    o  Title:                                              |  2.9
            > Descriptive and not misleading.              |
            > No suspect words, e.g., Proposed, Standard,  |
                                Requirements, Policy.      |
            > Abbreviations expanded                       |
                                                           |
    o  Author list not too long                            |  2.12
                                                           |
    o   Category field correct                             |  4.1
                                                           |
B. Basic Formatting                                        |  3.1
                                                           |
    o   Only printable ASCII characters                    |  3.1(1),
                                                           |    3.1(4)
    o   No lines exceeding 72 characters                   |  3.1(2)
        [This is especially important for "as is" tables   |
         and figures, which cannot be easily reformatted by|
         the RFC Editor.]                                  |
                                                           |
    o  Maximum page size is 58 lines.  [RFC Editor may     |  3.1(3)
         re-paginate, but this limit may be an issue for   |
         large "as is" tables and figures.                 |
                                                           |
    o   Must be ragged-right                               |  3.1(5)
                                                           |
    o   No word-breaking hyphenation at end of line        |  3.1(6)
                                                           |
    o   Two blanks after periods ending sentences          |  3.1(7)




RFC Editor                   Informational                     [Page 36]


Internet-Draft        Instructions to RFC Authors          1 August 2004



                                                           |
    o   No footnotes (end notes OK)                        |  3.1(8)
                                                           |
    o   Line spacing OK                                    |  3.1(9)
                                                           |
    o   Pages numbered                                     |  3.1(10)
                                                           |
    o   Running headers and footers OK                     |  3.3
                                                           |
    o   Formatted for easy reading; consistent spacing and |
        indentation                                        |  3.1(12)
                                                           |
    o   "Big-Endian" data definitions                      |  3.4
                                                           |
C. Required Sections supplied by author                    |  4
                                                           |
    o   Abstract                                           |  4.5
            > Clarity and content OK                       |
            > Reasonable length                            |
            > All abbreviations expanded                   |
            > No references                                |
            > Unnumbered section                           |
                                                           |
    o   Body of the Memo                                   |  4.7
            > Security Considerations                      |  4.7c
                                                           |
    o   Author's Address                                   |  4.8
                                                           |
D. Other Sections                                          |
                                                           |
    o   Table of Contents                                  |  4.6
            > Must be present in large document            |
                                                           |
    o   Body of the Memo                                   |  4.7
            > Contributors and/or Acknowledgments          | 4.7a, b
            > IANA Considerations, if needed               |  4.7d
            > Appendixes                                   |  4.7e
            > References                                   |  4.7f
                                                           |













RFC Editor                   Informational                     [Page 37]


Internet-Draft        Instructions to RFC Authors          1 August 2004



APPENDIX D: Changes from RFC 2223


      In general, this document contains the following major changes
      from RFC 2223.


   o  Section 1: Introduction


      The Introduction section was completely rewritten, using material
      from several sections of RFC 2223, bringing the discussion into
      conformance with RFC 2026 and adding additional clarification.


   o  Section 2: General RFC Editorial Policies


      This section combines material from several sections of RFC 2223.
      New material is included about the RFC Editor errata page,
      normative references, URLs, titles, RFC number pre-assignment,
      author lists, and IANA Considerations.


      Major procedural changes include: (1) publication of an RFC in
      both ASCII and PostScript versions now requires that both be
      published simultaneously, (2) all listed authors must give
      approval during the "Authors' 48 Hour" process, (3) long author
      lists are generally prohibited, and (4) a Contributors section is
      defined as an alternative to long author lists.


   o  Section 3: General Format Rules


      This section is expanded with much additional explanatory
      material.  For example:


           (1)  The requirement for printable ASCII characters is
                stated, and the use of CR, LF, and FF is clarified.


           (2)  The requirement for page numbers in specified.


           (3)  The requirement for running headers and footers is
                specified.


   o  Section 4: Required Sections in an RFC


      This section is reorganized to cover all the required sections of
      an RFC in order.  It adds the current conventions for formatting
      multiple author names and organizations, and it defines section
      ordering more precisely.


      This section describes five major changes in RFC formatting.


           (1)  The style and contents of the Abstract section are more




RFC Editor                   Informational                     [Page 38]


Internet-Draft        Instructions to RFC Authors          1 August 2004



                completely specified, in order to make RFC abstracts
                useful for searching and indexing.


           (2)  A Table of Contents section is required or recommended
                in all but very short RFCs.


           (3)  Separate lists are now required for normative references
                and informative references.


           (4)  A new optional section, Contributors, is defined.


           (5)  The intellectual property boilerplate was updated.



   o  Appendixes


      Former Appendix A, which contained the source for the fix.pl
      post-processor Perl script and an nroff RFC template, has been
      removed.  These files are available at the RFC Editor web site.


      Appendix B, RFC Preparation Tools, and Appendix C, Checklist, are
      new.


Normative References


   [BCP14]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.


   [IPC04]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
             3667, February 2004.


   [IPT04]   Bradner, S., "Intellectual Property Rights in IETF
             Technology", BCP 79, RFC 3668, February 2004.


   [RFCed]   RFC Editor web page, "http://www.rfc-editor.org".


   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.


Informative References


   [ASCII69] Cerf, V., "ASCII Format for Network Interchange", RFC 20,
             October 1969.


   [BCP95]   Postel, J., Li, T. and Y. Rekhter, "Best Current
             Practices", BCP 1, RFC 1818, August 1995.


   [FYI90]   Malkin, G. and J. Reynolds, "F.Y.I. on F.Y.I. --




RFC Editor                   Informational                     [Page 39]


Internet-Draft        Instructions to RFC Authors          1 August 2004



             Introduction to the F.Y.I. Notes", FYI 1, RFC 1150, March
             1990.


   [Hist99]  RFC Editor et al., "30 Years of RFCs", RFC 2555, April
             1999.


   [IANA98]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.


   [IDguide] IETF, "Guidelines to Authors of Internet Drafts".
             Available as 1id-guidelines.txt at http://www.ietf.org.


   [IEN137]  Cohen, D., "On Holy Wars and a Plea for Peace", Internet
             Experimental Note (IEN) 137, 1 April 1980.  A longer
             version is published in IEEE Computer Magazine, pp 48-54,
             October 1981.


   [Lang01]  IESG, "Guidance for the use of formal languages in IETF
             specifications", http://www.ietf.org/IESG/STATEMENTS,
             October 2001.


   [Secur03] Rescorla, E., Korver, B., and Internet Architecture Board,
             "Guidelines for Writing RFC Text on Security
             Considerations", Work in Progress, January 2003.


   [STD1]    Internet Engineering Task Force, Reynolds, J., Braden, R.,
             Ginoza, S., and A. De La Cruz, Ed., "Official Internet
             Protocol Standards", STD 1.  Latest version RFC 3300,
             November 2002.


   [STD92]   Postel, J., Editor, "Introduction to the STD Notes", RFC
             1311, March 1992.


   [TLD99]   Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names",
             RFC 2606, June 1999.


   [Word02]  Gahrns, M. and T. Hain, "Using Microsoft Word to create
             Internet Drafts and RFCs", RFC 3285, May 2002.


   [XMLrf99] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
             1999.










RFC Editor                   Informational                     [Page 40]


Internet-Draft        Instructions to RFC Authors          1 August 2004



CHANGES (To be removed by RFC Editor before publication)


Changes from -07 version


   1.   The intellectual property discussion and boilerplate was updated
        to incorporate the current rules in BCP 78, BCP 79.


   2    The term "individual submission" was changed to "independent
        submission", to avoid confusion with documents that are
        submitted to the IESG by individuals (rather than working
        groups) and are then published by the RFC Editor as official
        IETF documents.


Changes from -06 version


   1.   Changed document status from BCP to Informational.  All RFC
        Editor policy documents have been Informational RFCs.


   2.   Eliminated duplicate wording (numbers numbers) [1.1].


Changes from -05 version


   1.   Add Section 2.16 on Intellectual Property [2.16].


   2.   Note that all major contributors must be acknowledged [2.12].


   3.   Note that the RFC Editor fills in the sub-series number and the
        Categories field of the header, as well as the Status of this
        Memo field [4.1, 4.2].


   4.   Specify that internal cross references within the body of the
        memo should use section numbers, not page numbers [4.7].


   5.   Separate the list of changes that have been made in successive
        Internet Draft versions of this document from Appendix D, which
        summarizes changes from RFC 2223.  The former material is to be
        removed before publication.


   6.   Reduce the set of normative references.


   7.   Correct several minor nits.



Changes from -04 version


   1.   Replace overloaded "Status" attribute name with "Category"
        [1.1].





RFC Editor                   Informational                     [Page 41]


Internet-Draft        Instructions to RFC Authors          1 August 2004



   2.   Clarify the relation of this document to RFC 2026 [1.2].


   3.   Clarify the submission rules, including rules for IAB and IRTF
        documents and for BCPs [1.2]


   4.   Specify that RFC Editor reviews independent submissions for
        content as well as format [1.2.1].


   5.   Document "Do Not Publish Now" recommendation from the IESG
        [1.2.1].


   6.   Distinguish between the plain text format and the US-ASCII
        character set [2.4, 3.1].


   7.   Clarify the distinction between citation format and reference
        format, and use a more appropriate format for citations in this
        document [2.7].


   8.   State that RFC 2119 is not required, but some meaning must be
        defined for capitalized applicability words [2.14].


   9.   Checking of MIBs and other formal languages [2.15]


   10.  Clarify that Section 3 defines published format, not submission
        format [3.].


   11.  Reorganize the sections in section 4 to clarify and simplify the
        section ordering rules, and move appendixes to match our
        recommendation [4].


   12.  Suggest Glossary [4.7].


   13.  Fix many typos reported by ever-vigilant IETF members.




Changes from -03 version



   1.   Combine sections 1.3.1 and 1.3.2 into one section 1.3.1.


   2    Clarify the section ordering rules in section 4.



Changes from -02 version



   1.   Removed old Appendix C (definition of ASCII) and replace it with




RFC Editor                   Informational                     [Page 42]


Internet-Draft        Instructions to RFC Authors          1 August 2004



        a reference to RFC 20.


   2    Added new Appendix C, a Checklist.


   3    Made a few editorial changes and typo fixes.


   4    Clarified that .txt.pdf versions are equally authoritative with
        .txt versions of RFCs.


   5    Stated policy that (nearly) all abbreviations in body of the
        document must be expanded when first encountered.



Changes from -01 version



   1.   Incorporated new author list guidelines.


   2.   Clarified rules for hyphenation (Section 3.1 (6)).


   3.   Added guideline on example URLs (Section 2.8).


   4.   Clarified that dangling normative references are strictly
        prohibited only for standards-track documents (Section 2.7).



Authors' Addresses


   Joyce K. Reynolds
   RFC Editor
   4676 Admiralty Way
   Marina del Rey, CA  90292


   EMail: rfc-editor@rfc-editor.org



   Robert Braden
   RFC Editor
   4676 Admiralty Way
   Marina del Rey, CA  90292


   EMail: rfc-editor@rfc-editor.org










RFC Editor                   Informational                     [Page 43]


Internet-Draft        Instructions to RFC Authors          1 August 2004



Full Copyright Statement


   Copyright (C) The Internet Society (year).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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


Intellectual Property


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.














RFC Editor                   Informational                     [Page 44]