<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby3.4.8)2.5.9) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-modpod-group-processes-16" category="bcp" consensus="true" submissionType="IETF" xml:lang="en" number="9945" obsoletes="3683, 3934" updates="2418, 9245" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.31.0 --> <link href="https://datatracker.ietf.org/doc/draft-ietf-modpod-group-processes-latest" rel="prev"/> <front><title>IETF<title abbrev="IETF Community Moderation">IETF Community Moderation</title> <seriesInfoname="Internet-Draft" value="draft-ietf-modpod-group-processes-16"/>name="RFC" value="9945"/> <seriesInfo name="BCP" value="245"/> <author initials="L." surname="Eggert" fullname="Lars Eggert" role="editor"> <organization>Mozilla</organization> <address> <postal> <street>Stenbergintie 12 B</street> <city>Kauniainen</city> <code>02700</code> <country>FI</country> </postal> <email>lars@eggert.org</email><uri><https://eggert.org/></uri><uri>https://eggert.org/</uri> </address> </author> <author initials="E." surname="Lear" fullname="Eliot Lear" role="editor"> <organization>Cisco Systems</organization> <address> <postal> <street>Richtistrasse 7</street> <city>Wallisellen</city> <code>8304</code> <country>Switzerland</country> </postal> <phone>+41 44 878 9200</phone> <email>lear@lear.ch</email> </address> </author> <date year="2026"month="February" day="09"/>month="February"/> <area>GEN</area> <workgroup>modpod</workgroup> <keyword>disruption</keyword> <keyword>moderation</keyword> <keyword>participation</keyword> <abstract> <?line73?>78?> <t>The IETF community will treat people with kindness and grace, but not endless patience.</t> <t>This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://larseggert.github.io/draft-ietf-modpod-group-processes/draft-ietf-modpod-group-processes.html"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-modpod-group-processes/"/>. </t> <t> Discussion of this document takes place on the mod-discuss Working Group mailing list (<eref target="mailto:mod-discuss@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/mod-discuss/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/mod-discuss/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes"/>.</t> </note></front> <middle> <?line85?>90?> <section anchor="introduction"> <name>Introduction</name> <t>This memo establishes a policy for the moderation of disruptive participation across the IETF's various public online contribution channels and discussion fora. It creates a moderator team to develop procedures and to facilitate their consistent application.</t> <t>This memo obsoletes and updates some prior IETF processes, summarized here. Background information is described in more detail in <xref target="motivation"/>.</t> <t>This memo makes the following changes to existing processes:</t> <ul spacing="normal"> <li> <t>Obsoletes <xref target="RFC3683"/> as the "posting rights" (PR) action it definesareis replaced by processes defined herein;</t> </li> <li> <t>Obsoletes <xref target="RFC3934"/> as it replaces working group moderation procedures;</t> </li> <li> <t>Obsoletes <xref section="3" sectionFormat="of" target="RFC9245"/> and the second paragraph of <xref section="4" sectionFormat="of" target="RFC9245"/>, as the IETF moderator teamreplacesdefined in this document subsumes the IETF discussion listmoderationmoderator team.</t> </li> <li> <t>Updates <xref section="6.1" sectionFormat="of" target="RFC2418"/>, because the moderator team will work together with working group chairs to moderate disruptive behavior.</t> </li> </ul> <t>The processes described in this memo are solely applicable to IETF activities, and not to other related organizations, such as the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), the RFC Series Working Group (RSWG), the RFC Series Approval Board (RSAB), or the Independent RFC Submission Stream, without their explicit agreement. These changes take effect when the procedures described in <xref target="prod"/> have been approved by the IESG.</t> <section anchor="terminology-note"> <name>Terminology Note</name><t>Below,<t>In this document, the term "administrator" refers to the people who are assigned by the IESG to manage a particular public participation channel or discussion forum. This memo uses the term "forum" to refer to any public IETF participation channel, such as a mailing list, chat group, or discussion in a collaborative tool such as GitHub or GitLab. For example, working group chairs are administrators of all the public fora that their working groups use, which typically includes mailing lists and chat groups, but might also include collaborative tools such as GitHub or GitLab.Another example of administrators are theThe "owners" of non-WG IETF mailinglists.</t>lists are another example of administrators.</t> </section> <section anchor="genphil"> <name>General Philosophy</name><t>This policy's<t>The cornerstone of this policy is that individuals are responsible for furthering the goals of the IETF as an organization <xref target="RFC3935"/> in a manner consistent with the policy laid out in <xref target="RFC7154"/>.</t> <t>Disagreement and diverse points of view within any standards organization are to beexpected,expected and are even healthy. The IETF is an open standards organization with a discussion-based rough consensus process, a non-normative description of which is in <xref target="RFC7282"/>. Engaged, respectful discussion that is within the scope of an IETF forum should therefore not be considered disruptive, nor should someone be considered disruptive solely because they are outside the rough consensus. However, when someone crosses the line into disruptive behavior,someaction must be taken in order to maintain decorum of the community.</t> <t>The moderation policy goals are as follows:</t> <ul spacing="normal"> <li> <t>Apply consistent, fair, and timely moderation of communication across all public online IETF participation channels and participation fora without regard to a participant's role in the IETF or previous technical contributions;</t> </li> <li><t>Appeals<t>Ensure that appeals are available to address disagreements about moderation actions;</t> </li> <li> <t>Balance transparency against both privacy of individuals involved and further disruption to the community;</t> </li> <li> <t>Allow moderation decisions to be reconsidered; and</t> </li> <li> <t>Provide the broadest possible latitude to all people doing moderation, so that they have the flexibility to address a broad range of individuals and circumstances.</t> </li> </ul> <t>Questions about the processes detailed below should be answeredthrough the lens ofwith theseaims.</t>goals in mind.</t> <t>Thegoalobjective is explicitly <strong>not</strong> punishment, but to maintain an open, welcoming, non-hostile environment in which all may participate on an equal footing, regardless of their role in the IETF or past technical contributions.</t> </section> </section> <section anchor="ietf-moderator-team"> <name>IETF Moderator Team</name> <t>This memo defines a consistent approach to moderating the IETF's various public online fora. A moderator team for the IETF will develop and maintain guidelines for moderation and will facilitate their consistent implementation and application as detailed below. These changes are intended to address the issues identified in the previous model (see <xreftarget="motive"/>target="motive"/>) and the principles described in the introduction.</t> <section anchor="composition"> <name>Composition</name> <t>The IESG appoints and recalls moderators. The moderator team initially consists of no fewer than five individuals. The moderator team may expand or contract based on operational experience. In selecting members, the IESG will take into account geographic coverage, expected and unexpected absences, and team diversity.</t> <t>Because the IESG and IAB are in the appeals chain for moderator team decisions (see <xref target="appeals"/>), the IESG must not appoint a moderator who is serving on the IESG or IAB. Individuals serving on other bodies to which the NomCom appoints members, such as the IETF Trust or the IETF LLC Board, as well as IETF LLC staff and contractors shall also be excluded from serving on the moderator team. If a moderatoris assumingassumes any such role, they shall step down from the moderator team soon after.</t> <section anchor="team-diversity"> <name>Team Diversity</name> <t>Due to the global nature of the IETF, the membership of this team should reflect a diversity of time zones and other participant characteristics that lets it operate effectively around the clock and throughout the year. Ideally, the moderators should be able to respond to issues within a few hours.</t> <t>Team diversityisalsoimportant to ensureimproves the likelihood that any participant experiencing or observing disruptive behavior can identify a moderator they feel comfortable contacting.</t> </section> </section> <section anchor="training"> <name>Training</name> <t>The IETF is committed to providing and/or funding training for administrators and moderators as necessary. The IESG will negotiate any required funding or resources with IETF Administration LLC <xref target="RFC8711"/>.</t> </section> </section> <section anchor="scope-and-responsibilities"> <name>Scope and Responsibilities</name> <t>This policy applies to all public online IETF fora, both present and future, including, but not limited to, mailing lists, chat groups, and discussions in other systems that the IETF or WGs have chosen to employ, such as GitHub repositories, wikis, or issue trackers.</t> <t>Different people have different moderation responsibilities:</t> <ul spacing="normal"> <li> <t><strong>Participants</strong> should always behave inathe manner discussed in <xref target="genphil"/>. They are also encouraged to report disruptive behavior directed at them or someone else to an administrator of the respective forum <strong>and</strong> the moderators.</t> </li> <li> <t><strong>Administrators</strong> are primarily responsible for managing their fora in accordance with procedures developed by the moderators and approved by the IESG. As such, they shall address reports of disruptive behavior in a timely fashion, apprising moderators of reports or actions taken. Administrators may amend or rescind actions, including those taken by members of the moderation team <strong>after</strong> they have consulted with that team. </t> <t> For a working group, chairs are by default the administrators. They may delegate this responsibility in the same vein as <xref section="6.4" sectionFormat="of"target="RFC2418"/>target="RFC2418"/>, but they must always accept, acknowledge, and keep track of complaints of disruptive behavior. Forum administrators should perform moderation in a way that obviates the need for moderator team involvement.</t> </li> <li> <t><strong>Moderators</strong> are responsible for establishing procedures to address moderation needs across all IETF fora, both present and future. They are a resource that the community can use to address disruptive behavior. The moderator team is responsible to the IESG. The IESG will create or designate a forum to facilitate discussion aboutmoderation,moderation and refer interested parties to that forum. </t> <t> Moderators may take actions when administrators do not respond to reports in a timely fashion. Their first action should generally be to attempt to contact and advise the relevant administrators. They should only take moderation actions when administrators are notresponsive,responsive or when someone disrupts multiple fora at the same time. Moderators should generally give WG chairs the opportunity to manage what may be difficult and contentious debates within their groups. Within the bounds of this principle, it is left to moderators' judgment to determine when they must act, with the understanding that some situations may require fast responses. Moderators must notify administrators of any actions they take. <xref target="appeals"/> discusses the handling of disagreements. </t> <t> Moderators are administrators for IETF plenary fora, currently including the IETF discussion andlast-callLast Call lists and any plenary chat sessions. They are also administrators for any forum that does not otherwise have an administrator. </t> <t> In order to scale the function, except for plenary fora as described above, moderators are not expected to always actively monitor all communications. In general, they will process reports from participants.</t> </li> <li> <t><strong>AreaDirectors</strong>directors</strong> are expected to resolve conflicts as described here and in <xref target="appeals"/>. The IESG will periodically evaluate the performance and needs of moderators, and may appoint and recall moderators as they deem appropriate. Apart from that, the IESG shall refrain from the day-to-day operation and management of the moderator team. The moderators may consult with the IESG when needed.</t> </li> </ul> <section anchor="actions-that-are-out-of-scope"> <name>Actions That Are Out of Scope</name> <t>Moderator actions are only permitted for the purposes of limiting disruptive communications in online IETF fora. All other actions are beyond the scope of this memo. Examples of actions that are out of scope include, but are not limited to, Datatracker account removal; restriction of in-person, virtual, or hybrid meeting participation; content removal or redaction; and moderation or policing of private or non-IETF communications. While the moderator team does not moderate non-public IETF mailing lists, the administrators of such lists can choose to adopt some of the procedures that the moderator team develops.</t> </section> <section anchor="unsolicited-bulk-messages"> <name>Unsolicited Bulk Messages</name> <t>Unsolicited bulk messages are considered disruptive and should be handled in a manner consistent with theIESG statement"IESG Statement onIETFSpam Control on IETF MailingLists<xref target="IESG-SPAM"/>,Lists" <xref target="IESG-SPAM"/> or its successors. Administrators and moderators may take similar actions in other fora (e.g., GitHub orInstant Messaging).instant messaging). Such actions require no additional reporting.</t> </section> </section> <section anchor="prod"> <name>Moderation Procedures and Transparency</name> <t>Within the bounds of the policies set herein, the moderator team shall develop and maintain procedures and criteria relating to moderation, including the moderator team's own operating procedures.</t> <t>Those procedures and criteria shall be developed with community input, be approved by the IESG prior to going into effect, and be made public. However, they need not be documented in the RFCseries.Series. This shall be the first task for the moderator team. Until those procedures and criteria are established, all previous processes referenced in <xref target="introduction"/> shall remain in effect.</t> <t>The intent of this memo is to provide the widest possible freedom of action to administrators and moderators, with the expectation that the minimal actions necessary will be taken. Those who are directed to stop disrupting a forum must do so immediately. Further disruptions may lead to further corrective actions.</t> <t>Examples of actions that could be taken include:</t> <ul spacing="normal"> <li> <t>Automatedrate limitingrate-limiting mechanisms;</t> </li> <li> <t>Review and approval of submissions/messages;</t> </li> <li> <t>A private or public admonishment;</t> </li> <li> <t>Temporary or indefinite suspension of participation privileges in one or more fora.</t> </li> </ul> <t>These are onlyexamples,examples and are not in any way prescriptive. Administrators and moderators are free to decide on these or other actions.</t> <t>All moderation actions that restrict participation privileges shall be immediately reported to those against whom those actions take effect, to relevant administrators, and to the moderator team for their review. They shall also be periodically reported to the IESG.</t> <t>Only moderation actions suspending participation privileges for longer than fourteen (14) days must be reported to the forum to which such an action applies, or in any event, at the request of the suspended person. If such an action applies to more than one forum, it should be communicated to the community in a manner decided by the IESG.</t> <t>Moderators will periodically provide an aggregate report to the community on actions taken under this policy.</t> <section anchor="appeals"> <name>Consistency and Conflict Resolution</name> <t>Administrators and moderators shall act in a manner consistent with this memo and the guidelines approved by the IESG. In cases of disagreement over a moderation decision, anyone may take the matter up with the responsibleArea Directorarea director for resolution, or with the IETFchairChair if a responsibleArea Directorarea director cannot be determined or is not assigned. If the disagreement cannot be resolved by theArea Director,area director, that person may then appeal to theIESG,IESG and subsequently to the IAB using the processes stated in Sections <xref target="RFC2026" section="6.5.1" sectionFormat="bare"/> and <xref target="RFC2026" section="6.5.4" sectionFormat="bare"/> of <xref target="RFC2026"/>.</t> </section> <section anchor="reinstatement"> <name>Reinstatement</name> <t>People and circumstances change. Individuals whose participation privileges have been indefinitely suspended from a forum may request reinstatement. Requests for reinstatement may be made no earlier than a year after the initialdecision,decision and then only annually afterward.</t> <t>Any such request must be directed to the entity who made the decision (e.g., moderator team, working group chairs, etc.) or their successors. That party may at their discretion reinstate someone, conditionally or unconditionally.</t> <t>To avoid denial-of-service attacks on IETF processes, decisions to not reinstate someone's participation privileges may not be appealed. Any reinstatement is a grace and not a right.</t> <t>A suspension of participation privileges imposed prior to this process shall be reconsidered only in accordance with the processes in place at the time of the suspension, even if the corresponding RFC has been formally obsoleted.</t> </section> </section> <section anchor="relationship-to-other-ietf-functions"> <name>Relationship tootherOther IETFfunctions</name>Functions</name> <section anchor="relation-to-the-ombudsteam"> <name>Relation to the Ombudsteam</name> <t>Administrators and moderators shall complement the efforts of the IETFombudsteamOmbudsteam <xref target="OT"/>, whose focus on anti-harassmentand operationshall remain unchanged. Administrators and moderators should always report suspected harassment. They should nonetheless take any necessary actions regarding disruptive behavior.</t> </section> <section anchor="relation-to-the-ietf-llc"> <name>Relation to the IETF LLC</name> <t>The Board of Directors of the IETF Administration LLC (IETF LLC) has fiduciary duty for the overall organization, which includes the duty to protect the organization from serious legal risk that may arise from the behavior of IETF participants.</t> <t>This protection may include the need for the IETF LLC to take emergency moderation actions. These emergency actions are expected to be taken only when the IETF LLC has received legal advice that such action isnecessary,necessary and therefore will be extremely rare in frequency. Some examples of where this might be necessary are:</t> <ul spacing="normal"> <li> <t>Someone making a credible threat of harm to other IETF participants.</t> </li> <li> <t>Someone using IETF mailing lists and/or websites to share content where publishing that content on IETF lists and/or websites brings serious legal risk to the IETF.</t> </li> <li> <t>Someone making a credible threat of legal action where any form of interaction with them on IETF mailing lists may have serious legal consequences for the IETF.</t> </li> </ul> <t>If any such action is taken, the IETF LLC should, except where limited by legal advice to the contrary, inform the IESG as soon as possible, providing full details of the subject of the action, nature of the action, reason for theactionaction, and the expected duration. The IETF LLC should also inform the moderator team and IETF community, except where it receives legal advice to the contrary.</t> <t>As such an action would be taken by the IETF LLC in order to protect the IETF according to its fiduciary duty, then it cannot allow that to be overridden by a decision of the moderator team or the IESG. The subject of any such action may request a review by the IETF LLCboard,Board, as documented in <xref section="4.7" sectionFormat="of" target="RFC8711"/>.</t> <t>Any such action taken by the IETF LLC under this section of this policy is not subject to the rest of this policy.</t> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>The usual security considerations <xref target="RFC3552"/> do not apply to this memo.</t> <t>There is the potential abuse of the moderation procedures by moderators, working group chairs, and potentially others that could lead to censorship of legitimate participation. This potential risk is mitigated in eight ways:</t> <ol spacing="normal" type="1"><li> <t><xref target="prod"/> requires the moderator team to first establish procedures that are intended to apply uniformly across the IETF.</t> </li> <li> <t><xref target="genphil"/> explicitly states that viewpoints outside the rough consensus are not in and of themselves disruptive.</t> </li> <li> <t><xref target="prod"/> provides transparency by requiring that moderation actions that restrict participation privileges be immediately reported to the affected person and to the moderation team, and periodically reported to the IESG.</t> </li> <li><t>That same section<t><xref target="prod"/> also requires that the community be informed in the case of suspensions lasting longer than 14 days.</t> </li> <li> <t><xref target="appeals"/> lays out an appeals process in the case of disagreements.</t> </li> <li> <t>If moderators find that the procedures themselves are leading to inappropriate moderation, <xref target="prod"/> allows them to update those procedures in consultation with thecommunity,community and with the approval of the IESG.</t> </li> <li> <t>If IETF participants believe that either the IESG or the IAB are not performing their respective oversight functions as described in this document, they may comment to the NomCom <xref target="BCP10"/> or the community at large.</t> </li> <li> <t>Finally, if it appears that these processes are not functioning properly, the policies stated in this memo may be amended. They are not set in stone.</t> </li> </ol> <t>Moderation actions are intended to limit the likelihood of disruptive behavior by a few IETF participantsfrom discouragingthat may discourage participation by other IETF participants.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t>No IANA actions are requested.</t> </section> <section anchor="acknowledgments"> <name>Acknowledgments</name><t>Thismemo is based on two individual Internet-Drafts, <eref target="https://datatracker.ietf.org/doc/draft-ecahc-moderation/">draft-ecahc-moderation</eref> authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley and Brian E. Carpenter, and <eref target="https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/">draft-lear-bcp83-replacement</eref> authored by Eliot Lear, Robert Wilton, Bron Gondwana and John R. Levine. Robert Sayre authored <eref target="https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/">draft-sayre-modpod-excellent</eref>, which also originated ideas reflected in this work. Pete Resnick provided the basis for how the moderators interact with list/forum leadership.</t> <t>These individuals contributed additional improvements:</t> <ul spacing="normal"> <li> <t>Alissa Cooper</t> </li> <li> <t>Brian Carpenter</t> </li> <li> <t>Chris Box</t> </li> <li> <t>Colin Perkins</t> </li> <li> <t>David Schinazi</t> </li> <li> <t>Eric Rescorla</t> </li> <li> <t>Jay Daley</t> </li> <li> <t>Joel Halpern</t> </li> <li> <t>John Klensin</t> </li> <li> <t>John Scudder</t> </li> <li> <t>Martin Thomson</t> </li> <li> <t>Melinda Shore</t> </li> <li> <t>Michael Richardson</t> </li> <li> <t>Nick Hilliard</t> </li> <li> <t>Pete Resnick</t> </li> <li> <t>Rich Salz</t> </li> <li> <t>Robert Sayre</t> </li> <li> <t>Russ Housley</t> </li> <li> <t>Sean Turner</t> </li> <li> <t>Simon Josefsson</t> </li> <li> <t>Stephen Farrell</t> </li> <li> <t>Ted Lemon</t> </li> <li> <t>Tim Bray</t> </li> </ul> <t>N.B., acknowledgment should not be taken as endorsement by the individuals named above.</t>document has no IANA actions.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC2418"> <front> <title>IETF Working Group Guidelines and Procedures</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="September" year="1998"/> <abstract> <t>This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="2418"/> <seriesInfo name="DOI" value="10.17487/RFC2418"/> </reference> <reference anchor="RFC3935"> <front> <title>A Mission Statement for the IETF</title> <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/> <date month="October" year="2004"/> <abstract> <t>This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="95"/> <seriesInfo name="RFC" value="3935"/> <seriesInfo name="DOI" value="10.17487/RFC3935"/> </reference> <reference anchor="RFC7154"> <front> <title>IETF Guidelines for Conduct</title> <author fullname="S. Moonesamy" initials="S." role="editor" surname="Moonesamy"/> <date month="March" year="2014"/> <abstract> <t>This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.</t> <t>This document is an updated version of the guidelines for conduct originally published in RFC 3184.</t> </abstract> </front> <seriesInfo name="BCP" value="54"/> <seriesInfo name="RFC" value="7154"/> <seriesInfo name="DOI" value="10.17487/RFC7154"/> </reference> <reference anchor="RFC8711"> <front> <title>Structure of the IETF Administrative Support Activity, Version 2.0</title> <author fullname="B. Haberman" initials="B." surname="Haberman"/> <author fullname="J. Hall" initials="J." surname="Hall"/> <author fullname="J. Livingood" initials="J." surname="Livingood"/> <date month="February" year="2020"/> <abstract> <t>The IETF Administrative Support Activity (IASA) was originally established in 2005. In the years since then, the needs of the IETF evolved in ways that required changes to its administrative structure. The purpose of this RFC is to document and describe the IETF Administrative Support Activity, version 2.0 (IASA 2.0). It defines the roles and responsibilities of the IETF Administration LLC Board (IETF LLC Board), the IETF Executive Director, and the Internet Society in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board.</t> <t>This document obsoletes RFC 4071, RFC 4333, and RFC 7691.</t> </abstract> </front> <seriesInfo name="BCP" value="101"/> <seriesInfo name="RFC" value="8711"/> <seriesInfo name="DOI" value="10.17487/RFC8711"/> </reference> <reference anchor="RFC2026"> <front> <title>The Internet Standards Process -- Revision 3</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="October" year="1996"/> <abstract> <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="9"/> <seriesInfo name="RFC" value="2026"/> <seriesInfo name="DOI" value="10.17487/RFC2026"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2418.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3935.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7154.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8711.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/> <referencegroup anchor="BCP10" target="https://www.rfc-editor.org/info/bcp10"><reference anchor="RFC8713" target="https://www.rfc-editor.org/info/rfc8713"> <front> <title>IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees</title> <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/> <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/> <author fullname="J. Livingood" initials="J." role="editor" surname="Livingood"/> <date month="February" year="2020"/> <abstract> <t>The process by which the members of the IAB and IESG, some Trustees of the IETF Trust, and some Directors of the IETF Administration LLC (IETF LLC) are selected, confirmed, and recalled is specified in this document. This document is based on RFC 7437. Only those updates required to reflect the changes introduced by IETF Administrative Support Activity (IASA) 2.0 have been included. Any other changes will be addressed in future documents.</t> <t>This document obsoletes RFC 7437 and RFC 8318.</t> </abstract> </front> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="8713"/> <seriesInfo name="DOI" value="10.17487/RFC8713"/> </reference> <reference anchor="RFC9389" target="https://www.rfc-editor.org/info/rfc9389"> <front> <title>Nominating Committee Eligibility</title> <author fullname="M. Duke" initials="M." surname="Duke"/> <date month="April" year="2023"/> <abstract> <t>The IETF Nominating Committee (NomCom) appoints candidates to several IETF leadership committees. RFC 8713 provides criteria for NomCom membership that attempt to ensure NomCom volunteers are members of the loosely defined IETF community, by requiring in-person attendance in three of the past five in-person meetings. In 2020 and 2021, the IETF had six consecutive fully online plenary meetings that drove rapid advancement in remote meeting technologies and procedures, including an experiment that included remote attendance for NomCom eligibility. This document updates RFC 8713 by defining a new set of eligibility criteria from first principles, with consideration to the increased salience of remote attendance. This document obsoletes RFCs 8788 and 8989.</t> </abstract> </front> <seriesInfo name="BCP" value="10"/> <seriesInfo name="RFC" value="9389"/> <seriesInfo name="DOI" value="10.17487/RFC9389"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8713.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9389.xml"/> </referencegroup><reference anchor="RFC7776"> <front> <title>IETF Anti-Harassment Procedures</title> <author fullname="P. Resnick" initials="P." surname="Resnick"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <date month="March" year="2016"/> <abstract> <t>IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.</t> <t>This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</t> </abstract> </front> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="7776"/> <seriesInfo name="DOI" value="10.17487/RFC7776"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7776.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IESG-SPAM" target="https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-spam-control-on-ietf-mailing-lists-20080414/"> <front> <title>IESG Statement on Spam Control on IETF Mailing Lists</title> <author> <organization>IESG</organization> </author> <date year="2008" month="April"day="18"/>day="14"/> </front> </reference> <reference anchor="AHP" target="https://www.ietf.org/about/groups/iesg/statements/anti-harassment-policy/"> <front> <title>IETF Anti-Harassment Policy</title> <author> <organization>IESG</organization> </author> <date year="2013" month="November" day="03"/> </front> </reference> <reference anchor="OT" target="https://www.ietf.org/contact/ombudsteam/"> <front> <title>Ombudsteam</title> <author> <organization/> </author> <date/> </front> </reference> <reference anchor="MODML" target="https://www.ietf.org/about/groups/iesg/statements/mailing-lists-moderation/"> <front> <title>IESG Guidance on the Moderation of IETF Working Group Mailing Lists</title> <author> <organization>IESG</organization> </author> <date year="2000" month="August" day="29"/> </front> </reference> <reference anchor="DP" target="https://www.ietf.org/about/groups/iesg/statements/disruptive-posting/"> <front> <title>IESG Statement on Disruptive Posting</title> <author> <organization>IESG</organization> </author> <date year="2006" month="February"day="16"/> </front> </reference> <reference anchor="RFC3683"> <front> <title>A Practice for Revoking Posting Rights to IETF Mailing Lists</title> <author fullname="M. Rose" initials="M." surname="Rose"/> <date month="March" year="2004"/> <abstract> <t>All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discussion. Notably, in a small number of cases, a participant has engaged in a "denial-of-service" attack to disrupt the consensus-driven process. Regrettably, as these bad faith attacks become more common, the IETF needs to establish a practice that reduces or eliminates these attacks. This memo recommends such a practice for use by the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="83"/> <seriesInfo name="RFC" value="3683"/> <seriesInfo name="DOI" value="10.17487/RFC3683"/> </reference> <reference anchor="RFC3934"> <front> <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title> <author fullname="M. Wasserman" initials="M." surname="Wasserman"/> <date month="October" year="2004"/> <abstract> <t>This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="25"/> <seriesInfo name="RFC" value="3934"/> <seriesInfo name="DOI" value="10.17487/RFC3934"/> </reference> <reference anchor="RFC9245"> <front> <title>IETF Discussion List Charter</title> <author fullname="L. Eggert" initials="L." surname="Eggert"/> <author fullname="S. Harris" initials="S." surname="Harris"/> <date month="June" year="2022"/> <abstract> <t>The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.</t> <t>This document obsoletes RFC 3005 and updates RFC 3683.</t> </abstract> </front> <seriesInfo name="BCP" value="45"/> <seriesInfo name="RFC" value="9245"/> <seriesInfo name="DOI" value="10.17487/RFC9245"/> </reference> <reference anchor="RFC7282"> <front> <title>On Consensus and Humming in the IETF</title> <author fullname="P. Resnick" initials="P." surname="Resnick"/> <date month="June" year="2014"/> <abstract> <t>The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.</t> <t>Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus.</t> </abstract> </front> <seriesInfo name="RFC" value="7282"/> <seriesInfo name="DOI" value="10.17487/RFC7282"/> </reference> <reference anchor="RFC3552"> <front> <title>Guidelines for Writing RFC Text on Security Considerations</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <author fullname="B. Korver" initials="B." surname="Korver"/> <date month="July" year="2003"/> <abstract> <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract>day="17"/> </front><seriesInfo name="BCP" value="72"/> <seriesInfo name="RFC" value="3552"/> <seriesInfo name="DOI" value="10.17487/RFC3552"/></reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3683.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3934.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9245.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7282.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/> </references> </references> <?line522?> <section anchor="change-history-of-this-i-d"> <name>Change History of this I-D</name> <aside> <t>RFC Editor: Please remove this appendix before publication.</t> </aside> <section anchor="since-draft-ietf-modpod-group-processes-11"> <name>Since draft-ietf-modpod-group-processes-11</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/238/">clarify when changes take effect</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/239">Refine security considerations</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/257/files">Multi group and moderator reversal</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/258">Last(?) bits from 2nd last call</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-10"> <name>Since draft-ietf-modpod-group-processes-10</name> <ul spacing="normal"> <li> <t>Many editorial suggestions received during WGLC.</t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/181">remove attendee mailing lists from moderator primary responsibility</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/149">Correct reference to appeals process.</eref> <eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/230">Also this.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/197">Clarify fora that are out of scope.</eref> <eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/181">Incl. attendees' lists.</eref> <eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/235">Also this.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/220">Clarify WG chairs are default admins but can delegate.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/231">Mod team size guidance.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/229">Chair immediately notify mods and affected parties.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/232">Add all of the available mitigations to risks of censorship.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/234">Clarify AD responsibilities.</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-09"> <name>Since draft-ietf-modpod-group-processes-09</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/147">Try to find another happy medium on power of moderators</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-08"> <name>Since draft-ietf-modpod-group-processes-08</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/issues/142">Address timeliness and exisgent circumstances</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/143">Make clear that moderators should use their judgment on timing</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-07"> <name>Since draft-ietf-modpod-group-processes-07</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/issues/134">Pete Resnick issues and similar</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/135">Includes changes to abstract, intro, tweaks to make relationship between admins/WG chairs clearer; makes roles clearer, moderation team → moderator team.</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modmod-group-processes-06"> <name>Since draft-ietf-modmod-group-processes-06</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/129">Normalize handling of moderation across all fora</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/132">Obsolete RFC 3934, explicit admin responsibility</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-05"> <name>Since draft-ietf-modpod-group-processes-05</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/126">New attempt to address moderation/WG interactions</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-04"> <name>Since draft-ietf-modpod-group-processes-04</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/120">Use plain English instead of BCP 14 language</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-03"> <name>Since draft-ietf-modpod-group-processes-03</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/121">Non-normative Examples of Disruptive Behavior</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-02"> <name>Since draft-ietf-modpod-group-processes-02</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/105">Say which RFCs this obsoletes and updates.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/116">Address issue 113</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/103">Rewrite philosophy</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/107">Reinstatement</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/109">Content removal is not moderation.</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-01"> <name>Since draft-ietf-modpod-group-processes-01</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/92">Update "Relation to the IETF LLC".</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/97">Point to relevant IRTF material.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/100">Add some text to explain the role of moderators.</eref></t> </li> </ul> </section> <section anchor="since-draft-ietf-modpod-group-processes-00"> <name>Since draft-ietf-modpod-group-processes-00</name> <ul spacing="normal"> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/80">Spelling fix</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/75">Initial attempt to balance what the moderator defines and what</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/76">Scope and relationship between WG chairs and moderators</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/88">Fix wording, spelling and capitalization.</eref></t> </li> <li> <t><eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/87">Editorial changes to acknowledgments.</eref></t> </li> </ul> </section> <section anchor="since-draft-ecahc-moderation-01"> <name>Since draft-ecahc-moderation-01</name> <ul spacing="normal"> <li> <t>Content taken from <eref target="https://datatracker.ietf.org/doc/draft-ecahc-moderation/01/">draft-ecahc-moderation-01</eref>. <eref target="https://github.com/larseggert/draft-ietf-modpod-group-processes/pull/65">Updated editors. Acknowledge authors of original pre-WG I-Ds.</eref></t> </li> </ul> </section> </section>542?> <section anchor="motivation"> <name>Motivation</name> <t><xref target="introduction"/>summarizedsummarizes the process changes introduced by this memo. This appendix discusses the background that led to them.</t> <section anchor="background"> <name>Background</name> <t>The IETF community has defined general guidelines for personal interactions in the IETF <xreftarget="RFC7154"/>, and thetarget="RFC7154"/>. The IESG has defined an anti-harassment policy for the IETF <xref target="AHP"/> for which the IETF community has defined anti-harassment procedures <xref target="RFC7776"/>, empowering anombudsteamOmbudsteam <xref target="OT"/> to take necessary action.</t> <t>Dealing with <em>disruptive</em> behavior, however, is not part of the role of theombudsteam.Ombudsteam. <xref target="RFC2418"/> tasks the chairs of each IETF working group with moderating their group's in-person meetings while <xref target="RFC3934"/>providedprovides chairs a procedure to help manage mailing lists. An IESG statement <xref target="MODML"/>describeddescribes additional guidance to working group chairs about how—-- but not when—-- to moderate their lists.</t> <t>For IETF mailing lists not associated with a working group, another IESG statement <xref target="DP"/> clarifies that the IESG tasks list administrators with moderation. And the IETF list for general discussions has, mostly for historic reasons, a team of moderators that are not list administrators and operate by a different set of processes <xref target="RFC9245"/>.</t> <t>Note that the term "moderation" can refer both to <em>preemptive</em> moderation, where administrators review attempted participation before it occurs (such as reviewing messages to a mailing list), and <em>reactive</em> moderation, where administrators intervene after disruptive participation has occurred.TheHistorically, the IETFhistoricallyhas mainly practiced reactive moderation,with a spectrumemploying actions ranging from gentle reminders on- and off-list, all the way to suspension of posting rights and other ways of participating or communicating. It is up to the moderators and administrators to decide which mix of preemptive and reactive moderation to employ as part of their procedures.</t> <t>In addition, <xref target="RFC3683"/> defines a process for revoking an individual's posting rights to IETF mailing lists following a communitylast-callLast Call of a "posting rights" action (PR-action) proposed by the IESG, often in response to complaints from the community.</t> <t>Experience and community input suggests that an evolution of the existing processes is necessary.</t> </section> <section anchor="motive"> <name>Problems with the Previous Approach</name> <t>The previous approach to moderation of disruptive participation through chairs, list administrators, and moderator teams, combined with the IESG-led process of PR-actions, has proven to be less than ideal:</t> <ul spacing="normal"> <li> <t>The IETF community has not been able to agree on a common definition of disruptive behavior. Therefore, chairs and list administrators apply individually different criteria when making decisions, and participants have different expectations for when PR-actions are warranted.</t> </li> <li> <t>The moderation process that chairs and list administrators need to follow <xref target="RFC3934"/> is slow and cumbersome, which makes it ill-suited to situations that escalate quickly. It also assumes that the originator of disruptive behavior is a misguided participant who can be reasoned with and who will change their ways.</t> </li> <li> <t>Chairs and list administrators may only enact moderation actions for their single list, which is ill-suited when a pattern of disruptive behavior spans multiple lists. Also, chairs and list administrators may not be fully aware of disruptive behavior that spans multiple lists, due to not being subscribed to some of them.</t> </li> <li> <t>PR-actions, which can address disruptive behavior across several lists, arecumbersome andcumbersome, slow, and inconsistent. This has led to a situation where PR-actions are rarely used, and when they are used, they are perceived as very heavy-handed.</t> </li> <li> <t>For a given mailing list, participants may not feel comfortable reporting disruptive behavior to a chair or list administrator, for various reasons. For mailing lists not associated with working groups, list administrators are not even publicly identified--- they can only be contacted through an anonymous alias address. This exacerbates the problem, because participants may not be comfortable reporting disruptive behavior to an anonymous party.</t> </li> <li><t>The IETF offers participation not<t>Moderation processes have been defined for onlythrough in-person meetings and mailing lists, which are thetwo channels of participationfor which moderation processes are currently defined.in the IETF: in-person meetings and mailing lists. However, IETF businessalsonow happens in a number of fora (e.g., chat groups, remote meeting participation systems, virtual meetings, wikis,GitHub repositories,andmore. HowGitHub repositories). Procedures for moderating disruptive behavioris moderatedin these foraisare currently undefined.</t> </li> </ul> </section> </section> <section anchor="examples"> <name>Non-Normative Examples of Disruptive Behavior</name> <t>The list below describes some types of disruptive behavior, but it is non-exhaustive.</t> <ul spacing="normal"> <li> <t>Discussion of subjects unrelated to a forum's charter or scope;</t> </li> <li> <t>Uncivil commentary, regardless of the general subject;</t> </li> <li> <t>Messages announcing conferences, events, or activities that are not sponsored or endorsed by the Internet Society or IETF, unless posted with prior approval of list administrators;</t> </li> <li> <t>Repeatedly arguing counter to a WG charter that has been approved by the IESG; and</t> </li> <li> <t>"Sealioning", where a participant makes incessant requests for evidence or data, even while remaining superficially polite.</t> </li> </ul> <t>These items are examples. Moderators and administrators may take moderation actions for many other cases.</t> <t>The moderator team's task consists of subjective judgment calls. Behaviors not listed here might require moderation, and it is not possible to write a complete list of all such behaviors.</t> </section> <section anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>This memo is based on two individual Internet-Drafts, <eref target="https://datatracker.ietf.org/doc/draft-ecahc-moderation/">draft-ecahc-moderation</eref> authored by <contact fullname="Lars Eggert"/>, <contact fullname="Alissa Cooper"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Russ Housley"/>, and <contact fullname="Brian E. Carpenter"/>, and <eref target="https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/">draft-lear-bcp83-replacement</eref> authored by <contact fullname="Eliot Lear"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Bron Gondwana"/>, and <contact fullname="John R. Levine"/>. <contact fullname="Robert Sayre"/> authored <eref target="https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/">draft-sayre-modpod-excellent</eref>, which also originated ideas reflected in this work. <contact fullname="Pete Resnick"/> provided the basis for how the moderators interact with list/forum leadership.</t> <t>These individuals contributed additional improvements:</t> <ul spacing="normal"> <li> <t><contact fullname="Alissa Cooper"/></t> </li> <li> <t><contact fullname="Brian Carpenter"/></t> </li> <li> <t><contact fullname="Chris Box"/></t> </li> <li> <t><contact fullname="Colin Perkins"/></t> </li> <li> <t><contact fullname="David Schinazi"/></t> </li> <li> <t><contact fullname="Deb Cooley"/></t> </li> <li> <t><contact fullname="Dhruv Dhody"/></t> </li> <li> <t><contact fullname="Eric Rescorla"/></t> </li> <li> <t><contact fullname="Éric Vyncke"/></t> </li> <li> <t><contact fullname="Erik Kline"/></t> </li> <li> <t><contact fullname="Harald Alvestrand"/></t> </li> <li> <t><contact fullname="Jay Daley"/></t> </li> <li> <t><contact fullname="Joel Halpern"/></t> </li> <li> <t><contact fullname="John Klensin"/></t> </li> <li> <t><contact fullname="John Scudder"/></t> </li> <li> <t><contact fullname="Lisa Dusseault"/></t> </li> <li> <t><contact fullname="Martin Thomson"/></t> </li> <li> <t><contact fullname="Melinda Shore"/></t> </li> <li> <t><contact fullname="Michael Richardson"/></t> </li> <li> <t><contact fullname="Mike Bishop"/></t> </li> <li> <t><contact fullname="Mohamed Boucadair"/></t> </li> <li> <t><contact fullname="Murray Kucherawy"/></t> </li> <li> <t><contact fullname="Nick Hilliard"/></t> </li> <li> <t><contact fullname="Orie Steele"/></t> </li> <li> <t><contact fullname="Paul Hoffman"/></t> </li> <li> <t><contact fullname="Paul Wouters"/></t> </li> <li> <t><contact fullname="Pete Resnick"/></t> </li> <li> <t><contact fullname="Rich Salz"/></t> </li> <li> <t><contact fullname="Robert Sayre"/></t> </li> <li> <t><contact fullname="Robert Sparks"/></t> </li> <li> <t><contact fullname="Roman Danyliw"/></t> </li> <li> <t><contact fullname="Russ Housley"/></t> </li> <li> <t><contact fullname="Sean Turner"/></t> </li> <li> <t><contact fullname="Simon Josefsson"/></t> </li> <li> <t><contact fullname="Stephen Farrell"/></t> </li> <li> <t><contact fullname="Ted Lemon"/></t> </li> <li> <t><contact fullname="Tim Bray"/></t> </li> </ul> <t>N.B., acknowledgment should not be taken as endorsement by the individuals named above.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA7V9W5MTSZLue/yKGHho4EgqCopL02uzU1ybWehmqWrjYWwf UsqQlEsqU5OXKtQYZvu0P+DY+YX7S45/7h6RESkVNLbV8zBNScoIDw+/33I6 nZqu6Er3xN54/eL8pX1WbzZ9VXQ7+7bOXZN1RV3dMIusc6u62T2x88XWmLxe VNmGnsmbbNlNC9ctp5s639b5dNXU/Xa6beqFa1vXTo8fmrafb4q2pYW63ZYe wj6m6jdz1zwxOa38xCzqqnVV27dPbNf0zlw8sfdNPW/r0nWOPrz/8PH9ib3/ 4/0T02/xCH127+T48cT+eO/kgblwVU+rWPrfJivKJ5aAmeZFu+jb9m+AblY3 K/56VXTrfv7EllnTutXKNd3RN8/AD5bYtHti1123bZ8cHQ0LzGTNWVF/e6lv /2K27jalMVnfrWtCj5ny7oLtN7SnfcGb8qdNjXtzedHVDX9Ap3xC9/Z7UZYZ f9B2jXME9VnnKkL3qqi6wtnje/Ypf72ge35i/y2jC8+KylXyId07UcPde4/u 3r2hn/RVh8t/+Zr/doJkoOBvigOP374pnth/8Ugavjz6a3KSF2VRd/aNy5qv HOQZXWBtz3Zt5zZtcpz3xWLdFfRXRiizj2KwH9+/e3IjOtyHrCyL1pVlOJ2e 5eyy6H53TZlVOX+xXdcVFvg/J8f25MQ+fvSYaMtjwJ+YAP4b/m+2WBtT1c2G +OOCKM8U1XL4yxKJn72anr07fStEqRyGT+kqiJI2rupsXdmzbbYhliOI6hJ/ Mwu+pb2KamXf0Anl3MwklqB5PL17Mj1+zB96ErHyv6kgDXvInlmzchHB0hoZ IWzx0TUzzxJHxMhHrQeIyLJdyf8Nn9XVtCUgpwsBEn8L9QqQ0xJATgHa3ZPj kyPa+vTnd6NT05lOifCmP2e4MD77u7osFrvkcMf3p8fH07v3Dx3um6e7vLwc TpXN6747YsZqj3Ce4YztUQZI1gGS6ZYhAeC/nidw/7qZ9znRXraJwFxmZeu+ DQGwlS26ozqsgQ3e/vr87Zt9injVF3lWLRwIoFu7SPDaeino+1A3H0ESr3Cm rxHI3SnRyL0f/2Qcppe/CfDikM/Htz+m+edF2/RbcApRQdvROukRHk7v3oPa +HOPkAcoiAIYiiMSttOpzeaQK4vOmHO6C8b+IujES5KspKFc1tmtq7elo0+6 taW7ySsS35aEiV3R025i531nKxJyrspLfLUlDDm65RkWLlq7cZvaBhVn3798 1rKa4zWg6Sb8r6KzqvHkJ9B6/AUrPlJJ2ZxuYQ1yyKzQsiVRxIS0SQhpOLHZ Zk1XLIotf2eyRVMTgJ0e94fWXmRNUfcEc0+LLyzzfkEHwkqLdVZVrpSzqo7F 57RpNjOv6cAeJgJ51WcNqbyibA2AigDC05n/APASj8ysPV8TavFvQXXuLlxZ b21mWtfhENEKrDLzvnECyjJbEFHignGSogHULdEnqK7Y0FXh3uVJ3JmhcxSN PJrlm6JidUKQtDMmg02R070Zc9O+huDL+wXjKrq7+Jx/GurrihjNfecNLECg gMqk+LVdHTA6wh598xUEmmy7JWgY5ivoF4t4Qm3rjaMNCtqW+ScYNxPb9psN nfB3l9u1a4gZnpJGAouC1L0OpbPQBrlrF3Rmhy8In42jTzoiJfz5+fOmJnTy b798SUDaZB+dYHRZl2V9Cc4Axlb4lG7tU8HcPgAFI8v+Gg7y+fO/EqOBE798 sZmsdENFhG2K1bprb9hb797fttlCQO0IsCXdEkRxRmA2bluSCMjtfDfsor+R YxfVT4f2JKaXPWlJXaS1lyr6WY5FdEWbDXc4Xu7MCWz3QX1YG9ICa+Oq6UCt o8vNSSY1GYmr7Zp+RusNz52kz008Ikb0FICk79jqocuOCBLqIeYE5nGC9Del k2G/h7Nj7PgX2hECDjvO3SLrW3doW4gG2g6YoSslBUA4FUGcIktZnG5dF3Ax J1raYp1dEJXORNbHdxWRXhdIC5cLHJc7qwwxJw1Ay7NHA3K4KEjItyK5Ifzp u5qhaxwciBzqK6uK3xkfzA6LNeHWsACoOtdUJObeu5ZMTPriPGs/2pd1Q6bB rdfvz1/enqQ/PKUfFR2hkEjAPq1J1NLvTp/qzwiX9sw1BM/IfLj1/uzDq9sT O/rR6ZYQcJGVfqX3Z7yUCrTXVe62pMsgTvmh4NSRdid5s5nwDZDGVenhPgFD RMlEYY6F7wxYphsN3Eicat1ySQewl2snxk8kl8ItGOZ4+iYnEqYrc3Rz9POM ARY+Ewl69oqu8uZNe+4akuh1Wa929pe6IzH+lITepRyZkLexNxKZf4PuZ+mE VBgI1e3r2uDOyVQsVlW6EVNVVmUrB+HPQr0nh8jL7VTMq8Sm2x/J65503iC6 +lYll4DI398wtBFDhx2zaud3EMkab+MVQyArKFg1FcGKE8DRCW9MRrAQhjMS +OQ3zuuG3RjajnwSv9Krovu5n9NDhv71JpvPQJd0xxk068TznUn4jlGXqFbw eAYLCjiWY0Bp0d+ZJ5uEg1tDKKHV1+Tv2W63JY4rifmKalH2RB3J6UQFDSds xQTbQGIbstpr/9iBY7b757T+nKeVcLCe1eAI6aFwTtYS9WVFRHQDp6zIT/rw Si4pgVII9JWjXxKrvVsXZd3W2/XOfr65ctWW/v6i2kwsCjIJFnWDdTvyT6EX GVlkcJKwyfusbFXntFuoawgkQqlZ9g2gxrYAbVXjhwSXtzSYOqpEHBGL/UW0 EEl8wwSxAT0llhRLWb4+sXfKrCCh1neilPH8o+MHJ6ySyc4PrK+mygUdA48W ZIEDmovCXfKS2I1ImyyqKifh0yaAMQ8S8c8dhApJC5eLhMXnZM5UpFOzslvv ZoPJXsjxSGJdsaicJIt4YDrPWuJxop3VeghIea1AO/KlBqdfxdPW23hCpLQv YwK689G9x/eAiRfVisQEwYxLIvCXfRmzntxn6/HA6nlBkDOzaEiARYFpSbyW rMBJIMAggoqZO7kfUnAuj/TbBPEJq4/AIgP5XPVjr9Yipbtj9NLV4tesUBgz NmBmZn6uLwn9zUSkt9+DTVoVZDBeiZRgdw57ebU7EUNRzahN3/JhoBVYHtVN LkKP+Ics96IyOVkthAdPx8EtU/0d+wZCnUL2IsLVHBRzj3QdnXag6wlZv0Uj VNUVG6AiteB1r4U6L2K2Q5SJGCNjQi31q8WyCKj0K0g/WDKqORu3guqFoB9+ WHUkAxAhs0odvAXd7bZxF+wrkAmwBmwwimJPgc1COqoLWLggUeSNlizPGzim ecSn9DM4zYmjtghLPc1KjlOQ4Ktago/cWaKSFV0Nro7EJIz+i4w+JIzFEqqo LuoSmpodNRFNBKunCTBBnV4pQ477ikGh+y/AMq1Kg8YNxPwT1qaH3pFJQJ/w avOmzohLyVen22LRSEZY0UEH4Py4PVH0eQ1BOewEyiT4vFraidHBPkVJDsQc ftIuxmEme9kGls3o9PAKoJmKZtFvIIxInBDF/ntPkPFhBOWx9Qk3B+YGjBbP wnRewvolM263Fl5kFiNmNMIRxLhZsWmVHUD8kCveECOavnOHJMadO0S0pL7W GyZ8KMmIybzYJKZ2JV0HIQaSpJqu4QIRrlx1UTR1xVKdfi5iD7jcZLuIujma RWu5fxIOiM7rjlcSCueAiMBMKv8gbWdtN9B1StUz9so5Uhr8gnOE6SIvUD0y NmqC8mKDMYMpETwCVZDmq943O9b2dOyGeF+frf80XEH3HRC66okeS4bmQAyE nxtcb/Ot2AXrvcEbh2BL6WVsZYPvCRKY7nlMsoCcDHiiQlvAqi+WhVjaYoWr aAG0pXe3XeRBEqdXdNHlvrfEAj9ETMTeeVZviAcLH0JRE5rOIaYAFiVmJipq ByS3s1iqe6ST4dUVbAUqjloxt+zSXUJd0KntElom4sCDC4FciTWwdd0IgSHq J0ZAzUwg10TkB7Oj0ejda9J0roTfCpHhkMVqJ4NbIBFCeDZQe+QUcsLBrlzN jjZH00hnkkEwCdaMBE+q4c95i73EjzQMrdhOouueRp6x4JEeJ79Pr5o/z1Tq wxSvYrrT45tBlt5qnaMb1ie+fLkdnYaVMqwMvaokpETuEeRL65oL4KKuhucQ +Tl9OoPXGJTA8DsjFvW8zgsJyqiBT0//Um+IVgbKCAj2BnpguPMGsCkLvnnz TNxWjlSQ5CrxX3xKAne5FAGsVwyTvV0TCYlXwFYlOwakmhrae3SecYjy9TKO WxoYmsRFGw7AwoQFnJBoE9EcvBNB4bakZS4r2WJ/XdPWYOYleX7MMTdZotnn /trJnO6d15Krsp4TVVYZO/6RVS83pzhbF1v5Dj4DbyGKhGxHkC/bvro6/47M Hvt7XWksT64oMkLgPAJ9xAikCBbqh5Su43CVcIt352ldxEgkrMd6vawXH4Wa RXVpnMDukEyzr3MHlp6kiGlj1SdGixE/hwWZCi/vPkAAWPp9w/ov4Rn2BtgD JCnUkAZmjQcjFjZRtYuPiZCmEIA5YLLaBYkXFZe7NH6Ny146B121WWIXgtho HohW08BEQ+yItRNPBVZP0XUin7dswAg55Ue08pKQyGpKn2X/buyCQuEMeCPa rxysiazZIcAQySZTuRXJctwVTt6Qfi5gUvhdasSqWkLjQnGr+bthP8hwcJY4 OY8fHR+zu3fTnrHXAlDee28UWo14PPFoRX0J4w8WdGI/Q+FOvEVJykwcSHJq QfATdeRhT4QsS1kQBhmBk9TfniQhAZOGzNlZE0pvJc0cbL5giXx41Yr5tyAL CEGq2jhSyfVuMg4aNI51XN1wCPCy+Fi0HGZhQrWae23ZMyYuaXAqtT95/Tx8 GpkIzQiT7L3cufNuINiW7Dnlk6y8zHatEKuzsQevR2YVbT5/9pGGL5xxUVeP OYT0Dt093FXLcSfwyyHfjZijUWXF6NrgoN4DJF9HLOwqDZV4UaV+MIKw7NjS gehe6Bwp+8/krKcJqdOvACyZH8gjlLtx5EOCcmrWkSXF8aWiYkXcSJqVqTqJ M7LVNsT3Yk4Sc8vHGU2IM9pTCRolYt7bVoK3Nk39DLjjm1E3c5mRoIbHgV1I Iw9+iMbLwlqNd8XERZ6ZFDFs0GRkKObKw4sCsC800hx4huCtW+9m04lUW/i7 GYXrcTVQSnI56gjB8upLXL6GgzRnRxdmOS6YpWG8SRwRJByTcZ7R82KopLk3 pUc6C1koJTkLnI0q2pQRdt7MaenA9sIVbAfH6QROYIRsgpn36sixQaN8QiTh tuQBEV9W9SUZ0GSTsYD46EhbM7+q678tMx+yOnCfM/OSqXgkk5UpSTEirRUj lu+fQGDMmXp+UXA6BAeqHGTxnrnmPWgJozNbBN/Hs8SYEZLccETusEqVTiOY sHEbBza+LYgT4RG0xiBBgzNvoDX7dhx12MfjIXu/TQ6mFpCwYNBs4n1J2pMD 2w4Be9ZxEjob5Tej6Bs73yZ2/cUZQcAdbhNtDkJnC8FpgoDOJ7F70PtwD8yB bPp7RuW42Igs8poV1mDIGM/hB8SCnBFijNin86EypayVBJE5bIcsQUYmxGbL to3aHZrdvijUW2iIpS5g5Iwz3uciw3hZUsRyDLMfBTp4okwjkf6eLhyrPfzU eJWg1004IsaH2yiCWSmF2RgnnyX4FIDMcM4VyOXDq5DYo0frLZAn1RmES03J XOKOcB1z0atIznTBC4D5Buc2d3NmvCHyWjSSwoAg+jDEY+cwZNtgTQffdwLT lz4o3bLj3QPsP9j/7PMVB0k46d5xRsqFPJeXRItuEmLqhjZBnD9Tew9n4Agp GRW9ZAz5TGqzgUYC0hFSiilR/Ta2UvdTMGT4BV0CWHDbMxP5gMFgECSTU52z SSUCcAgXjjngQMpnqVUAhvBVkT2qMmXRN7B1QjbHZyrGOWTcWUkHnSI6YIZE D5vtuiJbeAQrm3SzkUWzD47BsyoW8GRe0zFBwGwJXoJZWM2NzRc+7OsoMN0S TBoW7KuFSA/yJUmp8KnjA0ucxuczSeiASTYp4rhayMcA2DhWNaX+1KauuEAS 0jmJR4NaCS7lE7VIWCRqUDEYEfA+TeTtBBuLRCc5mzDpBoUSwwLpXorqX5K1 3rXJgbiogTUDJz8CGUUiWuEh75G8fknjkSgqey038WoSBhrrYNFHQ8VP3Wha nc0cH40IcaPU+zGMgZyIVIw3Yljah6A5xdm9D551k2DPqQFHcr/hgIn30vNs N+3qKf1nCAgZAQOCRmraEsspBArOU0sSJo0aTkMWTTADmYDzuly8xFPlTS6G oquxv/a8CztYZuDzwMScqYHY3kLMsCfpg5PbviGvxDEq2UkaebYpIbE/NHLE gDZCjbhJ8Y5zt6vZo48SVqFYYmZfSMJUJE6QNnQizSvhc3lOE7MTNtM8J8Qe 3fOhdtX6iFpDmxAB/QTS7Jpi4TM1RTUlLLTEi+aiIM0AhiBcrHfzpsjJ2nVS /ROnYX7yWsEvKhZ0LlD/FHvXvElj2JNVgcg5D7E7ECePKwY9e5oP66I8WMoS ZE+oUMEacYpfvVmj3uy+zcx4hCcqwhG2FrmqtTe36q1qESFTE1uC3lIbAyUO keaqf6taPi0u42lffrRvEVhYwauPv5rjq41+xbd4ONMIZA5xHdYsEjnOzFfS zcKjcRkpI+dQ/bRJymM/fw612KgqgjvesecGuSgex+nXYikmGHUtESQqPDwt h9ABy/dbbraaTaL6gddVy5EmwRbBc3tmzjhgoM97NV6xUVxoqFkktQaM4lLg d2nB3nmcg/t8k4tjjLnCZtF0PQxY1FFKCdrk0NWLGFQCMEkeY1QxSJIfscBM SptYfdc2tqODXjf7+/xAgF2GGHvin3D2CtR71X4CIgy74LczmQxVukW17Um2 z93BEiGtTCRoV5z24/S0xC3F/aPnNlnuK1SIQEKem9UKu2iaec/rRQ+CDLkP ro1quaCKlV/RmgAvGwpsx3co7BqVig41sL+ReVqa7qtIYP0cClAR9mZtr1mb oXWFHRkkE3KpS4hTM2Tmea2HS8YPBA2aQCxEJsZSnetPfIxSTnRZpCnWJdmG eY0kvVF3pdszwlIWGyxgNTk0/ADnmBFEj26INTzjhNCm2BS+ZoDxDZwhLwH8 +BAVfKO2q7dBCnGttBiAbCiTS8bB4Y3LYSeUO/LoJUkdpajF9i5dJsWy+v2i bhoJZXnwCHlXar6FF3u+yIH1nlQk9F294RJB1gJeVRPWkcgr2g1n4N87LpkZ olLQVRD/vhivPfIimDPosXJSpUJXUfvsL35z7hAUBzYhGytOnBKR0Zrt1lWt atW0bAGrkkJbcckrmwy8AxfpShWyJiGDYaLVU1FppJb8kIlrEFqQUpoLMtK+ Ko55RZCYuFULUCFZZJL8RoQxtlIIjNPBNIzdWL4NbziMivWGww2iJqINldBi FguTagmEIcLb+I+iUJ0XLmJHH/TARfBocGM/zaxZ4YZvXx0cjThqCisxrCMI h4ClMb9WaVmLh1FuOt8zi6JrZmFV1tVKU6xmWRMDoAjz1vHJbVjJbSjgSfHj hgCMZPkkaO5398kArjNVkkBJF8JyncYs/olKCa/IFFjHgbUW+eXXyyvWFIXE xXmZ0CiDwk77YIEMptqAsFiVREF0JrdxuWnk/e67OF5QArbVqpF4pkbVxyUv lvsBogiv5XiAhhw4deKT6WofIZdCZPNMfTKkXepSegQ+3/ROmBnHiUcMpXS0 6OKzmn0bLBRBa0ovKms4WIjLLukigxIaRQ0sEuBD8iyu7IF42OGmgtXFDIHI VmP7rQmKIo4JJs4rU2oTECGRqMGKhG2O4JEplhKzvGIVsqK9ivexm1xyOZIO 14pgpj72E+PzDQ+r2xwwk2wyETEkdMz+YbeWsma6uDjSKUKThHwLXuCgif/2 9KntWx87GdQ+W8qq8jUo3tqHswezY14K/zoJBfd37z2UDN5NoiAIMrWyjXkn 6am98iUtLuE7HhL8l2KxXCVMh8LtQcuUu4ih2ekOilkDXcT6pomhmpn38nGr Vx1DrCE/Nt/IrnZZQ4JAq0IyTjZLjl2qX6SUJCE+pu3KsM6iW+yZi/mRy6yB e34acvwql1TsDQkxvRoEGdExtq4FHKYS3cl7C6mkn5hD7QsT67rF7LZWOpAW SHwXDhEA5TsJjHSqKhBBaxxfQcCQz89N4GF5h6Nkvd9XyUfQ38TpFzV5zLmr CEnTejnlvPjCIc5MrngbnLCovSep0JOYsG7uI8E/tFcrGZxAGUeYAAx2ylnq 6JI5my9ddsGYyKQzB/fzBw0XrgVAQjR4Axra5bMMRntcYyimzIFkYsJ84Dpu i/EajCsrEvXF1Ga4dLnwtayNZgRw/3Ai1lkr3MJhMb4nbfDhKBGxainRBdR5 hD4TidpoNLJVni6zuMYy6mv9Q6qB81+Ceabr5dLnNkMtztDmSvLm13M42iIM luQftVIJmHTdSolJCKglbggBz9Il/5YpmGS9NYsiCGY+HHbziSp9oCIyJNC5 CFHSNdXODE7F4J+jVBHXcTBXdQi1jP03b56J/yR9NISnEFhNKvDTkgouVrrl F7iN6zdLEqyLAjDlfTf0FnL9GCJyUTm7b5IIrREsbugpI+4auoTk4bgG3tc7 sdOIbCtdQkGuaefTJxn96UyIhoYyGN+XPAolnysLdZqHxRK+6yLJbsbIYuQh 3UQ01qzYqtk3UtnoJYIafhNHIqNItQneFTNr6CsKu4Gv6DpcAbUsZ0aGzCcu Idu941pEvmZQDlp67z51RK/sD2jZ3ZI1AoE2s2ck64yLvMBLDpCLEQVBBckS UVwjPuCZJss22UfxUUmE55L2XHPPMa1EVL0ZsXt6CcMyYhjst6D4wqJLN2+L Tuxk4kCJ2HG7p1WA2WWUBLL6rxoSUMl/eLk52k7gGR6irIFRZn/wxHpHciWX mmlgbthI2yKnaf33Ko43Acb06KBINkQS2KRuXqyrhXo7A5iw8UJp30AaTGWT lLhEwoQsEENrfCR7vhvRm3cAUJcICpMG2CFQlaGVlmt8jQ+vTKL6sGXPoToU /7aDfpn/J1hd/8w0KyWlgmb0KWG4lSaE6GOm88BQeS986KvISNgP59SiugHq kefKdalJA73HjJF75D5XZsX2q6iBXm/HXt5lGkwJvodeRdxBoiLJhB+IAteg JQLCqajlW+XOXjXlM25FkIgU+9uQwU2R57JxNlh2B5NBNtATXMbz9J7GpBVZ vuyicMRndDozD8WuaQgyauGdPfIWfqjROx1tdRhzkdvZupBXwd9GK/jUC/KH 0NtqgpueOKyWIOob2MLP1JLK1DgBIvoW/QGt/8ki+YlvjH7w4B5y0rUvRfYO EEHEuSZeqtHuOAS7OcUPcpqj7GS/tCkKq853cSjyChOcO3f8qjDFIH2ToJ4G Bs2CrLs6FN8SUZNRjbheaohq1+cAKAtH1g5dsVLfzThWFbBuSD0cz4YeWE0d HOzJRnCSg8whPByd1oQEXNISwBglBgUjw99JpxLMzD3sHYoG444StsoVESBU 39snbWNCFqOGOp/gK0TUyOVsWldCCgym1szcj06sgZQ27T2a+2KIoKH2LQfz lVhf7A9cEeUzStwZx/BC2Mnux+t8yZxU7V8VkIvkwMlM3DeufvGcFl3tuIyK QWRhO6QbEGAxHAH2fkXL5RKs8YZ4nT0+4SDdzDyYxQl6+u2Ob4vlqvYM+KKB aAso2lHhx0MuhY/M8WXBBpJCnaQZw/Xi7sEpInlNUUXp+SR5FC6eJa+sAezJ iAk7To6g7kCT61liB8SqR9pt9PM4fD5cySM+1J5Vhc6awl2oiegKtr2CmvbC XTswQNtazaDJLw7d+pJXVh0tc3bw09JiCj9zwEt2zTtJAcHG1xRhS+2W+Pz5 L0+fvTu+S+hSWAaaQY0+huTMzOOZfVlUUmdPXmfRyYU3A6m1sRfrj+KBxFlw V67xhfpDTjFEm7poDAfTKxekwmM990U5rDgcsz+3NA8h1DgmPRZRbEPxrmXx kS5jXde5OVyOKQoZ3QD798ieDGIjXOTMR0rkwXx3tWGNprPTX073tNgvtXwe g676W13101BgyrwT96nRf0PHUXdZR11LYczD9DlmxpFq+ocMj3OLbL2Ihi79 x61/+eaMr8NPHv31tg6aE+s0mi83saekOtqMTosrn9i/kytoT5uPH+uJfd+T dPiZrOfSSQT6KTFwZV/MzLOs2cIWkVZaDzEmpk3ni+3j+1OdGAI8/HG4Dz8/ hn6YKUcQ1nM6hP1QlB2kydOG0PuqrvLLrMoY4r/X68q+n9HPLwrQoD5wlu3g XuiqHv4Wn/p5fTBgMU3uO+A//DzBT+aGtk+SHV03BVGkcFLu2EvlRp2Is2Cc zKx950gEvndtVSw+es3Ivim61wpxX9ZsryYVSN5PEiEIf+hIYq2QyNIwFBJ3 cfduaL5Etf9QqVBsOOrPJC0pzJhi0C7MVBFIgj55tiY7xz6tP+HfJD0qOgrM rZb+fk7Mm9uzBXmb2e8FffCC9DVOSZZ6mdHffyeJ8jwjksO/a1fan7OSNqr4 T7rNf0MnbBH+PFv0ZJ5j17dg4wrJ4Q1pbnyAvEWe2TPcMv6mO8hoQYwVxKAA /tEvQO7PRVmSV8CNxRHSkYnFvZ1l5e/4d0Q8+DNiD/i4jrBw3mOGA/4qNkSL fyf1tWxlo7PObeFtvMyahiiDU7I5EeaGvz0vNoRIEv3ml9nTWVyszooghLSi 3nkiHZKbdOMStBPz3sQ3iiGMaDOsYWbxuKs5rQtR9YxDb3Ruks3NLljzr6fP jfn8JIPg+2L+ygHKFzyu8Yl9R+TTOimd0hgHFAtt94lg4mCJpJ79+Kib5BIU iJ3+gemhxyCsfyxIhaGUlaM5B8bH/Mctz4k6i5P039H3jPg82pIvfXTv/uOj 29jvPXcPX+WVXNtuP/Jmb1ERrf5GEuGE70dsmZXXteGDR0dLsnZb3vYNWYm3 /vW2nRdeL97TUlsLo/Xa9nx8+/tu/K5hlkUemAkM3lHb06atD8tq7I4MP5iR H169eYZQ0j+UAJErJKvBjQI/fMIBtdI/FHUPcVvJNR36+PExo/iZFIfYUISj zlZsZc+ua88ToiZr/3EKVQImvK6F792/K4dRHhwG9ozrOK/tKD8+4qO8rhbl LNxn+4MO0LnOS/pzEPYgQdjQr8BFSdr7xPUfLfcvomLTNztdGxD35NbItNbC vuJ3ydkja3V9R1VCx/kS91l7D+hhLdcP7rM00lzfOUWInuY5l8D5CGcYdKIB FZ+TRJyFg6VDnOb6kHEvuffT53vdm9e31cn3SdW7P7IePW92Eh/iBgrxdNYk kOii6OZ6Dppva8xRSArvr01EPfpOqB8bvVuZWIHWqCLMWcUkxxWXW8SlCf97 WKWvnKCV63wLM2MBFySJMEUJSJ3FQBwQen7gzRVw/68Ndfe/E3WPGHWJp6AN 81xLIrXM14csEORURDanH6OJm36gLvIbXUPuY3fpso9SnQXcNlEim4cy0ve+ yaw9GqQn34FrftIJn5ixED6c0IPjztX/+e//O66tva7bgIS/6jY2h27jId/G L5zJhyCOG6qSkGVov4SavS5wVUb6AaFsvcuE4WFII7D9J1lDkIvfRbsPBFso dB1aGvd7VkEbUe7v2sTUvYffCe8Jw/sbwmdoFLYvqhXH3VG0grQAXfLTZ+8Q gy2JK/ps5a4N1LvfCep9JcR4kF1crhwN536q8bRrg/X4O2G9x7CSV621DTz/ mv3Lg2OHr427if5ux3pH5jccH9+/rg2OH6qXeYlyfrsNQyCv7QT3dYOobOra 1n6kvk3aMVUkbUxw9K9twx+/k24kZiBDhu2Nq2p0blwXgD+KnfCOOxLjEm+M 7EXtKho2ymvb7VGwd7mrq3OfZJrNJ5E9knErXWrBXd9lfK/AuStMvHUl67tl 8emaQHl8Vy0OKeKMNMVcxxRe7re3hbFwSAXR19cEyyPx+IYBOLFNEyyayBFM CtmuCwiRKi+LT4gTy3ic1uOdS3izbdHB/rhW/nz8mLd9EYI1semXJj6ubcsD fsQ4t6FiwIspiYxy+zP5/Fc+MgD4vamUu8dHt2dYW+ROrtGrdhZlf3xmgTWt hvu5a4tHBU+fXxuCHrJ9at+GGfn2881oYL4x+41gw1z+qJg13KX/ta9k902+ kskK4d50asB8GO2vs8J8AnwjUeBh9v/Bl22ss2Fqvva2j4YpGknGQ/1EdmAy SzIeShxq+CRvixJLv362X6I6eqODrnb68ztC15LnW/ihdVwWdRjuvUWHtLhC 9ujRQ4IMM6XgeAuv2r2CWl8kacd1qhgn5TLmcU7r3BkyoneiSbtr38Koepr7 4P04proMpWHDxjMFUCbocMuiXKvKMHrAYZYm4yWd/82AeN4Ik5j4ux/aoUHb ajM2OgcKAiF5C0JIa3mROaAOuFi7cuvnrycd0hjYPe4W/vyZ37yDEqKQZI8S WT4qhlKPgy8QkAGtyKj9z3/9vzByjJMR+CB+vwAf1fhJ3y/9GzDSWLR2kNSL IgtDlPZGJml8xuyd5TkIUDIiRVwnIlPp+Zr4xQtph5lJLgUVSKeBF7SSk6na M1o0JM0QQaNXoUXBD+cWOTtULLSAkGdjS5lbUhASgsR0EnMApKgI3GkVXRiB pq97GTpahDjkdRQzJN27aNKQzMsfDneDY6oyxIeHF9EV3dmidkUYI5n3oyWl KWhadqdWhRvPbZa8lsHgw8WiJ+ze8rPg5EHp3NReeB7nHFPAbRFEdwh9C2HU CB5zEB6Wbxd0N9q/EtU9pJBB+DBMjVZd8GjbcGVcjoQye25Ow/aQ6R6QpARH yZLrVpAlZuWJgFvJyb6Ch9VYUptaxrXk10FNwoB/HnBVj9sxkhepmGHSJI86 Sfs1ZBphNEqhWs3sa+7/6Ld7zZKy2IjohyZRkdYbUlJMVp4U1FrbOz6b1Dzm j6tvB2lZNGmv+usqiJJJ+u6YYQSx16bSr3RRS61zFaVk0RWTYMa/VWScxQqv tMkihRPm43A56f7barTa89a791P5522AxO0vJmrZm9Djncxe91OFZJZUmH8W GgHi0esvwnBcHbCUtOH73J0XB5UlBGiTok6k2H8lT1J5L7bCu6aelxjQGCq4 3vlu91M/1lmNHPfFv89Ff3Bo7vP4xUyjvjU/YdsXgB4QX5NRthYSEOMmSYVC 9ZtkdsW05FYjoQPaOFwFPQGW5VKKSueaS2cK2mxRCFJyccUV9pEk/hEu9VPd UaLHHTf8S+6t5F67gl8ZdMUEO3vuGxsmsY9ySI9YLRcdiJf+GAR3mFDA6lHr +kNbmJQF2bQoazT9MpoB0KqhRSsNCINKQYdC1jRZJSVW03jYTqjvbX2B7lcP JE0pHea9C3elb2NCETQ+ZNLmd5bC7fbtNhKKLtAxUZTltO11ZE08sktqBjEr Cnrun32x+FjuWJDJfCpMD+ZG+qDOfCWQNNocKnHjFrhN0bI5PEIotxxC/3H3 GhR0sDHY662lT1lMezVYLMtfxuSzr2MLdX3S0V+hlOhAO/mS3+GpvYp0+xi7 z4pheEPGgCqZJ4eX46HYbfSutOENTaSFsioaHudNPULgHyDYqK8QPRMk0i8z GZx8CLfSBpTsR2vo+J1cpjDLaiBtdOWqSYlrHwbtbBibMZ/L+Rc8VuzKIYg+ B9A67vIadub+nECAksXhdxrxWwKroWFba8vh3Vjvc2UDQaq9k/ITNzGhBrz1 71YJg+r0pWbyTeerOEnkaxkGCSGCdId3sFzspkhsKEvKIFCM7KvS1xCl3O8v Z292sh1m4Ry+JxyL7x5mwv7NT5QS/Ux/NVblzUXfNsi9S2PD64QOmrB+bhtO KWVOkI1hoL6deiQuMm1Jk3ewYDxj9CYH9j/rardhfVUWeD2PEIlcJy3gPmUL 18zDqNCtaMThTWkH0Tp33NwU0PoHkBqDwq3Fs0QB1Ut+VVZqdvL4PB4cqQfa 9/L0PRij6cxaAKmvUEIJbHhdyl73rtynSt49Ye+nToXBguqDzwTsOdrh0Npr Re6uOWrBwYLkpVEIaKMY/dCgMPS0yZzoidXhYuF4YeLzwWnQYirghYc8Tugq oe79SF/f3+qcTAwJ9+eiFfrKnw1hHmRzfvmj2RwyknxjoppJTNbyqhHvHusr HPG67quG3srobdJ8HFCopu7TmohQGjdQzTlMcJT5NGgUIru98i/CY+7l8tMf OMzUwKuBoEcM9Scs8Vu1QHOG1Zp37pDbe31I8Fd1C37SDyhDB3/dVzyoDYML pQgLHfWYMCLDuYe39nkNHIrUYQFzcTGG6UpB5TDiwr+D74yEhuu4iZ4n8PPt yAtf6zYIE2kyj3sODggThv2922KKbc7z80m9M+h91en73zSI3MgMA4I2tInH U6ptsDvltTi07o0zRIm4jP9G8HkTs0FtmYrNbs7sRGMWHIIx/I5ifnFP1mWC RQndaOu26EP0PtCaMv+kLknND1XFPGJdOnaFBmfJ9NA9B26YAzLwu4kMDYSA fMk+zxpJXwU1TBvjiVvRG0OM0gtIOlRt8AtIZoFVWp1DyNfICJPeXW3R2Rsa LLNgObrmh2EhosQ5vkzb6DvlN30RHncbe5Yi4P8/bKZTTY9/AAA= --></rfc>