Skip to main content
Resources

ICANN 处理注册数据目录服务与隐私法间冲突的规程修订版

注:所有语种版本中,英文版为官方版本,其他语种版本仅供参考.

本政策已于 2024 年 2 月 21 日进行了更新,以反映实施注册数据政策所需的变更。本政策以前称为“ICANN 处理 WHOIS 与隐私法间冲突的规程修订版”。签约方可以自 2024 年 8 月 21 日起开始实施这一更新政策,并且必须在 2025 年 8 月 21 日前实施。

生效日期:2017 年 4 月 18 日

查看 RDDS 冲突处理规程的红线修订版

有关注册数据的更多信息,请访问我们 ICANN 页面上的注册数据

背景介绍

0.1 2003 年 12 月,[1]GNSO 的 WHOIS 第 2 任务组建议制定一个规程,让 gTLD 注册管理机构/注册服务机构可以证明因受到当地法律的影响,他们无法完全遵守 ICANN 合同中有关 WHOIS 个人信息的条款。

0.2 2005 年 11 月[2],GNSO 执行了政策制定流程来建立这一规程。该流程采纳了由 WHOIS 任务组提出并经 GNSO 理事会批准的“关于规程的成熟建议”。[3]2006 年 5 月,ICANN 董事会[4]通过了该政策,并指示 ICANN 员工制定和公开起草冲突处理规程。

