Network Working Group J. Klensin, Ed.
Internet-Draft April 12, 2006
Expires: October 14, 2006
Independent Submissions to the RFC Editor
draft-klensin-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 October 14, 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 a "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 October 14, 2006 [Page 1]
Internet-Draft Independent Submissions April 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 . . . . . . . . . . 3
2. The Role of Independent Submissions . . . . . . . . . . . . . 4
3. Submission . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . 8
5. The Editorial Review Board . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Klensin Expires October 14, 2006 [Page 2]
Internet-Draft Independent Submissions April 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 a "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 choose
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. The
latter 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". 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.
1.2. Context and Philosophical Assumptions
This document is intended to update RFC 3932 [RFC3932] and to
complement the discussions in the ongoing "TechSpec" effort,
including the discussion of IETF-originated documents in [Mankin-
Klensin Expires October 14, 2006 [Page 3]
Internet-Draft Independent Submissions April 2006
Techspec]. It takes a somewhat stronger view than those documents,
starting from the belief that independent submissions are valuable if
they are, in fact, independent of the IETF process. From the
perspective of the IETF, they are especially important as checks on
the IETF processes even though such checks are not the only, or even
a common, reason for publication of independent submissions. That
role is compromised if IETF-related entities are able to condemn
documents by attaching language to them that implies that the
documents are worthless. This is especially problematic when the
documents have not been sufficiently reviewed in the IETF to
determine an IETF consensus about their content. 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 IETF should condemn, 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
new reasons. 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.
These documents are published for the historical record.
o Satirical materials.
o Meeting notes and reports (RFC 164 [RFC0164] is the earliest, 1109
[RFC1109] the most important).
Klensin Expires October 14, 2006 [Page 4]
Internet-Draft Independent Submissions April 2006
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 IANA Policy Statements (e.g., RFC 1591 [RFC1591]), at least prior
to the June 2000 MOU [RFC2860].
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.
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
The IESG, in [RFC3932], specified its view of its role in the review
Klensin Expires October 14, 2006 [Page 5]
Internet-Draft Independent Submissions April 2006
process for independent submissions. Based on informal discussions
in the IETF, this document updates that one slightly.
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 an opportunity for community review and feedback on that draft,
the 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 if they conclude that the submissions 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
may, at their discretion, iterate with the author on the document to
improve its 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 evaluation of the reviews. 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
Klensin Expires October 14, 2006 [Page 6]
Internet-Draft Independent Submissions April 2006
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).
Independent of whether the reviews are public, reviewers are allowed
to be anonymous at their request.
4.6. Unsolicited Reviews
Unsolicited reviews from parties independent of the author, including
IESG members acting in their individual capacities, are welcome at
any time and will be handled as above.
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.
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.
The IESG evaluation is not a technical one. Instead, it covers the
issues outlined above in Section 1.2 and listed in RFC 3932. 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 and other comments may be sent 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 these delays is expected to
continue. That agreement permits the IESG to ask for a delay of up
Klensin Expires October 14, 2006 [Page 7]
Internet-Draft Independent Submissions April 2006
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 review the request to
not publish the document.
The RFC Editor or the author may appeal the IESG's request to delay
or not publish to the IAB. Such an appeal will be made public via
the RFC Editor web site.
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's web site to
supplement document status information.
4.10. Intellectual Property Rights
IPR provisions for independent submissions are as specified in the
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 general advice and
advice and reviews of particular proposed publications. 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.
Klensin Expires October 14, 2006 [Page 8]
Internet-Draft Independent Submissions April 2006
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.
9. Contributors
..to be supplied...
10. References
10.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.
10.2. Informative References
[Mankin-Techspec]
Mankin, A. and S. Hayes, "Requirements for IETF Technical
Klensin Expires October 14, 2006 [Page 9]
Internet-Draft Independent Submissions April 2006
Publication Service", April 2006, <http://www.ietf.org/
internet-drafts/draft-mankin-pub-req-06.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 October 14, 2006 [Page 10]
Internet-Draft Independent Submissions April 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 October 14, 2006 [Page 11]
Internet-Draft Independent Submissions April 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 October 14, 2006 [Page 12]