RFC 4846

RFC 4846: Independent Submissions to the RFC Editor 📜✨

okay bestie, RFC 4846 is titled Independent Submissions to the RFC Editor 🎀. It came out in July 2007 and was written by J. Klensin, Ed. and D. Thaler, Ed. for the Network Working Group. It's Informational, which means it's giving "here's some info" 💅, not a standard. The header doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC. 🦋

Status of This Memo 🌸

This memo is for the Internet community to read. It does not specify an Internet standard of any kind, so don't treat it as a rule. Distribution is unlimited, so share it with everyone! 💖

Copyright Notice 💜

Copyright (C) The IETF Trust (2007). 🫶

Abstract 🍓

ok so there's this super long tradition in the Internet community, way older than the IETF (Internet Engineering Task Force) itself 👑, of using the RFC Series to publish stuff that doesn't come from the IETF standards process and its review and approval steps. Those docs are called "Independent Submissions," and they do a lot for the community, both inside and outside the group of active IETF folks 🧚. This document talks about the Independent Submission model and why it matters. Then it covers the editorial and processing norms that can be used for Independent Submissions as things move forward into new relationships between the IETF community and its main technical publisher. It's giving big picture energy 🔥.

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

1. Introduction 🎀

Okay, same tradition as the abstract, just the intro version 💅. The RFC Series has been used for years to publish things that aren't rooted in the IETF standards process, and those are the "Independent Submissions." They're important to the community inside and outside the IETF crowd. This doc explains the model and why it's important, then goes over the editorial and processing norms that can be used as things evolve between the IETF community and its primary technical publisher 🦋.

Here's the thing to keep in mind: the RFC Editor function is older than the IETF. The RFC Series is 38 years old [RFC2555] right now, while the IETF is celebrating its 21st anniversary 🎂. Every doc published before the IETF existed, and for a few years after, would count as an Independent Submission today 🌈. As the IETF grew, the Internet Architecture Board (IAB) and then the IETF itself chose to publish IETF docs as RFCs, fully knowing the RFC Editor function was an independent publication mechanism 👑. Other paths were possible. For example, the IETF could have made its own publication series. People felt it was worth a lot to keep publishing IETF work in the same series used for the basic protocols of the Internet ✨.

1.1. Terminology Note 📝

This document is about what people have historically called "Independent Submissions." That term is different from IETF and IAB community docs that come from formal groups (the IAB, IRTF, and IETF Working Groups), and from submissions sent to the Internet Engineering Steering Group (IESG) for Standards-Track, Informational, or Experimental processing 🧚. Docs made by individuals, not by IETF WGs or other IETF-affiliated groups, but sent for publication through the IESG under Area Director sponsorship, are called "individual submissions" 💖.

For convenience and obvious historical reasons, the editor and publisher of docs that don't go through the IETF is called the "RFC Editor" in this doc. The RFC Editor will usually be an organization of one or more senior people plus editorial staff, and the term is used for all of them together. The term isn't meant to predict the future, either for who does the job or what they, or the doc series, end up being called 🔮.

1.2. Context and Philosophical Assumptions 🧠

This doc goes with the discussion and guidelines in [RFC4714], which focuses on Standards-Track docs. It takes a somewhat stronger stance than the discussions that led to that doc, starting from the belief that Independent Submissions are most valuable when they're actually independent of the IETF process 🔥. From the IETF's point of view, Independent Submissions matter a lot as checks on the IETF processes, even though checking isn't the only reason for them, or even a common one 🫶. That role gets compromised if IETF-related entities can block or deprecate such docs beyond what's needed to avoid trouble with the standards process 🙈.

2. The Role of Independent Submissions 🌸

When the RFC Series was pretty new, RFCs were used to publish general papers on networking as well as the kinds of docs we'd call standards today. Those roles also grew during the early design and development of the ARPANET, long before anyone dreamt of the IETF, back when the difference between, for example, Standards and Informational docs wasn't drawn as precisely 🦕. In more recent years, Independent Submissions have become important for several reasons, some of them pretty new. They include:

• Discussion of Internet-related technologies that aren't part of the IETF agenda.
• Introduction of important new ideas as a bridge publication venue between academia and IETF engineering.
• Informational discussions of technologies, options, or experience with protocols.
• Informational publication of vendor-specific protocols.
• Critiques and discussions of alternatives to IETF Standards-Track protocols. The potential for these critiques provides an important check on the IETF's standards processes and should be seen in that light 🔍.
• Documents considered by IETF Working Groups but not standardized. Lots of these are still published in the IETF document stream (see [RFC4844], Section 5.1.1) as Informational or Experimental RFCs, but the Independent Submission path has traditionally been open to them too. Because they're so tied to the IETF Standards Process and WG activities, and so sensitive to exact statements of relationships and timing, there's reason to believe these docs should normally be published via the IETF document stream. Either way, they're published for the historical record 📚.
• Satirical materials. 🙃
• Meeting notes and reports (RFC 21 [RFC0021] is the earliest; RFC 1109 [RFC1109] is probably the most important) 🗓️.
• Editorials (the best example is IEN 137 [IEN137], not an RFC) 🎤.
• Eulogies (RFC 2441 [RFC2441]) 🕊️.
• Technical contributions (e.g., RFC 1810 [RFC1810]) 🛠️.
• Historically, RFC Editor and, at least before 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 super clear from that list that, to work well, the review and approval process for Independent Submissions should be pretty independent of the IETF 💅. An important principle that's been used historically is that the RFC Editor asks the IESG for advice about possible relationships and conflicts with IETF work 🤝. Any submission that's an alternative to, or conflicts with, an IETF Standard or a proposal for Standards-Track adoption must clearly say so about that relationship 🚨. The IESG may point out such conflicts as part of its review.