0.3 2006 年 12 月 3 日,ICANN 员工发布了《ICANN 处理 WHOIS 与隐私法间冲突的规程草案》[插入脚注,https://gnso.icann.org/issues/whois-privacy/whois_national_laws_procedure.htm]。ICANN 就规程草案向政府咨询委员会 (Governmental Advisory Committee, GAC) 征询了意见。修订后的文本请参见下文的第 1.4 节。

0.4 2015 年 10 月 5 日,WHOIS 与国家法律间冲突处理规程的实施建议小组1发布了其报告,报告概述了此规程中可以改进的方面。2015 年 10 月 5 日至 11 月 17 日,针对建议小组的报告征询了公众意见。最终报告已经提交给 GNSO 理事会,以供理事会在 2016 年 5 月的会议上进行审议。

0.5 下文所述的规程详细说明了如果注册服务机构/注册管理机构[5]指明当地/国家隐私法律法规禁止他们按照 ICANN 合同的要求通过注册数据目录服务 (Registration Data Directory Service, RDDS) 收集、公布和传播个人数据,ICANN 应如何做出回应。该规程供 ICANN 员工使用。尽管该规程包含了可能对受影响的 gTLD 注册管理机构/注册服务机构采取的行动,但并未对注册管理机构/注册服务机构或第三方强加任何新义务。该规程旨在告知注册管理机构/注册服务机构和其他相关方,当向 ICANN 报告其他法律义务和与 RDDS 有关的 ICANN 合同要求发生冲突时,他们将需要采取哪些步骤。

第一步:

  1. RDDS 诉讼程序通知

    1.1 若注册管理机构/注册服务机构收到了调查通知、诉讼通知、监管诉讼程序通知或其他政府行动或民事诉讼,可能影响其遵循《注册服务机构认证协议》(Registrar Accreditation Agreement, RAA) 或与 ICANN 签订的有关处理通过注册数据目录服务收集、公布或传播个人身份数据的其他协议(“RDDS 诉讼程序”),该注册管理机构/注册服务机构应向 ICANN 员工提供以下信息:

    • 总结该行为的本质和状态(例如:审查、调查、诉讼、发出制裁威胁等)以及一系列可能出现的结果。
    • 联系注册服务机构/注册管理机构的相关负责人来解决问题。
    • 如适用,负责该地区的政府机关、其他原告的联系信息,以及由注册服务机构/注册管理机构向 ICANN 出具的授权 ICANN 与这一事宜相关的负责人或原告进行沟通的声明书。若注册服务机构/注册管理机构受到适用法律的约束,无法发出授权书,则应在通知中列明该内容。
    • 当地政府或其他原告在其诉讼或调查中引用的适用法律或规章的文本(如果该政府或其他原告谈及该信息的情况下)。
    • 关于为了同时遵守当地法律和履行 ICANN 义务所做努力的说明。

    1.2 满足通知中的要求使得注册服务机构/注册管理机构能够参与到调查中来,并能使得其代表律师能够以最佳的方式和程序对庭谕、规章或执法机构做出回应。

    1.3 根据 RDDS 诉讼程序的具体情况,注册服务机构/注册管理机构可以请求 ICANN 在 RDDS 诉讼程序结果尚未公布以前对各方之间的沟通信函予以保密。在不影响其他法律责任和 ICANN 运营透明度原则的情况下,ICANN 一般会批准这类请求。

    1.4 RDDS 诉讼程序所涉及的注册服务机构或注册管理机构应积极配合相关国家政府机关,确保注册服务机构或注册管理机构的运营符合国内法律法规、国际法和适用国际惯例。

  2. 导致启动冲突处理规程的其他情况:政府机构发出的书面声明

    1.5 如果未发生 RDDS 诉讼程序,注册管理机构或注册服务机构也可以向 ICANN 提交政府机构发出的书面声明:

    • (a) 说明声明发出前存在的情况,即:
      • (i) 所涉及的具体签约方(注册服务机构或注册管理机构)
      • (ii) 政府机构已审查的服务/注册协议的适用条款
      • (iii) 所涉及的 ICANN 合同的适用条款
      • (iv) 政府机构已分析的适用法律
    • (b) 指出并分析政府机构发现的国家法律与合同义务之间的冲突,引用各自的具体条款;以及
    • (c) 证明该机构具有执行与合同义务不符的国家法律的法定权力,并且拥有对签约方执行此国家法律的管辖权。

第二步:协商

2.1 协商流程的目的是在尽可能允许注册服务机构/注册管理机构最大限度地遵守其 RDDS 合同义务的情况下解决问题。

2.1.1 除非情况不允许,否则 ICANN 应在接到和阅读通知后,立即与注册服务机构/注册管理机构进行协商。在适当情况下,ICANN 应与当地/国家执法机构或其他原告及注册服务机构/注册管理机构进行协商。

2.1.2 根据 ICANN 政府咨询委员会提出的建议,针对禁止执行 ICANN RDDS 要求的通知,ICANN 将就该通知的权威性向相关国家政府机构征询意见。

2.2 按照 ICANN 的观点来看,若 RDDS 诉讼程序结束时确定无需对注册服务机构/注册管理机构的实践做出任何更改,或必须做出的更改并不构成对《注册服务机构认证协议》(RAA) 或其他合同义务的偏离,则 ICANN 和注册服务机构/注册管理机构无需采取后续行动。

2.3 若本地执法机构或��院要求注册服务机构/注册管理机构在尚未进行任何协商的情况下对其实践做出更改,且此更改导致无法遵守 RDDS 相关的合同义务,注册服务机构/注册管理机构应及时通知 ICANN 已经做出的更改及其所依据的法律/法规。

2.4 注册服务机构/注册管理机构可以要求 ICANN 在 RDDS 诉讼程序尚未结束之前对各方之间的沟通信函予以保密。在不影响其他法律责任和 ICANN 运营透明度原则的情况下,ICANN 一般会批准这类请求。

2.5 对于“导致启动冲突处理规程的其他情况”部分所述的情况,协商步骤包括公共协商,其中所有利益相关方均可在通知步骤中阅读提交的书面声明并对其所有方面发表评论。在这些情况下,根据规程第 2.1.2 节的规定,ICANN 还应与相关国家的 GAC 代表(如果有)进行协商。

第三步:总法律顾问的分析和建议

3.1 若 ICANN 总法律顾问办公室认为 RDDS 诉讼程序要求做出的更改(不论是在上述协商流程之前、期间或之后)不符合 RDDS 的合同义务,则 ICANN 员工可以根据条款要求,在可能导致注册服务机构/注册管理机构不合规的情况下选择不执行该裁定结果,而 ICANN 应起草一份公开报告并提出建议,然后将其提交给 ICANN 董事会,由董事会做决定。在公开发布报告前,注册管理机构/注册服务机构可以要求从报告中删除某些信息(包括但不限于:注册管理机构/注册服务机构与 ICANN 之间的沟通信息或其他机密/保密信息)。对于与提供给 ICANN 的法律建议或 ICANN 顾问提供的建议有关的任何已发布报告版本,如果总法律顾问认为其中有任何建议或信息由于权限问题或者可能会对 ICANN 不利而应该加以限制,则总法律顾问可从报告中删除该建议或信息。该报告内容可包括:

  1. 冲突事件中涉及的法律或规章的小结;
  2. 注册管理机构或注册服务机构 RDDS 合同义务中未完全履行的规定的详情;
  3. 第二步中对协商流程的小结,若有;以及
  4. 有关应如何解决该问题的建议,包括:ICANN 是否应根据一项或多项确定的 RDDS 合同条款的具体冲突情况,对这些注册服务机构/注册管理机构进行例外处理。该报告还应给出提出这些建议的详细理由,包括:一旦建议得到批准或拒绝,可能给互联网唯一标识符系统的运行稳定性、可靠性、安全性或全球互用性带来的影响。

3.2 注册服务机构/注册管理机构将获得向董事会提出看法的合理机会。注册服务机构/注册管理机构可以要求 ICANN 在董事会做出任何决议之前对此报告保密。在不影响其他法律责任和 ICANN 运营透明度原则的情况下,ICANN 一般会批准这类请求。

3.3 在其他情况适用的情况下,依据规程第 2.1.2 节,董事会将考虑收到的有关在通知步骤中提交的书面声明的任何公众意见以及 GAC 代表(如果有)从相关国家收到的任何意见。

第四步:决议

4.1 考虑到任何行动对互联网唯一标识符系统的运行稳定性、可靠性、安全性或全球互用性所带来的影响,董事会将根据总法律顾问报告中提出的可行建议采取适当的措施。这些措施可包括但不仅限于以下内容:

  • 批准或拒绝报告中已修订或未修订的建议内容;
  • 向受到影响的注册服务机构/注册管理机构或第三方索取额外信息;
  • 安排报告的公共评议期;或者
  • 将报告转交给 GNSO 以供其在规定时间内进行审核或评议。

第五步:公共通知

5.1 董事会对这个问题做出的决议,以及总法律顾问的报告(以及任何相关材料)将定期发布在 ICANN 的网站上并进行存档,以供将来研究所用。将这些信息公开发布之前,注册管理机构/注册服务机构可以请求从公开通知中删除某些信息(包括但不限于:注册管理机构/注册服务机构与 ICANN 之间的沟通信息或其他机密/保密信息)。对于与提供给 ICANN 的法律建议或 ICANN 顾问提供的建议有关的任何已发布报告版本,如果总法律顾问认为其中有任何建议或信息由于权限问题或者可能会对 ICANN 不利而应该加以限制,则总法律顾问可从报告中删除该建议或信息。在实际情况允许的条件下,当因删除信息而导致公众难以理解注册管理机构/注册服务机构所采取行动的本质时,ICANN 应向公众提供适当的公告,解释采取的措施及其司法依据。

5.2 除非董事会另有决定,否则如果问题的解决结果是从注册管理机构/注册服务机构的 RDDS 输出数据中删除某些数据元素或者限制对这些数据元素的访问,则 ICANN 应向公众发布适当的公告,说明该决议以及 ICANN 无法充分履行相关合同条款的原因。

第六步:坚持持续审核

6.1 ICANN 会考虑相关注册管理机构或注册服务机构提出的实质性建议,同时与所有选区一道对该流程的有效性进行年度审核。


[1] WHOIS 第 2 任务组的预备报告(2004 年 6 月);https://gnso.icann.org/issues/whois-privacy/Whois-tf2-preliminary

[2] GNSO 理事会会议记录(2005 年 11 月 28 日);https://gnso.icann.org/meetings/minutes-gnso-28nov05

[3] GNSO WHOIS 任务组的最终报告(2005 年 10 月 25 日);https://gnso.icann.org/issues/tf-final-rpt-25oct05.htm

[4] 董事会会议记录(2006 年 5 月 10 日);https://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."