注册数据临时规范

临时规范
临时规范（自 2018 年 5 月 25 日起生效）
PDF 下载：英文、阿拉伯文、中文、法文、俄文、西班牙文
ICANN董事会决议[2018.05.17.01 – 2018.05.17.09]
ICANN董事会决议[2018.08.21.01 – 2018.08.21.02]
ICANN董事会决议[2018.11.06.03 – 2018.11.06.04]
ICANN董事会决议[2019.01.27.14 – 2019.01.27.15]
背景
其他资源
咨询声明： gTLD注册数据临时规范[PDF, 511 KB]
Calzone 型号与临时规范要求的比较[PDF, 61 KB]
变更红线 - gTLD注册数据临时规范[PDF, 356 KB]
实施gTLD注册数据临时规范的常见问题解答，更新于 2018 年 7 月 6 日
ICANN临时规范模型注册管理机构-注册服务商协议修订条款：
PDF：英文、阿拉伯文、中文、法文、俄文、西班牙文
DOCX [35 KB]
gTLD 临时注册数据政策
ICANN的注册数据
背景
欧盟 (EU) 于 2016 年 4 月通过了通用数据保护条例 (GDPR)，并于 2018 年 5 月 25 日在欧盟国家全面生效。在过去的一年里，ICANN组织 ( ICANN org ) 咨询了缔约方、欧洲数据保护机构、法律专家、感兴趣的政府和其他利益相关方，以了解 GDPR 对某些参与者处理的个人数据的潜在影响。gTLD域名生态系统（包括注册管理运行机构和注册服务机构）符合ICANN政策和ICANN与受 GDPR 约束的此类参与者之间的合同。

本gTLD注册数据临时规范（临时规范）规定了临时要求，以允许ICANN和gTLD注册管理机构运营商和注册商继续遵守现有的ICANN合同要求和社群根据 GDPR 制定的政策。与ICANN遵守 GDPR 的既定目标一致，同时尽可能维护现有的WHOIS系统，临时规范维护注册数据（包括注册人）的强大收集、管理和技术联系信息），但将大多数个人数据限制为分层/分层访问。具有访问非公开个人数据的合法和相称目的的用户将能够通过注册服务商和注册管理运行机构请求此类访问。用户还将保持联系注册人的能力通过匿名电子邮件或 Web 表单进行管理和技术联系。临时规范应在 GDPR 要求的情况下实施，同时为注册管理运行机构和注册服务商提供灵活性，让他们可以选择在全球范围内应用这些要求，如果这样做在商业上是合理的，或者在技术上不可行的情况下将要求的应用限制在受 GDPR 管辖的数据。临时规范适用于所有注册，不要求注册服务商区分法人和自然人的注册。它还涵盖ICANN、注册管理运行机构、注册服务商和数据托管代理之间的数据处理安排，这些安排是遵守 GDPR 所必需的。

本临时规范由ICANN董事会（ICANN董事会）于 2018 年 5 月 17 日根据制定临时政策和临时规范或政策（此类术语在ICANN的注册管理机构协议和注册商委任协议）。包含ICANN董事会采纳此临时规范原因的详细解释的咨询声明可在此处获取： https ://www.icann.org/en/system/files/files/advisory-statement-gtld-registration-data-specs -17may18-en.pdf [PDF，511 KB]。

目录
gTLD注册数据临时规范

一、适用范围

2.定义和解释

3.保单生效日期

4.处理gTLD注册数据的合法性和目的

5.适用于注册管理运行机构和注册服务商的要求

6.仅适用于注册管理运行机构的要求

7.仅适用于注册商的要求

8.杂项

附录 A：注册数据目录服务

附录 B：补充数据托管要求

附录 C：数据处理要求

附录 D：统一快速暂停

附录 E：统一域名争议解决政策

附录 F：对ICANN的批量注册数据访问

附录 G：转移政策的补充程序

附件：进一步社区行动的重要问题

实施说明

范围
1.1. 本临时规范中使用的术语在第 2 节中定义。

1.2. 本临时规范适用于所有gTLD注册管理运行机构和ICANN认可的注册商。

1.3. 本临时规范的要求取代并取代注册管理运行机构的注册管理机构协议和注册服务机构的注册服务机构委任协议中关于本临时规范中所含事项的要求。如果本临时规范的要求与注册管理运行机构的注册管理机构协议和注册服务机构的注册服务机构委任协议的要求存在冲突，则应以本临时规范的条款为准，除非ICANN以其合理的判断力决定本临时规范不应控制。为清楚起见，除非本临时规范特别说明和修改，否则注册管理运行机构的注册管理机构协议和注册服务机构的注册服务机构委任协议以及共识政策中的所有其他要求和义务仍然适用并有效

定义和解释
术语“可以”、“必须”、“不得”、“要求”、“推荐”、“应”、“不应”、“不应”和“应该”用于表示符合RFC 2119，可从http://www.ietf.org/rfc/rfc2119.txt获得。

