RFC 9245

IETF Discussion List Charter

📅 published June 2022, from ietf

RFC 9245: IETF Discussion List Charter 💖

Okay bestie, let's talk about RFC 9245 🦋 It's titled IETF Discussion List Charter, and it's a Best Current Practice (that's BCP 45, so it's the official "this is how we do it now" label) ✨ Two authors wrote it: L. Eggert from NetApp and S. Harris. It came out in June 2022 📅 It's published by the Internet Engineering Task Force (IETF), with ISSN 2070-1721. The big drama is that it obsoletes RFC 3005 and updates RFC 3683 🌈 So if you're reading old stuff, this is the newer tea.

Abstract 💅

The IETF discussion list is basically the group chat for anything that doesn't have its own dedicated list yet 💬 It's how we push forward Internet tech by talking about technical, procedural, operational, and other topics, all in one place. It's the most general IETF list, so lots of topics fit, but some posts are a hard no 🙅‍♀️ This doc sets the charter for the IETF discussion list and explains what it's for.

This document obsoletes RFC 3005 and updates RFC 3683. 🫶

Status of This Memo 🌸

This memo documents 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, which is very important. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨ If you want more info on BCPs, check out Section 2 of RFC 7841.

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9245 🔗

Copyright (c) 2022 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 (https://trustee.ietf.org/license-info), as they stand on the date this document was published. Please read these carefully, bestie, because they explain your rights and restrictions for this doc. Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍

Table of Contents 📚

1.  Introduction
2.  Charter for the IETF Discussion List
3.  Moderation
4.  Security Considerations
5.  IANA Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

The IETF discussion list [IETF-DISCUSS] is where we push Internet technology forward by chatting about technical, procedural, operational, and other topics that don't have a dedicated list. It's the most general IETF list, so considerable latitude in topics is allowed 🫧 But there are posts and topics that just don't belong there. This document defines the charter for the IETF discussion list and explains its scope.

The IETF Note Well [NOTE-WELL] applies to discussions on the IETF discussion list and on all other IETF mailing lists 🤍 It requires conformance with the IETF Guidelines for Conduct [RFC7154] and the Anti-Harassment Policy [RFC7776], among others. Be nice, obviously 💖

This document obsoletes [RFC3005] 💅 It does that because it documents the use of other mailing lists for discussions that used to be in scope for the IETF discussion list. It also points to applicable policies, such as the Guidelines for Conduct [RFC7154] and the Anti-Harassment Policy [RFC7776], and it clarifies moderation procedures. It also updates part of Section 1 of [RFC3683], which copied the list of "inappropriate postings" from [RFC3005]. So the list in [RFC3683] is updated by the new list in Section 2 🌈

2. Charter for the IETF Discussion List 🦋

The IETF discussion list is meant for discussions that don't have a more appropriate list, like topics that don't fall within the scope of any working group, area, or other established list. When there's already a venue for a discussion, you should note that and move the discussion there 🫶

When no dedicated mailing list exists for a topic, it may be better to request that one be created [NON-WG-LISTS] rather than discuss it on the IETF discussion list 🌷 Once the new list exists, it may be announced on the IETF discussion list and on other related lists, such as area lists.

Appropriate postings to the IETF discussion list include:

  • Initial discussion of technical issues that could become IETF work, but where the appropriate mailing lists haven't been identified yet.
  • Questions and clarifications about practical aspects of IETF meetings. Most of these are better brought up on the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS] or on the attendee discussion list for a given IETF meeting, though.
  • Announcements of conferences, events, or activities that are sponsored or endorsed by the IETF, IRTF, IAB, or the Internet Society. The IETF announcement list [IETF-ANNOUNCE] is the preferred list for these 📣
  • Discussions of IETF direction, policy, and the standards process in general, when a more suitable list can't be identified. Some examples of more suitable lists are the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS], the IAB discussion list for architectural issues [ARCH-DISCUSS], a meeting attendees list, or a process-oriented WG list.

These topics used to be in scope for the IETF discussion list, but they have since moved to dedicated lists 🧚

  • Last Call discussions of documents now take place on the IETF Last Calls mailing list [LAST-CALLS].
  • Discussion of IETF administrative policies now takes place on the discussion list for IETF LLC administrative issues [ADMIN-DISCUSS].

Inappropriate postings include:

  • Advertising and other unsolicited bulk e-mail 🙅‍♀️
  • Discussion of subjects unrelated to IETF policy, meetings, activities, or technical topics
  • Uncivil commentary, regardless of the general subject, per the IETF Note Well [NOTE-WELL] 😤
  • Announcements of conferences, events, or activities that are not sponsored or endorsed by the IETF, IRTF, IAB, or the Internet Society.

3. Moderation 👑

The IETF Chair appoints _Moderators_ for the IETF discussion list. These used to be called the "sergeant-at-arms" 🛡️ Moderators are empowered to restrict posting by a person, or to an email thread, when the content is inappropriate and represents a pattern of abuse. They're encouraged to look at the overall nature of a person's postings and whether particular posts are typical or just an aberration. Context matters, bestie 🫶

Moderation of the IETF discussion list, including handling any appeals, is guided by the IETF discussion list charter in Section 2, along with the related guidance from Section 1 that applies to all mailing lists. The moderators are picked from within the community to moderate the community 🌈 The IESG and IAB are in the appeals chain for moderator decisions (more on that below), so the IETF Chair should not appoint a moderator who is serving in one of those roles. If a moderator gets selected for the IESG or IAB, they'll step down from the moderator team.

Apart from appointing moderators, the IETF Chair should stay out of the day-to-day operation and management of the moderator team. The moderator team will independently define, publish, and carry out their role. You can check out their current operating procedures [MOD-SOP] and abuse patterns [MOD-UPC]. If the moderator team needs help with a conflict, they should reach out to the IETF Chair in a timely manner 🙏

Here's the thing: a moderator serves at the discretion of the IETF Chair. Even if the IETF Chair isn't otherwise involved in running the moderator team, any moderator decision can be appealed to the IETF Chair, per [RFC2026]. Decisions made by the IETF Chair can be appealed to the IESG as a whole, again per [RFC2026] ⚖️

4. Security Considerations 💀

The usual security considerations [RFC3552] do not apply to this document. Honestly, low-drama vibes here 🙈

Potential abuse of the moderation process to suppress undesired opinions is counteracted by the availability of an appeals process, per Section 3. This one is serious, bestie. Appeals exist so moderation can't become a tool for silencing people 🚨

5. IANA Considerations 🎀

This document does not request any IANA actions. Nothing to register, nothing to update, no IANA homework 💅

6. References 📖

6.1. Normative References 🫶

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
           <https://www.rfc-editor.org/info/rfc2026>.

6.2. Informative References 📚

okay bestie, these are the extra-credit reads 🤓 they're not required to get the spec, but they give you the backstory on the lists, the rules, and the conduct stuff.

Acknowledgements ✨

okay so, Susan R. Harris wrote [RFC3005], which is the one this document replaces 🌷 and honestly she was a whole legend. Beyond all her technical work for the IETF, she wrote a bunch of foundational docs, like the original "IETF Guidelines for Conduct" [RFC3184] and the original "Tao of the IETF" [RFC3160]. 😭 Susan R. Harris passed away in early 2022, so this document is dedicated to her memory as a little thank-you for everything she gave us. 🕊️💖

Other people also helped out with this document, and they deserve the flowers too 💐:

  • Adrian Farrel 🌟
  • Barry Leiba 🌟
  • Ben Kaduk 🌟
  • Brian Carpenter 🌟
  • Carsten Bormann 🌟
  • Christian Huitema 🌟
  • Dhruv Dhody 🌟
  • Eric Rescorla 🌟
  • Eric Vyncke 🌟
  • Francesca Palombini 🌟
  • John Scudder 🌟
  • Lloyd Wood 🌟
  • Martin Thomson 🌟
  • Robert Wilton 🌟
  • Subramanian Moonesamy 🌟
  • Stephen Farrell 🌟

Authors' Addresses 🦋

Lars Eggert 💅 NetApp Stenbergintie 12 B FI-02700 Kauniainen Finland Email: lars@eggert.org URI: <https://eggert.org/>

Susan Harris 🎀

📦 where this page comes from