登録データポリシー

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

登録データポリシー

1. はじめに
2. 適用範囲
3. 定義と解釈
4. 本ポリシーの施行日
5. データ保護契約
6. 登録データの収集
7. レジストラからレジストリオペレータへの登録データの移転
8. データエスクロープロバイダへの登録データの移転
9. ドメイン名登録データの公開
10. 開示請求
11. ログファイル
12. 登録データの保持

補遺I

補遺II

実装に関する注記

1. 登録データの処理
2. 登録データの移転
3. エスクロープロバイダへの登録データの移転
4. レジストラント組織の公開
5. 合法的な開示に対する妥当な要請への対応
6. 登録データの保持
7. 提携プロバイダーおよび認定プライバシーまたはプロキシサービスプロバイダー
8. 作成日
9. 更新日

背景

登録データポリシー

1. はじめに

   登録データポリシー（以下、「ポリシー」）は、ICANNが認定する各レジストラ（以下、「レジストラ」）およびICANNと契約を締結しているgTLDレジストリオペレータ（以下、「レジストリオペレータ」）の登録データの処理に関する要件を記載したICANNのコンセンサスポリシーです。

2. 適用範囲

   2.1.本ポリシーは、ICANNと契約を締結している各ICANN認定レジストラおよびレジストリオペレータに適用されます。

   2.2.5項の要件となっているデータ保護契約により特定される目的以外での、登録データに含まれる個人データのレジストリオペレータおよびレジストラによる処理は、本ポリシーの範囲外です。

3. 定義と解釈

   3.1.本ドキュメントのキーワード「必要があります」、「禁止されています」、「必要になります」、「するものとします」、「するものではない」、「すべき」、「すべきではない」、「推奨される」、「推奨されない」、「できます」、および「任意の」は、BCP14 [RFC2119] [RFC8174]の規定どおりに解釈されます。

   3.2.データ主体の「同意」とは、データ主体が声明または明確な肯定的行為によって、データ主体に関連する個人データの処理に同意することを示す、データ主体の自由意志に基づく、具体的かつ十分な情報に基づく、明確な意思表示を意味します。

   3.3.「個人データ」とは、識別された自然人または識別可能な自然人（「データ主体」）に関するあらゆる情報を意味します。

   3.4.「処理」とは、自動化された手段によるか否かを問わず、個人データまたは個人データの集合に対して行われる単一または一連の操作（データの収集、記録、編集、構成、保存、修正、または変更、検索、参照、使用、送信による開示、配布又は他の方法により利用可能とすること、整列または結合、制限、消去または破壊を含む）を意味します。

   3.5.「公表」、「公開」、「発行」とは、一般にアクセス可能な登録データディレクトリサービスで登録データを提供することを意味します。

   3.6.「登録データ」とは、本ポリシーの6項に従い、登録名に関連して自然人もしくは法人から収集された、またはレジストラもしくはレジストリオペレータによって生成されたデータ要素値を意味します。

   3.7.「合法的な開示のための妥当な要求」（「開示請求」）とは、10項の要件に従って、非公開の登録データの開示をレジストリオペレータまたはレジストラに提出される請求を意味します。

   3.8.本ポリシーにおいて定義されていない用語は、レジストリ契約またはレジストラ認定契約で定められる意味を有するものとします（該当する場合）。

   3.9.本ポリシーの条項でレジストリオペレータおよびレジストラが共に参照される場合、かかる各条項は、各レジストリ契約またはレジストラ認定契約に準拠し、各レジストリオペレータおよび各レジストラの別個の要件および義務を示すものとします。

4. 本ポリシーの施行日

   本ポリシーは、2025年8月21日に発効します。gTLDの暫定登録データポリシーは2025年8月20日まで有効になります。2024年8月21日から2025年8月20日までの期間、レジストリおよびレジストラは、gTLD登録データに関する暫定仕様書もしくは本ポリシー全体、またはその両方の要素に合致する対策を引き続き実施できます。

5. データ保護契約

   適用法で求められる場合、ICANN、gTLDレジストリオペレータ、および認定レジストラは、相互におよび本ポリシーに基づき企図される関連するサードパーティープロバイダー間で、必要なデータ保護契約を締結しなければなりません。本条件には、登録データの処理に関する法的根拠が含まれる場合があります。

   レジストリオペレータまたはレジストラとICANNとの間のかかる契約が適用法を遵守するために必要となる場合、ICANNは、要請に応じて、不当な遅延を生じさせることなく、本ポリシーに従って実施されるデータ保護契約をレジストリオペレータまたはレジストラと締結する必要があります。

   レジストリオペレータおよびレジストラが適用法によりかかる合意が求められると判断した場合、本ポリシーに従い、不当な遅滞なく要請する必要があります。

   また、データ保護契約は、適用法で規定される関連データ保護機関からの追加のガイダンスに基づいて、随時修正および更新される可能性があります。