The specific procedures for review are described in Section 4 and Section 5 📋.

3. Document Submission 📬

Independent Submissions go directly to the RFC Editor. They must first be posted as Internet-Drafts (I-Ds), so the submission is usually just a note asking the RFC Editor to think about a particular Internet-Draft for publication ✉️. The process is described in [RFC2223]. More info can be found in the working draft of an update to that doc [RFC2223BIS].

Any doc that meets the requirements of this spec, of [RFC2223] and its successors, and of any intellectual property or other conditions that may be set from time to time, can be submitted to the RFC Editor for consideration as an Independent Submission 🎀. However, the RFC Editor prefers that docs created through IETF processes (e.g., working group output) get considered by the IESG and only come this way if a working group or the IESG decides not to publish them 🙏. In those latter cases, the review will go more smoothly if the authors give a history of consideration and reviews of the doc at submission time 📖.

4. The Review Process 🔄

In general, the steps in the review process are listed in the subsections below. Any of them can be repeated and, at the RFC Editor's discretion, steps after the first can be taken out of order 🌀. Also, the IESG review, as covered in Section 5, must take place before a final decision is made on whether to publish the doc ⏳.

4.1. Posting of Draft 📝

The author(s) or editor(s) of a document post it as an Internet-Draft. That's step one, bestie 💖✨

---

That's the first chunk of the doc, babe 🦋. There's more to come in the next parts, so stay tuned 💜

4.2. Request for Publication 💌

okay so once the I-D has had its normal chance for community review and feedback, and the I-D repository has announced it, the author or editor sends a request for consideration for publication to the RFC Editor at rfc-editor@rfc-editor.org. ✨ bestie, that request should note any community discussion or reviews the document got before submission, plus the desired document category (Informational or Experimental, as discussed in RFC 2026 [RFC2026], Section 4.2). 🎀

if the document needs 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 do a first check on the document to see if there are any obvious issues or problems, and to decide the order of the other steps. 🦋

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 can repeat as many times as needed to get to an acceptable editorial quality 💅

4.4. Review and Evaluation 📝

the RFC Editor sets up one or more reviews of the document. this may include reviews from the Editorial Board (see Section 6), 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. unless some unusual circumstance comes up, a preponderance of favorable reviews should lead to publication 🔥

4.5. Additional Reviews 🔁

if the author is unhappy with one or more reviews, the author may ask the RFC Editor to solicit additional reviews. in exceptional circumstances, the author may ask the IAB to review the document. requests to the IAB, and any reviews the IAB chooses to perform, will happen according to procedures of the IAB's choosing. the IAB is not required to start a review or go along 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 we just went over leads to the conclusion that the document is not publishable, the RFC Editor may reject the document. that would normally happen because the submission doesn't meet the technical or editorial standards of the RFC Series, or isn't relevant to the areas the series covers 💀

if the RFC Editor rejects a document, the author may request an additional review from the IAB, as described below. but the IAB is not obligated to do that review, and the RFC Editor is not obligated to publish it, even with a favorable IAB review. not me making the rules, but yeah 🥲

4.7. Final Decision and Notification 📬

in all cases, the ultimate decision to publish or not publish, and with what text, belongs to the RFC Editor. 👑

the RFC Editor will tell the author and the Editorial Board the final decision. 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 gets handled in a similar way to other RFCs, with principles about priorities worked out with the IAB as appropriate. main character energy for the paperwork 🌸

---

5. Formal IESG Review ✨

okay so at an appropriate time in the review process, normally after the RFC Editor has made a tentative decision to publish, the document gets forwarded to the IESG for evaluation with a relatively short timeout. if the nature of the document convinces 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 looks to the RFC Editor like the IESG is likely to want to take the document over and assign it to a working group, it may be better to ask for the IESG review before taking on the delays of 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 means the evaluation should focus exclusively on conflicts or confusion with IETF process, and attempts to subvert ("end run") working group activities. 🚧

when the document is forwarded to the IESG, the RFC Editor posts a note on its Web site saying the document is under IESG review, and that comments on conflicts can be sent to the IESG with copies to the RFC Editor. additional mechanisms may be developed from time to time to let a community know 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. 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 should be delayed for a reasonable period of time, because 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 lets the IESG ask for a delay of up to six months and, if necessary, 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 ask that the IAB provide an additional opinion. such a request will be made public via the RFC Editor Web site. just like the IESG review itself, the IAB's opinion, if any, will be advisory. and, just like 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. much like the editorial boards of professional journals and publishers, it gives the RFC Editor both advice and reviews of particular proposed publications, plus general and strategic policy advice. the membership list is public and can be found at http://www.rfc-editor.org/edboard.html. 🎓

