Skip to main content
Resources

gTLD 用暫定登録データポリシー

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

すべての翻訳されたコンテンツおよび文書の英語版が公式版であり、英語以外の言語の翻訳版は情報提供のみを目的として作成されたものです。

gTLD 用の本暫定登録データポリシー (暫定ポリシー) は、一般トップレベルドメイン(gTLD)に関するデータ保護要件について、2019年5月15日、ICANN 理事会が採択した一般トップレベルドメイン名支持組織 (GNSO) ポリシー推奨事項です。この暫定ポリシーは、下記の背景セクションに記載のとおり、促進ポリシー開発プロセス (EPDP) チームの推奨事項の全29のうち、1つを実施します。gTLD 用の後続登録データポリシー (登録データポリシー) は、理事会承認の推奨事項を実施し、ステージ2の終了後、この暫定ポリシーに代わります。

本暫定ポリシーは、2019年5月20日発効です。本暫定ポリシーでは gTLD レジストリオペレータおよび ICANN 認定レジストラ (総称して、「契約当事者」) が、2019年5月20日付けで、暫定ベースで gTLD 登録データの暫定仕様書に合致する対策を引き続き実施し、登録データポリシーの実施を保留することを求めています。

  1. ステージ1
  2. 2019年5月20日付で、契約当事者は、2018年5月17日に ICANN 理事会が採択した gTLD 登録データの暫定仕様書 (暫定仕様書) と合致した対策を引き続き実施しなければなりません。

  3. ステージ2
  4. ICANN 組織による (a) 実施審査チームとの相談による登録データポリシー文書の完了、 (b) 登録データポリシー文書の発行、および (c) 登録データポリシーの発行に関する契約当事者への正式通知の後、契約当事者は、引き続き暫定仕様書と合致した対策を実施するか、あるいは登録データポリシー文書と合致した対策を実施しなければなりません。

    このステージでは、契約当事者は、登録データポリシー文書の発効日の準備時、暫定ポリシーまたは登録データポリシー全体、あるいはその両方を実施することができます。

  5. ステージ3
  6. 登録データポリシーの発効日 (EPDP チームは2020年2月29日を推奨) 時点で、契約当事者は、登録データポリシーに準拠しなければなりまえん。

実装に関する注記

ICANN契約遵守チームは、契約当事者にこの暫定ポリシーへの準拠義務を下記のとおり、施行します。

ステージ 1: ICANN契約遵守チームは契約当事者に対して、暫定仕様書と合致する対策の継続実施義務の履行を求めます。

ステージ 2: ICANN契約遵守チームは契約当事者に対して、(a) 暫定仕様書と合致した対策の継続実施、または (b) 登録データポリシー文書と合致した対策実施義務の履行を求めます。契約に関する問い合わせに対応する形で、契約当事者は、その活動がこの責務をどのように満たしているかを実証することが義務付けられます。暫定仕様書から登録データポリシーへの移行ペースは、契約当事者の裁量に委ねられます。

ステージ 3: ICANN契約遵守チームは、契約当事者への登録データポリシー準拠義務を施行します。このステージでは、登録データポリシーが運用され、暫定ポリシーは失効となります。

契約当事者は、3つのステージを通じて、レジストリ契約およびレジストラ認定契約の未変更部分には引き続き準拠しなければなりません。

背景

2018年5月17日付で ICANN 理事会 (ICANN 理事会) は gTLD 登録データに対する暫定仕様書 を採択。暫定仕様書では、欧州一般データ保護規則(GDPR) によるレジストラ認定およびレジストリ契約の既存準拠要件を修正しました。ICANN 細則並びにコンセンサスポリシーおよびレジストリ契約 (RA) とレジストリ・レジストラ契約 (RAA) での一時ポリシー仕様にしたがって、暫定仕様書は、2019年5月20日をもって有効期限となります。

2018年7月19日、GNSO 評議会は EPDP を 開始 し、gTLD 登録データチーム向けに暫定仕様書に関する EPDP の憲章を作成しています。この参加に関心を示したすべての GNSO ステークホルダーグループ、機関および ICANN 諮問委員会は、同憲章によりグループごとの加盟者数が限られていますが、EPDP チームとして代表権を有します。

本憲章では EPDP に対して gTLD 登録データ向けの暫定仕様書が ICANN コンセンサスポリシー原本あるいは修正版になっているかを確認するように求めています。また、本憲章では、その結果が GDPR に準拠し、他の関連するプライバシーおよびデータ保護法令を考慮する必要があることを指示しています。EPDP チーム憲章では、非公開登録データへの標準化アクセスモデルについて討議が求められ、続いて EPDP チームのポリシー推奨事項および導入の質問の討議の完了が求められます。

2018年11月21日、EPDP チームは 公聴用の初回レポートを発行。初回レポートには、公聴するために EPDP チームの予備推奨事項および一連の質問が記載されています。また、EPDP チームは、以下についても説明および推奨を行っています。(i) 暫定仕様書で記載の目的の妥当性、合法性および法的基礎、(ii) (x) 登録データのレジストラ収集、および (y) 暫定仕様書にそれぞれ記載のレジストラからレジストリへのデータ移管の合法性、必要性および範囲、 (iii) 暫定仕様書に記載のレジストラおよびレジストリによる登録データの発行。

初回レポートには、一般の方が以下について検討する予備推奨事項および質問も記載されています。(i) レジストラおよびレジストリからエスクロー提供者と ICANN へのデータ移管、(ii) レジストリから緊急バックエンドレジストリオペレータ (EBERO) へのデータ移管、(iii) 登録データへの適正アクセスのための定義および枠組み、(iv) GDPR、すなわち、関係当事者の各役割と責任、(v) ICANN コンセンサスポリシーに適用される更新、(vi) 関連するコンセンサスポリシーが適用法令に合致するように再評価を受けることができるようにするための GNSO による将来の作業。

EPDP チームは、データ処理ステップそれぞれ、それぞれの目的と法的基礎を文書化しています。この基礎作業は、GDPR 準拠のソリューションを開発する上で必要であり、またレポートの補遺に記載されています。

初回レポートの発行後、EPDP チームは以下の項目を実施しました。(i) 法的問題に関するガイダンスを求める、(ii) 発行した初回レポートに対して寄せられたパブリックコメントの丁寧な見直し、(iii) チームメンバーが代表するコミュニティグループとの進捗中の作業の見直し、および (iv) 最終レポートの作成。コンセンサスは、GNSO 作業グループガイドラインで求められているように、この最終レポートに記載の推奨事項を呼びかけ、下記サイトのとおり、EPDP チーム議長が実施しました。 https://mm.icann.org/pipermail/gnso-epdp-team/2019-February/001436.html.

GNSO 評議会は2019年3月4日、最終レポートを採択。ICANN 組織は2019年3月4日、最終レポートにて官報公告期間を開始官報公告 向けサマリーおよび分析レポートは、2019年4月23日に発行。理事会は2019年3月15日、いくつかの例外を除き、推奨事項の採択を決議

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