6. 登録データの収集

   6.1.レジストラは、以下のデータ要素の値を収集または生成する必要があります。生成する必要があるデータ要素にはアスタリスクが付けられています。

   6.1.1.ドメイン名

   6.1.2.レジストラのWHOISサーバー*

   6.1.3.レジストラのURL*

   6.1.4.レジストラ*

   6.1.5.レジストラのIANA ID*

   6.1.6.レジストラの悪用対応担当者の電子メール*

   6.1.7.レジストラの悪用対応担当者の電話番号*

   6.1.8.ドメインステータス*

   6.1.9.レジストラント名

   6.1.10.レジストラントの番地

   6.1.11.レジストラントの都市名

   6.1.12.レジストラントの州名

   6.1.13.レジストラントの郵便番号

   6.1.14.レジストラントの国名

   6.1.15.レジストラントの電話

   6.1.16.レジストラントの電子メール

   6.1.17.レジストラの登録満了日*

   「州名」および「郵便番号」の値は、万国郵便連合（UPU）の郵便住所指定基準またはその国や地域の他の同等の基準の定義に従い、その国や地域で該当する場合にのみ収集する必要があります。

   「レジストラのWHOISサーバー」の値は、レジストラ認定契約またはICANNコンセンサスポリシーによって要求される場合にのみ生成する必要があります。

   6.2.レジストラは、登録名所有者に以下のデータ要素の値を提供する機会を提供することができます。レジストラがデータ要素の値の収集を提案し、登録名所有者が値を提供することを選択した場合、レジストラは以下の値を収集する必要があります。

   6.2.1.レジストラントの内線電話

   6.2.2.レジストラントのファックス

   6.2.3.レジストラントの内線ファックス

   6.2.4.技術担当者の氏名

   6.2.5.技術担当者の電話

   6.2.6.技術担当者の電子メール

   6.3.登録名所有者が技術担当者の連絡先を提供する場合、レジストラは登録時に、登録名所有者が個人の連絡先を提供する代わりに、(a)登録名所有者（またはその代表者）と同一人物を技術担当者の連絡先として指定すること、また(b)技術担当者の連絡先の個人を特定できる情報ではない連絡先（例、john.doe@example.orgの代わりに tech-assistance@example.orgなどの電子メールアドレス）を提供できることを登録名所有者に通知する必要があります。

   6.4.レジストラは、再販業者のデータ要素の値を生成することができます。

   6.5.レジストラは、登録名所有者に以下のデータ要素の値を提供する機会を提供する必要があります。登録名所有者から提供される場合、レジストラは以下のデータ要素値を収集する必要があります。

   6.5.1.レジストラントの組織名

   6.5.2.ネームサーバー

   6.5.3.ネームサーバーのIPアドレス

   6.5.4.DNSSEC要素

   6.6.登録名所有者がレジストラントの組織名のデータ要素に値を入力した場合、レジストラは登録名所有者に以下を通知する必要があります。

   6.6.1.登録名所有者が値の公開に同意した場合、レジストラントの組織名がRDDSで公開されること。

   6.6.2.レジストラントの組織名が登録名所有者と見なされること。

   6.7.レジストラは、レジストリ-レジストラ契約またはレジストリオペレータの登録ポリシーによって求められる場合、追加のデータ要素を収集することができます。

   6.8.レジストラは、本ポリシーの発効日より前に収集された管理担当者の連絡先データを削除することができます。管理担当者の連絡先データを削除する前に、レジストラは、6.1.9項から6.1.16項にある必須の登録名所有者のデータ要素の値が収集されていることを確認する必要があります。

