メインコンテンツへスキップ

ガバナンス

ガバナンス

ガバナンスは、インターネット基盤に影響を与え得る機関、政策プロセス、標準化活動、レジストリ運用、説明責任をめぐる紛争、実装シグナルを追跡します。BTW.MEDIA は、公開された報道、出典に基づく分析、制度的背景、長期にわたるケースの継続報道を整理し、読者が世界のネットワークエコシステム全体で、意思決定のポイント、ガバナンス上のリスク、運用の継続性、正統性をめぐる論点、政策の結果を追えるようにしています。RIR や標準化団体、ICANN のプロセス、ネットワーク運用者グループ、公共政策に関わる主体、説明責任をめぐる紛争、裏付けとなる証拠を比較したい読者は、このページで、どのプロセスが単なる手続きに過ぎないのか、どのシグナルが運用上の前提を変え得るのか、どのコミュニティが影響を受けやすいのかを確認できます。

RIR監視ケースファイル番号資源コミュニティICANNIETFインターネット史ネットワーク運用者グループ
ガバナンス のシグナル画像
ガバナンスガバナンス
焦点機関ガバナンス

インターネット運営・政策を担う機関における政策継続性・正当性・説明責任のシグナルを追跡します。

現在7つのガバナンス・トラック

RIR監視、ケースファイル、番号資源社会、ICANN、IETF、インターネット史、NOG セッションを含みます。

シグナル実行重視

表明された立場よりも、実施の証拠と機関の行動を重視します。

最新の報道

ガバナンスの最新情報

7,703件の記事

RIPE ABUSE:連絡先から救済まで、管理権限はどこで移るのか

記事

RIPE ABUSE:連絡先から救済まで、管理権限はどこで移るのか

RIPE Database の abuse-c は、インターネット番号資源に関する不正利用の報告先を示す。しかし、連絡先が公開され、メールボックスが検証されても、それだけで報告が読まれ、調査され、技術的な是正措置が実施され、再発が防止されたことにはならない。実際に問うべきなのは、報告が送られた後に、どの主体が何を管理し、どの段階で救済を求める先が変わるのかである。

2026年9月9日
APNICとNIXIのインドROV計画は、一つの割合では完了を証明できない

記事

APNICとNIXIのインドROV計画は、一つの割合では完了を証明できない

2026年9月8日のインドについて、APNIC Labs の時系列は約1.14%とも約6.03%とも読める。どちらも同じ日のデータであり、異なるのは集計期間だ。新たな ROV 協力が最初に守るべきものは、見栄えのよい一つの値ではなく、その値が何を数え、どの制御点までを示すのかという境界である。

2026年9月9日
コントローラは状態を受信した。しかし時刻の証明は残っていない:RFC 9857

ケースファイル

コントローラは状態を受信した。しかし時刻の証明は残っていない:RFC 9857

RFC 9857 は SR Policy の候補パス状態を外部コンポーネントへ運ぶ。受信済みという事実を運用判断へ昇格させるには、観測者、世代、SRPM、FIB、実トラフィック、サービス結果を別々の証拠として結び直す必要がある。

2026年9月9日
Jon Callasと、一つの鍵を一意に示さなかったOpenPGP Key ID

IETF

Jon Callasと、一つの鍵を一意に示さなかったOpenPGP Key ID

短い識別子は鍵を探す入口にはなる。だが検索結果の先頭を、その人の唯一の鍵や行為の権限へ変える保証はない。

2026年9月9日
TLSスイートの非推奨指定は、端点での無効化を意味しない

IETF

TLSスイートの非推奨指定は、端点での無効化を意味しない

RFC 10015は、TLS 1.2と DTLS 1.2に残る古い鍵交換の扱いを厳格化した。しかし、IANA の欄に付いた`D`は、ロードバランサーの設定を書き換えず、プロセスを再読込せず、見落とされた終端装置を探してもくれない。規範が変わった事実と、稼働状態が変わった事実は別々に立証する必要がある。

2026年9月9日
メモはネットワークに命令できなかった:RFC 1958 と変更する権利

インターネット史

メモはネットワークに命令できなかった:RFC 1958 と変更する権利

「原則」を掲げる文書が最初に置いたのは、永続する原則ではなく、その原則さえ古くなるという留保だった。RFC 1958 の強さは設計図の完全さではなく、設計図を実装の反証にさらした点にある。

