RFC 9945には見える発効記録が要る

Summary

RFC 9945は2026年2月にBCP 245として公開され、IETFの公開オンラインフォーラムを横断するモデレーション方針を設けた。ただし新しい変更は、Section 4の手続をIESGが承認した時点で発効し、それまでは従来のプロセスが効力を保つと明記している。
RFC Editorの「obsoletes」、6人の現行チーム、公開SOP、実施件数は、それぞれ別の事実を示す。必要な発効記録は、固定された手続版、コミュニティー入力、IESGの承認行為と発効時刻、旧規則の扱い、対象範囲、役割、継続中案件の移行を結び、通報内容は保護する。

最初に見るべきなのは最新版ではない

ある投稿が6月30日に保留されたとする。7月に異議申立てが行われ、9月に公開手続が更新された。9月の読者にとって最新版は便利だが、6月30日の判断を支えた手続を自動的に置き換えることはできない。

RFC 9945の構造は、この時間差を前提にしている。文書はIETFの公開審査とIESGの出版承認を経て、BCP 245として公表された。RFC 3683とRFC 3934をobsoleteとし、RFC 9245の一部を置き換え、RFC 2418を更新する。

その一方、Introductionの末尾は、変更が発効する条件をSection 4の手続に置く。モデレーターチームはコミュニティーの意見を受けて手続と基準を作る。IESGが発効前に承認し、文書は公開される。RFCシリーズに収録する必要はない。新手続が確立するまでは、Section 1で参照された従来プロセスが残る。

これは、恒久的な枠組みと変更可能な運用層を分離した設計である。新しいチャットや共同作業ツールに対応するたびRFCを改訂しなくてよい。代わりに、権限が切り替わった瞬間はRFC外の承認記録に依存する。

文献上の後継関係は運用時計ではない

RFC 3934の情報ページには、RFC 9945によってobsoleteになったと表示される。古い文書に到達した利用者を後継文書へ案内するうえで、正しい表示である。

しかし、その欄にはSection 4手続の版、ハッシュ、コミュニティー検討期間、IESG決定、発効時刻がない。文献同士の関係は示せても、特定の日にどの手続が実行権限を持っていたかまでは示せない。

したがって、「RFC 3934は文献上obsoleteである」と「RFC 3934のプロセスは移行条項によって一時的に有効である」は両立しうる。前者はコーパスの状態、後者は行為の状態を語る。どちらかを消すと制度を誤って単純化する。

RFC公開をもって旧手続が即日消えたと考えるのも、新手続発効までRFC 9945全体が存在しないと考えるのも正確ではない。必要なのは、公開、承認、発効を別フィールドとして表示し、相互に参照できるようにすることだ。

7月の異議申立てが時点の意味を示した

Andrew Leeは2026年6月30日、TLS Working Group Last Call中のモデレーションをめぐりIESGへ異議申立てを行った。主張の一つは、RFC 9945がRFC 3934をobsoleteとした以上、後者は権限の根拠にならないというものだった。

IESGは7月9日に申立てを棄却した。この点については、RFC 3934がなお有効だと明示した。RFC 9945 Section 4が、新しい手続と基準の確立まで従来プロセスを維持しているからである。また、BCP 9自体はモデレーション権限を与えないが、その追加的な引用だけで措置全体が無効になるわけではないと整理した。

この記事は当事者の是非を再審査しない。公開資料は、censorship、偏見、違法性、不正行為を証明しない。IESGの回答があらゆるモデレーション行為の公正さを保証するわけでもない。申立てに含まれた技術的見解、recusal、選択的執行、少数意見に関する論点には、IESGが別途答えている。

ここで確定できるのは限定的な事実だ。7月9日の判断では、どの手続が適用されるかを決めるために移行条件が使われた。「obsolete」の一語だけでは足りなかった。

その回答は7月9日の状態を示すが、将来を固定しない。9月11日までに確認した公式資料の中では、新しいSection 4手続の特定版をIESGが後に承認した公開行為を見つけられなかった。検索で見つからないことは不存在の証明ではない。ただし、公開と承認を要件にする制度で発見が難しいなら、権限の索引が不足している。

チームページとSOPは違う問いに答える

Datatrackerのietfmoderatorsページは、Activeな6人のIETF Moderator Teamを掲載している。説明はRFC 9945の広い役割に沿う。現在と将来の公開フォーラムの手続を設け、コミュニティーの資源となり、plenary forumと管理者不在のフォーラムを担当し、IESGに任命され責任を負う。

このページは役割と人を特定する。承認された手続の不変な版や発効時刻は特定しない。

一方、ietf/Moderatorsリポジトリを固定commit b907805e15…で読むと、READMEは主にIETFの一般討議リストとRFC 9245を対象にしている。SOPは3人を列挙し、措置には少なくとも2人の合意を求め、Level 0、1、2の段階を示す。統計ファイルはその区分で件数を集計する。

差異は管理不全の証拠ではない。一般討議リスト向けの従来資料かもしれない。新チームは別の場所で作業しているかもしれない。名簿更新が遅れているだけかもしれない。移行条項の下で旧SOPが一時的に正当である可能性もある。

