Independent Submissions to the RFC Editor
draft-iab-rfc-independent-00

Versions: 00 rfc4846                                       Informational
Network Working Group                                    J. Klensin, Ed.
Internet-Draft                                            D. Thaler, Ed.
Expires: September 4, 2007                                 March 3, 2007


               Independent Submissions to the RFC Editor
                    draft-iab-rfc-independent-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on September 4, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   There is a long-term tradition in the Internet community, predating
   the IETF by many years, of use of the RFC series to publish materials
   that are not rooted in the IETF standards process and its review and
   approval mechanisms.  These documents, known as "independent
   submissions", serve a number of important functions for the Internet
   community, both inside and outside of the community of active IETF
   participants.  This document discusses the independent submission
   model and some reasons why it is important.  It then describes
   editorial and processing norms that can be used for independent



Klensin & Thaler        Expires September 4, 2007               [Page 1]


Internet-Draft           Independent Submissions              March 2007


   submissions as the community goes forward into new relationships
   between the IETF community and its primary technical publisher.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology Note . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Context and Philosophical Assumptions  . . . . . . . . . .  4
   2.  The Role of Independent Submissions  . . . . . . . . . . . . .  4
   3.  Document Submission  . . . . . . . . . . . . . . . . . . . . .  5
   4.  The Review Process . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Posting of Draft . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Request for Publication  . . . . . . . . . . . . . . . . .  6
     4.3.  Initial RFC Editor Review  . . . . . . . . . . . . . . . .  6
     4.4.  Review and Evaluation  . . . . . . . . . . . . . . . . . .  6
     4.5.  Additional Reviews . . . . . . . . . . . . . . . . . . . .  7
     4.6.  Document Rejection . . . . . . . . . . . . . . . . . . . .  7
     4.7.  Final Decision and Notification  . . . . . . . . . . . . .  7
     4.8.  Final Editing and Publication  . . . . . . . . . . . . . .  8
   5.  Formal IESG Review . . . . . . . . . . . . . . . . . . . . . .  8
   6.  The Editorial Review Board . . . . . . . . . . . . . . . . . .  9
   7.  Status and Availability of Reviews . . . . . . . . . . . . . .  9
     7.1.  Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
     7.2.  Rejected Documents . . . . . . . . . . . . . . . . . . . . 10
     7.3.  Documents Approved for Publication . . . . . . . . . . . . 11
   8.  Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   12. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1. Changes between version -02 and version -03  . . . . . . . 13
     12.2. Changes for -04  . . . . . . . . . . . . . . . . . . . . . 13
     12.3. Changes for -05  . . . . . . . . . . . . . . . . . . . . . 14
     12.4. Changes for -06  . . . . . . . . . . . . . . . . . . . . . 14
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     13.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  IAB Members at the time of this writing . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17










Klensin & Thaler        Expires September 4, 2007               [Page 2]


Internet-Draft           Independent Submissions              March 2007


1.  Introduction

   There is a long-term tradition in the Internet community, predating
   the IETF by many years, of use of the RFC series to publish materials
   that are not rooted in the IETF standards process and its review and
   approval mechanisms.  These documents, known as "independent
   submissions", serve a number of important functions for the Internet
   community, both inside and outside of the community of active IETF
   participants.  This document discusses the independent submission
   model and some reasons why it is important.  It then describes
   editorial and processing norms that can be used for independent
   submissions as the community goes forward into new relationships
   between the IETF community and its primary technical publisher.

   To understand the perspective of this document, it is important to
   remember that the RFC-Editor function predates the creation of the
   IETF.  As of the time of this writing, the RFC series goes back 38
   years [RFC2555] while the IETF is celebrating its 21st anniversary.
   All of the documents that were published before the IETF was created,
   and for some years thereafter, would be considered independent
   submissions today.  As the IETF evolved, the IAB and then the IETF
   itself chose to publish IETF documents as RFCs while fully
   understanding that the RFC-Editor function was an independent
   publication mechanism.  Other decisions were possible: e.g., the IETF
   could have decided to create it own publication series.  It was felt
   that there was considerable value in continuing to publish the IETF
   work in the same series as the one used to publish the basic
   protocols for the Internet.

