[要約] IETFの公開チャネルにおける破壊的な参加を抑制し、オープンで歓迎的な環境を維持するためのモデレーションポリシーを確立しています。IESGによって任命されるモデレーターチームを新設し、一貫したモデレーション手順の開発や、ワーキンググループ議長などの管理者との連携を促進します。RFC 3683や3934を廃止し、2418や9245を更新することで、多様なプラットフォームに対応した現代的で公平なコミュニティ運営の枠組みを提供しています。

Internet Engineering Task Force (IETF)                    L. Eggert, Ed.
Request for Comments: 9945                                       Mozilla
BCP: 245                                                    E. Lear, Ed.
Obsoletes: 3683, 3934                                      Cisco Systems
Updates: 2418, 9245                                        February 2026
Category: Best Current Practice                                         
ISSN: 2070-1721
        
IETF Community Moderation
IETFコミュニティモデレーション
Abstract
概要

The IETF community will treat people with kindness and grace, but not endless patience.

IETF コミュニティは人々を親切かつ優雅に扱いますが、際限なく忍耐するわけではありません。

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.

このメモは、RFC 3683 および 3934 を廃止し、IETF のさまざまな公的貢献チャネルおよびディスカッション フォーラム全体での破壊的参加の緩和に関するポリシーを確立することにより、RFC 2418 および 9245 を更新します。モデレーションのためのガードレールとモデレーター チームを確立します。そのチームは一連のモデレーション手順を開発し、議長および管理者との一貫した実施を促進します。

Status of This Memo
本文書の状態

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベスト プラクティスを文書化したものです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。BCP の詳細については、RFC 7841 のセクション 2 を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9945.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9945 で入手できます。

著作権表示

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

Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。

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.

この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。

Table of Contents
目次
   1.  Introduction
     1.1.  Terminology Note
     1.2.  General Philosophy
   2.  IETF Moderator Team
     2.1.  Composition
       2.1.1.  Team Diversity
     2.2.  Training
   3.  Scope and Responsibilities
     3.1.  Actions That Are Out of Scope
     3.2.  Unsolicited Bulk Messages
   4.  Moderation Procedures and Transparency
     4.1.  Consistency and Conflict Resolution
     4.2.  Reinstatement
   5.  Relationship to Other IETF Functions
     5.1.  Relation to the Ombudsteam
     5.2.  Relation to the IETF LLC
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Motivation
     A.1.  Background
     A.2.  Problems with the Previous Approach
   Appendix B.  Non-Normative Examples of Disruptive Behavior
   Acknowledgments
   Authors' Addresses
        
1. Introduction
1. はじめに

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.

このメモは、IETF のさまざまな公開オンライン貢献チャネルおよびディスカッション フォーラム全体での破壊的な参加を抑制するためのポリシーを確立します。手順を開発し、その一貫した適用を促進するためのモデレータ チームが作成されます。

This memo obsoletes and updates some prior IETF processes, summarized here. Background information is described in more detail in Appendix A.

このメモは、ここに要約されている以前の IETF プロセスの一部を廃止および更新します。背景情報については、付録 A で詳しく説明します。

This memo makes the following changes to existing processes:

このメモは、既存のプロセスに次の変更を加えます。

* Obsoletes [RFC3683] as the "posting rights" (PR) action it defines is replaced by processes defined herein;

* [RFC3683] が定義する「投稿権」(PR) アクションがここで定義されるプロセスに置き換えられるため、[RFC3683] は廃止されます。

* Obsoletes [RFC3934] as it replaces working group moderation procedures;

* [RFC3934] はワーキンググループのモデレーション手順に置き換わるため廃止されます。

* Obsoletes Section 3 of [RFC9245] and the second paragraph of Section 4 of [RFC9245], as the IETF moderator team defined in this document replaces the IETF discussion list moderator team.

* この文書で定義されている IETF モデレータ チームが IETF ディスカッション リスト モデレータ チームに置き換わるため、[RFC9245] のセクション 3 および [RFC9245] のセクション 4 の第 2 段落を廃止します。

* Updates Section 6.1 of [RFC2418], because the moderator team will work together with working group chairs to moderate disruptive behavior.

* [RFC2418] のセクション 6.1 を更新します。これは、モデレータ チームがワーキング グループの議長と協力して、破壊的な行為を抑制するためです。

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 Section 4 have been approved by the IESG.

このメモで説明されているプロセスは、IETF の活動にのみ適用され、明示的な合意がない限り、インターネット調査タスクフォース (IRTF)、インターネット アーキテクチャ委員会 (IAB)、RFC シリーズ ワーキング グループ (RSWG)、RFC シリーズ承認委員会 (RSAB)、または独立 RFC サブミッション ストリームなどの他の関連組織には適用されません。これらの変更は、セクション 4 で説明されている手順が IESG によって承認されたときに発効します。

1.1. Terminology Note
1.1. 用語メモ

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. The "owners" of non-WG IETF mailing lists are another example of administrators.