7. レジストラからレジストリオペレータへの登録データの移転

   7.1.レジストラは、以下のデータ要素をレジストリオペレータに移転する必要があります。

   7.1.1.ドメイン名

   7.1.2.レジストラのURL

   7.1.3.レジストラ

   7.1.4.レジストラのIANA ID

   7.1.5.レジストラの悪用対応担当者の電子メール

   7.1.6.レジストラの悪用対応担当者の電話

   7.1.7.ドメインステータス

   7.2.レジストラは、以下のデータ要素が収集または生成された場合、レジストリオペレータに移転する必要があります。

   7.2.1.レジストラのWHOISサーバー

   7.2.2.ネームサーバー

   7.2.3.ネームサーバーのIPアドレス

   7.2.4.DNSSEC要素

   7.3.レジストラは、適切な法的根拠があり、データ処理契約が締結されている場合、以下のデータ要素をレジストリオペレータに移転する必要があります。

   7.3.1.レジストラント名

   7.3.2.レジストラントの番地

   7.3.3.レジストラントの都市名

   7.3.4.レジストラントの国名

   7.3.5.レジストラントの電話

   7.3.6.レジストラントの電子メール

   7.4.レジストラは、適切な法的根拠があり、データ処理契約が締結されている場合、以下のデータ要素が収集されている場合、レジストリオペレータに移転する必要があります:

   7.4.1.レジストラントの組織名

   7.4.2.レジストラントの州名

   7.4.3.レジストラントの郵便番号

   7.4.4.レジストラントの内線電話

   7.4.5.レジストラントのファックス

   7.4.6.レジストラントの内線ファックス

   7.4.7.技術担当者の氏名

   7.4.8.技術担当者の電話

   7.4.9.技術担当者の電子メール

   7.5.レジストラは、レジストリオペレータによってサポートされている場合、以下のデータ要素をレジストリオペレータに移転する必要があります。

   7.5.1.レジストラの登録満了日

   7.5.2.リセラー

8. データエスクロープロバイダへの登録データの移転

   8.1.レジストラは、以下のデータ要素の電子コピーを、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに提出する必要があります。

   8.1.1.ドメイン名

   8.1.2.レジストラの登録満了日

   8.1.3.レジストラのIANA ID

   8.1.4.レジストラント名

   8.1.5.レジストラントの番地

   8.1.6.レジストラントの都市名

   8.1.7.レジストラントの州名

   8.1.8.レジストラントの郵便番号

   8.1.9.レジストラントの国名

   8.1.10.レジストラントの電話

   8.1.11.レジストラントの電子メール

   「州名」および「郵便番号」の値は、該当する国や地域で利用できない場合は、移転する必要はありません。

   8.2.レジストラが以下のデータ要素を収集または生成する場合、レジストラは、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに電子コピーを提出する必要があります。

   8.2.1.レジストラントの組織名

   8.3.レジストラが以下のいずれかのデータ要素を収集または生成する場合、レジストラは、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに以下に示すデータ要素の電子コピーを提出することができます。

   8.3.1.リセラー

   8.3.2.レジストラントの内線電話

   8.3.3.レジストラントのファックス

   8.3.4.レジストラントの内線ファックス

   8.3.5.技術担当者の氏名

   8.3.6.技術担当者の電話

   8.3.7.技術担当者の電子メール

   8.4.レジストリオペレータは、以下のデータ要素の電子コピーを、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに提出する必要があります。

   8.4.1.ドメイン名

   8.4.2.レジストリドメインID

   8.4.3.レジストラのURL

   8.4.4.作成日

   8.4.5.レジストリの有効期限日

   8.4.6.レジストラ

   8.4.7.レジストラのIANA ID

   8.4.8.レジストラの悪用対応担当者の電子メール

   8.4.9.レジストラの悪用対応担当者の電話

   8.4.10.ドメインステータス

   8.5.レジストリオペレータは、レジストラから移転された、あるいはレジストリオペレータによって生成された場合、以下のデータ要素の電子コピーを、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに提出する必要があります。

   8.5.1.レジストラのWHOISサーバー

   8.5.2.更新日

   8.5.3.レジストラの登録満了日

   8.5.4.リセラー

   8.5.5.レジストリのレジストラントID

   8.5.6.レジストラント名

   8.5.7.レジストラントの組織名

   8.5.8.レジストラントの番地

   8.5.9.レジストラントの都市名

   8.5.10.レジストラントの州名

   8.5.11.レジストラントの郵便番号

   8.5.12.レジストラントの国名

   8.5.13.レジストラントの電話

   8.5.14.レジストラントの内線電話

   8.5.15.レジストラントのファックス

   8.5.16.レジストラントの内線ファックス

   8.5.17.レジストラントの電子メール

   8.5.18.ネームサーバー

   8.5.19.DNSSEC要素

   8.5.20.ネームサーバーのIPアドレス

   8.6.レジストリオペレータは、レジストラから移転された、あるいはレジストリオペレータによって生成された場合、以下のデータ要素の電子コピーを、ICANNが指定する形式で、ICANNが承認するデータエスクローエージェントに提出することができます。

   8.6.1.レジストリの技術担当者 ID

   8.6.2.技術担当者の氏名

   8.6.3.技術担当者の電話

   8.6.4.技術担当者の電子メール

