GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4846

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4846.txt · Last modified: 2007/07/17 00:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki