RFC 3934

📮 RFC 3934: Updates to RFC 2418 Regarding the Management of IETF Mailing Lists 💖

okay bestie, so the title block is giving: this is RFC 3934, written by Margaret Wasserman from ThingMagic and dated October 2004 🎀. It's a Best Current Practice (BCP 94), and it updates RFC 2418 🌸. It doesn't obsolete anything 🙈

---

Status of this Memo 🫶

this doc is an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 💅 distribution is unlimited, so share it with everyone 🌈

Copyright Notice ✨

Copyright (C) The Internet Society (2004).

Abstract 🔥

this is an update to RFC 2418 that gives WG chairs clear responsibility for managing WG mailing lists 👑 the big deal is that chairs get the power to temporarily suspend the mailing list posting privileges of disruptive people 🙅‍♀️

Table of Contents 🧚

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Specific Changes to RFC 2418 . . . . . . . . . . . . . . . . .  2
3.  Security Considerations  . . . . . . . . . . . . . . . . . . .  3
4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  3
5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  3
    5.1.  Normative References . . . . . . . . . . . . . . . . . .  3
    5.2.  Informative References . . . . . . . . . . . . . . . . .  3
6.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
7.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  5

---

1. Introduction 🦋

okay so the vibe check: RFC 2418 [RFC2418] gives WG chairs more power over face-to-face discussions than over mailing list discussions 😭 in person, the chair can say no to someone who is unprepared, covering inappropriate material, or, in the Chair's opinion, disrupting the WG process. the exact quote is "to refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material, or who, in the opinion of the Chair, is disrupting the WG process." 💅

but a chair can't suspend the mailing list posting privileges of someone who is doing the same disruptive thing on the list. and RFC 2418 literally requires full IESG approval for that action. main character energy? not really 💀

so this doc updates RFC 2418, section 3.2 🎀 it lets WG chairs temporarily suspend the posting privileges of disruptive individuals without IESG approval ✨

2. Specific Changes to RFC 2418 🌸

these paragraphs replace the last paragraph of RFC 2418, section 3.2 🫶

Just like face-to-face sessions, sometimes one or more people might act up on a mailing list in a way that the WG chair thinks is disruptive to the WG process 🙈 unless the behavior is so bad that it has to be stopped right away, the WG chair SHOULD first try to calm things down by messaging the person directly 🫶 if it keeps going, the WG chair SHOULD send at least one public warning on the WG mailing list 📢 as a last resort, and usually only after one or more explicit warnings and a chat with the responsible Area Director, the WG chair MAY suspend the disruptive person's mailing list posting privileges for no more than 30 days 🔥 even while posting is suspended, the person MUST NOT be stopped from receiving messages posted to the list 💌 and just like every other WG chair decision, any suspension of posting privileges can be appealed, as described in RFC 2026 [RFC2026] ⚖️

this mechanism is meant for a WG chair to suspend someone's posting privileges for a short time 🧚 it does NOT let chairs suspend someone's posting for longer than 30 days, no matter what kind or how bad the incident was 🙅‍♀️ but if the same person keeps being disruptive, that will be looked at separately and might lead to more warnings or suspensions 🔁 any other kind of mailing list control, including longer suspensions, MUST be done under other IETF-approved procedures 📋 BCP 83 [RFC3683] is one set of procedures that's already defined and accepted by the community ✨

3. Security Considerations 💀

this doc describes a change to the IETF process for managing mailing list discussions 🧐 it has no security considerations 🔒 (no drama here, the vibes are just process.)

4. Acknowledgements 🫶

this doc came out of a discussion on the MPOWR mailing list in December 2003 and January 2004 💬 the people who threw in ideas that shaped it were Harald Alvestrand, Dave Crocker, James Kempf, and John Klensin 👑 it was written with the xml2rfc tool described in RFC 2629 [RFC2629] 🛠️

5. References 📚

5.1. Normative References 🔥

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

[RFC2418]  Bradner, S., "IETF Working Group Guidelines and
           Procedures", BCP 25, RFC 2418, September 1998.

5.2. Informative References 🧚

[RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
           June 1999.

[RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
           Mailing Lists", BCP 83, RFC 3683, March 2004.

6. Author's Address 💌

Margaret Wasserman
ThingMagic
One Broadway, 14th Floor
Cambridge, MA  02142
USA

Phone: +1 617 758 4177
EMail: margaret@thingmagic.com
URI:   http://www.thingmagic.com/

7. Full Copyright Statement 🌈

Copyright (C) The Internet Society (2004).

this doc is subject to the rights, licenses, and restrictions in BCP 78, and at www.rfc-editor.org 🎀 except as set out there, the authors keep all their rights 💜

this document and the info in it 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 doesn't take a position on whether any Intellectual Property Rights or other rights that might be claimed for the technology in this document are valid or in scope, or whether any license under those rights is available 🤷‍♀️ it also doesn't claim to have done any independent search for such rights 🔍 info on ISOC's procedures for rights in ISOC Documents is in BCP 78 and BCP 79 📜

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 🔗

the IETF invites anyone interested to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed 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 💖