9. ドメイン名登録データの公開

   9.1.RDDSへの公開要件

   9.1.1.RDDSクエリへの応答で、レジストラおよびレジストリオペレータは以下のデータ要素を公開する必要があります。

   9.1.1.1.ドメイン名

   9.1.1.2.レジストラのURL

   9.1.1.3.作成日

   9.1.1.4.レジストリの有効期限日（例外：レジストラが公開できます）

   9.1.1.5.レジストラの登録満了日（例外：レジストリオペレータが公開できます）

   9.1.1.6.レジストラ

   9.1.1.7.レジストラのIANA ID

   9.1.1.8.レジストラの悪用対応担当者の電子メール

   9.1.1.9.レジストラの悪用対応担当者の電話

   9.1.1.10.ドメインステータス

   9.1.1.11.RDDSの最終更新日

   9.1.2.RDDSクエリへの応答で、レジストラおよびレジストリオペレータは以下のデータ要素が収集、移転、または生成される場合、公開する必要があります。

   9.1.2.1.レジストラのWHOISサーバー

   9.1.2.2.更新日

   9.1.2.3.ネームサーバー

   9.1.2.4.DNSSEC要素

   9.1.3.RDDSクエリへの応答で、または9.2項の要件に従って、(a)レジストラは、 以下のデータ要素が収集または生成された場合、公開する必要があり、(b)レジストリは、レジストラから移転、またはレジストリオペレータによって生成された場合、以下のデータ要素を公開する必要があります。

   9.1.3.1.レジストリドメインID

   9.1.3.2.レジストリのレジストラントID

   9.1.3.3.レジストラントの組織名

   9.1.3.4.レジストラントの郵便番号

   9.1.3.5.レジストリの技術担当者 ID

   9.1.3.6.技術担当者の氏名

   9.1.3.7.技術担当者の電話

   9.1.3.8.技術担当者の電子メール

   9.1.4.RDDSクエリへの応答で、(a)レジストラは、レジストラントの州名のデータ要素を収集した場合、公開する必要があり、(b)レジストリオペレータは、レジストラから移転された場合、レジストラントの州名のデータ要素を公開する必要があります。

   9.1.5.RDDSクエリの応答で、(a)レジストラはレジストラントの国名のデータ要素を公開する必要があり、(b)レジストリオペレータは、レジストラから移転された場合、レジストラントの国名のデータ要素を公開する必要があります。

   9.1.6.RDDSクエリへの応答で、または9.2項の要件に従って、(a)レジストラは、 以下のデータ要素を公開する必要があり、(b)レジストリは、レジストラから移転された場合、以下のデータ要素を公開する必要があります。

   9.1.6.1.レジストラント名

   9.1.6.2.レジストラントの番地

   9.1.6.3.レジストラントの都市名

   9.1.6.4.レジストラントの電話

   9.1.6.5.レジストラントの電子メール

   9.1.7.RDDSクエリへの応答で、レジストラおよびレジストリオペレータは、リセラーのデータ要素を公開することができます。

   9.1.8.RDDSクエリへの応答で、レジストラはネームサーバーのIPアドレスのデータ要素を公開することができます。

   9.1.9.RDDSクエリへの応答で、レジストリオペレータは、

   9.1.9.1.レジストリ契約が（RFC8499で定義）ドメイン内のグルーレコードの公開を要求する場合、ネームサーバーのIPアドレスのデータ要素を公開する必要があります。

   9.1.9.2.レジストリ契約で要求されていない場合は、ネームサーバーのIPアドレスのデータ要素を公開することができます。

   9.1.10.RDDSクエリへの応答で、また9.2項の要件に従って、レジストラおよびレジストリオペレータは以下のデータ要素を公開することができます。

   9.1.10.1.レジストラントの内線電話

   9.1.10.2.レジストラントのファックス

   9.1.10.3.レジストラントの内線ファックス

   9.2.登録データの公開に関する修正要件

   9.2.1.レジストリオペレータとレジストラは、(a) 適用法を遵守するために登録データに含まれる個人データの編集が必要な場合は、RDDSの9.2項の要件を適用する必要があり、(b) (i)商業上合理的な目的がある場合、または(ii)本項の要件の適用を制限することが技術的に可能でない場合、9.2項の要件を適用することができます。9.2項の要件を適用するか否かを決定するにあたり、レジストリオペレータおよびレジストラは、登録データが法人に関連するか、または登録データに個人データが含まれるか、および登録名所有者または関連する連絡先の地理的な場所を考慮することができますが、その義務はありません。

   9.2.2.9.2項において、編集とは以下の条件を満たすものと定義されます。レジストリオペレータおよびレジストラは、(a) RDDS出力にデータ要素の値を含めてはならず、(b) 値が編集されていることを示す必要があります。

   9.2.2.1.レジストリオペレータまたはレジストラが9.2.1項の要件を適用する場合、以下のサブセクションに概説される例外を条件として、以下のデータ要素の値を編集する必要があります。

   9.2.2.1.1.レジストリドメインID

   9.2.2.1.2.レジストリのレジストラントID

   9.2.2.1.3.レジストラント名

   9.2.2.1.4.レジストラントの番地

   9.2.2.1.5.レジストラントの郵便番号

   9.2.2.1.6.レジストラントの電話

   9.2.2.1.7.レジストラントの内線電話

   9.2.2.1.8.レジストラントのファックス

   9.2.2.1.9.レジストラントの内線ファックス

   9.2.2.1.10.レジストリの技術担当者 ID

   9.2.2.1.11.技術担当者の氏名

   9.2.2.1.12.技術担当者の電話

   9.2.2.2.レジストリオペレータが9.2.1項の要件を適用する場合、レジストリオペレータは以下のデータ要素の値を編集する必要があります。

   9.2.2.2.1.レジストラントの電子メール

   9.2.2.2.2.技術担当者の電子メール

   9.2.2.3.レジストリオペレータが9.2.1項の要件を適用する場合、レジストリオペレータはレジストラントの組織名の値を編集することができます。

   9.2.2.4.レジストラまたはレジストリオペレータが9.2.1項の要件を適用する場合、レジストラントの都市名の値を編集することができます。

   9.2.3.レジストラが9.2.1項の要件を以下のデータ要素については適用する場合、レジストラは電子メールの値に対して、関連する連絡先との電子メールでのコミュニケーショ ンを容易にするための電子メールアドレスまたはWebフォームへのリンクを公開する必要があります。ただし、公開するときには、連絡先の電子メールアドレスまたは連絡先自体を特定してはなりません。

   9.2.3.1.レジストラントの電子メール

   9.2.3.2.技術担当者の電子メール

   9.2.4.9.2.2.1.1項から9.2.2.1.9項、9.2.2.4項、および9.2.3.1項に列挙されたデータ要素の値に対して、レジストラが9.2.1項の要件を適用する場合、登録名所有者がデータ要素の値を公表することに同意する機会を提供する必要があります。レジストラは、登録名所有者が公表することに同意したデータ要素の値を公表する必要があります。

   9.2.5.提携プロバイダーまたは認定されたプライバシーまたはプロキシサービスのプロバイダーを利用する登録名については、レジストラおよびレジストリオペレータは、プライバシーまたはプロキシサービスの完全な登録データを公開する必要があり、これには既存のプライバシーまたはプロキシを仮名化したメールを含めることができます。

   9.2.6.登録名所有者がレジストラントの組織名のデータ要素の値を公開することに同意した場合、レジストラはその値を公開する必要があります。登録名所有者がその公表に同意しない場合、レジストラはレジストラントの組織名の値を編集することができます。