複数の無害な説明がある以上、参加者に正解を推測させてはならない。チームページはappointment、commitはtext、統計はclassification useを証明する。発効には「この版を、この範囲について、IESGが承認し、この時刻から効力を持たせた」という別の証拠が要る。

権限を一か所に集めない設計

各フォーラムのadministratorが第一の責任を持つ。Working Groupではchairsが既定のadministratorであり、作業を委任しても、通報を受け、受領を知らせ、追跡しなければならない。チームと協議した後なら、moderatorが行った措置を修正または撤回できる。

Moderator Teamは共通手続を作り、助言し、administratorが適時に応答しない場合や行為が複数フォーラムに及ぶ場合に介入できる。通常はまず担当administratorに連絡する。plenary forumと他に担当者のいない公開空間では直接administratorとなる。

Area Directorが最初の衝突を扱う。IESGは手続を承認し、メンバーを任免し、チームを評価し、異議申立て経路を担う。RFC 2026に従ってさらにIABへの経路がある。Ombudsteamはanti-harassmentの任務を維持する。IETF Administration LLCは深刻な法的リスクに関する助言を受けた稀な緊急時に、別系統で行動する。

IRTF、IAB、RSWG、RSAB、Independent Submission streamには、明示的合意なしに自動適用されない。分散は権力の集中を防ぐが、審査時に版と範囲を取り違える危険を増やす。今日の最新版ではなく、原措置の日に有効だったものが必要になる。

旧制度も単一ではなかった

RFC 3934はWorking Group mailing list上の措置をchairsに与えた。RFC 3683はコミュニティーとIESGを通じたposting rights actionを定めた。RFC 9245はIETF一般討議リストを規定した。RFC 2418はchairsの広い責任を定め、RFC 2026は異議申立ての基礎を提供した。

RFC 9945の動機には、基準の不均一、旧手続の遅さ、複数リストにまたがるパターン、そしてchat、wiki、GitHub、GitLab、issue trackerなどメール外の作業面がある。横断チームと共通方針は現実の必要に応える。

ただし、旧プロセスが移行中に残るからといって権限が無限定になるわけではない。Datatracker accountの削除、対面・オンライン会議への参加制限、content removal、privateまたはnon-IETF communicationは通常のmoderator actionの範囲外である。

過去の措置にも版が付く。新プロセス前に無期限停止となった人のreinstatementは、原決定時のプロセスで再考される。RFC 9945自身が、後の更新で歴史を塗り替えない原則を置いている。

発効記録は一枚でよい

最初に承認対象を固定する。procedure revision、SHA-256、永続URL、対象となるforum classを記録する。可変なmainは最新情報には便利だが、過去の権限証明には単独で使えない。

次に承認行為を置く。community inputの期間、主要意見へのdisposition index、IESG決定、決定時刻、発効時刻を分ける。段階導入ならスケジュールを明示する。

旧規則との対応表も必要だ。終了する条項、既存措置に残る条項、範囲外組織、LLC緊急経路を区別する。チームの任命期間は別表にし、人の存在が手続承認の代替にならないようにする。

移行中の通報、制限、異議申立て、reinstatement clockは保護された台帳で管理する。公開層は件数、版区分、移行方針だけでよい。発効日をまたぐ案件では、どの規則を選んだかを記録し、後から静かに置き換えない。

各フォーラムのadministratorと技術運用者は導入版をacknowledgeできる。これは権限を作らず、中央承認が実行点に届いたことを示す。修正は履歴を上書きせず、superseding recordとしてつなぐ。

人を公開せずに権限を公開する

通報には氏名、私的文脈、有害な表現が含まれうる。全面公開すれば、被害を反復し、通報者と対象者をさらにさらす。法的助言が通知を制限する場合もある。透明性はraw case fileの公開を意味しない。

発効記録の公開部分は、規則のhash、approval、scope、effective time、supersession、役割、訂正だけで成立する。個別措置は別の保護記録で、notice、reason class、範囲、期間、decision-maker、review、appealを結ぶ。

証拠の目的も分けるべきだ。正しく発効した手続は各判断の公正さを証明しない。通知は申し立てられた行為を自動的に証明しない。集計値は個別の一貫性を証明しない。名簿は手続の発効を証明しない。

Heng Luの文章はここで状態を分ける視点を与えるが、IETFについての事実証拠ではない。文書ラベル、実行可能な決定、観測された結果は別の層にある。最小初期仕様は必要なjoinだけを固定し、後の選択は権限を持つ主体に残す。

RFC 9945は、幅広い公開フォーラム、迅速な対応、権限の限界、再考、異議申立てを一つの枠組みにした。運用詳細をRFCに凍結しないことも合理的だ。その柔軟性を信頼できるものにする鍵は、単純である。teamは「誰」を示す。procedureは「どう」を示す。IESG approvalは「どの権限で」を示す。effective timeが初めて「いつ」を示す。

RFC 9945のモデレーターチームは発効証明ではない

なぜ重要か

Summary

最初に見るべきなのは最新版ではない

文献上の後継関係は運用時計ではない

7月の異議申立てが時点の意味を示した

チームページとSOPは違う問いに答える

権限を一か所に集めない設計

旧制度も単一ではなかった

発効記録は一枚でよい

人を公開せずに権限を公開する

Sources

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説