“同意”、“控制者”、“个人数据”、“处理”和“处理者”应具有与 GDPR 第 4 条相同的定义。

“ gTLD ”应具有注册商委任协议中给出的含义。

“临时模型”是指与欧盟通用数据保护条例相关的ICANN协议和政策合规性临时模型，发布于https://www.icann.org/en/system/files/files/gdpr-compliance-interim -model-08mar18-en.pdf [PDF, 922 KB] 并且可能会不时修订。

“注册名称”应具有《注册商委任协议》中给出的含义。

“注册名称持有人”应具有《注册商委任协议》中给出的含义。

“注册服务商委任协议”是指注册服务商与ICANN之间的任何注册服务商委任协议，该协议基于ICANN董事会于 2013 年 6 月 27 日批准的特定 2013 年注册服务商委任协议（“2013 年注册服务商委任协议”）或此类协议的任何后续协议由ICANN董事会批准。

“注册数据”是指从自然人和法人处收集的与域名注册相关的数据。

“注册数据目录服务”是指WHOIS、基于 Web 的WHOIS和 RDAP 服务的集合。

“注册管理机构协议”是指注册管理执行机构与ICANN之间的任何gTLD注册管理机构协议，包括任何基于ICANN董事会于 2013 年 7 月 2 日批准的新gTLD注册管理机构协议（经修订）的任何注册管理机构协议（“基础注册管理机构协议”）。

如果术语大写但未在本临时规范中定义，则该术语应具有注册管理机构协议或注册服务商委任协议（如适用）中赋予的含义。

除非本文另有明确规定，否则术语“或”不应被视为具有排他性。

当在本临时规范的条款中同时提及注册管理运行机构和注册服务机构时，每条此类规定代表每个注册管理运行机构和每个注册服务机构根据其各自的注册管理机构协议或注册服务机构委任协议的单独要求和义务。

保单生效日期
本临时规范自 2018 年 5 月 25 日起生效。

处理gTLD注册数据的合法性和目的
4.1. 如章程第 1.1(a) 节所述， ICANN的使命是“协调互联网唯一标识符系统的稳定运行”。第 1.1(a) 节具体描述了此任务在名称上下文中的含义。虽然ICANN的职责范围很窄，但并不局限于技术稳定性。具体而言，章程规定ICANN的目的是协调自下而上的多利益相关方制定和实施政策，“[f] 统一或协调的解决方案对于促进开放性、互操作性、弹性、安全性和/或DNS的稳定性，包括gTLD注册商和注册管理机构”[章程第 1.1(a)(i) 节]，在章程的附件 G-1 和 G-2 中进一步定义，其中包括：

解决有关域名注册的争议（相对于此类域名的使用，但包括此类政策考虑域名使用的情况）；
维护和访问有关注册名称和名称服务器的准确和最新信息；
避免因注册运营商或注册服务商（例如托管）暂停或终止运营而导致域名注册中断的程序；和
在赞助一个或多个注册名称的注册服务商发生变化时转移注册数据。
4.2. 章程明确指出，围绕注册管理运行机构和注册服务机构提供注册数据目录服务 (RDDS) 的问题完全属于ICANN的使命范围。章程进一步深入了解旨在由 RDDS 服务的合法利益。例如，章程明确要求ICANN在履行其职责时“充分解决竞争、消费者保护、安全、稳定和弹性、恶意滥用问题、主权问题和权利保护等问题”[章程第 4.6 (d) 节]. 虽然ICANN既没有权力也没有专业知识来执行竞争或消费者保护法，并且只是网络安全生态系统中的众多利益相关者之一，提供 RDDS 用于合法和相称的使用是ICANN解决消费者保护、恶意滥用问题的关键和基本方式问题、主权问题和权利保护——执行政策，使消费者、权利持有人、执法部门和其他利益相关者能够访问必要的数据，以处理和解决违反法律或权利的使用。

4.3. 因此，ICANN的使命直接涉及为与执法、竞争、消费者保护、信任、安全、稳定、弹性、恶意滥用、主权和权利保护相关的合法和相称目的的第三方处理提供便利。章程第 4.6(e) 节要求ICANN根据适用法律“使用商业上合理的努力来执行其与注册目录服务相关的政策”，包括与利益相关方合作“探索结构变化以提高准确性和访问权限通用顶级域注册数据”，“以及考虑保护此类数据的保障措施。” 因此，ICANN认为收集个人数据（处理的要素之一）是章程特别规定的。此外，根据注册管理运行机构与 ICANN 的注册管理机构协议和注册服务机构与ICANN的注册服务机构委任协议的要求和允许，注册管理运行机构和注册服务机构处理注册数据中的个人数据的其他要素是确保协调、稳定和安全的必要条件互联网唯一标识符系统的运行。

4.4. 但是，此类处理必须以符合 GDPR 的方式进行，包括基于此类处理的特定确定目的。因此，注册数据中包含的个人数据可能会根据合法利益进行处理，这些合法利益不会被其个人数据包含在注册数据中的个人的基本权利和自由所凌驾，并且仅用于以下合法目的：