10. 開示請求

    10.1.レジストラおよびレジストリオペレータは、そのホームページ（ドメイン名サービスが提供される一般に利用可能なWebページ）に、開示請求の仕組みと請求の提出プロセスが詳細に記載されたページへの直接リンクを掲載する必要があります。その仕組みとプロセスでは、(a)開示請求の書式と内容、(b) 請求者に応答する手段、(c)応答までのタイムラインの予測を規定する必要があります。

    10.2.レジストラおよびレジストリオペレータの開示請求の書式および内容には、最低限以下が含まれている必要があります。

    10.2.1.以下の情報を含む請求者の身元

    10.2.1.1.請求者の連絡先、

    10.2.1.2.法人または個人の性質/種類、および

    10.2.1.3.委任状、または請求者の代理として行動する権限を証明する類似の書類（該当および関連する場合）。

    10.2.2.請求者が要求したデータ要素の値のリスト。

    10.2.3.請求者の法的権利に関する情報、開示請求の具体的な根拠と理由。

    10.2.4.善意をもって請求していることの確認。

    10.2.5.請求への応答として受信したデータ要素の値を合法的に処理することへの請求者の同意。

    10.3.レジストラおよびレジストリオペレータは、要求されたそれぞれの形式を満たすように開示請求に回答する必要があります。

    10.4.レジストラおよびレジストリオペレータは、適切に形式化された各開示請求を、それぞれの請求の具体的な根拠と理由を考慮し、その価値に基づいて検討する必要があります。

    10.5.レジストラおよびレジストリオペレータは、要求されたそれぞれの形式を満たす開示請求の受領を、受領してから2営業日を超えない範囲で、過度な遅滞なく確認する必要があり、また、例外的な事情がない限り、受領してから30日間を超えない範囲で、過度な遅滞なく回答する必要があります。

    10.6.開示請求に対する回答は、以下のいずれかである必要があります。

    10.6.1.要求されたデータを提供する。または、

    10.6.2.レジストリオペレータまたはレジストラが、要求されたデータ（全部または一部）を提供できない理由の根拠を提供し、かかる拒否の具体的な理由を示し、請求者が判断の理由を客観的に十分に理解できるように、判断に至った明確な説明を追加する必要があります。これには、データ主体の基本的権利および自由が、請求者の正当な利益（該当する場合）とどのように衡量されたかに関する分析と説明が含まれます。

    10.7.レジストリオペレータまたはレジストラは、不正な請求/請求者に対処するために訂正処置をとることができます。訂正処置には、反復的または不完全な申請の拒否、権限を乱用する請求者の不履行に対する追加情報の要求、および適切とみなされるその他の措置を含めることができます。訂正処置は、請求者に通知する必要があります。

