注册数据政策
注册数据政策
-
简介
注册数据政策（“政策”）是一项 ICANN 共识性政策，规定了每个与 ICANN 签订相应协议的 ICANN 认证注册服务机构（“注册服务机构”）和 gTLD 注册管理运行机构（“注册管理运行机构”）在处理注册数据时应遵循的要求。
-
范围
2.1. 本政策适用于每个与 ICANN 签订协议的 ICANN 认证注册服务机构和注册管理运行机构。
2.2.注册管理运行机构和注册服务机构出于第 5 节所要求“数据保护协议”所述目的以外的其他目的对注册数据中包含的个人资料进行的处理，不在本政策范围之内。
-
定义和解释
3.1.本文的关键字“必须”、“不得”、“要求”、“应该”、“不应”、“建议”、“不建议”、“可以”和“可选”，当且仅当它们以全大写形式出现时，按照 BCP 14 [RFC2119] [RFC8174] 中的说明进行解释。
3.2.数据主体的“同意”是指，数据主体自由做出的、具体、知情且明确的意愿表达；在该意愿表达中，数据主体通过声明或明确肯定的行为，表示同意处理与数据主体有关的个人资料。
3.3.“个人资料”是指，任何与确定的或可识别的自然人（“数据主体”）有关的信息。
3.4.“处理”是指，对个人资料或个人资料集进行的任何一项操作或一系列操作，无论是否采用自动化手段，例如，收集、记录、组织、构建、存储、改编或更改、检索、咨询、使用，通过传输、传播或其他方式披露，排列或组合、限制、删除或销毁。
3.5.“发布”、“公开”和“已发布”、“已公开”是指，在公众可访问的注册数据目录服务中提供注册数据。
3.6.“注册数据”是指，根据本政策第 6 节从自然人或法人处收集的，或由注册服务机构或注册管理运行机构生成的，与注册域名有关的数据元素值。
3.7.“合法披露的合理请求”（“披露请求”）是指，根据第 10 节的要求，向注册管理运行机构或注册服务机构提交的、要求披露非公开注册数据的请求。
3.8.本政策中大写但未定义的术语应该 (SHALL) 具有《注册管理机构协议》或《注册服务机构认证协议》赋予的含义（如果适用）。
3.9.在本政策某项条款中一并提及注册管理运行机构和注册服务机构时，每一条此类条款都表示，每个注册管理运行机构和每个注册服务机构均根据其各自的《注册管理机构协议》或《注册服务机构认证协议》，承担其各自的要求和义务。
-
政策生效日期
本政策于 2025 年 8 月 21 日起生效。《gTLD 临时注册数据政策》在 2025 年 8 月 20 日前有效。在 2024 年 8 月 21 日至 2025 年 8 月 20 日期间，注册管理机构和注册服务机构可以继续实施与《gTLD 注册数据临时规范》或本政策的全部内容或部分内容相符的措施。
-
数据保护协议
ICANN、gTLD 注册管理运行机构和认证的注册服务机构必须 (MUST) 相互签订所要求的数据保护协议，并根据适用法律要求，与适用本政策的相关第三方提供商签订数据保护协议。协议条款可以包括处理注册数据的法律依据。
如果适用法律要求在注册管理运行机构或注册服务机构与 ICANN 之间签订此类协议，ICANN 必须 (MUST) 在收到请求后，与注册管理运行机构或注册服务机构签订根据本政策实施的数据保护协议，不得无故拖延。
如果注册管理运行机构或注册服务机构确定适用法律要求签订此类协议，则必须 (MUST) 根据本政策提出签订协议的请求，不得无故拖延。
数据保护协议也可以 (MAY) 按照适用法律的规定，根据相关数据保护机构的额外指导不时进行修改和更新。
-
注册数据收集
6.1.注册服务机构必须 (MUST) 收集或生成以下数据元素的值（星号表示生成的值）：
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 邮政地址标准或该国家/地区采用的其他同等标准时，才需收集该标准所定义的“州/省”和“邮政编码”值。
只有在《注册服务机构认证协议》或 ICANN 共识性政策要求时，才需生成“注册服务机构 WHOIS 服务器”值。
6.2.注册服务机构可以 (MAY) 为注册域名持有人提供机会，使注册域名持有人为以下数据元素提供值。如果注册服务机构给予这一收集数据值的机会，并且注册域名持有人选择接受提供数据值，则注册服务机构必须 (MUST) 收集这些数据值：
6.2.1.注册人电话分机号码
6.2.2.注册人传真号码
6.2.3.注册人传真分机号码
6.2.4.技术人员姓名
6.2.5.技术人员电话号码
6.2.6.技术人员电子邮件
6.3.如果注册域名持有人提供技术联系人，则注册服务机构必须 (MUST) 在注册时告知注册域名持有人，注册域名持有人可以 (a) 指定与注册域名持有人（或其代表）相同的人员作为技术联系人，此时则无需提供技术联系人的个人联系信息；或者 (b) 提供不构成技术联系人个人身份信息的联系信息（例如，tech-assistance@example.org 电子邮件地址，而非 john.doe@example.org）。
6.4.注册服务机构可以 (MAY) 生成分销商数据元素值。
6.5.注册服务机构必须 (MUST) 为注册域名持有人提供机会，使注册域名持有人为以下数据元素提供值。如果注册域名持有人提供了以下数据元素值，则注册服务机构必须 (MUST) 收集这些值：
6.5.1.注册人组织
6.5.2.域名服务器
6.5.3.域名服务器 IP 地址
6.5.4.DNSSEC 元素
6.6.如果注册域名持有人输入了“注册人组织”数据元素的值，则注册服务机构必须 (MUST) 将以下信息告知注册域名持有人：
6.6.1.如果注册域名持有人同意发布“注册人组织”的值，则将在 RDDS 中发布注册人组织；并且
6.6.2.注册人组织将被视为注册域名持有人。
6.7.注册服务机构可以 (MAY) 根据其《注册管理机构-注册服务机构协议》和/或注册管理运行机构的注册政策的要求，收集其他数据元素。
6.8.注册服务机构可以 (MAY) 删除在本政策生效日期之前收集的管理联系人数据。在删除管理联系人数据之前，注册服务机构必须 (MUST) 确保已经收集了第 6.1.9 至 6.1.16 节所要求的注册域名持有人数据元素的值。
-
将注册数据从注册服务机构传输给注册管理运行机构
7.1.注册服务机构必须 (MUST) 向注册管理运行机构传输以下数据元素：
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.如果收集或生成了以下数据元素，则注册服务机构必须 (MUST) 将其传输给注册管理运行机构：
7.2.1.注册服务机构 WHOIS 服务器
7.2.2.域名服务器
7.2.3.域名服务器 IP 地址
7.2.4.DNSSEC 元素
7.3.如果有适用的法律依据和数据处理协议，则注册服务机构必须 (MUST) 向注册管理运行机构传输以下数据元素：
7.3.1.注册人姓名
7.3.2.注册人所在街道
7.3.3.注册人所在城市
7.3.4.注册人所在国家或地区
7.3.5.注册人电话号码
7.3.6.注册人电子邮件
7.4.如果有适用的法律依据和数据处理协议，并且如果收集了以下数据元素，则注册服务机构必须 (MUST) 向注册管理运行机构传输这些数据元素：
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.如果注册管理运行机构支持，则注册服务机构可以 (MAY) 向注册管理运行机构传输以下数据元素：
7.5.1.注册服务机构注册到期日期
7.5.2.分销商
-
将注册数据传输给数据托管提供商
8.1.注册服务机构必须 (MUST) 以 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.如果注册服务机构收集或生成以下数据元素，则注册服务机构必须 (MUST) 以 ICANN 规定的格式，向 ICANN 批准的数据托管代理提交这些数据元素的电子副本：
8.2.1.注册人组织
8.3.如果注册服务机构收集或生成以下任何数据元素，则注册服务机构可以 (MAY) 以 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.注册管理运行机构必须 (MUST) 以 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.如果从注册服务机构传输了以下数据元素或者由注册管理运行机构生成了以下数据元素，则注册管理运行机构必须 (MUST) 以 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.如果从注册服务机构传输了以下数据元素或者由注册管理运行机构生成了以下数据元素，则注册管理运行机构可以 (MAY) 以 ICANN 规定的格式，向 ICANN 批准的数据托管代理提交这些数据元素的电子副本：
8.6.1.注册管理机构技术人员 ID
8.6.2.技术人员姓名
8.6.3.技术人员电话号码
8.6.4.技术人员电子邮件
-
发布域名注册数据
9.1.RDDS 发布要求
9.1.1.在响应 RDDS 查询时，注册服务机构和注册管理运行机构必须 (MUST) 发布以下数据元素：
9.1.1.1. 域名
9.1.1.2.注册服务机构 URL
9.1.1.3.生成日期
9.1.1.4.注册管理机构到期日期（例外：注册服务机构可以 (MAY) 发布）
9.1.1.5.注册服务机构注册到期日期（例外：注册管理运行机构可以 (MAY) 发布）
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 查询时，注册服务机构和注册管理运行机构必须 (MUST) 发布以下数据元素：
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) 如果收集或生成了以下数据元素，则注册服务机构必须 (MUST) 发布这些数据元素；以及 (b) 如果从注册服务机构传输了以下数据元素或者由注册管理运行机构生成了以下数据元素，则注册管理机构必须 (MUST) 发布这些数据元素：
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) 如果收集了注册人的“州/省”数据元素，则注册服务机构必须 (MUST) 发布该数据元素；以及 (b) 如果从注册服务机构传输了注册人的“州/省”数据元素，则注册管理运行机构必须 (MUST) 发布该数据元素。
9.1.5.在响应 RDDS 查询时，(a) 注册服务机构必须 (MUST) 发布“注册人所在国家或地区”数据元素；以及 (b) 如果从注册服务机构传输了“注册人所在国家或地区”数据元素，则注册管理运行机构必须 (MUST) 发布该数据元素。
9.1.6.在响应 RDDS 查询时，根据第 9.2 节的要求，(a) 注册服务机构必须 (MUST) 发布以下数据元素；以及 (b) 如果从注册服务机构传输了以下数据元素，则注册管理机构必须 (MUST) 发布这些数据元素：
9.1.6.1.注册人姓名
9.1.6.2.注册人所在街道
9.1.6.3.注册人所在城市
9.1.6.4.注册人电话号码
9.1.6.5.注册人电子邮件
9.1.7.在响应 RDDS 查询时，注册服务机构和注册管理运行机构可以 (MAY) 发布“分销商”数据元素。
9.1.8.在响应 RDDS 查询时，注册服务机构可以 (MAY) 发布“域名服务器 IP 地址”数据元素。
9.1.9.在响应 RDDS 查询时，注册管理运行机构：
9.1.9.1.必须 (MUST) 发布“域名服务器 IP 地址”数据元素（当《注册管理机构协议》要求发布如 RFC8499 中所定义的域内粘合记录时）。
9.1.9.2.可以 (MAY) 发布“域名服务器 IP 地址”数据元素（当《注册管理机构协议》没有要求时）。
9.1.10.在响应 RDDS 查询时，根据第 9.2 节的要求，注册服务机构和注册管理运行机构可以 (MAY) 发布以下数据元素：
9.1.10.1.注册人电话分机号码
9.1.10.2.注册人传真号码
9.1.10.3.注册人传真分机号码
9.2.注册数据发布的修订要求
9.2.1.注册管理运行机构和注册服务机构：(a) 如果为了遵守适用法律，需要对注册数据中包含的个人资料进行修订，则必须 (MUST) 在 RDDS 中适用第 9.2 节的要求；(b) 如果满足以下条件之一，则可以 (MAY) 适用第 9.2 节的要求：(i) 具有商业上合理的目的；或者 (ii) 如果适用本节的要求在技术上不可行。在确定是否适用第 9.2 节的要求时，注册管理运行机构和注册服务机构可以 (MAY) 但不是必须考虑：注册数据是否与法人有关或是否包含个人资料；以及注册域名持有人或相关联系人的地理位置。
9.2.2.在第 9.2 节中，“修订”被定义为满足以下条件：注册管理运行机构和注册服务机构 (a) 不得 (MUST NOT) 在 RDDS 输出中包含相应数据元素的值，以及 (b) 必须 (MUST) 指出该值已被修订。
9.2.2.1.如果注册管理运行机构或注册服务机构适用第 9.2.1 节的要求，则必须 (MUST) 修订以下数据元素的值，但后续各节所述的例外情况除外：
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 节的要求，则注册管理运行机构必须 (MUST) 修订以下数据元素的值：
9.2.2.2.1. 注册人电子邮件
9.2.2.2.2. 技术人员电子邮件
9.2.2.3.如果注册管理运行机构适用第 9.2.1 节的要求，则注册管理运行机构可以 (MAY) 修订“注册人组织”的值。
9.2.2.4.如果注册服务机构或注册管理运行机构适用第 9.2.1 节的要求，则可以 (MAY) 修订“注册人所在城市”的值。
9.2.3.如果注册服务机构适用第 9.2.1 节的要求，对于以下数据元素，注册服务机构必须 (MUST) 发布电子邮件地址或网页表单链接，以便与“电子邮件”值的相关联系人进行电子邮件通信，但不得 (MUST NOT) 识别联系人电子邮件地址或联系人本身。
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 节的要求，则注册服务机构必须 (MUST) 提供机会，让注册域名持有人同意发布相应数据元素的值。注册服务机构必须 (MUST) 发布注册域名持有人同意发布的数据元素的值。
9.2.5.对于使用关联或认证隐私或代理服务的注册域名，注册服务机构和注册管理运行机构必须 (MUST) 发布隐私或代理服务的完整注册数据，也可以 (MAY) 包括现有的隐私或代理假名化电子邮件。
9.2.6.如果注册域名持有人同意发布“注册人组织”数据元素的值，则注册服务机构必须 (MUST) 发布该值。如果注册域名持有人不同意发布，则注册服务机构可以 (MAY) 修订“注册人组织”值。
-
披露请求
10.1.注册服务机构和注册管理运行机构必须 (MUST) 在其主页（提供其域名服务的公开网页）上发布一个链接，直接指向详细介绍提交披露请求的机制和流程的页面。该机制和流程必须 (MUST) 明确指定：(a) 要求的请求格式和内容；(b) 向请求者提供响应的方式；(c) 预期的响应时间。
10.2.注册服务机构和注册管理运行机构要求的请求格式和内容必须 (MUST) 至少包括以下信息：
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.注册服务机构和注册管理运行机构必须 (MUST) 对符合各自所要求格式的披露请求作出响应。
10.4.注册服务机构和注册管理运行机构必须 (MUST) 考量每个请求的具体理由和依据，按照实际情况，就事论事对每个格式正确的披露请求进行审核。
10.5.注册服务机构和注册管理运行机构必须 (MUST) 确认收到符合其各自所要求格式的披露请求，不得无故拖延，且必须在收到请求之日起的两 (2) 个工作日内予以确认；并且必须 (MUST) 作出响应，不得无故拖延，无特殊情况下，必须在确认收到请求后三十 (30) 个日历日内予以响应。
10.6.对披露请求的响应必须 (MUST)：
10.6.1.提供所请求的数据；或者
10.6.2.提供注册管理运行机构或注册服务机构不能提供（全部或部分）所请求数据的理由，说明拒绝提供数据的具体原因，包括明确解释如何做出这一决定，从而足以让请求者客观地理解做出该决定的原因。这包括分析和解释如何权衡数据主体的基本权利和自由与请求者的合法利益（如果适用）。
10.7.注册管理运行机构或注册服务机构可以 (MAY) 采取纠正措施来处理不当请求/请求者。纠正措施可以 (MAY) 包括拒绝重复或不完整的请求，要求不当请求者提供默认情况下需要提供的更多信息，以及采取其认为适当的其他措施。必须 (MUST) 向请求者告知所采取的纠正措施。
-
日志文件
11.1.如果注册服务机构适用第 9.2.3 节的要求，则注册服务机构：
11.1.1.必须 (MUST) 维护日志文件，以便确认请求者向注册域名持有人电子邮件地址发出的邮件已被传送。日志文件不得 (MUST NOT) 包含信息来源、收件人、邮件内容或任何个人资料。
11.1.2.可以 (MAY) 维护日志文件，以便确认请求者向技术人员电子邮件地址发出的邮件已被传送。日志文件不得 (MUST NOT) 包含信息来源、收件人、邮件内容或任何个人资料。
11.1.3.出于合规目的，必须 (MUST) 在收到请求时向 ICANN 组织提供与向注册域名持有人电子邮件地址传送邮件相关的日志文件。本条款的任何内容均不得解释为阻止注册服务机构采取合理且适当的措施来防止注册服务机构的联系流程被滥用。
11.2.注册管理运行机构和注册服务机构必须 (MUST) 按照标准业务备案惯例保留请求、确认和响应日志，以便根据需要生成日志，包括但不限于满足 ICANN 组织审核需求。
-
留存注册数据
注册服务机构必须 (MUST) 留存“转让争议解决政策”所需的数据元素，留存期限不得少于注册服务机构在注册支持期结束后或注册服务机构之间（注册人变更）转让注册后十五 (15) 个月。
附录 I
实施 WHOIS（通过端口 43 提供）和基于 Web 的 WHOIS 目录服务应该 (SHALL) 遵守以下规定：
- 对于未收集、生成或传输任何值数据的数据元素，(a) 字段显示的键（即冒号左侧的字符串）在值部分（即冒号右侧部分）必须 (MUST) 不显示任何信息；或 (b) 必须 (MUST) 不显示键和值。
- 对于有值数据且符合本政策第 9.2.2 节要求的数据元素，值部分（即冒号右侧部分）必须 (MUST) 使用字符串“REDACTED”进行替换。
注：本附录 I 适用于（通过端口 43）提供 WHOIS 或基于 Web 的 WHOIS 目录服务的每个注册服务机构和注册管理运行机构。
附录 II
对于生成日期在本政策生效日期之前的现有域名注册：
- 注册服务机构必须 (MUST) 联系已输入“注册人组织”数据元素值的注册域名持有人，并 (a) 请求注册域名持有人审核并确认该值正确无误；以及 (b) 确认注册域名持有人是否同意发布该“注册人组织”值。
- 如果注册域名持有人确认或更正“注册人组织”的值，并同意发布该值，则注册服务机构必须 (MUST)：(a) 通知注册域名持有人，该“注册人组织”值将被视为非个人资料，并且会在本政策的生效日期前发布；(b) 在本政策生效日期前发布第 9.1.3 节所述的“注册人组织”值。
- 如果注册域名持有人拒绝发布“注册人组织”值，或不回应查询，则注册服务机构可以 (MAY) 根据第 9.2.6 节所述，修订（如第 9.2.2 节中所定义）“注册人组织”值，或者可以 (MAY) 删除在本政策生效日期前收集的“注册人组织”值。在删除“注册人组织”值之前，注册服务机构必须 (MUST) 确保已经收集了第 6.1.9 节所要求的注册域名持有人数据元素的值。
实施说明
-
处理注册数据：
- 本政策中的任何规定均不禁止注册管理运行机构或注册服务机构出于超出本政策范围的其他目的处理数据。例如：
- 出于处理域名注册付款目的而收集信用卡信息。
- 为创建联系人而收集或生成其他数据元素，例如：<contact:id>、<contact:authInfo>；或技术联系人所在城市 (<contact:city>) 以及国家或地区 (<contact:cc>)。
- 如果注册服务机构收集其他联系人数据，则可以在 RDDS 中发布相关联系人数据。例如，如果注册服务机构根据第 6.2 节从注册域名持有人处收集技术联系人数据，并修订第 9.2.2.1.10 节至第 9.2.2.1.12 节中列出的数据元素值，则注册服务机构可以 (MAY) 提供机会，让相关联系人同意发布这些数据元素值。注册服务机构可以 (MAY) 发布相关联系人同意发布的数据元素值。
- 本政策中的任何规定均不禁止注册管理运行机构或注册服务机构出于超出本政策范围的其他目的处理数据。例如：
-
传输注册数据
- 本政策中的任何规定均不妨碍注册服务机构或注册管理运行机构向数据托管代理传输其他数据元素（例如：用于提供《注册管理机构协议》中定义的注册管理机构服务）。
- 在适用法律要求提供法律依据的情况下，本政策中的任何规定均不妨碍注册管理运行机构在有法律依据的情况下，要求注册服务机构传输其他数据元素值。
- 如果根据第 7 节的规定，将数据从注册服务机构传输给注册管理运行机构时需要提供法律依据，则法律依据将由传输各方确定。法律依据的存在不由 ICANN 组织确定，也不受强制执行的约束。如果注册管理运行机构和注册服务机构确定存在法律依据，并且注册管理运行机构和注册服务机构已就要传输的数据签订了数据保护协议，则 ICANN 组织可以执行第 7 节规定的传输要求。
- 如果适用法律没有要求，则注册管理运行机构和注册服务机构无需确定处理个人资料的法律依据，包括将数据从注册服务机构传输给注册管理运行机构的法律依据。
-
将注册数据传输给托管提供商
为明确起见，根据适用的《注册管理机构协议》，注册管理运行机构必须托管所有必需的数据元素，以便提供所有经其批准的注册管理机构服务。
-
发布注册人组织
- “注册人姓名”将被视为注册人组织的联络点。
- 注册服务机构可以使用自己的流程征得注册域名持有人同意发布“注册人组织”值，并告知注册域名持有人第 6.6.1 和 6.6.2 节中的要求，例如，通过弹出窗口通知、选择加入式 (opt-in) 要求、在注册人明确同意发布数据元素（通过勾选相应方框）之前将“注册人组织”灰显等方式，来显示披露信息、免责声明或请求，供注册域名持有人确认“注册人组织”的值并同意予以发布。此处所举示例并未详尽列明所有可能方式。
-
响应合法披露的合理请求
在评估注册服务机构或注册管理运行机构对披露请求的响应时间时，ICANN 组织可考虑：收到的请求数量；管理的域名数量；平均响应时间；以及被拒绝的请求数量。
-
留存注册数据
- 本政策中的任何规定均不禁止注册服务机构和注册管理运行机构在法律、法律程序或其他适当法律依据要求的情况下设定留存期限，其中可能包括酌情请求数据留存义务弃权书。
- 注册服务机构无需请求弃权书即可设定更长的留存期限。ICANN 组织的数据留存弃权程序允许注册服务机构请求较短的数据留存期限。
- 为明确起见，第 12 节中的数据留存要求仅适用于注册数据（如本政策中所定义），并且不妨碍请求者（包括 ICANN 合规部）请求出于转让争议解决政策 (Transfer Dispute Resolution Policy, TDRP) 以外的目的披露这些留存的数据元素。
-
关联和认证隐私或代理服务
《注册服务机构认证协议》第 1.3 节对“关联”进行了定义，并在《注册服务机构认证协议》第 1.7 节中作了进一步解释。认证的隐私或代理服务提供商（如有）将从《隐私和代理服务认证政策》生效之日起遵守此要求。
-
生成日期
本政策中的“生成日期”是指，在注册管理机构数据库中创建域名对象的时间点。
-
更新日期
对于注册服务机构而言，本政策中的“更新日期”是指，第 7 节中列出的任何数据元素在注册服务机构数据库或注册管理机构数据库中发生的最新一次更新。
背景介绍
2018 年 5 月 17 日，ICANN 董事会通过了《gTLD 注册数据临时规范》。为符合欧盟《通用数据保护条例》(GDPR) 的规定，“临时规范”修改了《注册服务机构认证协议》和《注册管理机构协议》中的部分现有要求，最大程度地确保 WHOIS 服务的持续可用性，并在遵守规定的同时对 gTLD 注册数据进行其他处理，避免 WHOIS 碎片化。根据 ICANN 章程以及《注册管理机构协议》(RA) 和《注册管理机构-注册服务机构协议》(RAA) 中的共识性政策和临时政策规范要求，“临时规范”自 2018 年 5 月 25 日生效之日起，最多一年有效。
2018 年 7 月 19 日，通用名称支持组织 (GNSO) 理事会启动了一个分两阶段进行的快速政策制定流程 (Expedited Policy Development Process, EPDP)，并授权成立 gTLD 注册数据临时规范 EPDP 团队。在第 1 阶段工作中，EPDP 团队的任务是，确定是将《gTLD 注册数据临时规范》一字不改地纳入“ICANN 共识性政策”，还是适当修改后再纳入。此外，章程还要求，结果必须符合 GDPR 的规定，同时充分考虑其他相关隐私法和数据保护法。按照章程，EPDP 团队第 2 阶段工作的任务是评估非公开 gTLD 注册数据的标准化访问/披露系统，解决临时规范附录中指出的问题，以及解决第 1 阶段悬而未决的其他问题。
2018 年 11 月 21 日，EPDP 团队发布了第 1 阶段初步报告，以征询公众意见。初步报告中包含 EPDP 团队要征询公众意见的初步建议和各种问题。EPDP 团队还对以下方面进行了审核并提出了一些建议：(i)“临时规范”中所述目的的有效性、合理性和法律依据，(ii)“临时规范”中所述 (x) 注册服务机构收集注册数据的合理性、必要性和范围，以及 (y) 将数据从注册服务机构转移到注册管理机构的合理性、必要性和范围，(iii)“临时规范”中所述注册服务机构和注册管理机构对注册数据的发布。
2019 年 2 月 20 日，EPDP 团队发布了其最终报告，GNSO 理事会于 2019 年 3 月 4 日通过了该报告。ICANN 组织于 2019 年 3 月 4 日开启了关于最终报告的公共评议期。在董事会采取行动前，该公共评议期曾针对《gTLD 注册数据临时规范》就 GNSO EPDP 的最终政策建议征询社群意见。关于公众意见的摘要和分析报告于 2019 年 4 月 23 日发布。董事会于 2019 年 5 月 15 日批准通过了相关建议，少数建议除外。
成立了共识性政策实施团队，以开始制定实施规划。此外，还成立了一个由 PDP 工作组成员和感兴趣的社群成员组成的实施审核小组 (Implementation Review Team, IRT)，以根据 ICANN 组织制定并由 GNSO 理事会批准通过的共识性政策实施框架 (Consensus Policy Implementation Framework, CPIF)，与共识性政策实施团队展开合作。
在董事会决议之前，实施团队提出了政策实施三个阶段的构想。
- 第 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 优先级建议”。2021 年 6 月 21 日，董事会通过了建议 19-22，并将这些建议的实施纳入了注册数据政策实施的工作范围。
2022 年 2 月 24 日，董事会通过了 GNSO 理事会对 EPDP 建议 12 的补充建议，该建议涉及删除“组织”字段中的数据，因为它解决了董事会对基本数据丢失的首要关切。