この文書では、「管理者」という用語は、特定の公衆参加チャネルまたはディスカッション フォーラムを管理するために IESG によって任命された人々を指します。このメモでは、メーリング リスト、チャット グループ、GitHub や GitLab などの共同ツールでのディスカッションなど、公的 IETF 参加チャネルを指すために「フォーラム」という用語を使用しています。たとえば、ワーキング グループの議長は、ワーキング グループが使用するすべての公開フォーラムの管理者です。これには通常、メーリング リストやチャット グループが含まれますが、GitHub や GitLab などの共同作業ツールが含まれる場合もあります。非 WG IETF メーリング リストの「所有者」も管理者の例です。

1.2. General Philosophy
1.2. 一般的な理念

The cornerstone of this policy is that individuals are responsible for furthering the goals of the IETF as an organization [RFC3935] in a manner consistent with the policy laid out in [RFC7154].

このポリシーの基礎は、[RFC7154] に定められたポリシーと一致する方法で、個人が組織としての IETF の目標 [RFC3935] を推進する責任があるということです。

Disagreement and diverse points of view within any standards organization are to be 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 [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, action must be taken in order to maintain decorum of the community.

いかなる標準化組織内でも意見の相違や多様な視点が存在することは予期されており、それは健全なことですらあります。IETF は、議論ベースの大まかな合意プロセスを備えたオープンな標準団体であり、その非規範的な説明は [RFC7282] にあります。したがって、IETF フォーラムの範囲内での熱心で敬意を持った議論は、破壊的であるとみなされるべきではありません。また、大まかな合意から外れているという理由だけで誰かが破壊的であるとみなされるべきでもありません。ただし、誰かが一線を越えて破壊的な行動をとった場合は、コミュニティの礼儀を維持するために行動をとらなければなりません。

The moderation policy goals are as follows:

モデレーション ポリシーの目標は次のとおりです。

* 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;

* IETF における参加者の役割や以前の技術貢献に関係なく、すべての公開オンライン IETF 参加チャネルおよび参加フォーラムにわたって、一貫した公平かつタイムリーなコミュニケーションのモデレーションを適用します。

* Ensure that appeals are available to address disagreements about moderation actions;

* モデレーションアクションに関する意見の相違に対処するための異議申し立てが利用できるようにする。

* Balance transparency against both privacy of individuals involved and further disruption to the community;

* 関係者のプライバシーとコミュニティへのさらなる混乱の両方に対する透明性のバランスを取る。

* Allow moderation decisions to be reconsidered; and

* モデレーションの決定を再検討できるようにする。そして

* 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.

* モデレートを行うすべての人に可能な限り幅広い自由度を与え、幅広い個人や状況に柔軟に対応できるようにします。

Questions about the processes detailed below should be answered with these goals in mind.

以下で詳しく説明するプロセスに関する質問には、これらの目標を念頭に置いて回答する必要があります。

The objective is explicitly *not* 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.

その目的は、明らかに「罰」ではなく、IETF での役割や過去の技術貢献に関係なく、全員が平等な立場で参加できる、オープンで歓迎的で敵対的ではない環境を維持することです。

2. IETF Moderator Team
2. IETFモデレーターチーム

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 Appendix A.2) and the principles described in the introduction.

このメモは、IETF のさまざまな公開オンライン フォーラムを管理するための一貫したアプローチを定義します。IETF のモデレーター チームは、モデレーションのためのガイドラインを開発および維持し、以下に詳述するように、その一貫した実装と適用を促進します。これらの変更は、以前のモデル (付録 A.2 を参照) で特定された問題と、序文で説明した原則に対処することを目的としています。

2.1. Composition
2.1. 構成

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.

IESG はモデレーターを任命および召還します。モデレータ チームは当初 5 人以上で構成されます。モデレータ チームは運用経験に基づいて拡大または縮小する場合があります。IESG はメンバーを選出する際に、地理的範囲、予想される欠席および予期せぬ欠席、チームの多様性を考慮します。

Because the IESG and IAB are in the appeals chain for moderator team decisions (see Section 4.1), 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 moderator assumes any such role, they shall step down from the moderator team soon after.

IESG と IAB はモデレーター チームの決定に対する異議申し立ての連鎖に含まれるため (セクション 4.1 を参照)、IESG は IESG または IAB に所属するモデレーターを任命してはなりません。IETF トラストや IETF LLC 理事会など、NomCom がメンバーを任命する他の団体の職員、IETF LLC のスタッフや請負業者も、モデレーター チームのメンバーから除外されます。モデレータがそのような役割を引き受けた場合、モデレータはすぐにモデレータ チームから退任するものとします。

2.1.1. Team Diversity
2.1.1. チームの多様性

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.

IETF はグローバルな性質を持っているため、このチームのメンバーはタイムゾーンの多様性やその他の参加者の特性を反映し、24 時間および年間を通じて効果的に運営できるようにする必要があります。理想的には、モデレーターは数時間以内に問題に応答できる必要があります。

Team diversity also improves the likelihood that any participant experiencing or observing disruptive behavior can identify a moderator they feel comfortable contacting.

また、チームの多様性により、破壊的な行動を経験または観察している参加者が、安心して連絡できるモデレータを特定できる可能性が高まります。

2.2. Training
2.2. トレーニング

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 [RFC8711].