4.4.1. 反映注册名称持有人在注册名称中的权利，并确保注册名称持有人可以就注册名称行使其权利；

4.4.2. 根据 GDPR 的规定，根据不高于相关数据主体基本权利的合法利益，提供对准确、可靠和统一注册数据的访问权限；

4.4.3. 启用一种可靠的机制来识别和联系注册名称持有人，以用于下文更全面阐述的各种合法目的；

4.4.4. 启用一种机制，由其选择的注册服务商向注册域名持有人传达或通知付款和发票信息以及提醒；

4.4.5. 启用一种机制，用于就注册名称或与此类注册名称相关的任何内容或资源的技术问题和/或错误向注册名称持有人进行沟通或通知；

4.4.6. 为注册管理运行机构或选定的注册服务商启用一种机制，以便与注册名称持有人沟通或通知注册名称持有人已注册注册名称的域中的商业或技术变化；

4.4.7. 应注册域名持有人的要求，允许发布管理域名的技术和管理联系人；

4.4.8. 支持解决涉及域名注册问题的框架，包括但不限于：消费者保护、网络犯罪调查、DNS滥用和知识产权保护；

4.4.9. 提供一个框架来解决适当的执法需求；

4.4.10。促进向互联网用户提供 gTLD 的区域文件；

4.4.11。提供机制，在出现业务或技术故障或注册服务商或注册管理运行机构出现其他不可用情况时保护已注册名称持有人的注册数据；

4.4.12。协调特定域名争议的争议解决服务；和

4.4.13。处理注册管理运行机构、注册服务商、注册名称持有人和其他互联网用户提交的合同合规性监控请求、审计和投诉。

4.5. 在考虑处理注册数据中包含的个人数据是否符合 GDPR 1第 6(1)(f) 条时，GDPR 要求ICANN平衡上述合法利益与受影响数据的利益、权利和自由主题。ICANN发现处理是相称的，原因如下：

4.5.1. 处理本临时规范中确定的有限个人数据对于实现确定的合法利益是必要的，正如在为期 12 个月的社区咨询过程中许多利益相关者的评论和意见中所记录的那样。此处理具体包括保留已收集的个人数据和正在进行的个人数据收集；

4.5.2. 临时模型中确定并在本临时规范中实施的 RDDS 分层/分层访问框架专门设计用于最大限度地减少处理的侵入性，同时仍允许必要的处理；

4.5.3. 根据本临时规范的要求，在分层/分层访问框架下进行处理可最大限度地降低未经授权和不正当处理的风险；

4.5.4. 本临时规范包含一些要求，以确保注册名称持有人了解预期的处理以及他们在此类处理方面的权利；

4.5.5. 本临时规范包含确保保留适当的处理活动记录以满足 GDPR 中规定的问责义务的要求。

适用于注册管理运行机构和注册服务商的要求
5.1. 注册数据的发布。注册管理运行机构和注册服务机构必须遵守所附附录 A（“附录 A ”）的要求，并且必须提供注册数据的公共访问权限。

5.2. 注册服务商和注册管理运行机构服务级别协议。注册管理运行机构和注册服务机构承认，在实施注册数据访问协议(RDAP) 服务时，他们必须遵守额外的服务水平协议。ICANN和签约方将在 2018 年 7 月 31 日之前就适当的服务水平协议进行真诚协商。如果签约方和ICANN无法在该日期之前通过真诚协商确定此类服务水平协议，ICANN将要求注册服务商和注册管理运行机构遵守与 RDDS 各自协议中已经存在的服务级别相当的服务级别。

5.3. 数据托管。注册管理运行机构和注册服务机构必须遵守附录 B（“附录 B ”）中规定的有关注册数据托管程序的附加要求。

5.4. 数据处理要求。注册管理运行机构和注册服务机构必须遵守本协议所附附录 C（“附录 C ”）中规定的条款和条件的要求，并且必须处理个人数据。

5.5. 注册管理运行机构、注册服务商和ICANN之间的国际数据传输。在执行本临时规范、注册管理机构协议和注册服务机构委任协议的要求的过程中，注册管理运行机构、注册服务机构和/或ICANN可能需要将个人数据传输到欧盟委员会认为不符合条款规定的国家/地区GDPR 第 45(1) 条。在这种情况下，ICANN、注册管理运行机构和/或注册服务商必须根据 GDPR 第 V 章允许的充分保障措施传输个人数据，包括使用标准合同条款 (2004/915/ EC )（或其后续条款）条款）和ICANN、注册管理运行机构和/或注册服务商必须遵守此类适当的保护措施。

5.6. 统一快速暂停 ( URS )。注册管理运行机构和注册服务机构必须遵守 2013 年 10 月 17 日针对注册管理机构和注册服务机构的URS高级技术要求的附加要求，详见附录 D（“附录 D ”）。

