要約

  • ICANNの基本文書は、固有識別子システムの調整という使命を定める一方、インターネット上のサービスやコンテンツを一般的に規制する権限を認めるものではない。[FACT_PACKAGE_SOURCE_0]
  • 実際の運用上の強制力は、コミュニティー・ポリシーの契約への組み込み、レジストリ・レジストラ契約、契約上のコンプライアンス手続き、そして対象となる当事者に応じた再審査・独立審査の経路から生じる。[FACT_PACKAGE_SOURCE_2]

権限は一つの根拠から生じない

ICANNを政府規制機関のように扱うと、権限の仕組みを取り違える。ICANNの設立文書は、同組織をカリフォルニア州の非営利公益法人として位置づけ、インターネットの固有識別子システムの調整と運用上の安定性を中心に据えている。[FACT_PACKAGE_SOURCE_1] そのうえで、Bylawsは使命、公益上のコミットメント、透明性、ボトムアップの政策形成、客観性や公平性といった基準を、権限の根拠であると同時に制約として置く。[FACT_PACKAGE_SOURCE_0]

したがって、特定のICANN措置を評価する際に最初に問うべきなのは、「ICANNに権限があるか」という抽象的な問いではない。「その措置は、使命、ポリシー、契約、理事会決議、または別の手続きのどれによって認められているのか」である。Bylaws上の使命が、実際の契約条項や個別の執行結果を自動的に正当化するわけではない。適用される版、発効日、個別契約、当事者の地位を確認しなければならない。

ポリシーが契約上の義務になるまで

コミュニティーが作るConsensus Policyも、それ自体があらゆる主体に直接命令する一般法になるわけではない。適格なポリシーが所定の政策形成手続きを経て、適用されるレジストリ契約やRegistrar Accreditation Agreementに組み込まれることで、対象となる契約当事者に対する義務として作用する。[FACT_PACKAGE_SOURCE_5] したがって、同じポリシーを見ても、誰に適用されるか、どの契約版が有効か、実施通知や移行条項があるかによって結果は変わり得る。

レジストリ契約の一覧は、各TLDを運営する事業者の義務を確認する入口になる。[FACT_PACKAGE_SOURCE_2] 新gTLDの基本契約資料は、仕様書、公益上のコミットメント、セキュリティー、継続性、データ・エスクロー、乱用対応、監査、終了や移行などを契約上の構造に変換する候補資料を示す。[FACT_PACKAGE_SOURCE_3] ただし、基本契約の雛形だけでは特定のレジストリに適用される条件を証明できない。実行済み契約、後日の包括修正、個別修正、TLD固有の仕様が優先する。

レジストラについては、認定契約が、Consensus PolicyやTemporary Policyへの遵守、登録データ、データ保持、乱用窓口、登録者の権利、プライバシー・プロキシサービスなどの運用義務を契約上の関係に置く。[FACT_PACKAGE_SOURCE_4] ここでも、ICANNの権限は無限定の規制権限ではなく、契約によって定められた範囲の執行権限である。

運用上の結果を生む経路

Registry Services Evaluation Processは、レジストリが新しい、または変更されたサービスを提案した際に、セキュリティー、安定性、競争上の影響を検討するための具体的な経路を示す候補資料である。[FACT_PACKAGE_SOURCE_6] この制度は、ICANNの判断が政策文書だけでなく、申請、技術評価、決定、契約上の義務という連続した記録を通じて現れることを示す。ただし、RSEPの仕組みをすべての理事会判断、レジストラ問題、ポリシー争いに一般化することはできない。

契約上のコンプライアンスでは、苦情、監視、監査、情報要求、是正期間、正式な違反通知、場合によっては停止や終了などが、関連契約に従って進む。[FACT_PACKAGE_SOURCE_7] プロセス説明は、非公式な解決から正式な執行へ移る場合の流れを補助的に示すが、運用ガイダンスが契約そのものを拡張するわけではない。[FACT_PACKAGE_SOURCE_8]

公表された執行通知は、問題となった条項、ICANNが主張する事実、期限、是正要求、可能な制裁を確認する重要な資料になり得る。[FACT_PACKAGE_SOURCE_9] しかし、通知はICANN側の執行上の立場を記録するものであり、必ずしも最終的な裁定ではない。苦情の受付経路も、契約当事者に対するコンプライアンス調査を始める方法であって、裁判所の判決や一般的な上訴制度ではない。[FACT_PACKAGE_SOURCE_10]

争う方法は立場によって変わる

ICANNの措置に異議を唱える人が、すべて同じ救済を利用できるわけではない。Bylaws、再考請求の資料、Independent Review Processの資料は、一定のICANNの作為・不作為を対象にする正式な説明・審査経路を示す候補資料である。[FACT_PACKAGE_SOURCE_13] [FACT_PACKAGE_SOURCE_14] [FACT_PACKAGE_SOURCE_15] IRPの補足手続きも、その制度が独自の基準と手順を持つことを示す。[FACT_PACKAGE_SOURCE_15]

一方、契約上のコンプライアンス苦情は、通常、レジストリやレジストラの契約違反をICANNに知らせる経路である。再考請求やIRPと同じ目的ではない。Cooperative Engagement、情報公開請求、オンブズマン、Complaints Office、Empowered Communityにもそれぞれ別の範囲と効果がある。[FACT_PACKAGE_SOURCE_16] [FACT_PACKAGE_SOURCE_17] [FACT_PACKAGE_SOURCE_18] [FACT_PACKAGE_SOURCE_19] [FACT_PACKAGE_SOURCE_20]

この区別は、結果の可逆性を判断するうえで重要である。契約当事者への是正要求、理事会決定への再考請求、IRPによる審査、裁判所での司法審査は、対象、期限、基準、実行主体が異なる。ある経路が開いていることは、別の経路で同じ結果を止めたり取り消したりできることを意味しない。

読者が確認すべき文書

特定のICANN措置を検証するには、少なくとも次の順序が必要になる。第一に、決定日当時のBylawsとArticlesで使命と制約を確認する。第二に、適用されるConsensus Policyと政策形成・実施記録を確認する。第三に、対象レジストリまたはレジストラの実行済み契約、修正、仕様書、発効日を確認する。第四に、実際に発出された通知、情報要求、是正結果、理事会決議を時系列で並べる。最後に、申立人の地位に応じて、苦情、再考請求、IRP、オンブズマン、情報開示その他の経路が何を審査し、どのような結果を生み得るかを分けて読む。

今回確認できたのは、公式ICANNの文書位置と、そこから得られる証拠候補である。ライブのページ本文、現行の修正、発効日、個別の執行結果はこの調査では検証されていない。そのため、ここで示したのは特定の措置が適法だったという結論ではなく、権限を検証可能な文書の連鎖として読むための枠組みである。

Sources

関連ディレクトリ項目: https://btw.media/ja/directory/internet-corporation-for-assigned-names-and-numbers