1.1.  Terminology Note

   This document describes what have historically been referred to as
   "independent submissions".  That term is distinguished from those
   IETF and IAB community documents that originate from formal groups --
   IAB, IRTF, IETF WGs -- and from submissions submitted to the IESG for
   standards-track, informational, or experimental processing.
   Documents produced by individuals, rather than IETF WGs or others
   IETF-affiliated groups, but submitted for publication under Area
   Director sponsorship, are known as "individual submissions".

   For convenience and obvious historical reasons, the editor and
   publisher of documents that are not processed through the IETF is
   known below as the "RFC Editor".  The RFC Editor will typically be an
   organization or one or more senior people and associated editorial
   staff, and the term is used collectively below.  That term is not
   intended to predict the future, either in terms of who does the job
   or what they, or the document series, are called.




Klensin & Thaler        Expires September 4, 2007               [Page 3]


Internet-Draft           Independent Submissions              March 2007


1.2.  Context and Philosophical Assumptions

   This document complements the discussion and guidelines in [RFC4714],
   which focuses on standards track documents.  It takes a somewhat
   stronger view than the discussions that led to that document,
   starting from the belief that independent submissions are most
   valuable if they are, in fact, independent of the IETF process.  From
   the perspective of the IETF, independent submissions are especially
   important as checks on the IETF processes even though such checks are
   not the only, or even a common, reason for them.  That role is
   compromised if IETF-related entities are able to block or deprecate
   such documents to a degree beyond that needed to avoid difficulties
   with the standards process.


2.  The Role of Independent Submissions

   When the RFC series was fairly new, RFCs were used to publish general
   papers on networking as well as the types of documents we would
   describe as standards today.  Those roles also developed as part of
   the early design and development of the ARPANET, long before anyone
   dreamt of the IETF and when the distinction between, e.g., standards
   and informational documents was less precisely drawn.  In more recent
   years, independent submissions have become important for multiple
   reasons, some of them relatively new.  They include:

   o  Discussion of Internet-related technologies that are not part of
      the IETF agenda.
   o  Introduction of important new ideas as a bridge publication venue
      between academia and IETF engineering.
   o  Informational discussions of technologies, options, or experience
      with protocols.
   o  Informational publication of vendor-specific protocols.
   o  Critiques and discussions of alternatives to IETF standards-track
      protocols.  The potential for such critiques provides an important
      check on the IETF's standards processes and should be seen in that
      light.
   o  Documents considered by IETF Working Groups but not standardized.
      While many documents of this type are published via the IESG
      approval path (see RFC 3932, Section 1 [RFC3932]), the independent
      submission path has traditionally been open to them.  Because of
      their intimate connection to the IETF Standards Process and WG
      activities and the consequent sensitivity to exact statements of
      relationships and to timing, there is reason to believe that all
      such documents should be published only at IESG request.  In any
      event, these documents are published for the historical record.





Klensin & Thaler        Expires September 4, 2007               [Page 4]


Internet-Draft           Independent Submissions              March 2007


   o  Satirical materials.
   o  Meeting notes and reports (RFC 21 [RFC0021] is the earliest, RFC
      1109 [RFC1109] probably the most important).
   o  Editorials (the best example is IEN 137 [IEN137], not an RFC).
   o  Eulogies (RFC 2441 [RFC2441]).
   o  Technical contributions (e.g., RFC 1810 [RFC1810]).
   o  Historically, RFC Editor and, at least prior to the handoff
      between ISI and ICANN and the June 2000 MOU [RFC2860], IANA Policy
      Statements (e.g., [RFC2223] and RFC 1591 [RFC1591]).

   It should be clear from the list above that, to be effective, the
   review and approval process for independent submissions should be
   largely independent of the IETF.  As a important principle that has
   been applied historically, the RFC Editor seeks advice from the IESG
   about possible relationships and conflicts with IETF work.  Any
   submission that constitutes an alternative to, or is in conflict
   with, an IETF Standard or proposal for standards-track adoption must
   clearly indicate that relationship.  The IESG may identify such
   conflicts as part of its review.

   The specific procedures to be followed in review are described in
   Section 4 and Section 5.