11. ログファイル

    11.1.レジストラが9.2.3項の要件を適用する場合、レジストラは、

    11.1.1.請求者から登録名所有者の電子メールアドレスへの通信リレーが発生したことを確認するログファイルを保持する必要があります。このログファイルには、発信元、受信者、メッセージの内容、またはいかなる個人データも含んではなりません。

    11.1.2.請求者から技術担当者の電子メールアドレスへの通信リレーが発生したことを確認するログファイルを保持することができます。このログファイルには、発信元、受信者、メッセージの内容、またはいかなる個人データも含んではなりません。

    11.1.3.登録名所有者の電子メールへの通信リレーに関連するログファイルを、要求に応じて、コンプライアンスの目的でICANN組織に提供する必要があります。本条項のいかなる規定も、レジストラの連絡プロセスの濫用を防止するためにレジストラが合理的かつ適切な措置をとることを妨げるものと解釈されるべきではありません。

    11.2.レジストリオペレータおよびレジストラは、開示請求に対する要求、確認、および応答のログを、ICANN組織による監査目的に対応することを含め（ただしこの目的に限定されない）、必要に応じて作成できるように、標準的な業務記録の慣行に従って維持する必要があります。

12. 登録データの保持

    レジストラは、レジストラの登録のスポンサーシップの終了後またはレジストラント間（登録者の変更）の登録の移転後15か月以上の期間、移転紛争処理ポリシーの目的のために必要なデータ要素を保持する必要があります。

補遺I

WHOIS（ポート43経由で利用可能）およびWebベースのWhoisディレクトリサービスの実装は、以下に準拠する必要があります。

1. 値データが収集、生成、移転されていないデータ要素については、(a)フィールドの値セクション（つまり、コロンの右側）に情報がないキー（つまり、コロンの左側の文字列）を表示する必要があります。または、(b) キーまたは値を1つも表示しないようにします。
2. 値データが存在し、本ポリシーの9.2.2項の要件に従うデータ要素については、値セクション（つまり、コロンの右側）は文字列「REDACTED」（編集済）に置換する必要があります。

注：この補遺Iは、WHOIS（ポート43経由で利用可能）またはWebベースのWhoisディレクトリサービスを提供する各レジストラおよびレジストリオペレータに適用されます。

補遺II

本ポリシーの発効日より前に作成された既存のドメイン名登録の場合：

1. レジストラは、レジストラントの組織名のデータ要素に値を入力した登録名所有者に連絡し、(a)登録名所有者にその値が正しいことの確認と検証を要求し、(b)登録名所有者がレジストラントの組織名の値の公表に同意するかどうかを確認する必要があります。
2. 登録名所有者がレジストラントの組織名の値を確認または訂正し、その公表に同意した場合、レジストラは、(a)本ポリシーの発効日までに、レジストラントの組織名の値を非個人情報として扱い、公表する旨を登録名所有者に通知し、(b)本ポリシーの発効日までに、9.1.3項に記載されているように、レジストラントの組織名の値を公表する必要があります。
3. 登録名所有者がレジストラントの組織名の値の公表を拒否した場合、または問い合わせに応じなかった場合、9.2.6項に記載されているように、レジストラはレジストラントの組織名の値を（9.2.2項に定義されるとおり）編集することができます。または、本ポリシーの発効日以前に収集されたレジストラントの組織名の値を削除することができます。レジストラントの組織名の値を削除する前に、レジストラは、6.1.16項にある必須の登録名所有者のデータ要素の値が収集されていることを確認する必要があります。

