Skip to main content
Resources

WHOISとプライバシー法の競合に対処するためのICANNの手順の改訂版

このページは以下の言語でもご覧いただけます。

発効日:2017年4月18日

WHOIS手順の改訂版のレッドライン版を表示

概要と背景

0.1 2003年12月[1]、GNSOのWHOISタスクフォース2は、gTLDレジストリ/レジストラがWHOISの個人情報に関するICANN契約条項を完全に遵守することが現地の法律により妨げられていることを示すことができる手順の開発を勧告しました。

0.2 2005年11月[2]、GNSOはそのような手順を確立するためのポリシー策定プロセスを完了しました。これは、WHOISタスクフォースによって勧告され、GNSO評議会によって承認された「手順に関する十分に開発された助言」に従うものです。[3] 2006年5月、ICANN理事会[4]はこのポリシーを採択し、ICANNスタッフに競合に対処するための手順を作成し、公的に文書化するよう指示しました。

0.3 2006年12月3日、ICANNスタッフは、WHOISとプライバシー法の競合に対処するためのICANNの手順の草案を公開しました[脚注を挿入、http://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]。ICANNは、政府諮問委員会(GAC)に対して手順の草案に関する意見の提供を求めました。改訂された文言は、後述のセクション1.4に組み込まれています。

0.4 2015年10月5日、WHOISと国内法の競合に関する実施諮問グループ1は、この手順の改善の可能性について概説したレポートを発表しました。2015年10月5日から11月17日まで、諮問グループのレポートに対するパブリックコメントが求められました。最終レポートはGNSO評議会に提出され、2016年5月の会議で審議されました。

0.5 以下に概説する手順は、WHOIS経由での個人データの収集、表示、配布に関するICANN契約条項の遵守が地方/国内のプライバシー法または規則によって妨げられていることをレジストラ/レジストリ[5]が示す場合に、ICANNがどのように応答するのかを説明しています。この手順は、ICANNスタッフが使用するためのものです。この手順は、影響を受けるgTLDレジストリ/レジストラが実行可能なアクションを含んでいますが、レジストリ/レジストラまたは第三者に新たな義務を課すものではありません。これは、他の法的義務とWHOISに関するICANNの契約上の要件との間に競合が生じる可能性がICANNに報告された場合に実行されるステップについて、レジストリ/レジストラおよび他の当事者に情報を提供することを目的としています。

ステップ1:

  1. WHOIS 手続きの通知

    1.1 レジストラ/レジストリは、レジストラ認定契約(以下、「RAA」)、またはWHOIS経由での個人識別可能データの収集、表示、または配布に関するその他のICANNとの契約の条項の遵守に影響を及ぼす可能性のある調査、訴訟、規制上の手続き、またはその他の政府または民事訴訟(以下、「WHOIS手続き」)の通知を受けた際には、早期の適切な時点でICANNスタッフに以下の情報を提供する必要があります。

    • 行為の性質と状態(問い合わせ、調査、訴訟、制裁の脅威など)と可能な結果の範囲の概要説明。
    • 問題解決に責任を負うレジストラ/レジストリの担当者の連絡先情報。
    • (該当する場合)管轄の政府機関またはその他の申立人の連絡先、およびICANNが当該当局者または申立人に連絡することを許可するレジストラ/レジストリの説明文書。レジストラ/レジストリがそのような許可を与えることが適用される法律によって妨げられる場合は、通知にその旨を記載する必要があります。
    • 現地の政府機関またはその他の申立人が行為または調査の根拠とする適用法または規制の文言(そのような情報が政府機関またはその他の申立人によって示唆されている場合)。
    • 現地法とICANNに対する義務の両方の要件を満たすために実行された取り組みの説明。

    1.2 通知要件を満たすことにより、レジストラ/レジストリは、法律顧問が最善と判断した方法および方針により、調査に参加し、裁判所の命令、規制、または執行機関に対応できます。

    1.3 WHOIS手続きの状況に照らして、レジストラ/レジストリはICANNに対して、WHOIS手続きの結果が出るまで当事者間のすべての連絡を機密に保つよう要求できます。ICANNは通常、ICANNの業務に適用されるその他の法的責任と透明性の基本原則により対処可能な範囲で、かかる要求に好意的に応答します。

    1.4 WHOIS手続きの対象となるレジストラまたはレジストリは、国内の法規制および国際的な法令ならびに適用される国際条約に準拠して活動するように、関連する国の政府と協力する必要があります。

  2. 代替トリガー:政府機関からの説明文書

    1.5 WHOIS手続きがない場合、レジストリまたはレジストラは政府機関からの説明文書をICANNに提出できます。

    • (1) 先立つ事実。以下の例を含みます。
      • (i) 当該の契約当事者(レジストラまたはレジストリ)
      • (ii) 政府機関が審査したサービス/登録契約の適用される条項
      • (iii) 当該のICANN契約の適用される条項
      • (iv) 検討した適用法
    • (2) 政府機関が発見した国内法と契約の義務の矛盾の特定と検討。それぞれの具体的な条項を明記します。
    • (3) 政府機関が、契約上の義務と矛盾していることを発見した国内法を執行する法的権限を有しており、そのような執行のために契約当事者を管轄していることの証明

ステップ2:協議

2.1 協議プロセスの目標は、レジストラ/レジストリが契約上のWHOISの義務を可能な限り遵守する能力を維持する形で問題を解決することです。

2.1.1 状況に応じて実用的でない場合を除き、ICANNは通知を受け取って審査した時点でレジストラ/レジストリと協議します。適切な場合、ICANNはレジストラ/レジストリとともに地方/国の執行機関またはその他の申立人と協議します。

2.1.2 ICANNの政府諮問委員会の助言に従い、ICANNは、ICANN WHOISの要件からの免除の申請の権限について、関連する国の政府に助言を求めます。

2.2 WHOIS手続きが変更を必要とせずに終了した場合、またはレジストラ/レジストリの慣行で必要とされる変更がRAAまたはその他の契約上の義務から逸脱するとICANNが判断する場合、ICANNとレジストラ/レジストリはさらなる措置を講じる必要がありません。

2.3 協議プロセスが行われる前に、レジストラ/レジストリがWHOIS関連の契約上の義務の遵守に影響を及ぼす慣行を変更するように地域の法執行機関または裁判所に求められた場合、レジストラ/レジストリは変更とその根拠となる法律/規制についてICANNに速やかに通知する必要があります。

2.4 レジストラ/レジストリはICANNに対して、WHOIS手続きの結果が出るまで当事者間のすべての連絡を機密に保つよう要求できます。ICANNは通常、ICANNの業務に適用されるその他の法的責任と透明性の基本原則により対処可能な範囲で、かかる要求に好意的に応答します。

2.5 代替トリガーが適用される場合、協議ステップに公開協議を含め、すべての利害関係者が通知ステップで提出された説明文書を審査し、そのすべての側面について意見を述べることができるようにします。このような場合、ICANNは、本手順のセクション2.1.2に従って、当該国のGACの代表(存在する場合)とも協議します。

ステップ3:法律顧問の検討と勧告

3.1 WHOIS手続きがWHOISの契約上の義務の遵守を妨げる変更(上記の協議プロセスの前、最中、または後)を必要とするとICANN法律顧問事務所が判断する場合、ICANNスタッフはレジストラ/レジストリの違反に対する執行措置の実行を暫定的に控え、ICANNは公開レポートと勧告を作成し、これをICANN理事会に提出して判断を仰ぎます。レポートを公開する前に、レジストリ/レジストラはレポートの特定の情報(レジストリ/レジストラとICANNの間のやりとり、その他の部外秘/機密情報を含みますが、これらに限定されません)を訂正するよう要求できます。法律顧問は、ICANNへの法的助言やICANN法律顧問からの助言に関連するレポートの公開バージョンから、法律顧問がICANNの特権やあり得る義務により制限すべきであるとみなした助言または情報を訂正できます。そのようなレポートは、次のような情報を含むことがあります。

  1. 競合に関連する法律または規制の概要。
  2. レジストリまたはレジストラの契約上のWHOIS義務の、完全な遵守が妨げられている具体的な部分。
  3. 協議プロセスの概要(ステップ2で行われた場合)。
  4. 問題解決方法の勧告。ICANNは、特定された1つ以上のWHOIS契約条項からの例外を当該の競合が適用されるレジストラ/レジストリに認めるかどうかを含めることがあります。このレポートは、勧告が承認または却下された場合のインターネットの固有の識別子システムの運用上の安定性、信頼性、安全性、またはグローバルな相互運用性への予期される影響を含む、勧告を正当化する詳細な根拠を含む必要があります。

3.2 レジストラ/レジストリには、理事会に意見を述べる合理的な機会が与えられます。レジストラ/レジストリは、理事会決議の前に、ICANNがそのようなレポートを秘密にすることを要求できます。ICANNは通常、ICANNの業務に適用されるその他の法的責任と透明性の基本原則により対処可能な範囲で、かかる要求に好意的に応答します。

3.3 代替トリガーが適用される場合、理事会は、通知ステップで提出された説明文書に対して寄せられたパブリックコメント、および当該国のGACの代表(存在する場合)から受け取った見解を、本手順のセクション2.1.2に従って検討します。

ステップ4:解決

4.1 インターネットの固有の識別子システムの運用上の安定性、信頼性、安全性、グローバルな相互運用性への予期される影響を考慮して、理事会は可能な限り速やかに法律顧問のレポートに含まれる勧告を検討し、適切な措置を講じます。措置には、以下が含まれますが、これらに限定されません。

  • レポートの勧告を承認または拒否する(変更の有無にかかわらず)。
  • 影響を受けるレジストラ/レジストリまたは第三者からの追加情報を求める。
  • レポートのパブリックコメント期間を計画する。
  • レポートをGNSOに提出し、特定期日までに審査して意見を提供するよう求める。

ステップ5:公示

5.1 問題に対する理事会の決議は、通常は法律顧問のレポートと共に公表され、今後の調査のためにICANNのWebサイトに掲載されます(他の関連資料とともに)。そのような情報を公開する前に、レジストリ/レジストラは公示の特定の情報(レジストリ/レジストラとICANNの間のやりとり、その他の部外秘/機密情報を含みますが、これらに限定されません)を訂正するよう要求できます。法律顧問は、ICANNへの法的助言やICANN法律顧問からの助言に関連するレポートの公開バージョンから、法律顧問がICANNの特権やあり得る義務により制限すべきであるとみなした助言または情報を訂正できます。訂正によってレジストリ/レジストラが行った措置の性質を公に伝えることが困難になる場合、ICANNは、状況に応じて実用的な方法で、実行される措置およびそのような措置の正当性を説明する適切な通知を提供します。

5.2 理事会が別段の決定を下さない限り、問題の解決の結果としてWHOISで提供されるレジストリ/レジストラの情報のデータ要素が削除されたりアクセス性が低下したりする場合、ICANNは解決策および当該契約条項の完全遵守をICANNが控えることの理由について適切な公示を行います。

ステップ6:継続審査

6.1 ICANNは、関係するレジストリまたはレジストラから提供される実質的な情報を使用し、またすべての部会と協力して、このプロセスの有効性を毎年検討します。


[1] WHOISタスクフォース2の暫定レポート(2004年6月):http://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary.html

[2] GNSO評議会議事録(2005年11月28日):http://gnso.icann.org/meetings/minutes-gnso-28nov05.shtml

[3] GNSO WHOISタスクフォースの最終タスクフォースレポート(2005年10月25日):http://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

[4] 理事会議事録(2006年5月10日):http://www.icann.org/minutes/minutes-10may06.htm

[5] 本文書に記載された「レジストリ」は、レジストリ オペレータおよびスポンサー組織を含みます。


1 https://community.icann.org/display/WNLCI/WHOIS+and+national+law+conflicts+IAG+Home

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."