IETF は、必要に応じて、管理者やモデレーター向けのトレーニングを提供したり、資金を提供したりすることに取り組んでいます。IESG は、必要な資金やリソースについて IETF Administration LLC [RFC8711] と交渉します。

3. Scope and Responsibilities
3. 範囲と責任

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.

このポリシーは、現在および将来のすべての公開オンライン IETF フォーラムに適用されます。これには、メーリング リスト、チャット グループ、および IETF または WG が採用することを選択した他のシステム (GitHub リポジトリ、Wiki、問題トラッカーなど) でのディスカッションが含まれますが、これらに限定されません。

Different people have different moderation responsibilities:

人によってモデレーションの責任も異なります。

* *Participants* should always behave in the manner discussed in Section 1.2. They are also encouraged to report disruptive behavior directed at them or someone else to an administrator of the respective forum *and* the moderators.

* *参加者*は常にセクション 1.2 で説明した方法に従って行動する必要があります。また、自分または他の人に対する破壊的な行為を、それぞれのフォーラムの管理者 * および * モデレーターに報告することも奨励されます。

* *Administrators* 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 moderator team *after* they have consulted with that team.

* *管理者* は主に、モデレーターによって作成され、IESG によって承認された手順に従ってフォーラムを管理する責任を負います。そのため、妨害行為の報告にはタイムリーに対処し、報告や取られた行動について管理者に通知するものとします。管理者は、モデレーター チームのメンバーがチームと協議した後、そのメンバーがとったアクションを含め、アクションを修正または取り消すことができます。