5.7. ICANN合同合规部。注册管理运行机构和注册服务机构必须根据ICANN的合理通知和请求向ICANN提供对注册数据的合理访问权限，以便调查与注册管理机构协议、注册服务机构委任协议和ICANN 共识性政策的合规相关查询和执行情况。

仅适用于注册管理运行机构的要求
6.1. 对ICANN的批量注册数据访问。注册管理运行机构必须遵守并必须根据随附的附录 F（“附录 F ”）向ICANN提供对注册数据的定期访问权限。

6.2. 注册月度报告。ICANN和注册管理运行机构将在 2018 年 7 月 31 日之前就其实施 RDAP 真诚协商适当的额外报告要求。如果ICANN和注册管理运行机构无法在该日期之前通过真诚协商确定此类额外报告要求，ICANN将要求注册管理机构运营商遵守与 RDDS 的注册协议中已经存在的报告要求相当的额外报告要求。

6.3. 注册管理机构协议。

6.3.1. 注册管理运行机构必须在其与注册服务商签订的注册管理机构-注册服务商协议中包含关于以符合 GDPR 第 28 条适用要求的方式处理个人数据的处理条款。

6.3.2. 注册管理运行机构可以修改或重申其注册管理机构-注册服务商协议，以纳入数据处理条款和条件（其本身包含欧盟示范条款以管理国际数据传输，如果适用于各方之间），与 << https:/中提供的要求基本相似/www.icann.org/resources/pages/gtld-registration-data-specs-en/#6 >> 无需ICANN的任何进一步批准，前提是注册管理运行机构必须立即向 ICANN 交付任何此类修订或重述的注册管理机构-注册服务商协议. 在ICANN在收到此类修订或重述的注册管理机构-注册服务商协议后，将视作补充或替换（如适用）已批准的注册管理机构-注册服务商协议，该协议作为注册管理运行机构的注册管理机构协议的附录（如果有）随附。

仅适用于注册商的要求
7.1. 注册名称持有人关于数据处理的通知。注册服务商应向每个现有的、新的或更新的注册名称持有人发出通知，说明：

7.1.1. 注册商处理任何个人数据的具体目的；

7.1.2. 个人数据的预期接收者或接收者类别（包括注册管理运行机构和将从注册运行机构接收个人数据的其他人）；

7.1.3. 哪些数据是强制性的，哪些数据（如果有）是自愿的；

7.1.4. 注册名称持有人或数据主体如何访问并在必要时纠正持有的有关他们的个人数据；

7.1.5. 注册服务商（作为控制者）以及注册服务商在欧洲经济区的代表（如适用）的身份和联系方式；

7.1.6. 注册商数据保护官的详细联系方式（如适用）；

7.1.7. 根据 GDPR 第 6(1)(f) 条处理的指定合法权益；

7.1.8. 个人数据的接收者或接收者类别（如果有）；

7.1.9. 在适用的情况下，注册服务商打算将个人数据传输到：(i) 到第三国或国际组织，以及委员会是否存在充分性决定；(ii) 在 GDPR 第 46 条或第 47 条或 GDPR 第 49(1) 条第 2 项中提及的转移的情况下，提及适当或适当的保障措施以及如何获得它们的副本或它们在哪里可用。

7.1.10。个人数据的存储期限，或者如果无法指明期限，则用于确定该期限的标准；

7.1.11。是否存在要求注册服务商访问、更正或删除个人数据的权利，或限制处理与注册名称持有人或数据主体有关的个人数据，或反对处理的权利，以及数据权可移植性;

7.1.12。遵守 GDPR 第 6(1)(a) 条和第 9(2)(a) 条，其中注册服务商依赖已注册域名持有人的同意进行处理；

7.1.13。注册名称持有人或数据主体向相关监管机构投诉的权利；

7.1.14。提供个人资料是否为法定或合约要求，或订立合约的必要要求，以及注册名称持有人是否有义务提供个人资料，以及未能提供该等个人资料可能产生的后果; 和

7.1.15。GDPR 第 22(1) 和 (4) 条中提到的自动化决策（包括分析）的存在，至少在这些情况下，关于所涉及逻辑的有意义信息，以及重要性和预期后果为数据主体进行此类处理。

本第 7.1 节的要求应取代和替换《注册服务商委任协议》第 3.7.7.4 节的要求。

7.2. 注册数据的附加发布。

7.2.1. 在商业上合理的情况下，注册服务商必须尽快为注册名称持有人提供机会，以表示同意为注册名称持有人发布附录 A 第 2.3 节中概述的其他联系信息。

7.2.2. 注册服务商可以为管理员/技术人员和/或其他联系人提供机会，以同意发布附录 A 第 2.4 节中概述的其他联系信息。

7.2.3. 如果注册服务商寻求此类同意，则应以明显区别于其他事项（包括基于合法利益处理的其他个人数据）的方式提出同意请求。同意请求应采用易于理解和易于访问的形式，使用清晰明了的语言。注册名称持有人应有权随时撤回其同意。撤回同意不得影响基于撤回前获得的同意进行处理的合法性。

