diff options
Diffstat (limited to 'doc/rfc/rfc4846.txt')
| -rw-r--r-- | doc/rfc/rfc4846.txt | 899 |
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] + |