For a working group, chairs are by default the administrators. They may delegate this responsibility in the same vein as Section 6.4 of [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.

ワーキング グループの場合、議長はデフォルトで管理者になります。彼らは、[RFC2418] のセクション 6.4 と同じ趣旨でこの責任を委任することができますが、破壊的な行為の苦情を常に受け入れ、承認し、追跡しなければなりません。フォーラム管理者は、モデレーター チームの関与を不要にする方法でモデレーションを実行する必要があります。

* *Moderators* 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 about moderation and refer interested parties to that forum.

* *モデレーター* は、現在および将来のすべての IETF フォーラムにわたるモデレーションのニーズに対処するための手順を確立する責任があります。これらは、コミュニティが破壊的な行為に対処するために使用できるリソースです。モデレータ チームは IESG に対して責任を負います。IESG は、モデレーションに関する議論を促進し、関係者をそのフォーラムに紹介するためのフォーラムを作成または指定します。

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 not 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. Section 4.1 discusses the handling of disagreements.

管理者がレポートにタイムリーに応答しない場合、モデレーターは措置を講じることがあります。通常、最初のアクションは、関連する管理者に連絡してアドバイスを試みることです。管理者が応答しない場合、または誰かが同時に複数のフォーラムを妨害した場合にのみ、管理アクションを実行する必要があります。モデレーターは通常、WG の議長に対し、グループ内の困難で議論の余地のある議論を管理する機会を与える必要があります。この原則の範囲内で、状況によっては迅速な対応が必要になる可能性があることを理解した上で、いつ行動する必要があるかを決定するのはモデレータの判断に任されています。モデレーターは、実行するアクションを管理者に通知する必要があります。セクション 4.1 では、意見の相違の処理について説明します。

Moderators are administrators for IETF plenary fora, currently including the IETF discussion and Last Call lists and any plenary chat sessions. They are also administrators for any forum that does not otherwise have an administrator.

モデレーターは、IETF プレナリー フォーラムの管理者であり、現在、IETF ディスカッション、ラスト コール リスト、およびプレナリー チャット セッションが含まれています。彼らは、管理者が存在しないフォーラムの管理者でもあります。

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.

機能を拡張するために、上記の本会議を除いて、モデレーターはすべての通信を常に積極的に監視することは期待されていません。In general, they will process reports from participants.

* *Area directors* are expected to resolve conflicts as described here and in Section 4.1. 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.

* *エリア ディレクター*は、ここおよびセクション 4.1 で説明されているように、紛争を解決することが期待されています。IESG は定期的にモデレータのパフォーマンスとニーズを評価し、適切と判断した場合にはモデレータを任命したり、解任したりすることがあります。それとは別に、IESG はモデレータ チームの日常的な運営と管理を控えるものとします。モデレーターは、必要に応じて IESG と協議することがあります。

3.1. Actions That Are Out of Scope
3.1. 範囲外のアクション

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.

モデレーターのアクションは、オンライン IETF フォーラムでの中断を伴う通信を制限する目的でのみ許可されます。他のすべてのアクションは、このメモの範囲外です。範囲外のアクションの例には、Datatracker アカウントの削除が含まれますが、これらに限定されません。対面、仮想、またはハイブリッド会議への参加の制限。コンテンツの削除または編集。プライベートまたは非 IETF 通信のモデレーションまたはポリシング。モデレータ チームは非公開の IETF メーリング リストを管理しませんが、そのようなリストの管理者は、モデレータ チームが開発した手順の一部を採用することを選択できます。

3.2. Unsolicited Bulk Messages
3.2. 迷惑なバルクメッセージ

Unsolicited bulk messages are considered disruptive and should be handled in a manner consistent with the "IESG Statement on Spam Control on IETF Mailing Lists" [IESG-SPAM] or its successors. Administrators and moderators may take similar actions in other fora (e.g., GitHub or instant messaging). Such actions require no additional reporting.

未承諾のバルク メッセージは破壊的であるとみなされ、「IETF メーリング リストのスパム制御に関する IESG 声明」[IESG-SPAM] またはその後継に準拠した方法で処理される必要があります。管理者とモデレーターは、他のフォーラム (GitHub やインスタント メッセージングなど) で同様のアクションを実行する場合があります。このような行為には追加の報告は必要ありません。

4. Moderation Procedures and Transparency
4. モデレーション手順と透明性

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.

ここで設定されたポリシーの範囲内で、モデレーター チームは、モデレーター チーム独自の運用手順を含む、モデレーターに関する手順と基準を開発および維持するものとします。

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 RFC Series. This shall be the first task for the moderator team. Until those procedures and criteria are established, all previous processes referenced in Section 1 shall remain in effect.

これらの手順と基準はコミュニティの意見をもとに開発され、発効前に IESG によって承認され、公開されるものとします。ただし、RFC シリーズに文書化する必要はありません。これがモデレータ チームの最初のタスクとなります。これらの手順と基準が確立されるまで、セクション 1 で参照されている以前のすべてのプロセスは引き続き有効となります。

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.

このメモの目的は、必要最小限の措置が講じられることを期待して、管理者とモデレーターに可能な限り幅広い行動の自由を提供することです。フォーラムの妨害をやめるよう指示された人は、直ちにそうしなければなりません。さらなる混乱はさらなる是正措置につながる可能性があります。

Examples of actions that could be taken include:

実行できるアクションの例は次のとおりです。

* Automated rate-limiting mechanisms;

* 自動化されたレート制限メカニズム。

* Review and approval of submissions/messages;

* 提出物/メッセージのレビューと承認。

* A private or public admonishment;

* 私的または公的な勧告。

* Temporary or indefinite suspension of participation privileges in one or more fora.

* 1 つ以上のフォーラムへの参加権限を一時的または無期限に停止する。

These are only examples and are not in any way prescriptive. Administrators and moderators are free to decide on these or other actions.

これらは単なる例であり、決して規範的なものではありません。管理者とモデレーターは、これらのアクションまたはその他のアクションを自由に決定できます。

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.

参加権限を制限するすべてのモデレーション アクションは、それらのアクションが有効になる対象者、関連する管理者、およびレビューのためにモデレーター チームに直ちに報告されるものとします。それらはまた、IESG にも定期的に報告されるものとします。

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.

14 日を超えて参加権限を停止するモデレーションアクションのみ、そのようなアクションが適用されるフォーラムに報告する必要があります。または、いずれの場合も、停止された者の要求に応じて報告する必要があります。このような措置が複数のフォーラムに適用される場合は、IESG が決定した方法でコミュニティに通知する必要があります。

Moderators will periodically provide an aggregate report to the community on actions taken under this policy.

モデレーターは、このポリシーに基づいて行われたアクションに関する集計レポートをコミュニティに定期的に提供します。

4.1. Consistency and Conflict Resolution
4.1. 一貫性と競合の解決

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 responsible area director for resolution, or with the IETF Chair if a responsible area director cannot be determined or is not assigned. If the disagreement cannot be resolved by the area director, that person may then appeal to the IESG and subsequently to the IAB using the processes stated in Sections 6.5.1 and 6.5.4 of [RFC2026].

管理者とモデレーターは、このメモと IESG によって承認されたガイドラインに従って行動するものとします。モデレーションの決定に関して意見が一致しない場合は、誰でも責任のあるエリア ディレクターに問題を取り上げて解決を求めることができます。また、責任のあるエリア ディレクターが決定できない場合、または割り当てられていない場合は IETF 議長に相談することができます。意見の相違がエリアディレクターによって解決できない場合、その担当者は、[RFC2026] のセクション 6.5.1 および 6.5.4 に記載されているプロセスを使用して、IESG に、続いて IAB に上訴することができます。

4.2. Reinstatement
4.2. 復帰

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 initial decision and then only annually afterward.

人も状況も変わります。フォーラムへの参加権限が無期限に停止された個人は、回復をリクエストできます。復帰の要求は、最初の決定から 1 年以内に行うことができ、その後は 1 年ごとにのみ行うことができます。

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.

そのようなリクエストは、決定を行った主体 (モデレーター チーム、ワーキング グループの議長など) またはその後継者に送られる必要があります。その当事者は、その裁量により、条件付きまたは無条件で誰かを復職させることができます。

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.

IETF プロセスに対するサービス拒否攻撃を回避するために、誰かの参加特権を回復しないという決定に対しては上訴できない場合があります。いかなる復職も猶予であり、権利ではありません。

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.

このプロセスの前に課された参加特権の一時停止は、対応する RFC が正式に廃止された場合でも、一時停止の時点で実施されていたプロセスに従ってのみ再検討されるものとします。

5. Relationship to Other IETF Functions
5. 他のIETF機能との関係
5.1. Relation to the Ombudsteam
5.1. オンブズチームとの関係

Administrators and moderators shall complement the efforts of the IETF Ombudsteam [OT], whose focus on anti-harassment shall remain unchanged. Administrators and moderators should always report suspected harassment. They should nonetheless take any necessary actions regarding disruptive behavior.

管理者とモデレーターは、IETF オンブズチーム [OT] の取り組みを補完するものとし、ハラスメント対策への焦点は変わりません。管理者とモデレーターは、ハラスメントの疑いを常に報告する必要があります。それでも、破壊的な行為に関しては必要な措置を講じるべきです。

5.2. Relation to the IETF LLC
5.2. IETF LLCとの関係

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.

IETF Administration LLC (IETF LLC) の取締役会は、組織全体に対する受託者責任を負います。これには、IETF 参加者の行動から生じる可能性のある重大な法的リスクから組織を保護する義務が含まれます。

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 is necessary and therefore will be extremely rare in frequency. Some examples of where this might be necessary are:

この保護には、IETF LLC が緊急の調整措置を講じる必要性が含まれる場合があります。これらの緊急措置は、IETF LLC がそのような措置が必要であるという法的助言を受けた場合にのみ講じられることが期待されており、そのため頻度は非常にまれです。これが必要となる可能性のある例としては、次のようなものがあります。

* Someone making a credible threat of harm to other IETF participants.

* 他の IETF 参加者に危害を加えるという確かな脅迫を行う者。

* 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.

* IETF メーリング リストや Web サイトを使用してコンテンツを共有する者が、そのコンテンツを IETF リストや Web サイトに公開すると、IETF に重大な法的リスクが生じます。

* 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.

* IETF メーリング リスト上での何らかのやり取りが IETF に重大な法的影響を与える可能性があり、法的措置を講じるという確かな脅迫を行う人物。

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 the action, 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.

そのような措置が講じられた場合、IETF LLC は、法的助言によって反対の制限がある場合を除き、措置の主題、措置の性質、措置の理由、および予想される期間の詳細をすべて提供して、できるだけ早く IESG に通知する必要があります。IETF LLC は、反対の法的助言を受けた場合を除き、モデレータ チームと IETF コミュニティにも通知する必要があります。

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 LLC Board, as documented in Section 4.7 of [RFC8711].

このような措置は受託者責任に従って IETF を保護するために IETF LLC によって取られるものであるため、モデレーター チームまたは IESG の決定によってそれが無効になることを許可することはできません。[RFC8711] のセクション 4.7 に記載されているように、そのような措置の対象者は IETF LLC 理事会による審査を要求することができます。

Any such action taken by the IETF LLC under this section of this policy is not subject to the rest of this policy.

このポリシーのこのセクションに基づいて IETF LLC が行うそのような措置は、このポリシーの残りの部分には適用されません。

6. Security Considerations
6. セキュリティに関する考慮事項

The usual security considerations [RFC3552] do not apply to this memo.

通常のセキュリティに関する考慮事項 [RFC3552] は、このメモには適用されません。

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:

モデレータ、ワーキンググループの議長、その他の者によるモデレーション手順の乱用の可能性があり、正当な参加に対する検閲につながる可能性があります。この潜在的なリスクは、次の 8 つの方法で軽減されます。

1. Section 4 requires the moderator team to first establish procedures that are intended to apply uniformly across the IETF.

1. セクション 4 では、モデレーター チームが、IETF 全体に均一に適用されることを目的とした手順を最初に確立する必要があります。

2. Section 1.2 explicitly states that viewpoints outside the rough consensus are not in and of themselves disruptive.

2. セクション 1.2 では、大まかなコンセンサスから外れた視点は、それ自体が破壊的なものではない、と明示的に述べています。

3. Section 4 provides transparency by requiring that moderation actions that restrict participation privileges be immediately reported to the affected person and to the moderator team, and periodically reported to the IESG.

3. セクション 4 では、参加権限を制限するモデレーション行為が影響を受ける人物とモデレータ チームに即時に報告され、IESG に定期的に報告されることを義務付けることで、透明性を確保しています。

4. Section 4 also requires that the community be informed in the case of suspensions lasting longer than 14 days.

4. セクション 4 では、停止が 14 日を超えて続く場合にはコミュニティに通知することも義務付けています。

5. Section 4.1 lays out an appeals process in the case of disagreements.

5. セクション 4.1 では、意見が異なる場合の控訴プロセスについて説明します。

6. If moderators find that the procedures themselves are leading to inappropriate moderation, Section 4 allows them to update those procedures in consultation with the community and with the approval of the IESG.

6. モデレーターが手順自体が不適切なモデレーションにつながっていると判断した場合、第 4 条ではコミュニティと協議し、IESG の承認を得て手順を更新することが許可されています。

7. 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 [BCP10] or the community at large.

7. IETF 参加者が、IESG または IAB のいずれかがこの文書に記載されているそれぞれの監視機能を実行していないと考える場合は、NomCom [BCP10] またはコミュニティ全体にコメントすることができます。

8. 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.

8. 最後に、これらのプロセスが適切に機能していないと思われる場合は、このメモに記載されているポリシーが修正される可能性があります。それらは決まったものではありません。

Moderation actions are intended to limit the likelihood of disruptive behavior by a few IETF participants that may discourage participation by other IETF participants.

モデレーション アクションは、他の IETF 参加者の参加を妨げる可能性のある少数の IETF 参加者による妨害行為の可能性を制限することを目的としています。

7. IANA Considerations
7. IANAの考慮事項

This document has no IANA actions.

この文書には IANA のアクションはありません。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献
   [BCP10]    Best Current Practice 10,
              <https://www.rfc-editor.org/info/bcp10>.
              At the time of writing, this BCP comprises the following:

              Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection,
              Confirmation, and Recall Process: Operation of the IETF
              Nominating and Recall Committees", BCP 10, RFC 8713,
              DOI 10.17487/RFC8713, February 2020,
              <https://www.rfc-editor.org/info/rfc8713>.

              Duke, M., "Nominating Committee Eligibility", BCP 10,
              RFC 9389, DOI 10.17487/RFC9389, April 2023,
              <https://www.rfc-editor.org/info/rfc9389>.
        
   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.
        
   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <https://www.rfc-editor.org/info/rfc2418>.
        
   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <https://www.rfc-editor.org/info/rfc3935>.
        
   [RFC7154]  Moonesamy, S., Ed., "IETF Guidelines for Conduct", BCP 54,
              RFC 7154, DOI 10.17487/RFC7154, March 2014,
              <https://www.rfc-editor.org/info/rfc7154>.
        
   [RFC7776]  Resnick, P. and A. Farrel, "IETF Anti-Harassment
              Procedures", BCP 25, RFC 7776, DOI 10.17487/RFC7776, March
              2016, <https://www.rfc-editor.org/info/rfc7776>.
        
   [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
              the IETF Administrative Support Activity, Version 2.0",
              BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
              <https://www.rfc-editor.org/info/rfc8711>.
        
8.2. Informative References
8.2. 参考引用
   [AHP]      IESG, "IETF Anti-Harassment Policy", 3 November 2013,
              <https://www.ietf.org/about/groups/iesg/statements/anti-
              harassment-policy/>.
        
   [DP]       IESG, "IESG Statement on Disruptive Posting", 17 February
              2006, <https://www.ietf.org/about/groups/iesg/statements/
              disruptive-posting/>.
        
   [IESG-SPAM]
              IESG, "IESG Statement on Spam Control on IETF Mailing
              Lists", 14 April 2008, <https://datatracker.ietf.org/doc/
              statement-iesg-iesg-statement-on-spam-control-on-ietf-
              mailing-lists-20080414/>.
        
   [MODML]    IESG, "IESG Guidance on the Moderation of IETF Working
              Group Mailing Lists", 29 August 2000,
              <https://www.ietf.org/about/groups/iesg/statements/
              mailing-lists-moderation/>.
        
   [OT]       "Ombudsteam", <https://www.ietf.org/contact/ombudsteam/>.
        
   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.
        
   [RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
              Mailing Lists", BCP 83, RFC 3683, DOI 10.17487/RFC3683,
              March 2004, <https://www.rfc-editor.org/info/rfc3683>.
        
   [RFC3934]  Wasserman, M., "Updates to RFC 2418 Regarding the
              Management of IETF Mailing Lists", BCP 25, RFC 3934,
              DOI 10.17487/RFC3934, October 2004,
              <https://www.rfc-editor.org/info/rfc3934>.
        
   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, DOI 10.17487/RFC7282, June 2014,
              <https://www.rfc-editor.org/info/rfc7282>.
        
   [RFC9245]  Eggert, L. and S. Harris, "IETF Discussion List Charter",
              BCP 45, RFC 9245, DOI 10.17487/RFC9245, June 2022,
              <https://www.rfc-editor.org/info/rfc9245>.
        
Appendix A. Motivation
付録A. モチベーション

Section 1 summarizes the process changes introduced by this memo. This appendix discusses the background that led to them.

セクション 1 では、このメモによって導入されたプロセスの変更を要約します。この付録では、それらに至った背景について説明します。

A.1. Background
A.1. 背景

The IETF community has defined general guidelines for personal interactions in the IETF [RFC7154]. The IESG has defined an anti-harassment policy for the IETF [AHP] for which the IETF community has defined anti-harassment procedures [RFC7776], empowering an Ombudsteam [OT] to take necessary action.

IETF コミュニティは、IETF [RFC7154] で個人的なやり取りに関する一般的なガイドラインを定義しました。IESG は IETF 向けのハラスメント防止ポリシー [AHP] を定義し、IETF コミュニティはこれに対してハラスメント防止手順 [RFC7776] を定義し、オンブズチーム [OT] が必要な措置を講じることができるようにしました。

Dealing with _disruptive_ behavior, however, is not part of the role of the Ombudsteam. [RFC2418] tasks the chairs of each IETF working group with moderating their group's in-person meetings while [RFC3934] provides chairs a procedure to help manage mailing lists. An IESG statement [MODML] describes additional guidance to working group chairs about how -- but not when -- to moderate their lists.

ただし、「破壊的」行為に対処することは、オンブズチームの役割の一部ではありません。[RFC2418] は各 IETF ワーキング グループの議長にグループの対面会議の司会を課し、[RFC3934] は議長にメーリング リストの管理を支援する手順を提供します。IESG 声明 [MODML] では、作業グループの議長に対して、いつではなくどのようにリストを調整するかについての追加のガイダンスが記載されています。

For IETF mailing lists not associated with a working group, another IESG statement [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 [RFC9245].

ワーキング グループに関連付けられていない IETF メーリング リストについては、別の IESG ステートメント [DP] で、IESG タスク リストの管理者にモデレーションが与えられることが明確にされています。そして、一般的な議論のための IETF リストには、主に歴史的な理由から、リスト管理者ではなく、異なる一連のプロセスによって運営されるモデレータのチームが存在します [RFC9245]。

Note that the term "moderation" can refer both to _preemptive_ moderation, where administrators review attempted participation before it occurs (such as reviewing messages to a mailing list), and _reactive_ moderation, where administrators intervene after disruptive participation has occurred. Historically, the IETF has mainly practiced reactive moderation, employing 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.

「モデレーション」という用語は、管理者が参加の試みを事前にレビューする (メーリング リストへのメッセージの確認など) _preemptive_ モデレーションと、中断的な参加が発生した後に管理者が介入する _reactive_ モデレーションの両方を指す場合があることに注意してください。歴史的に、IETF は主に事後対応型のモデレーションを実践しており、リスト内外での穏やかなリマインダーから、投稿権やその他の参加またはコミュニケーション方法の停止に至るまでの措置を採用してきました。手順の一部としてプリエンプティブ モデレーションとリアクティブ モデレーションのどの組み合わせを採用するかを決定するのは、モデレータと管理者の責任です。

In addition, [RFC3683] defines a process for revoking an individual's posting rights to IETF mailing lists following a community Last Call of a "posting rights" action (PR-action) proposed by the IESG, often in response to complaints from the community.

さらに、[RFC3683] は、多くの場合コミュニティからの苦情に応じて、IESG によって提案された「投稿権」アクション (PR アクション) のコミュニティー最終呼び出しに続いて、IETF メーリングリストへの個人の投稿権を取り消すプロセスを定義しています。

Experience and community input suggests that an evolution of the existing processes is necessary.

経験とコミュニティからの意見は、既存のプロセスの進化が必要であることを示唆しています。

A.2. Problems with the Previous Approach
A.2. 以前のアプローチの問題点

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:

議長、リスト管理者、モデレータ チームを通じて破壊的な参加を抑制するこれまでのアプローチと、IESG 主導の PR アクションのプロセスを組み合わせた方法は、理想的とは言えないことが判明しました。

* 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.

* IETF コミュニティは、破壊的な行為の共通の定義について合意できていません。したがって、議長とリスト管理者は意思決定を行う際に個別に異なる基準を適用し、参加者は PR アクションがいつ正当化されるかについて異なる期待を持っています。

* The moderation process that chairs and list administrators need to follow [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.

* 議長とリスト管理者が従う必要があるモデレーションプロセス [RFC3934] は遅くて面倒なため、急速にエスカレートする状況には不向きです。It also assumes that the originator of disruptive behavior is a misguided participant who can be reasoned with and who will change their ways.

* 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.

* 議長とリスト管理者は、単一のリストに対してのみモデレーションアクションを実行できますが、破壊的な行動のパターンが複数のリストにまたがる場合には不適切です。また、議長やリスト管理者は、一部のリストに登録していないため、複数のリストにまたがる破壊的な行為を十分に認識していない可能性があります。

* PR-actions, which can address disruptive behavior across several lists, are cumbersome, 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.

* PR アクションは、複数のリストにわたる破壊的な行為に対処できますが、面倒で時間がかかり、一貫性がありません。このため、PR アクションはめったに使用されず、使用されたとしても非常に高圧的なものとして認識されるという状況が生じています。

* 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.

* 特定のメーリング リストでは、参加者はさまざまな理由から、破壊的な行為を議長またはリスト管理者に報告することに抵抗を感じる場合があります。ワーキング グループに関連付けられていないメーリング リストの場合、リスト管理者は公的に特定されることさえありません。匿名のエイリアス アドレスを介してのみ連絡できます。参加者は破壊的な行為を匿名の相手に報告することに抵抗がある可能性があるため、これが問題を悪化させます。

* Moderation processes have been defined for only two channels of participation in the IETF: in-person meetings and mailing lists. However, IETF business now happens in a number of fora (e.g., chat groups, remote meeting participation systems, virtual meetings, wikis, and GitHub repositories). Procedures for moderating disruptive behavior in these fora are currently undefined.

* モデレーション プロセスは、IETF への参加チャネルとして、対面会議とメーリング リストの 2 つのみに対して定義されています。しかし、IETF ビジネスは現在、多くのフォーラム (チャット グループ、リモート会議参加システム、仮想会議、Wiki、GitHub リポジトリなど) で行われています。これらのフォーラムでの破壊的な行為を緩和するための手順は現在未定義です。

Appendix B. Non-Normative Examples of Disruptive Behavior
付録B. 破壊的な行為の非規範的な例

The list below describes some types of disruptive behavior, but it is non-exhaustive.

以下のリストでは、いくつかの種類の破壊的行為について説明しますが、これがすべてではありません。

* Discussion of subjects unrelated to a forum's charter or scope;

* フォーラムの憲章や範囲に関係のない主題の議論。

* Uncivil commentary, regardless of the general subject;

* 一般的な主題に関わらず、非礼なコメント。

* 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;

* リスト管理者の事前の承認を得て投稿しない限り、Internet Society または IETF によって後援または承認されていないカンファレンス、イベント、または活動を告知するメッセージ。

* Repeatedly arguing counter to a WG charter that has been approved by the IESG; and

* IESG によって承認された WG 憲章に反対する主張を繰り返し行う。そして

* "Sealioning", where a participant makes incessant requests for evidence or data, even while remaining superficially polite.

* 「シーリオニング」では、参加者が表面的には礼儀正しく保ちながらも、証拠やデータを絶えず要求します。

These items are examples. Moderators and administrators may take moderation actions for many other cases.

これらの項目は一例です。モデレーターと管理者は、他の多くのケースに対してモデレーション アクションを実行する場合があります。

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.

モデレーター チームのタスクは主観的な判断で構成されます。ここにリストされていない行動には節度が必要な場合がありますが、そのようなすべての行動の完全なリストを書くことは不可能です。

Acknowledgments
謝辞

This memo is based on two individual Internet-Drafts, draft-ecahc-moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/) authored by Lars Eggert, Alissa Cooper, Jari Arkko, Russ Housley, and Brian E. Carpenter, and draft-lear-bcp83-replacement (https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/) authored by Eliot Lear, Robert Wilton, Bron Gondwana, and John R. Levine. Robert Sayre authored draft-sayre-modpod-excellent (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/), which also originated ideas reflected in this work. Pete Resnick provided the basis for how the moderators interact with list/forum leadership.

このメモは、Lars Eggert、Alissa Cooper、Jari Arkko、Russ Housley、Brian E. Carpenter によって作成された 2 つのインターネット ドラフト、draft-ecahc-moderation (https://datatracker.ietf.org/doc/draft-ecahc-moderation/) と、draft-lear-bcp83-replacement に基づいています。(https://datatracker.ietf.org/doc/draft-lear-bcp83-replacement/) 著者は Eliot Lear、Robert Wilton、Bron Gondwana、John R. Levine です。Robert Sayre は、draft-sayre-modpod-excellent (https://datatracker.ietf.org/doc/draft-sayre-modpod-excellent/) を作成し、この作業に反映されたアイデアもこの人から生まれました。Pete Resnick は、モデレーターがリスト/フォーラムのリーダーとどのように対話するかの基礎を提供しました。

These individuals contributed additional improvements:

これらの人々がさらなる改善に貢献しました。

* Alissa Cooper

* アリッサ・クーパー

* Brian Carpenter

* ブライアン・カーペンター

* Chris Box

* クリス・ボックス

* Colin Perkins

* コリン・パーキンス

* David Schinazi

* デビッド・スキナジ

* Deb Cooley

* デブ・クーリー

* Dhruv Dhody

* ドゥルブ・ドーディ

* Eric Rescorla

* エリック・レスコルラ

* Éric Vyncke

* エリック・ヴィンケ

* Erik Kline

* エリック・クライン

* Harald Alvestrand

* ハラルド・アルヴェストランド

* Jay Daley

* ジェイ・デイリー

* Joel Halpern

* ジョエル・ハルパーン

* John Klensin

* ジョン・クレンシン

* John Scudder

* ジョン・スカダー

* Lisa Dusseault

* リサ・デュッソー

* Martin Thomson

* マーティン・トムソン

* Melinda Shore

* メリンダ・ショア

* Michael Richardson

* マイケル・リチャードソン

* Mike Bishop

* マイク・ビショップ

* Mohamed Boucadair

* モハメド・ブーカデア

* Murray Kucherawy

* マレー・クチェラウィ

* Nick Hilliard

* ニック・ヒリアード

* Orie Steele

* オリー・スティール

* Paul Hoffman

* ポール・ホフマン

* Paul Wouters

* ポール・ウーターズ

* Pete Resnick

* ピート・レズニック

* Rich Salz

* リッチ・ザルツ

* Robert Sayre

* ロバート・セイヤー

* Robert Sparks

* ロバート・スパークス

* Roman Danyliw

* ローマン・ダニリュー

* Russ Housley

* ラス・ハウスリー

* Sean Turner

* ショーン・ターナー

* Simon Josefsson

* サイモン・ジョセフソン

* Stephen Farrell

* スティーブン・ファレル

* Ted Lemon

* テッド・レモン

* Tim Bray

* ティム・ブレイ

N.B., acknowledgment should not be taken as endorsement by the individuals named above.

注意: 謝辞は、上記の個人による承認とみなされるべきではありません。

Authors' Addresses
著者の住所
   Lars Eggert (editor)
   Mozilla
   Stenbergintie 12 B
   FI-02700 Kauniainen
   Finland
   Email: lars@eggert.org
   URI:   https://eggert.org/
        
   Eliot Lear (editor)
   Cisco Systems
   Richtistrasse 7
   CH-8304 Wallisellen
   Switzerland
   Phone: +41 44 878 9200
   Email: lear@lear.ch