3.  Document Submission

   Independent submissions are submitted directly to the RFC Editor.
   They must first be posted as Internet Drafts, so the submission is
   typically simply a note requesting that the RFC Editor consider a
   particular Internet Draft for publication.  The process is described
   in [RFC2223].  Further information can be found in the working draft
   of an update of that document [RFC2223bis].

   Any document that meets the requirements of this specification, of
   [RFC2223] and its successors, and of any intellectual property or
   other conditions that may be established from time to time, may be
   submitted to the RFC Editor for consideration as an Independent
   Submission.  However, the RFC Editor prefers that documents created
   through IETF processes (e.g., working group output) be considered by
   the IESG and submitted using this path only if a working group, or
   the IESG, decline to publish it.  In the latter cases, the review
   process will be more efficient if the authors provide a history of
   consideration and reviews of the document at the time of submission.


4.  The Review Process

   In general, the steps in the review process are identified in the



Klensin & Thaler        Expires September 4, 2007               [Page 5]


Internet-Draft           Independent Submissions              March 2007


   subsections below.  Any of them may be iterated and, at the
   discretion of the RFC Editor, steps after the first may be taken out
   of order.  In addition, the IESG review, as discussed in Section 5,
   must take place before a final decision is made on whether to publish
   the document.

4.1.  Posting of Draft

   The author(s) or editor(s) of a document post it as an Internet
   Draft.

4.2.  Request for Publication

   After the normal opportunity for community review and feedback
   provided by the submission of the I-D and the I-D repository
   announcement thereof, the author or editor sends a request for
   consideration for publication to the RFC Editor at
   rfc-editor@rfc-editor.org.  That request should note any community
   discussion or reviews of the document that have occurred before
   submission, as well as the desired document category (Informational
   or Experimental, as discussed in RFC 2026 [RFC2026] section 4.2).

   If the document requires any IANA allocations, authors should take
   care to check the assignment policy for the relevant name space,
   since some assignment policies (e.g., "IETF Consensus") cannot be
   used by Independent Submissions.  See RFC 2434 [RFC2434] for more
   information.

4.3.  Initial RFC Editor Review

   RFC Editor staff performs an initial check on the document to
   determine whether there are obvious issues or problems and to decide
   on the sequencing of other steps.

   At any time during the process, the RFC Editor may make general
   and/or specific suggestions to the author on how to improve the
   editorial quality of the document and note any specific violations of
   the rules.  The author will be expected to make the suggested
   updates, submit a new version, and inform the RFC Editor.  This may
   be repeated as often as necessary to obtain an acceptable editorial
   quality.

4.4.  Review and Evaluation

   The RFC Editor arranges for one or more reviews of the document.
   This may include Editorial Board (see Section 6) reviews or reviews
   by others.  Unsolicited reviews from parties independent of the
   author are welcome at any time.



Klensin & Thaler        Expires September 4, 2007               [Page 6]


Internet-Draft           Independent Submissions              March 2007


   At minimum, the author of every document shall receive a written
   summary of the review(s).  Reviewer anonymity is discussed in Section
   6.  The RFC Editor may also share reviews with the Editorial Board.

   An author rebuttal to some aspect of a review, followed by a healthy
   technical dialog among the author and the reviewer(s), is fully
   appropriate.  Consensus followed by document revision is the desired
   outcome.

   The RFC Editor is expected to consider all competent reviews
   carefully, and in the absence of some unusual circumstance, a
   preponderance of favorable reviews should lead to publication.

4.5.  Additional Reviews

   If the author is unsatisfied with one or more review(s), the author
   may request that the RFC Editor solicit additional reviews.  In
   exceptional circumstances, the author may request that the IAB review
   the document.  Such requests to the IAB, and any reviews the IAB
   chooses to perform, will occur according to procedures of the IAB's
   choosing.  The IAB is not required to initiate a review or comply
   with a request for one: a request to the IAB for a review is not an
   appeal process.

4.6.  Document Rejection

   If any stage of the review process just described leads to the
   conclusion that the document is not publishable, the RFC Editor may
   reject the document ("Do Not Publish" or "DNP").  Such rejection
   would normally be based on the conclusion that the submission does
   not meet the technical or editorial standards of the RFC Series or is
   not relevant to the areas that the series covers.

   If a document is rejected by the RFC Editor, the author may request
   an additional review from the IAB, as described below, but the IAB is
   not obligated to do that review, nor is the RFC Editor obligated to
   publish even with a favorable IAB review.