7.2.4. 注册服务商必须公布附录 A 第 2.3 节和第 2.4 节中列出的已获得其同意的其他联系信息。

7.3. 统一域名争议解决政策。注册服务商必须遵守附录 E（“附录 E ”）中规定的统一域名争议解决政策规则的附加要求。

7.4. 转让政策。注册商必须遵守附录 G（“附录 G ”）中规定的转让政策的补充程序。

各种各样的
8.1. 无第三方受益人。本临时规范不得解释为ICANN、注册管理运行机构或注册服务商对本临时规范的任何非当事方（包括注册名称持有人）产生任何义务。

8.2. 对临时规范的修改。本临时规范的实施细节可以根据ICANN董事会三分之二的投票结果进行修改，以根据第 29 条工作组/欧洲数据保护委员会的进一步意见、具有管辖权的相关法院关于GDPR、适用的法律或法规，或作为董事会-GAC 章程咨询的结果，涉及圣胡安公报中有关WHOIS和 GDPR的GAC建议。

8.3. 可分割性。本临时规范应被视为可分割的；本临时规范的任何条款或规定的无效或不可执行性不应影响本临时规范或本协议任何其他条款的其余部分的有效性或可执行性，这些条款应保持完全有效。

附录 A：注册数据目录服务
注册数据目录服务

本节修改了以下相关要求：(i) 2013 年注册商委任协议的注册数据目录服务 ( WHOIS ) 规范；(ii) 如果是仿照基本注册协议的注册协议，则为基本注册协议规范 4 的第 1 节；(iii) 如果注册管理机构协议不是以注册管理机构基本协议为蓝本，则此类注册管理机构协议的条款与基本注册管理机构协议规范 4 第 1 节的规定相当；(iv) 注册管理机构注册数据目录服务一致标签和显示政策的第 10 条。

1.1. 注册商和注册管理运行机构必须运行注册数据访问协议(RDAP) 服务。ICANN和社群将在 2018 年 7 月 31 日之前定义适当的配置文件。ICANN随后将发出实施此类服务的通知，并且注册服务商和注册管理运行机构应在ICANN提出请求后的 135 天内实施该服务。注册服务商和注册管理运行机构可以在需要 RDAP 服务的日期之前运行试点 RDAP 服务。

1.2. RDDS 搜索功能

1.2.1. 在允许和提供搜索功能的情况下，注册管理运行机构和注册服务商必须：(1) 确保此类搜索功能符合适用的隐私法律或政策；(2) 根据用户是否只能访问 RDDS 中公开可用的数据或用户是否可以访问非公开注册数据，仅允许搜索查询用户可用的其他数据；(3) 根据用户是否只能访问 RDDS 中公开可用的数据或用户是否可以访问非公开注册数据，仅向查询用户提供其他可用的结果；(4) 确保此类搜索功能在其他方面符合本临时规范关于访问公共和非公共注册数据的要求。

1.2.2. 在允许和提供搜索功能的情况下，注册管理运行机构和注册服务机构必须在基于 Web 的目录服务和 RDAP 服务（实施时）上提供搜索功能。

在处理受 GDPR 约束的公共 RDDS 中处理个人数据的要求

2.1. 注册管理运行机构（注册管理运行机构运行“瘦”注册管理机构的情况除外）和注册服务商必须对注册数据中包含的个人数据应用本附录第 2 和 4 节中的要求，其中：

根据 GDPR 第 3(1) 条的规定，注册商或注册管理运行机构在欧洲经济区 (EEA) 成立，并处理注册数据中包含的个人数据；
注册服务商或注册管理运行机构在 EEA 以外成立，并按照 GDPR 第 3(2) 条的规定向位于 EEA 的注册名称持有人提供注册服务，涉及处理来自位于 EEA 的注册人的个人数据；或者
注册服务商或注册管理运行机构位于 EEA 之外并处理注册数据中包含的个人数据，并且注册管理运行机构或注册服务运行机构聘请位于 EEA 内的处理者来处理此类个人数据。
2.2. 对于本附录第 2.3 和 2.4 节要求“编辑”的字段，注册服务商和注册管理运行机构必须在编辑字段文本的值部分中提供与以下基本类似的内容：“为隐私而编辑”。在规定的 RDAP 实施日期之前，注册服务商和注册管理运行机构可以：(i) 在编辑字段的值部分不提供任何信息；(ii) 不发布编辑字段。

2.3. 在响应域名查询时，注册服务商和注册管理运行机构必须将以下注册人字段视为“已编辑”，除非已注册名称持有人同意发布已注册名称持有人的数据：

注册局注册人ID
注册人姓名
注册人街道
注册城市
注册人邮政编码
注册人电话
注册人电话分机
注册人传真
注册人传真分机
2.4. 在响应域名查询时，注册服务商和注册管理运行机构必须将以下字段视为“已编辑”，除非联系人（例如，管理员、技术人员）同意发布联系人的数据：