実装に関する注記

1. 登録データの保持：

   1. 本ポリシーのいかなる規定も、レジストリオペレータおよびレジストラが、本ポリシーの範囲を超えるその他の目的でデータを処理することを禁止するものではありません。例：
      1. ドメイン名登録の支払いを目的としたクレジットカード情報の収集。
      2. 連絡先を作成するために、以下のような追加のデータ要素を収集または生成すること。<contact:id>、<contact:authInfo>; または技術担当者の連絡先の都市（<contact:city>）と国（<contact:cc>）。
      3. レジストラが追加の連絡先データを収集する場合、関連する連絡先データをRDDSに公表することができます。例えば、レジストラが6.2項に基づいて登録名所有者から技術担当者の連絡先データを収集し、9.2.2.1.10項から第9.2.2.1.12項に列挙されたデータ要素の値を編集する場合、レジストラは、関連する連絡先にデータ要素の値の公表に同意する機会を提供することができます。レジストラは、関連する連絡先が公表に同意したデータ要素の値を発行することができます。

2. 登録データの移転

   1. 本ポリシーのいかなる規定も、レジストラまたはレジストリオペレータがデータエスクローエージェントに追加のデータ要素を移転することを妨げるものではありません（例えば、レジストリ契約で定義されるレジストリサービスの提供のため）。
   2. 本ポリシーのいかなる規定も、法的根拠が存在し、適用法により法的根拠が要求される場合、レジストリオペレータがレジストラに対して追加のデータ要素の値の移転を要求することを妨げるものではありません。
   3. 7項に従い、データをレジストラからレジストリオペレータに移転するために法的根拠が必要とされる場合、法的根拠の決定は移転の当事者によって行われます。法的根拠の有無は、ICANN組織によって決定されるものでもなければ、執行の対象となるものでもありません。レジストリオペレータおよびレジストラが法的根拠の存在を立証し、かつ、レジストリオペレータおよびレジストラが、移転されるデータを網羅するデータ保護契約を締結している場合、ICANN組織は、7項に基づく移転要件を執行できる場合があります
   4. レジストリオペレータおよびレジストラは、適用法により要求されない場合、レジストラからレジストリオペレータへの移転を含め、個人データを処理する法的根拠を確立する必要はありません。

3. エスクロープロバイダへの登録データの移転

   明確にするために、適用されるレジストリ契約に従って、レジストリオペレータは、承認されたレジストリサービスのすべてを提供するために必要なすべてのデータ要素を預託しなければなりません。

4. レジストラント組織の公開

   1. レジストラント名は、レジストラントの組織名の問い合わせ先とみなされます。
   2. レジストラは、レジストラントの組織名の値を公開し、6.6.1項および6.6.2項の要件を通知することについて、例えば、ポップアップウィンドウによる勧告、オプトイン要件、レジストラントがデータ要素の公開に明示的に同意するまで（チェックボックスにチェックを入れるまで）レジストラントの組織名をグレーアウトするなどの方法により、開示、免責事項、またはレジストラントの組織名の値の確認要求を提示することで、登録名所有者の同意を得るための独自のプロセスを使用できます。ここで示した例以外の方法を用いることもできます。

5. 合法的な開示に対する妥当な要請への対応

   開示要請に対するレジストラまたはレジストリオペレータの応答時間を評価するときに、ICANN組織は、受領した要請の数、管理しているドメイン名の数、平均応答時間、および拒否された要求の数を考慮することができます。

6. 登録データの保持

   1. 法律、法的手続き、またはその他の適切な法的根拠により要求される場合、本ポリシーのいかなる規定も、レジストラおよびレジストリオペレータが保持期間を設定することを禁止するものではなく、これには、必要に応じて、データ保持義務の放棄を要求することも含まれます。
   2. レジストラは、より長い保存期間を設定するために権利放棄を求める必要はありません。ICANN組織のデータ保持放棄手続きは、レジストラがデータ保持期間の短縮を要求することを許可します。
   3. 明確にするために、12項のデータ保持要件は、（本ポリシー内で定義される）登録データのみに適用され、ICANNコンプライアンスを含む要求者が、移転紛争解決ポリシー（TDRP）以外の目的でこれらの保持されたデータ要素の開示を要求することを妨げるものではありません。

7. 提携プロバイダーおよび認定プライバシーまたはプロキシサービスプロバイダー

   提携プロバイダーは、レジストラ認定契約の1.3項で定義され、レジストラ認定契約の1.7項でさらに詳細に説明されています。認定されたプライバシーまたはプロキシサービスプロバイダーは、利用可能となる場合、プライバシーおよびプロキシサービス認定ポリシーの発効日から本要件の対象となります。