4.7.  Final Decision and Notification

   In all cases, the ultimate decision to publish or not publish, and
   with what language, rests with the RFC Editor.

   The RFC Editor will communicate the final decision to the author and
   the Editorial Board.  For a rejection, there will be a summary of the
   reason(s) for the action.

   Information about any IESG-requested publication delay or request to



Klensin & Thaler        Expires September 4, 2007               [Page 7]


Internet-Draft           Independent Submissions              March 2007


   not publish a document will be posted to the RFC Editor web site to
   supplement document status information.

4.8.  Final Editing and Publication

   Once a document is approved for publication, it is handled in a
   fashion similar to other RFCs, with principles about priorities
   worked out with the IAB as appropriate.


5.  Formal IESG Review

   At an appropriate time in the review process, normally after the RFC
   Editor has made a tentative decision to publish, the document is
   forwarded to the IESG for evaluation with a relatively short timeout.
   If the nature of the document persuades the RFC Editor or the IESG
   that the interests of the community or efficiency in the publication
   process would be better served by a different schedule, then that
   schedule should be followed.  For example, if it appears to the RFC
   Editor that it is likely that the IESG will wish to take the document
   over and assign it to a working group, it may be better to ask for
   the IESG review prior to incurring the delays associated with other
   reviews or significant editorial work.

   The IESG evaluation is not a technical one.  Instead, it covers the
   issues listed in RFC 3932 or its successors, presumably from the
   perspective outlined above in Section 1.2.  That is, the evaluation
   should focus exclusively on conflicts or confusion with IETF process
   and attempts to subvert ("end run") working group activities.

   At the time the document is forwarded to the IESG, the RFC Editor
   posts an indication on its web site that the document is under IESG
   review and that comments on conflicts can be sent to the IESG with
   copies to the RFC Editor.  Additional mechanisms may be developed
   from time to time to inform a community that a document is entering
   formal prepublication review.  Comments not directly related to IETF
   procedures or conflicts may be sent directly to the author(s) and RFC
   Editor.

   In addition to the IESG review for conflict with IETF work,
   individuals in the IESG, or in the broader IETF community, are free
   to review a draft and, if they have comments of any kind --including
   the extreme case of believing that the proposal is damaging to the
   Internet as a whole-- these comments should be directed to the
   author(s) and the RFC Editor.

   If the IESG, after completing its review, identifies issues, it may
   recommend explanatory or qualifying text for the RFC Editor to



Klensin & Thaler        Expires September 4, 2007               [Page 8]


Internet-Draft           Independent Submissions              March 2007


   include in the document if it is published.

   If the IESG concludes that publication of the document should be
   delayed for a reasonable period of time because their untimely
   publication could cause confusion or other harm with proposals under
   consideration for standardization, the RFC Editor will grant that
   request.  The current agreement between the RFC Editor and the IESG
   on requested delays is expected to continue.  That agreement permits
   the IESG to ask for a delay of up to six months and, if necessary, to
   renew that request twice, for a total possible delay of 18 months.

   If the IESG concludes that the document should not be published as an
   RFC, it will request that the RFC Editor not publish and provide
   appropriate justification for that request.  The RFC Editor will
   consider the request to not publish the document.

   The RFC Editor or the author may request that the IAB review the
   IESG's request to delay or not publish the document and request that
   the IAB provide an additional opinion.  Such a request will be made
   public via the RFC Editor web site.  As with the IESG review itself,
   the IAB's opinion, if any, will be advisory.  And, as with author
   requests for an IAB technical review (see Section 4.5), the IAB is
   not obligated to perform this type of review and may decline the
   request.


6.  The Editorial Review Board

   The RFC Editor appoints and maintains an Editorial Review Board
   which, much like the Editorial Boards of professional journals and
   publishers, provides the RFC Editor with both advice and reviews of
   particular proposed publications and general and strategic policy
   advice.  The membership list of the Editorial Review Board is public
   and can be found at http://www.rfc-editor.org/edboard.html.
   Editorial Board members serve at the pleasure of the RFC Editor.
   From time to time, the RFC Editor will solicit suggestions for new
   appointees from the IAB and other sources and will seek IAB comments
   on those to be appointed and on the effectiveness of the review
   process and the quality of documents being published and criteria
   applied.  However, to ensure the independence of the independent
   submission process, the final decision to appoint (or not appoint)
   Editorial Board members rests with the RFC Editor.