2026年9月9日
委任にはプリンシパルが署名した。それでもエージェント鍵を結び付けたのは発行者だ

IETF

委任にはプリンシパルが署名した。それでもエージェント鍵を結び付けたのは発行者だ

二つの署名が両方とも正しくても、同じ権限を証明しているとは限らない。AIC-JWT の新しい版は、プリンシパルが署名した委任を発行者のトークンに入れる。同時に、エージェントの名前と、そのエージェントが提示する鍵との間に誰の署名があるのかを分けている。

2026年9月9日
新しいエントロピーはセッションに入った。それでも復旧には双方向の証明が要る

IETF

新しいエントロピーはセッションに入った。それでも復旧には双方向の証明が要る

通常の TLS 1.3 KeyUpdate は、すでに存在する秘密の連鎖を次へ進める。Extended Key Update の草案は、稼働中のセッション内でもう一度鍵交換を行い、新しい共有秘密を後継状態に混ぜる。それは侵害後の復旧機会をつくるが、過去の状態が消えたことやアプリケーションが戻ったことまでは証明しない。

2026年9月9日
URL が運んだのは検索であり、権限ではない:RFC 1959

インターネット史

URL が運んだのは検索であり、権限ではない:RFC 1959

三つ目のスラッシュの後にディレクトリ名を書けば、サーバー名のない LDAP URL を作れた。短い文字列はどこへ問い合わせるかさえ決めたように見える。しかし RFC 1959 が共通化したのは検索の表現であり、サーバーの選択、接続時の主体、閲覧許可、返答の完全性、利用側の判断までは共通化していない。

2026年9月9日
`_for-sale`レコードは売却意思を示すが、売り手の権限は証明しない

IETF

`_for-sale`レコードは売却意思を示すが、売り手の権限は証明しない

DNS に「このドメイン名は譲渡可能だ」と掲示できれば、買い手は交渉の入口を見つけやすくなる。しかし、その掲示だけでは、誰が保有者を拘束できるのか、提示額が今も有効なのか、移転が完了するのかは分からない。RFC 10023が機械可読にしたのは発見のための意思表示であって、取引の権限証明ではない。

2026年9月9日
Nathaniel Borensteinと、機密性を約束しなかったBase64

IETF

Nathaniel Borensteinと、機密性を約束しなかったBase64

読みにくい文字列は、秘密の容器とは限らない。Base64 が保証するのは所定の規則でバイト列を戻せることまでであり、その先の信頼は別の証拠に属する。

2026年9月9日
二つの送信源、一つの選択、それでも受信継続性は未証明:RFC 9856

ケースファイル

二つの送信源、一つの選択、それでも受信継続性は未証明:RFC 9856

冗長化された送信源が二つ見えることと、受信者が一つの正しいストリームを途切れなく得ることは別の事実である。RFC 9856 は EVPN 内の選択を整えるが、サービスの判定までは代行しない。

2026年9月9日
RIPE NCCはRISのベアメタル移行を終えた。それでもパイプライン全体は完了ではない

記事

RIPE NCCはRISのベアメタル移行を終えた。それでもパイプライン全体は完了ではない

「移行完了」という判定は、対象を一語でも広げれば別の主張になる。RIPE NCC が完了したと記したのは RIS/RIPEstat のデータ移行だ。その周囲では Kafka の更新、HBase 依存を減らす検討、処理監視、RIPEstat の遅延対策がそれぞれの時計で動いている。必要なのは完了を疑うことではなく、その射程を保存することだ。

2026年9月9日
Sirius Telecomは実在するネットワーク事業者なのか――公開記録が示す確認の空白

ケースファイル

Sirius Telecomは実在するネットワーク事業者なのか――公開記録が示す確認の空白

Directory 上ではグローバルなネットワーク事業者として扱われ、PeeringDB のネットワーク番号1283とも結び付けられている。しかし、確認できる公開記録は、Sirius Telecom がどの法人によって運営され、どのネットワーク資産を実際に管理し、どの顧客や通信事業者と関係を持つのかを、まだ独立して立証していない。重要なのは、見つからないことを「存在しない」と読み替えることではない。問題は、Directory の記録から実際の運用と市場上の影響へ移るための証拠の連鎖が、どこで途切れているかである。

