Movatterモバイル変換

Network Working Group                                    J. Klensin, Ed.Request for Comments: 4846                                D. Thaler, Ed.Category: Informational                                        July 2007Independent Submissions to the RFC EditorStatus 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 2007Table of Contents1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .31.1.  Terminology Note . . . . . . . . . . . . . . . . . . . . .31.2.  Context and Philosophical Assumptions  . . . . . . . . . .42.  The Role of Independent Submissions  . . . . . . . . . . . . .43.  Document Submission  . . . . . . . . . . . . . . . . . . . . .54.  The Review Process . . . . . . . . . . . . . . . . . . . . . .64.1.  Posting of Draft . . . . . . . . . . . . . . . . . . . . .64.2.  Request for Publication  . . . . . . . . . . . . . . . . .64.3.  Initial RFC Editor Review  . . . . . . . . . . . . . . . .64.4.  Review and Evaluation  . . . . . . . . . . . . . . . . . .74.5.  Additional Reviews . . . . . . . . . . . . . . . . . . . .74.6.  Document Rejection . . . . . . . . . . . . . . . . . . . .74.7.  Final Decision and Notification  . . . . . . . . . . . . .84.8.  Final Editing and Publication  . . . . . . . . . . . . . .85.  Formal IESG Review . . . . . . . . . . . . . . . . . . . . . .86.  The Editorial Review Board . . . . . . . . . . . . . . . . . .97.  Status and Availability of Reviews . . . . . . . . . . . . . .107.1.  Posted Reviews . . . . . . . . . . . . . . . . . . . . . .107.2.  Rejected Documents . . . . . . . . . . . . . . . . . . . .117.3.  Documents Approved for Publication . . . . . . . . . . . .118.  Intellectual Property Rights . . . . . . . . . . . . . . . . .119.  Security Considerations  . . . . . . . . . . . . . . . . . . .1310. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .1311. References . . . . . . . . . . . . . . . . . . . . . . . . . .1311.1. Normative References . . . . . . . . . . . . . . . . . . .1311.2. Informative References . . . . . . . . . . . . . . . . . .14Appendix A.  IAB Members at the Time of Approval . . . . . . . . .15Klensin & Thaler             Informational                      [Page 2]

RFC 4846                Independent Submissions                July 20071.  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 notKlensin & 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 orKlensin & 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;RFC1109 [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] andRFC 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 inSection 4 andSection 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 inSection 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 inRFC 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.  SeeRFC 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 (seeSection 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 inSection 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 inRFC 3932 [RFC3932] or its successors, presumably   from the perspective outlined above inSection 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 withKlensin & 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 (seeSection 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 athttp://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 inSection 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 willKlensin & 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 ofBCP 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 EditorKlensin & 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, orKlensin & 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 fromBCP 78 [RFC3978] and   used inSection 8.11.  References11.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 200711.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 2007Appendix 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 ZhangAuthors' 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.comKlensin & Thaler             Informational                     [Page 15]

RFC 4846                Independent Submissions                July 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]