8. 作成日

   本ポリシーにおける「作成日」とは、レジストリデータベースにおいてドメインオブジェクトの作成が行われた時点を指します。

9. 更新日

   レジストラにとって、本ポリシーにおける「更新日」とは、7項に列挙されるデータ要素のうち、レジストラデータベースまたはレジストリデータベースにおいて行われた直近の更新を指します。

背景

2018年5月17日に、ICANN理事会は gTLD登録データの暫定仕様書を採択しました。暫定仕様書では、欧州連合の一般データ保護規則（GDPR）に準拠し、WHOISサービスを可能な限り継続的に利用できるようにするため、また、WHOISを遵守しながらgTLD登録データを処理し、WHOISの断片化を避けるために、レジストラ認定契約およびレジストリ契約における既存の要件を修正しました。ICANN細則並びにコンセンサスポリシーおよびレジストリ契約 (RA) とレジストリ・レジストラ契約 (RAA) での一時ポリシー仕様にしたがって、一時的な仕様の有効期間は、発効日である2018年5月25日から最長1年間のみになります。

2018年7月19日、GNSO（ジェネリックドメイン名支持組織）評議会は、2段階に分けて策定するEPDP（迅速なポリシー策定プロセス）を 開始し、gTLD登録データチームの暫定仕様書に関するEPDPを憲章として許可しました。この作業の第1段階では、EPDPチームはgTLD登録データ向けの暫定仕様書がICANNコンセンサスポリシー原本あるいは修正版になっているかを確認するように求められました。また、本憲章では、その結果がGDPRに準拠し、他の関連するプライバシーおよびデータ保護法令を考慮する必要があることを指示しています。EPDPチーム憲章の第2段階の目的は、非公開のgTLD登録データの標準化されたアクセス/公開システムの評価、 暫定仕様書の付属書類で指摘された問題への対処、および第1段階で延期されたその他の問題への対処でした。

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

2019年2月20日、EPDPチームは最終レポートを発表しこのレポートは、2019年3月4日にGNSO理事会で採択されました。ICANN組織は2019年3月4日、最終レポートに関する官報公告期間を開始しました。官報公告期間の手続きは、gTLD登録データの暫定仕様書に関するGNSO EPDPの最終的な政策提言に対する理事会の決定に先立ち、コミュニティからの意見を得ることを目的としたものでした。官報公告向けサマリーおよび分析 レポートは、2019年4月23日に発行されました。理事会は2019年3月15日、いくつかの例外を除き、推奨事項の採択を決議しました。

コンセンサスポリシー実装チームが結成され、実装計画に着手しました。また、ICANN組織が作成し、GNSO理事会が採択した コンセンサスポリシー実装フレームワーク（CPIF）に沿って、PDP作業部会のメンバーおよび関心のあるコミュニティメンバーから構成される実装レビューチーム（IRT）が結成され、コンセンサスポリシー実装チームと協働することになりました。

理事会の決議に先立ち、実装チームはポリシー実装の以下の3段階のコンセプトを作成しました。

• 第1段階：2019年5月25日に有効期限が切れるgTLD登録データに関する暫定仕様書に沿った措置を引き続き実施。これは、勧告に基づいて恒久的なポリシーが作成され公表されるまでの暫定的な登録データポリシーです。
• 第2段階：この段階は、ICANN組織が登録データポリシーをコンセンサスポリシーとして公表し、契約当事者に正式に通知した後に開始されます。この段階では、契約当事者は、登録データポリシーの発効日の準備時、暫定ポリシー、登録データポリシー、あるいはその両方の要素を実施することができます。
• 第3段階：契約当事者は、登録データポリシーを遵守する必要があります。

2019年5月17日、ICANN組織は2019年5月15日の理事会の決議に基づき、gTLDの暫定登録データポリシーを公表しました。2019年5月20日付で発効した暫定ポリシーでは、2019年5月25日に失効したgTLD登録データの仕様書に沿った措置を引き続き実施することを契約当事者に求めています。

EPDPチームは第2段階の作業を完了し、EPDP第2段階のプライオリティ2勧告と呼ばれる4つの勧告からなる最終報告書を公表しました。2021年6月21日、理事会は 勧告19-22を採択し、これらの勧告の実施が登録データポリシーの実施業務範囲に追加されました。

2022年2月24日、理事会は、EPDP勧告12に対するGNSO理事会の補足勧告を採択しました 。EPDP勧告12は、基本データの喪失という理事会の包括的な懸念に対処するものになっています。