新 gTLD 协议
新 gTLD 协议
x文件包含的注册管理机构协议涉及新 gTLD 的《申请人指南》。
申请成功的 gTLD 申请人应与 ICANN 签署本注册管理机构协议，然后才能获得所申请的新 gTLD 授权。（说明：ICANN 保留在申请流程进行中对本协议提案进行适当更新和修改的权利，包括在申请流程进行中可能通过的新政策所引致的更新或修改）。本协议草案版本与上一草案版本有所差异，说明备忘录《基本协议变更摘要》中提供了相关的背景信息。
x《注册管理机构协议》（以下简称本“协议”）由加利福尼亚州非营利性公益组织“互联网名称与数字地址分配机构”（以下简称“ICANN”）与 （所属司法辖区及性质 ）（以下简称“注册管理执行机构”）共同签署，自 （以下简称“生效日期”）起生效。
ARTICLE 1.
顶级域的授权和经营；xx和保证
1.1 域与指定。本协议适用的顶级域为 （以下简称“TLD”）。自生效日期起，直至第 4.1 节中定义的期限结束之日，ICANN 根据 TLD 授权以及进入根区域的要求及必要的审批，指定 为该TLD 的注册管理执行机构。
1.2 字符串的技术可行性。尽管 ICANN 一向鼓励并且还将继续鼓励整个互联网范围内能够普遍接受所有顶级域字符串，某些顶级域字符串还是有可能会遇到 ISP 和网络主机提供商难以接受和/或 Web 应用程序难以验证的问题。注册管理执行机构应在签署本协议之前负责确保其满足TLD 字符串的技术可行性。
1.3 x x 和 保 证 。
(a) 注册管理执行机构向 ICANN 作出以下xx和保证：
(i) 其在注册管理机构 TLD 申请中提供的所有重要信息、做出的所有声明以及在本协议谈判期间所做的书面声明在所有重要方面均真实准确，且自生效日期起，此类信息和声明在所有重要方面将继续保持真实准确，除非注册管理执行机构以书面形式另行通知 ICANN。
(ii) 注册管理执行机构依据本文前言部分填写的辖区的法律正式成立、有效存续且资格完备，而且注册管理执行机构具备所有必要权利和权限并已获得所有必要批准，可以订立、正式签署和交付本协议；且
(iii) 注册管理执行机构已正式签署并向 ICANN 交付一份法律文书，以保证在本协议终止和到期之时可提供执行所运营的 TLD 注册管理机构职能所需的资金（“持续运营法律文书”），此类法律文书对本协议各方均具有约束力且其条款对于协议各方均具有强制执行力。
(b) ICANN 向注册管理执行机构作出xx和保证，ICANN 是依据美国加利福尼亚州法律正式成立、有效存续且资格完备的一家非营利性公益组织。ICANN 具备订立并正式签署和交付本协议所需的所有权利和权限并已通过所有必要的机构审批。
ARTICLE 2.
注册管理执行机构的约款
注册管理执行机构与 ICANN 达成协议如下：
2.1 批准的服务；附加服务。注册管理执行机构应有权提供规范中第 2.1 节的 (a) 和 (b)款中所述的注册管理机构服务 [参见规范 6]（“规范 6”）及附录 A 中规定的此类其他注册管理机构服务（统称为“批准的服务”）。如果注册管理执行机构意欲提供任何不属于批准的服务的注册管理机构服务或属于对批准的服务修改后的服务（均称为“附加服务”），则注册管理执行机构应根据 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx 上载明的注册管理机构服务评估政策
（简称“RSEP”，此类政策可能不时根据 ICANN 章程（称为“ICANN 章程”，可能会不时修订）进行修订，以适应共识性政策的需要）提交此类附加服务审批申请。只有经过 ICANN 的书面批准，注册管理执行机构才能提供附加服务，而且在得到批准后，此类附加服务应视为本协议下的注册管理机构服务。ICANN 经过合理的判断，可能要求对本协议作出修订，以反映根据 RSEP 批准提供任何附加服务这一情况，修订内容应采用各方可以合理接受的格式。
2.2 遵守共识性政策和临时政策。注册管理执行机构应遵守并执行本协议生效之日时
<xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx> 中的所有共识性政策和临时政策，以及将来按照 ICANN 章程可能制定和采纳的政策，前提是此类共识性政策和临时政策按 [请参见规范 1]*
（称为“规范 1”）中规定的程序进行采纳、与其中的主题相关并遵守其中规定的限制。
2.3 数据托管。注册管理执行机构应遵守 [请参见规范 2]* 中公布的注册管理机构数据托管程序。
2.4 每月报告。在每个月结束后的二十 (20) 日之内，注册管理执行机构应以规范 [请参见规范 3]* 中公布的格式向 ICANN 提交报告。
2.5 注册数据的公布。注册管理执行机构应根据 [请参阅规范 4]*（“规范 4”）中公布的规范提供公众访问注册数据的途径。
2.6 保留名称。除 ICANN 以书面形式另行明确授权外，注册管理执行机构应遵守 [请参见规范 5]*（“规范 5”）中规定的字符串注册限制。注册管理执行机构可自行决定拟订有关保留更多的字符串或在 TLD 中阻止注册这些字符串的政策。如果注册管理执行机构是注册管理机构 TLD 中任何域名（而非规范 5 中规定的注册管理执行机构保留的二级域名）的注册人，则此类注册必须通过 ICANN 认可的注册服务商进行。任何此类注册将视为交易（如第 6.1 节中定义），以便于根据第 6.1 节计算注册管理执行机构要支付给ICANN 的注册管理机构交易费用。
2.7 注册管理机构互操作性和连续性。注册管理执行机构应遵守“规范 6”中规定的 “注册管理机构互操作性和连续性规范”。
2.8 第三方合法权利的保护。注册管理执行机构必须按照 [请参见规范 7]*（“规范 7”）中的规定，指定并遵守一个流程和程序，用于启动 TLD 以及在首次注册和后续过程中对第三方的合法权利提供持续保护。注册管理执行机构可以自行选择对第三方合法权利实施额外保护。在本协议生效日期后对“规范 7”所要求的流程和程序作出的任何更改或修改均应由 ICANN 提前做出书面批准。注册管理执行机构必须按照规范 7 第 2 节之规定遵守 ICANN 强制施行的所有补救措施，前提是注册管理执行机构有权对规范中提到的适当程序所规定的此类补救程序提出质疑。注册管理执行机构应采取合理措施，对任何来自执法机构及政府和准政府机构且涉及 TLD 使用的非法行为的报告进行调查并给予答复。在答复此类报告时，注册管理执行机构无需采取任何违反适用法律的措施。
2.9 注 册 服 务 商 。
(a) 注册管理执行机构只能使用 ICANN 认可的注册服务商来注册域名。如果注册管理执行机构要为在 TLD 中注册属于 TLD 正常使用范畴的名称的注册资格建立无歧视性标准，则必须无歧视地为所有 ICANN 认可的、签订并遵守 TLD“注册管理机构-注册服务商协议”的注册服务商提供注册管理机构服务访问权限。注册管理执行机构对所有经授权可在 TLD 中注册名称的注册服务商都要使用统一的无歧视性协议。注册管理执行机构可能会不时对此类协议进行修订，不过，任何修订须经 ICANN 事先批准。
(b) 如果注册管理执行机构 (i) 成为某个 ICANN 认可的注册服务商的附属机构或分销商；或者 (ii) 将任何注册管理机构服务的提供分包给 ICANN 认可的注册服务商、注册服务商的分销商或其任何附属机构，无论出现情况 (i) 还是情况 (ii)，注册管理执行机构都要就促成此类附属关系、分销商关系或分包关系（ 如果适用） 的相应合同、交易或其他约定迅速通知 ICANN，这包括在 ICANN 提出要求时，将任何与此相关的合同副本提供给 ICANN，前提是 ICANN 不会将此类合同披露给相关竞争管理机构之外的任何第三方。ICANN 保留在确定此类合同、交易或约定可能引发竞争问题的情况下将合同、交易或其他约定转交相关竞争管理机构处理的权利，但 ICANN 并不承担此类转交的义务。
(c) 在本协议中：(i)“附属机构”是指直接或间接通过一个或多个中间方来控制指定个人或实体、受指定个人或实体控制或与其共同受控的个人或实体；(ii)“控制”（包括术语“控制”、“受控”和“共同受控”）是指拥有直接或间接的权利来引导或造成引导个人或实体的管理和政策，无论是通过证券所有权、作为受托人或执行人、通过担任理事会或等效监管机构的成员、根据合约、信用协定还是其他方式。
2.10 注册管理机构服务定价。
(a) 注册管理执行机构针对域名初始注册的任何提价举动（包括取消退款、返款、折扣、产品搭售或取消其他有效减低对注册服务商收取的价格的计划，除非此类退款、返款、折扣、产品搭售或其他计划有一定期限，且在提供时已清楚、明显地披露给注册服务商），应至少提前三十 (30) 天向每个 ICANN 认可且正式签署了 TLD“注册管理机构-注册服务商协议”的注册服务商发出书面通知。注册管理执行机构为注册服务商提供获得初始注册域名一至十年
（由注册服务商自行选择）的方案，但不超过十年。
(b) 注册管理执行机构针对域名注册续约的任何提价举动（包括取消退款、返款、折扣、产品搭售、限制性营销计划或取消其他有效减低对注册服务商收取的价格的计划），应至少提前一百八十天 (180) 天向每个 ICANN 认可且正式签署了 TLD“注册管理机构-注册服务商协议”的注册服务商发出书面通知。尽管有上一句规定，但对于域名注册续约：(i) 如果 (A) 自协议生效日期起十二 (12) 个月期间，最终价格少于或等于最初针对在 TLD 中注册名称而收取的价格；或者 (B) 在此期间后，最终价格少于或等于注册管理执行机构在所提议提价的生效日期之前十二 (12) 个月内按照此 2.10(b) 节第一句之要求通知的价格，注册管理执行机构仅需提前三十
(30) 天就任何提价举动发出通知；(ii) 对于按照第 6.3 节规定所收取的可变注册管理机构费用，注册管理执行机构无需就提价发出任何通知。
(c) 注册管理执行机构为注册服务商提供以当前价格（即任何提价通知之前的价格）对域名注册续约一至十年（由注册服务商自行选择）的方案，但不超过十年。另外，注册管理执行机构必须对域名注册续约统一定价（“续约价格”）。就确定续约价格而言，每个域名注册续约价格要与当时存在的所有其他域名注册续约价格相同，此价格须考虑统一适用续约时存在的任何退款、返款、折扣、产品搭售或其他计划。此 2.10(c) 节的上述要求在以下情况下不适用：
(i) 如果注册服务商已向注册管理执行机构提供相应文件，证明相应的注册人在初始域名注册时于其注册协议中明确表示同意较高的续约价格，且注册人此前已被清楚、明确地告知此续约价格，则此要求在确定续约价格时不适用；(ii) 此要求不适用于按照限制性营销计划（定义见下文）作出的打折续约价格。相关方承认此 2.10(c) 节之目的在于阻止注册管理执行机构在初始域名注册时未经相关注册人书面同意而实施滥用性和/或歧视性的续约定价行为，并且此 2.10(c) 节之xx在阻止此类行为方面应做宽泛解释。就 2.10(c) 节而言，此处的“限制性营销计划”是指注册管理执行机构在提供有折扣的续约定价时所依照的营销计划，其前提是需满足下述各项标准：(i) 营销计划及相关折扣的持续时间不超过一百八十 (180) 个日历天（在确定计划的日历天数时需汇总充分相似的连续计划）；(ii) ICANN 认可的所有注册服务商都有同等机会来符合此类打折续约价格的条件；(iii) 营销计划的意图和实际效果应是不排斥任何特定类别的注册（例如，大公司进行的注册），也不会提高任何特定类别注册的续约价格。此 2.10(c) 节的任何内容均不应限制注册管理执行机构根据第 2.10(b) 节需履行的义务。
(d) 注册管理执行机构应自费为 TLD 提供面向公众的基于查询的 DNS 查找服务（即运行注册管理机构TLD 区域服务器）。
2.11 合同和运营合规审核。
(a) ICANN 可能会不时（每年不超过两次）自己或聘用第三方机构进行合同合规性审核，以评估注册管理执行机构是否遵守本协议第 1 条中包括的xx和保证及第 2 条中包括的约款。此类审核应针对评估合规性的目标而设计，ICANN (a) 应合理地提前通知任何此类审核，此通知中应适当详细说明 ICANN 所要求的文档、数据和其他信息的类别，并且 (b) 通过合理的商业行为以不会无理干扰注册管理执行机构运营的方式来执行此类审核。在任何此类审核过程中，注册管理执行机构应根据 ICANN 的要求履行以下义务：及时提供所有必要的相关文档、数据和任何其他信息，以证明注册管理执行机构遵守了本协议。ICANN 应至少提前五 (5) 个工作日通知（或经注册管理执行机构同意另行指定提前期），以便可以在任何合同合规性审核过程中在
正常工作时间进行现场访问，以评估注册管理执行机构是否遵守本协议第 1 条中包括的xx和保
证及第 2 条中包括的约款。
(b) 任何依照 2.11(a) 执行的审核由 ICANN 承担费用，除非 (i) 注册管理执行机构 (A) 控制、受控制于、与其共同受某方控制或以其他方式附属于任何 ICANN 认可的注册服务商或注册服务商的分销商或其任何附属机构，或者注册管理执行机构 (B) 已将注册管理机构服务的提供分包给某个 ICANN 认可的注册服务商、注册服务商的分销商或其任何附属机构，并且无论是情况 (A) 还是情况 (B)，审核都是关于注册管理执行机构是否遵守第 2.14 节之规定，此种情况下，注册管理执行机构应向 ICANN 补偿审核活动中与注册管理执行机构是否遵守第 2.14 节相关的审核过程所涉及的所有合理成本和费用；或者除非 (ii) 该审核是关于注册管理执行机构支付费用不符合本协议之规定且差额超过 5% 而给 ICANN 带来损害，此种情况下，注册管理执行机构应向 ICANN 补偿整个审核过程涉及的所有合理成本和费用。无论是情况 (i) 还是情况 (ii)，此类补偿费用应在此类审核成本声明发送之日起的下一个注册管理机构费用支付日，与注册费用一起支付。
(c) 尽管有 2.11(a) 节之规定，但如果在根据第 2.11 节进行的连续两次审核中发现注册管理执行机构未遵守本协议第 1 条中的xx和保证及第 2 条中包括的约款，则 ICANN 可以将此类审核的次数增加到每季度一次。
(d) 如果要开始任何第 4.3(d) 节提及的诉讼或出现第 4.3(f) 节所指定的任何情况，注册管理执行机构要立即就此通知 ICANN。
2.12 持续运营法律文书。注册管理执行机构应遵守规范 [请参阅规范 8] 中列出的与“持续运营法律文书”相关的条款与条件。
2.13 紧急移交。注册管理执行机构同意，如果在规范 10 的第 6 节中规定的任何注册管理机构职能未能履行的时间超过该节中设定的此类职能紧急阈值，则 ICANN 可以依据 ICANN 的注册管理机构过户流程（在 提供）（称为“注册管理机构过户流程”，该流程可能不时修正），为该 TLD 注册管理机构指定一个紧急的过渡性注册管理执行机构（“紧急执行机构”），直到原注册管理执行机构向 ICANN 表明并使其合理相信，它可以继续运营 TLD 注册管理机构而不会再发生这种未能履行职责的情况。之后，注册管理执行机构可以根据注册管理机构过户流程中规定的程序，重新运营 TLD 注册管理机构，前提是注册管理执行机构支付了下列所有合理相关成本：(i) ICANN 因指定紧急执行机构而发生的成本，以及 (ii) 紧急执行机构因其运营 TLD 注册管理机构而发生的成本，这些成本应以合理的详细程度记录在案并提供给注册管理执行机构。x ICANN 依据此 2.13 节和注册管理机构过户流程指定一家紧急执行机构，则如果 ICANN或此类紧急执行机构提出合理要求，注册管理执行机构应向 ICANN 或该紧急执行机构提供维持运营和注册管理机构职能必需的所有 TLD 注册管理机构运营数据（包括根据第 2.3 节托管的数据）。注册管理执行机构同意，如果依据此 2.13 节指定了紧急执行机构，则 ICANN 可以对 IANA 数据库中与 TLD 相关的 DNS 和 WHOIS 记录进行其认为有必要的任何修改。此外，在这种未能履行职责的情况下，ICANN 将保留并可执行其根据“持续运营法律文书”和其他法律文书
（如果适用）应享有的权利。
2.14 注册管理机构行为准则。关于 TLD 注册管理机构的运营，注册管理执行机构应遵守规范[请参阅规范 9] 中规定的“注册管理机构行为准则”。
2.15 配合开展经济研究活动。如果 ICANN 针对新通用顶级域对互联网、DNS 或相关事务的影响及功用而发起或委托开展了某项经济研究活动，注册管理执行机构应适当配合开展此类研究，包括为了 ICANN 或 ICANN 指定方要求的此类研究，向其提供所有合理必要的数据，但前提是注册管理执行机构可以保留自己准备的与此类数据有关的任何内部分析或评估。按照此 2.15节提供给 ICANN 或其指定方的任何数据在披露给任何第三方之前应由 ICANN 或其指定方完全汇总并进行匿名处理。
2.16 注册管理机构性能规范。有关 TLD 运营方面的注册管理机构性能“规范”将在规范中进行说明 [请参见规范 10]*。注册管理执行机构应遵守此类性能规范，并且对于协议期限内的每一个日历年，至少在一年内保留足以证明遵守此类规范的技术和运营记录。
2.17 个人数据。注册管理执行机构应 (i) 将以下事项通知给每一个 ICANN 认可的签署 TLD“注册管理机构-注册服务商协议”的注册服务商：根据本协议或在其他情况下，注册管理执行机构会收集和使用注册服务商提交给注册管理执行机构的有关任何身份确定或可确定的自然人的哪些数据（“个人数据”），以及此类个人数据的预期接收者（或接收者类别），并且 (ii) 要求此类注册服务商向 TLD 中的每位注册人取得此类个人数据收集和使用的同意。注册管理执行机构应采取合理步骤防止从此类注册服务商处收集到的个人数据遭到丢失、滥用、未授权披露、篡改或破坏。注册管理执行机构不得以不符合向注册服务商提供的通知的方式使用或授权使用个人数据。
2.18 [说明：仅限基于群体的 TLD] 注册管理执行机构对 TLD 群体的责任。注册管理执行机构应按照提交的关于 TLD 的申请就以下各项制定注册政策：(i) TLD 中的命名规则；(ii) TLD群体成员的注册要求；和 (iii) 按照基于群体的 TLD 的确定目的对所注册域名的使用。注册管理执行机构的 TLD 运营方式应允许 TLD 群体讨论和参与 TLD 政策和做法的制定和修改。注册管理执行机构应制定 TLD 注册政策的执行程序和有关 TLD 注册政策合规性的争议解决程序，还应负责执行这些注册政策。对于根据第 2.18 节引发的争议， 注册管理执行机构同意执行 [insert applicable URL] 中规定的“注册管理机构限制争议解决程序”并受其约束。]
ARTICLE 3. ICANN 约款
ICANN 与注册管理执行机构达成协议如下：
3.1 公开和透明。ICANN 将按照其公示的使命与核心价值，以公开透明的方式行使职责。
3.2 公平待遇。除非有实质性的正当理由，否则 ICANN 不得以武断、不合理、不公正的方式应用自己的标准、政策、程序或做法，也不得对注册管理执行机构区别对待。
3.3 TLD 名称服务器。ICANN 将通过合理的商业行为确保由注册管理执行机构提交给 ICANN 的对 TLD 名称服务器指定的任何变更（使用 ICANN 在 xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/中指定的格式并包含所需的技术要素），都会由 ICANN 在技术验证后七 (7) 天之内或尽快实施。
3.4 根区域信息的公布。ICANN 在公布注册管理机构 TLD 的根区域联系信息时，应包括注册管理执行机构及其管理和技术联系人的信息。注册管理执行机构修改联系人信息的任何请求，必须始终以 ICANN 在 xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ 上指定的格式提出。
3.5 官方根数据库。如果 ICANN 获得授权制定与官方根服务器系统相关的政策， ICANN 应该通过合理的商业行为(a) 确保官方根指向注册管理执行机构为TLD 指定的顶级域名称服务器，(b) 依据 ICANN 公开可用的政策和程序，维护一个稳定、安全且公开可用的包含 TLD 相关信息的权威数据库，并且 (c) 协调官方根服务器系统，使其以一种稳定安全的方式运行和维护；前提是，ICANN 不构成违反本协议且 ICANN 对于任何第三方（包括任何政府机构或互联网服务提供商）在任何司法管辖区内阻止或限制访问 TLD 的情况不承担任何责任。。
ARTICLE 4.
期限和终止
4.1 期限。本协议的期限将自生效日期起持续十年（此期限可根据第 4.2 节延长，以下简称“期限”）。
4.2 续 x 。
(a) 在上述第 4.1 节中规定的初始期限和各个后续期限到期后，本协议都将进行续约（期限为十年的倍数），除非：
(i) 注册管理执行机构从根本上和实质上违反本协议第 2 条中规定的注册管理执行机构约款或没有履行本协议第 6 条规定的付款责任，并且在收到 ICANN 就此违约行为向注册管理执行机构发出的通知（应详细说明所指控的违约行为）后三十 (30) 天内未纠正自己的违约行为；(A) 仲裁机构和法院最终裁定注册管理执行机构从根本上和实质上违反此约款或没有履行此付款责任，和 (B) 注册管理执行机构未遵守此裁定，在十 (10) 天或仲裁机构和法院规定的其他时间期限内未纠正自己的违约行为；或
(ii) 现行“期限”期间，仲裁机构（根据本协议第 5.2 节）最少在三 (3) 次不同情况下发现注册管理执行机构从根本上和实质上违反本协议第 2 条中规定的注册管理执行机构约款或没有履行本协议第 6 条规定的付款责任（不管有没有纠正）。
(b) 出现第 4.2 (a) (i) 或 (ii) 节所述事件后，本协议将于现行期限到期时终止。
4.3 ICANN 终 止 协 议 。
(a) 如果出现下列情况，ICANN 可在通知注册管理执行机构后终止本协议：(i)注册管理执行机构 (A) 从根本上和实质上违反本协议第 1 条中规定的注册管理执行机构的xx和保证，没有履行本协议第 2 条规定的约款，或者没有履行本协议第 6 条规定的注册管理执行机构付款责任，在收到 ICANN 就此违约行为向注册管理执行机构发出的通知（应详细说明所指控的违约行为）后三十 (30) 天内没有纠正违约行为；(ii) 仲裁机构或法院最终裁定注册管理执行机构从根本上和实质上违反此类约款或没有履行其付款责任；和 (iii) 注册管理执行机构未遵守此裁定，在十(10) 天或者仲裁机构或法院规定的其他时间期限内未纠正自己的违约行为。
(b) 如果注册管理执行机构在生效日期起十二 (12) 个月内未完成将 TLD 授权到根区域需要的所有的测试和程序（ICANN 在本协议日期前发送给注册管理执行机构的书面文件中确定的测试和程序），ICANN 可在通知注册管理执行机构后终止本协议。如果注册管理执行机构能向 ICANN 证明其正在为成功完成 TLD 授权必需的步骤而勤勉诚实地努力，且得到了 ICANN的合理认同，则注册管理执行机构可以请求延长授权期限，最多可以延长十二 (12) 个月。在此终止日期之前由注册管理执行机构向 ICANN 支付的所有费用，应由 ICANN 全额保留。
(c) 如发生以下情形，则 ICANN 可在通知注册管理执行机构后终止本协议：(i)注册管理执行机构从实质上违反了本协议第 2.12 节中规定的注册管理执行机构责任，且未在 ICANN 发出此类违约通知之后的三十 (30) 天内纠正违约行为，或者“持续运营法律文书”在生效日期之后的任何时间连续超过六十 (60) 天无效，(ii) 仲裁机构或法院最终裁定注册管理执行机构从实质上违反此约款，以及 (iii) 注册管理执行机构在十 (10) 天或仲裁机构或法院规定的其他此类时间期限内未能纠正此类违约行为。
(d) 如发生以下情形，ICANN 可在通知注册管理执行机构后终止本协议：(i) 注册管理执行机构为了债权人的利益进行转让或采取类似措施，(ii) 对注册管理执行机构提起了查封、传唤或类似诉讼程序、诉讼程序对注册管理执行机构的 TLD 注册管理机构的运营能力构成实质性威胁并且在六十 (60) 天内没有被驳回，(iii) 指定了委托人、接收人、清算人或具有同类效力的人来取代注册管理执行机构或保持对注册管理执行机构任何财产的控制，(iv) 对注册管理执行机构的任何财产进行法律执行，(v) 依据任何破产、无力偿还、重组或其他与债务人债务清除相关的法律，由注册管理执行机构或针对注册管理执行机构提起了诉讼程序，并且此类诉讼在三十 (30) 天内没有被驳回，或者 (vi) 注册管理执行机构依照美国破产法（美国法典第 11 编第 101 条及以下内容）或同等外国法律申请保护或者清盘、关闭或以其他方式停止其运营或停止 TLD 的运营。
(e) ICANN 可按照规范 7 第 2 节的规定，在通知注册管理执行机构三十 (30) 天后终止本协议，前提是注册管理执行机构有权按照该处所述的适当程序对此类终止提出质疑。
(f) 如发生以下情形，ICANN 可在通知注册管理执行机构后终止本协议：(i) 注册管理执行机构在知情的情况下雇用的任何高管被判与经济活动相关的轻罪或任何重罪，或被具有有效管辖权的法院判定进行欺诈或违反诚信义务，或是某司法认定的处罚对象，且 ICANN 有理由相信此处罚在性质上与以上罪行同样严重并且注册管理执行机构在了解上述情况后的三十
(30) 天内没有免除该高管职务；或者 (ii) 注册管理执行机构董事会或类似主管团体的任何成员被判与经济活动相关的轻罪或任何重罪，或被具有有效管辖权的法院判定进行欺诈或违反诚信义务，或是某司法认定的处罚对象，且 ICANN 有理由相信此处罚在性质上与以上罪行同样严重并且注册管理执行机构在了解上述情况后的三十 (30) 天内没有将该成员从注册管理执行机构的理事会或类似管理机构除名。
协议。
(g) [仅适用于政府间机构或政府组织。] ICANN 可依照第 7.14 节之规定终止本
4.4 注册管理执行机构终止协议。
(a) 如发生以下情形，注册管理执行机构可在通知 ICANN 后终止本协议：(i) ICANN 从根本上和实质上违反第 3 条中规定的 ICANN 约款，并在注册管理执行机构就此违反行为向 ICANN 发出通知（应详细说明所指控的违约行为）后三十 (30) 天内没有纠正此违约行为；
(ii) 仲裁机构或法院最终裁定 ICANN 从根本上和实质上违反此类约款；(iii) ICANN 未遵守此裁定，在十(10) 天或仲裁机构或法院规定的其他此类时间期限内未纠正自己的违约行为。
终止本协议。
(b) 注册管理执行机构可在提前一百八十 (180) 天通知 ICANN 后，因任何原因
4.5 协议终止时的注册管理机构移交。当期限根据第 4.1 或 4.2 节的规定而过期或本协议根据第 4.3 或 4.4 节的规定而终止时，如果 ICANN 或 ICANN 指定的任何继任 TLD 注册管理执行机构提出合理要求，注册管理执行机构应依据此 4.5 节向 ICANN 或此类继任的注册管理执行机构提供维持运营和注册管理机构职能必需的所有 TLD 注册管理机构运营数据（包括根据第 2.3 节托管的数据）。与注册管理执行机构商讨后，ICANN 应根据注册管理机构过户流程，自行决定是否将 TLD 的运营移交给继任注册管理执行机构；不过，前提是，如果注册管理执行机构能在令 ICANN 合理满意的情况下证实：(i) TLD 中注册的所有域名均是向注册管理执行机构注册，由注册管理执行机构维护以供其独家使用；(ii) 注册管理执行机构没有向不附属于注册管理执行机构的任何第三方出售、分配或转让 TLD 中任何注册域名的控制权或使用权；以及 (iii) 对于保护公众利益而言，移交 TLD 运营权并无必要，则在本协议到期或终止时，未经注册管理执行机构同意， ICANN 不得将 TLD 运营权移交给继任注册管理执行机构（这一点不得无理拒绝、设置条件或延迟）。为避免疑义，上一句的规定未禁止 ICANN 依据未来用于授权顶级域名的申请流程来授权 TLD，该申请流程受到 ICANN 制定的与此类申请流程有关的任何流程和异议程序的约束，以保护第三方的权利。。注册管理执行机构同意，如果依据此 4.5 节移交了 TLD，则 ICANN 可以对 IANA 数据库中与 TLD 相关的 DNS 和 WHOIS 记录进行其认为有必要的任何修改。此外，不管本协议终止或到期的理由为何，ICANN 或 ICANN 指定的一方应保留并可执行其根据“持续运营法律文书”和其他法律文书（如果适用）应享有的权利。
[第 4.5 节协议终止时的注册管理机构移交的替换文本（适用于政府间机构或政府组织或其他特殊情况）：
“协议终止时的注册管理机构移交。当期限根据第 4.1 或 4.2 节的规定而过期或本协议根据第 4.3 或 4.4 节的规定而终止时，如果 ICANN 指定了继任的 TLD 注册管理执行机构，则注册管理执行机构和 ICANN 同意相互协商并密切协作，根据此 4.5 节促进和实施 TLD 的移交。与注册管理执行机构商讨后，ICANN 应根据注册管理机构过户流程，自行决定是否将 TLD 的运营移交给继任注册管理执行机构。x ICANN 决定将 TLD 的运营移交给继任注册管理执行机构，在注册管理执行机构的同意下（不得无理拒绝、提条件或延迟），如果 ICANN 或此类继任 TLD 注册管理执行机构提出合理要求，注册管理执行机构应向 ICANN或该注册管理执行机构提供维持运营和注册管理机构职能必需的所有 TLD 运营数据，包括根据第 2.3 节托管的数据。若注册管理执行机构不同意提供此类数据，则应将与 TLD 相关的所有注册管理机构数据返回给注册管理执行机构，除非双方另行达成协议。注册管理执行机构同意，如果依据此 4.5 节移交了 TLD，则 ICANN 可以对 IANA 数据库中与 TLD 相关的 DNS 和 WHOIS 记录进行其认为有必要的任何修改。此外，不管本协议终止或到期的理由为何，ICANN 或 ICANN 指定的一方应保留并可执行其根据“持续运营法律文书”和其他法律文书（如果适用）应享有的权利。”]
4.6 协议终止的效力。本协议到期或终止时，本协议各方依照本协议的义务和权利也将终止，但本协议的到期和终止不能免除本协议各方在本协议到期或终止之前产生的任何义务或违约赔偿责任，包括但不限于根据第 6 条产生的所有应计付款义务。此外，第 5 条，第 7 条，第
2.12 节，第 4.5 节以及第 4.6 节在本协议到期或终止后继续生效。为避免疑义特此说明，注册管理执行机构对TLD 注册管理机构的运营权利在本协议期限到期或终止时随即终止。
ARTICLE 5.
争议解决
5.1 合作约定。在任何一方依据下文第 5.2 节之规定启动仲裁程序之前，ICANN 和注册管理执行机构应该开始诚恳的沟通，然后，双方必须以诚恳的态度进行至少十五 (15) 天的商讨，以尝试解决争议。
5.2 仲裁。由本协议引起或与本协议有关的争议，包括申请强制履行，将依据国际商会国际仲裁法院的规则进行具有约束力的仲裁加以解决。仲裁将在美国加利福尼亚州洛杉矶郡以英文语言进行。任何仲裁将由一位仲裁人作出，除非 (i) ICANN 提请惩罚性或警告性赔偿或者运营制裁；或者 (ii) 本协议各方书面同意由更多仲裁人进行裁决。在诉讼判决中无论是条文 (i) 的情况还是条文 (ii) 的情况，仲裁将由三位仲裁人执行，每方各选择一位仲裁人并由选出的这两位仲裁人选择第三位仲裁人。为了加快仲裁处理进度并限制其成本，仲裁人应对各方与仲裁相关的材料做出页数限制，而且一旦仲裁人决定必须举行听证会，则应将听证会限制在一 (1) 天内完成，如果是对 ICANN 提请惩罚性或警告性赔偿或者运营制裁的诉讼进行仲裁，可在双方协商一致或者仲裁人根据其独立决定或根据相关一方的合理请求做出命令的情况下，将听证会延长一 (1) 个
日历天。仲裁中胜诉一方有权要求获得成本和合理的律师费用的补偿，仲裁人应在其裁决中包含此项补偿。如果仲裁人裁决注册管理执行机构一再蓄意从根本上和实质上违反本协议第 2 条、第
6 条或第 5.4 节中规定的注册管理执行机构义务，ICANN 均可向仲裁人申请惩罚性或警告性赔偿，或对注册管理执行机构进行运营制裁（包括但不限于发出临时限制注册管理执行机构出售新注册的权利的指令）。在涉及 ICANN 且与本协议有关的任何诉讼中，此类诉讼的辖区和唯一审判地点将是位于加利福尼亚州洛杉矶县的法院；但是，协议双方均有权通过任何具备有效管辖权的法院来强制执行上述法院的审判结果。
[第 5.2 节仲裁的替换文本（适用于政府间机构或政府组织或其他特殊情况）：
“仲裁。由本协议引起或与本协议有关的争议，包括申请强制履行，将依据国际商会国际仲裁法院的规则进行具有约束力的仲裁加以解决。仲裁将使用英语语言在瑞士日内瓦进行，除非注册管理执行机构和 ICANN 双方都同意在其他地点进行。任何仲裁将由一位仲裁人作出，除非 (i) ICANN 提请惩罚性或警告性赔偿或者运营制裁；或者 (ii) 本协议各方书面同意由更多仲裁人进行裁决。在诉讼判决中无论是条文 (i) 的情况还是条文 (ii) 的情况
，仲裁将由三位仲裁人执行，每方各选择一位仲裁人并由选出的这两位仲裁人选择第三位仲裁人。为了加快仲裁处理进度并限制其成本，仲裁人应对各方与仲裁相关的材料做出页数限制，而且一旦仲裁人决定必须举行听证会，则应将听证会限制在一 (1) 天内完成，如果是对 ICANN 提请惩罚性或警告性赔偿或者运营制裁的诉讼进行仲裁，可在双方协商一致或者仲裁人根据其独立决定或根据相关一方的合理请求做出命令的情况下，将听证会延长一
(1) 个日历天。仲裁中胜诉一方有权要求获得成本和合理的律师费用的补偿，仲裁人应在其裁决中包含此项补偿。如果仲裁人裁决注册管理执行机构一再蓄意从根本上和实质上违反本协议第 2 条、第 6 条或第 5.4 节中规定的注册管理执行机构义务，ICANN 均可向仲裁人申请惩罚性或警告性赔偿，或对注册管理执行机构进行运营制裁（包括但不限于发出临时限制注册管理执行机构出售新注册的权利的指令）。在涉及 ICANN 且与本协议有关的任何诉讼中，此类诉讼的辖区和唯一审判地点将是位于瑞士日内瓦的法院，除非注册管理执行机构和 ICANN 双方都同意其他地点；但是，协议双方还有权通过任何具备有效管辖权的法院来强制执行上述法院的审判结果。”]
5.3 责任限制。ICANN 在违反本协议时的总赔偿金额不得超过注册管理执行机构根据本协议在前十二个月期限内向 ICANN 支付的注册管理机构费用的同等金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内）。注册管理执行机构在违反本协议时对 ICANN 的总赔偿金额仅限于在前十二个月期限内向 ICANN 支付的费用的同等金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内），以及第 5.2 节规定的惩罚性或警告性赔偿（如果有）。除第 5.2 节中规定的赔偿之外，在任何情况下，任意一方均无需承担因本协议引起或与本协议有关的特殊损害赔偿、惩罚性损害赔偿、警告性损害赔偿或间接损害赔偿，也无需对履行或不履行本协议中规定的义务承担损害赔偿责任。除非本协议中另有规定，否则任一协议方均不得做出关于自己提供的服务、其服务人员或代理人或者其工作结果的任何明确或默示的保证，包括但不限于对任何适销性、非侵害性或特定用途适用性的默示保证。
5.4 强制履行。注册管理执行机构和 ICANN 同意，不按照本协议的细则来履行本协议条款将可能造成无法挽回的损害。因此，双方同意各方均应有权请求仲裁人发出强制履行本协议条款的命令（此外，双方还有权采取其他任何补救措施）。
ARTICLE 6.
费用
6.1 注册管理机构费用。注册管理执行机构应向 ICANN 支付注册管理机构费用，支付金额等于：(i) 每个季度 6,250 美元的注册管理机构固定费用；加上 (ii) 注册管理机构交易费用。注册管理机构交易费用等于：在适用的季度内首次域名注册或续签域名注册（一级或多级注册，包括与在 ICANN 认可的注册服务商之间迁移域名相关的续签，各为一个“交易”）每年递增的数量乘以 0.25 美元。但是，只有在任意日历季度或任意四个日历季度期，TLD 中发生的交易超过 50,000 个（“交易阈值”）以后才应支付注册管理机构交易费，并且在达到交易阈值的季度，每个交易都应付费，但在没有达到交易阈值的季度则无需支付此费用。注册管理执行机构应在全年每个季度结束后的第 20 天（例如对于 3 月 31 日、6 月 30 日、9 月 30 日和 12 月 31 日结束的季度分别为 4 月 20 日、7 月 20 日、10 月 20 日和 1 月 20 日）向 ICANN 指定的账户支付每季的注册管理机构费用。
6.2 RSTEP 的成本回收。注册管理执行机构根据第 2.1 节请求批准附加服务的申请应由 ICANN 根据 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/ 中的流程提交至注册管理机构服务技术评估小组（以下简称为“RSTEP”）。如果此类申请提交至 RSTEP， 注册管理执行机构应在从 ICANN 收到 RSTEP 发票副本后十 (10) 个工作日内，向 ICANN 汇出 RSTEP 审核费用，除非 ICANN 自行决定支付全部或部分的 RSTEP 审核费用。
6.3 可变注册管理机构费用。
(a) 如果 ICANN 认可的注册服务商（作为一个整体）根据其与 ICANN 的注册服务商委任协议条款，没有批准 ICANN 理事会规定的任何 ICANN 财年的可变委任费，则在 ICANN 发出通知后，注册管理执行机构应向 ICANN 支付可变注册管理机构费用，该费用应每个财政季度支付一次，且应从该 ICANN 财年的第一个财政季度开始累积。该费用由 ICANN 每个季度计算并开具发票，并由注册管理执行机构在从 ICANN 收到发票后六十 (60) 天之内（针对此 ICANN 财年的第一个季度）和二十 (20) 天内（针对此 ICANN 财年的最后一个季度）支付。注册管理执行机构可向与自己签订“注册管理机构-注册服务商协议”的注册服务商开具发票，并征收可变注册管理机构费用（协议中可能专门规定了补偿注册管理执行机构按照第 6.3 节支付的可变注册管理机构费用），但前提是如果向任何一个注册服务商开具发票，则应向 ICANN 认可的所有注册服务商开具发票。可变注册管理机构费用如果可由 ICANN 征收，则属于注册管理执行机构的应付费用，应根据本协议第 6.3 节的规定支付此类费用，不管注册管理执行机构是否可从注册服务商获得此类费用的补偿。如果注册管理执行机构已向 ICANN 支付了可变注册管理机构费用，而 ICANN 之后又征收可变委任费用，则应由 ICANN 合理确定，向注册管理执行机构补偿适当金额的可变注册管理机构费用。如果 ICANN 认可的注册服务商（作为一个整体）根据其与 ICANN 的注册服务商委任协议条款批准了 ICANN 理事会规定的任一财年的可变委任费，则不管
ICANN 认可的注册服务商在此财年期间是否对 ICANN 履行了支付义务，ICANN 均无权征收此财年的可变注册管理机构费用。
(b) 可变注册管理机构费用的金额应针对每个注册服务商规定，且该金额可以同时包括针对每个注册服务商的部分和交易部分。可变注册管理机构费用中针对每个注册服务商的部分应由 ICANN 根据 ICANN 理事会通过的 ICANN 各财年预算来规定。可变注册管理机构费用的交易部分应由 ICANN 根据 ICANN 理事会通过的 ICANN 各财年预算来规定，但每个域名注册（包括与在 ICANN 认可的注册服务商之间迁移域名相关的续约）每年不得超过 0.25 美元。
6.4 费用调整。尽管本协议第 6 条对于费用限制作出规定，但在整个协议期限内，在本协议第一年结束时开始，以及之后的每一年结束之时，ICANN 可自行决定是否增加第 6.1 和
6.3 节中规定的现行费用，如果调整，变更的百分比为 (i) 美国劳工部劳工统计局发布的城镇消费者物价指数美国城市平均值 (1982-1984 = 100)，或相关年份开始之前一 (1) 个月的任何替代指数 (“CPI”)，减去 (ii) 上一年开始之前一 (1) 个月发布的 CPI 指数。如果要增加费用，ICANN 应向注册管理执行机构发出详细说明了调整金额的通知。根据本协议第 6.4 节调整的任何费用均从进行以上计算当年的第一天开始生效。
6.5 延迟付款的附加费用。根据本协议，如果付款延迟三十 (30) 天或更长时间，注册管理执行机构应以每月 1.5% 的利率支付延迟付款的附加费用；如果付款延迟少于三十 (30) 天，则按适用法律允许的最大利率支付延迟付款的附加费用。
ARTICLE 7.
杂项
7.1 对 ICANN 的 补 偿 。
(a) 对于因 TLD 的知识产权所有权、将 TLD 委托给注册管理执行机构、注册管理执行机构运营 TLD 注册管理机构或提供注册管理机构服务而引发的或与之相关的任何第三方索赔、损害赔偿、债务、费用和开支（包括合理法律费用和开支），注册管理执行机构应为 ICANN 及其理事、官员、雇员和代理人（通称为“受补偿人”）提供补偿和辩护；但如果索赔、损害赔偿、债务、费用和开支是因 (i) ICANN、其分包商、专家组成员或评估人的与注册管理机构 TLD 申请流程专门相关及在申请流程过程中发生的行为或不作为（注册管理执行机构要求或出于注册管理执行机构的利益而采取的行为或不作为除外）或因 (ii) ICANN 违反本协议所含任何义务或 ICANN 的故意不当行为而产生，则注册管理执行机构对任何受补偿人均无补偿或辩护义务。本节不应视为要求注册管理执行机构向 ICANN 偿还或补偿与本协议的协商或执行相关的成本或与监督或管理本协议各方各自的协议义务相关的成本。此外，本节也不适用于与本协议各方之间任何诉讼或仲裁相关的律师费的申请，该费用应由第 5 条规定或由法院或仲裁机构判定。
[第 7.1(a) 节的替换文本（适用于政府间机构或政府组织）：
“对于因 TLD 的知识产权所有权、将 TLD 委托给注册管理执行机构、注册管理执行机构运营 TLD 注册管理机构或提供注册管理机构服务而引发的或与之相关的任何第三方索赔、损害赔偿、债务、费用和开支（包括合理法律费用和开支），注册管理执行机构应尽全力与 ICANN 合作以确保 ICANN 不会发生相关成本；但如果索赔、损害赔偿、债务、费用和开支是因 ICANN 违反本协议所含其任何义务或 ICANN 的故意不当行为而产生，则注册管理执行机构没有义务提供此类合作。本节不应视为要求注册管理执行机构向 ICANN偿还或补偿与本协议的协商或执行相关的成本或与监督或管理本协议各方各自的协议义务相关的成本。此外，本节也不适用于与本协议各方之间任何诉讼或仲裁相关的律师费的申请，该费用应由第 5 条规定或由法院或仲裁机构判定。”]
(b) 如果 ICANN 对参与引起索赔的同一行为或疏忽行为的多个注册管理执行机构（包括“注册管理执行机构”）提出补偿要求，注册管理执行机构对 ICANN 关于此类索赔的总补偿金额应限定于 ICANN 索赔总额的一部分（百分比），计算方法：将在 TLD 中注册管理执行机构注册的域名总数（注册域名总数的计算方法应与第 6 条规定的任何适用季度的计算方法一致）除以注册管理执行机构参与的引起索赔的同一行为或疏忽行为所涉及的所有顶级域中的注册域名总数。为了按照第 7.1(b) 节的规定减轻注册管理执行机构按照第 7.1(a) 节应承担的责任，注册管理执行机构应负责确定参与引起索赔的同一行为或疏忽行为的其他注册管理执行机构，并在得到 ICANN 合理认可的前提下证明这些注册管理执行机构存在参与此类行为或疏忽行为的过失。为避免疑义特此说明，如果注册管理执行机构参与了引起索赔的同一行为或疏忽行为，但此注册管理执行机构对于 ICANN 没有以上第 7.1(a) 节中规定的相同或类似的补偿义务，则上一句所述的计算中仍应包括由此类注册管理执行机构管理的域名数量。[说明：此 7.1(b) 节不适用于政府间机构或政府组织。]
7.2 补偿程序。如果发生属于以上第 7.1 节补偿范围的任何第三方索赔，则 ICANN 应尽快通知注册管理执行机构。注册管理执行机构可在自愿的基础上，通过迅速向 ICANN 发出通知而立即接管此类索赔的辩护和调查，并雇用 ICANN 理应接受的律师进行处理和辩护，有关费用和开支全部由注册管理执行机构承担；但无论是什么情况，ICANN 都可以自费控制与 ICANN政策、ICANN 章程或行为的合法性或阐释有关的问题的诉讼。在注册管理执行机构承担费用和开支的情况下，ICANN 应该与注册管理执行机构及其律师在此类索赔和由此产生的任何申诉的调查、审判和辩护中进行一切合理的合作；ICANN 也可以在自费的情况下，通过自身的律师或其他途径参与此类索赔和由此产生的任何申诉的调查、审判和辩护。未经 ICANN 同意，不得达成任何涉及影响到 ICANN 的赔偿的索赔和解，除非需要支付的金额完全由注册管理执行机构补偿。如果注册管理执行机构没有按照本协议第 7.2 节规定对此类索赔辩护取得完全控制权，则 ICANN有权以它认为合适的方式对索赔进行辩护，费用和开支由注册管理执行机构承担，并且注册管理执行机构应对此类辩护给予配合。[说明：此 7.2 节不适用于政府间机构或政府组织。]
7.3 术语定义。在本协议中，除非未来依照“共识性政策”对此类定义进行修改（在此情况下，下列定义应视为依照“共识性政策”的完整精神进行了修订和重申），“安全性”和 “稳定性”的定义如下：
(a) 在本协议中，对“安全性”造成影响是指 (1) 出现未经授权而泄露、篡改、插入或销毁注册数据的情况，或 (2) 遵照所有适用标准运行的系统出现未经授权而访问或泄露互联网信息或资源的情况。
(b) 在本协议中，对“稳定性”造成影响是指 (1) 不符合由信誉卓著、业界公认的互联网标准组织发布的相关权威性适用标准，例如互联网工程任务组 (IETF) 提出的相关标准通道或当前最佳实践意见征求稿（“RFC”），或 (2) 对于遵守由xxxx、业界公认的互联网标准组织发布的相关权威性适用标准（例如 IETF 提出的相关标准通道或当前最佳实践 RFC）并依赖于注册管理执行机构的授权信息或提供的服务而运行的互联网服务器或终端系统，给其吞吐能力、响应时间、一致性或连贯性带来负面影响。
7.4 禁止抵销。不论注册管理执行机构与 ICANN 之间有无悬而未决的纠纷（金钱或其他方面），本协议规定的所有付款应在本协议期限内及时付清。
7.5 控制权变更；转让和分包。任何一方都不得在未经对方书面批准的情况下转让本协议，同时任何一方都不得无理地拒绝批准。尽管有上述规定，如 ICANN 发生重组或再合并， ICANN 可将本协议转让给与组建 ICANN 相同的司法管辖区内且出于相同或基本相同的目的而组建的非营利性公司或相似实体。对于此 7.5 节，对注册管理执行机构控制权的直接或间接变更或者对 TLD 注册管理机构运营的任何实质性分包安排都应被视作转让。如果 ICANN 有合理理由断定获取注册管理执行机构控制权或者接受这种分包安排的个人或实体（或者其所属最终父实体）不满足 ICANN 采用的当时有效的注册管理执行机构的标准或资格，则 ICANN 应被视为已经合理撤消对任何此类控制权的直接或间接变更或分包安排的同意。此外，尽管有上述规定，注册管理执行机构必须至少提前三十 (30) 天将所有重要分包安排通知 ICANN，有关分包部分 TLD 运营业务的协议必须遵守注册管理执行机构在本协议中的所有约款、义务和协议，并且注册管理执行机构将继续受此类约款、义务和协议的约束。在不对上述条款构成限制的前提下，如果预计有任何完成的交易可能导致注册管理执行机构的控制权发生直接或间接变更，注册管理执行机构应在该交易完成前至少三十 (30) 天向 ICANN 发布通知。此类控制权变更通知应包括一项声明，确认获取此控制权一方的最高总部遵守 ICANN 为注册管理执行机构标准制定的规范和政策，并确认注册管理执行机构遵守本协议的义务。在收到此通知三十 (30) 天内，ICANN 可向注册管理执行机构索取更多信息以遵守本协议，对此，注册管理执行机构必须在十五 (15) 天内提供所要求的信息。如果 ICANN 在收到注册管理执行机构发送的有关此类交易的书面通知后三十 (30) 或六十 (60)
（如果 ICANN 依照上述规定要求注册管理执行机构提供更多信息）个日历天内，未能明确表示同意或拒绝注册管理执行机构控制权的直接或间接变更或任何实质性分包安排，则视为 ICANN已同意此类交易。就任何此类交易，注册管理执行机构应遵照注册管理机构过户流程行事。
7.6 修 订 和 弃 权 。
(a) 如果 ICANN 确定对本协议（包括对其中引用的“规范”）以及 ICANN 与适用注册管理执行机构之间的所有其他注册管理机构协议（“适用注册管理机构协议”）的修订
（分别称为“特殊修订”）是必要的，则 ICANN 可以提交一份特殊修订供适用注册管理执行机构依据此 7.6 节中规定的流程进行审批，前提是该特殊修订不是“受限修订”（定义见下文）。在提交特殊修订进行此类审批之前，ICANN 首先应就特殊修订的形式和内容与工作组（定义见下
文）进行诚恳磋商。这种磋商的持续时间应由 ICANN 根据特殊修订的内容合理确定。磋商后， ICANN 可以通过在其网站上公开发布特殊修订不少于三十 (30) 天（“发布期”），并根据第 7.8节的规定将其通知给适用注册管理执行机构，提议采纳该特殊修订。ICANN 将考虑在发布期内针对特殊修订征集到的公众意见，包括由适用注册管理执行机构提交的意见。
(b) 如果在发布期到期后的两 (2) 年内（“审批期”），(i) ICANN 理事会批准了特殊修订（可能与提交以征询公众意见的版本形式不同）并且 (ii) 特殊修订获得“注册管理执行机构批准”（定义见下文），则该特殊修订应被视为已获得适用注册管理执行机构的批准
（“获批修订”）（获得这种批准的最后日期在本协议中称为“修订批准日期”），并且应在 ICANN 向注册管理执行机构发出通知后六十 (60) 天之际（“修订生效日期”）生效并被视为对本协议的修订。如果特殊修订在审批期内没有获得 ICANN 理事会批准或没有获得注册管理执行机构批准，则该特殊修订将不会生效。ICANN 采用的获得注册管理执行机构批准的程序应该设计为记录适用注册管理执行机构的书面批准，可以采用电子形式。
(c) 在修订批准日期之后的三十 (30) 天期限内，注册管理执行机构（前提是它没有投票赞成获批修订）可以书面向 ICANN 申请从“获批修订”豁免（注册管理执行机构提交的每个此类请求特此称为“豁免请求”）。每个豁免请求将说明这种请求的依据，并为从“获批修订”豁免提供详细的支持信息。豁免请求还可以包含对该注册管理执行机构提议的获批修订备选方案或变通方案的详细说明和支持信息。只有当注册管理执行机构明确且令人信服地表明，遵守获批修订会与适用法律发生冲突或者将对注册管理执行机构的长期财务状况或运营绩效产生实质性负面影响时，才应批准豁免请求。如果 ICANN 经过合理的判断认定批准这种豁免请求将对注册人造成实质性损害或导致对注册人直接利益的否决，则不会批准该豁免请求。在 ICANN 收到豁免请求的九十 (90) 天内，ICANN 应该书面批准（可能是有条件的批准或批准获批修订的备选或变通方案）或拒绝该豁免请求，在此期间获批修订不会修订本协议，前提是，任何此类条件、备选或变通方案应在修订生效日期生效，并在适用范围内修订本协议。如果豁免请求获得 ICANN 批准，则获批修订不会修订本协议。如果豁免请求被 ICANN 拒绝，则获批修订将自修订生效日期开始修订本协议（或者，如果该日期已过，应将获批修订视为在被拒绝之日立即生效）；但是，注册管理执行机构可以在收到 ICANN 决定的三十 (30) 天内，根据第 5 条规定的争议解决程序对 ICANN 拒绝豁免请求的决定提出上诉。在争议解决流程进行期间，获批修订将被视为未修订本协议。为避免疑义特此说明，只有注册管理执行机构提交的由 ICANN 根据第 7.6(c)节批准的或根据第 5 条通过仲裁决议批准的豁免请求才应将注册管理执行机构从“获批修订”豁免，而且针对任何其他适用注册管理执行机构批准的豁免请求（无论是通过 ICANN 还是仲裁）均不应对本协议有任何影响或从任何获批修订豁免注册管理执行机构。
(d) 除第 7.6 条规定的情况外，未经协议双方签字生效，本协议的任何修订、补充、更改或这些改动中的任何条款均无约束力，第 7.6 节中的任何内容都不应限制 ICANN 和注册管理执行机构通过仅在双方之间进行的谈判达成对本协议的双边修订和更改。没有任何一方根据本协议的规定可以豁免，除非有明确规定由一个放弃这种权利各方授权代表签署的书面文件。除非弃权方另外明确表示，否则对本协议中任何条款的放弃或未执行本协议中任何条款的事实，均不应视为或构成对本协议中任何其他条款的放弃，也不应构成持续的弃权。为避免疑义特此说明，此 7.6 节中的任何内容均不应视为是对注册管理执行机构遵守第 2.2 节的义务的限制。
(e) 在此 7.6 节中，下列术语的解释如下：
(i) “适用注册管理执行机构”是指包含类似于此 7.6 节条款的注册管理机构协议之顶级域名协议方的注册管理执行机构的总称，涵盖普通注册管理执行机构。
(ii) “注册管理执行机构批准”表示获得以下批准：(A) 根据注册管理机构协议，向 ICANN 支付的款项占所有适用注册管理执行机构在上一年度付给 ICANN 的所有费用（适用时转换为美元）三分之二的适用注册管理执行机构所给予的肯定批准；以及 (B) 获得此类批准时的大多数适用注册管理执行机构的肯定批准。为避免疑义特此说明，关于条款 (B)，每个适用注册管理执行机构应根据适用注册管理机构协议，对由该注册管理执行机构运营的每个顶级域名有一次投票权。
(iii) “受限修订”含义如下：(i) 对规范 1 的修订；(ii) 除本协议第 2.10节中规定的范围之外，规定注册管理执行机构对注册人收取的域名注册费用的修订；(iii) 对规范 6 的第 2.1 节中第一段给出的注册管理机构服务定义的修订；(iv)对期限时间长度的修订。
(iv) “工作组”是指适用注册管理执行机构的代表和 ICANN 指派的其他机构群体成员，作为工作组为适用注册管理机构协议的修订（不含根据第 7.6(d)节进行的双边修订）提供咨询。
7.7 无第三方受益人。本协议不应解释为 ICANN 或注册管理执行机构给本协议之外的任何一方（包括任何注册服务商或已注册名称持有人）施加任何义务。
7.8 一般通知。除了根据第 7.6 节规定做出的通知，有关本协议的所有通知的发送形式为：(i) 按照下面列出的地址以书面形式发往相应当事方；或 (ii) 按照下面提供的传真号码或电子邮件地址发出。除非相应当事方已通知变更邮政地址、电子邮件地址或传真号码，否则将按照本协议提供的下列地址或传真号码发送有关本协议的所有通知。应通过在 ICANN 的网站上发布相关信息，并通过电子邮件将此类信息发送至注册管理执行机构，来发布第 7.6 节规定的所有通知。如一方要更改下文的通知联系信息，必须在此类变更发生后三十 (30) 天内通知对方。根据本协议发出的所有通知、任命、决议和说明均以英语书写。除根据第 7.6 节规定做出的通知以外，在下列情况中，本协议要求的任何通知都将视为已适当提供：(i) 如果是纸面通知，当面递送或通过快递服务递送并收到送达确认；(ii) 如果是传真或电子邮件形式的通知，收到接收方传真机或电子邮件服务器的送达确认，但前提是，通过传真或电子邮件传送通知后应在两 (2) 个工作日之内由正常邮递服务传送一份副本。对于第 7.6 节要求的任何通知，如果在 ICANN 网站上以电子形式发布并收到电子邮件服务器送达确认，均应视为已适当提供。如果有切实可行的其他通知方式，例如通过安全网站发布通知，双方将按本协议合作实施此类通知方式。
ICANN 的通信地址如下：
Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330
Marina Del Rey, California 90292
电话：0-000-000-0000传真：0-000-000-0000
收件人：President and CEO
同时必须将副本送至：General Counsel
电子邮件：（按当时的指定地址。）
注册管理执行机构的通信地址如下：
[ ]
[ ]
[ ]
电话： 传真： 收件人：
同时必须将副本送至：
电子邮件：（按当时的指定地址。）
7.9 协议完整性。本协议（包括通过引用本协议中的 URL 地址而并入的规范和文档）构成双方就 TLD 的运营而达成的完整协议，取代双方此前在该问题上的所有口头或书面协议、谅解、谈判和讨论。
7.10 英语语言约束。虽然注册管理执行机构可能会收到本协议（和/或规范）的翻译版本，但本协议（及其所有引用规范）的英语版是约束协议双方的正式版本。如果本协议的任何翻译版本和英语版本存在冲突或差异，则以英语版本为准。所有根据本协议发出的通知、任命、决议和说明均以英语书写。
7.11 所有权。本协议中的任何内容均不应解释为确立或授予注册管理执行机构对 TLD
或 TLD 文本字符串中包含的字母、单词、符号或其他字符具有任何资产所有权或相关利益。
7.12 可分割条款。本协议应视为可分割；本协议任何条款的无效或不可执行，不影响本协议其他部分或本协议任何其他条款的效力或执行，它们具有完全的执行力和效力。如果本协议任何条款被确定为无效或不可执行，协议各方应真诚协商来修改此协议，以便尽量接近各方的原意。
7.13 法院命令。ICANN 尊重具有效司法管辖权的法院发出的任何命令，包括来自需要政府赞成或无异议才可授权 TLD 的任何司法管辖区的法院命令。不论本协议其他条款如何规定， ICANN 执行任何此类法院命令均不构成违反本协议。
[说明：下节仅适用于政府间机构或政府组织。]
7.14 关于政府间机构或政府组织的特殊条款。
(a) ICANN 承认注册管理执行机构是受公共国际法律制约的实体，包括适用于注册管理执行机构的国际条约（此类公共国际法律和条约以下统称“适用法律”）。本协议中的任何内容均不应解读或解释为要求注册管理执行机构违反适用法律或阻止其遵守这些法律。各方同意，注册管理执行机构对适用法律的遵守不应构成对本协议的违反。
(b) 如果注册管理执行机构合理认定本协议的任何条款及其相关规范或者本协议中引用的任何 ICANN 决策或政策，包括但不限于临时政策和共识性政策（此类条款、规范和政策以下统称“ICANN 要求”），可能违反适用法律或与之发生冲突（以下称“潜在冲突”），则注册管理执行机构应尽早向 ICANN 提供此类潜在冲突的详细声明（以下称“声明”），而且若与提议的共识性政策之间存在潜在冲突，不得晚于该共识性政策的任何公众意见征询期结束日。如果注册管理执行机构认定在提议的适用法律与任何 ICANN 要求之间存在潜在冲突，则注册管理执行机构应尽早向 ICANN 提供此类潜在冲突的详细声明，而且若与提议的共识性政策之间存在潜在冲突，不得晚于该共识性政策的任何公众意见征询期结束日。
(c) 在此类审核后，各方应尽早根据第 5.1 节中规定的程序，共同协作努力解决潜在冲突。此外，注册管理执行机构应尽全力消除或尽量消除因这种适用法律与 ICANN 要求之间的潜在冲突而导致的任何影响。如果在协作努力解决冲突后，注册管理执行机构仍认定潜在冲突构成一端的任何 ICANN 要求与另一端的适用法律之间的实际冲突，则 ICANN 应放弃要求遵守此类 ICANN 要求（前提是各方应在之后不断诚意地协商以减小或消除由此对 ICANN 带来的影响），除非 ICANN 合理并客观认定注册管理执行机构不遵守此类 ICANN 要求将对注册管理机构服务、互联网或 DNS 的安全和稳定构成威胁（以下称“ICANN 决议”）。在注册管理执行机构收到此类 ICANN 决议后，注册管理执行机构应获得为期九十 (90) 天的宽限期来解决与适用法律之间的这种冲突。如果在此期间与适用法律之间冲突的解决未能使 ICANN 完全满意，则注册管理执行机构有权在此后十 (10) 天内提交该问题进行具有约束力的仲裁，如下面的子节 (d) 中所定义。如果在此期间，注册管理执行机构没有依据下述子节 (d) 提交问题进行仲裁，ICANN 可以在通知注册管理执行机构后立即终止本协议。
(d) 如果注册管理执行机构不同意某项 ICANN 决议，则注册管理执行机构可以依据第 5.2 节的条款提交该问题进行有约束力的仲裁，除非提交给仲裁机构进行裁决的唯一问题是 ICANN 是否合理且客观地作出该 ICANN 决议。对于此类仲裁，ICANN 应向仲裁机构提交证据来支持 ICANN 决议。如果仲裁机构判定 ICANN 未能合理且客观地作出 ICANN 决议，则 ICANN 应放弃要求注册管理执行机构遵守相关 ICANN 要求。如果仲裁机构或仲裁前调停机构
（如适用）判定 ICANN 确实合理且客观地作出 ICANN 决议，则在通知注册管理执行机构后，
ICANN 可以立即终止本协议。
(e) 注册管理执行机构特此声明并保证，根据其全部所知，截至本协议执行日期，任何现有 ICANN 要求均不违反任何适用法律或与之发生冲突。
(f) 无论此 7.14 节中任何其他条款如何规定，在 ICANN 决议出台之后、仲裁机构依据上述第 7.14(d) 节做出裁定之前，ICANN 可以在事先与注册管理执行机构商议的前提下，采取此类其认为有必要的合理技术措施来确保注册管理机构服务、互联网和 DNS 的安全与稳定。这些合理的技术措施应由 ICANN 临时执行，直到上述第 7.14(d) 节中规定的仲裁程序生成判决之日或完全解决与适用法律间冲突之日为止，以两者中较早的日期为准。若注册管理执行机构不同意 ICANN 采取的此类技术措施，注册管理执行机构可以依据上述第 5.2 节条款提交问题进行有约束力的仲裁，在此过程中 ICANN 可以继续执行此类技术措施。x ICANN 执行此类措施，则注册管理执行机构应支付 ICANN 为此付出的所有费用。此外，x ICANN 执行此类措施，ICANN应该保留并可执行其依据“持续运营法律文书”和其他法律文书（如果适用）应享有的权利。
* * * * *
双方兹派其正式授权代表签署本协议，特此为证。互联网名称与数字地址分配机构
代表：
[ ]
总裁兼首席执行官
日期：
[注册管理执行机构]
代表：
[ ]
[ ]
日期：
附录 A
批准的服务
规范 1
合意政策和临时政策规范
1. 合 意 政 策 。
1.1. “合意政策”是指根据以下条件制定的政策：(1) 遵循互联网名称与数字地址分配机构 (ICANN)章程中规定的程序和正当流程；(2) 涵盖本文档第 1.2 节中列出的主题。ICANN 章程中规定的 有关制定合意政策的流程和程序，随时可能根据此处规定的流程进行修订。
1.2. 合意政策和制定这些政策的程序应旨在允许的范围内，使各个互联网利益主体（包括通用顶级域名 [gTLD] 运营商）达成一致的意见。合意政策应与以下一项或多项内容有关：
1.2.1. 为提高互联网或域名系统（以下简称“DNS”）的互操作性、安全性和/或稳定性，必须采取统一或协调的解决方案的问题；
1.2.2. 有关提供注册服务的职能和履行规范；
1.2.3. 顶级域名(TLD) 注册数据库的安全性和稳定性；
1.2.4. 为实施与注册机构运营或注册商相关的合意政策而必需的合理注册政策；
1.2.5. 解决与域名注册相关的争议（不同于此类域名的使用）；或
1.2.6. 对注册机构运营商和注册商或注册商分销商交叉持股的限制，以及有关注册机构运营和注册机构和注册商数据使用（在注册机构运营商和注册商或注册商分销商联营的情况下）的规定和限制。
1.3. 本文第 1.2 节中提到的此类问题应包括但不限于：
1.3.1. 用于分配TLD 中已注册名称的原则（例如先到先得、及时续签、过期后仍然持有）；
1.3.2. 禁止注册机构或注册商对域名进行囤积或投机；
1.3.3. 保留最初不能注册或由于与下列因素相关的合理原因而不能续签的TLD 中的已注册名称：(i) 避免用户混淆或对用户产生误导；(ii) 知识产权；或 (iii) DNS 或互联网的技术管理（例如注册时即确立对名称的保留）；以及
1.3.4. 与域名注册相关的最新准确信息的维护与访问；避免因注册运营商或注册商暂停或终止运营而中断域名注册的程序，包括为TLD 中受此类暂停或终止运营影响的已注册域名提供服务的责任分配程序。
1.4. 除对合意政策的其他限制外，这些政策不应：
1.4.1. 规定或限制注册服务的价格；
1.4.2. 修改续签或终止注册协议的条款或条件；
1.4.3. 修改对临时政策（见下文定义）或合意政策的限制；
1.4.4. 修改注册协议中有关注册机构运营商向互联网名称与数字地址分配机构 (ICANN) 支付费用的规定；或
1.4.5. 修改互联网名称与数字地址分配机构 (ICANN) 责任，以确保注册机构运营商的公平待遇，并以公开透明的方式行使职责。
2. 临时政策。对于董事会临时确立、并由董事会中至少三分之二的成员表决通过的所有规范或政策，只要董事会有理由确定此类修改或修订是正当的，并且就相关问题立即确立的临时性规范或政策对于维护注册服务或域名系统 (DNS) 的稳定性或安全性具有不可或缺的作用，注册机构运营商就应当遵守并予以实施（以下简称“临时政策”）。
2.1. 此类建议的规范或政策应尽可能细化，以实现相应的目标。在确立任何临时政策时，董事会应说明采用临时政策的持续时间，并应立即实施 ICANN 章程中规定的合意政策制定流程。
2.1.1. ICANN 还应发表咨询声明，详细阐明采用临时政策的原因，以及董事会为何认为此类临时政策会得到互联网利益主体的一致同意。
2.1.2. 如果采用临时政策的持续时间超过 90 天，董事会应每 90 天重申暂时采用该临时政 策，总持续时间不得超过 1 年，以使此类临时政策在上述期限内始终有效，直到成为合意政策时为止。如果持续时间超过 1 年，或者如果在此 1 年内，临时政策没有成为合意政策，并且董事会没有重申采用该政策，则注册运营商不再需要遵守或实施此类临时政策。
3. 通知和冲突。考虑到可能存在的紧急情况，注册机构运营商在收到确立合意政策或临时政策的通知后，应获得一段合理的时间来逐步适应此类政策或规范。如果注册服务与合意政策或任何临时政策发生冲突，应以合意政策或临时政策为准，但仅限于发生冲突的情况。
规范 2
数据托管要求
注册运营商将根据与注册协议相关的数据托管服务的规定，指定某一独立实体作为数据托管代理
（以下简称“托管代理”）。注册运营商与托管代理之间达成的任何数据托管协议，均应包含以下第一部分中规定的技术规范以及第二部分中规定的法律要求，并且必须将互联网名称与数字地址分配机构 (ICANN) 认定为第三方受益人。除以下要求外，数据托管协议还可以包含其他规定，但这些规定不能破坏下面提供的必要条款，或与这些条款相抵触。
第一部分– 技术规范
1. 寄存。将有两种类型的寄存：完全寄存和差别寄存。对于这两种类型，要考虑进行数据托管的全体注册对象是指那些提供所有已获批准的注册服务所必需的对象。
1.1 “完全寄存”将包括反映截止到每个星期日的 00:00:00（世界标准时间，UTC）为止的注册机构状态的数据。在此时刻的未决交易（即尚未提交的交易）不会反映在完全寄存中。
1.2 “差别寄存”是指符合以下条件的数据：反映未反映在上一个完全寄存或差别寄存（视具体情况而定）中的所有交易。每个差别寄存都将包含自上一个寄存完成时起至每天（星期日除 外）00:00:00（世界标准时间，UTC）为止的所有数据库交易。差别寄存必须包括自进行最新完全寄存或差别寄存后未包括的或已更改的完整托管记录（即新添加或修改的域名），见以下规定。
2. 寄存时间表。注册机构运营商将根据以下要求每日提交一组托管文件：
2.1 每个星期日，必须在 23:59（世界标准时间，UTC）之前将完全寄存提交给托管代理。
2.2 在一周的其余六天，必须在 23:59（世界标准时间，UTC）之前将相应的差别寄存提交给托管代理。
3. 托 管 格 式 规 范 。
3.1 寄存格式。注册对象（例如域、联系人、名称服务器、注册商等）将被编入一个文件中，该文件结构如draft-arias-noguchi-registry-data-escrow 中所述，请参见[1]。上述文件将一些要素描述为可选要素；注册机构运营商将在寄存中包括这些要素（如果有）。如果还不是评议请求 (RFC)，则注册机构运营商将使用签署协议时提供的初稿。将规范发布成评议请求 (RFC) 后，注册机构运营商将在此后 180 天内实施该规范。将使用 UTF-8 字符编码。
3.2 扩展。如果注册机构运营商提供了需要提交上述数据之外的其他数据的其他注册服务，应根据具体情况定义其他“扩展模式”来代表这些数据。这些“扩展模式”将按 [1] 中所述进行指定。与“扩展模式”相关的数据将包括在第 3.1 款中所述的寄存文件中。互联网名称与数字地址分配机构 (ICANN) 和各个注册机构应通力合作，以达成此类新对象的数据托管规范。
4. 寄存文件的处理。建议使用压缩，以缩短电子数据传输时间，并减少需要的存储容量。将使用数据加密来确保注册机构托管数据的隐私性。根据 OpenPGP 消息格式- 评议请求 (RFC) 4880，进行压缩和加密的文件将为二进制 OpenPGP 格式，请参见[2]。公钥密码系统、对称密钥密码系统、哈希和压缩的可接受算法为评议请求 (RFC) 4880 中列举的算法，这些算法在 OpenPGP 互联网号码分配当局 (IANA) 注册机构中未被标记为过时（请参见[3]），而且这些算法是免版权税的。原始文本格式的数据文件的流程为：
(1) 文件应进行压缩。根据RFC 4880，建议的压缩算法为 ZIP。
(2) 将使用托管代理的公钥对压缩的数据进行加密。根据RFC 4880，建议的公钥加密算法为 Elgamal 和RSA。根据RFC 4880，建议的对称密钥算法为 TripleDES、AES128 和 CAST5。
(3) 如果文件在经过压缩和加密后超过托管代理所认可的文件大小限制，则可在必要时拆分文件。拆分文件的每部分或整个文件（如果未进行拆分）在本款中都称为已处理文件。
(4) 将使用注册机构的私钥为每个已处理的文件生成数字签名文件。根据评议请求 (RFC) 4880 [2]，数字签名文件将为二进制 OpenPGP 格式，且不会被压缩或加密。根据RFC 4880，建议的数字签名算法为 DSA 和RSA。数字签名xxx的建议算法是 SHA256。
(5) 然后，将根据托管代理和注册机构运营商之间达成的协议，通过安全电子机制（例如， SFTP、SCP、HTTPS 文件上传等）将已处理的文件和数字签名文件传输给托管代理。如果经过互联网名称与数字地址分配机构 (ICANN) 授权，也可以通过物理介质（例如 CD-
ROM、DVD-ROM 或USB 存储设备）实现非电子方式的交付。
(6) 随后，托管代理将使用第8 款中所述的程序验证每个已传输（已处理）的数据文件。
5. 文件命名规则。将根据以下规则命名文件：
{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext}，其中：
5.1 {gTLD} 将替换为通用顶级域 (gTLD) 的名称；如果是国际化域名顶级域名 (IDN – TLD)，则必须使用与ASCII 兼容的格式（A 标签）；
5.2 {YYYY-MM-DD} 将替换为与用作交易的时间线水印的时间相对应的日期；即，对于与 2009- 08-02T00:00Z 相对应的完全寄存，要使用的字符串为“2009-08-02”；
5.3 {type} 将被替换为：
(1) “full”（如果数据代表完全寄存）；
(2) “diff”（如果数据代表差别寄存）；
(3) “thin”（如果数据代表批量注册数据访问文件，如规范 4 的第 3 款中指定）；
5.4 {#} 将被替换为文件在一系列文件中的位置，以“1”开头；如果只有一个文件，则必须替换为“1”。
5.5 {rev} 将被替换为以“0”开头的文件的修订（或重新发送）号：
5.6 {ext} 将被替换为“sig”（如果它是与quasi 同名的文件的数字签名文件）。否则，它将被替换为“ryde”。
6. 公钥的分发。每个注册运营商和托管代理均应按照指定的电子邮件地址将其公钥分发给另一方（注册运营商或托管代理，根据具体情况而定）。各方应该通过回复电子邮件确认收到另一方的公钥，分发方随后将重新确认通过离线方法（例如个人会议、电话等）传输的密钥的真实性。通过这种方式，公钥传输经过验证，用户可以通过分发方运营的邮件服务器发送和接收邮件。托管代理、注册机构和互联网名称与数字地址分配机构 (ICANN) 将按照相同程序交换密钥。
7. 寄存通知。注册运营商每提交一个寄存，都必须同时向托管代理和互联网名称与数字地址分配机构 (ICANN) 提交一份书面声明（可以通过经验证的电子邮件提交），其中要包含一份在创建寄存时生成的报告，并声明该寄存已经注册运营商检查，是完整而准确的。注册机构运营商将在其报表中包括寄存的“ID”和“重新发送”属性。这两个属性在 [1] 中进行了说明。
8. 验 证 程 序 。
(1) 验证每个已处理文件的签名文件。
(2) 如果已处理文件属于某较大文件，则将后者放到一起。
(3) 然后解密上一步骤中所得的每个文件并解压缩。
(4) 再根据[1] 中定义的格式，验证上一个步骤中所包含的每个数据文件。
(5) 如果[1] 包括验证流程，将会在此步骤中应用该流程。
如果在上述任何步骤中发现任何差异，则寄存将被视为不完整。
9. 参 考 资 料 。
[1] 域名数据托管规范（工作正在进行当中），
xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxxxxxx-xxxx-xxxxxx
[2] OpenPGP 消息格式，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[3] OpenPGP 参数，xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx-xxxxxxxxxx/xxx-xxxxxxxxxx.xxxxx
第二部分– 法律要求
1. 托管代理。注册机构运营商在签署托管协议前，必须以托管代理的身份向互联网名称与数字地址分配机构 (ICANN) 发出通知，同时向互联网名称与数字地址分配机构(ICANN) 提供联系信息、一份相关托管协议的副本，以及该协议的所有修正。此外，注册机构运营商在签署托管协议前，必须取得互联网名称与数字地址分配机构 (ICANN) 的同意来进行以下活动：(a) 使用指定的托管代理，并 (b) 签署提供的托管协议表单。必须向互联网名称与数字地址分配机构 (ICANN) 明确指定托管协议的第三方受益人。互联网名称与数字地址分配机构 (ICANN) 保留同意任何托管代理、托管协议或该协议的任何修正的权利，一切皆由其自行决定。
2. 费用。注册运营商必须直接或让其代表代为向托管代理付费。如果注册运营商未能在截止日期前付清任何费用，托管代理将向互联网名称与数字地址分配机构 (ICANN) 发出有关此类未付费情况的书面通知，而互联网名称与数字地址分配机构 (ICANN) 可在收到托管代理的书面通知后十个工作日内支付过期未付费用。在互联网名称与数字地址分配机构 (ICANN) 支付过期未付费用后，互联网名称与数字地址分配机构 (ICANN) 应向注册运营商索要该笔费用，而注册运营商必须将该笔费用连同按注册协议需交纳的下一笔费用提交给互联网名称与数字地址分配机构 (ICANN)。
3. 所有权。在托管协议有效期内，寄存的所有权将始终归注册运营商所有。因此，注册运营商应将此类寄存中的所有此类所有权（包括知识产权，视具体情况而定）转让给互联网名称与数字地址分配机构 (ICANN)。如果在注册协议有效期内将任何寄存从托管代理转让给互联网名称与数字地址分配机构 (ICANN)，则注册运营商在寄存中享有的任何知识产权都将自动以非独占、永久、不可撤消、免版税和xxx款的方式许可给互联网名称与数字地址分配机构 (ICANN) 或互联网名称与数字地址分配机构 (ICANN) 书面指定的一方。
4. 完整性和保密性。托管代理必须：(i) 将寄存保管于安全、经锁定和对环境安全的设施内，且只能由托管代理的授权代表访问；(ii) 使用在商业上合理的措施保护寄存的完整性和保密
性，并 (iii) 保留和保护每个寄存一年时间。互联网名称与数字地址分配机构 (ICANN) 和注册运营商将有权检查托管代理的相应记录，但此类检查应有事先的合理通知，并且须在正常工作时间进行。注册机构运营商和互联网名称与数字地址分配机构 (ICANN) 将有权指定第三方审计师，来不时审核托管代理是否符合此“规范 2”的技术规范和维护要求。
如果托管代理收到法院或其他仲裁法庭的有关寄存披露或转让的传票或任何其他指令，则托管代理将立即通知托管运营商和互联网名称与数字地址分配机构 (ICANN)，除非法律禁止其通知。通知注册运营商和互联网名称与数字地址分配机构 (ICANN) 后，托管代理应给予注册运营商或互联网名称与数字地址分配机构 (ICANN) 足够的时间来对任何此类指令提出异议，这应当是注册运营商或互联网名称与数字地址分配机构 (ICANN) 的责任，但前提是托管代理不放弃其在此类指令中阐明其立场的权利。托管代理将与注册运营商或互联网名称与数字地址分配机构 (ICANN) 通力合作以支持撤消或限制任何传讯的工作，所需费用由各方自行承
担。任何一方如申请其他协助，则应向支付托管代理的标准费用或在提交具体申请后根据报价支付相关费用。
5. 副本。为了遵守托管协议的条款和规定，托管代理可以复制任何寄存。
6. 寄存的转让。如果托管代理收到注册机构运营商有关影响此类交付（向互联网名称与数字地址分配机构[ICANN] 交付）的请求，或收到互联网名称与数字地址分配机构 (ICANN) 声明下列情况之一的书面通知，则托管代理应在二十四小时内提供给互联网名称与数字地址分配机构 (ICANN) 或其指定方进行电子下载（除非另有要求）：
6.1 注册协议已到期且未续约，或者注册协议已终止；或
6.2 在有关 (a) 任何完全寄存或(b) 任一日历月内的五个差别寄存的预定交付日期过后，互联网名称与数字地址分配机构 (ICANN) 未在五个日历日内收到托管代理的接收通知；并且(x) 互联网名称与数字地址分配机构 (ICANN) 已向托管代理和注册机构运营商通知该情况；且 (y) 互联网名称与数字地址分配机构 (ICANN) 未在发出此类通知后七个日历日内收到托管代理声明收到寄存的通知；或
6.3 互联网名称与数字地址分配机构 (ICANN) 已收到托管代理关于某一完全寄存验证失败或任一日历月内的五个差别寄存验证失败的通知，并且 (a) 互联网名称与数字地址分配机构(ICANN)已将该情况通知注册机构运营商；而 (b) 互联网名称与数字地址分配机构(ICANN) 未在发出此类通知后七个日历日内收到托管代理有关这类完全寄存或差别寄存修正版本验证情况的通 知；或
6.4 注册运营商已：(i) 停止经营其正常业务；或 (ii) 申请破产、无力偿债或按世界上任何地区的任何法律管辖范围的法律而处于与上述情况类似的状态；或
6.5 注册运营商无法执行其关键的注册职能，且互联网名称与数字地址分配机构 (ICANN) 已根据注册协议第 2.13 款声明其权利；或
6.6 具备有效管辖权的法院、仲裁机构、立法机构或政府部门命令将寄存让渡给ICANN。
除非托管代理事先已将注册运营商的寄存转让给互联网名称与数字地址分配机构 (ICANN) 或其指定方，否则托管代理应将在注册协议或托管协议到期时将所有寄存交付给互联网名称与数字地址分配机构 (ICANN)。
7. 寄 存 的 验 证 。
7.1 在收到每个寄存或已修正寄存后的二十四小时内，托管代理必须验证每个寄存的格式和完整性，并向互联网名称与数字地址分配机构 (ICANN) 交付一份为每个寄存生成的验证报告副本。报告将按照互联网名称与数字地址分配机构 (ICANN) 的不时指定，以电子方式进行交付。
7.2 如果托管代理发现有任何寄存未通过验证程序，托管代理必须在收到不合格寄存二十四小时 x，以电子邮件、传真或电话形式，向注册机构运营商和互联网名称与数字地址分配机构 (ICANN) 通报此类情况。注册运营商在获悉此类验证失败的情况时，必须开始开发寄存的修改、更新、修正和其他修补程序，以使寄存能够通过验证程序，并将此类修补程序尽快提交给托管代理。
8. 修正。托管代理和注册运营商应在此规范2 出现任何修正或修改起的十(10) 个日历日内修订托管协议的条款，以符合此规范2。如果本规范2 与托管协议有冲突，则以本规范2 为准。
9. 赔偿义务。对于第三方就托管协议的相关事项、托管代理或其各董事、高级职员、代理、员工、成员和股东执行（统称“托管代理受偿方”）托管协议的相关事项，而提出的任何索 赔、诉讼、损害、责任、义务、成本、费用和任何其他支出，包括合理的律师费用，注册运营商应绝对且永久地对托管代理及托管代理受偿方做出赔偿并使其免受损害，但由于托管代理及其董事、高级职员、代理、员工、订约方、成员和股东错误xx、疏忽或错误执行托管协议而引起的任何索赔除外。对于第三方就托管代理、其董事、高级职员、代理、员工和订约方错误xx、疏忽或错误执行而提出的任何索赔、诉讼、损害、责任、义务、成本、费用和任何其他支出，包括合理的律师费用，托管代理应绝对且永久地对注册运营商和互联网名称与数字地址分配机构(ICANN) 以及其各自的董事、高级职员、代理、员工、成员和股东（统称
“受偿方”）做出赔偿并使其免受损害。
规范 3
注册运营商月度报告的格式和内容
注册机构运营商应针对每个通用顶级域名 (gTLD) 向 呈报一套含下列内容的月度报告。互联网名称与数字地址分配机构 (ICANN) 今后可能要求以其他方式和其他格式提交报告。 ICANN 将采取合理商业手段为报告信息保密，保密期限至报告涉及月份结束三个月后。
1. 每个注册商交易报告。该报告应汇编到评议请求 (RFC) 4180 规定的逗号分隔值格式的文件中。文件应命名为“gTLD-transactions-yyyymm.csv”，其中“gTLD”为通用顶级域名 (gTLD) 名称；如果是国际化域名顶级域名 (IDN-TLD)，则应使用 A 标签；“yyyymm”是报告的年份和月份。对于每个注册商，文件应包含以下字段：
字段号 | 字段名称 | 说明 |
01 | registrar-name | 在互联网号码分配当局 (IANA) 注册的注册商公司全称 |
02 | iana-id | |
03 | total-domains | 合计赞助域数量 |
04 | total-nameservers | 注册顶级域名(TLD) 的名称服务器总数 |
05 | net-adds-1-yr | 在最初一年期限内成功注册的域数量（在追加宽限期内未删除） |
06 | net-adds-2-yr | 在最初两年期限内成功注册的域数量（在追加宽限期内未删除） |
07 | net-adds-3-yr | 在最初三年期限内成功注册的域数量（在追加宽限期内未删除） |
08 | net-adds-4-yr | 在最初四年期限内成功注册的域数量（在追加宽限期内未删除） |
09 | net-adds-5-yr | 在最初五年期限内成功注册的域数量（在追加宽限期内未删除） |
10 | net-adds-6-yr | 在最初六年期限内成功注册的域数量（在追加宽限期内未删除） |
11 | net-adds-7-yr | 在最初七年期限内成功注册的域数量（在追加宽限期内未删除） |
12 | net-adds-8-yr | 在最初八年期限内成功注册的域数量（在追加宽限期内未删除） |
13 | net-adds-9-yr | 在最初九年期限内成功注册的域数量（在追加宽限期内未删除） |
14 | net-adds-10-yr | 在最初十年期限内成功注册的域数量（在追加宽限期内未删除） |
15 | net-renews-1-yr | 在新的一年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
16 | net-renews-2-yr | 在新的两年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
17 | net-renews-3-yr | 在新的三年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
18 | net-renews-4-yr | 在新的四年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
19 | net-renews-5-yr | 在新的五年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
20 | net-renews-6-yr | 在新的六年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
21 | net-renews-7-yr | 在新的七年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
22 | net-renews-8-yr | 在新的八年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
23 | net-renews-9-yr | 在新的九年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
24 | net-renews-10-yr | 在新的十年续签期内自动或通过命令成功续签的域数量（在续签宽限期内未删除） |
25 | transfer-gaining-successful | 此注册商发起并由其他注册商通过命令或自动承认的转让 |
26 | transfer-gaining-nacked | 此注册商发起并被其他注册商否认的转让 |
27 | transfer-losing-successful | 另一注册商发起并由此注册商通过命令或自动承认的转让 |
28 | transfer-losing-nacked | 另一注册商发起并被此注册商否认的转让 |
29 | transfer-disputed-won | 此注册商胜诉的转让纠纷次数 |
30 | transfer-disputed-lost | 此注册商败诉的转让纠纷次数 |
31 | transfer-disputed-nodecision | 牵涉到此注册商的分拆或无结果的转让纠纷次数 |
32 | deleted-domains-grace | 在追加宽限期内删除的域 |
33 | deleted-domains-nograce | 在追加宽限期外删除的域 |
34 | restored-domains | 从赎回期恢复的域名 |
35 | restored-noreport | 注册商未能提交有关恢复报告的恢复名称总数 |
36 | agp-exemption-requests | 追加宽限期 (AGP) 豁免请求总数 |
37 | agp-exemptions-granted | 批准的追加宽限期 (AGP) 豁免请求总数 |
38 | agp-exempted-domains | 受批准的追加宽限期 (AGP) 豁免请求影响的名称总数 |
39 | attempted-adds | 尝试域名创建命令（无论成功与否）的次数 |
作为评议请求(RFC) 4180 第 2 款规定的“标题行”，第一行应包含与上表所述名称完全相符的字段名称。每份报告的最后一行应包含每列的所有注册商合计；此行的第一个字段应为“合计”，第二个字段应留空。除上述行之外，不得包含任何其他行。根据评议请求 (RFC) 4180 的规定，换行符应为 <U+000D, U+000A>。
2. 注册功能活动报告。该报告应汇编到评议请求 (RFC) 4180 规定的逗号分隔值格式的文件中。文件应命名为“gTLD-transactions-yyyymm.csv”，其中“gTLD”为通用顶级域名 (gTLD) 名称；如果是国际化域名顶级域名 (IDN-TLD)，则应使用 A 标签；“yyyymm”是报告的年份和月份。文件应包含以下字段：
字段号 | 字段名称 | 说明 |
01 | operational-registrars | 报告期末运营注册商的数量 |
02 | ramp-up-registrars | 报告期末收到访问OT&E 密码的注册商数量 |
03 | pre-ramp-up-registrars | 报告期末已要求访问但尚未进入线程创建期的注册商数量 |
04 | zfa-passwords | 报告期末激活区域文件访问密码的数量 |
05 | whois-43-queries | 报告期内已响应WHOIS（端口 43）查询的数量 |
06 | web-whois-queries | 报告期内已响应基于网络的Whois（不含可搜索的Whois）查询的数量 |
07 | searchable-whois-queries | 报告期内已响应可搜索Whois 查询（如有）的数量 |
08 | dns-udp-queries-received | 报告期内通过UDP 传输收到的DNS 查询的数量 |
09 | dns-udp-queries-responded | 报告期内通过UDP 传输收到的已响应DNS 查询的数量 |
10 | dns-tcp-queries-received | 报告期内通过 TCP 传输收到的DNS 查询的数量 |
11 | dns-tcp-queries-responded | 报告期内通过 TCP 传输收到的已响应DNS 查询的数量 |
12 | srs-dom-check | 报告期内已响应域名“检查”要求的 SRS（EPP 及其他接口）数量 |
13 | srs-dom-create | 报告期内已响应域名“创建”要求的 SRS（EPP 及其他接口）数量 |
14 | srs-dom-delete | 报告期内已响应域名“删除”要求的 SRS（EPP 及其他接口）数量 |
15 | srs-dom-info | 报告期内已响应域名“信息”要求的 SRS（EPP 及其他接口）数量 |
16 | srs-dom-renew | 报告期内已响应域名“更新”要求的 SRS（EPP 及其他接口）数量 |
17 | srs-dom-rgp-restore-report | 报告期内已响应域名RGP“恢复”要求的 SRS（EPP 及其他接口）数量 |
18 | srs-dom-rgp-restore-request | 报告期内已响应域名RGP“恢复”要求并出具恢复报告的 SRS（EPP 及其他接口）数量 |
19 | srs-dom-transfer-approve | 报告期内已响应域名“转让”要求并批准转让的 SRS （EPP 及其他接口）数量 |
20 | srs-dom-transfer-cancel | 报告期内已响应域名“转让”要求并取消转让的 SRS （EPP 及其他接口）数量 |
21 | srs-dom-transfer-query | 报告期内已响应域名“转让”要求并对转让进行查询的 SRS（EPP 及其他接口）数量 |
22 | srs-dom-transfer-reject | 报告期内已响应域名“转让”要求并拒绝转让的 SRS （EPP 及其他接口）数量 |
23 | srs-dom-transfer-request | 报告期内已响应域名“转让”要求并要求转让的 SRS （EPP 及其他接口）数量 |
24 | srs-dom-update | 报告期内已响应域名“升级”要求（不含RGP 恢复要求）的 SRS（EPP 及其他接口）数量 |
25 | srs-host-check | 报告期内已响应主机“检查”要求的 SRS（EPP 及其他接口）数量 |
26 | srs-host-create | 报告期内已响应主机“创建”要求的 SRS（EPP 及其他接口）数量 |
27 | srs-host-delete | 报告期内已响应主机“删除”要求的 SRS（EPP 及其他接口）数量 |
28 | srs-host-info | 报告期内已响应主机“信息”要求的 SRS（EPP 及其他接口）数量 |
29 | srs-host-update | 报告期内已响应主机“升级”要求的 SRS（EPP 及其他接口）数量 |
30 | srs-cont-check | 报告期内已响应联系人“检查”要求的 SRS（EPP 及其他接口）数量 |
31 | srs-cont-create | 报告期内已响应联系人“创建”要求的 SRS（EPP 及其他接口）数量 |
32 | srs-cont-delete | 报告期内已响应联系人“删除”要求的 SRS（EPP 及其他接口）数量 |
33 | srs-cont-info | 报告期内已响应联系人“信息”要求的 SRS（EPP 及其他接口）数量 |
34 | srs-cont-transfer-approve | 报告期内已响应联系人“转让”要求并批准转让的 SRS（EPP 及其他接口）数量 |
35 | srs-cont-transfer-cancel | 报告期内已响应联系人“转让”要求并取消转让的 SRS（EPP 及其他接口）数量 |
36 | srs-cont-transfer-query | 报告期内已响应联系人“转让”要求并对转让进行查询的 SRS（EPP 及其他接口）数量 |
37 | srs-cont-transfer-reject | 报告期内已响应联系人“转让”要求并拒绝转让的 SRS（EPP 及其他接口）数量 |
38 | srs-cont-transfer-request | 报告期内已响应联系人“转让”要求并要求转让的 SRS（EPP 及其他接口）数量 |
39 | srs-cont-update | 报告期内已响应联系人“更新”要求的 SRS（EPP 及其他接口）数量 |
作为评议请求(RFC) 4180 第 2 款规定的“标题行”，第一行应包含与上表所述名称完全相符的字段
名称，如评议请求 (RFC) 4180 的第 2 款所述。每份报告的最后一行应包含每列的所有注册商合计；此行的第一个字段表示“合计”，第二个字段应留空。除上述行之外，不得包含任何其他行。根据评议请求 (RFC) 4180 的规定，换行符应为 <U+000D, U+000A>。
规范 4
注册数据公布服务规范
1. 注册数据目录服务。在互联网名称与数字地址分配机构 (ICANN) 要求提供其他协议之前，注册机构运营商将根据RFC 3912 运营通过端口 43 提供的WHOIS 服务以及(<whois.nic.TLD>) 上基于Web 的目录服务，允许公众至少能够查询以下格式的元素。互联网名称与数字地址分配机构 (ICANN) 保留指定替代格式和协议的权利，指定此类规范之后，注册机构运营商应在合理可行的情况下尽快实施此类替代规范。
1.1. 回应应采用下述半自由文本格式，后跟空行和免责声明（指定注册机构运营商和查询数据库的用户的权利）。
1.2. 每个数据对象都应表示为一组密钥/值对，行首是密钥，后跟冒号和空格作为分隔符，再后跟值。
1.3. 对于存在多个值的字段，应允许多个密钥/值对具有相同的密钥（例如列出多个名称服务器）。空行之后的第一个密钥/值对应视为新记录的开始，并应视为该记录的标识，用于将数据
（例如主机名和IP 地址或域名和注册人信息）组合在一起。
1.4. 域名数据：
1.4.1. 查询格式：whois EXAMPLE.TLD
1.4.2. 回应格式：
域名：EXAMPLE.TLD域 ID：D1234567-TLD
WHOIS 服务器：whois.example.tld引用URL：xxxx://xxx.xxxxxxx.xxxxxxx：2009-05-29T20:13:00Z创建时间：2000-10-08T00:45:00Z
注册到期时间：2010-10-08T00:44:59Z赞助注册商：EXAMPLE REGISTRAR LLC
赞助注册商互联网号码分配当局 (IANA) ID：5555555
域状态：clientDeleteProhibited
域状态：clientRenewProhibited域状态：clientTransferProhibited域状态：serverUpdateProhibited注册人 ID：5372808-ERL
注册人姓名：EXAMPLE REGISTRANT
注册人组织：EXAMPLE ORGANIZATION
注册人所在街道：123 EXAMPLE STREET
注册人所在城市：ANYTOWN注册人所在州/省：AP
注册人邮政编码：A1A1A1 注册人所在国家和地区：EX
注册人电话：+1.5555551212注册人电话分机：1234
注册人传真：+1.5555551213注册人传真分机：4321
注册人电子邮件：EMAIL@EXAMPLE.TLD管理员 ID：5372809-ERL
管理员姓名：EXAMPLE REGISTRANT ADMINISTRATIVE
管理员组织：EXAMPLE REGISTRANT ORGANIZATION
管理员所在街道：123 EXAMPLE STREET
管理员所在城市：ANYTOWN管理员所在州/省：AP
管理员邮政编码：A1A1A1 管理员所在国家和地区：EX管理员电话：+1.5555551212管理员电话分机：1234
管理员传真：+1.5555551213
管理员传真分机：
管理员电子邮件：EMAIL@EXAMPLE.TLD技术人员 ID：5372811-ERL
技术人员姓名：EXAMPLE REGISTRAR TECHNICAL
技术人员组织：EXAMPLE REGISTRAR LLC
技术人员所在街道：123 EXAMPLE STREET
技术人员所在城市：ANYTOWN技术人员所在州/省：AP
技术人员邮政编码：A1A1A1 技术人员所在国家和地区：EX技术人员电话：+1.1235551234技术人员电话分机：1234
技术人员传真：+1.5555551213技术人员传真分机：93
技术人员电子邮件：EMAIL@EXAMPLE.TLD名称服务器：NS01.EXAMPLEREGISTRAR.TLD名称服务器：NS02.EXAMPLEREGISTRAR.TLD
域名系统安全扩展协议 (DNSSEC)：signedDelegation
域名系统安全扩展协议 (DNSSEC)：unsigned
>>>WHOIS 数据库上次更新时间：2009-05-29T20:15:00Z<<<
1.5. 注册商数据：
1.5.1. 查询格式：whois "registrar Example Registrar, Inc."
1.5.2. 回应格式：
注册商名称：Example Registrar, Inc.
街道：1234 Admiralty Way
城市：Xxxxxx del Rey
州/省：CA
邮政编码：90292国家和地区：US
电话号码：+1.3105551212传真号码：+1.3105551213
WHOIS 服务器：whois.example-registrar.tld引用URL：xxxx://xxx. example-registrar.tld管理联系人：Xxx Xxxxxxxxx
电话号码：+1.3105551213传真号码：+1.3105551213
电子邮件：joeregistrar@example-registrar.tld管理联系人：Xxxx Xxxxxxxxx
电话号码：+1.3105551214传真号码：+1.3105551213
电子邮件：janeregistrar@example-registrar.tld技术联系人：Xxxx Xxxx
电话号码：+1.3105551215传真号码：+1.3105551216
电子邮件：xxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
>>>WHOIS 数据库上次更新时间：2009-05-29T20:15:00Z<<<
1.6. 名称服务器数据：
1.6.1. 查询格式：whois "NS1.EXAMPLE.TLD" 或whois "nameserver (IP Address)"
1.6.2. 回应格式：
服务器名称：NS1.EXAMPLE.TLD IP 地址：192.0.2.123
IP 地址：2001:0DB8::1
注册商：Example Registrar, Inc.
WHOIS 服务器：whois.example-registrar.tld引用URL：xxxx://xxx. example-registrar.tld
>>>WHOIS 数据库上次更新时间：2009-05-29T20:15:00Z<<<
1.7. 对于域状态、个人姓名和组织名称、地址、街道、城市、州/省、邮政编码、国家和地区、电话和传真号码、电子邮件地址、日期和时间这些数据字段，其格式应符合EPP RFC 5730 - 5734 中指定的映射，以便此类信息（或在WHOIS 回应中返回的值）的显示可以统一处理和理解。
1.8. 可搜索。在目录服务中提供可搜索功能是可选操作，但如果注册机构运营商提供了该功能，则它应符合本节中所述的规范。
1.8.1.注册机构运营商将在基于 Web 的目录服务中提供可搜索功能。
1.8.2. 注册机构运营商将至少在下列字段中提供部分匹配功能：域名、联系人和注册人的姓名，以及联系人和注册人的邮政地址，包括 EPP 中所述的所有子字段（例如，街道、城市、州或省等）。
1.8.3. 注册机构运营商将至少在下列字段中提供完全匹配功能：注册商 ID、名称服务器名称，以及名称服务器的IP 地址（仅适用于注册机构存储的IP 地址，即粘合记录）。
1.8.4.注册机构运营商将至少为下列用于连接一组搜索标准的逻辑运算符提供布尔搜索功能支持：AND（和）、OR（或）、NOT（不）。
1.8.5.搜索结果将包括与搜索标准匹配的域名。
1.8.6. 注册机构运营商将：1) 采取适当措施以避免滥用此功能（例如，只有获得合法授权的用户才可访问）；2) 确保该功能符合任何适用的隐私法律或政策规定。
2.区域文件访问
2.1.第三方访问
2.1.1. 区域文件访问协议。注册运营商将与所有互联网用户签订协议，该协议将允许此类用户访问注册运营商指定的互联网主机服务器并下载区域文件数据。该协议将由集中区域数据访问提供商（CZDA 提供商）进行标准化、推动和管理。注册机构运营商将按照第 2.1.3 款提供对区域文件数据的访问，并使用第 2.1.4 款中所述的文件格式进行访问。尽管有上述规定，但(a)如果任何用户并未满足以下第 2.1.2 款中的认证要求，则集中区域数据访问(CZDA) 提供商可以拒绝其访问请求；(b) 如果任何用户并未按照第 2.1.2 款的规定提供正确或合法的认证，或者如果注册机构运营商有理由认为任何用户的行为会违反以下第 2.1.5 款的条款，则可以拒绝其访问请求；(c) 如果注册机构运营商有证据证明任何用户已违反第 2.1.5 款的条款，则可以撤销该用户的访问权限。
2.1.2. 认证要求。注册机构运营商（在集中区域数据访问[CZDA] 提供商协助下）将要求每个用户向其提供足以正确识别并找到用户身份的信息。此类用户信息包括但不限于公司名称、联系人姓名、地址、电话号码、传真号码、电子邮件地址和互联网主机名及 IP 地址。
2.1.3. 准许访问。每个注册机构运营商将为ICANN 所指定和管理的URL（特别是
<TLD>.xxx.xxxxx.xxx，其中 <TLD> 为注册机构所负责的TLD）提供区域文件 FTP（或其他注册构支持的）服务，以便用户访问注册机构的区域数据存档。注册机构运营商将授予用户非排他性、不可转让的有限权利，让用户访问注册机构运营商的区域文件 FTP 服务器，并以不高于每 24 小时一次的频率，使用 FTP 或互联网名称与数字地址分配机构 (ICANN) 可能规定的其他数据传输和访问协议，传输顶级域区域文件及其相关的加密校验和文件副本。对于各个区域文件访问服务器，这些区域文件位于名为 <zone>.zone.gz 的顶级目录中，其中 <zone>.zone.gz.md5 和 <zone>.zone.gz.sig 用于验证下 载。如果注册机构运营商还提供历史数据，则它将使用命名模式 <zone>-yyyymmdd.zone.gz 等。
2.1.4. 文件格式标准。注册机构运营商应采用标准主文件格式的子格式（最初定义见评议请求[RFC] 1035，第 5 款）提供区域文件，其中应包括公共域名系统 (DNS) 中使用的实际区域内的所有记录。子格式如下所示：
1. 每个记录均必须在一行中按以下格式包括所有字段：<domain-name> <TTL> <class> <type>
<RDATA>。
2. 类和类型必须使用标准助记符，而且必须采用小写字母的形式。
3. TTL 必须显示为十进制整数。
4. 允许在域名中使用/X 和/DDD。
5. 所有域名均必须采用小写字母。
6. 在一个记录中必须仅使用一个制表符作为字段之间的分隔符。
7. 所有域名必须完全符合条件。
8. 禁止使用$ORIGIN 指令。
9. 禁止使用“@”来表示现下来源。
10. 禁止在记录的开头使用“空域名”，以便继续在上一个记录中使用域名。
11. 禁止使用$INCLUDE 指令。
12. 禁止使用$TTL 指令。
13. 禁止使用括号，例如，以便跨越线框继续在记录中使用字段列表。
14. 禁止使用备注。
15. 禁止使用空行。
16. SOA 记录应出现在区域文件的顶部并在结尾处进行复制。
17. 除了 SOA 记录外，文件中的所有记录均必须按字母顺序排列。
18. 每个文件一个区域。如果 TLD 将其 DNS 数据分成多个区域，则每个区域将对应一个单独的文件（命名方式如上所示），所有的这些文件将通过 tar 合并成一个名为 <tld>.zone.tar 的文件。
2.1.5. 用户对数据的使用。注册机构运营商将允许用户为合法目的而使用区域文件；前提是 (a) 用户采取一切合理措施防止未经授权访问、使用和泄露数据；(b) 在任何情况下，注册机构运营商都不允许用户使用这些数据 (i) 允许、帮助或通过其他方式支持以电子邮件、电话或传真形 式，向用户自己现有客户之外的实体，发送大量未经允许的商业广告或推销信息；(ii) 启用高容量的自动电子流程，向注册机构运营商或互联网名称与数字地址分配机构 (ICANN) 委任的任何注册商的系统发送查询或数据。
2.1.6. 使用期限。注册机构运营商（在集中区域数据访问[CZDA] 提供商协助下）应为每个用户提供不短于三 (3) 个月的区域文件访问权限。注册机构运营商将允许用户更新其准许访问权限。
2.1.7. 免费访问。注册机构运营商（在集中区域数据访问[CZDA] 提供商协助下）应为用户提供免费的区域文件访问权限。
2.2 合作
2.2.1.协助。注册机构运营商将与 ICANN 和 CZDA 提供商合作并尽力协助其促进和维护本表下面的临时允许用户对区域文件数据的高效访问。
2.3 互联网名称与数字地址分配机构(ICANN) 访问。注册机构运营商应不断以互联网名称与数字地址分配机构 (ICANN) 随时合理指定的方式，针对互联网名称与数字地址分配机构 (ICANN) 或其指定的一方的顶级域名 (TLD) 注册，提供区域文件批量访问权限。
2.4 应急运营商访问。注册机构运营商应不断以互联网名称与数字地址分配机构 (ICANN) 随时合理指定的方式，针对互联网名称与数字地址分配机构 (ICANN) 指定的应急运营商的顶级域名 (TLD) 注册，提供区域文件批量访问权限。
3.对ICANN 进行成批注册数据访问
3.1.定期访问少量注册数据。为了验证和确保注册机构服务的运营稳定性以及方便对获得认证的注册商进行合规性检查，注册机构运营商每周将为ICANN 提供下面指定的最新注册数据。这些数据将包括截止至ICANN 所指定检索日期的前一天的 00:00:00 UTC 所提交的数据。
3.1.1.内容。注册机构运营商将为所有注册的域名至少提供以下数据：域名、域名库对象ID (roid)、注册商ID (IANA ID)、状态、上次更新时间、创建时间、到期时间以及名称服务器的名称。对于赞助注册商，它将至少提供：注册商名称、注册商库对象ID (roid)、注册商WHOIS 服务器的主机名以及注册商的URL。
3.1.2.格式。数据将以数据托管的规范 2 中指定的格式提供（包括加密、签名等），但只包括前面部分中所述的字段，也就是说，该文件将只包含具有上述字段的域和注册商对象。注册机构运营商可选择提供完整寄存文件而非规范 2 中指定的文件。
3.1.3,访问。注册机构运营商将在互联网名称与数字地址分配机构 (ICANN) 所指定的 检索日期的 00:00:00 UTC 准备好文件以供下载。这些文件将可通过 SFTP 进行下载，尽管互联网名称与数字地址分配机构 (ICANN) 将来可能要求使用其他方式下载。
3.2.特殊访问大量注册数据。如果注册商出现故障、被鉴定为不合格、收到法院指令等情况而需要按 ICANN 的要求将其域名暂时或永久转移至其他注册商，则注册机构运营商将为 ICANN 提供有关弃用注册商的最新域名数据。数据将以数据托管的规范 2 中指定的格式提供。该文件将只包含
与弃用注册商的域名相关的数据。注册机构运营商将在 2 个工作日内提供该数据。除非注册机构运营商与 ICANN 另有约定，否则该文件将按本规范的第 3.1 中规定的数据下载方式提供下载，供ICANN使用。
规范 5
通用顶级域名(gTLD) 注册机构二级保留名称明细表
除互联网名称与数字地址分配机构 (ICANN) 另行以书面形式明确授权，否则，注册机构运营商应保留（即，注册机构运营商不得注册、授权、使用或以其他方式为任何第三方提供此类标签，但可以在其自己的名称中注册此类标签，以便阻止授权或使用这些标签）由在顶级域名 (TLD) 内首次（即并非续签）注册的下列标签组成的名称：
1. Example。标签“EXAMPLE”应在第二级和注册机构运营商提供注册的顶级域名 (TLD) 内的其他所有级别保留。
2. 二字符标签。应在一开始就保留所有二字符标签。如果注册机构运营商与政府以及国家和地区代码管理员达成协议，对二字符标签字符串的保留可取消。注册机构运营商也可以在采取措施以避免与相应国家和地区代码混淆的前提下，提议取消这些保留。
3. 有标记的域名。如果标签在其ASCII 编码中表示有效国际化域名，则连字号只能位于标签的第三位和第四位（例如“xn--ndk061n”）。
4. 用于注册机构运营的二级保留。应保留下列名称，用于与顶级域名 (TLD) 注册机构运营有关的方面。注册机构运营商可以使用它们，但顶级域名 (TLD) 注册机构运营商成立后，注册机构运营商即失去指定资格，就应按互联网名称与数字地址分配机构 (ICANN) 的要求将它们转让：NIC、 WWW、IRIS 和WHOIS。
5. 国家和地区名称。以下国际公认的列表中包含的国家和地区名称一开始应在第二级和注册机构运营商提供注册的顶级域名 (TLD) 内的其他所有级别保留：
5.1. ISO 3166-1 列表中包含的所有国家和地区名称的简称（英文），不断进行更新，包括欧盟，其特别保留在ISO3166-1 列表中，并且其范围已在 1999 年 8 月扩展至需要显示名称“欧盟”的任何应用
<xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0000- 1_decoding_table.htm#EU>；
5.2. 联合国地理名称专家组的《地理名称标准化技术参考手册》中的第三部分- 世界各国家和地区名称；以及
5.3. 由联合国地名标准化会议的国名工作组用 6 种联合国官方语言制定的联合国成员国列表；
规定在注册机构运营商与适用政府达成协议后才可取消对特定国家和地区名称的保留，进一步规 定，注册机构运营商也可提议发布这些保留，但这些保留必须经过互联网名称与数字地址分配机构 (ICANN) 政府咨询委员会的审核和互联网名称与数字地址分配机构 (ICANN) 的批准。
规范 6
注册机构互操作性和持续性性能规范
1 标准遵从性
1.1. 域名系统(DNS)。注册机构运营商应遵守与以下内容有关的现有评议请求 (RFC) 和今后由互联网工程任务组 (IETF) 发布评议请求 (RFC)（其中包括所有后续标准、修改或补充）：域名系统 (DNS) 和名称服务器运营（包括但不限于现有评议请求 (RFC) 1034、1035、1982、2181、2182、2671、3226、3596、3597、4343 和 5966）。
1.2. 可扩展供应协议(EPP)。注册机构运营商应遵守与以下内容有关的现有评议请求 (RFC) 和今后由互联网工程任务组 (IETF) 发布评议请求 (RFC)（其中包括所有后续标准、修改或补充）：按照评议请求 (RFC) 5910、5730、5731、5732、5733 和 5734，使用可扩展供应协议 (EPP) 供应和管理域名。如果注册机构运营商实施注册宽限期 (RGP)，则必须遵守评议请求 (RFC) 3915 及其后续规定。如果注册机构运营商要求使用基本可扩展供应协议 (EPP) RFC 之外的功能，则根据RFC 3735 中的指南所述，注册机构运营商必须提供互联网草案格式的可扩展供应协议(EPP) 扩展机制的文件。部署之前，注册机构运营商要向互联网名称与数字地址分配机构 (ICANN) 提供和更新受支持的所有可扩展供应协议 (EPP) 对象和扩展的相关文档。
1.3. 域名系统安全扩展(DNSSEC)。注册机构运营商应在实施域名系统安全扩展
（简称“DNSSEC”）的顶级域名 (TLD) 区域文件上签名。在此期限内，注册机构运营商应遵守RFC 4033、4034、4035、4509 及其后续规定，并遵循RFC 4641 及其后续规定中描述的最佳做法。如果注册机构运营商实施用于域名系统(DNS) 安全扩展的哈希鉴定否定存在，它应该遵循RFC 5155 及其后续规定。注册机构运营商应根据行业最佳做法，以安全的方式接受子域名的公钥材料。注册机构还应在其网站中发布域名系统安全扩展 (DNSSEC) 做法声明(DPS)，说明密钥材料存储的重要安全控制措施和程序、自有密钥的访问和使用，以及注册人公钥材料的安全接受。注册机构运营商应在“做法声明(DPS)-框架”成为评议请求(RFC) 后 180 天内按照“做法声明(DPS)-框架”中所述的格式（目前为草案格式，请参阅xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxx-xxxxx-xxxxxx-xxx-xxxxxxxxx）发布其做法声明 (DPS)。
1.4. 国际化域名(IDN)。如果注册机构运营商提供国际化域名 (IDN)，则需要遵守评议请求 (RFC) 5890、5891、5892、5893 及后续规定。注册机构运营商应该遵守位于
<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx> 的互联网名称与数字地址分配机构 (ICANN) 国际化域名 (IDN) 指导原则（这些指导原则可能随时被修正、修改或取代）。如互联网名称与数字地址分配机构 (ICANN) 国际化域名 (IDN) 指南中所规定的那样，注册机构运营商应在国际化域名 (IDN) 做法的互联网号码分配当局 (IANA) 库中，发布并随时更新其国际化域名 (IDN) 表和国际化域名 (IDN) 注册规则。
1.5. IPv6。注册机构运营商应该能够接受IPv6 地址作为注册系统中的粘合记录，并在域名系统(DNS) 中公布它们。注册机构运营商应至少为根区域中列出的两个注册机构名称服务器（具有在互联网号码分配当局[IANA] 中注册的相应IPv6 地址）提供公共 IPv6 传输。注册机构运营商应遵循BCP 91 中所述的“域名系统(DNS) IPv6 传输运营指
南”和RFC 4472 中所述的建议和注意事项。注册机构运营商应按照本协议规范 4 中的定义为注册数据发布服务提供公共IPv6 传输；例如Whois (RFC 3912)、基于Web 的
WHOIS。收到通用顶级域名 (gTLD) 认证注册商希望通过IPv6 运营共享注册系统 (SRS) 的第一个书面申请之后，注册机构运营商应在六个月内为该注册商提供用于其共享注册系统 (SRS) 的公共IPv6 传输。
2 注册服务
2.1. 注册服务。注册协议中的“注册服务”定义如下：(a) 对于完成以下任务至
关重要的注册机构运营服务：从注册商处接收与域名和名称服务器注册有关的数据；为注册商提供与顶级域名 (TLD) 区域服务器有关的状态信息；传播顶级域名 (TLD) 区域文 件；注册机构域名系统 (DNS) 服务器的运营；根据此协议的要求，传播与顶级域名(TLD)中域名服务器注册有关的联系人信息和其他信息；(b) 根据规范 1 中规定的合意政策要求注册机构运营商提供的其他产品或服务；(c) 由注册机构运营商特性决定的只能由注册机构运营商提供的任何其他产品或服务；(d) 在上述(a)、(b) 或 (c) 项范围内，对任何注册服务的重大更改。
2.2. 禁止使用通配符。对于域名未注册、注册人未提供要在域名系统(DNS) 区域文件中列出的有效记录（如名称服务器[NS] 记录）或域名状态不允许在域名系统(DNS)中公布这些域名的，则禁止注册机构使用RFC 1034 和 4592 中所述的域名系统 (DNS) 通配符资源记录，或用于合成域名系统(DNS) 资源记录和在域名系统 (DNS) 中使用重定向的其他方法或技术。当查询此类域名时，权威名称服务器必须返回“名称错误”响应
（也称为NXDOMAIN），如 RFC 1035 和相关RFC 中所述的RCODE 3。此规定适用于域名系统(DNS) 树中所有级别的所有域名系统 (DNS) 区域文件，注册机构运营商（或提供注册服务的附属机构）为这些文件维护数据、安排此类维护或通过此类维护获取收入。
3 注册连续性
3.1. 高可用性。注册机构运营商应使用网络和分布于不同地理区域的冗余服务器
（包括网络级冗余、终端节点级冗余和适用时实施负载xx方案）进行运营，以确保在发生技术故障（广泛或局部）或超出注册机构运营商控制能力的非常情况下仍能继续运营。
3.2. 非常事件。如果发生超出注册机构运营商控制能力的非常事件，注册机构运营商应使用商业上合理的措施在此类事件结束后 24 小时内恢复注册机构的关键职能，并在此类事件结束后最多 48 小时内恢复全部系统功能（具体取决于所涉及的关键职能类 型）。因此类事件而发生的宕机不属于缺乏服务可用性的情况。
3.3. 业务连续性。注册机构运营商应留有一份业务连续性计划，准备在发生超出注册机构运营商控制能力之外的非常事件或注册机构运营商业务出现问题时维护注册服务，还可能要包括指定注册服务连续性提供商。如果此类计划的内容包括指定注册服务连续性提供商，则注册机构运营商应向互联网名称与数字地址分配机构 (ICANN) 提供所指定的注册服务连续性提供商的名称和联系信息。如果发生超出注册机构运营商控制能力的非常事件，并且无法联系到注册机构运营商，则注册机构运营商同意互联网名称与数字地址分配机构 (ICANN) 联系指定的注册服务连续性提供商（如果有）。注册机构运营商每年至少应执行一次注册服务连续性测试。
4. 滥用缓解措施
4.1 滥用联系人。注册机构运营商应向互联网名称与数字地址分配机构 (ICANN)
提供准确、详细的联系信息并在其网站上发布，联系信息包括有效的电子邮件地址、邮寄地址以及处理与顶级域名 (TLD) 中恶意行为有关的查询的主要联系人，并应向互联网名称与数字地址分配机构 (ICANN) 提供有关此类联系信息任何更改的及时通知。
4.2 恶意使用孤立的粘附记录。注册机构运营商在以书面形式提供与恶意行为有关时存在孤立粘附记录的证据时，应采取措施删除此类记录（如 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxxxxxx/xxx000.xxx 中定义）。
4 支持的初始和续签注册期
4.1. 初始注册期。可以一 (1) 年为单位在注册机构对已注册名称进行初始注册，最长可注册十(10) 年。为避免疑义，已注册名称的初始注册不应超过十(10) 年。
4.2. 续签期。可以一(1) 年为单位对已注册名称进行续签，最长可注册十 (10)
年。为避免疑义，已注册名称的续签不应将注册期延长到续期十(10) 年后。
对权利保护机制的最低要求
1. 权力保护机制。注册运营商要应用并遵守互联网名称与数字地址分配机构 (ICANN) 随时要求的所有权利保护机制（简称“RPM”）。除了这些 RPM，注册运营商还可制定并应用其他的 RPM，以阻止或预防注册违反或滥用对方合法权利的域名。注册运营商应把互联网名称与数字地址分配机构 (ICANN) 要求的、单独制定的所有 RPM，写入与经授权可在顶级域名 (TLD) 中注册名称的互联网名称与数字地址分配机构 (ICANN) 认可注册商达成的注册机构-注册商协议文件中。按照互联网名称与数字地址分配机构 (ICANN)建立的要求，注册运营商要应用商标清算所强制性规定的每个 RPM（发布在 [采用最终商标清算所时要插入的 URL] 上，ICANN 可能随时进行修订）。除了互联网名称与数字地址分配机构 (ICANN) 指定的商标清算所，注册运营商不得要求任何适用知识产权的所有者使用任何其他商标信息收集、通知或验证服务。
2. 争议解决机制。注册运营商要遵守以下可能随时进行修订的争议解决机制：
a. 互联网名称与数字地址分配机构 (ICANN) 采用的商标授权后争议解决程序 (PDDRP) 和注册限制争议解决程序 (RRDRP)（发布在 [采用最终程序时要插入的 URL] 上）注册运营商应同意遵守任何商标授权后争议解决程序 (PDDRP) 和注册限制争议解决程序 (RRDRP)专门小组的决议，应用并遵守互联网名称与数字地址分配机构 (ICANN) 强加的所有补救措施（可包括任何合理的补救措施，包括为了避免疑虑以及按照注册协议的第 4.3(e) 节终止注册协议而采取的补救措施），并受任何此类决议约束；
b. 互联网名称与数字地址分配机构 (ICANN) 采用的统一的快速暂停系统（简称“URS”，发布在 [要插入的 URL] 上），包括采用 URS 专家组成员做出的决议。
持续运营凭证
1. 持续运营凭证将(a) 提供充足的财务资源，以确保与《申请人指导手册》（发布在[推出该手册的最终版本时要插入的 URL] 上，是制定规范 8 的参考依据）第 [ ] 节中所列的顶级域名 (TLD) 有关的重要注册机构职能在以下时间段内的持续运营：在生效日期起五 (5) 周年（含）之前终止此协议后的三 (3) 年时间内，或者生效日期起五
(5) 周年后但生效日期起六 (6) 周年（含）之前终止此协议后的一 (1) 年时间内 (b) 采用 (i) 不可撤销的备用信用证书或 (ii) 不可撤销的现金托管寄存的方式，每种方式都需要符合《申请人指导手册》（发布在 [推出该手册的最终版本时要插入的 URL]
上，是制定规范 8 的参考依据）第 [ ] 节中所列的要求。注册运营商将尽全力采取所有必要或适当的措施，以保持持续运营凭证在生效日期起的六 (6) 年时间内有效，并使互联网名称与数字地址分配机构 (ICANN) 保持为第三方受益人。注册运营商将为互联网名称与数字地址分配机构 (ICANN) 提供与持续运营凭证有关的所有最终文档的副本，并合理通知互联网名称与数字地址分配机构(ICANN) 有关持续运营凭证的材料的制定。事先未经互联网名称与数字地址分配机构 (ICANN) 的书面许可（此类许可不会无理由拒绝），注册运营商不应同意或允许修改或放弃持续运营凭证或与此有关的其他文档。持续运营凭证要特别声明，按照注册协议的第 2.13 或 4.5 节 [针对政府实体插入：或第 7.14 节]，互联网名称与数字地址分配机构 (ICANN) 可以访问持续运营凭证的财务资源。
2. 尽管注册运营商在尽最大努力履行他们在上一段落中涵盖的义务，但如果持续运营凭证到期，或在生效日期起六周年之前因任何原因被第三方全部或部分终止，那么注册运营商应立即 (i) 通知互联网名称与数字地址分配机构 (ICANN) 凭证的到期或终止以及相应的原因 (ii) 准备备用凭证（简称“备用凭证”）来提供充足的财务资源，以确保与顶级域名 (TLD) 有关的注册服务能在以下时间段内持续运营：在生效日期起五周年（含）之前终止此协议后的三 (3) 年时间内，或者生效日期起五周年后但生效日期起六 (6) 周年（含）之前终止此协议后的一 (1) 年时间内。任何此类备用凭证中的条款给互联网名称与数字地址分配机构 (ICANN) 留下的印象不逊色于持续运营凭证，因此在形式和内容上都应得到互联网名称与数字地址分配机构 (ICANN)的认可。
3. 如果有任何内容违背了此规范 8 中的规定，注册运营商随时可将持续运营凭证替换为可起到以下作用的备用凭证：(i) 提供充足的财务资源，以确保与顶级域名 (TLD)有关的注册服务能在以下时间段内持续运营：在生效日期起五周年（含）之前终止此协议后的三 (3) 年时间内，或者生效日期起五周年后但生效日期起六 (6) 周年
（含）之前终止此协议后的一 (1) 年时间内 (ii) 所含条款给互联网名称与数字地址分配机构 (ICANN) 留下的印象不逊色于持续运营凭证，因此在形式和内容上都应得到互联网名称与数字地址分配机构 (ICANN) 的认可。如果注册运营商按照第 2 段或第 3 段（本段）替换持续运营凭证，则此规范 8 将不再适用于原始持续运营凭证，而是适用于此类替换凭证。
规范 9
注册机构运营商行为准则
1. 关于注册机构对顶级域名 (TLD) 的运营，注册机构运营商不允许任何母公司、子公司、附属机构、分包商或其他相关实体（均称为“注册机构相关方”）在该方参与提供顶级域名 (TLD) 相关注册机构服务的范围内进行以下行为：
a. 直接或间接向任何注册商提供任何关于在运营方面访问注册系统和相关注册服务的优先权或任何特殊报酬，除非根据基本相似的条款和条件向所有注册商提供取得此类优先权或报酬资格的同等机会；
b. 使用自己的权利注册域名，以下情况除外：通过互联网名称与数字地址分配机构 (ICANN) 认可的注册商注册对于顶级域名 (TLD) 的管理、运营和用途有必要的域名，前提是注册机构运营商可能根据注册协议第 2.6 款保留注册名称；
c. 通过访问关于消费者对未注册域名的搜索或决议请求的专有信息，注册顶级域名 (TLD) 中的名称或顶级域名 (TLD) 的子域名（通常称为“域名抢注”）。
d. 允许任何联营的注册商将用户数据透露给注册机构运营商或任何注册机构相关方（需要如此管理和运营顶级域名 (TLD) 时除外），除非按照基本相似的条款和条件向所有不相关的第三方（包括其他注册机构运营商）提供对此类用户数据的同等访问。
e. 将注册机构机密数据或有关其注册服务或运营的机密信息透露给任何域名系统
(DNS) 服务供应商的任何员工（需要如此管理和运营顶级域名 (TLD) 时除
外），除非按照基本相似的条款和条件向所有不相关的第三方（包括其他注册机构运营商）提供对此类注册机构机密数据或机密信息的同等访问。
2. 如果注册机构运营商或注册机构相关方同时也是注册商或注册商分销商服务的供应 商，注册机构运营商会让此类注册机构相关方维护与其注册商或注册商分销商运营相关的单独帐目。
3. 注册机构运营商每个日历年开展至少一次内部审核，以确保遵守此行为准则。在每个日历年结束后的二十 (20) 个日历天内，注册机构运营商将提供内部审核的结果，并提供由注册机构运营商执行的认证，以证明注册机构运营商遵守此行为准则，提供方式是向由互联网名称与数字地址分配机构 (ICANN) 提供的地址发送电子邮件。（互联网名称与数字地址分配机构 [ICANN] 可能会指定将来通过其他合理方式交付此类报告的表格及内容或报告。）注册机构运营商同意互联网名称与数字地址分配机构 (ICANN) 可公开发布此类结果和认证。
4. (i) 限制互联网名称与数字地址分配机构 (ICANN) 就注册机构运营商不遵循此行为准则的投诉进行调查；或 (ii) 给出理由，说明注册机构运营商为什么拒绝配合互联网名称与数字地址分配机构 (ICANN) 就注册机构运营商不遵循此行为准则的投诉进行的调查。
5. 本文所有规定均不限制注册机构运营商或任何注册机构相关方在正常业务范围内与注册商或分销商针对与顶级域名 (TLD) 毫不相关的产品和服务参加公平交易。
6. 注册机构运营商可能请求对本行为准则的豁免，并且此类豁免可能由互联网名称与数字地址分配机构(ICANN) 合理自行授予，前提是注册机构运营商达到互联网名称与数字地址分配机构(ICANN) 合理满意程度，即(i) 顶级域名(TLD) 中的所有域名注册均由注册机构运营商维护并注册供自己使用；(ii) 注册机构运营商不将顶级域名(TLD) 中的任何注册的控制权和使用权出售、分发或转让给不是注册机构运营商附属机构的任何第三方，以及(iii) 对顶级域名(TLD) 应用本行为准则对于保护公众利益并非必需。
规定 10
注册管理机构执行规定
1. 定 义
1.1. DNS。指在 RFC（意见征求书）1034、1035 和相关 RFC 中指定的域名系统 (DNS)。
1.2. DNSSEC 正当决议。存在从根区域信任锚到某个特定域名的有效 DNSSEC（域名系统安全扩展）信任链，如 TLD（顶级域名）、在 TLD 下注册的域名等。
1.3. EPP。指RFC 5730 和相关RFC 中指定的可扩展供应协议 (EPP)。
1.4. IP 地址。指 IPv4 地址或 IPv6 地址，不对二者加以区别。如果需要区别二者，则使用 IPv4 或
IPv6。
1.5. 探测器。位于全球各地的、用于执行（DNS、EPP 等）测试（见下文）的网络主机。
1.6. RDDS。注册数据目录服务 (RDDS) 指本协议“规定 4”中定义的 WHOIS 和基于 Web 的
WHOIS 服务的集合。
1.7. RTT。往返时间或 RTT 指从发送数据包序列中第一个数据包的第一个位数（用于提出请求）开始，到收到数据包序列中最后一个数据包的最后一个位数（用于接收响应）为止的这段时间。如果客户端未收到表明收到响应的整个数据包序列，则该请求将被视为未响应。
1.8. SLR。服务级别要求(SLR) 是服务级别协议 (SLA) 中对正在测量的特定参数所要求的服务级别。
2. 服务水平协议矩阵
参数 | SLR（按月衡量） | |
DNS | DNS 服务可用性 | 0 分钟中断= 100% 可用性 |
DNS 名称服务器可用性 | 432 分钟中断( 99%) | |
TCP DNS 解析 RTT | 1500 毫秒（对于至少 95% 的查询） | |
UDP DNS 解析RTT | 500 毫秒（对于至少 95% 的查询） | |
DNS 更新时间 | 60 分钟（对于至少 95% 的探测器） | |
RDDS | RDDS 可用性 | 864 分钟中断( 98%) |
RDDS 查询RTT | 2000 毫秒（对于至少 95% 的查询） | |
RDDS 更新时间 | 60 分钟（对于至少 95% 的探测器） |
EPP | EPP 服务可用性 | 864 分钟中断( 98%) |
EPP 会话命令RTT | 4000 毫秒（对于至少 90% 的命令） | |
EPP 查询命令RTT | 2000 毫秒（对于至少 90% 的命令） | |
EPP 传输命令RTT | 4000 毫秒（对于至少 90% 的命令） |
当每项服务的统计流量较低时，建议注册管理执行机构为不同服务提供维护。但请注意，不会提供计划宕机或任何类似中断。出于维护目的或由于系统故障导致的中断将被直接视为中断并计入 SLA考量。
3. DNS
3.1 DNS 服务可用性。指一组列为特定域名（例如，TLD）的权威性名称服务器在答复来自 DNS 探测器的DNS 查询方面的能力。要使服务在某个时间点被视为可用，在注册到 DNS的名称服务器中，至少有两台委托服务器必须在对其每一个已注册公共DNS 的、名称服务器解析到的“IP 地址”的“DNS 测试”中具有成功结果。如果在给定时间内有 51% 或更多的DNS 测试探测器认为服务不可用，则DNS 服务将被视为不可用。
3.2 DNS 名称服务器可用性。指某个特定服务器（被列为域名的权威性名称服务器）已注册公共DNS 的“IP 地址”在答复互联网用户DNS 查询方面的能力。被监控的域名的所有名称服务器在公共DNS 中注册的“IP 地址”都应单独进行测试。如果在给定时间内，有 51% 或更多的DNS 测试探测器在对名称服务器“IP 地址”进行的“DNS 测试”中都得到未定义/未答复的结果，则该名称服务器“IP 地址”将被视为不可用。
3.3 UDP DNS 解析RTT。指两个数据包序列（UDP DNS 查询和相应的UDP DNS 响应）的 RTT。如果 RTT 比相关 SLR 中指定的时间长 5 倍，则该 RTT 将被视为未定义。
3.4 TCP DNS 解析RTT。指从 TCP 连接开始到结束（包括只收到一个DNS 查询的DNS 响应）这一期间的数据包序列的 RTT。如果 RTT 比相关 SLR 中指定的时间长 5 倍，则该 RTT 将被视为未定义。
3.5 DNS 解析RTT。指“UDP DNS 解析RTT”或“TCP DNS 解析RTT”。
3.6 DNS 更新时间。指从收到某个域名的转变命令的EPP 确认开始，到父域名的名称服务器用与所作更改一致的数据答复“DNS 查询”时为止衡量的这段时间。它只适用于对DNS信息所作的更改。
3.7 DNS 测试。指发送到特定“IP 地址”的一个非递归DNS 查询（通过UDP 或TCP）。如果所查询的DNS 区域中提供DNSSEC，则要确定查询已被答复，签名必须肯定通过验证（根据父区域中发布的相应DS 记录，如果父区域未签名，则根据静态配置的信任锚）。对查询的答复必须包含注册系统中的相应信息，否则查询将被视为未答复。“DNS 解析RTT”高于相应 SLR 5 倍的查询将被视为未答复。DNS 测试的结果可能为：与“DNS 解析RTT”对应的数字（以毫秒为单位）或未定义/未答复。
3.8 测量DNS 参数。对于被监控域名的名称服务器的每个已注册公共DNS 的“IP 地址”，每个DNS 探测器每分钟都应该对其执行UDP 和 TCP“DNS 测试”。如果“DNS 测试”未定义/未答复，该探测器将认为被测IP 不可用，直至执行新的测试。
3.9 整理来自DNS 探测器的结果。在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 20，否则测量将被弃置并视为无结果；在这种情况下不会根据 SLR 标记故障。
3.10 UDP 和TCP 查询的分发。DNS 探测器将按照类似于UDP 或 TCP 查询分发的方式来发送
UDP 或 TCP“DNS 测试”。
3.11 DNS 探测器放置。用于测量DNS 参数的探测器应尽可能放在跨不同地理区域、拥有大多数用户的网络上的 DNS 解析器附近；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。
4. RDDS
4.1 RDDS 可用性。指 TLD 的所有RDDS 服务通过提供相关注册系统中的相应数据来响应互联网用户查询的能力。如果有 51% 或更多的RDDS 测试探测器认为在特定时间内有任何 RDDS 服务不可用，则RDDS 将被视为不可用。
4.2 WHOIS 查询RTT。指从TCP 连接开始到结束（包括收到WHOIS 响应）这一期间的数据包序列的RTT。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
4.3 基于 Web 的 WHOIS 查询RTT。指从 TCP 连接开始到结束（包括只收到一个HTTP 请求的 HTTP 响应）这一期间的数据包序列的RTT。如果注册管理执行机构执行多步骤流程来获取信息，则只测量最后一步。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
4.4 RDDS 查询RTT。指“WHOIS 查询RTT”和“基于 Web 的WHOIS 查询RTT”的集合。
4.5 RDDS 更新时间。指从收到某个域名、主机或联系上传输命令的EPP 确认开始，到 RDDS
服务的服务器反映出所作更改时为止的这一段时间。
4.6 RDDS 测试。指发送到某个RDDS 服务的某个服务器的某个特定“IP 地址”的一条查询。查询应针对注册系统中的现有对象，且响应必须包含相应信息，否则查询将被视为未答复。RTT 高于相应SLR 5 倍的查询将被视为未答复。RDDS 测试的结果可能为：与 RTT 对应的数字（以毫秒为单位）或未定义/未答复。
4.7 测量RDDS 参数。对于被监控的 TLD 的每项RDDS 服务，RDDS 探测器每 5 分钟都将从服务器的所有已注册公共DNS 的“IP 地址”中选择一个IP 地址并对其执行“RDDS 测试”。如果“RDDS 测试”结果未定义/未答复，该探测器将认为相应的RDDS 服务不可用，直至执行新的测试。
4.8 整理来自RDDS 探测器的结果。在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 10，否则测量将被弃置并视为无结果；在这种情况下不会根据SLR 标记故障。
4.9 RDDS 探测器放置。用于测量RDDS 参数的探测器应放在跨不同地理区域、拥有大多数用户的网络中；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。
5. EPP
5.1 EPP 服务可用性。指 TLD EPP 服务器作为组，响应注册管理机构委任的注册服务商（已拥有服务器的凭据）所发出的命令的能力。响应应包括注册系统中的相应数据。“EPP 命令 RTT”高于相应 SLR 5 倍的 EPP 命令将被视为未答复。如果在给定时间内有 51% 或更多的 EPP 测试探测器认为 EPP 服务不可用，则 EPP 服务将被视为不可用。
5.2 EPP 会话命令RTT。指以下数据包序列的 RTT：此数据包序列包括发送会话命令，和只接收一个EPP 会话命令的EPP 响应。对于登录命令，将包括用于启动 TCP 会话的数据包。对于注销命令，将包括用于关闭 TCP 会话的数据包。EPP 会话命令是指 EPP RFC 5730 中第
2.9.1 部分所述的命令。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
5.3 EPP 查询命令RTT。指以下数据包序列的 RTT：此数据包序列包括发送查询命令，以及只接收一个 EPP 查询命令的 EPP 响应。它不包括启动和关闭EPP 或 TCP 会话所需的数据
包。EPP 查询命令是指EPP RFC 5730 中第 2.9.2 部分所述的命令。如果 RTT 是相应SLR 的 5
倍或更多，则 RTT 将被视为未定义。
5.4 EPP 传输命令RTT。指以下数据包序列的RTT：此数据包序列包括发送传输命令，以及只接收一个 EPP 传输命令的 EPP 响应。它不包括启动和关闭EPP 或 TCP 会话所需的数据
包。EPP 传输命令是指EPP RFC 5730 中第 2.9.3 部分所述的命令。如果 RTT 是相应SLR 的 5
倍或更多，则 RTT 将被视为未定义。
5.5 EPP 命令RTT。指“EPP 会话命令RTT”、“EPP 查询命令RTT”或“EPP 传输命令
RTT”。
5.6 EPP 测试。指发送到某个EPP 服务器的特定“IP 地址”的一条EPP 命令。查询和传输命令
（“创建”除外）应针对注册系统中的现有对象。响应应包括注册系统中的相应数据。EPP测试的结果可能为：与“EPP 命令RTT”对应的数字（以毫秒为单位）或未定义/未答复。
5.7 测量EPP 参数。EPP 探测器将于每 5 分钟选择一个所监控的 TLD 的EPP 服务器的“IP 地 址”并执行“EPP 测试”；探测器每次应该在 3 种不同类型的命令之间以及每种类型内部的命令之间进行变换。如果“EPP 测试”未定义/未答复，该探测器将认为 EPP 服务不可用，直至执行新的测试。
5.8 整理来自 EPP 探测器的结果。在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 5，否则测量将被弃置并视为无结果；在这种情况下不会根据 SLR 标记故障。
5.9 EPP 探测器放置。用于测量 EPP 参数的探测器应放在注册服务商的互联网（跨不同地理区域）接入点内部或附近；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。
6. 紧急阈值
以下矩阵显示了紧急阈值，如果某个 TLD 的上述任何一个服务达到紧急阈值，将引发如本协议中第
2.13. 部分所述的关键职能的紧急移交。
关键职能 | 紧急阈值 |
DNS 服务（所有服务器） | 4 小时中断/周 |
DNSSEC 正当解析 | 4 小时中断/周 |
EPP | 24 小时中断/周 |
RDDS（WHOIS/基于Web 的WHOIS） | 24 小时中断/周 |
数据托管 | 因丢失托管“寄存”而违反注册管理机构协议，如第 6 节B 部分的规定 2 所述。 |
7. 紧急呈报
呈报的目的严格限制为通知并调查与被监控服务有关的可能或潜在的问题。任何呈报的发起和后续的合作调查本身并不意味着被监控的服务已经不能达到其执行要求。
呈报应在ICANN（互联网名称与数字地址分配机构）和注册管理执行机构、注册服务商和注册管理执行机构、以及注册服务商和ICANN 之间展开。注册管理执行机构和ICANN 必须提供如前所述的紧急运营部门。ICANN 和注册管理执行机构之间必须保持最新的联系信息，并且，当在呈报中存在与注册服务商的职能相关的信息时，必须在所有相关方对紧急呈报进行任何处理之前向注册服务商公布这些联系信息。同时，这些联系信息必须始终保持为最新信息。
7.1 由ICANN 发起的紧急呈报
一旦达到第 6 部分所述的紧急阈值的 10%，ICANN 的紧急运营部门就将向相关的注册管理执行机构发起紧急呈报。紧急呈报由以下最小要素组成：向注册管理执行机构的紧急运营部门发送电子（即电子邮件或短信息）和/或语音联系通知，提供与待呈报问题相关的详细信息，包括监控故障证
据、ICANN 工作人员和注册管理执行机构对监控故障的合作故障排除，以及承诺启动监控服务或被监控服务的问题纠正流程。
7.2 由注册服务商发起的紧急呈报
注册管理执行机构将常设一个紧急运营部门，随时处理来自注册服务商的紧急请求。当注册服务商因注册管理机构服务故障无法执行与注册管理机构的 EPP 事务，并且无法联系（通过ICANN 规定的通信方式）注册管理执行机构，或者注册管理执行机构无法或不愿解决故障时，注册服务商可向 ICANN 的紧急运营部门发起紧急呈报。然后，ICANN 可以按照如前所述的方式向注册管理执行机构发起紧急呈报。
7.3 中断和维护通知
当注册管理执行机构计划进行维护时，将在进行维护的至少 24 小时前向ICANN 紧急运营部门提供相关通知。ICANN 的紧急运营部门将记录计划维护的时间，并在预定的维护中断期间暂停被监控服务的紧急呈报服务。
如果注册管理执行机构按照与ICANN 的合同义务，宣布中断 SLA 和执行要求下的服务，将会通知 ICANN 紧急运营部门。在宣布的中断期间，ICANN 的紧急运营部门将针对所涉及的被监控服务，记录并暂停紧急呈报服务。
8. 执行测量公约
8.1 不干预。注册管理执行机构将不会干预测量探测器，包括对被监控服务的请求进行任何形式的优先处理。注册管理执行机构将以与响应来自互联网用户（DNS 和RDDS）和注册服务商(EPP) 的其他任何请求相同的方式来响应本规定中所述的测量测试。
8.2 ICANN 测试注册服务商。注册管理执行机构同意 ICANN 拥有一个测试注册服务商来测量上述 SLR。注册管理执行机构同意不对测试注册服务商提供任何与无此事务的其他注册服务商不同的区别对待。ICANN 不会使用该注册服务商来为自己或他人注册域名（或其他注册管理机构对象），除非是出于使用本协议中所述的条件来验证合同符合性的目的。