Network Working Group E. Lear Internet-Draft R. Wilton Obsoletes: rfc3683 (if approved) Cisco Systems Updates: rfc9245, rfc3934 (if approved) B. Gondwana Intended status: Best Current Practice Fastmail Pty Ltd Expires: 21 December 2024 J. Levine Standcore LLC 19 June 2024 IETF Plenary List Management Procedures draft-lear-bcp83-replacement-00 Abstract This memo provides a procedure and authority to address inappropriate behavior on IETF plenary lists. It obsoletes RFC 3683 and updates RFC 9245. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Lear, et al. Expires 21 December 2024 [Page 1] Internet-Draft IETF Lists June 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Summary of changes . . . . . . . . . . . . . . . . . . . 3 1.3. Why shift this function from the community to the executive director? . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Mailing List Policy . . . . . . . . . . . . . . . . . . . . . 4 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. What is appropriate or inappropriate behavior? . . . . . 4 2.3. Initiating Complaints . . . . . . . . . . . . . . . . . . 4 2.4. Who is responsible for addressing inappropriate messages? . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. What actions may be taken? . . . . . . . . . . . . . . . 5 2.6. Community Notice . . . . . . . . . . . . . . . . . . . . 5 2.7. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.8. Review . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Handling of Spam, Phishing, and other automated messages . . 6 4. Informational Collection and Reporting . . . . . . . . . . . 6 5. LLC Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The charter for the IETF discussion list is layed out in [RFC9245]. Individuals are expected to behave at all times in a professional manner for the purposes of the organization, as specified in [RFC3935], and for the purposes of individual mailing lists. Thankfully the need to take action against individuals is relatively rare. Experience has shown that when the existing procedure is invoked, the procedure itself causes as many problems as it solves, including: Lear, et al. Expires 21 December 2024 [Page 2] Internet-Draft IETF Lists June 2024 * Community discussion drawing away from the fundamental mission of the organization; * Humiliation the individual who has behaved inappropriately; * The need for a committee draws scarce volunteer resources from other potentially more fruitful activities; * Consumption of IESG resources. 1.1. Goals For these reasons, a new approach that aligns with other professional bodies is specified. The goals of the approach address the problems above as follows: * Minimize inappropriate behavior. * Maximize appropriate participation in IETF activities. * Minimize volunteer resources necessary to address inappropriate behavior. * Allow for approaches that are tailored to each situation. * Limit humiliation of those who have offended. * Provide a right of appeal. * Provide for transparency. 1.2. Summary of changes The following changes are made to IETF policy: * [RFC3686] and all processes therein are obsoleted by the new process that vests authority in the executive director. * Only the moderation function in Section 3 of [RFC9245] is obsoleted. * Additional authority is given to the executive director to address other IETF mailing lists in limited circumstances. Thus [RFC3934] is updated accordingly. What is and is not acceptable behavior has not changed. Lear, et al. Expires 21 December 2024 [Page 3] Internet-Draft IETF Lists June 2024 1.3. Why shift this function from the community to the executive director? The previous policy required that a discussion take place within the community to ban an individual. Those discussions have proven to be long, meandering, emotional, and time consuming. The reason we have juries is so that the public needn't vote in a popularity contest about whether someone should be convicted. The executive director is in a position to address complaints and observe bad behavior outside the melee of any particular technical discussion, because they carry no agenda other than the aims of the organization. In addition, as a managerial arm of the IETF, the executive director has the capability to manage what are sometimes difficult personal situations. Finally, the executive director is in a position to engage and make decisions in an effective manner, without consuming inordinate amounts of community resources. 2. Mailing List Policy 2.1. Applicability This policy applies to all IETF plenary lists mentioned in [RFC9245]. In addition, certain aspects of this policy may be applied across all IETF lists, as stated below. 2.2. What is appropriate or inappropriate behavior? [RFC9245] describes both appropriate and inappropriate contributions to the IETF list, and lays out charters of other plenary lists. Any new plenary lists created shall contain a statement as to what the list is to be used for. Messages beyond that purpose are inappropriate, as are messages that violate our community standards as specified by [RFC7776], [RFC8716], and [BCP54]. 2.3. Initiating Complaints Complaints against individuals shall be transmitted to the executive director via a mailing list [TBD]. Complaints must not be sent to other IETF mailing lists. The executive director may also take action on their own initiative. It is beyond the scope of ANY mailing list to discuss the behavior of an individual, except for the purposes of reviewing this policy, in which case a separate mailing list shall be designated by the IESG for that purpose. Lear, et al. Expires 21 December 2024 [Page 4] Internet-Draft IETF Lists June 2024 2.4. Who is responsible for addressing inappropriate messages? The executive director of the IETF shall be responsible for addressing inappropriate messages. The executive director may delegate this function. The moderation function described in Section 3 of [RFC9245] is discontinued. The executive director may consult with members of the community, including but not limited to area directors, working group chairs, and IETF participants; in order to seek a good outcome. 2.5. What actions may be taken? The executive director may take any action they deem appropriate in a given circumstance, including but not limited to no action, advising, warning, moderating, rate-limiting, suspending, or banning individuals. In performing this function, the executive director should apply all appropriate processes specified by the IETF in relevant BCPs in an even-handed way, using the least amount of intervention necessary to satisfy the goals in Section 1. The executive director MAY, in consultations with the IESG, apply any action taken across all IETF mailing lists. However, posting rights limitations across all lists should be viewed as an absolute last resort. 2.6. Community Notice When the executive director takes an action in accordance with this policy, they shall inform the IESG by email. In the case of bans or suspensions, this notification shall be noted and minuted in the next IESG meeting. In cases where an individual is banned or suspended from any working group list, notice shall be given to either the impacted working group or to IETF-Announce. 2.7. Appeals Individuals may appeal the decisions taken by the executive director, as specified in Section 2.5. Appeals follow a fairly usual IETF appeals process and timeline, as follows. Any initial appeal should be made to the executive director, and if the appeallant is unhappy with the outcome of the appeal decision, they may escalate the complaint to the IESG, and finally the IAB, as described in [RFC2026]. Appeals must be made within one month of receiving initial notification of the moderation action, or subsequent appeal outcome. In taking any action, the executive director shall notify the offender of these rights. Lear, et al. Expires 21 December 2024 [Page 5] Internet-Draft IETF Lists June 2024 2.8. Review An individual who has been moderated, rate-limited, suspended, or banned from a list within the scope of this policy may apply to the executive director to restore normal posting rights after a period of twelve months, and every twelve months thereafter. At their sole discretion, the executive director may reinstate some or all posting priveleges to an individual. Such decisions are not subject to appeal. 3. Handling of Spam, Phishing, and other automated messages The executive director may take any action they deem appropriate to limit spam, phishing, and other such automated attacks. They shall inform the IETF community of the mechanisms in place to the extent that sensible operational security permits. 4. Informational Collection and Reporting The executive director shall collect and report aggregate statistics annually to the community about complaints received and their disposition. 5. LLC Considerations The IETF requests that, if requested by the executive director, sufficient resources be allocated for this purpose. 6. Privacy Considerations This policy attempts to limit exposure of the names of individuals accused of inappropriate behavior. However, the transparency needs of the organization demand that the community be informed of certain actions taken against individuals. This permits community oversight of the function without causing undue embarressment or humiliation. 7. Security Considerations This memo creates no new technical mechanisms and therefore there are no security considerations. 8. IANA Considerations [This section to be removed by RFC Editor.] No registries are requested. Lear, et al. Expires 21 December 2024 [Page 6] Internet-Draft IETF Lists June 2024 9. Acknowledgments The authors would like to thank Marshall Rose for having first addressed this difficult subject in our series, as well as all those who have served as moderators and ombudspeople. 10. Normative References [BCP54] Best Current Practice 54, . At the time of writing, this BCP comprises the following: Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54, RFC 7154, DOI 10.17487/RFC7154, March 2014, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, . [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, DOI 10.17487/RFC3934, October 2004, . [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, . [RFC7776] Resnick, P. and A. Farrel, "IETF Anti-Harassment Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March 2016, . [RFC8716] Resnick, P. and A. Farrel, "Update to the IETF Anti- Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC", BCP 25, RFC 8716, DOI 10.17487/RFC8716, February 2020, . [RFC9245] Eggert, L. and S. Harris, "IETF Discussion List Charter", BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022, . Lear, et al. Expires 21 December 2024 [Page 7] Internet-Draft IETF Lists June 2024 Appendix A. Changes from Earlier Versions [[This section to be removed by RFC Editor]] Authors' Addresses Eliot Lear Cisco Systems Richtistrasse 7 CH-8304 Wallisellen Switzerland Phone: +41 44 878 9200 Email: lear@lear.ch Robert Wilton Cisco Systems Email: rwilton@cisco.com Bron Gondwana Fastmail Pty Ltd Level 2, 114 William Street 3000 Australia Phone: +61 457 416 436 Email: brong@fastmailteam.com John Levine Standcore LLC Phone: +1 607 330 5711 Email: standards@standcore.com Lear, et al. Expires 21 December 2024 [Page 8]