2026年9月9日
パラメータ集合は検証できても、署名状態は証明されない:RFC 9858

ケースファイル

パラメータ集合は検証できても、署名状態は証明されない:RFC 9858

RFC 9858 は HSS/LMS に新しいハッシュと安全強度の選択肢を加えた。しかし、ステートフル署名の核心は変わらない。検証者が一つの署名を正しいと判定できても、並行処理、障害復旧、古いバックアップ、鍵の枯渇を通じて同じワンタイム葉が二度使われていないことまでは分からない。

2026年9月9日
RFC 10040予定稿はMap-Replyに署名できても、位置を検証できない

IETF

RFC 10040予定稿はMap-Replyに署名できても、位置を検証できない

封印が本物でも、中に入っている座標が現地で正しく測られたとは限らない。RFC 10040予定稿は出版直前まで進んだ。そこで見えてくるのは LISP の新しい位置表現だけではなく、署名が証明する範囲と、現実世界の観測が必要とする証拠の切れ目である。

2026年9月9日
ICANNの異議申立ては、どの機関を動かせるのか

ICANN

ICANNの異議申立ては、どの機関を動かせるのか

ICANN の説明責任制度は、単一の「不服申立て」ではない。取締役会の特定の決定を拒否する権限、スタッフや取締役会の行為について再考を求める手続、そして定款または付属定款との不整合を独立パネルに審査させる手続は、それぞれ権限の根拠、開始できる主体、判断主体、期限、救済の範囲が異なる。重要なのは、異議が存在することではなく、どの制度上の入口が、どのような結果を生むのかである。

2026年9月9日
標準化はどこで運用依存になるのか――IETFの仕様、ネットワークの継続性、測定の限界

IETF

標準化はどこで運用依存になるのか――IETFの仕様、ネットワークの継続性、測定の限界

IETF の標準はネットワークを直接運用しない。それでも、QUIC、HTTP/3、DNSSEC、BGP、PIM-SM のような仕様が実装されると、接続の維持、経路の回復、名前解決の検証、マルチキャストの到達性は、標準文書だけでは完結しない複数の運用主体に分散する。問題は、仕様が存在するかではなく、障害時にどの主体が状態を戻せるかである。

2026年9月9日
RFC 10028はIPv6マルチキャスト空間の境界をどう制度化したか

インターネット史

RFC 10028はIPv6マルチキャスト空間の境界をどう制度化したか

RFC 10028は、IPv6 マルチキャストアドレス空間の分類を更新する技術標準である。しかし、その意味はアドレス表の整理だけではない。RFC 本文と IANA レジストリを組み合わせることで、IETF の合意が、将来の割り当てを制約する行政的な境界へ変わる過程が見えてくる。公開資料が示すのは、規範と登録の仕組みであり、既存のソフトウェア、運用設定、実際のトラフィックがその境界を採用したことまでではない。

2026年9月9日
APNIC地域で4,611台のBGPルーターが露出 スキャンだけでは開放理由が分からない

記事

APNIC地域で4,611台のBGPルーターが露出 スキャンだけでは開放理由が分からない

APNIC 62で、制御プレーンの見えにくい問題が地域別の数字として示された。2月の IPv4 スキャンでは、APNIC 地域の1,343 AS に属すると推定された4,611台が、求められていない BGP OPEN 交換に応答した。単なる開放ポート検出より踏み込んだ証拠だが、侵害報告でも現在の台帳でもない。必要なのは、対象を公表せずに通知、運用者の判断、再測定をつなぐ記録だ。

2026年9月9日

セッションマップ

ガバナンス分野

RIR監視

割り当て政策、理事会の正統性、機関の継続性を追跡する5つの地域セッション。

RIR監視を開く

ケースファイル

長期のガバナンス調査資料。法務・選挙・制度のストレス分析を扱います。

ケースファイルを開く

番号資源社会

NRS エコシステムから得られる、会員制度・憲章・資源ガバナンスの調査・分析。

NRS セッションを開く

ICANN

DNS の調整、説明責任の枠組み、グローバルなマルチステークホルダープロセスの力学。

ICANN セッションを開く

ネットワーク運用者グループ

APRICOT と地域・国別 NOG エコシステムから得られる運用者向けの実装ノウハウ。

NOG セッションを開く