7.  Status and Availability of Reviews

   The RFC Editor will conduct the reviews discussed above with the
   intent of balancing fairness to authors, transparency of the review



Klensin & Thaler        Expires September 4, 2007               [Page 9]


Internet-Draft           Independent Submissions              March 2007


   process to the general community, protection of reviewers from
   possible retaliation or undue pressure, and the interest of the
   community in having any significant dissents from published documents
   available to the community with the same degree of scrutiny that the
   original documents received.  To this end, reviews and information
   about reviewers will be made public under the following
   circumstances.  In special cases in which other considerations apply,
   the RFC Editor may adopt special provisions after reviewing the
   circumstances and proposed action with the IAB.

   Any reviewer participating in the process outlined in this document
   does so on condition of giving consent to handling of the reviews as
   outlined in this section.  In special cases, individual arrangements
   may be worked out in advance with the RFC Editor.

   As described in Section 4.4, all reviews will be shared with the
   document authors (with possible editing to remove any extreme
   language).  The names of the reviewers will normally accompany these
   reviews, but reviewers will be granted anonymity upon request to the
   RFC Editor.  The RFC Editor will in any case forward any author
   rebuttal messages to the reviewer.

   Nothing in this section or the subsections below precludes private
   communications between reviewers, the Editorial Board, and the RFC
   Editor; such communications will remain confidential.

7.1.  Posted Reviews

   Once a final accept or reject decision has been made on a document,
   the RFC Editor may choose to post the full set of reviews (and author
   rebuttals, if any) associated with a document, if doing so would be
   in the best interest of the community.  The author may request
   earlier posting of reviews and rebuttals, to inspire additional
   unsolicited reviews, for example.  The names of the reviewers will
   accompany their reviews, except for a reviewer who requested
   anonymity.

   The author will be notified of the intent to post the final reviews
   in advance.  The author may then request that the document be
   withdrawn and the reviews kept private.  However, such author request
   must be timely, generally within 14 days of the notification of
   intent to post.

7.2.  Rejected Documents

   If the RFC Editor rejects a document, the author has the following
   recourses.




Klensin & Thaler        Expires September 4, 2007              [Page 10]


Internet-Draft           Independent Submissions              March 2007


   o  Request one or more additional reviews (Section 4.5) followed by a
      reconsideration.
   o  Request an IAB review (Section 4.5, Section 4.6) followed by a
      reconsideration.
   o  Request that the reviews be published on the RFC Editor web site.

7.3.  Documents Approved for Publication

   In considering whether to make review materials public for documents
   accepted for publication, the RFC Editor is expected to note that the
   best way to comment on, or dissent from, an RFC is generally another
   RFC; that reviews critical of a document are not themselves reviewed;
   that the review and refutation process is necessarily fragmentary;
   and that a reviewer who feels strongly about a subject about which a
   review has already been written often would not need to do
   significant additional work to produce an RFC-format document from
   that review.


8.  Intellectual Property Rights

   The following material was extracted from the relevant sections of
   BCP 78 [RFC3978] [RFC4748] in order to get all independent submission
   information for technical publications produced under the auspices of
   the IETF, IASA or the IETF Trust, or ISOC into a single place and to
   initialize the process of separating discussions of independent
   submissions from those about standards-track or other IETF documents.
   Note that the text that follows uses the term "RFC Editor
   Contribution" to describe the same type of document referred to as an
   "independent submission" elsewhere in this document.  The RFC Editor
   may change these provisions from time to time after obtaining the
   advice and consent of the IETF Trust in the RFC Editor's capacity as
   the formal publisher of RFCs.

   By submission of an RFC Editor Contribution, each person actually
   submitting the RFC Editor Contribution, and each named co-
   Contributor, is deemed to agree to the following terms and
   conditions, and to grant the following rights, on his or her own
   behalf and on behalf of the organization the Contributor represents
   or is sponsored by (if any) when submitting the RFC Editor
   Contribution.

   a.  For Internet Drafts that are to expected be submitted as RFC
       Editor Contributions: To the extent that an RFC Editor
       Contribution or any portion thereof is protected by copyright and
       other rights of authorship, the Contributor, and each named co-
       Contributor, and the organization he or she represents or is
       sponsored by (if any) grant an irrevocable, non-exclusive,