注册表管理员/技术人员/其他 ID
管理员/技术/其他名称
行政/技术/其他组织
行政/技术/其他街道
行政/技术/其他城市
行政/技术/其他州/省
行政/技术/其他邮政编码
行政/技术/其他国家
行政/技术/其他电话
行政/技术/其他电话分机
行政/技术/其他传真
行政/技术/其他传真分机
2.5. 在响应域名查询时，在每个联系人（例如，Registrant、Admin、Tech）的“Email”字段的值中：

2.5.1. 注册服务商必须提供电子邮件地址或网络表格，以促进与相关联系人的电子邮件通信，但不得识别联系人电子邮件地址或联系人本身。

2.5.1.1。电子邮件地址和 Web 表单的URL必须提供将收到的通信转发到适用联系人的电子邮件地址的功能。

2.5.1.2。注册服务商可以实施商业上合理的保护措施来过滤掉垃圾邮件和其他形式的滥用通信。

2.5.1.3. 从电子邮件地址和为促进与相关联系人的电子邮件通信而提供的 Web 表单的URL中提取或派生联系人的电子邮件地址不得可行。

2.5.2. 注册管理运行机构必须提供与以下基本类似的消息：“请查询此输出中标识的记录注册商的 RDDS 服务，以获取有关如何联系所查询域名的注册人、管理员或技术联系人的信息。”

2.6. 尽管有本附录第 2.2、2.3、2.4 和 2.5 节的规定，在使用隐私/代理服务的域名注册情况下（例如，与自然人相关的数据被屏蔽），注册商必须返回以响应任何查询完整的WHOIS数据，包括现有的代理/代理假名电子邮件。

关于处理不受 GDPR 约束的公共 RDDS 中的个人数据的附加规定

注册管理运行机构和注册服务商可以应用本附录第 2 节中的要求 (i) 出于商业上合理的目的，或 (ii) 限制应用附录第 2.1 节中规定的要求的应用在技术上不可行本附录。

访问非公开注册数据

4.1. 注册服务商和注册管理运行机构必须根据第三方追求的合法利益向第三方提供对注册数据中个人数据的合理访问权限，除非此类利益被注册名称持有人的利益或基本权利和自由所凌驾或GDPR 第 6(1)(f) 条规定的数据主体。

4.2. 尽管有本附录第 4.1 节的规定，注册服务商和注册管理运行机构必须向第三方提供对注册数据中个人数据的合理访问权限，如果第 29 条工作组/欧洲数据保护委员会、具有管辖权的相关法院关于 GDPR 的法院命令，适用的法律或法规已提供指导，即出于特定目的向特定类别的第三方提供注册数据的特定非公开元素是合法的。注册服务商和注册管理运行机构必须在ICANN发布任何此类指南之日起 90 天内提供此类合理的访问权限，除非法律要求另有要求提前实施。

附加数据字段的发布

注册服务商和注册管理运行机构可以根据附录 C中的数据处理要求输出额外的数据字段。

附录 B：补充数据托管要求
数据处理要求

注册管理运行机构和注册服务机构必须分别确保注册管理运行机构与托管代理和/或注册服务机构与托管代理之间的任何数据托管协议包含符合 GDPR 第 28 条的数据处理要求。此类托管代理必须提供充分的保证，以实施适当的技术和组织措施，使处理符合 GDPR 的要求，并确保保护数据主体的权利。

国际转账

在根据与托管代理达成的协议执行要求的过程中，托管代理可能需要在欧盟委员会根据 GDPR 第 45(1) 条认为不适当的国家/地区处理个人数据。在这种情况下，传输和处理将基于 GDPR 第五章允许的充分保障措施，包括使用标准合同条款 (2004/915/ EC )（或其后续条款）和托管代理控制者必须遵守此类适当的保障措施。

ICANN批准

注册管理运行机构可以修改或重申其各自的数据托管协议，以纳入与 << http://www.bqjs.org//resources/pages/gtld-registration-data-specs-en中提供的要求基本相似的数据处理条款和条件>> 无需ICANN的任何进一步批准，前提是注册管理运行机构和注册服务商必须及时向ICANN交付任何此类修订或重述的数据托管协议。ICANN收到后，此类修订或重述的数据托管协议将被视为补充或替换（如适用）已批准的数据托管协议，该协议作为注册管理运行机构的注册管理机构协议的附录（如果有）。

其他要求

除上述要求外，数据托管协议可能包含与上述要求条款不矛盾、不一致或旨在颠覆的其他数据处理条款。

附录 C：数据处理要求
本附录规定了在作为数据控制者或数据处理者的各方之间处理和共享包含个人数据的注册数据的框架，如下表所示，并定义了各方应遵守的原则和程序以及双方的责任各方相互欠债。双方共同承认并同意，注册数据的处理由双方在互联网的复杂环境中的不同阶段进行，有时甚至同时进行。因此，需要本附录以确保在可以访问个人数据的情况下，此类访问将始终符合 GDPR 的要求。除非在本附录中定义，首字母大写的术语具有 GDPR 中给出的含义。