Editorial Board members serve at the pleasure of the RFC Editor. from time to time, the RFC Editor will ask the IAB and other sources for suggestions for new appointees, and will seek IAB comments on those to be appointed. the RFC Editor will also ask the IAB for comments on how well the review process works, the quality of documents being published, and the criteria applied. still, to keep the Independent Submission process independent, 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 run the reviews discussed above with a few goals in mind: being fair to authors, keeping the review process transparent to the wider community, protecting reviewers from possible retaliation or undue pressure, and making sure the community can see any significant dissents from published documents, with the same level of scrutiny the original documents got. to that end, reviews and information about reviewers will be made public under the circumstances below. in special cases where other considerations apply, the RFC Editor may adopt special provisions, after looking at the circumstances and proposed action with the IAB. 🔍

any reviewer taking part in the process outlined in this document does so on the condition that they consent to how the reviews are handled, as outlined in this section. in special cases, individual arrangements may be worked out with the RFC Editor in advance. 🤝

as described in Section 4.4, all reviews will be shared with the document authors (with possible editing to remove any extreme language). reviewers' names will normally go along with these reviews, but reviewers can be granted anonymity if they ask the RFC Editor. in any case, the RFC Editor will forward any author rebuttal messages to the reviewer. 📨

nothing in this section or the subsections below stops private communications between reviewers, the Editorial Board, and the RFC Editor. those communications will stay 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 the document, if doing so would be in the best interest of the community. the author may ask for earlier posting of reviews and rebuttals, to inspire additional unsolicited reviews, for example. the reviewers' names will go along with their reviews, except for a reviewer who asked for anonymity. 🦄

the author will be notified in advance of the intent to post the final reviews. the author may then ask 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:

• Request one or more additional reviews (Section 4.5) followed by a reconsideration. 🔄
• Request an IAB review (Section 4.5, Section 4.6) followed by a reconsideration. 🧐
• Request that the reviews be published on the RFC Editor Web site. 🌟

7.3. Documents Approved for Publication ✨

okay so when the RFC Editor is deciding whether to make review materials public for documents that got accepted, they're expected to keep a few things in mind 🧐. the best way to comment on or disagree with an RFC is generally another RFC 💅. reviews that criticize a document don't get reviewed themselves 🙈. the review and refutation process is necessarily fragmentary 🧩. and if someone feels strongly about a subject that already has a review written, they often wouldn't need to do much extra work to turn that review into an RFC-format document 🎀.

8. Intellectual Property Rights 🔥

okay this part is a little legal-y but it's important, bestie 🫶. the following material was pulled from the relevant sections of BCP 78 [RFC3978] [RFC4748] so that all the Independent Submission info for technical publications made under the IETF, the IETF Administrative Support Activity (IASA), the IETF Trust, or the Internet Society (ISOC) lives in one single place 🗂️. it also kicks off the process of separating discussions about Independent Submissions from discussions about Standards-Track or other IETF documents 🦋. quick heads up: the text below calls the same thing an "Independent Submission" elsewhere in this document "RFC Editor Contribution" 💜. and the RFC Editor may change these provisions from time to time, but only after getting the advice and consent of the IETF Trust in its role as the formal publisher of RFCs 🌈.

by submitting an RFC Editor Contribution, each person actually submitting it, and each named co-Contributor, is deemed to agree to the following terms and conditions and to grant the following rights 📜. this applies on their own behalf and on behalf of the organization they represent or are sponsored by (if any) when they submit 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 of it, is protected by copyright and other rights of authorship, the Contributor, each named co-Contributor, and the organization they represent or are 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. that covers copying, publishing, displaying, and distributing 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. that's to copy, publish, display, and distribute the RFC Editor Contribution irrevocably and in perpetuity. they also irrevocably and in perpetuity grant the rights listed below to those organizations, entities, and 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 to comment upon it. the license to such derivative works shall not grant the IETF Trust, the IETF, or any 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 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 for that reproduction, preserve the 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 one's short but it matters, so listen up 👑. this document specifies an RFC Editor (and, indirectly, IETF) administrative and publication procedure. it has no specific security implications 💜.

10. Acknowledgments 🫶

big thank-yous are owed to Bob Hinden and Craig Partridge, who suggested several improvements to the text in earlier versions of this document 🌷. also to Stewart Bryant, Scott Bradner, Brian Carpenter, Vint Cerf, Leslie Daigle, and Olaf Kolkman, who shared a bunch of useful ideas about the organization and content of later versions 🙌. we also appreciate the IETF and Scott Bradner, Editor, for the material extracted from BCP 78 [RFC3978] that's 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.

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.

Appendix A. IAB Members at the Time of Approval 🧚

these are the IAB members at the time this was approved 🌈:

• 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

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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology described in this document, or on whether any license under those rights might or might not be available. it also doesn't claim to have made any independent effort to find such rights 🔍. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 💜.

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr ✨.

the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💖.

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society 🎀.