RFC 4845

RFC 4845: Process for Publication of IAB RFCs 🎀✨

okay bestie, let's get into this one 💅. It's an Informational RFC (so it's just giving info, not a standard 🫶), written by L. Daigle, Ed. for the Internet Architecture Board (IAB), and it came out in July 2007. It doesn't obsolete or update anything, and it's not a standard of any kind, so you can read it without any pressure 🌸.

Status of This Memo 🦋

This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited 💜.

Copyright Notice 🌈

Copyright (C) The IETF Trust (2007).

Abstract 💖

Sometimes the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This doc spells out how those documents get made, reviewed, and published in the RFC Series, so it's basically the rulebook 📖✨.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Review and Approval . . . . . . . . . . . . . . . . . . . . . . 2
3.  IAB RFC Publication Process . . . . . . . . . . . . . . . . . . 3
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 3
5.  IAB Members at the Time of Approval . . . . . . . . . . . . . . 4
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1. Introduction 🌸

Every so often the IAB has a reason to publish RFCs, and it's usually for one of these 3 reasons 🍓:

• documents that come out of the IAB thinking about an issue, which the IAB writes through a nominated editor.
• documents that report on IAB activities, like workshop reports, usually written by a nominated editor who's generally one of the people who took part in the activity 💅.
• documents that didn't come out of an IETF Working Group effort, but that the IAB decided would help the IETF community. These don't have to be written or revised by the IAB itself 🫶.

Most IAB-published docs end up as Informational RFCs (see [RFC2026]). In general, the IAB doesn't publish Standards-Track or Experimental RFCs 🙈. If the IAB ever publishes something as a Best Current Practice (BCP), that goes through the IETF standards stream approval process instead (see [RFC4844]) 👑.

2. Review and Approval ✨

A lot of the time the IAB publishes stuff to keep a permanent record of an IAB statement or position 📜. The IAB uses its internal discussions to polish the wording and technical content, and the doc only gets approved if, and only if, the IAB agrees on its substantive content 💖.

Sometimes it isn't right for the IAB to own technical correctness. For example, if the IAB sponsored a workshop where not everyone was an IAB member and/or not every IAB member was there, the IAB's approval of the workshop report only says that the report is a faithful account of what happened and that the topic is interesting to the community 🧚.

Docs where the IAB does take responsibility for technical correctness (the most common case) list the IAB as an author, with individuals listed as editors or text authors 💅. Other docs, like workshop reports, don't list the IAB as an author. That doesn't stop individual IAB members from being authors or editors though 🦋.

Generally, the intro text should make it obvious what role the IAB played in publishing and backing the text 🎀. If the IAB has big issues with any specific item in the doc, the doc can include a note explaining the problem 🔥.

3. IAB RFC Publication Process 🌈

Here's how the IAB gets its docs out as RFCs 💜:

1. The IAB decides the doc is an IAB document, as described in Section 1 ✨.
2. The IAB publishes an IAB draft (draft-iab-*). Comments on the draft get reviewed and might make it into later versions. The IAB can also send the doc to individuals or groups and ask them for comments if that makes sense 🌸.
3. If the doc is meant to be a BCP, it goes to the Internet Engineering Steering Group (IESG) with a sponsoring Area Director (AD), and follows the process in [SPONSOR] 👑.
4. If the doc is meant to be an Informational RFC, the rest of this process applies 🫶.
5. The chair of the IAB sends out an IETF-wide Call for Comment on the IETF Announce mailing list. The comment period is normally no shorter than four weeks ⏳.
6. Comments get considered for the doc. The IAB decides whether the doc is ready to publish based on those comments, or whether it needs another round of editing and, optionally, another call for input 💅.
7. The doc goes to the RFC Editor for publication as an IAB document Informational RFC 🎀.

4. Security Considerations 🔐

This document doesn't discuss any matters with particular security implications 🙈.

5. 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

6. References 📚

• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996.
• [RFC4844] Daigle, L., Ed., "The RFC Series and RFC Editor", RFC 4844, July 2007.
• [SPONSOR] Arkko, J., Ed., "Guidance on Area Director Sponsoring of Documents", ION, May 2007.

---

Authors' Addresses 💌

Leslie L. Daigle (editor) EMail: ledaigle@cisco.com, leslie@thinkingcat.com

(IAB) EMail: iab@iab.org URI: http://www.iab.org/

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. 🌈