RFC 3932

The IESG and RFC Editor Documents: Procedures 🎀

Okay bestie, this is the title block 💅 It's RFC 3932, written by H. Alvestrand and dated October 2004. It's a Best Current Practice (BCP 92) in the Network Working Group. It updates RFC 3710 and RFC 2026, and the header doesn't list anything it obsoletes 🦋

Status of this Memo ✨

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. 🌸

Copyright Notice 🫶

Copyright (C) The Internet Society (2004).

Abstract 💜

This document describes the IESG's procedures for handling documents submitted for RFC publication via the RFC Editor, subsequent to the changes proposed by the IESG at the Seoul IETF, March 2004. It's giving "the process just got a glow-up" energy 🧚

This document updates procedures described in RFC 2026 and RFC 3710. 🔥

1. Introduction and History ✨

Okay so there are a bunch of different ways an RFC can get published. Some go through review in the Internet Engineering Task Force (IETF), and some get approval from the Internet Engineering Steering Group (IESG) 👑

• IETF Working Group (WG) to Standards Track: Includes WG consensus, review in the IETF, IETF Last Call, and IESG approval
• IETF WG to Experimental/Informational: Includes WG consensus, review in the IETF, and IESG approval
• Area Director (AD) sponsored to Standards Track: Includes review in the IETF, IETF Last Call, and IESG approval
• AD Sponsored Individual to Experimental/Informational: Includes some form of review in the IETF and IESG approval
• Documents for which special rules exist
• RFC Editor documents to Experimental/Informational

This memo is only about the IESG processing of that last category, so that's the only one we're focusing on 💖

Special rules apply to some documents, including documents from the Internet Architecture Board (IAB), April 1st RFCs, and republication of documents from other standards development organizations. The IESG and the RFC Editor keep a running dialogue, in consultation with the IAB, on these other documents and how they're classified, but they're outside the scope of this memo 🍓

For the last few years, the IESG has reviewed all RFC Editor documents (documents submitted by individuals to the RFC Editor for RFC publication) before publication. In 2003, this review was often a full-scale review of technical content, with the ADs trying to clear points with the authors, stimulate revisions of the documents, encourage the authors to contact appropriate working groups, and so on. It was a huge drain on the IESG's resources, and since this wasn't the highest priority task for IESG members, it often caused significant delays 😭

In March 2004, the IESG decided to make a major change to this review model. Under the new model, the IESG takes responsibility ONLY for checking for conflicts between the work of the IETF and the submitted documents. Soliciting technical review is the responsibility of the RFC Editor. If an individual IESG member chooses to review the technical content of a document and finds issues, that member communicates those issues to the RFC Editor, and they get treated the same way as comments on documents from other sources 🎀

Note: This document describes only the review process done by the IESG when the RFC Editor requests that review. There are many other interactions between document editors and the IESG. For instance, an AD may suggest that an author submit a document as input for work within the IETF rather than to the RFC Editor, or the IESG may suggest that a document submitted to the IETF is better suited for submission to the RFC Editor. But these interactions are not described in this memo 🙈

2. Background Material 🧚

The review of independent submissions by the IESG was prescribed by RFC 2026 [1] section 4.2.3. The procedure described in this document is compatible with that description ✨

RFC 3710 [4] section 5.2.2 describes the spring 2003 review process (even though the RFC was published in 2004). With the publication of this document, the procedure described in RFC 3710 is no longer relevant to documents submitted via the RFC Editor 💅

3. Detailed Description of IESG Review 🔥

The RFC Editor reviews submissions for suitability for publication as RFCs. Once the RFC Editor thinks a document may be suited for RFC publication, the RFC Editor asks the IESG to review the document for conflicts with the IETF standards process or work done in the IETF community 🦋

The review starts with a note from the RFC Editor. That note specifies the document name, the RFC Editor's belief about the document's present suitability for publication, and (if possible) the list of people who have reviewed the document for the RFC Editor 📝

The IESG can return five different responses. Any of them may come with an IESG note to be put on the document if the RFC Editor wants to publish it 💜

1. The IESG has not found any conflict between this document and IETF work.
2. The IESG thinks that this work is related to IETF work done in WG <X>, but this does not prevent publishing.
3. The IESG thinks that publication is harmful to the IETF work done in WG <X> and recommends not publishing the document at this time.
4. The IESG thinks that this document violates IETF procedures for <X> and should therefore not be published without IETF review and IESG approval.
5. The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval.

The last two responses are there for two different situations. The first is when a document tries to take actions (such as registering a new URI scheme) that require IETF consensus or IESG approval (as these terms are defined in RFC 2434 [2]). The second is when an IETF protocol is proposed to be changed or extended in an unanticipated way that may be harmful to the normal usage of the protocol, but the protocol documents don't explicitly say that this type of extension requires IETF review 🌈

If a document requires IETF review, the IESG will offer the author the chance to ask for publication as an AD-sponsored individual document. That path is subject to full IESG review, including possible assignment to a WG or rejection. Being redirected to the full IESG review path is not a guarantee that the IESG will accept the work item, or even that the IESG will give it any particular priority. It is a guarantee that the IESG will consider the document 🫶

The IESG will normally finish review within 4 weeks of the RFC Editor's notification. If there's a possible conflict, the IESG may contact a WG or a WG chair for an outside opinion on whether publishing the document is harmful to the work of the WG. And if there's a possible conflict with an IANA registration procedure, the IESG may contact the IANA expert for that registry ⭐

Note that if the IESG has not found any conflict between a submission and IETF work, then judging its technical merits, including considerations of possible harm to the Internet, becomes the responsibility of the RFC Editor. The IESG assumes that the RFC Editor, in agreement with the IAB, will manage mechanisms for additional technical review. Main character energy for the RFC Editor, honestly 👑

6. IAB Statement ✨

okay so the IAB is the body that signs off on the general policy the RFC Editor follows (see RFC 2850 [3]) 🎀. they looked at this proposal and they're totally on board with it 💅. they see it as an operational change that fits nicely with the roles of the IESG and the RFC Editor 🦋. the IAB is also keeping an eye on the organized discussions happening in the IETF about tweaking how documents get published (like the NEWTRK working group) 👀. and they get it: the process in this document, plus other general IETF publication processes, might need to change depending on what comes out of those conversations 🌸.

7. Security Considerations 🔐

no cap, this one is very chill 😌. the process change in this memo doesn't have any direct effect on the security of the Internet 🫶.

8. Acknowledgements 🌈

this doc is a product of the IESG, so every single member deserves a huge thank you 👑💖.

it was reviewed in the IETF, by the RFC Editor, and by the IAB, and the IAB wrote the text of section 6 ✍️. special shoutout to John Klensin, Keith Moore, Pete Resnick, Scott Bradner, Kurt Zeilenga, Eliot Lear, Paul Hoffman, Brian Carpenter, and everyone else in the IETF community who gave valuable feedback on the document 🧚💜.

9. References 📚

9.1. Normative Reference

• [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

9.2. Informative References

• [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [3] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
• [4] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.

Author's Address 🏠

Harald Alvestrand

EMail: harald@alvestrand.no

Full Copyright Statement ©️

Copyright (C) The Internet Society (2004).

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 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 IETF's procedures with respect to rights in IETF 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.