Skip to main content
Resources

面向非律师人员的 2009 年 5 月注册服务商委任协议指南*

本页面还提供其他语种:

面向非律师人员的 2009 年 5 月注册服务商委任协议指南 [PDF, 240 KB]

概述
RAA
总结
术语表

本文档应网络普通用户咨询委员会 (ALAC) 关于提供面向非律师人员的 ICANN 注册服务商委托协议 (RAA) 指南的要求而制作,具体请访问 http://www.atlarge.icann.org/correspondence/correspondence-01oct09-en.htm. 正如要求中所述, RAA 是 ICANN 和 注册服务商之间签署的法律文档,依据加州法律起草。因此 , 与本协议无关的各方、不熟悉美国法律制度的人员、非律师人员和 / 或母语为非英语的人员可能很难理解 ICANN 和注册服务商所达成的义务协议。 本指南不以任何方式对 RAA 进行改变或修正 , 也不是对 RAA 的法律解释。

本指南提供了 2009 年 5 月版 RAA 的基本概要 ( 请访问 http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm ) 。某些注册服务商仍然根据 2001 年 5 月版 RAA 运作 ( 请访问 http://www.icann.org/registrars/ra-agreement-17may01.htm ), 因此本文讨论的部分条款当前并不适用于所有注册服务商。通过查阅委任的注册服务商清单 , 您可以了解哪些注册服务商目前遵循 2009 年 RAA ( 请访问 http://www.icann.org/en/registrars/accredited-list.html ) 。 “ RAA ” 列定义了适用于每个注册服务商的 RAA 。

为了帮助您更好地阅读本指南,文档末尾附有一个简短的术语表。


1. 概述

RAA 是域名注册服务流程中的一部分。简言之 , ICANN 与注册管理执行机构 ( 即运营 gTLD 的公司 ) 签订合同。如果客户想在 gTLD 内注册一个域名 , 必须通过一个 ICANN 委任的注册服务商 ( 与 ICANN 签订 RAA 的公司 ) 注册。客户在注册域名时向注册服务商提供相关信息,例如账单、联系信息以及运行该域名的域名服务器的信息。然后,注册服务商将这些信息传给注册管理执行机构,这样就能通过域名系统解析这一域名了。每个域名注册都有时间限制。注册服务商提供的最短注册期为一年,最长注册期为十年。到期后,注册域名持有者可以续延注册。如果注册域名持有者不同意续延注册,通常会失去对该域名的所有权,而该域名可由其他客户注册。 当注册期到期但未获续延时,域名最终可能被注册服务商删除,因而不再能解析。

注册服务商要获得 ICANN 的委任 , 必须提出委任申请 , 具体流程请访问 http://www.icann.org/en/registrars/accreditation.htm. 。简言之,申请委任的公司必须向 ICANN 提供商业、技术和财务方面的信息。申请者还必须提供公司高管、董事以及经理的相关信息。 如果申请成功,注册服务商还必须签署 ICANN 的标准 RAA ,以完成整个委任过程。

对于 ICANN 委任的每个注册服务商,如果要提供 gTLD 的注册功能,必须与 ICANN 签署标准 RAA 。 RAA 由多个部分组成: (1) 主体协议; (2) 注册服务商被委任可以运营的每个 TLD 的附录;以及 (3) ICANN 徽标许可附录,允许获得委任的注册服务商在其网站上使用专门的“ ICANN 委任的注册服务商”徽标。尽管每个注册服务商都必须签署主体协议和徽标许可附录,但是注册服务商可以自主选择是否签署所提供的所有 TLD 附录。例如,注册服务商可以选择仅提供某些 TLD 的注册,如.COM 、.NET 和.INFO ,而不提供其他 TLD 的注册。这种情况下,注册服务商只需选择签署有关.COM 、.NET 和.INFO 的 TLD 附录,但可在以后选择增加其他 TLD 。访问 http://www.icann.org/en/registrars/accredited-list.html 的列表,可以查阅每个获得委任的注册服务商可以提供哪些 TLD 注册服务。本指南中的“相关 TLD ”一词是指注册服务商获得委任可以提供的 TLD 注册服务。 注册服务商通常会与它委任范围内的每一家注册管理执行机构单独签订一份协议,该协议可能包括额外的注册服务商义务。

注册服务商不得声称能够为注册域名持有者提供高于其他注册服务商的对任何相关 TLD 的访问权限。

某些 ICANN 委任的注册服务商可以为国家或地区代码顶级域名 (ccTLD) , 如.DE 、.UK 和.ME , 提供注册服务。 ICANN 并没有 委任注册服务商提供 ccTLD 服务 , 因 此 RAA 的要求 并不适用于这些 ccTLD 注册。 委任 ccTLD 注册服务商是 ccTLD 注册管理执行机构的选择 , 不要求其必须 为 ccTLD 委任注册服务商 ; 但如果选择委任 , ccTLD 可以设置自己的委任标准和义务。

RAA 是双向的。也就是说 , ICANN 和注册服务商在协议中互相做出承诺 , 而 ICANN 和注册服务商各自都可能违反协议。 无论 ICANN 还是注册服务商都应为未能履行各自的义务而承担责任。

因为 RAA 是 ICANN 和注册服务商之间签订的协议 , 其他任何人 , 包括注册域名持有者 , 都不能起诉 ICANN 或注册服务商违反 RAA 。


2. RAA

主体协议分为五个部分:

  1. 定义
  2. ICANN 的义务
  3. 注册服务商的义务
  4. 制定或修订规范和政策的程序
  5. 其他条款

虽然本指南通常遵循 RAA 中所列的各部分顺序 , 但是某些条款是互相关联的。 因此,本指南按主题进行讨论,并不一定按条款顺序逐一进行讨论。

2.1 定义

“ 定义 ” 部分说明了 RAA 中使用的某些术语。 此部分没有重新描述所有定义 , 某些关键术语在本指南末尾的术语表中定义。

2.2 ICANN 的义务

简言之 , ICANN 的义务包括给予委任 , 以及向注册服务商授予许可 , 允许其声明自己是获 ICANN 委任的。注册服务商可以在协议有效期内请求获得其他 TLD 的委任。 ICANN 还有责任以公开透明的方式行事 , 在各注册服务商之间公平地应用标准 , 不限制竞争 , 并且确保注册服务商在 ICANN 内有充分的申诉程序。

2.3 注册服务商的义务

由于 RAA 的 “ 注册服务商的义务 ” 部分包含了注册服务商的注册域名持有者相关义务的众多具体规定 , 因此与本指南的其他部分相比 , 此部分中提供的详细信息更多。

注册服务商承担一些基本义务 , 例如注册服务商必须遵守 ICANN 政策和共识政策并且依法运营。 RAA 还特别要求注册服务商遵守 统一域名争议解决政策 ( 通常称为 UDRP ) 。

注册服务商还必须就某些具体事项通知注册域名持有者,包括注册期结束的通知、注册域名持有者个人资料的使用,以及某些情况下有关托管通过私人或代理注册服务注册的域名数据的通知,如下所述。 注册服务商还必须公布恢复注册域名所收的费用。

2.3.1 注册服务商向注册管理执行机构提交 数据

对于每个相关 TLD , 注册服务商必须提交与 TLD 内的每个注册域名相关的 某些数据要素

3.2.1.1 正在注册的注册域名的名称 ;

3.2.1.2 注册域名的主要域名服务器和辅助域名服务器的互联网协议 (IP) 地址 ;

3.2.1.3 这些域名服务器的相应名称 ;

3.2.1.4 除非注册管理机构系统自动生成 , 否则还要提供 “ 注册服务商 ” 的身份信息 ;

3.2.1.5 除非注册管理机构系统自动生成 , 否则还要提供注册失效日期 ;

3.2.1.6 注册管理执行机构要求提交的任何其他数据。

注册域名持有者通常只需要向注册服务商提供与域名服务器相关的资料 ( 3.2.1.2 – 3) , 但可能还必须根据 3.2.1.6 条款的要求提供其他数据。 如果注册域名持有者提供了对这些数据要素的更新 , 注册服务商应在五 (5) 天内将更新提供给注册管理执行机构。

如果出现技术故障或注册管理执行机构发生变更 , 在 ICANN 的要求下 , 注册服务商还必须向 ICANN 提供包含 TLD 中所有现行注册的全部数据要素的电子数据库。

2.3.2 Whois 数据

RAA 中没有讨论 Whois 服务的背景。为供参考 , 注册服务商必须提供有关注册服务商委任范围内的每个域名注册的具体联系信息和技术信息。这些信息 , 即 Whois 数据 , 必须采用特定的格式必须向公众提供 , 并且通过一个为共享 Whois 数据保留的指定 “ 端口 ”( 端口号为 43 ) 提供 , 并在一个互动网页上提供。 Whois 服务可以用作多种用途 , 例如决定某个域名是否可以注册 , 识别与恶意活动相关的域名的注册人 , 就商标保护问题与域名注册人联系 , 以及核实网上商家等等。

注册服务商必须向公众提供一个互动网页和使用端口 43 的 Whois 服务 , 从而实现免费查询。 RAA 定义了某些数据要素 , 这些数据必须可供查询 :

3.3.1.1 注册域名 ;

3.3.1.2 注册域名的主要域名服务器和辅助域名服务器的名称 ;

3.3.1.3 “ 注册服务商 ” 的身份信息 ( 可通过注册服务商网站提供 );

3.3.1.4 注册的初始创建日期 ;

3.3.1.5 注册失效日期 ;

3.3.1.6 注册域名持有者的名称和邮政地址 ;

3.3.1.7 注册域名技术联系人的姓名、邮政地址、电子邮件地址、语音电话号码和传真号码 ( 如有 );

3.3.1.8 注册域名管理联系人的姓名、邮政地址、电子邮件地址、语音电话号码和传真号码 ( 如有 ) 。

这些数据要素通常称为 Whois 数据。如下所述 , 注册域名持有者必须向注册服务商及时提供注册域名 Whois 数据的更新。收到更新后 , 注册服务商应立即更新 Whois 数据。 注册服务商可将公共查询功能的维护外包给第三方。

RAA 要求注册服务商向第三方提供对 Whois 数据的批量访问。 通过公共查询功能提供对 Whois 数据的批量访问或访问时 , 注册服务商必须限制使用大量查询 , 并且遵循 RAA 中规定的其他 Whois 数据使用限制 , 包括营销活动和大量索取。

2.3.3 与注册域名持有者的通信往来

注册服务商必须保留与注册域名持有者的所有通信记录,同时还应保留提供给注册管理执行机构的信息记录。

2.3.4 注册域名持有者数据托管

注册服务商必须维护包含通过注册服务商委任注册的所有域名的全部 Whois 数据的数据库 , 同时还应维护注册服务商提交给注册管理执行机构的所有数据。 此外,注册服务商必须在数据库中提供每个注册域名付款联系人的姓名、邮政地址(如有)、电子邮件地址、语音电话号码和传真号码。

注册服务商必须对完整的数据库实施托管(或托由第三方保管),称为“数据托管”。数据库可以停止托管 , 以在必要时协助注册服务商、 ICANN 或代理人提供注册服务商服务。 ICANN 、注册服务商和数据托管公司之间额外签订一份合同 , 以具体规定数据托管流程的条款 , 可访问 http://www.icann.org/en/rde/registrar-data-escrow-agreement-09nov07.pdf [PDF, 45 KB] 参考该合同范本。

背景方面 , 在某些情况下 , 希望使用域名的客户可能想要限制注册服务商在 Whois 查询中提供的个人信息量。为此,可以通过私人服务(允许注册域名持有者用私人服务的信息取代一些个人身份识别信息,例如使用私人服务的信箱取代注册域名持有者的家庭或办公地址)或代理服务(用于注册域名和许可客户使用域名的服务)来注册域名。 使用代理服务时,代理服务是注册域名持有者,因此代理服务信息可作为大多数或全部的所需数据要素。 1 尽管事实上 RAA 包含了与使用私人或代理服务相关的条款, 但 ICANN 从未就私人或代理服务表示过赞成或反对意见。

通过私人或代理注册服务注册域名时,会影响数据库中的信息,因此 RAA 要 求提供私人或代理服务的注册服务商必须完成以下两项工作之一:注册服务商必须 (1) 在数据库中包含客户名称和邮政地址、电子邮件地址、语音电话号码以及代理或私人注册服务的信息;或者 (2) 在客户选择私人或代理注册服务时,显示客户数据没有被托管的通知。客户数据没被托管时,仅会托管与私人或代理注册服务相关的联系信息。 如果客户数据未被托管而数据库中仅包含私人或代理服务的信息,则在注册服务商或注册机构破产时,之后的通知可能只能根据私人或代理服务的联系信息递送,而不会发送给客户。

ICANN 有权访问或审查注册服务商必须维护的数据。 然而,在未获 ICANN 规范或政策许可的情况下, ICANN 不得披露数据内容。

2.3.5 注册服务商与注册域名持有者的业务交易

RAA 对注册服务商的业务交易施加了很多要求 , 包括与注册域名持有者之间的交易。

RAA 3.7.4 条款要求注册服务商在未获得将支付注册费的合理保证的情况下 , 不得激活注册域名。

RAA 中规定了注册期结束时 , 如果注册域名持有者没有表示同意续延注册 , 注册服务商可以采取的行动 , 包括注册服务商在当前注册期结束时删除该注册。 如果注册域名持有者 ( 或其代表 ) 不同意续延 , 注册服务商必须确保在注册期结束后的 45 天内 , 将注册域名从注册管理机构数据库中删除。

这种删除域名的规定不是绝对的。 RAA 的 3.7.5.1 条款中给出了可能出现的特殊情况摂列表,即当出现这些情况时,即使未获注册域名持有者的同意,也允许注册服务商续延域名。这些情况包括注册域名受 到 UDRP (统一域名争议解决政策)2 起诉、法庭指令,进入破产程序或存在付款争议,等等。如果注册服务商决定在未获注册域名持有者同意的情况下续延域名,则必须保留一份相关的原因记录。 注册服务商还能够在其与注册域名持有者之间签署的协议中,加入修改注册服务商删除规定的附加条款。

注册服务商必须向每个新的注册域名持有者通报注册服务商的删除和自动续延政策。如果在注册协议期内注册服务商的删除政策发生改变,注册服务商必须尽力将这些政策变化通报给注册域名持有者。 注册服务商必须在其运营的用于域名注册和续延的所有网站上公布删除和自动续延政策的详细内容,还必须在这些网站上说明在恢复宽限期(注册管理机构将域名设置为“待删除”状态的 30 天)内恢复域名所需的所有费用。3

如果某个注册域名在注册删除或失效时牵 涉到 UDRP 争议 ,则 UDRP 投 诉人有权续延(或恢复,在删除情况下)该域名。 如果投诉人延续或恢复域名 , 则注册服务商必须将该域名置于 “ 保持 ” 或 “ 锁定 ” 状态 , 4 并且必须更改 Whois 信息以显示该域名处于争议状态。 RAA 3.7.5.7 条款也规定了在 UDRP 投 诉终止但无结果,或 UDRP 投诉的结果为支持原注册域名持有者的情况下,原注册域名持有者恢复或续延域名的权利。

2.3.5.1 注册服务商 / 注册域名持有者协议

注册服务商必须与所有注册域名持有者签订电子或书面注册协议。 根据 RAA , 注册服务商 / 注册域名持有者协议必须至少包含以下条款 ( 如 RAA 3.7.7.1 – 12 条所述 ):

  • 注册域名持有者必须提供“准确可靠的详细联系信息”,并必须在注册期内“及时地更正和更新这些信息”。 3.7.7.1 条款中描述了所需的详细信息 : “ 注册域名持有者的全名、邮政地址、电子邮件地址、语音电话号码以及传真号码 ( 如有 ); 如果注册域名持有者是一个组织、协会或公司 , 则需提供授权联系人的姓名 ; 还须提供第 3.3.1.2 、 3.3.1.7 和 3.3.1.8 条款规定的数据要素。 ”
  • 如果注册域名持有者故意提供不准确或不可靠的信息、故意不及时更新该信息或者没有在十五 (15) 日内对注册服务商就联系信息准确性进行的问询作出回应 , 则严重违反了协议 , 此时可以删除注册。
  • 任何所列的注册域名持有者都是记录在册的注册域名持有者,必须提供完整的联系信息。有时,注册域名持有者可能会注册域名,然后授权其他人使用该域名(例如网站设计人员为客户注册域名)。如果出现这种情况 , 真正使用域名的人并没有签署注册服务商 / 注册域名持有者协议 ( 在 RAA 中被称为 “ 第三方 ”), 注册域名持有者可能须对第三方的使用域名不当负责。如果注册域名持有者收到第三方域名使用的“可控诉损害的合理证据”,则会发生这种情况。 在这种情况下,注册域名持有者将“对因注册域名使用不当造成的损害承担责任”,除非注册域名持有者及时披露最终用户提供的用户身份和最新联系信息。
  • 注册服务商必须就如何使用注册域名持有者提供的数据以及谁将收到注册域名持有者的数据发布通知。注册服务商还必须就注册域名持有者可以如何访问和更新数据发布通知。此外,注册服务商必须确认在注册域名持有者向其提供的数据中,哪些是必须的,哪些是自愿的。 注册域名持有者必须同意所有这些数据处理条款。
  • 如果注册域名持有者代表没有签署注册服务商 / 注册域名持有者协议的个人 ( 上文所述的 “ 第三方 ”) 向注册服务商提供了其个人资料 , 则注册域名持有者必须确认 (1) 已向第三方个人提供了注册服务商发出的数据处理通知 , 以及 (2) 就注册服务商数据处理条款征得了第三方的同意。
  • 注册服务商只能按上述数据处理通知中的说明处理注册域名持有者的数据。
  • 注册服务商必须同意采取合理的预防措施,防止注册域名持有者的资料“丢失、被滥用、受到未经授权的访问或者被泄露、更改或破坏。 ”
  • 注册域名持有者必须表明:“就其所知,无论注册域名的注册还是其直接或间接的使用方式均未侵犯任何第三方的合法权利。”也就是说,注册域名持有者必须向注册服务商声明,域名的注册使用不会侵犯他人的合法权利。 例如,侵犯非注册域名持有者所持有的商标的域名注册就属于此类“侵犯”。 5
  • 如果因使用注册域名引发了争议 , 注册域名持有者必须同意注册服务商所在地 ( 通常在网站或注册服务商 / 注册域名持有者协议中注明 ) 的法院和注册域名持有者驻地的法院都有管辖权。“驻地”一词有特定的法律意义,但是通常是注册域名持有者在必需的个人资料中向注册服务商提供的地点。 同意管辖权意味着注册域名持有者同意这两个地点中的法院都有权处理这类案件。 6
  • 注册域名持有者必须同意基于 3.7.7.11 条款中所述理由,其注册可能被“暂停、删除或转让”。这些理由包括:如果 ICANN 通过的规范或政策或者注册服务商或注册管理机构程序要求注册域名持有者“纠正注册服务商或注册管理执行机构在域名注册时或解决与注册域名有关的争议时发生的错误。” 例如, UDRP 是一项 ICANN 通过的政策,该政策规定对域名争议进行听证的官方小组可以命令域名注册暂停、转让或删除,而注册域名持有者必须同意这一可能性。
  • 注册域名持有者应“确保注册管理执行机构及其董事、高管、员工和代理免于承担因注册域名持有者的域名注册导致或与之相关的任何索赔、损失、责任、成本以及开销(包括合理的法律费用)”。简言之,如果注册域名的注册管理执行机构(或其员工等)因注册域名持有者的域名注册被起诉,则注册域名持有者应向注册管理执行机构支付用于诉讼辩护的所有费用和开销,并且承担所有的判决费用或法定债务。 这种“补偿”不仅限于诉讼案件。

    2.3.5.2 联系信息的确认

下文详细说明了可能制定的适用于注册服务商的规范和政策。某些规范或政策针对注册服务商在首次注册域名时确认注册域名持有者提供的联系信息做出了规定,同时制定定期重新确认联系信息的相关要求。 只要这类规范和政策是商业可行的,注册服务商都必须遵守。

当有人向注册服务商报告某个注册域名的联系信息不准确时,注册服务商还必须采取“合理措施”确认联系信息。 即使没有任何人举报 , 而仅由注册服务商发现了联系信息不准确 , 注册服务商也有责任采取更正措施。

注册服务商还必须维护自己的正确联系信息,包括有效地电子邮件地址和邮政地址。 此联系信息必须公布在注册服务商的网站上。

2.3.5.3 注册服务费

RAA 没有对注册服务商可以向注册域名持有者收取的注册服务费进行限制。

2.3.6 注册服务商向 ICANN 缴付的费用

RAA 规定注册服务商须向 ICANN 缴付年费以及不定额费用。 RAA 规定了缴费条款。

2.3.7 注册服务商对他人行为的义务

2.3.7.1 共同控股权益

当机构提出委任申请时 , 必须向 ICANN 提供有关相关注册服务商的所有权和管理的资料。这种情况多见于拥有共同控股权益(例如母公司相同或所有者相同)的多个公司申请单独的委任。这些注册服务商是签署了各自 RAA 的独立法人实体 , 但是由于附属公司之间具有密切关系 , 2009 年 5 月版 RAA 增补了一些针对附属注册服务商的额外义务要求。 并非所有的注册服务商都有附属注册服务商。

RAA 规定了 , 与其附属注册服务商共享控股权益的注册服务商 , 由于其中两个或更多个附属注册服务商的行为而违反 RAA 的情况。

2.3.7.2 分销商的安排

2009 年 RAA 还规定了与分销商 ( 注册服务商为了带来客户以及在某些情况下提供某些注册服务商服务而签订合约的个人或实体 ) 协作的注册服务商的新义务。 2009 年 RAA 要求注册服务商在注册服务商 / 分销商协议中引入某些具体条款 , 包括 : 禁止分销商声明自己由 ICANN 委任 ; 要求所有分销商的注册协议中必需包含注册服务商在注册服务商 / 注册域名持有者协议中必须包含的所有条款 ; 要求必须发布注册服务商有义务发布的所有 ICANN 网站的链接 ; 以及标识赞助注册服务商。分销商还必须确保如果客户使用分销商的私人或代理注册服务注册域名 , 应完成以下三项工作之一 : (1) 将客户身份和联系信息交由注册服务商保管 (2) 将身份和联系信息进行托管 , 或 (3) 通知客户其联系信息不受托管。

RAA 还要求注册服务商在分销商违反任何规定条款时采取合法和执行行动。

2.3.8 注册服务商与 ICANN 的合作

作为注册服务商的义务,注册服务商现在必须完成培训课程。该培训课程是参考注册服务商的意见制定并且由 ICANN 提供。根据合理的通知( RAA 中规定),注册服务商还应与 ICANN 合规审计部门合作,及时向 ICANN 提供信息,允许 ICANN 进行所要求的现场参观,并且允许独立第三方对注册服务商帐簿记录进行会计核查审计。 。 此外,如果 ICANN 通过参考注册服务商的意见,制定了确认注册域名持有者的权利和责任的内容,注册服务商必须发布包含该内容的网页链接。

2.4 制定或修订规范和政策的程序

如上所述 , 注册服务商必须遵守 ICANN 规范和政策 , 包括 RAA 有效期内制定或修订的规范和政策。 RAA 规定了日后可能制定和修订的规范和政策的主题 , 其中包括与 DNS 的互用性和稳定性、域名争议解决、注册域名分配以及禁止注册服务商囤积注册域名相关的条款。这些都是特定的主题 , 很难概括或压缩 ; 但重要的是 , 注册服务商在很多领域都有遵守在 RAA 有效期内新制定及修订的规范和政策的长期义务 , 即使这些规范和政策的条款并未明确写入 RAA 。 通知发出之后 , ICANN 必须为注册服务商提供合理的时间 , 使其可以遵守新制定的规范或政策。

其中某些规范和政策被称为 “ 共识性政策 ”, 这些规范和政策是 “ 根据 ICANN 流程涉及的互联网利益主体之间达成的共识 ” 制定的。正如注册服务商必须遵守其他 ICANN 规范和政策一样 , 注册服务商也必须遵守这些共识性政策。但是可能会出现这样的情况,即注册服务商不相信该政策的制定达成了“共识”,并由此认为自己不需要遵守共识性政策。因此, RAA 为注册服务商规定了以下程序:讨论是否达成了共识,并由此确定注册服务商是否必须遵守有争议的规范或政策。 RAA 中的 4.3 和 4.4 条款包含了大量与共识性政策的制定以及争议流程的时间安排相关的具体信息。7

2.5 其他条款

RAA 中的第 5 条规定了多个条款,主要涉及依据 RAA 解决争议、 RAA 的终止以及 ICANN 或注册服务商可能依据 RAA 提出的诉讼或仲裁而寻求的救济类型。 以下是 第 5 条中一些值得注意的部分:

2.5.1 终止

RAA 有五 (5) 年有效期,如果注册服务商在五年期结束时要求续延其 RAA , ICANN 将允许续延,但前提是注册服务商遵守 RAA 规定的义务。正如 2009 年所发生的,可能会再次修订 RAA 。如果出现这种情况,注册服务商可以要求(但不是必须)签订新的 RAA ,即使注册服务商的当前协议尚未结束。 如果在五年期届满时注册服务商想要续延 RAA ,则必须签署当时最新版本的 RAA 。

在 RAA 到期之前,注册服务商可通过提前三十 (30) 天以书面形式通知,随时 ICANN 终止协议。8 ICANN 只能在 5.3 条款中规定的具体情况下终止 RAA ,这些情况包括注册服务商:在其委任申请中存在严重失实陈述;面临与欺诈或类似犯罪行为相关的定罪或法律判决;因滥用他人资金被政府处罚;以及未纠正在 ICANN 发出的违规通知内指出的 RAA 违反行为。如果注册服务商破产或无力偿债,或者注册服务商从事 ICANN 认定为威胁互联网运行稳定性的行为, ICANN 也可以终止注册服务商的委任。除了破产外,在所有其他情况下, ICANN 必须提前十五 (15) 天发出终止通知。 对于涉及互联网稳定性的情况, ICANN 可以使 RAA 最长暂停五 (5) 天,同时向法院寻求紧急救济。

如果注册服务商收到了终止通知,可以通过申请仲裁对对终止提出质疑。9 注册服务商还可以要求仲裁员暂缓执行终止,也就是说,允许注册服务商继续作为委任的注册服务商运营,直到做出最终裁决。只有当注册服务商表明其继续运作不会对消费者或公众利益造成损害,或者仲裁员任命一个独立的管理者(与 ICANN 或注册服务商无关联)管理注册服务商的运作直到其做出裁决时,仲裁员才能发出暂缓终止的命令并允许注册服务商继续运营其业务。与以前的 RAA 版本不同, ICANN 可以在仲裁完成之前要求仲裁员“取消”延缓终止的命令并终止注册服务商的运营。 RAA 就如何以及在何处进行仲裁规定了额外要求。此外, RAA 规定 ICANN 或注册服务商均可以就与 RAA 有关的争议向法院提起诉讼。 RAA 限制了仲裁庭或法官在诉讼或仲裁中向任意一方征收的货币金额。

ICANN 可以对注册服务商采取其他合规行动,而无需终止 RAA 。例如, ICANN 有权暂停注册服务商创建新注册域名和 / 或转让注册域名的职能,暂停时间最长为一年,但是仅限于特定情况下。注册服务商可能因为未能在要求的时间内纠正违反 RAA 的行为而面临暂停。此外,如果注册服务商在一年内由于至少三个单独的 RAA 违规行为收到通知,即使注册服务商在要求的时间内纠正了所有通知的违规行为,但基于 RAA 违规情况的重复发生, ICANN 仍有权暂停注册服务商创建新注册的职能。 暂停权利是附加在终止条款之上的,不过暂停作为合规执行工具没有终止那么严厉。

如果注册服务商被某公司 / 实体收购,则必须在收购发生三十 (30) 天内向 ICANN 提供收购通知,并且就注册服务商继续符合委任要求的能力提供相关资料。 如果注册服务商想要将 RAA 转让给另一公司或实体, ICANN 必须书面同意转让。


3. 总结

RAA 是 ICANN 及其委任的各个注册服务商之间签订的具有法律效应的文件。 RAA 对于确定注册服务商在域名系统中的作用以及注册服务商与其注册域名持有者之间如何互动有着重要的意义。本指南旨在协助注册域名持有者和最终用户更好地理解 ICANN 和注册服务商之间的义务,并且就 RAA 义务如何影响注册域名持有者和最终用户进行了一些讨论。 虽然本指南不具有法律效力,但是也非常重要,它可帮助所有人更容易理解 ICANN 的工作,而且也就互联网群体中所有人的作用和责任增进了共识。


4. 术语表

此部分给出了一些基本术语,帮助您理解与 ICANN 和域名系统 (DNS) 相关的内容。更加全面的术语表请访问 http://www.iana.org/about/glossary/ 。 这里对术语所作的一般性描述并不能替代 RAA 中所用术语的法律定义,只是为了帮助您理解本指南。

ccTLD 或国 家或地区顶级域名: ccTLD 是一类只能分配用于代表 ISO 3166 列表中的国家或地区的 TLD (见下文)。这些域名是双字符域名,例如.DE 代表德国,.IE 代表爱尔兰。近期将会出现其他 ccTLD ,称为国际化域名 ccTLD (IDN ccTLD) ,这些域名是对应的非拉丁字符,允许使用本国的文字和字符注册,例如使用阿拉伯文表示沙特阿拉伯,或者使用西里尔字母表示俄罗斯。 ccTLD 注册不遵循 RAA 的条款。

gTLD ( 通用顶级域名 ): 用于一般用途的一类 TLD ( 见下文 ), 例如.COM 或.NET 。 gTLD 有两种类型 : 商业性顶级域名 , 如.JOBS 或.TRAVEL , 非商业性 TLD , 如.COM 和.NET 。商业性 TLD 面向特定的群体,注册管理机构与赞助组织互动,监督商业性 TLD 的运作政策的制定。 RAA 适用于所有 gTLD 的注册。

域名服务器: 互联网上响应域名转换请求的系统的通称。

注册域名持有者: 域名的注册人。

注册服务商: 应注册域名持有者的请求,在注册管理机构进行更改(包括域名的最初注册)的实体。 RAA 适用于所有获得 gTLD 域名注册委任的注册服务商。

注册管理机构: 为了理解 RAA ,注册管理机构是特定 TLD 内的所有注册的记录。

注册管理执行机构: 运行注册管理机构的个人或实体。

TLD (顶级域名): TLD 是 DNS 中最高级别的子域,由“点”右侧的所有符号表示,例如.COM 、.UK 和.EDU 。 TLD 有许多不同的分类,包括通用 TLD (gTLD) 和国家或地区代码 TLD (ccTLD) 。

UDRP ( 统一域名争议解决政策): UDRP 是 ICANN 通过的一项政策,这项政策已纳入到注册域名持有者和 gTLD 注册服务商之间的签订的每个协议。 UDRP 针对与域名的注册和使用有关的争议规定了条款和条件。 UDRP 已被翻译为 10 种语言,发布在 http://www.icann.org/en/dndr/udrp/policy.htm


* 非律师人员指南正在修订中。ICANN 工作人员欢迎您就如何改进指南发表意见和建议。

1 RAA 没有列出有关代理 / 私人注册的讨论。本指南中提供了相关讨论。

2 在本指南末尾的术语表中简要解 释了 UDRP 。

3 访问http://www.icann.org/en/registrars/gtld-lifecycle.htm 可查阅典型 的 gTLD 注册域名的生命周期图解。本图解可为域名过期状态提供更多有用的参考信息 。

4 域名状态有正式的技术名称,这是由基于群体的互联网征求意见书草案提出的。此处要求的状态由注册服务商确定。当注册处于这些状态中之一时,不能删除域名并且不能修改注册。要进行修改,注册服务商必须取消“保持”或“锁定”状态 。

5 还有很多其他可能的方式会“侵犯他人合法权利”,如果潜在注册域名持有者担心域名的注册或使用可能侵犯他人权利,最好寻求独立的建议帮助。

6 可能会有其他管辖区能够处理有关注册域名使用的争议, 但是 RAA 中 并没有具体指定这些管辖区。

7 如需 ICANN 中 已经制定的共识性政策举例,请访问 http://www.icann.org/en/general/consensus-policies.htm.

8 在注册服务商的委任终止时, ICANN 可 以遵循特定的流程,协助有序的注册转换。在丧失认可资格的注册服务商数据交接流程可以找到有关具体流程的更多信息,请访问 http://www.icann.org/en/processes/registrars/de-accredited-registrar-transition-procedure-01oct08.pdf [PDF, 119 KB] 。

9仲裁是解决争议的私人方式,与之相对的公开方式是向法院提起诉讼。仲裁相比向法院提起诉讼通常更快且更有效。仲裁受私人雇佣的仲裁员组成的评判小组监督,而不是受法官监督,所有这些仲裁员必须清楚了解仲裁相关各方的利益冲突。

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