doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc4846.txt b/doc/rfc/rfc4846.txt
new file mode 100644
index 0000000..766dd31
--- /dev/null
+++ b/doc/rfc/rfc4846.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                    J. Klensin, Ed.
+Request for Comments: 4846                                D. Thaler, Ed.
+Category: Informational                                        July 2007
+
+
+               Independent Submissions to the RFC Editor
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   There is a long-standing tradition in the Internet community,
+   predating the Internet Engineering Task Force (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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin & Thaler             Informational                      [Page 1]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+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.  Review and Evaluation  . . . . . . . . . . . . . . . . . .  7
+     4.5.  Additional Reviews . . . . . . . . . . . . . . . . . . . .  7
+     4.6.  Document Rejection . . . . . . . . . . . . . . . . . . . .  7
+     4.7.  Final Decision and Notification  . . . . . . . . . . . . .  8
+     4.8.  Final Editing and Publication  . . . . . . . . . . . . . .  8
+   5.  Formal IESG Review . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  The Editorial Review Board . . . . . . . . . . . . . . . . . .  9
+   7.  Status and Availability of Reviews . . . . . . . . . . . . . . 10
+     7.1.  Posted Reviews . . . . . . . . . . . . . . . . . . . . . . 10
+     7.2.  Rejected Documents . . . . . . . . . . . . . . . . . . . . 11
+     7.3.  Documents Approved for Publication . . . . . . . . . . . . 11
+   8.  Intellectual Property Rights . . . . . . . . . . . . . . . . . 11
+   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
+   Appendix A.  IAB Members at the Time of Approval . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin & Thaler             Informational                      [Page 2]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+1.  Introduction
+
+   There is a long-standing 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 Internet Architecture
+   Board (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 its 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 --
+   the IAB, IRTF, and IETF Working Groups -- and from submissions
+   submitted to the Internet Engineering Steering Group (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 via the IESG
+   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 of one or more senior people and associated editorial
+   staff, and the term is used collectively below.  That term is not
+
+
+
+Klensin & Thaler             Informational                      [Page 3]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   intended to predict the future, either in terms of who does the job
+   or what they, or the document series, are called.
+
+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 still published in the IETF
+      document stream (see [RFC4844], Section 5.1.1) as Informational or
+
+
+
+Klensin & Thaler             Informational                      [Page 4]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+      Experimental RFCs, the Independent Submission path has
+      traditionally been open to them as well.  However, 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 such
+      documents should normally be published via the IETF document
+      stream.  In any event, these documents are published for the
+      historical record.
+
+   o  Satirical materials.
+
+   o  Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC
+      1109 [RFC1109] is 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 the Informational Sciences Institute (ISI) and the
+      Internet Corporation for Assigned Names and Numbers (ICANN) and
+      the June 2000 MOU [RFC2860], Internet Assigned Numbers Authority
+      (IANA) Policy Statements (e.g., RFC 2223 [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 an 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 (I-Ds), 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].
+
+
+
+Klensin & Thaler             Informational                      [Page 5]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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 declines 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
+   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 namespace, 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.
+
+
+
+
+Klensin & Thaler             Informational                      [Page 6]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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.
+
+   At minimum, the author of every document shall receive a written
+   summary of the review(s).  Reviewer anonymity is discussed in
+   Section 7.  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 dissatisfied 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.  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.
+
+
+
+Klensin & Thaler             Informational                      [Page 7]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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 perform that review, nor is the RFC Editor obligated
+   to publish it, 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 text, 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
+   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 [RFC3932] 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
+
+
+
+Klensin & Thaler             Informational                      [Page 8]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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
+   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 its 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 the 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.
+
+
+
+Klensin & Thaler             Informational                      [Page 9]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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.  The RFC Editor will also solicit IAB
+   comments 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
+   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 the 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
+
+
+
+Klensin & Thaler             Informational                     [Page 10]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   accompany their reviews, except for a reviewer who requested
+   anonymity.
+
+   The author will be notified in advance of the intent to post the
+   final reviews.  The author may then request that the document be
+   withdrawn and the reviews kept private.  However, such an 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
+   options for recourse.
+
+   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, the IETF Administrative Support Activity (IASA) or the IETF
+   Trust, or the Internet Society (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
+
+
+
+
+
+Klensin & Thaler             Informational                     [Page 11]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+   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 expected to 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 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
+           that are included in the RFC Editor Contribution solely in
+           connection with the reproduction, distribution, or
+
+
+
+Klensin & Thaler             Informational                     [Page 12]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+           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.  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.
+
+11.  References
+
+11.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.
+
+   [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.
+
+
+
+Klensin & Thaler             Informational                     [Page 13]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+11.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.
+
+   [RFC2223BIS]  Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
+                 Request for Comments (RFC) Authors", Work in Progress,
+                 August 2004.
+
+   [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, 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.
+
+   [RFC4844]     Daigle, L., Ed. and IAB, "The RFC Series and RFC
+                 Editor", RFC 4844, July 2007.
+
+
+
+
+
+
+
+
+
+Klensin & Thaler             Informational                     [Page 14]
+
+RFC 4846                Independent Submissions                July 2007
+
+
+Appendix A.  IAB Members at the Time of Approval
+
+   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             Informational                     [Page 15]
+
+RFC 4846                Independent Submissions                July 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Klensin & Thaler             Informational                     [Page 16]
+