Klensin & Thaler        Expires September 4, 2007              [Page 11]


Internet-Draft           Independent Submissions              March 2007


       royalty-free, world-wide right and license to the IETF Trust and
       the IETF under all intellectual property rights in the RFC Editor
       Contribution for at least the life of the Internet-Draft, to
       copy, publish, display, and distribute the RFC Editor
       Contribution as an Internet-Draft.
   b.  For an RFC Editor Contribution submitted for publication as an
       RFC, and to the extent described above, the Contributor, each
       named co-Contributor, and the organizations represented above
       grant the same license to those organizations and to the
       community as a whole to copy, publish, display, and distribute
       the RFC Editor Contribution irrevocably and in perpetuity and,
       also irrevocably and in perpetuity, grant the rights listed below
       to those organizations and entities and to the community
       A.  to prepare or allow the preparation of translations of the
           RFC into languages other than English,
       B.  unless explicitly disallowed in the notices contained in an
           RFC Editor Contribution, to prepare derivative works (other
           than translations) that are based on or incorporate all or
           part of the RFC Editor Contribution, or comment upon it.  The
           license to such derivative works shall not grant the IETF
           Trust, the IETF, or other party preparing a derivative work
           any more rights than the license to the original RFC Editor
           Contribution, and
       C.  to reproduce any trademarks, service marks or trade names
           which are included in the RFC Editor Contribution solely in
           connection with the reproduction, distribution or publication
           of the RFC Editor Contribution and derivative works thereof
           as permitted by this paragraph.  Any entity reproducing RFC
           Editor Contributions will, as a condition of permission of
           such reproduction, preserve trademark and service mark
           identifiers used by the Contributor of the RFC Editor
           Contribution, including (TM) and (R) where appropriate.
       D.  The Contributor grants the IETF Trust and the IETF,
           permission to reference the name(s) and address(es) of the
           Contributor(s) and of the organization(s) s/he represents or
           is sponsored by (if any).


9.  Security Considerations

   This document specifies an RFC Editor (and, indirectly, IETF)
   administrative and publication procedure.  It has no specific
   security implications.


10.  IANA Considerations

   This document requires no actions by the IANA.



Klensin & Thaler        Expires September 4, 2007              [Page 12]


Internet-Draft           Independent Submissions              March 2007


11.  Acknowledgments

   Special thanks are due to Bob Hinden and Craig Partridge, who made
   several suggestions for improved text in earlier versions of this
   document and to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint
   Cerf, Leslie Daigle, and Olaf Kolkman who made a number of useful
   suggestions about the organization and content of subsequent
   versions.  We also express our appreciation to the IETF and Scott
   Bradner, Editor, for the material extracted from BCP 78 [RFC3978] and
   used in Section 8.


12.  Change log

   [[anchor16: RFC Editor: please remove this section before
   publication]]

12.1.  Changes between version -02 and version -03

   This section summarizes changes between version -02 and version -03.

   o  Removed material suggesting specific revisions to RFC 3932.  There
      is still a forward pointer to a proposal for those revisions, but
      it is not normative.
   o  Added new text questioning whether documents considered by, but
      rejected in, WGs should be processed as independent submissions or
      via the IESG (and, implicitly, subject to normal appeal procedures
      if rejected there).
   o  Clarified that the order of actions in Section 4 is not a binding
      requirement.
   o  Indicated that authors should submit notes on existing discussion
      and reviews along with the request for publication itself.
   o  Brian Carpenter's suggested text about technical reviews was
      incorporated (approximately) into Section 5.
   o  Clarified the status of review privacy on documents accepted for
      publication.
   o  Added text to Section 6 to indicate that the RFC Editor will
      solicit inputs about effectiveness and quality in addition to
      names of individuals.
   o  Several small editorial and textual changes for clarity and
      correctness.

12.2.  Changes for -04

   This section summarizes changes between version -03 and version -04.






Klensin & Thaler        Expires September 4, 2007              [Page 13]


