RFC 5742

RFC 5742: IESG Procedures for Handling of Independent and IRTF Stream Submissions 🎀

okay bestie, this is the title block tea ☕ 💅

• RFC number: 5742
• Series: BCP 92 (a Best Current Practice 🌸)
• Category: Best Current Practice
• Date: December 2009
• Authors: H. Alvestrand (Google) and R. Housley (Vigil Security) 👑
• Stream: Internet Engineering Task Force (IETF) 🦋
• ISSN: 2070-1721
• Obsoletes: RFC 3932 🙈
• Updates: RFC 2026 and RFC 3710 ✨

---

Abstract 🦋

okay so this doc explains how the IESG (the IETF's steering group) handles papers that come in for RFC publication from the Independent Submission and IRTF streams. it's giving process, but it matters 💅

it also updates the procedures in RFC 2026 and RFC 3710. so those older docs get a glow-up too ✨

---

Status of This Memo 🌈

this memo is an Internet Best Current Practice. 🎀

this document is a product of the Internet Engineering Task Force (IETF). it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on BCPs is in Section 2 of RFC 5741 📖

the current status of this document, any errata, and how to leave feedback can be found at http://www.rfc-editor.org/info/rfc5742. 🔗

---

Copyright Notice 🔒

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. please read these carefully, bestie, they spell out your rights and restrictions for this doc 🫶

if you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as described in the BSD License. ⚠️

---

1. Introduction and History 🌸

okay so RFC 4844 [N1] sets up four RFC streams. the review a document gets when it's submitted depends on which stream it's going to be published in. the four are:

• The IETF stream
• The IAB stream
• The IRTF stream
• The Independent Submission stream

the IETF is in charge of keeping up the Internet Standards Process. that covers the requirements for developing, reviewing, and approving Standards Track and BCP RFCs. those RFCs, plus any other IETF-generated Informational or Experimental docs, get reviewed by the right IETF bodies [N2] and published in the IETF stream 🧚

now here's the important part 👀 docs published in the other streams might not get any IETF review for things like security, congestion control, or messing up with protocols that are already out there. there's usually no attempt at IETF consensus or IESG approval. so the IETF disclaims, for non-IETF-stream docs, any knowledge of whether those RFCs are fit for any purpose. 💀

the IESG processing in this document is only about the last two categories, which are the Independent Submission stream and the IRTF stream, in that order [N1] 💖

after RFC 2026 [N2] was approved, and before RFC 3932 [I1] was published, the IESG reviewed every Independent Submission stream document before publication. this review was often a full-scale check of the technical content. the Area Directors (ADs) tried to clear points with the authors, push for revisions, encourage authors to contact the right working groups (WGs), and so on. it was a big drain on IESG resources. since it wasn't the top priority for IESG members, it often caused major delays 😭

in March 2004, the IESG made a big change to this review model. the IESG only takes responsibility for checking conflicts between the work of the IETF and the submitted documents. soliciting technical review became the responsibility of the RFC Editor. if an individual AD does review the technical content and finds issues, that AD tells the RFC Editor, and those issues get handled like comments from any other source 🍓

before 2006, IRTF documents were handled either as IAB submissions or as Independent Submissions via the RFC Editor. then the Internet Research Steering Group (IRSG) set up a review process for publishing RFCs from the IRTF stream [I2]. once those procedures are fully adopted, the IESG will only check for conflicts between the work of the IETF and the submitted documents. the results of that check get reported to the IRTF, and they may be copied to the RFC Editor as a courtesy 🌈

this document only covers the IESG's review process when the RFC Editor or the IRTF asks for that review. the RFC Editor requests review of Independent Submission stream docs, and the IRTF requests review of IRTF stream docs. there are lots of other interactions between document editors and the IESG. for example, an AD might suggest that an author submit a document as input for IETF work instead of sending it to the RFC Editor as an Independent Submission. or the IESG might suggest that a document submitted to the IETF is better suited to the Independent Submission stream via the RFC Editor. but those interactions aren't described in this memo 🙈

for the reader's convenience, this document also describes some actions taken by the RFC Editor, the IAB, and the IRSG. including those actions is not normative. they're there to explain the overall process around the normative IESG procedures in this document. no RFC Editor, IAB, or IRSG procedures are set by this document 💅

1.1. Changes since RFC 3932 ✨

RFC 3932 gave the procedures for reviewing Independent Submission stream submissions. once the IRSG defined procedures for the IRTF stream, it became clear that similar procedures apply to the IESG's review of IRTF stream documents 🦋

the IAB and the RFC Editor updated the formatting of the title page for all RFCs [N3]. with those changes, the upper left-hand corner of the title page shows which stream produced the RFC. that label replaces some info that used to appear in mandatory IESG notes on non-IETF-stream docs 🎀

the IESG may ask for an IESG note to be included in an Independent Submission or IRTF stream document. the note explains the specific relationship, if any, to IETF work. if there's a dispute about what the IESG note says, this document includes a dispute resolution process 🤝

---

2. Background Material 💖

the IESG's review of Independent Submissions was set out in RFC 2026 [N2], Section 4.2.3. the procedure in this document is compatible with that description 🫶

the procedures the IRTF developed for documents created by the Research Groups also include review by the IESG [I2] 🧠

the IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review process that was used in Spring 2003. the RFC wasn't published until 2004, though 😅 once RFC 3932 [I1] came out, the procedure in RFC 3710 stopped being relevant for documents submitted via the RFC Editor. this document further updates Section 5.2.2 of RFC 3710, and now it covers both the IRTF and the Independent Submission streams 👑

3. Detailed Description of IESG Review ✨

okay so the RFC Editor reviews Independent Submission stream submissions to see if they're suitable to be published as RFCs 📝 And like RFC 4846 [I3] says, the RFC Editor asks the IESG to check the docs for conflicts with the IETF standards process or with work the IETF community is already doing 👀

Same deal for docs meant for the IRTF stream. They get sent to the IESG for a conflict check too [I2] 🌸

The IESG review of these Independent Submission and IRTF stream docs ends in one of five possible conclusions, and any of them can come with a request to include an IESG note if the doc gets published 💅

1. The IESG has concluded that there is no conflict between this document and IETF work.
2. The IESG has concluded that this work is related to IETF work done in WG <X>, but this relationship does not prevent publishing.
3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG <X> and recommends not publishing the document at this time.
4. The IESG has concluded that this document violates IETF procedures for <Y> and should therefore not be published without IETF review and IESG approval.
5. The IESG has concluded 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 RFC headers and boilerplate [N3] are there to explain how the doc relates to the IETF standards process 🎀 In rare cases where that relationship is kinda unclear, the IESG may ask for an IESG note to clear things up. A note like that will probably point to related IETF RFCs 🔍 The dispute resolution process in Section 4 is there for when the IRSG or the RFC Editor has concerns about what's in a requested IESG note.

The last two responses are for two different situations. The first is when a doc tries to do something that needs IETF Review, Standards Action, or IESG Approval, like registering a new URI scheme. (Those terms are defined in RFC 5226 [I6].) The second is when someone proposes a change or extension to an IETF protocol that the original authors didn't see coming, which could mess with how the protocol normally gets used, but where the protocol docs don't explicitly say that this kind of extension needs IETF review 🧐

If a doc needs IETF review, the IESG will give the author the chance to ask for publication as an AD-sponsored individual document. That one gets full IETF review, which could mean getting assigned to a WG or getting rejected 😬 Getting redirected to the full IESG review path doesn't guarantee the IESG will accept the work item, or even give it any particular priority. What it does guarantee is that the IESG will consider the document 🫶

The IESG will normally finish its review within four weeks of being notified by the RFC Editor or the IRTF ⏰ If there's a possible conflict, the IESG may reach out to a WG or a WG Chair for an outside opinion on whether publishing the doc would harm that WG's work. If it's a possible conflict with an IANA registration procedure, they can ask the IANA expert for that registry instead 🧚

If the IESG doesn't find any conflict between an Independent Submission and IETF work, the RFC Editor is responsible for judging the technical merits of that submission, including any possible harm to the Internet 🌈 If the IESG doesn't find any conflict between an IRTF submission and IETF work, the IRSG is the one responsible for judging the technical merits, including possible harm to the Internet 💜

The RFC Editor, in agreement with the IAB, shall manage mechanisms for appropriate technical review of Independent Submissions. Likewise, the IRSG, in agreement with the IAB, shall manage mechanisms for appropriate technical review of IRTF submissions ✨

4. Dispute Resolution 🤝

Honestly, the IESG and the RFC Editor have been working really well together on publication recommendations and IESG notes 🥰 When questions have come up, they've been resolved quickly once everyone knows what the concerns are. But if a dispute ever does happen, a third party can help sort it out. So this dispute procedure has an informal dialogue phase, followed by an arbitration phase if the matter is still unresolved ⚖️

If the IESG requests an IESG note, and the IRSG or the RFC Editor plans to publish the document without it, then they must give the IESG a clear and concise description of their concerns before going ahead 📣 Proposing alternate IESG note text is highly encouraged, btw 💅

If the IESG doesn't want the document published without the requested IESG note, then the IESG must start an informal dialogue. That dialogue should not take more than six weeks. This window lets the IESG run an IETF Last Call on just the content of the requested IESG note (not the whole document) if it wants to see where the community stands 🗳️ At the end of the dialogue, the IESG can reaffirm the original IESG note, provide an alternate one, or withdraw the note entirely. And if an IESG note was requested, the IRSG or the RFC Editor must say whether they intend to include it 🙌

If the dialogue doesn't fix the IRSG or RFC Editor's concerns with the content of a requested IESG note, and they still plan to publish without it, then the IESG can formally ask the IAB to arbitrate 🏛️ The IAB isn't obligated to do arbitration and can decline the request. If they decline, the RFC Editor decides whether the IESG note gets included. If the IAB accepts, its review follows whatever procedures the IAB picks for itself. The IAB can direct that the note be included, direct that it be withdrawn, or leave the final call to the RFC Editor. Unlike the IAB reviews specified in RFC 4846 [I3], if the IAB directs the inclusion or withdrawal of the IESG note, that IAB decision is binding, not advisory 🔥

5. Examples of Cases Where Publication Is Harmful 🕵️‍♀️

This section gives a couple of examples of when delaying or stopping publication of a document might be the right move because it conflicts with IETF work. It's background material, not part of the procedure 📚

Rejected Alternative Bypass:

Say a WG is working on a solution to a problem, and a participant decides to ask for Independent Submission stream publication of a solution the WG already rejected 🙄 Publishing that doc would give the publishing party an RFC number before the WG is finished. It makes more sense to publish the WG product first, and publish the non-adopted document later with a clear disclaimer note saying that "the IETF technology for this function is X" 🎀

Example: Photuris (RFC 2522), which was published after IKE (RFC 2409).

Note: In general, the IESG has no problem with rejected alternatives being made available to the community. Those publications can be a valuable contribution to the technical literature 📖 However, it's necessary to avoid confusion with the alternatives adopted by the WG 🫠

Inappropriate Reuse of "free" Bits:

Back in 2003, a proposal for an experimental RFC was published that wanted to reuse the high bits of the "fragment offset" part of the IP header for a different purpose 😱 No IANA consideration says how these bits can be repurposed, but the standard defines a specific meaning for them. The IESG concluded that implementing this experiment risked causing hard-to-debug interoperability problems, so it recommended not publishing the document in the RFC series. The RFC Editor accepted that recommendation 💀

The RFC series is one of many available publication channels, and this document takes no position on which documents are appropriate for publication in the RFC Series. That's a question for the Internet community to talk through 🌍

6. IAB Statement 🏛️

The IAB is the body that approves the general policy the RFC Editor follows (see RFC 2850 [I4]), and it has reviewed this proposal. It supports the proposal as an operational change that fits with the respective roles of the IESG, IRTF, and RFC Editor 💖 The IAB keeps an eye on IETF discussions about possible changes to the IETF document publication processes. It also recognizes that the process described in this document, along with other general IETF publication processes, may need adjusting to line up with whatever comes out of those discussions 🦋

7. Security Considerations 🔐

The process change described in this memo has no direct bearing on the security of the Internet. Nothing dramatic here, bestie, but I still take security super seriously 🫡

8. Acknowledgements 🫶

RFC 3932 was a product of the IESG in October 2004. It was reviewed in the IETF, by the RFC Editor, and by the IAB. Huge thanks for developing RFC 3932 go to (in alphabetical order) Scott Bradner, Brian Carpenter, Paul Hoffman, John Klensin, Eliot Lear, Keith Moore, Pete Resnick, Kurt Zeilenga, and all the other IETF community participants who gave valuable feedback 🥹

This update to RFC 3932 was the product of the IESG in July and August of 2008. It was reviewed in the IETF, by the RFC Editor, by the IRSG, and by the IAB. Special thanks for developing this update go to (in alphabetical order) Jari Arkko, Ran Atkinson, Leslie Daigle, Lars Eggert, Aaron Falk, Sam Hartman, John Klensin, Olaf Kolkman, and Andy Malis 👑

9. References 📚

9.1. Normative Reference

[N1] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.

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

[N3] Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.

9.2. Informative References

[I1] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.

[I2] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, December 2009.

[I3] Klensin, J., Ed., and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, July 2007.

[I4] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.

[I5] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.

[I6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

Authors' Address 💌

Harald Alvestrand EMail: harald@alvestrand.no

Russell Housley EMail: housley@vigilsec.com