[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                    J. Klensin, Ed.
Internet-Draft                                              May 19, 2006
Expires: November 20, 2006


               Independent Submissions to the RFC Editor
                 draft-klensin-rfc-independent-02.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 November 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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, some reasons why it is important, and describes editorial and
   processing norms that can be used for independent submissions as we



Klensin                 Expires November 20, 2006               [Page 1]

Internet-Draft           Independent Submissions                May 2006


   go 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.  Submission . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Review . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Posting of Draft . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Request for Publication  . . . . . . . . . . . . . . . . .  6
     4.3.  Initial RFC Editor Review  . . . . . . . . . . . . . . . .  6
     4.4.  Document Rejection . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Review and Evaluation  . . . . . . . . . . . . . . . . . .  7
     4.6.  Unsolicited Reviews  . . . . . . . . . . . . . . . . . . .  7
     4.7.  Additional Reviews . . . . . . . . . . . . . . . . . . . .  7
     4.8.  Formal IESG Review . . . . . . . . . . . . . . . . . . . .  7
     4.9.  Final Decision and Notification  . . . . . . . . . . . . .  8
     4.10. Intellectual Property Rights . . . . . . . . . . . . . . .  8
     4.11. Final Editing and Publication  . . . . . . . . . . . . . .  9
   5.  The Editorial Review Board . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Interactions with RFC 3932  . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13


















Klensin                 Expires November 20, 2006               [Page 2]

Internet-Draft           Independent Submissions                May 2006


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, some reasons why it is important, and describes editorial and
   processing norms that can be used for independent submissions as we
   go 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 36
   years while the IETF is celebrating its 20th 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 a
   "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, have been known historically 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 by an
   organization or one or more senior people and associated 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, is called.




Klensin                 Expires November 20, 2006               [Page 3]

Internet-Draft           Independent Submissions                May 2006


1.2.  Context and Philosophical Assumptions

   This document contains text that, if agreed to by the community, may
   suggest a reexamination of and a corresponding update to RFC 3932
   [RFC3932].  Issues that should be examined and possibly changed in
   3932 are identified in an appendix for easy separation into a form
   that would be appropriate for BCP processing.  This document
   complements the discussions in the ongoing "TechSpec" effort,
   including the discussion of IETF-originated documents in [Mankin-
   Techspec].  It takes a somewhat stronger view than some have read
   into those documents, 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.  While the authors
   and contributors to this document are firmly committed to IESG review
   to identify conflicts with the standards process and suggestions that
   would cause serious harm to the Internet, as outlined in RFC 3932 and
   RFC 2026 [RFC2026], they believe that the IESG should deprecate, as
   distinct from issuing general warnings about the lack of formal IETF
   review, only those things about which there is IETF consensus about
   harm.


2.  The Role of Independent Submissions

   When the RFC series was fairly new, RFCs could be used to publish
   general papers on networking as well as the types of documents we
   would describes 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



Klensin                 Expires November 20, 2006               [Page 4]

Internet-Draft           Independent Submissions                May 2006


      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 [RFC3932] RFC 3932, Section ???), the
      independent submission path has traditionally been open to them.
      These documents are published for the historical record.
   o  Satirical materials.
   o  Meeting notes and reports (RFC 164 [RFC0164] is the earliest, 1109
      [RFC1109] probably the most important).
   o  Editorials (the best example is IEN-137, not an RFC).
   o  Eulogies (RFC 2441 [RFC2441])
   o  Technical contributions (e.g., RFC 1810 [RFC1810]) and,
      historically,
   o  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 should seek advice from the
   IESG about possible relationships and conflicts with IETF work.  The
   IESG may ask that publication of particular documents be deferred, as
   a courtesy, because their untimely publication could cause confusion
   or other harm with proposals under consideration for standardization
   and, absent compelling arguments to the contrary, the RFC Editor will
   honor such requests.  Similarly, 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 or, after doing a technical
   review, conclude that the document describes a protocol or technique
   that would cause operational damage to the Internet.  In those cases,
   the IESG may recommend explanatory or qualifying text for the RFC
   Editor to include in the document if it is published.

   However, in no case should qualifying text go beyond these general
   principles.  In particular, no text supplied by the IESG should
   indicate that the independent submission is technically deficient or
   should not be taken seriously unless there has been an IETF technical
   review that has reached consensus on that conclusion.

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


3.  Submission

   Independent submissions are submitted directly to the RFC Editor.



Klensin                 Expires November 20, 2006               [Page 5]

Internet-Draft           Independent Submissions                May 2006


   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 more detail in [RFC2223] and a working draft of an update to it
   [RFC2223bis].


4.  Review

   While this document is consistent with the broad outline of
   independent submission and review as practiced over the years, it
   specifies some new arrangements in RFC Editor processing that will
   improve the balance between openness and independent decisons.
   [RFC3932], specified its view of its role in the review process for
   independent submissions.

   In general, the steps in the review process are as follows:

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.

4.3.  Initial RFC Editor Review

   RFC Editor Staff perform an initial check on the document.  If they
   believe there is a high likelihood of conflicts or other interactions
   with IETF efforts (including believing that the document is one that
   the IESG should probably process), they may forward it to the IESG,
   or relevant ADs, for preliminary evaluation and comment.

4.4.  Document Rejection

   If the document does not appear publishable, the RFC Editor may
   reject a submitted document at any point in the process specified
   here.  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.  Alternatively, the RFC Editor Staff may, at their
   discretion, iterate with the author on the document to improve its



Klensin                 Expires November 20, 2006               [Page 6]