Internet-Draft           Independent Submissions              March 2007


   o  Removed the material on public reviews and public authors to a
      separate section and revised the rules somewhat.  The reader may
      wish to note that, in addition to the often-repeated arguments
      about standard practices in professional journals, no IETF-related
      management body makes transcripts of its internal discussions
      public.  In particular, the IESG has repeatedly declined (for good
      reason) to make its mailing list contents public and has also
      declined to permit general access to its conference calls.  There
      appear to be strong analogies between those precedents and
      reasonable confidentiality of reviews.  In particular, an author
      should always have the option of withdrawing a document rather
      than having reviews made public.
   o  The relationship between WG-produced documents, and documents
      considered as part of WG processes, has been further clarified.
   o  At IETF 67, the IPR WG decided that IPR rules for independent
      submissions were not the responsibility of that WG and would not
      be covered in future versions of BCP 78 [RFC3978].  To facilitate
      that transition, the material on that subject from RFC 3978 has
      been incorporated directly into this document.
   o  Several small editorial changes

12.3.  Changes for -05

   This section summarizes changes between version -04 and version -05.

   o  Updated the IPR text to reflect RFC 4748
   o  Removed a spurious empty subsection from that section.

12.4.  Changes for -06

   This section summarizes changes between version -05 and version -06.

   o  Pulled IESG Review out of sequence into its own section, which may
      happen at any time chosen by the RFC Editor.
   o  Clarified that IESG provides advice, and the decisions rest with
      the RFC Editor.
   o  Added text from the mailing list regarding reviewer anonymity.
   o  Added reference to RFC 2434 regarding IANA assignment policies
      that require going through the IETF.
   o  Added reference to RFC 2026 regarding document categories for
      independent submissions.
   o  Updated the IPR text to match RFC 3978 and RFC 4748.
   o  Addressed various editorial nits.


13.  References





Klensin & Thaler        Expires September 4, 2007              [Page 14]


Internet-Draft           Independent Submissions              March 2007


13.1.  Normative References

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

   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.

   [RFC2223bis]
              Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
              Request for Comments (RFC) Authors", <http://www.ietf.org/
              internet-drafts/draft-rfc-editor-rfc2223bis-08.txt>.

   [RFC3932]  Alvestrand, H., "The IESG and RFC Editor Documents:
              Procedures", BCP 92, RFC 3932, October 2004.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC4748]  Bradner, S., "RFC 3978 Update to Recognize the IETF
              Trust", BCP 78, RFC 4748, October 2006.

13.2.  Informative References

   [IEN137]   Cohen, D., "On Holy Wars and a Plea for Peace", IEN 137,
              April 1980,
              <ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt>.

   [RFC0021]  Cerf, V., "Network meeting", RFC 21, October 1969.

   [RFC1109]  Cerf, V., "Report of the second Ad Hoc Network Management
              Review Group", RFC 1109, August 1989.

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, March 1994.

   [RFC1810]  Touch, J., "Report on MD5 Performance", RFC 1810,
              June 1995.

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

   [RFC2441]  Cohen, D., "Working with Jon Tribute delivered at UCLA,
              October 30, 1998", RFC 2441, November 1998.

   [RFC2555]  Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler,
              J., and C. Anderson, "30 Years of RFCs", RFC 2555,



Klensin & Thaler        Expires September 4, 2007              [Page 15]


Internet-Draft           Independent Submissions              March 2007


              April 1999.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC4714]  Mankin, A. and S. Hayes, "Requirements for IETF Technical
              Publication Service", RFC 4714, October 2006.


Appendix A.  IAB Members at the time of this writing

   Bernard Aboba
   Loa Andersson
   Brian Carpenter
   Leslie Daigle
   Elwyn Davies
   Kevin Fall
   Olaf Kolkman
   Kurtis Lindqvist
   David Meyer
   David Oran
   Eric Rescorla
   Dave Thaler
   Lixia Zhang


Authors' Addresses

   John C Klensin (editor)
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140
   USA

   Phone: +1 617 491 5735
   Email: john-ietf@jck.com


   Dave Thaler (editor)
   One Microsoft Way
   Redmond, WA  98052
   USA

   Phone: +1 425 703 8835
   Email: dthaler@microsoft.com






Klensin & Thaler        Expires September 4, 2007              [Page 16]


Internet-Draft           Independent Submissions              March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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 procedures with respect to rights in RFC 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Klensin & Thaler        Expires September 4, 2007              [Page 17]