gTLD处理活动    注册商角色/法律依据    注册管理运行机构角色/法律依据    ICANN角色/法律依据
从注册名称持有人处收集注册数据    控制器（合同的同意和履行）    控制者（合法权益和合同履行）    控制人（合法权益）
将注册数据从注册服务商转移到注册管理运行机构或注册管理运行机构后端服务提供商    处理者（合同的履行）    控制人（合法权益）    控制人（合法权益）
将注册数据从注册管理运行机构传输到数据托管代理    无角色    处理者（合同的履行）    控制人（合法权益）
将注册数据从注册商转移到数据托管代理    处理者（合同的履行）    无角色    控制人（合法权益）
将注册数据传输给ICANN合同合规部    处理器    处理器    控制人（合法权益）
将注册数据传输至紧急后端注册管理运行机构 ( EBERO )    无角色    处理者（合同的履行）    控制人（合法权益）
公共 RDDS/ WHOIS    控制人（合法权益）    控制人（合法权益）    控制人（合法权益）
向第三方披露非公开的 RDDS/ WHOIS    控制者（合同的履行[也可能因请求方而异]）    控制者（合同的履行[也可能因请求方而异]）    控制者（合同的履行）
数据保留    无角色    处理者（合同的履行）    控制者（合同的履行）
处理原则

每个控制者将遵守以下原则来管理其对注册数据中包含的个人数据的处理，适用法律或法规要求的除外。个人数据应：

1.1. 仅以与注册名称持有人和其他数据主体相关的合法、公平和透明的方式进行处理（“合法、公平和透明”）；

1.2. 仅出于特定、明确和合法的目的（如本临时规范第 4 节所述）获得，不得以与这些目的不相容的任何方式进一步处理（“目的限制”）；

1.3. 就处理它们的目的而言是充分的、相关的并且不过分（“数据最小化”）；

1.4. 准确并在必要时保持最新，以适合处理它们的目的（“准确性”）；

1.5. 不得以允许识别注册名称持有人和其他数据主体身份的形式保存超过允许目的所需的时间（“存储限制”）；和

1.6. 以确保个人数据适当安全的方式进行处理，包括使用适当的技术或组织措施（“完整性和机密性”）防止未经授权或非法处理以及意外丢失、破坏或损坏。

每个注册商和注册管理运行机构均应负责并能够证明遵守原则 (1.1) 至 (1.6)（“问责制”）。如果注册服务商或注册管理运行机构 (i) 无法遵守本附录第 1 节中概述的处理原则，或 (ii) 收到注册域名持有人或其他数据主体的投诉，注册服务商或注册管理运行机构应立即通知ICANN注册商或注册管理运行机构未能遵守此类原则。

处理的合法性

对于与注册数据目录服务有关的个人数据处理，此类处理将基于控制者或第三方或个人数据披露方的合法利益进行，除非此类利益被需要保护个人数据的数据主体的利益或基本权利和自由，尤其是在数据主体是儿童的情况下。对于为其他目的收集的其他个人数据，除非适用 GDPR 第 6(1) 条规定的法律依据，否则不得处理此类个人数据。

特定控制器处理要求

除了合法处理的一般原则和要求外，每个控制者还应遵守以下具体要求：

3.1. 实施适当的措施。实施适当的技术和组织措施以确保并能够证明处理是按照 GDPR 执行的，例如适当的数据保护政策、批准的行为准则或批准的认证机制。控制器应定期审查并在必要时更新此类措施。双方承认并同意，他们有责任维护适当的组织和安全措施，以根据适用法律保护双方共享的此类个人数据。本附录第 3.8 节进一步列举了适当的组织和安全措施，通常必须包括：

3.1.1. 确保只有为本附录目的而获得授权的个人才能访问个人数据的措施；

3.1.2. 在必要或适当的情况下对个人数据进行假名化和加密；

3.1.3. 确保其处理系统和服务的持续机密性、完整性、可用性和弹性的能力；

3.1.4. 及时恢复个人数据的可用性和访问权限的能力；

3.1.5. 定期测试、评估和评估技术和组织措施有效性的流程，以确保个人数据处理的安全性；和

3.1.6. 识别其系统中个人数据处理漏洞的措施；

3.2. 仅使用选定的处理器。仅聘用选定的处理者并与每个处理者签订合同，其中规定了处理的主题和持续时间、处理的性质和目的、个人数据的类型和数据主体的类别以及控制者的义务和权利. 处理者的参与必须符合 GDPR 第 28 条；

3.3. 指定一名数据保护官。根据 GDPR 第 37 条或成员国国家数据保护法的要求指定“数据保护官”；

3.4. 维护处理记录。根据 GDPR 第 30 条，在控制者的责任下维护处理活动的记录；

3.5. 提供透明的信息。采取适当措施，以简明、透明、易懂且易于访问的形式向数据主体提供 GDPR 第 13 条和第 14 条提及的任何信息以及 GDPR 第 15 至 22 条和第 34 条与处理相关的任何通信，使用清晰明了的语言，其中应具体包括以下义务：