Internet-Draft           Independent Submissions                May 2006


   quality.  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.5.  Review and Evaluation

   The RFC Editor arranges for one or more reviews of the document.
   This may include Editorial Board reviews or evaluation of reviews by
   others.  Unless there is some substantive reason to not do so, these
   reviews will be made public and posted on the RFC Editor web site.
   The author may request that the reviews be kept private and the
   request to publish their document be withdrawn.

   This section does not preclude private communications between
   reviewers, the Editorial Board, and the RFC Editor; such
   communications will remain confidential.  At minimum, the author
   shall receive a written summary of the review(s).

   While the reviews will generally be public, as discussed above,
   reviewers are allowed to be anonymous at their request.

4.6.  Unsolicited Reviews

   Unsolicited reviews from parties independent of the author are
   welcome at any time and will be handled as above.  Unsolicited
   reviews will be shared with the author including the identity of the
   reviewer.

4.7.  Additional Reviews

   If the author is unsatisfied with the 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 documents.  Such requests to the IAB, and any reviews the IAB
   chooses to perform, will occur according to procedures of the IAB's
   choosing.  However, 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..  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.8.  Formal IESG Review

   Once the RFC Editor has made a tentative decision to publish, the
   document is forwarded to the IESG for evaluation with a relatively
   short timeout.



Klensin                 Expires November 20, 2006               [Page 7]

Internet-Draft           Independent Submissions                May 2006


   The IESG evaluation is not a technical one.  Instead, it covers the
   issues outlined above in Section 1.2 and listed in RFC 3932 or its
   successors.  That is, the evaluation should focus exclusively on
   conflicts or confusion with IETF process, end runs around working
   group activities, and obvious and significant harm to the Internet.

   At the time the document is forwarded to the IESG, the RFC Editor
   will post an indication on its web pages that the document is under
   IESG review and that comments on conflicts or harm 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.

   If the IESG, after completing its review, concludes that publication
   of the document should be delayed for a reasonable period of time,
   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, providing
   appropriate justification.  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 for 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.7), the IAB is not obligated to
   perform this type of review.

4.9.  Final Decision and Notification

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

   Information about the IESG requested publication delay or request to
   not publish a document will be posted to the RFC Editor web site to
   supplement document status information.

4.10.  Intellectual Property Rights

   IPR provisions for independent submissions are as specified in the



Klensin                 Expires November 20, 2006               [Page 8]

Internet-Draft           Independent Submissions                May 2006


   material on RFC Editor submissions in BCP 78 [RFC3978] although that
   material should eventually be migrated into a successor of this
   document.

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


6.  Security Considerations

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


7.  IANA Considerations

   This document requires no actions by the IANA.


8.  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, and Leslie Daigle who made a number of useful suggestions about
   the organization and content of subsequent versions.


Appendix A.  Interactions with RFC 3932




Klensin                 Expires November 20, 2006               [Page 9]

Internet-Draft           Independent Submissions                May 2006


   The discussions that led to this document and experience since RFC
   3932 was published suggests that a review of the principles of IESG
   review and corresponding adjustment of specific text is in order.
   The author of this document believes that the principles should be:

   1.  No document should be published on an independent submission
       basis that would cause confusion with an active IETF protocol
       development or specification effort.  The IESG is normally the
       best-positioned body to determine whether such conflicts exist.
   2.  No independent submission should be so written as to state or
       imply that it is a standard, or a specification that will be
       standardized, from the IETF or any other body unless that is, in
       fact, the case.  Similarly, no claim should be made about IETF
       consensus unless the IESG determines, after a Last Call or
       equivalent process, and such consensus actually exists.
   3.  Some, although certainly not all, independent submissions are
       extensively discussed and reviewed within the IETF community, or
       the Internet community more generally, prior to submission for
       publication.  Just as no statement should appear in a published
       document that states or implies level of adoption, agreement, or
       consensus that did not occur, no statement should appear that
       states that significantly less review occurred than was actually
       the case.  Similarly, no statement should appear that suggests
       that the IETF community has a negative view of the document
       unless such a view has been established via formal consensus-
       determining mechanisms.
   4.  It is desirable that well-reasoned critical reviews and critiques
       of, and even dissents from, IETF standards and conclusions be
       published in the RFC series.  These documents must be clear about
       their status and purpose.  Such clarity in the text is preferable
       to "boilerplate" disclaimers that few people will read: such
       boilerplate is, at best, a second-choice alternative to clarity
       in the text.  Conflict with an IETF position is not a reason to
       deny, or even significantly defer, publication.  The potential
       for confusion with an IETF Standard or position, or its
       interpretation, usually will be a reason to deny or defer
       publication.


9.  References

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



Klensin                 Expires November 20, 2006              [Page 10]

Internet-Draft           Independent Submissions                May 2006


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

9.2.  Informative References

   [Mankin-Techspec]
              Mankin, A. and S. Hayes, "Requirements for IETF Technical
              Publication Service", May 2006, <http://www.ietf.org/
              internet-drafts/draft-mankin-pub-req-08.txt>.

   [RFC0164]  Heafner, J., "Minutes of Network Working Group meeting,
              5/16 through 5/19/71", RFC 164, May 1971.

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

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

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















Klensin                 Expires November 20, 2006              [Page 11]

Internet-Draft           Independent Submissions                May 2006


Author's Address

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

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










































Klensin                 Expires November 20, 2006              [Page 12]

Internet-Draft           Independent Submissions                May 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


Copyright Statement

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


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Klensin                 Expires November 20, 2006              [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/