Network Working Group J. Klensin, Ed.
Internet-Draft December 21, 2006
Intended status: Informational
Expires: June 24, 2007
Independent Submissions to the RFC Editor
draft-klensin-rfc-independent-05.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 June 24, 2007.
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 and some reasons why it is important. It then describes
Klensin Expires June 24, 2007 [Page 1]
Internet-Draft Independent Submissions December 2006
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.
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 . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Posting of Draft . . . . . . . . . . . . . . . . . . . . . 6
4.2. Request for Publication . . . . . . . . . . . . . . . . . 6
4.3. Initial RFC Editor Review . . . . . . . . . . . . . . . . 6
4.4. Document Rejection . . . . . . . . . . . . . . . . . . . . 7
4.5. Review and Evaluation . . . . . . . . . . . . . . . . . . 7
4.6. Unsolicited Reviews . . . . . . . . . . . . . . . . . . . 7
4.7. Additional Reviews . . . . . . . . . . . . . . . . . . . . 7
4.8. Final IESG Review . . . . . . . . . . . . . . . . . . . . 7
4.9. Final Decision and Notification . . . . . . . . . . . . . 8
4.10. Final Editing and Publication . . . . . . . . . . . . . . 9
5. The Editorial Review Board . . . . . . . . . . . . . . . . . . 9
6. Status and Availability of Reviews . . . . . . . . . . . . . . 9
6.1. Documents in process or rejected . . . . . . . . . . . . . 10
6.2. Published Documents and Documents Approved for
Publication . . . . . . . . . . . . . . . . . . . . . . . 10
7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Changes between version -02 and version -03 . . . . . . . 12
11.2. Changes for -04 . . . . . . . . . . . . . . . . . . . . . 13
11.3. Changes for -05 . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Klensin Expires June 24, 2007 [Page 2]
Internet-Draft Independent Submissions December 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 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 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 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, 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 be 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, are called.
Klensin Expires June 24, 2007 [Page 3]
Internet-Draft Independent Submissions December 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]. Those issues, and proposals for changes, are discussed in
a different document [RFC3932upd], but they are semi-independent of
the content of this document, which focuses on the review and
approval process for independent submissions.
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 lead up 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 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
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
Klensin Expires June 24, 2007 [Page 4]
Internet-Draft Independent Submissions December 2006
their intimate connection to the IETF Standards Process and WG
activites 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.
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, as a courtesy, publication of particular documents
be deferred because their untimely publication could cause confusion
or other harm with proposals under consideration for standardization.
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 as part of its review. If the
IESG identifies issues, it may recommend explanatory or qualifying
text for the RFC Editor to include in the document if it is
published.
The specific procedures to be followed in review are described in
Section 4.
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 more detail in [RFC2223] and a working draft of an update to it
[RFC2223bis].
Any document that meets the requirements of this specification, of
[RFC2223] and its successors, and of any intellectual property or
Klensin Expires June 24, 2007 [Page 5]
Internet-Draft Independent Submissions December 2006
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 is likely to 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
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 decisions.
In general, the steps in the review process are identified in the
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.
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.
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.
Klensin Expires June 24, 2007 [Page 6]
Internet-Draft Independent Submissions December 2006
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
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 (see Section 5) reviews or
evaluation of reviews by others.
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. Final 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
Klensin Expires June 24, 2007 [Page 7]
Internet-Draft Independent Submissions December 2006
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
will post an indication on its web pages 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
authors and the 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 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.7), the IAB is
not obligated to perform this type of review and may decline the
request.
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.
Klensin Expires June 24, 2007 [Page 8]
Internet-Draft Independent Submissions December 2006
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. 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.
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.
6. Status and Availability of Reviews
The RFC Editor will conduct the reviews discussed above with the
intent of balancing fairness to authors, transparancy of the review
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.
Klensin Expires June 24, 2007 [Page 9]
Internet-Draft Independent Submissions December 2006
6.1. Documents in process or rejected
For documents in process, reviews may be made public and posted on
the RFC Editor web site at the request of the author. The names of
reviewers associated with each review will normally accompany their
reviews, but may be withheld at the request of the reviewer.
If the RFC Editor declines to publish a document, the document author
may request that reviews be made public, as above, However, that
request must be timely, generally within thirty days of the author's
notification that the document would not be published.
With or without a document author request, the RFC Editor may post
the full set of reviews associated with a document in process or
rejected for publication if they conclude that doing so would be in
the best interest of the community. The author will be notified that
this action is about to be taken and may optionally request that the
request to publish the document be withdrawn and the reviews kept
private. Under normal circumstances, the RFC Editor will honor that
request.
6.2. Published Documents and Documents Approved for Publication
For documents that are published, either the author or any reviewer
may request that reviews be made public. The RFC Editor may, but is
not required to, do so. In considering whether to make review
materials public, the RFC Editor is expected to note, first, 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
and that the author generally does not have the right to publish a
refutation to an unfavorable review; 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.
Nothing in this section or the subsections above precludes private
communications between reviewers, the Editorial Board, and the RFC
Editor; such communications will remain confidential. At minimum,
the author of either an accepted or rejected document shall receive a
written summary of the review(s).
7. 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
Klensin Expires June 24, 2007 [Page 10]
Internet-Draft Independent Submissions December 2006
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 its 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,
royalty-free, world-wide right and license to the ISOC, 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 ISOC,
the IETF, or other party preparing a derivative work any more
rights than the license to the original RFC Editor
Contribution, and
Klensin Expires June 24, 2007 [Page 11]
Internet-Draft Independent Submissions December 2006
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, ISOC, and the RFC
Editor 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).
8. Security Considerations
This document specifies an RFC Editor (and, indirectly, IETF)
administrative and publication procedure. It has no specific
security implications.
9. IANA Considerations
This document requires no actions by the IANA.
10. 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 7.
11. Change log
[[anchor18: RFC Editor: please remove this section before
publication]]
11.1. Changes between version -02 and version -03
This section summarizes changes between version -02 and version -03.
Klensin Expires June 24, 2007 [Page 12]
Internet-Draft Independent Submissions December 2006
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 4.8.
o Clarified the status of review privacy on documents accepted for
publication.
o Added text to Section 5 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.
11.2. Changes for -04
This section summarizes changes between version -03 and version -04.
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 as far as this editor is concerned) to make its mailing
list contents public and 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
Klensin Expires June 24, 2007 [Page 13]
Internet-Draft Independent Submissions December 2006
11.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. References
12.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.
[RFC3932upd]
Klensin, J., Ed., "IESG Notes on Independent Submissions
to the RFC Editor".
[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.
12.2. Informative References
[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,
Klensin Expires June 24, 2007 [Page 14]
Internet-Draft Independent Submissions December 2006
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.
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical
Publication Service", RFC 4714, October 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 June 24, 2007 [Page 15]
Internet-Draft Independent Submissions December 2006
Full 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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the 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 Expires June 24, 2007 [Page 16]