3.5.1. 双方应确保其隐私声明清晰明了，并向数据主体提供足够的信息，以便他们了解双方正在共享哪些个人数据、共享数据的情况、数据共享的目的以及共享数据的身份或将接收个人数据的组织类型的描述；

3.5.2. 双方承诺告知数据主体处理其个人数据的目的，并提供其根据适用法律必须提供的所有信息，以确保数据主体了解他们的个人数据将如何被处理控制器。

3.6. 促进数据主体权利的行使。促进数据主体根据 GDPR 第 15 至 22 条行使权利。在 GDPR 第 11 条第 2 款所述的情况下，控制者不得拒绝数据主体根据 GDPR 第 15 至 22 条行使其权利的请求，除非控制者证明其无法识别数据主体；

3.7. 通过设计和默认实施数据保护措施。在确定处理方式和处理本身时实施适当的技术和组织措施，旨在有效实施数据保护原则，并将必要的保障措施整合到处理中以满足 GDPR 的要求并保护数据主体的权利。实施适当的技术和组织措施，以确保默认情况下仅处理每个特定处理目的所必需的个人数据。

3.8. 实施适当的安全措施。实施适当的技术和组织措施，以确保适合数据处理风险的安全级别，同时考虑到最新技术、实施成本和处理的性质、范围、背景和目的以及风险自然人权利和自由的不同可能性和严重程度。保护共享的个人数据免遭未经授权或非法处理以及意外丢失、破坏、损坏、更改或披露的适当技术和组织措施可能包括但不限于：

3.8.1. 确保 IT 设备（包括便携式设备）在无人看管时存放在可上锁的区域；

3.8.2. 不要让包含个人数据的便携式设备无人看管；

3.8.3. 确保使用适当的安全密码登录包含双方共享的个人数据的系统或数据库；

3.8.4. 确保所有 IT 设备都受到防病毒软件、防火墙、密码和合适的加密设备的保护；

3.8.5. 在必要或适当的情况下使用行业标准的 256 位 AES 加密或适当的等效加密；

3.8.6. 将对相关数据库和系统的访问限制为需要访问个人数据的管理人员、员工、代理、供应商和分包商，并确保定期更改和更新密码，以防止在个人不再访问时进行不当访问由当事人聘用；

3.8.7. 定期对系统进行威胁评估或渗透测试；和

3.8.8. 确保所有处理个人数据的授权个人都了解他们在处理个人数据方面的责任。

3.9. 制定违规通知程序。制定违规通知程序，以确保遵守 GDPR 第 33-34 条规定的义务。与 GDPR 第 33-34 条相关的任何通知也应提供给ICANN。如果一方不是数据控制者，它必须在发现任何数据安全漏洞后立即通报，并将立即反馈此事件可能/将对控制者产生的任何影响以及与控制者共享的任何个人数据。此类通知将尽快提供。

3.10. 国际数据传输的观察条件。遵守国际数据传输的条件，以便任何正在处理或打算在传输到第三国或国际组织后进行处理的个人数据的传输只有在符合 GDPR 第五章规定的条件时才能进行与，包括将个人数据从第三国或国际组织转移到另一个第三国或另一个国际组织。一方只能根据本第 3.10 节的条款将注册数据（包括与欧盟个人相关的个人数据）传输到欧盟以外（或者如果此类个人数据已经在欧盟以外，则转移到也在欧盟之外的任何第三方） ，以及适用法律的要求。

3.11. 与监管机构合作。根据要求与监管机构合作执行其任务。

附录 D：统一快速暂停
本附录包含 2013 年 10 月 17 日针对注册管理机构和注册服务商的URS高级技术要求和2013 年 6 月 28 日生效的URS规则的补充要求。

针对注册管理运行机构和注册服务机构的URS高级技术要求

1.1. 注册管理运行机构要求：在URS提供商通知注册管理运行机构（或指定的 BERO）存在投诉后，注册管理运行机构（或指定的 BERO）必须向URS提供商提供每个指定域名的完整注册数据，或参与其他机制以向ICANN指定的提供商提供完整的注册数据。如果gTLD作为“瘦”注册管理机构运营，注册管理运行机构必须向URS提供商提供可用的注册数据。

1.2. 注册服务商要求：如果投诉涉及的域名位于“瘦”注册管理机构，则注册服务商必须在收到投诉通知后向URS提供商提供完整的注册数据。

URS规则

投诉人的投诉不会因未能提供被投诉人（注册名称持有人）的姓名以及URS规则第 3 节要求的所有其他相关联系信息（如果被投诉人的此类联系信息未在公开可用的注册数据中提供）而被视为有缺陷在 RDDS 中或投诉人不知道的其他情况。在这种情况下，投诉人可以提出“Doe”投诉，审查员应在收到“Doe”投诉后提供注册名称持有人的相关联系方式。

附录 E：统一域名争议解决政策
本附录包含对统一域名争议解决政策规则（“规则”）的补充要求。