本《注册管理机构协议》（本“协议”）由加利福尼亚州非营利性公益型企业“互联网名称与数字地址分配机构”（“ICANN”）与 （所属司法管辖区及性质
注册管理机构协议
本《注册管理机构协议》（本“协议”）由加利福尼亚州非营利性公益型企业“互联网名称与数字地址分配机构”（“ICANN”）与 （所属司法管辖区及性质
）（“注册管理运行机构”）共同签署，自 （“生效日期”）起生效。
第 1 条
顶级域的授权和运营；xx和保证
1.1 域与指定。本协议适用的顶级域为 （以下简称“TLD”）。自生效日期起，直至第 4.1 节中定义的期限结束之日或根据第 4 条终止本协议（以先到日期为
准），ICANN 根据TLD 授权及进入根区的要求和必要的审批，指定注册管理运行机构为该TLD 的注册管理运行机构。
1.2 字符串的技术可行性。尽管ICANN 一向鼓励并且还将继续鼓励互联网上所有顶级域字符串的普遍适用性，某些顶级域字符串还是有可能会遇到ISP 和网络主机提供商难以接受和/或Web 应用程序难以验证的问题。注册管理运行机构应在签署本协议之前负责确保其满足TLD 字符串的技术可行性。
1.3 xx和保证。
(a) 注册管理运行机构向ICANN 作出以下xx和保证：
(i) 其在注册管理机构TLD 申请中提供的所有重要信息、作出的所有声明以及在本协议谈判期间所作的书面声明的所有重要内容在提供之时均真实准确，且自生效日期起，此类信息和声明的所有重要内容将继续保持真实准确，除非注册管理运行机构以书面形式另行通知ICANN。
(ii) 注册管理运行机构依据本文前言部分填写的辖区的法律正式成立、有效存续且资格完备，而且注册管理运行机构具备所有必要权利和权限并已获得所有必要批准，可以订立、正式签署和交付本协议；且
(iii) 注册管理运行机构已向ICANN 交付一份经正式签署的经营方案，以保证在本协议终止和到期之时可提供执行所运营的TLD 注册管理机构职能所需的资金（“持续经营方案”），此类经营方案对本协议各方均具有约束力且其条款对于协议各方均具有强制执行力。
(b) ICANN 向注册管理运行机构作出xx和保证，ICANN 是依据美国加利福尼亚州法律正式成立、有效存续且资格完备的一家非营利性公益型企业。ICANN 具备订立、正式签署和交付本协议所需的所有权利和权限，并已通过所有必要的机构审批。
第 2 条
注册管理运行机构的约款注册管理运行机构与ICANN 达成协议如下：
2.1 批准的服务；附加服务。注册管理运行机构应有权提供随附的规范 6（“规范 6”）中第 2.1 节第 1 段的(a) 和(b) 款中所述的注册管理机构服务，以及附录A 中规 定的此类其他注册管理机构服务（统称为“批准的服务”）。如果注册管理运行机构希望提供的任何注册管理机构服务不属于批准的服务，或是对批准的服务进行重大修改后的服务（均称为“附加服务”），则注册管理运行机构应根据xxxxx://xxx.xxxxx.xxx/xxxx 上载明的注册管理机构服务评估政策（简称“RSEP”）提交此类附加服务审批申请。RSEP政策可能不时根据ICANN 章程（称为“ICANN 章程”，可能会不时修订）进行修订，以适应共识性政策的需要。注册管理运行机构只能在获得ICANN 书面批准的情况下提供附加服务。获得相关批准后，此类附加服务应视为本协议下的注册管理机构服务。ICANN 经过合理的判断，可能要求对本协议作出修订，以反映根据RSEP 批准提供任何附加服务这一情况，修订内容应采用各方可以合理接受的格式。
2.2 遵守共识性政策和临时政策。注册管理运行机构应遵守并执行本协议生效日期时xxxxx://xxx.xxxxx.xxx/xxxxxxxxx-xxxxxxxx 中载明的所有共识性政策和临时政策，以及将来可能按照ICANN 章程制定和采纳的共识性政策和临时政策，前提是此类未来政策按随附的规范 1（“规范 1”）中规定的程序进行采纳、与其中的主题相关并遵守其中规定的限制。
2.3 数据托管。注册管理运行机构应在授权后的十四(14) 个日历日内遵守随附的规范 2（“规范 2”）中规定的注册数据托管程序。
2.4 每月报告。从在根区中授权TLD 的首个日历月开始，在每个日历月结束后的二十(20) 个日历日内，注册管理运行机构应按随附的规范 3（“规范 3”）中规定的格式向ICANN 递交报告；但如果是在一个日历月的第十五(15) 个日历日之后才在根区中授权TLD，注册管理运行机构可以延迟递交该首个日历月的报告，并在不迟于下一个日历 月要求注册管理运行机构提交报告的时间，向ICANN 提交该月份报告。注册管理运行机构必须在各注册服务机构交易报告中纳入在授权前测试阶段中创建且在授权时尚未删除的所有域名，尤其是（但不限于）通过注册服务机构ID 9995 和/或 9996 注册的域名。
2.5 注册数据的公布。注册管理运行机构应根据随附的规范 4（“规范 4”）为公众提供访问注册数据的途径。
2.6 保留名称。除非ICANN 另行以书面形式明确授权，否则注册管理运行机构应遵守随附的规范 5（“规范 5”）中规定的要求。注册管理运行机构有权酌情制定或修改有关注册管理运行机构在TLD 中保留（所谓保留即拒绝注册某些域名或将其分配给注册管理运行机构，而不注册给第三方，不在DNS 中授权、使用、激活或以其他方式提供给外部使用）或禁止其他字符串注册的政策。如若注册管理运行机构为注册管理机构
TLD 中域名的注册人，此类注册必须通过ICANN 认证注册服务机构进行并视为交易（如第 6.1 节中定义），以便计算注册管理运行机构根据第 6.1 节支付给ICANN 的注册管理机构交易费，规范 5 中规定的情况除外。
2.7 注册管理机构互用性和连续性。注册管理运行机构应遵守随附的规范 6
（“规范 6”）中规定的注册管理机构互用性和连续性要求。
2.8 第三方合法权利的保护。注册管理运行机构必须按照随附的规范 7（“规范 7”）指定并遵守相关流程和程序，以用于启动TLD 以及在首次注册和后续过程中对第三方的合法权利提供持续保护。注册管理运行机构可以自行选择对第三方合法权利实施额外保护。在本协议生效日期后对规范 7 所要求的流程和程序作出的任何更改或修改均应由 ICANN 提前做出书面批准。注册管理运行机构必须遵守ICANN 根据规范 7 第 2 节实行的所有补救措施，但是注册管理运行机构有权按照所述的适当程序对此类补救措施提出质 疑。对于执法机构、政府和准政府机构报告的与TLD 使用相关的非法行为，注册管理运行机构应采取合理措施进行调查，并作出回应。在注册管理运行机构对此类报告作出回应时，不得要求其采取任何与适用法律相违背的行动。
2.9 注册服务机构。
(a) TLD 中的所有域名注册均必须通过ICANN 认证注册服务机构进行；如果注册管理运行机构以自己的名义注册域名，以便阻止根据第 2.6 节授权或使用这些域名，则无需使用注册服务机构。根据规范 11 的要求，注册管理运行机构必须一视同仁地为所有签订并遵守TLD 注册管理机构-注册服务机构协议的ICANN 认证注册服务机构提供注册管理机构服务访问权限；前提是注册管理运行机构针对在TLD 中注册域名的资格制定非歧视标准，确保TLD 的正常运作。对于所有经授权可在TLD 中注册域名的注册服务机构，注册管理运行机构必须使用统一的公正协议（即“注册管理机构-注册服务机构协议”）。注册管理运行机构可随时修订注册管理机构-注册服务机构协议，但任何材料修订均须在得到ICANN 的批准后才能生效并对注册服务机构形成约束。注册管理运行机构需至少提前十五(15) 个日历日向ICANN 及所有授权在TLD 中注册域名的注册服务机构提供书面通知，阐述对注册管理机构-注册服务机构协议所做修订，之后该修订才能生效并对注册服务机构形成约束。在此期间，ICANN 将确定该修订提议的性质：无关紧要、具有潜在重要意义或者非常重要。如果ICANN 未在此十五(15) 个日历日内向注册管理运行机构提供有关其决定的通知，即视为ICANN 确定该修订提议的性质为无关紧要。如果 ICANN 确定或根据本 2.9(a) 节被视为已经确定该修订无关紧要，那么注册管理运行机构可以采用并执行该修订。如果ICANN 确定该修订非常重要或具有潜在重要意义，则将遵循其在xxxxx://xxx.xxxxx.xxx/xxx-xxxxxxxxx-xxxxxxxxx 上有关审核与审批注册管理机构-注册服务机构协议变更的程序予以处理，在获取ICANN 批准前，不得采用或执行该修订。尽管本 2.9(a) 节有上述规定，对注册管理机构-注册服务机构协议中仅与注册管理运行机构针对在TLD 中注册域名收取费用相关内容执行的修订，不受本 2.9(a) 节规定的通知和审批流程约束，但需遵循下述第 2.10 节的要求。
(b) 如果注册管理运行机构 (i) 成为ICANN 认证注册服务机构的附属机构或分销商，或 (ii) 向任何ICANN 认证注册服务机构、注册服务机构分销商或其各自的附 属机构转包注册管理机构服务项目，则无论出现情况 (i) 还是情况 (ii)，注册管理运行机 构都要就促成此类附属关系、分销商关系或转包关系的相应合同、交易或其他约定（如适用）及时通知ICANN，包括应ICANN 要求提供相关合同副本；前提是ICANN 根据第 7.15节的规定将适当标记为机密（根据第 7.15 节要求）的此类合同或相关文件视作注册管理运行机构的机密信息（但是ICANN 可向相关竞争管理机构披露此类合同和相关文件）。当确定此类合同、相关文件、交易或其他约定可能在适用法律下引发重大竞争问题时， ICANN 有权将合同、相关文件、交易或其他约定转介给相关竞争管理机构处理，但 ICANN 并不承担此类义务。如果可行且情况适当，ICANN 将在向竞争管理机构转介前给予注册管理运行机构提前通知。
(c) 在本协议中：(i)“附属机构”是指通过一个或多个中间方或联合一 个或多个其他个人或实体，以直接或间接方式控制指定个人或实体、受指定个人或实体控制，或者与指定个人或实体受共同控制的个人或实体；(ii)“控制”（包括术语“受控”和“共同受控”）是指拥有直接或间接的权利来左右某个人或实体的管理事务和政策，无论是通过证券所有权、作为受托人或执行人、通过担任董事会或等效监管机构的员工或成员、根据合约或信用协定还是其他方式。
2.10 注册管理机构服务定价。
(a) 注册管理运行机构针对域名初始注册的任何提价举动（包括取消退 款、回扣、折扣、产品搭售或取消其他有效减低对注册服务机构收取的价格的计划，除非此类退款、回扣、折扣、产品搭售或其他计划有一定期限，且在提供时已清楚、明显地透漏给注册服务机构），应至少提前三十(30) 个日历日向每个正式签署了TLD 注册管理机构-注册服务机构协议的ICANN 认证注册服务机构发出书面通知。注册管理运行机构应为注册服务机构提供为期一(1) 到十(10) 年（由注册服务机构自行选择），但不超过十
(10) 年的初始域名注册方案。
(b) 注册管理运行机构针对域名注册续订的任何提价举动（包括取消退 款、回扣、折扣、产品搭售、合格的营销计划，或取消其他有效减低对注册服务机构收取的价格的计划），应至少提前一百八十(180) 个日历日向每个正式签署了TLD 注册管理机构-注册服务机构协议的ICANN 认证注册服务机构发出书面通知。尽管有上述规定，但对于域名注册续订：(i) 如果最终价格低于或等于 (A) 从生效日开始到生效日之后的十二
(12) 个月内，针对TLD 中的注册收取的初始价格；或者 (B) 在后续期间，注册管理运行机构根据本 2.10(b) 节第一句的规定，在拟定提价措施生效日的前十二(12) 个月提供通知的价格；则注册管理运行机构仅需提前三十(30) 个日历日就任何提价行动发出通知；(ii)对于按照第 6.3 节规定所收取的可变注册管理机构费用，注册管理运行机构无需就提价发出任何通知。注册管理运行机构为注册服务机构提供以当前价格（即任何提价通知之前的价格）取得为期一(1) 到十(10) 年（由注册服务机构自行选择），但不超过十(10) 年的域名注册续订方案。
(c) 此外，注册管理运行机构对于域名注册的续订必须有统一定价（“续订定价”）。为确定续订定价，每个域名注册续订的价格必须与此类续订时敲定的所有其他域名注册续订的价格相同，且此类价格必须考虑退款、回扣、折扣、产品搭售或续订时实行的其他计划等情况。如果注册服务机构已向注册管理运行机构提供文件，证明适用的注册人在域名初始注册时已清晰明确地了解续订定价，并在与注册服务机构的注册协议中明确同意提高续订定价，则本 2.10(c) 节的上述规定不适用于 (i) 确定续订定价，(ii) 根据 “合格的营销计划”（定义如下）折后的续订定价。双方了解，x 2.10(c) 节旨在禁止注册管理运行机构在初始域名注册时在未取得适用注册人书面同意的情况下滥用续订定价和
/或进行歧视性续订定价的行为，且本 2.10(c) 节广泛解释为禁止此类行为。在本 2.10(c)节中，“合格的营销计划”是指注册管理运行机构据以提供折扣续订定价的营销计划，前提是满足以下条件：(i) 计划及相关折扣的提供时段不超过一百八十(180) 个日历日（确定计划的日历日天数时需结合随后大致相似的计划），(ii) 所有ICANN 认证注册服务机构获得此类折扣续订定价的机会均等；(iii) 计划的初衷或结果是不排除任何特定类别的注册
（例如大企业持有的注册）或提高任何特定类别的注册的续订定价。x 2.10(c) 节中的任何内容均不能限制第 2.10(b) 节中规定的注册管理运行机构义务。
(d) 注册管理运行机构应自费为TLD 提供面向公众的基于查询的DNS 查询服务（即运行注册管理机构TLD 区域服务器）。
2.11 合同和运营合规审计。
(a) ICANN 可能会不时（每个日历年不超过两次）自行或聘用第三方机 构进行合同合规审计，以评估注册管理运行机构是否遵守本协议第 1 条中包含的xx和保证及第 2 条中包含的约款。此类审计应针对评估合规性的目标而设计，ICANN (a) 应就任何此类审计提供合理的提前通知，并在通知中适当详细说明ICANN 所要求的文件、数据和其他信息类别，并且(b) 通过合理的商业行为以不会无理干扰注册管理运行机构运营的方式在常规工作时间执行此类审计。在任何此类审计过程中，注册管理运行机构应根据 ICANN 的要求履行以下义务：及时提供所有合理必要的相关文件、数据和任何其他信
息，以证明注册管理运行机构遵守了本协议。ICANN 应至少提前十(10) 个日历日通知
（或经注册管理运行机构同意另行指定提前期），以便在正常工作时间赴现场执行任何合同合规审计，从而评估注册管理运行机构是否遵守本协议第 1 条中包含的xx和保证及第
2 条中包含的约款。根据第 7.15 节的规定，ICANN 需将在此类审计过程中获得的适当标
记为机密（按第 7.15 节要求）的信息视为注册管理运行机构的机密信息。
(b) 根据第 2.11(a) 节进行的任何审计的费用均将由ICANN 承担，除非
(i) 注册管理运行机构(A) 控制或受控于任何ICANN 认证注册服务机构或注册服务机构分销商或其任何附属机构，与这些机构共同受某方控制，或以其他方式与这些机构相关联，或者 (B) 已将注册管理机构服务项目转包给某个ICANN 认证注册服务机构、注册服务机构分销商或其任何附属机构，并且在上述(A) 或 (B) 情形下，审计是关于注册管理运行机构是否遵守第 2.14 节之规定，此时注册管理运行机构应就与注册管理运行机构遵守第
2.14 节相关审计部分所产生的所有成本和费用为ICANN 提供合理补偿；或者除非 (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（“规范 8”）中列出的与“持续经营方案”相关的条款与条件。
2.13 紧急移交。注册管理运行机构同意，如果达到规范 10 的第 6 节中规定的任何注册管理机构职能紧急情况阈值，ICANN 可以依据 ICANN 的注册管理机构移交流程
（参阅 xxxxx://xxx.xxxxx.xxx/xxxxxxxx-xxxxxxxxxx-xxxxxxxxx）（称为“注册管理机构移交流程”，该流程可能不时修订）为该TLD 注册管理机构指定一个紧急的过渡性注册管理运行机构（“紧急运行机构”），直到原注册管理运行机构向 ICANN 表明并使其合理相 信，它可以继续运营 TLD 注册管理机构而不会再发生这种未能履行职责的情况。之后，注册管理运行机构可以根据注册管理机构移交流程中规定的程序，重新运营 TLD 注册管理机构，前提是注册管理运行机构支付了下列所有合理相关成本：(i) ICANN 因指定紧急运行机构而发生的成本，以及 (ii) 紧急运行机构因其运营 TLD 注册管理机构而发生的成本，这些成本应以合理的详细程度记录在案并提供给注册管理运行机构。x ICANN 依据
本 2.13 节和注册管理机构移交流程指定一家紧急运行机构，则如果 ICANN 或此类紧急运行机构提出合理要求，注册管理运行机构应向 ICANN 或该紧急运行机构提供维持运营和注册管理机构职能必需的所有 TLD 注册管理机构运营数据（包括根据第 2.3 节托管的数据）。注册管理运行机构同意，如果依据本 2.13 节指定了紧急运行机构，则 ICANN 可以对 IANA 数据库中与 TLD 相关的内容进行其认为有必要的任何修改。此外，在这种未能履行职责的情况下，ICANN 将保留并可执行其根据“持续经营方案”应享有的权利。
2.14 注册管理机构行为准则。在开展有关TLD 注册管理机构的运营活动时，注册管理运行机构应遵守随附的规范 9（“规范 9”）中规定的注册管理机构行为准则。
2.15 配合经济研究。如果ICANN 针对互联网上新的通用顶级域的影响或功能、 DNS 或相关问题发起或委托经济研究，注册管理运行机构应提供合理协作，包括应要求向ICANN 或其指定方提供进行此类研究合理所需的所有TLD 运营相关数据，然而注册管理运行机构可保留(a) 其就此类数据开展的内部分析和评估，以及(b) 适用法律禁止提供的数据。根据本 2.15 节向IACNN 或其指定方提供的适当标记为机密（按第 7.15 节要求）的所有数据应根据第 7.15 节之规定视为注册管理运行机构的机密信息，但是经汇总和匿名处理后，ICANN 或其指定方可向第三方披露此类数据。完成注册管理运行机构提供了相关数据的经济研究后，ICANN 将销毁注册管理运行机构提供的所有未经汇总和匿名处理的数据。
2.16 注册管理机构执行规范。注册管理机构运营TLD 的执行规范在随附的规范 10（“规范 10”）中有相应规定。注册管理运行机构应遵守此类执行规范，并且对于协议期限内的每一个日历年，至少在一(1) 年内保留足以证明其遵守此类规范的技术和运营记录。
2.17 其他公共利益承诺。注册管理运行机构应遵守随附的规范 11（“规范 11”）中规定的公共利益承诺。
2.18 个人资料。注册管理运行机构应 (i) 向已签署TLD 注册管理机构-注册服务机构协议的每家ICANN 认证注册服务机构发出通知，说明其根据本协议或其他协议收集和使用注册服务机构提交给注册管理运行机构的任何已识别或可识别的自然人的数据（即 “个人资料”）的目的，以及此类个人资料的预期接收方（或接收方所属类别）；以及
(ii) 要求相关注册服务机构获取每个TLD 注册人的同意，允许其收集和使用个人资料。注册管理运行机构应采取合理措施，防止从注册服务机构收集的个人资料丢失、被滥用、被未经授权地披露、被更改或被破坏。注册管理运行机构不得以有别于向注册服务机构通知的方式使用或授权使用个人资料。
2.19 [注：仅限基于社群的 TLD] 注册管理运行机构对TLD 社群的义务。注册管理运行机构应按照提交的关于TLD 的申请就以下各项制定注册政策：(i) TLD 中的命名规则；(ii) TLD 群体成员的注册要求；和(iii) 按照基于群体的TLD 的确定目的对所注册域名的使用。注册管理运行机构的TLD 运营方式应允许TLD 社群讨论并参与TLD 政策与实践的制定和修改。注册管理运行机构应制定TLD 注册政策的执行程序和有关TLD 注册政策合规性的争议解决程序，还应负责执行这些注册政策。对于根据本 2.19 节引发的争议，注册管理运行机构同意实行并遵守xxxxx://xxx.xxxxx.xxx/xxxxx 中规定的注册限制争议解决程序。注册管理运行机构应实行并遵守随附的规范 12 中规定的社群注册政策。
第 3 条
ICANN 约款
ICANN 与注册管理运行机构达成如下约款：
3.1 公开透明。ICANN 将按照其公示的使命与核心价值，以公开透明的方式行使职责。
3.2 公平对待。除非有实质性的正当理由，否则ICANN 不得以武断、不合理、不公正的方式应用自己的标准、政策、程序或做法，也不得对注册管理运行机构区别对待。
3.3 TLD 域名服务器。ICANN 将通过合理的商业行为确保由注册管理运行机构提交给ICANN 的对TLD 域名服务器指定的任何变更（使用ICANN 在 xxxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ 中指定的格式并包含所需的技术要素），都会由 ICANN 在技术验证后七(7) 个日历日内或尽快实施。
3.4 根区信息的公布。ICANN 在公布TLD 的根区联系信息时，应包括注册管理运行机构及其管理和技术联系人的信息。注册管理运行机构修改联系人信息的任何请求，必须始终以ICANN 在https://www.iana.org/domains/root/ 上指定的格式提出。
3.5 权威根数据库。如果ICANN 获得授权制定与权威根服务器系统（“权威根服务器系统”）相关的政策，ICANN 应该通过合理的商业行为(a) 确保权威根指向注册管理运行机构为TLD 指定的顶级域名服务器，(b) 依据ICANN 的公开政策和程序，确保包含TLD 相关信息的权威数据库始终稳定、安全且公开，并且(c) 协调权威根服务器系统，使其以稳定、安全的方式运行和维护；前提是ICANN 不得违反本协议，且如果任何第三方在任何司法管辖区（包括任何政府实体或互联网服务提供商）阻止或限制对TLD 的访问，ICANN 不应承担任何责任。
第 4 条
期限和终止
4.1 期限。本协议的期限将为自生效日期起持续十(10) 年（此期限可根据第 4.2
节延长，以下简称“期限”）。
4.2 续订。
(a) 在上述第 4.1 节中规定的初始期限和各个后续期限到期后，本协议都将进行续订（期限为十(10) 年的倍数），除非：
(i) 注册管理运行机构从根本上和实质上违反本协议第 2 条中规定的注册管理运行机构约款或没有履行本协议第 6 条规定的付款责任，并且未在收到ICANN 就此违约行为向其发出的通知（应详细说明所指控的违约行为）后三十(30) 个日历日内纠正自己的违约行为；(A) 仲裁机构和有司法管辖权的法庭最终裁定注册管理运行机构从根本上和实质上违反此约款或没有履行此付款责任，和 (B) 注册管理运行机构未遵守此裁定，并且未在十(10)个日历日内或仲裁机构和有司法管辖权的法庭规定的其他时间期限内纠正自己的违约行为；或
(ii) 适用“期限”期间，仲裁机构或有司法管辖权的法庭（根据本协议第 5.2 节）最少在三(3) 次不同情况下发现(A) 注册管理运行机构从根本上和实质上违反本协议第 2 条中规定的注册管理运行机构约款或 (B) 没有履行本协议第 6 条规定的付款责任（不管有没有纠正）。
(b) 出现第 4.2(a) (i) 或 (ii) 节所述事件后，本协议将于适用期限到期时
4.3 ICANN 终止协议。
(a) 如果出现下列情况，ICANN 可在通知注册管理运行机构后终止本协议：(i) 注册管理运行机构(A) 从根本上和实质上违反本协议第 1 条中规定的注册管理运行机构的陈述和保证，或没有履行本协议第 2 条规定的约款，或者 (B) 没有履行本协议第 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) 注册管理运行机构未能在六十(60) 个日历日内驳回其他方对其提起的查封、传唤或类似诉讼程序，且此类程序对其运营TLD 注册管理机构的能力产生了重大威胁，(iii) 委托人、接收人、清 算人或具有同类效力的实体经指定来取代注册管理运行机构或控制注册管理运行机构的任何财产，(iv) 对注册管理运行机构的任何重要财产执行了法律手段，且一旦执行此类法律手段，就可以合理预见注册管理运行机构运营TLD 注册管理机构的能力会受到实质性不利影响，(v) 依据任何破产、无力偿还、重组或其他与债务人债务清除相关的法律，注册管理运行机构对其他方或者其他方对注册管理运行机构提起了诉讼程序，并且此类诉讼在六十(60) 个日历日内（如果此类诉讼由注册管理运行机构或其附属机构提起）或一百八
十(180) 个日历日内（如果此类诉讼由第三方对注册管理运行机构提起）没有被驳回，或者(vi) 注册管理运行机构依照美国破产法（美国法典第 11 编第 101 条及其他条款）或同等外国法律申请保护或者清盘、关闭或以其他方式停止其运营或停止TLD 的运营。
(e) ICANN 可按照任何PDDRP 小组或RRDRP 小组根据规范 7 第 2 节作出的裁定，或任何PICDRP 小组根据规范 11 第 2 节、第 3 节或任何其他适用节作出的裁定，在通知注册管理运行机构三十(30) 个日历日后终止本协议，但是注册管理运行机构有权按照前述的适当程序对此类终止提出质疑。
(f) 如发生以下情形，ICANN 可在通知注册管理运行机构后终止本协 议：(i) 注册管理运行机构明知某高管被判重罪或与金融活动相关的轻罪，或被具有司法管辖权的法院裁定从事欺诈行为或违反诚信义务，或是某司法裁定的处罚对象，且 ICANN 有理由相信此处罚在性质上与以上罪行同样严重，却仍然雇用该高管，且注册管理运行机构在获悉此情况后三十(30) 个日历日内未终止雇用该高管；或者 (ii) 注册管理
运行机构董事会或类似主管团体的任何成员被判重罪或与金融活动相关的轻罪，或被具有司法管辖权的法院裁定从事欺诈行为或违反诚信义务，或是某司法裁定的处罚对象，且 ICANN 有理由相信此处罚在性质上与以上罪行同样严重，且注册管理运行机构在获悉此情况后三十(30) 个日历日内未将该成员从注册管理运行机构董事会或类似主管团体除
名。
(g) ICANN 可根据第 7.5 节在通知注册管理运行机构三十(30) 个日历日后终止本协议。
(h) [仅适用于国际政府间组织或政府实体。]ICANN 可根据第 7.16 节终
4.4 注册管理运行机构终止协议。
(a) 如发生以下情形，注册管理运行机构可在通知ICANN 后终止本协
议：(i) ICANN 从根本上和实质上违反第 3 条中规定的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 的运营移交给继任注册管理运行机构，但前提是 (i) 在决定是否将TLD 运营移交给继任注册管理运行机构时，ICANN 应考虑注册管理运行机构的任何知识产权（由注册管理运行机构报告给ICANN）；(ii) 如果注册管理运行机构向ICANN 合理证明(A) TLD 中的所有域名注册均注册到注册管理运行机构或其附
属机构并由其维护以供其专用，(B) 注册管理运行机构未将TLD 中任何注册的控制或使用权出售、分销或转移给不属于其附属机构的第三方，(C) 移交TLD 运营并非保护公众利益的必要前提，则ICANN 不得在本协议到期或终止时未经注册管理运行机构同意而将TLD运营移交给继任注册管理运行机构（不得无理拒绝、提条件或延迟）。为免存疑，上述规定不应禁止ICANN 按照将来的顶级域授权申请流程来授权顶级域，ICANN 制定的任何与此类申请流程相关的流程和异议程序均须严格遵守，以期保护第三方的权利。注册管理运行机构同意，如果依据本 4.5 节移交了TLD，则ICANN 可以对IANA 数据库中与TLD 相关的内容进行其认为必要的任何修改。此外，不管本协议终止或到期的理由为何，为维护和运营TLD，ICANN 或ICANN 指定方应保留持续经营方案规定的权利，并且可以行使这些权利。
[适用于国际政府间组织、政府实体或其他特殊情况的第 4.5 节“协议终止时的注册管理机构移交”的替换文本：
“协议终止时的注册管理机构移交。当协议期限根据第 4.1 或 4.2 节的规定而过期或者本协议根据第 4.3 或 4.4 节的规定而终止时，如果ICANN 指定了继任TLD 注册管理运行机构，则注册管理运行机构和ICANN 同意相互协商并密切协作，根据本 4.5 节促进和实施TLD 的移交。与注册管理运行机构协商后，ICANN 应根据注册管理机构移交流
程，自行决定是否将TLD 运营移交给继任注册管理运行机构。若ICANN 决定将TLD 的运营移交给继任注册管理运行机构，在注册管理运行机构的同意下（不得无理拒绝、提条件或延迟），如果ICANN 或此类继任TLD 注册管理运行机构提出合理要求，注册管理运行机构应向ICANN 或该注册管理运行机构提供维持运营和注册管理机构职能必需的所有 TLD 运营数据，包括根据第 2.3 节托管的数据。若注册管理运行机构不同意提供此类数 据，则应将与TLD 相关的所有注册管理机构数据返回给注册管理运行机构，除非双方另行达成协议。注册管理运行机构同意，如果依据本 4.5 节移交了TLD，则ICANN 可以对 IANA 数据库中与TLD 相关的内容进行其认为必要的任何修改。此外，不管本协议终止或到期的理由为何，ICANN 或ICANN 指定方应保留持续经营方案规定的权利，并且可以行使这些权利。”]
4.6 协议终止的影响。本协议到期或终止时，各方依照协议承担的义务和享有 的权利也将解除，但本协议的到期或终止不能免除各方在协议到期或终止之前形成的任何义务或违约责任，包括但不限于根据第 6 条形成的所有应计付款义务。此外，第 5 条、第 7 条、第 2.12 节、第 4.5 节以及本 4.6 节规定在本协议到期或终止后继续生效。为避免疑义特此说明，注册管理运行机构对TLD 注册管理机构的运营权利在本协议期限到期或终止时随即终止。
第 5 条
争议解决
5.1 调解。由本协议引起或与本协议有关的争议，在任一方根据下述第 5.2 节提出仲裁前，ICANN 和注册管理运行机构必须尝试根据以下条款条件通过调解方式予以解决：
(a) 一方应以书面通知形式向另一方提起争议调解。应由双方共同选择一位调解员进行调解。如果双方不能根据本 5.1 节在书面通知送达的十五(15) 个日历日内就调解员达成一致意见，双方应立即选择一个双方都能接受的调解服务提供机构，该机构应尽快在切实可行的范围内指定一位具有合同法一般知识、与任一方均无当前业务关系且具备调解具体争议所需的域名系统一般知识的持照律师作为调解员。任何调解员必须以书面形式确认其不是且在调解期间不会成为ICANN 或注册管理运行机构的雇员、合伙人、首席执行官、董事或证券持有人。如果指定调解员不能作出此类确认，则应根据本 5.1(a)节另行指定调解员。
(b) 调解员应在与双方协商后，根据其自行选择的调解规则及程序开展调解工作。纠纷双方应就争议进行友好协商，并尽力在调解员的协助下达成解决方案。调解应视为解决方案商讨，因此应保密，并不得在争议相关的后续程序（包括根据第 5.2 节进行的仲裁）中用以驳斥另一方。调解员不得在争议相关的任何后续程序中为任一方作证。
(c) 各方应自行承担各自的调解费用。双方应均摊调解员的费用。各方应根据第 7.15 节规定，将在调解中获得的另一方适当标记为机密（按第 7.15 节要求）的信息视为另一方的机密信息。
(d) 如果双方均真诚参与调解，但因故未解决争议，任一方或调解员可随时终止调解，之后可根据以下第 5.2 节继续以仲裁方式解决争议。如在根据第 5.1(a) 节送达通知之日起的九十(90) 个日历日内双方因故未能解决争议，调解应自动终止（除非双方协商延长），之后可根据以下第 5.2 节继续以仲裁方式解决争议。
5.2 仲裁。由本协议引起或与本协议有关的，根据第 5.1 节未能解决的争议，包括申请强制履行，将依据国际商会（以下简称“ICC”）国际仲裁法院的规则进行具有约束力的仲裁来加以解决。仲裁将在美国加利福尼亚州洛杉矶县以英语进行。任何仲裁将由一位仲裁员作出，除非(i) ICANN 提请惩罚性或警告性赔偿或者运营制裁；(ii) 本协议各方书面同意由更多仲裁员进行裁决；或者 (iii) 争议由第 7.6 或 7.7 节引起。如果出现上述 (i)、(ii) 或(iii) 的情况，仲裁均将由三位仲裁员执行，协议双方各提名一位仲裁员，由 ICC 确认，然后由选出的两位仲裁员提名第三位仲裁员，由ICC 确认。如果仲裁由独立仲裁员执行，注册管理运行机构和ICANN 可在达成共识后提名独立仲裁员，由ICC 确认。如果协议双方无法提名独立仲裁员，或者仲裁由三位仲裁员执行且协议双方均无法提名仲裁员，那么在一方收到另一方仲裁请求的三十(30) 个日历日内，或者在ICC 法院秘书处允许的额外时间内，ICC 应委任仲裁员。如果任何已提名仲裁员无法得到ICC 的认可，那么委任该仲裁员的一方或个人应及时提名替换仲裁员并由ICC 确认。为了加快仲裁处理进
度并限制其成本，仲裁员应对双方与仲裁相关的材料做出页数限制，而且一旦仲裁员决定必须举行听证会，则应将听证会限制在一(1) 个日历日内完成，如果是对ICANN 提请惩罚性或警告性赔偿或者对运营制裁的诉讼进行仲裁，可在双方协商一致的情况下、仲裁员根据其独立决策而发出指令的情况下，或者在一方提出合理要求的情况下将听证会延长一
(1) 个日历日。仲裁中胜诉一方有权要求获得成本和合理的律师费用补偿，仲裁员应在其裁决中包含此项补偿。如果仲裁员裁决注册管理运行机构一再蓄意从根本上和实质上违反本协议第 2 条、第 6 条或第 5.4 节中规定的义务，ICANN 可向仲裁员申请惩罚性或警告性赔偿（包括但不限于发出指令，临时限制注册管理运行机构出售新注册的权利）。根据第
7.15 节的规定，对于接收自另一方的合理标记为机密（根据第 7.15 节的要求）的仲裁相关信息，双方均应视其为另一方的机密信息予以处理。在涉及ICANN 且与本协议有关的任何诉讼中，此类诉讼的辖区和唯一审判地点将是位于加利福尼亚州洛杉矶县的法院；但是，协议双方均有权通过任何具备有效管辖权的法院来强制执行上述法院的审判结果。
[适用于国际政府间组织、政府实体或其他特殊情况的第 5.2 节“仲裁”的替换文
本：
“仲裁。由本协议引起或与本协议有关的，根据第 5.1 节未能解决的争议，包括申请强制履行，将依据国际商会（以下简称“ICC”）国际仲裁法院的规则进行具有约束力的仲裁来加以解决。仲裁将使用英语语言在瑞士日内瓦进行，除非注册管理运行机构和 ICANN 双方都同意在其他地点进行。任何仲裁将由一位仲裁员作出，除非(i) ICANN 提请惩罚性或警告性赔偿或者运营制裁；(ii) 本协议各方书面同意由更多仲裁员进行裁决；或者 (iii) 争议由第 7.6 或 7.7 节引起。如果出现上述 (i)、(ii) 或(iii) 的情况，仲裁均将由三位仲裁员执行，协议双方各提名一位仲裁员，由ICC 确认，然后由选出的两位仲裁员提名第三位仲裁员，由ICC 确认。如果仲裁由独立仲裁员执行，注册管理运行机构和ICANN 可在达成共识后提名独立仲裁员，由ICC 确认。如果协议双方无法提名独立仲裁员，或者仲裁由三位仲裁员执行且协议双方均无法提名仲裁员，那么在一方收到另一方仲裁请求的三十(30) 个日历日内，或者在ICC 法院秘书处允许的额外时间内，ICC 应委任仲裁员。如果任何已提名仲裁员无法得到ICC 的认可，那么委任该仲裁员的一方或个人应及时提名替换仲裁员并由ICC 确认。为了加快仲裁处理进度并限制其成本，仲裁员应对双方与仲裁相关的材料做出页数限制，而且一旦仲裁员决定必须举行听证会，则应将听证会限制在一
(1) 个日历日内完成，如果是对ICANN 提请惩罚性或警告性赔偿或者对运营制裁的诉讼进行仲裁，可在双方协商一致的情况下、仲裁员根据其独立决策而发出指令的情况下，或者在一方提出合理要求的情况下将听证会延长一(1) 个日历日。仲裁中胜诉一方有权要求获得成本和合理的律师费用补偿，仲裁员应在其裁决中包含此项补偿。如果仲裁员裁决注册管理运行机构一再蓄意从根本上和实质上违反本协议第 2 条、第 6 条或第 5.4 节中规定的义务，ICANN 可向仲裁员申请惩罚性或警告性赔偿（包括但不限于发出指令，临时限制注册管理运行机构出售新注册的权利）。根据第 7.15 节的规定，对于接收自另一方的合理标记为机密（根据第 7.15 节的要求）的仲裁相关信息，双方均应视其为另一方的机密信息予以处理。在涉及ICANN 且与本协议有关的任何诉讼中，此类诉讼的辖区和唯一审判地点将是位于瑞士日内瓦的法院，除非注册管理运行机构和ICANN 双方都同意其他地点；但是，协议双方均有权通过任何具备有效管辖权的法院来强制执行上述法院的审判结果。”]
5.3 责任限制。ICANN 在违反本协议时的总赔偿金额不得超过注册管理运行机构根据本协议在前十二个月期限内向ICANN 支付的注册管理机构费用的同等金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内）。注册管理运行机构在违反本协议时对ICANN 的总赔偿金额仅限于在前十二个月期限内向ICANN 支付的费用的同等金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内），以及第 5.2 节规定的惩罚性或警告性赔偿（如果有），但第 7.1 和 7.2 节规定的注册管理运行机构补偿义务除外。除第 5.2 节中规定的赔偿之外，在任何情况下，任意一方均无需承担因本协议引起或与本协议有关的特殊损害赔偿、惩罚性损害赔偿、警告性损害赔偿或间接损害赔 偿，也无需对履行或不履行本协议中规定的义务承担损害赔偿责任。除非本协议中另有规定，否则任一协议方均不得做出关于自己提供的服务、其服务人员或代理人或者其工作结果的任何明确或默示的保证，包括但不限于对任何适销性、非侵害性或特定用途适用性的默示保证。
5.4 强制履行。注册管理运行机构和ICANN 同意，不按照本协议的细则来履行本协议条款将可能造成无法挽回的损害。因此，双方同意每一方均应有权请求仲裁员或有相应司法管辖权的法院发出强制履行本协议条款的命令（此外，双方还有权采取任何其他补救措施）。
第 6 条
费用
6.1 注册管理机构费用。
(a) 注册管理运行机构应向ICANN 支付注册管理机构费用，支付金额等于：(i) 每个季度 6,250 美元的注册管理机构固定费；加上 (ii) 注册管理机构交易费（统称为“注册管理机构费用”）。注册管理机构交易费等于：在适用的季度内初始域名注册或域名注册续订（一级或多级注册，包括与在ICANN 认证注册服务机构之间转让域名相关的续订，各为一个“交易”）每年递增的数量乘以 0.25 美元。但是，只有在任一季度或总计连续四个季度在TLD 中注册的域名超过 50,000 个以后才应支付注册管理机构交易费
（“交易阈值”），并适用于在符合交易阈值的每个季度发生的每个交易，但不适用于不符合交易阈值的每个季度。从TLD 被授权到注册管理运行机构的DNS 之日起，注册管理运行机构有义务开始支付固定季度注册管理机构费用。注册管理机构固定费用的首笔季度费用将根据授权日期到授权日期所在季度结束日期之间的天数按比例计算。
(b) 根据第 6.1(a) 节，注册管理运行机构应按季度在ICANN 开出发票后的三十(30) 个日历日内向ICANN 指定的账户支付注册管理机构费用。
6.2 RSTEP 的成本回收。注册管理运行机构根据第 2.1 节请求批准附加服务的申请应由ICANN 根据https://www.icann.org/rsep 中的流程提交至注册管理机构服务技术评估小组（简称“RSTEP”）。如果此类申请提交至RSTEP，注册管理运行机构应在收到 ICANN 提供的RSTEP 发票副本后十四(14) 个工作日内，向ICANN 汇出RSTEP 审核费
用，除非ICANN 自行决定支付全部或部分的RSTEP 审核费用。
6.3 可变注册管理机构费用。
(a) 如果ICANN 认证注册服务机构（共计需要承担所有注册服务机构费用的三分之二，或根据当时的注册服务机构认证协议批准可变认证费所需达到的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 经手费用。注册管理运行机构应根据规范 7 向ICANN 支付(i) 5,000 美元的一次性费用以访问和使用商标信息交换中心（“RPM 访问费用”）和(ii) 0.25 美元每次的优先注册费和声明注册费（因为此类条款用于规范 7 规定的商标信息交换中心RPM）
（“RPM 注册费用”）。“RPM 访问费用”将自本协议的生效日期起开发票，且注册管理运行机构应在发票日期的三十(30) 个日历日内将此类费用支付到ICANN 指定的账户。 ICANN 将按季度就“RPM 注册费用”向注册管理运行机构开具发票，注册管理运行机构应根据第 6.1 节中指定的开票和付款程序付款。
6.5 费用调整。尽管本协议第 6 条对于费用限制作出规定，但在整个协议期限 内，在本协议第一年结束时开始，以及之后的每一年结束之时，ICANN 可自行决定是否增加第 6.1 和 6.3 节中规定的现行费用，如果调整，变更的百分比为 (i) 美国劳工部劳工统计局发布的城镇消费者物价指数美国城市平均值(1982-1984 = 100)，或相关年份开始之
前一(1) 个月的任何替代指数（“CPI”）减去(ii) 上一年开始之前一(1) 个月发布的CPI指数。如果要增加费用，ICANN 应向注册管理运行机构发出通知，详细说明调整金额。本 6.5 节中的费用调整应从ICANN 向注册管理运行机构送达此类费用调整通知后的至少三十(30) 天后的第一个季度的第一天起生效。
6.6 延迟付款的附加费用。根据本协议，如果付款延迟三十(30) 个日历日或更长时间，注册管理运行机构应以每月 1.5% 的利率支付延迟付款的附加费用；如果付款延迟少于三十(30) 个日历日，则按适用法律允许的最大利率支付延迟付款的附加费用。
6.7 费用减免。ICANN 可自行决定是否减免注册管理运行机构在任意时段内需支付的注册管理机构费用（以下简称“费用减免”）。ICANN 可自行决定任何费用减免应(a) 限制在一段时间内还是(b) 以注册管理运行机构接受该减免所对应的条款和条件为前提。如第 7.6(i) 节所述，除非ICANN 以书面形式执行，否则费用减免不予生效。ICANN将根据第 7.9 节向注册管理运行机构提供任何费用减免通知。
第 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 的赔偿的索赔和解，除非需要支付的金额完全由注册管理运行机构补偿。如果注册管理运行机构没有按照本 7.2 节规定对此类索赔辩护取得完全控制权，则ICANN 有权以其认为合适的方式对索赔进行辩护，费用和开支由注册管理运行机构承担，且注册管理运行机构应协助此类辩护。[注：本 7.2 节不适用于国际政府间组织或政府实体。]
7.3 术语定义。“安全性”和“稳定性”在本协议中的定义如下，除非将来根 据共识性政策对其做出修改（届时以下定义应视为根据此类共识性政策中的规定进行全文修改和重述）：
(a) 在本协议中，对“安全性”造成影响是指(1) 出现未经授权而披露、篡改、插入或销毁注册数据的情况，或(2) 遵照所有适用标准运行的系统出现未经授权而访问或披露互联网信息或资源的情况。
(b) 在本协议中，对“稳定性”造成影响是指(1) 不符合由信誉卓著、业界公认的互联网标准组织发布的相关权威性适用标准，例如互联网工程任务组(IETF) 提出的相关“标准通道”或“当前最佳实践”类意见征询（“RFC”)，或(2) 对于遵守由信
誉卓著、业界公认的互联网标准组织发布的相关权威性适用标准（例如IETF 提出的“标准通道”或“当前最佳实践”类RFC）并依赖于注册管理运行机构的授权信息或所供服务而运行的互联网服务器或终端系统，给其吞吐能力、响应时间、一致性或连贯性带来负面影响。
7.4 禁止抵销。不论注册管理运行机构与ICANN 之间有无悬而未决的纠纷（金钱或其他方面），本协议规定的所有付款应在本协议期限内及时付清。
7.5 控制权变更；转让和转包。除非本 7.5 节另有规定，任一方均不得在未经对方书面批准的情况下转让其在本协议中的权利和义务，同时任一方均不得无理由拒绝批准另一方的此类请求。为便于落实本 7.5 节的规定，特此说明对注册管理运行机构控制权的直接或间接变更或者对TLD 的任何与关键职能（见规范 10 第 6 节的说明）相关的转包安排（“实质性转包安排”）都应视作转让。
(a) 注册管理运行机构必须至少提前三十(30) 个日历日将所有转让或实质性转包安排通知ICANN，有关转让或转包部分TLD 运营业务（无论是否为实质性转包安排）的协议必须遵守注册管理运行机构在本协议中的所有约款、义务和协议，并且注册管理运行机构将继续受此类约款、义务和协议的约束。如果预计有任何完成的交易可能导致注册管理运行机构的控制权发生直接或间接变更，注册管理运行机构也应在该交易完成前至少三十(30) 个日历日通知ICANN。
(b) 在根据第 7.5(a) 节作出任一此类通知的三十(30) 个日历日内， ICANN 可要求注册管理运行机构提供其他信息，以确保 (i) 符合本协议，(ii) 获得此类控制权或签订此类转让或实质性转包安排的一方（无论何种情况，均称为“合同方”）以及合同方的最终母公司实体符合ICANN 当时执行的有关注册管理运行机构标准的规范或政策（包括财务资源及运营和技术能力），此时注册管理运行机构必须在十五(15) 个日历日内提供所要求的信息。
(c) 注册管理运行机构同意ICANN 根据针对拟定合同方（及此类合同方的附属机构）的背景审查，决定是否认可任何转让、控制权变更或实质性转包安排。
(d) 如果ICANN 在收到注册管理运行机构发送的有关此类交易的通知后的三十(30) 个日历日内（或如果ICANN 如上所述向注册管理运行机构要求其他信息，则为收到有关此类交易的所有书面信息后的三十(30) 个日历日内），未能明确表示同意或拒绝任何转让、注册管理运行机构控制权的直接或间接变更或任何实质性转包安排，则视为ICANN 已同意此类交易。
(e) 在处理有关此类转让、控制权变更或实质性转包安排的事务时，注册管理运行机构应遵守注册管理机构移交流程。
(f) 尽管有上述规定，(i) ICANN 不得撤销控制权的任何既遂变更，但是如果ICANN 经合理判断，决定拒绝同意此类交易，ICANN 可根据第 4.3(g) 节终止本协议；(ii) 如ICANN 发生重组、重建或再合并，ICANN 在获得ICANN 董事会批准后无需注
册管理运行机构同意，即可将本协议转让给另外一个明确表示接受本协议条款和条件的受让人；(iii) 注册管理运行机构可不经ICANN 同意将本协议直接转让给附属受让人（此术语在下文中定义），前提是此类附属受让人明确以书面形式接受本协议的条款和条件；
(iv) 如合同方与ICANN 签订了注册管理机构协议，已成为现有通用顶级域运营机构，则 ICANN 应视为已同意任何转让、实质性转包安排或控制权变更交易（前提是此类合同方在所有实质性方面遵守此类注册管理机构协议的条款和条件），但ICANN 在收到此类交易通知的十(10) 个日历日内根据本 7.5 节就此类交易向注册管理运行机构提出书面异议 的情况除外。尽管有第 7.5(a) 节的规定，如果根据本 7.5(f) 节的条款 (ii) 或 (iii) 进行了转让，则转让方在执行该转让后应及时通知另一方。对于本 7.5(f) 节，(A)“附属受让人”指通过一个或多个中介机构直接或间接地控制、被控制或者与指定个人或实体受到共同控制的个人或实体；(B)“控制”（包括“被控制”和“受到共同控制”）的含义与本协议第 2.9(c) 节所指定的含义相同。
7.6 修订和弃权。
(a) 如果ICANN 董事会确定对本协议（包括其中的“规范”）以及 ICANN 与适用注册管理运行机构之间的所有其他注册管理机构协议（“适用注册管理机构协议”）的修订（均称为“特殊修订”）是必要的，则ICANN 可根据本 7.6 节中的要求和规定的流程采纳特殊修订；前提是该特殊修订不是“受限修订”。
(b) 在提交特殊修订以获得注册管理运行机构批准之前，ICANN 首先应就特殊修订的形式和内容与工作组进行诚恳磋商。这种磋商的持续时间应由ICANN 根据特殊修订的内容合理确定。磋商后，ICANN 可以在其网站上公开发布特殊修订不少于三十(30) 个日历日（“发布期”），并根据第 7.9 节的规定将其通知给适用注册管理运行机构，提议采纳该特殊修订。ICANN 将审议在发布期内针对特殊修订征集到的公众意
见，包括由适用注册管理运行机构提交的意见。
(c) 如果ICANN 董事会在发布期结束后一百八十(180) 个日历日内
（“审批期”）批准特殊修订（可能与公开发布以征询公众意见用的特殊修订不同，但必须解决公开征询意见的特殊修订的主题问题，并根据工作组和公众意见进行修改）， ICANN 应发出通知并提交此类特殊修订供适用注册管理运行机构批准或拒绝。如果在 ICANN 向适用注册管理运行机构提供此类通知后的六十(60) 个日历日内，此类特殊修订获得注册管理运行机构批准，则特殊修订应视为获得适用注册管理运行机构批准（“获批修订”），并应在ICANN 向注册管理运行机构发出此类获批修订的批准通知后六十(60)个日历日起生效并视为对本协议的修订（“修订生效日期”）。如果此类特殊修订未获得注册管理运行机构批准，特殊修订应视为未获得适用注册管理运行机构批准（“被拒修 订”）。被拒修订对本协议项下条款条件无任何效力，但以下另有规定的除外。
(d) 如果ICANN 董事会合理确定某被拒修订属于规范 1 第 1.2 节中的主题问题类别，ICANN 董事会可通过一项决议（其中通过此类决议的日期称为“决议通过日期”），要求通用名称支持组织（“GNSO”）就此类被拒修订的内容提交问题报告
（定义详见ICANN 章程）。其中，GNSO 根据此类要求的问题报告所采用的政策制定流程
简称为“PDP”。如果此类PDP 形成最终报告，并获得GNSO 绝对多数票（如ICANN 章程定义）支持，建议 (i) 将被拒修订采纳为共识性政策或 (ii) 不将被拒修订采纳为共识性政策，则在 (i) 项的情况下，董事会采纳此类共识性政策，注册管理运行机构应根据本协议第 2.2 节规定履行义务。在任一情况下，ICANN 均将放弃被拒修订，此类被拒修订对本协议项下条款条件不产生任何效力。尽管有本 7.6(d) 节的上述规定，如果根据第 7.6(c) 节提交此类被拒修订以获得注册管理运行机构批准的前十二(12) 个月期间，此类被拒修订的主题问题成为未获得GNSO 绝对多数票推荐的定论或被放弃/被终止的PDP 的主题问题，则不得要求ICANN 董事会启动与被拒修订相关的PDP。
(e) 如果(a) 被拒修订不属于规范 1 第 1.2 节中的主题问题类别，(b) 在根据第 7.6(c) 节提交被拒修订以获得注册管理运行机构批准的前十二(12) 个月期间，被拒修订的主题问题成为未获得GNSO 绝对多数票推荐的定论或被放弃/被终止的PDP 的主题问题，或(c) PDP 未产生最终报告而获得GNSO 绝对多数票的如下支持：(A) 建议采纳被拒修订为共识性政策或 (B) 建议不采纳被拒修订为共识性政策（或此类PDP 因故放弃或终止），则在上述任何情况下，此类被拒修订仍可能以下述方式采纳并生效。要使被拒修订被采纳，必须满足以下要求：
(i) 被拒修订的主题问题必须在ICANN 使命范围内，并符合其核心价值观（如ICANN 章程中所述）的均衡应用原则；
(iii) 如若被拒修订禁止或要求适用注册管理运行机构实施特定行为或活动，产生高昂费用，和/或大幅削减公众访问域名服务，被拒修订必须是合理回应与公共利益相关的重要而迫切的原因的一种限制最少的方式；
(iv) ICANN 董事会必须提交被拒修订和其认为被拒修订符合上述
(i) 至(iii) 项要求的书面原因说明以征询公众意见，为期不少于三十(30) 个日历日；且
(v) 在该公共评议期结束后，ICANN 董事会必须(a) 与工作组、主题问题专家、GNSO 成员、相关咨询委员会及其他利益相关方就此类被拒修订进行为期不少于六十(60) 个日历日的协商（或指示ICANN 管理层进行协商）；及(b) 在此类协商后，如果至少三分之二有资格对此类问题投票的 ICANN 董事会成员投赞成票（考虑任何影响此类资格的ICANN 政策，包括 ICANN 的利益冲突政策），则重新审批被拒修订（可能与提请注册管理运行机构批准的被拒修订不同，但必须解决此类被拒修订的主题问题，并根据工作组和公众意见进行修改）（“董事会修订”）。
根据第 7.6(f) 节，此类董事会修订应视为获批修订，并应在ICANN 向注册管理运行机构发出此类董事会修订通知之日起的六十(60) 个日历日后生效，并视为对本协议的修订
（其生效日期应视为修订生效日期）。尽管有上述规定，董事会修订不得修订ICANN 收取的注册管理机构费用或修订本 7.6 节。
(f) 尽管有第 7.6(e) 节的规定，如果在ICANN 董事会批准董事会修订后的三十(30) 个日历日内，工作组代表适用注册管理运行机构向ICANN 董事会提交符合以下要求的董事会修订的替代性方案（下称“替代性修订”），则董事会修订不得被视为获批修订：
(i) 列明工作组建议的替代董事会修订对本协议予以修改的准确文本内容；
(ii) 回应ICANN 董事会为董事会修订提出的与公共利益相关的重要而迫切的原因；且
(iii) 与董事会修订相比，该替代性修订：(a) 以更有针对性的方式回应与公共利益相关的重要而迫切的原因，(b) 如若替代性修订禁止或要求适用注册管理运行机构实施特定行为或活动，产生高昂费用，或大幅削减公众访问域名服务，它应以更不受限的方式回应与公共利益相关的重要而迫切的原因。
不符合前述 (i) 到 (iii) 项要求的拟定修订不得视为替代性修订，因此不应取代董事会修订或推迟董事会修订的生效日期。如果向ICANN 董事会提交替代性修订后，替代性修订获注册管理运行机构批准，则替代性修订应取代董事会修订并应视为获批修订（并应在 ICANN 向注册管理运行机构发出此类替代性修订的批准通知后六十(60) 个日历日起生效并视为对本协议的修订，其生效日期应视为修订生效日期），除非工作组向ICANN 董事会发出有关此类替代性修订的注册管理运行机构批准通知后六十(60) 个日历日内（在此期间ICANN 应就替代性修订与工作组协商），ICANN 董事会至少三分之二有资格对此类问题投票的ICANN 董事会成员投票拒绝替代性修订（考虑任何影响此类资格的ICANN 政策，包括ICANN 的利益冲突政策）。如果(A) 向适用注册管理运行机构提交此类替代性修订后三十(30) 个日历日内未获得注册管理运行机构批准（且工作组应通知ICANN 此类提交日期），或(B) ICANN 董事会以三分之二反对票拒绝替代性修订，则董事会修订（而非替代性修订）应在ICANN 向注册管理运行机构发出通知后的六十(60) 个日历日起生效并视为对本协议的修订（此生效日期应视为修订生效日期）。如果ICANN 董事会拒绝替代性修订，董事会应发布书面解释，阐明其对 7.6(f)(i) 到 7.6(f)(iii) 中规定的标准的分
析。ICANN 董事会有权拒绝替代性修订，这并不表示董事会可免除确保董事会修订符合第 7.6(e)(i) 到 7.6(e)(v) 节中规定标准的义务。
(g) 如果注册管理运行机构确定获批修订不符合本 7.6 节中规定的实质性要求，或其采纳过程违反本 7.6 节的程序性规定，注册管理运行机构可根据第 5 条中规定的争议解决条款就此类特殊修订的采纳提出质疑，但是此种情况的仲裁应由一个三人仲裁庭进行。注册管理运行机构必须在ICANN 向其发出获批修订通知后的六十(60) 个日历日
内提出此类质疑，ICANN 可将各方（包括“注册管理运行机构”）提出的所有质疑合并在一个程序中予以处理。在上述争议解决期间，获批修订不得视为对本协议的正式修订。
(h) 在ICANN 向注册管理运行机构发出此类获批修订通知后三十(30) 个日历日内，注册管理运行机构可向ICANN 书面申请获批修订豁免（注册管理运行机构提交的每个此类请求称为“豁免请求”）。每个豁免请求将说明这种请求的依据，并为从 “获批修订”豁免提供详细的支持信息。豁免请求还可以包含对该注册管理运行机构提议的获批修订替代方案或变通方案的详细说明和支持信息。只有当注册管理运行机构明确且令人信服地表明，遵守获批修订会与适用法律发生冲突或者将对注册管理运行机构的长期财务状况或运营绩效产生实质性负面影响时，才应批准豁免请求。如果ICANN 经过合理的判断认定批准此类豁免请求将对注册人造成实质性损害或导致对注册人直接利益的剥 夺，则不会批准该豁免请求。在ICANN 收到豁免请求的九十(90) 个日历日内，ICANN 应该书面批准（可能是有条件的批准或批准获批修订的替代或变通方案）或拒绝该豁免请 求，在此期间获批修订将不对本协议发生效力。如果豁免请求经ICANN 批准，获批修订将不对本协议发生效力；但是，ICANN 对本获批修订提出的附加条件、替代方案或变通方案应自修订生效日起生效，并在适用的范围内对本协议予以修订。如果豁免请求被 ICANN 拒绝，则获批修订将自修订生效日期开始修订本协议（或者，如果该日期已过，应将获批修订视为在豁免请求被拒绝之日立即生效）；但是，注册管理运行机构可以在收到ICANN 决定的三十(30) 个日历日内，根据第 5 条规定的争议解决程序对ICANN 拒绝豁免请求的决定提出上诉。在上述争议解决期间，获批修订不得视为对本协议的正式修订。为避免疑义特此说明，由注册管理运行机构提交的豁免请求只有在根据本 7.6(j) 节获得 ICANN 批准、根据第 5.1 节调解并获得ICANN 同意或根据第 5.2 节仲裁并获得ICANN 同意后，才可使注册管理运行机构获得对获批修订的豁免，而且向任何其他适用注册管理运行机构授予的豁免请求（无论是由ICANN 授予或通过仲裁授予）均不应对本协议有任何影响，亦不得使注册管理运行机构获得对获批修订的豁免。
(i) 除本 7.6 节、第 7.7 节、本协议其他条款及其随附规范另有规定外，未经双方签字生效，本协议的任何修订、补充或更改或者其中的任何条款均无约束力，且本 7.6 节或第 7.7 节中的任何内容都不应限制ICANN 和注册管理运行机构通过仅在双方之间进行的谈判达成对本协议的双边修订和更改。若要放弃本协议的任何条款权利，弃权方需根据此类条款出具书面签署文件。除非弃权方另外明确表示，否则对本协议中任何条款的放弃或未执行本协议中任何条款的事实，均不应视为或构成对本协议中任何其他条款的放弃，也不应构成持续的弃权。为避免疑义特此说明，本 7.6 节或第 7.7 节中的任何内容均不应视为是对注册管理运行机构遵守第 2.2 节的义务的限制。
(j) 在本 7.6 节中，下列术语的解释如下：
(i) “适用注册管理运行机构”是指包含类似于本 7.6 节条款的注册管理机构协议之顶级域名协议方的注册管理运行机构的总称，涵盖普通注册管理运行机构。
(ii) “注册管理运行机构批准”表示获得以下批准：(i) 根据适用的注册管理机构协议，向ICANN 支付的款项占所有适用注册管理运行机构在上一日历年付给ICANN 的所有费用（如适用，在ICANN 计算当日按照
《华尔街日报》美国版前一天公布的现行汇率转换为美元）的三分之二的适用注册管理运行机构所给予的肯定批准；以及(ii) 获得此类批准时的大多数适用注册管理运行机构的肯定批准。为避免疑义特此说明，关于条款 (B)，根据适用注册管理机构协议，每个适用注册管理运行机构应对其运营的每个顶级域有一次投票权。
(iii) “受限修订”含义如下：(A) 对规范 1 的修订；(B) 除本协议第 2.10 节中规定的范围之外，规定注册管理运行机构对注册服务机构收取的域名注册费用的修订；(C) 对规范 6 第 2.1 节中第一段给出的“注册管理机构服务”定义的修订；(D) 对期限时间长度的修订。
(iv) “与公共利益相关的重要而迫切的原因”是可通过一个重要、具体、清晰阐明的公共利益目标证明其正当性的原因，该目标在ICANN 的使命范围内并且符合ICANN 章程中定义的ICANN 核心价值的平衡应用。
(v) “工作组”是指适用注册管理运行机构的代表和注册管理机构利益相关方团体不时指派的其他社群成员，这些成员组成工作组就适用注册管理机构协议的修订（不含根据第 7.6(i) 节进行的双边修订）展开磋商。
(k) 无论本 7.6 节中有何相反规定，(i) 如果注册管理运行机构向ICANN提供合理满意的证据证明，获批修订将大幅增加提供注册管理机构服务的成本，则 ICANN 将允许获批修订在最长一百八十(180) 个日历日后对注册管理运行机构生效，(ii)如果注册管理运行机构根据第 4.4(b) 节向ICANN 发出不可撤消的协议终止通知，则根据第 7.6 节采纳的获批修订不应对注册管理运行机构生效。
7.7 协商流程。
(a) 如果ICANN 首席执行官（“CEO”）或注册管理机构利益相关方团体主席（“主席”）希望探讨对本协议的修订，CEO 或主席（视情况而定）应向另一方 发出书面通知，通知中应阐明对本协议的拟定修订的合理详细信息（“协商通知”）。尽管有上述规定，CEO 或主席均不得 (i) 提议对本协议进行旨在修改现有共识性政策的修
订，(ii) 根据本 7.7 节在 2014 年 6 月 30 日或之前提议对本协议进行修订，或(ⅲ) 在
2014 年 7 月 1 日后的任何十二(12) 个月期间多次提出修订意见或提交协商通知。
(b) 收到CEO 或主席的协商通知后，ICANN 和工作组（如第 7.6 节定义）应就对本协议的拟定修订的形式和内容进行至少为期九十(90) 个日历日（“讨论
期”）的真诚协商（提早达成解决方案除外），其形式应为对本协议的拟定修订（“拟定修订”），并应尽力就双方可接受的拟定修订达成一致。
(c) 如果讨论期结束后就拟定修订达成了一致，ICANN 应在其网站上公开发布双方商定的拟定修订不少于三十(30) 个日历日（“发布期”）以征询公众意见，并根据第 7.9 节的规定向所有适用注册管理运行机构通知此类修订。ICANN 和工作组将审议在发布期内针对拟定修订征集到的公众意见，包括由适用注册管理运行机构提交的意见。发布期结束后，应将拟定修订提交注册管理运行机构批准（如第 7.6 节中定义）和 ICANN 董事会批准。如果获得此类批准，拟定修订应视为适用注册管理运行机构和 ICANN 的获批修订（如第 7.6 节中定义），且应在ICANN 通知注册管理运行机构后的六十(60) 个日历日起生效并视为对本协议的修订。
(d) 如果讨论期结束后，ICANN 和工作组之间未就拟定修订达成一致， CEO 或主席可向另一方发出书面通知（“调解通知”），要求各方尝试按照以下规定的 条款条件通过公正、便利（非评估）的调解来解决拟定修订相关的意见分歧。发出此类调解通知后，ICANN 和工作组应在十五(15) 个日历日内，同时在ICANN 网站上发布其预期的拟定修订版本及其立场声明文件。
(i) 应由双方共同选择一位调解员进行调解。在收到CEO 或主席
（视情况而定）调解通知后十五(15) 个日历日内，如果双方不能就调解员达成一致意见，双方应立即选择一个双方都能接受的调解服务提供机构，该机构应尽快在切实可行的范围内指定一位具有合同法一般知识、与任一方均无当前业务关系且具备调解具体争议所需的域名系统一般知识的持照律师作为调解员。任何调解员必须以书面形式确认其不是且在调解期间不会成为 ICANN 或适用注册管理运行机构的雇员、合伙人、首席执行官、董事或证券持有人。如果指定调解员不能作出此类确认，则应根据本 7.7(d)(i) 节另行指定调解员。
(ii) 调解员应在与双方沟通后，根据其自行选择的促进式调解规则及程序进行调解工作。纠纷双方应就争议进行友好协商，并尽力在调解员的协助下达成解决方案。
(iii) 各方应自行承担各自的调解费用。双方应均摊调解员的费用。
(iv) 如果在调解期间达成一致，ICANN 应于发布期在其网站上发布双方商定的拟定修订，并根据第 7.9 节向所有适用注册管理运行机构发出通知。ICANN 和工作组将审议在发布期内针对商定的拟定修订征集到的公众意见，包括由适用注册管理运行机构提交的意见。发布期结束后，应将拟定修订提交注册管理运行机构批准和ICANN 董事会批准。如果获得此类批准，拟定修订应视为适用注册管理运行机构和ICANN 的获批修订（如第 7.6节中定义），且应在ICANN 通知注册管理运行机构后的六十(60) 个日历日起生效并视为对本协议的修订。
(v) 如果在CEO 或主席（视情况而定）收到对方调解通知的九十
(90) 个日历日内，双方因故未能解决争议，调解应自动终止（除非双方协商延长）。关于此后根据一方申请而进行的仲裁中所可能涉及的相关争议事
项，调解员应向双方发出梳理报告。这些事项适用下以下第 7.7(e)(ii) 节中所规定的限制。
(e) 如果ICANN 和工作组在调解结束后未能就拟定修订达成一致，CEO或主席可向另一方发出书面通知（“仲裁通知”），要求ICANN 和适用注册管理运行机构根据第 5.2 节中的规定，遵从本 7.7(e) 节的要求和限制通过有约束力的仲裁解决争议。
(i) 如果已发出仲裁通知，应将调解员的争议事项梳理报告和拟定修订（来自ICANN、工作组或双方）发布在ICANN 网站上不少于三十(30)个日历日，以征询公众意见。ICANN 和工作组将审议在发布期内针对拟定修订征集到的公众意见（包括由适用注册管理运行机构提交的意见），且此类意见和审议结果应提交给由三(3) 位仲裁员组成的仲裁庭。各方均可在发布期前后对拟定修订予以调整。在该公共评议期结束前，不得启动仲裁程 序，且ICANN 可将各方（包括“注册管理运行机构”）提出的所有异议及主张在同一程序中合并审理。除本 7.7 节规定的情况外，所有仲裁应根据第
5.2 节执行。
(ii) 拟定修订项下主题问题有下列情形之一的，不得将其有关争议提交仲裁，即 (i) 与共识性政策相关；(ii) 属于规范 1 第 1.2 节中所规定的主题问题范畴；或 (iii) 意图修订本协议的以下任一条款或规范：第 1、3 和 6条；第 2.1、2.2、2.5、2.7、2.9、2.10、2.16、2.17、2.19、4.1、4.2、
7.3、7.6、7.7、7.8、7.10、7.11、7.12、7.13、7.14、7.16 节；第 2.8 节和
规范 7（但仅限于此类拟定修订意图实施第 2.8 节和规范 7 未考虑的
RPM）；附录A；以及规范 1、4、6、10 和 11。
(iii) 调解员将向仲裁庭简略说明ICANN 和工作组对于拟定修订的各自建议。
(iv) 工作组或ICANN 不得将本协议的拟定修订提交仲裁，除非对于工作组来说拟定修订获得了注册管理运行机构批准，或对于ICANN 来说拟定修订获得了ICANN 董事会批准。
(v) 为使仲裁庭批准由ICANN 或工作组提出的拟定修订，仲裁庭经审查必须得出以下结论，即此类修订符合对ICANN 核心价值观（其定义详见ICANN 章程）的均衡应用原则，且能够合理平衡适用注册管理运行机构及ICANN（视情况而定）的商业成本和收益，并实现拟定修订所努力达致的公共利益。如果仲裁庭的审查结论认为ICANN 或工作组提出的拟定修订符合前述标准，此类修订应自ICANN 向注册管理运行机构发出通知后六十(60) 个日历日生效，并被正式视为本协议的获批修订。
(f) 对于与ICANN 提出的拟定修订相关的获批修订，注册管理机构可根据第 7.6 节的规定向ICANN 书面申请修订豁免。
(g) 无论本 7.7 节中有何相反规定，(a) 如果注册管理运行机构向ICANN提供合理满意的证据证明，获批修订将大幅增加提供注册管理机构服务的成本，则 ICANN 将允许获批修订在最长一百八十(180) 个日历日后对注册管理运行机构生效，(b)如果注册管理运行机构根据第 4.4(b) 节向ICANN 发出不可撤消的协议终止通知，则根据第 7.7 节采纳的获批修订不应对注册管理运行机构生效。
7.8 无第三方受益人。本协议不应解释为ICANN 或注册管理运行机构给本协议之外的任何一方（包括任何注册服务机构或注册域名持有人）施加任何义务。
7.9 一般通知。除第 7.6 和 7.7 节规定的通知以外，有关本协议的所有通知的发送形式为：(i) 按照下面列出的地址以书面形式发往相应方；或 (ii) 通过提供的下列电子 邮件发出。除非相应方已通知变更邮政地址或电子邮件地址，否则将按照本协议提供的下列地址发送有关本协议的所有通知。发布第 7.6 和 7.7 节规定的所有通知时，相应方应在 ICANN 的网站上发布适用信息，同时通过电子邮件将此类信息发送至注册管理运行机
构。如一方要更改下文的通知联系信息，必须在此类变更发生后三十(30) 个日历日内通
知对方。除第 7.6 和 7.7 节规定的通知以外，在下列情况中，本协议要求的任何通知都将视为已适当提供：(i) 如果是纸面通知，当面递送或通过快递服务递送并收到送达确认；
(ii) 如果是电子邮件形式的通知，收到接收方电子邮件服务器的送达确认，但前提是，通过电子邮件传送通知后应在三(3) 个日历日内由正常邮递服务寄送一份副本。对于第 7.6和 7.7 节要求的任何通知，如果在ICANN 网站上以电子形式发布并收到电子邮件服务器 送达确认，均应视为已适当提供。如果有切实可行的其他通知方式，例如通过安全网站发布通知，双方将按本协议合作实施此类通知方式。
发送给ICANN 的地址为：
互联网名称与数字地址分配机构 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536
美国
电话：+1-310-301-5800
收件人：总裁兼首席执行官
同时必须将副本发送至：总法律顾问电子邮件：（按当时的指定地址。）
注册管理运行机构的通信地址如下：
[ ]
[ ]
[ ]
电话：
同时必须将副本发送至：
电子邮件：（按当时的指定地址。）
7.10 整个协议。本协议（包括通过引用本协议中的URL 地址而并入的规范和文件）构成双方就TLD 的运营而达成的完整协议，取代双方此前在该问题上的所有口头或书面协议、谅解、谈判和讨论。
7.11 英语语言控制。虽然注册管理运行机构可能会收到本协议和/或规范的翻译版本，但本协议及其所有引用规范的英语版本是约束协议双方的正式版本。如果本协议的任何翻译版本和英语版本存在冲突或差异，则以英语版本为准。根据本协议发出的通知、任命、决议和规范均以英语书写。
7.12 所有权。本协议中的任何内容均不应解释为(a) 确立或授予注册管理运行机构对TLD 或者TLD 文本字符串中包含的字母、单词、符号或其他字符具有任何资产所有权或相关利益，或(b) 影响注册管理运行机构的任何现有知识产权或所有权。
7.13 可分割性；与法律的冲突。本协议应视为可分割；本协议任何条款的无效 或不可执行，不影响本协议其他部分或本协议任何其他条款的效力或执行，它们具有完全的执行力和效力。如果此处任何条款被认为无效或不可执行，双方应真诚地进行协商，以修改本协议，最大程度地实现双方的最初目的。ICANN 和工作组将相互协作制定 ICANN规程，供 ICANN 审核和考量适用法律与本协议非 RDDS（如规范 4 中定义）相关条款之间的冲突。在 ICANN 制定并实施此类规程之前，ICANN 将采用处理 WHOIS 与隐私法之间冲突的相似 ICANN 规程，审核和考量适用法律与本协议非 RDDS 相关条款之间的冲 突。
7.14 法院指令。ICANN 将遵守来自具有司法管辖权的法院的任何指令，包括来自那些只有政府许可或无异议才能获得TLD 授权的辖区的任何指令。尽管本协议中还有其他条款，但ICANN 实施任何此类指令都不算是违反本协议。
7.15 保密
(a) 根据第 7.15(c) 节，协议期间及随后三(3) 年，各方应确保自身及其附属机构的高级职员、董事、雇员和代理人对属于、披露方标记为或以书面方式向接收方指定为“机密商业秘密”、“机密商业信息”或“机密金融信息”（统称为“机密信
息”）的任何信息进行保密，并不得直接或间接公开或以其他方式向任何第三方披露，本协议条款允许的披露除外。
(b) 第 7.15(a) 节规定的保密义务不适用于以下机密信息：(i) 现在或今后并非因接收方违反本协议而进入公共领域（例如因公开使用、发布、成为常识或其他方 式）的机密信息；(ii) 有文件或其他有力证据证明相关信息在披露方披露之前已属接收方所有且接收方对此类信息无保密义务；(iii) 随后由接收方从对此类信息无保密义务的第三方处获得；(iv) 由第三方发布，或通过其他并非接收方过错的方式进入公共领域；或(v)可通过文件或其他有力证据证明属于接收方未参考披露方的保密信息而独立生成的信息，或者第三方未参考披露方的保密信息而为接收方独立生成的信息。
(c) 各方应有权披露机密信息，只要此类披露 (i) 是为回应有司法管辖权的法院的有效指令，或根据接收方律师的合理意见，此类披露为适用法律的要求；但前提是接收方应首先通知披露方并给予披露方合理机会撤销此类指令或取得保护令或保密处理指令，要求此类法院或其他第三方接收方对受限于此类指令或其他适用法律的保密信息保密，除非此类指令或适用法律不允许接收方发出此类通知，或 (ii) 是接收方或其附属机构因根据本协议进行活动时可能需要或有帮助，而向其或其各自的律师、审计师、顾问、咨询顾问、承包商或其他第三方披露，以供此类个人或实体使用，前提是此类第三方应负有至少与本协议中规定的保密义务同样严格的保密义务，无论是通过书面协议或通过专业责任标准。
[注：下节仅适用于国际政府间组织或政府实体。]
7.16 关于国际政府间组织或政府实体的特殊条款。
(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.16 节中任何其他条款如何规定，在ICANN 决议出台之后、仲裁员依据上述第 7.16(d) 节做出裁定之前，ICANN 可以在事先与注册管理运行机构商议的前提下，采取其认为有必要的合理技术措施来确保注册管理机构服务、互联网和DNS的安全性与稳定性。这些合理的技术措施应由ICANN 临时执行，直到上述第 7.16(d) 节中规定的仲裁程序生成判决之日或完全解决与适用法律间冲突之日为止（以两者中较早的日期为准）。若注册管理运行机构不同意ICANN 采取的此类技术措施，注册管理运行机构可以依据上述第 5.2 节条款提交问题进行有约束力的仲裁，在此过程中ICANN 可以继续执行此类技术措施。若ICANN 执行此类措施，则注册管理运行机构应支付ICANN 为此付出的所有费用。此外，若ICANN 执行此类措施，ICANN 应该保留并可执行其依据“持续经营方案”和替代经营方案（如适用）应享有的权利。
* * * * *
双方兹派其正式授权代表签署本协议，特此为证。互联网名称与数字地址分配机构
代表：
[ ]
总裁兼首席执行官日期：
[注册管理运行机构]
代表：
[ ]
[ ]
日期：
附录 A
批准的服务
ICANN gTLD《申请人指导手册》（位于https://newgtlds.icann.org/en/applicants/agb）和RSEP 规定了审议拟定注册管理机构服务的流程。注册管理运行机构可提供本协议条款要求的任何服务。此外，以下服务（如有）特别指定为已在协议生效日期前获得ICANN批准，且注册管理运行机构可提供此类服务：
1. DNS 服务– TLD 区域内容
无论本协议中的其他表述如何，如gTLD《申请人指导手册》第 2.2.3.3 节所述，TLD DNS
服务的允许内容如下：
1.1. 对于“互联网”(IN) 类别：
1.1.1. Apex SOA 记录
1.1.2. Apex NS 记录以及适用于TLD DNS 服务器的在辖区粘附记录
1.1.3. TLD 注册域名DNS 服务器的NS 记录和辖区内粘合记录
1.1.4. 适用于TLD 中注册域名的DS 记录
1.1.5. 与TLD 区域签名相关的记录（如RRSIG、DNSKEY、NSEC、NSEC3PARAM 和
NSEC3）
1.1.6. 针对区域版本控制目的的 Apex TXT 记录
1.1.7. 适用于自动DNSSEC 签名信令的 Apex TYPE65534 记录
1.2. 对于“Chaos”(CH) 类别：
1.2.1. 针对服务器版本/标识的TXT 记录（如“version.bind.”、“id.server.”、 “authors.bind”和/或“hostname.bind.”的 TXT 记录）
（注：上述语句有效排除了能够在TLD 区域启用无点域名的DNS 资源记录（如apex A、 AAAA 和 MX 记录）和其他相关记录。）
如果注册管理运行机构希望在其TLD DNS 服务中纳入任何DNS 资源记录类型或类别（除以上第 1.1 节或 1.2 节所列类型外），则必须在其提案中对此进行详细说明，并提交注册管理机构服务评估流程(RSEP) 申请。此提案将根据RSEP 进行评估，以确定此服务是否会对DNS 的安全性或稳定性造成实质性的不利影响。注册管理运行机构认同并承认，即
使基于使用TLD 区域中不常用的DNS 资源记录和/或类别的服务已通过批准，但由于缺少软件支持，也可能不能供所有用户使用。
规范 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
数据托管要求
注册管理运行机构将根据与注册管理机构协议相关的数据托管服务的规定，指定某一独立实体作为数据托管代理（以下简称“托管代理”）。注册管理运行机构与托管代理之间 达成的任何数据托管协议，均应包含以下第A 部分中规定的技术规范，以及第B 部分中规定的法律要求，并且必须将ICANN 认定为第三方受益人。除以下要求外，数据托管协议还可以包含其他规定，但这些规定不能破坏下面提供的必要条款，或与这些条款相抵 触。
第 A 部分 - 技术规范
1. 寄存。寄存有两种类型：完全寄存和差别寄存。对于这两种类型，数据托管要考 虑的全体注册管理机构对象是指提供所有批准的注册管理机构服务所必需的对象。
1.1. “完全寄存”由反映此类完全寄存提交到托管代理当天截至 00:00:00 UTC
（世界协调时）的注册管理机构状态的数据组成。
1.2. “差别寄存”是指反映未在上次完全寄存或差别寄存中（根据具体情况） 包含的所有交易的数据。每个差别寄存都将包含自上一个寄存完成时起至每天（星期日除外）00:00:00 UTC 为止的所有数据库交易。差别寄存必须包括自进行最新完全寄存或差别寄存后未包括的或已更改的完整托管记录（即所有添加、修改或删除的数据），见以下规定。
2. 寄存时间表。注册管理运行机构将根据以下要求每日提交一组托管文件：
2.1. 每个星期日，必须在 23:59 UTC 之前向托管代理提交一次完全寄存。
2.2. 每周其余六(6) 天，必须在 23:59 UTC 之前向托管代理提交一次完全寄存或相应差别寄存。
3. 托管格式规范。
3.1. 寄存格式。注册管理机构对象，例如域、联系人、域名服务器、注册服务机构等将编译成RFC 8909（请参见本规范第A 部分第 9 节参考 1）及RFC 9022（请参见本规范第A 部分第 9 节参考 2）中描述的构建文件（统称为 “DNDE 规范”）。DNDE 规范将部分要素描述为可选；注册管理运行机构将在这些要素可用时将其纳入寄存。将使用UTF-8 字符编码。
3.2. 扩展性。如果注册管理运行机构提供需要提交上述以外的其他数据的其他 注册管理机构服务，应根据具体情况逐个定义“扩展性方案”以体现相应数据。这些“扩展性方案”将如本规范第A 部分第 9 节参考 2 中所述指定。 “扩展性方案”相关的数据将纳入本规范第A 部分第 3.1 节中所述的寄存文
件中。ICANN 和各注册管理运行机构应共同协作，就此类新对象的数据托管规范达成一致。
4. 寄存文件的处理。建议使用压缩技术以缩短电子数据传输时间和降低存储容量要 求。将使用数据加密来保护注册管理机构托管数据的隐私性。经压缩和加密处理的文件将按照OpenPGP 消息格式(RFC 4880) 转换为二进制OpenPGP 格式，请参阅本规范第A 部分第 9 节参考 3。公钥加密、对称密钥加密、哈希和压缩技术可接受的算法为RFC 4880 中列举的算法，而不是OpenPGP IANA 注册管理机构中标记为已弃用的算法（请参阅本规范第A 部分第 9 节参考 4），而且这些算法是免版税 的。原始文本格式的数据文件的处理流程如下：
(1) 如本规范第A 部分第 9 节参考 1 中所述寄存的XML 文件必须按第 5 节的规定命名为包含文件，但应使用xml 作为扩展名。
(2) 数据文件均整合在一个命名同(1) 的tarball 压缩文件中，但应使用tar 作为扩展名。
(3) 创建经压缩和加密的OpenPGP 消息时，就将tarball 文件作为唯一输入文件。根据RFC 4880，建议的压缩算法为ZIP。压缩数据将使用托管代理的公钥进行加密。根据RFC 4880，建议的公钥加密算法为Elgamal 和RSA。根据RFC 4880，建议的对称密钥加密算法为TripleDES、AES128 和 CAST5。
(4) 文件在压缩和加密后如果超过托管代理同意的文件大小限制，必要时可进行分割。本节中，分割文件的各个部分或整个文件（如未分割）将称为已处理文件。
(5) 将使用注册管理运行机构私钥为每一个已处理文件生成一个数字签名文件。根据RFC 4880 第 9 节（参考 3），数字签名文件将为二进制OpenPGP 格 式，且不会压缩和加密。根据RFC 4880，建议的数字签名算法为DSA 和 RSA。对于数字签名中的哈希算法，推荐使用SHA256。
(6) 然后，将根据托管代理和注册管理运行机构之间达成的协议，通过安全电子机制（例如，SFTP、SCP、HTTPS 文件上传等）将已处理文件和数字签名文件传输给托管代理。如果经ICANN 授权，可通过物理介质（例如 CD-
ROM、DVD-ROM 或USB 存储设备）进行非电子传输。
(7) 托管代理随后将使用本规范第A 部分第 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 节中指定的批量注册数据访问文件）；
(4) “thick-{gurid}”（如果数据代表规范 4 第 3.2 节中定义的特定注册服务机构的详尽注册数据）。{gurid} 元素必须替换为与数据相关联的IANA 注册服务机构ID。
5.4. {#} 将替换为该文件在一系列文件中的位置，以“1”开头；如果只有一个文件，则必须替换为“1”。
5.5. {rev} 将替换为文件的修订（或重新发送）次数，以“0”开头。
5.6. {ext} 将替换为“sig”（如果是准同名文件的数字签名文件）。否则，将替换为“ryde”。
6. 公钥分发。每个注册管理运行机构和托管代理将按照指定的电子邮件地址将公钥 分发给另一方（注册管理运行机构或托管代理，根据具体情况而定）。各方应该通过回复电子邮件确认收到另一方的公钥，分发方随后将通过脱机方法（如面对面、电话等）重新确认所传输密钥的真实性。通过这种方式，可确认公钥被传输给能够通过分发方运营的邮件服务器收发邮件的用户。托管代理、注册管理运行机构和 ICANN 都将按照上述程序交换公钥。
7. 寄存通知。注册管理运行机构每提交一个寄存，都必须同时向托管代理和ICANN提交（使用draft-lozano-icann-registry-interfaces 中所述的 API，参阅本规范第 A部分第 9 节参考 5 （“接口规范”））一份书面声明（可以通过经验证的电子邮件提交），其中应包含一份在创建寄存时生成的报告，并声明该寄存已经注册管理运行机构检查，是完整而准确的。此声明必须由注册管理运行机构或其指定方制定和提交，前提是该指定方不是托管代理或者托管代理的任何附属机构。注册管理运行机构将在其声明中包括寄存的“id”和“resend”属性。本规范第 A 部分第 9 节参考 1 对这些属性提供了说明。
如果尚未形成FRC，注册管理运行机构可在生效日期使用接口规范的最新草案版 本。注册管理运行机构可选择在生效日期后使用较新版本的接口规范。一旦接口规范作为RFC 发布，注册管理运行机构需在发布后的一百八十(180) 个日历日内执行该版本的接口规范。
8. 验证程序。
(1) 验证每个已处理文件的签名文件。
(2) 如果已处理文件是某个较大文件的分割部分，则需进行合并。
(3) 随后对先前步骤中包含的每个文件进行解密和解压缩。
(4) 然后根据本规范第A 部分第 9 节参考 1 中定义的格式对先前步骤中包含的每个数据文件进行验证。
(5) 数据托管代理可延长验证流程（如本规范 2 第A 部分参考 2 所定义）以及此参考中包含的任何其他数据托管验证流程。
如果在上述任何步骤中发现任何差异，则寄存将被视为不完整。
9. 参考。
(1) 注册数据托管规范，https://www.rfc-editor.org/rfc/rfc8909.txt
(2) 域名注册数据(DNRD) 对象映射，https://www.rfc- editor.org/rfc/rfc9022.txt
(3) OpenPGP 消息格式，https://www.rfc-editor.org/rfc/rfc4880.txt
(4) OpenPGP 参数，
https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml
(5) ICANN 注册管理机构接口，https://datatracker.ietf.org/doc/draft-lozano- icann-registry-interfaces
第 B 部分– 法律要求
1. 托管代理。注册管理运行机构在签署托管协议之前，必须向ICANN 告知其托管代理的身份，同时向ICANN 提供托管代理的联系信息和相关托管协议副本以及所有相关修订。此外，签订托管协议前，注册管理运行机构必须获得ICANN 的同意以
(a) 使用指定托管代理，(b) 签订提供的托管协议。必须明确将ICANN 指定为此托管协议的第三方受益人。ICANN 保留酌情拒绝同意任何托管代理、托管协议或任何相关修订的权利。
2. 费用。注册管理运行机构必须直接或让其代表代为向托管代理付费。如果注册管 理运行机构未能在截止日期前付清任何费用，托管代理将向ICANN 发出有关未付费情况的书面通知，而ICANN 可在收到托管代理的书面通知后十五(15) 个日历日内支付过期未付费用。在ICANN 支付过期未付费用后，ICANN 应向注册管理运行机构索要该笔费用，而注册管理运行机构必须将该笔费用连同按注册管理机构协议需交纳的下一笔费用交给ICANN。
3. 所有权。在注册管理机构协议有效期内，寄存所有权始终归注册管理运行机构所 有。因此，注册管理运行机构应将此类寄存的任何所有权（视具体情况而定，可能包括知识产权）分配给ICANN。在注册管理机构协议期限内，如果通过托管向 ICANN 让渡任何寄存，则注册管理运行机构对此寄存享有的任何知识产权将在非独占、永久、不可撤销、免版税和已付费的基础上自动授予给ICANN 或ICANN 书面指定的一方以用于TLD 的运营、维护或转移。
4. 完整性和保密性。托管代理必须：(i) 将寄存保管于安全、经锁定和对环境安全的设施内，该设施只能由托管代理的授权代表访问；(ii) 使用在商业上合理的措施保护寄存的完整性和保密性，并 (iii) 保留和保护每个寄存一(1) 年时间。ICANN 和注册管理运行机构将有权检查托管代理的相应记录，此类检查应有事先的合理通知，并且须在正常工作时间进行。注册管理运行机构和ICANN 将有权指定第三方审计师不时审计托管代理是否符合本规范 2 中的技术规范和维护要求。
如果托管代理从法院或其他司法仲裁庭收到与寄存披露或让渡相关的传票或其他任何命令，除非有法律禁止，否则托管代理应立即通知注册管理运行机构和
ICANN。通知注册管理运行机构和ICANN 后，托管代理应提供足够的时间供注册管理运行机构或ICANN 对此类命令提出质疑（此责任应由注册管理运行机构或 ICANN 承担）；但托管代理并未放弃对任何此类命令表明立场的权利。托管代理将与注册管理运行机构或ICANN 通力合作，以支持撤消或限制任何此类传票，所需费用由各方自行承担。任何一方如申请其他协助，则应向托管代理支付标准费用，或在提交具体申请后根据报价支付相关费用。
5. 副本。为了遵守托管协议的条款与规定，托管代理可复制任何寄存。
6. 寄存的让渡。如果托管代理收到注册管理运行机构的有关请求，或收到ICANN 声明下列情况之一的书面通知，则托管代理应在由注册管理运行机构承担费用的情况
下，在二十四(24) 小时内将其掌握的所有寄存提供给ICANN 或其指定方进行电子下载（除非另有要求）：
6.1. 注册管理机构协议已到期且未续订，或者注册管理机构协议已终止；或
6.2. 寄存预定交付日期后五(5) 个日历日内，ICANN 未自托管代理收到本规范第 B 部分第 7.1 和 7.2 节所述的通知；(a) ICANN 已向托管代理和注册管理运行机构通知该情况；(b) 发出此类通知后的七(7) 个日历日内，ICANN 未收到来自托管代理的通知；或
6.3. ICANN 已自托管代理处收到本规范第B 部分第 7.1 和 7.2 节所述的关于特定日期最新托管寄存验证失败的通知或寄存丢失的通知，而该通知针对应在周日进行的寄存（即完全寄存）；(a) ICANN 通知注册管理运行机构其已收到该通知；(b) 发出此类通知后七(7) 个日历日内，ICANN 未自托管代理处收到本规范第B 部分第 7.1 和 7.2 节所述的关于此类完全寄存修正版本验证的通知；或
6.4. ICANN 在过去三十(30) 个日历日内自托管代理处收到五次关于应在周一至周六进行的托管寄存（即差别寄存）丢失或失败的通知，且(x) ICANN 通知注册管理运行机构其已收到此类通知；(y) ICANN 在向注册管理运行机构发出此类通知后七(7) 个日历日内未收到来自托管代理的关于此类差别寄存修正版本验证的通知；或
6.5. 注册管理运行机构已：(i) 停止执行其正常业务；或 (ii) 申请破产、无力偿 债或按世界上任何地区的任何法律管辖范围的法律而处于与上述情况类似的状态；或
6.6. 注册管理运行机构的关键注册职能出现问题，而ICANN 已根据本协议第
2.13 节声明其权利；或
6.7. 具备有效管辖权的法院、仲裁机构、立法机构或政府部门命令将寄存让渡给
ICANN；或
6.8. 根据本协议第 2.11 节中的规定进行合同和运营合规审计。
托管代理在注册管理机构协议或托管协议到期或终止时必须将所有寄存让渡给 ICANN，除非托管代理先前已将注册管理运行机构的寄存让渡给ICANN 或ICANN指定的一方。
7. 寄存验证。
7.1. 在收到每个寄存或更正寄存后二十四(24) 小时内，托管代理必须验证每个寄存的格式和完整性，并向ICANN 提交一份针对每个寄存生成的通知。报
告应使用draft-lozano-icann-registry-interfaces 中所述的 API 通过电子方式寄送，请参阅本规范第A 部分第 9 节参考 5。
7.2. 如果托管代理发现任何寄存未能通过验证程序或如果托管代理未收到预定寄存，托管代理必须在收到此类不合格寄存后或此类寄存截止期限后二十四
(24) 小时内，通过电子邮件、传真或电话通知注册管理运行机构和ICANN
（使用draft-lozano-icann-registry-interfaces 中所述的 API，请参阅本规范第A 部分第 9 节参考 5）此类不合格或未收到情况。注册管理运行机构在获悉此类验证或寄送失败的情况后，必须开始制定寄存的修改、更新、修正和其他修补程序，以使寄存能够寄送并通过验证程序，并将此类修补程序尽快提交给托管代理。
8. 修订。在本规范 2 受到任何修订或修改后十(10) 个日历日内，托管代理和注册管理运行机构应修订托管协议的条款，使其符合本规范 2。如果本规范 2 与托管协议之间有冲突，以本规范 2 为准。
9. 保障。如果第三方对注册管理运行机构和ICANN 及其各自的董事、高级职员、代理人、员工、成员和股东（“受保障人”）提出了与托管代理及其董事、高级职 员、代理人、员工和承包商的失实陈述、疏忽或不当行为相关的任何索赔、起诉、损害赔偿、诉讼、责任、义务、成本、费用、收费及其他任何费用（包括合理的律师费和成本），托管代理应确保“受保障人”绝对永久性免于承担任何此类费用或责任。
规范 3
注册管理运行机构月度报告的格式和内容
注册管理运行机构应使用draft-lozano-icann-registry-interfaces 中所述的 API（请参阅规范 2 第A 部分第 9 节参考 5）提供每个gTLD 的一组月度报告，报告应包含以下内容。
将来ICANN 可能会要求以其他方式、使用其他格式递交报告。ICANN 将采用合理的商业措施对所报告的信息保密，直至报告相关月份结束后三(3) 个月。除非本规范 3 中另有规定，涉及的任何特定时间是指世界协调时(UTC)。月度报告应由反映当月结束时(UTC) 注册管理机构状态的数据组成。
1. 各注册服务机构交易报告。如RFC 4180 中的规定，本报告应该使用逗号分隔值格式文件编制。文件应命名为“gTLD-transactions-yyyymm.csv”，其中“gTLD”为 gTLD 名称；如果是IDN-TLD，则应使用A 标签；“yyyymm”是所报告的年份和月份。针对每个注册服务机构，文件应包含以下字段：
字段 号 | 字段名称 | 描述 |
01 | registrar-name | 注册服务机构的公司全称，即向IANA 注册的名称 |
02 | iana-id | 如果注册管理运行机构扮演注册服务机构的角色 （即不使用ICANN 认证注册服务机构），应根据注册类型使用 9998 或 9999（如规范 5 所述），否则，应根据 https://www.iana.org/assignments/registrar-ids的规定使用支持注册服务机构IANA ID |
03 | total-domains | 未清除的EPP 状态（pendingCreate 除外）的所有已提供域名 |
04 | total-nameservers | 未清除的EPP 状态（pendingCreate 除外）的、与TLD 注册域名相关的所有域名服务器（主机对象或域名服务器主机作为域名属性） |
05 | net-adds-1-yr | 在最初一(1) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
06 | net-adds-2-yr | 在最初两(2) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
07 | net-adds-3-yr | 在最初三(3) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
08 | net-adds-4-yr | 在最初四(4) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
09 | net-adds-5-yr | 在最初五(5) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
10 | net-adds-6-yr | 在最初六(6) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
11 | net-adds-7-yr | 在最初七(7) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
12 | net-adds-8-yr | 在最初八(8) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
13 | net-adds-9-yr | 在最初九(9) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
14 | net-adds-10-yr | 在最初十(10) 年期限内成功注册（即不处于EPP pendingCreate 状态）的域数量（且在新注宽限期内未删除）。新注宽限期结束的当月必须报告交易。 |
15 | net-renews-1-yr | 在新的一(1) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
16 | net-renews-2-yr | 在新的两(2) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数 |
量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 | ||
17 | net-renews-3-yr | 在新的三(3) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
18 | net-renews-4-yr | 在新的四(4) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
19 | net-renews-5-yr | 在新的五(5) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
20 | net-renews-6-yr | 在新的六(6) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
21 | net-renews-7-yr | 在新的七(7) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
22 | net-renews-8-yr | 在新的八(8) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
23 | net-renews-9-yr | 在新的九(9) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
24 | net-renews-10-yr | 在新的十(10) 年续订期内自动或通过命令成功续订（即不处于EPP pendingRenew 状态）的域数量（且在续订或自动续订宽限期内未删除）。续订或自动续订宽限期结束的当月必须报告交易。 |
25 | transfer-gaining-successful | 由该注册服务机构发起、成功完成（明确或自动批准）且在转让宽限期内未删除的域转让数。转让宽限期结束的当月必须报告交易。 |
26 | transfer-gaining-nacked | 由该注册服务机构发起而遭另一注册服务机构拒绝（例如EPP transfer op="reject"）的域转让数 |
27 | transfer-losing-successful | 由另一注册服务机构发起且成功完成（明确或自动批准）的域转让数 |
28 | transfer-losing-nacked | 由另一注册服务机构发起而遭该注册服务机构拒绝（例如EPP transfer op="reject"）的域转让数 |
29 | transfer-disputed-won | 该注册服务机构胜诉的转让争议数（作出裁决的当月报告） |
30 | transfer-disputed-lost | 该注册服务机构败诉的转让争议数（作出裁决的当月报告） |
31 | transfer-disputed-nodecision | 涉及该注册服务机构且存在分歧或未做出裁定的转让争议数（作出裁决的当月报告） |
32 | deleted-domains-grace | 新注宽限期内删除的域（不包括处于EPP pendingCreate 状态时删除的域名）。清除域名的当月必须报告删除事件。 |
33 | deleted-domains-nograce | 新注宽限期外删除的域（不包括处于EPP pendingCreate 状态时删除的域名）。清除域名的当月必须报告删除事件。 |
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-activity-yyyymm.csv”，其中“gTLD”为 gTLD 名称；如果是IDN-TLD，则应使用A 标签；“yyyymm”是所报告的年份和月份。文件应包含以下字段：
字段号 | 字段名称 | 描述 |
01 | operational-registrars | 报告期结束时生产系统中运营的注册服务机构的数量 |
02 | zfa-passwords | 报告期结束时活动的区文件访问密码数量，如果使用了集中化域资料服务(CZDS) 向最终用户提供区文件，则可能使用“CZDS”代替活动的区文件访问密码的数量 |
03 | whois-43-queries | 报告期间响应的WHOIS（端口 43）查询数；如果在WHOIS 服务终止日期（如规范 4 中定义）之后未提供WHOIS（端口 43）服务，则应在该日期之后使用空值 |
04 | web-whois-queries | 报告期间响应的基于网络的WHOIS 查询数，不包括可搜索的WHOIS；如果在WHOIS 服务终止日期之后未提供基于网络的WHOIS 服务，则应在该日期之后使用空值 |
05 | searchable-whois-queries | 报告期间响应的可搜索WHOIS 查询数；如果在报告期间未提供可搜索WHOIS 服务，则应使用空值 |
06 | dns-udp-queries-received | 报告期间通过UDP 传输接收的DNS 查询数 |
07 | dns-udp-queries-responded | 报告期间响应的通过UDP 传输接收的DNS 查询数 |
08 | dns-tcp-queries-received | 报告期间通过TCP 传输接收的DNS 查询数 |
09 | dns-tcp-queries-responded | 报告期间响应的通过TCP 传输接收的DNS 查询数 |
10 | srs-dom-check | 报告期间响应的SRS（EPP 和任何其他接口）域名“检查”请求数 |
11 | srs-dom-create | 报告期间响应的SRS（EPP 和任何其他接口）域名“创建”请求数 |
12 | srs-dom-delete | 报告期间响应的SRS（EPP 和任何其他接口）域名“删除”请求数 |
13 | srs-dom-info | 报告期间响应的SRS（EPP 和任何其他接口）域名“信息”请求数 |
14 | srs-dom-renew | 报告期间响应的SRS（EPP 和任何其他接口）域名“续订”请求数 |
15 | srs-dom-rgp-restore-report | 报告期间响应的递交恢复报告的SRS（EPP 和任何其他接口）域名RGP“恢复”请求数 |
字段号 | 字段名称 | 描述 |
16 | srs-dom-rgp-restore-request | 报告期间响应的SRS（EPP 和任何其他接口）域名RGP“恢复”请求数 |
17 | srs-dom-transfer-approve | 报告期间响应的批准转让的SRS（EPP 和任何其他接口）域名“转让”请求数 |
18 | srs-dom-transfer-cancel | 报告期间响应的取消转让的SRS（EPP 和任何其他接口）域名“转让”请求数 |
19 | srs-dom-transfer-query | 报告期间响应的查询转让的SRS（EPP 和任何其他接口）域名“转让”请求数 |
20 | srs-dom-transfer-reject | 报告期间响应的拒绝转让的SRS（EPP 和任何其他接口）域名“转让”请求数 |
21 | srs-dom-transfer-request | 报告期间响应的请求转让的SRS（EPP 和任何其他接口）域名“转让”请求数 |
22 | srs-dom-update | 报告期间响应的SRS（EPP 和任何其他接口）域名“更新”请求数（不包括RGP 恢复请求） |
23 | srs-host-check | 报告期间响应的SRS（EPP 和任何其他接口）主机“检查”请求数 |
24 | srs-host-create | 报告期间响应的SRS（EPP 和任何其他接口）主机“创建”请求数 |
25 | srs-host-delete | 报告期间响应的SRS（EPP 和任何其他接口）主机“删除”请求数 |
26 | srs-host-info | 报告期间响应的SRS（EPP 和任何其他接口）主机“信息”请求数 |
27 | srs-host-update | 报告期间响应的SRS（EPP 和任何其他接口）主机“更新”请求数 |
28 | srs-cont-check | 报告期间响应的SRS（EPP 和任何其他接口）联系人“检查”请求数 |
29 | srs-cont-create | 报告期间响应的SRS（EPP 和任何其他接口）联系人“创建”请求数 |
30 | srs-cont-delete | 报告期间响应的SRS（EPP 和任何其他接口）联系人“删除”请求数 |
31 | srs-cont-info | 报告期间响应的SRS（EPP 和任何其他接口）联系人“信息”请求数 |
32 | srs-cont-transfer-approve | 报告期间响应的批准转让的SRS（EPP 和任何其他接口）联系人“转让”请求数 |
字段号 | 字段名称 | 描述 |
33 | srs-cont-transfer-cancel | 报告期间响应的取消转让的SRS（EPP 和任何其他接口）联系人“转让”请求数 |
34 | srs-cont-transfer-query | 报告期间响应的查询转让的SRS（EPP 和任何其他接口）联系人“转让”请求数 |
35 | srs-cont-transfer-reject | 报告期间响应的拒绝转让的SRS（EPP 和任何其他接口）联系人“转让”请求数 |
36 | srs-cont-transfer-request | 报告期间响应的请求转让的SRS（EPP 和任何其他接口）联系人“转让”请求数 |
37 | srs-cont-update | 报告期间响应的SRS（EPP 和任何其他接口）联系人“更新”请求数 |
38 | rdap-queries | 报告期间响应的RDAP 查询数 |
作为“标题行”，第一行应包括与上表完全相同的字段名称，如RFC 4180 第 2 节中所述。除上述行之外，不得包含任何其他行。如RFC 4180 所述，换行符应该为<U+000D,
U+000A>。
对于作为单一实例共享注册系统一部分的gTLD：(1) 注册管理机构职能活动报告中的字段whois-43-queries、web-whois-queries、searchable-whois-queries 和rdap-queries 应当与单一实例共享注册系统中针对gTLD 报告的查询数总和相匹配；(2) 如果查询与上述
(1) 中的字段相关，而注册管理运行机构无法确定要统计查询的TLD（例如，针对运营多个共享同一RDAP 基准URL 的TLD 的注册服务机构进行的注册服务机构查询），注册管理机构可以灵活选择利用单一实例共享注册系统在gTLD 之间分配这些查询的方式；以及
(3) 注册管理机构职能活动报告可以包含系统中所有gTLD 的所有联系人或托管交易。
规范 4
注册数据发布服务
1. 注册数据目录服务
1.1. 定义。
1.1.1 “注册数据访问协议”（或称为“RDAP”）是一个互联网协议，可提供“RESTful”网络服务，以便从域名注册管理机构和地区互联网注册管理机构检索注册元数据。
1.1.2 “RDAP 目录服务”是指使用STD 95 (https://www.rfc- editor.org/refs/ref-std95.txt) 及其后续标准中所述的 RDAP 的注册数据目录服务。
1.1.3 “注册数据目录服务”（或称为“RDDS”）是指WHOIS 数据目录服务（如本规范 4 中所定义）和注册数据访问协议(RDAP) 目录服务
（如本规范 4 中所定义）的集合。
1.1.4 “WHOIS 数据目录服务”是指根据RFC 3912 通过端口 43 提供的 WHOIS 服务和可以提供注册数据免费公众查询访问的基于网络的 WHOIS 服务的集合。
1.1.5 “RDAP 启动期”是指截至 2024 年 2 月 3 日的时间段。
1.1.6 “WHOIS 服务终止日期”是指“RDAP 启动期”到期后的 360 天，前提是ICANN 和注册管理机构利益相关方团体双方同意延迟WHOIS服务终止日期。如果ICANN 首席执行官（“CEO”）或注册管理机构利益相关方团体主席（“主席”）希望讨论延迟WHOIS 服务终止日期的相关事宜，CEO 或主席（如适用）应向另一方发出书面通
知，通知中应阐明拟定延迟的合理详细信息。
1.2. RDAP 目录服务
1.2.1 注册管理运行机构应实施https://icann.org/gtld-rdap-profile 上发布的最新版《RDAP 技术实施指南》和《RDAP 响应简介》。注册管理运行机构将在收到ICANN 通知之后的一百八十(180) 个日历日内实施新版《RDAP 技术实施指南》和《RDAP 响应简介》。
1.2.2 注册管理运行机构应针对以下内容提供查询支持：
(1) RFC 9082 的“域路径段规范”部分中描述的域信息。
(2) RFC 9082 的“域名服务器路径段规范”部分中描述的域名服务器信息；但是，如果注册管理运行机构将域名服务器指定为 EPP 中的域属性，则该注册管理运行机构无需（但仍可以选 择）支持域名服务器查询。
(3) RFC 9082 的“实体路径段规范”部分中描述的注册服务机构信息。
(4) RFC 9082 的“帮助路径段规范”部分中描述的帮助信息。
1.2.3 ICANN 保留通过与注册数据相关的适用IETF 流程指定批准为“互联网标准”（而不是信息或实验标准）的替代格式和协议的权利。根据此类规范，ICANN 应该：(a) 与gTLD 注册管理机构和ICANN 认证注册服务机构合作，以定义实施适用标准所需的所有运营要求；以及
(b) 如果适用，启动协商程序以定义所有报告要求（如果有）以及与类似情况的服务相适应的合理服务水平要求。
1.3. 可搜索性。针对注册数据提供搜索功能属于可选服务，但如果是由注册管理运行机构提供此服务，则须符合本节中所述的规范。
1.3.1 注册管理运行机构将提供可搜索性作为基于网络的服务。
1.3.2 注册管理运行机构将对以下每个字段提供部分匹配功能：域名、联系人和注册人姓名、联系人和注册人邮政地址，其中包括EPP 中介绍的所有子字段（例如，街道、城市、州或省等），并且可能对其他字段提供部分匹配功能，每种情况均受适用法律的约束。
1.3.3 注册管理运行机构至少应对以下字段提供完全匹配功能：注册服务机构ID、域名服务器名称、域名服务器的IP 地址（仅适用于注册管理机构存储的IP 地址，即粘合记录）。
1.3.4 注册管理运行机构将提供Boolean 搜索功能，至少支持以下逻辑运算符与一组搜索条件相结合：AND（和）、OR（或）、NOT（非）。
1.3.5 搜索结果将包括与搜索条件相匹配的域名。
1.3.6 注册管理运行机构将：1) 采取适当的措施，以避免滥用该功能（如仅允许合法授权用户访问）；以及 2) 确保该功能符合所有适用的隐私法律及ICANN 共识性政策和临时政策。
1.3.7 注册管理运行机构应仅在RDAP 目录服务中提供《RDAP 技术实施指南》和《RDAP 响应简介》中要求的可搜索性功能。
1.4. WHOIS 数据目录服务。
1.4.1 在WHOIS 服务终止日期之前，注册管理运行机构将运营根据RFC 3912 通过端口 43 提供的WHOIS 服务，以及<whois.nic.TLD> 上基于网络的WHOIS 服务，该服务可以提供采用以下格式且至少包含以下数据元素的免费公众查询访问。
1.4.2 响应应采用下述半自由文本格式，后跟空行和免责声明（指定注册管理运行机构和查询数据库的用户的权利）。
1.4.3 每个数据对象都应表示为一组键/值对，行首是键，后跟冒号和空格作为分隔符，再后跟值。
1.4.4 对于存在多个值的字段，应允许多个键/值对具有相同的键（例如列出多个域名服务器）。空行之后的第一个键/值对应视为新记录的开始，并应视为该记录的标识，用于将数据（例如主机名和IP 地址或域名和注册人信息）组合在一起。
1.4.5 以下指定的字段提出了最低输出要求。
1.4.6 域名数据
(1) 查询格式：whois EXAMPLE.TLD
(2) 响应格式：
域名：EXAMPLE.TLD
注册管理机构域ID：D1234567-TLD
注册服务机构WHOIS 服务器：whois.example.tld注册服务机构 URL：http://www.example.tld
更新日期：2009-05-29T20:13:00Z创建日期：2000-10-08T00:45:00Z
注册管理机构到期日期：2010-10-08T00:44:59Z
注册服务机构注册到期日期：2010-10-08T00:44:59Z1注册服务机构：EXAMPLE REGISTRAR LLC
注册服务机构IANA ID：5555555
注册服务机构滥用行为联系电子邮件：email@registrar.tld注册服务机构滥用行为联系电话：+1.123551234
分销商：EXAMPLE RESELLER12
域状态：clientDeleteProhibited 域状态：clientRenewProhibited域状态：clientTransferProhibited域状态：serverUpdateProhibited
注册管理机构注册人ID：5372808-ERL
1 这个字段是可选的。
2 这个字段是可选的。
注册人姓名：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
ICANN WHOIS 信息错误投诉表的 URL： https://www.icann.org/wicf/https://www.icann.org/wicf/
>>> WHOIS 数据库最近一次更新时间：2009-05-29T20:15:00Z <<<
1.4.7 注册服务机构数据
(1) 查询格式：whois “registrar Example Registrar, Inc.”
(2) 响应格式：
注册服务机构：Example Registrar, Inc.
街道：1234 Admiralty Way
城市：Marina del Rey
州/省：CA
邮政编码：90292国家/地区：美国
电话号码：+1.3105551212传真号码：+1.3105551213
注册服务机构WHOIS 服务器：whois.example-registrar.tld注册服务机构 URL：http://www.example-registrar.tld
管理员联系人：Joe Registrar电话号码：+1.3105551213传真号码：+1.3105551213
电子邮件：joeregistrar@example-registrar.tld管理员联系人：Jane Registrar
电话号码：+1.3105551214传真号码：+1.3105551213
电子邮件：janeregistrar@example-registrar.tld技术联系人：John Geek
电话号码：+1.3105551215传真号码：+1.3105551216
电子邮件：johngeek@example-registrar.tld
>>> WHOIS 数据库最近一次更新时间：2009-05-29T20:15:00Z <<<
1.4.8 域名服务器数据：
(1) 查询格式：whois “nameserver (域名服务器名称)”，或whois “nameserver (IP 地址)”。例如：whois “nameserver NS1.EXAMPLE.TLD”。
(2) 响应格式：
服务器名称：NS1.EXAMPLE.TLD IP 地址：192.0.2.123
IP 地址：2001:0DB8::1
注册服务机构：Example Registrar, Inc.
注册服务机构WHOIS 服务器：whois.example-registrar.tld注册服务机构 URL：http://www.example-registrar.tld
>>> WHOIS 数据库最近一次更新时间：2009-05-29T20:15:00Z <<<
1.4.9 以下数据字段：域名状态、个人和组织的名称、地址、街道、城市、州/省、邮编、国家/地区、电话和传真号码（分机号将如上所示作为单独的字段提供）、电子邮件地址、日期和时间的格式应符合EPP RFC 5730-5734 中规定的映射，以便可以一致地处理和理解此信息
（或WHOIS 响应中返回的值）的显示。
1.5. WHOIS 服务终止日期之后的 WHOIS 数据目录服务。如果注册管理运行机构在WHOIS 服务终止日期之后继续提供WHOIS 数据目录服务，则以下要求适用：
1.5.1 如果注册管理运行机构继续通过端口 43 提供WHOIS 服务，注册管理运行机构应根据RFC 3912 提供服务。
1.5.2 注册管理运行机构应向IANA 职能运营商提交变更请求，以更新TLD
的任何过时或不准确的WHOIS 记录，如规范 6 的第 1.6 节中所述。
1.5.3 注册数据中包含的个人资料必须根据ICANN 共识性政策和临时政策进行修订；
1.5.4 如果注册管理运行机构选择添加数据字段，则必须遵守与一致标签和显示共识性政策的其他字段相关的要求。
1.5.5 如果注册管理运行机构在WHOIS 数据目录服务中提供的注册数据少于RDAP 目录服务中提供的注册数据，则注册管理运行机构必须在 WHOIS 输出页脚中添加以下免责声明：“此服务中提供的注册数据是有限的。其他数据可在https://lookup.icann.org 上获取。”
1.5.6 在WHOIS 服务终止日期之后，如果WHOIS 数据目录服务要求与 WHOIS 服务终止日期之后生效的共识性政策或任何临时政策发生冲突，则应以共识性政策或临时政策为准，但仅限于主题问题方面的冲突。
1.5.7 在根据ICANN 董事会于 2019 年 5 月通过的gTLD 注册数据临时规范快速政策制定流程第 1 阶段GNSO 共识性政策建议对共识性政策和规程进行更新并使其生效之前（截至WHOIS 服务终止日期），此类政策中的以下术语应解释如下：
(1) 除了“可搜索Whois”和“Whois 联系人查询服务”之外，以下术语：“WHOIS”、“Whois”、“Whois 服务”、“公众可访问Whois”及其变体应解释为本规范中定义的RDDS。
(2) “Whois 数据”、“WHOIS 信息”、“Whois 联系人信息”、“WHOIS 查询数据”、“WHOIS 详细信息”、
“Whois 输出”、“Whois 记录”、“Whois 条目”及其变体应解释为本规范中引用的注册数据。
1.6. 在WHOIS 服务终止日期之后，上述 1.5.7(1) 和 1.5.7(2) 中的术语（包括在附录A 以及规范 11 和 12 中）将按照 1.5.7(1) 和 1.5.7(2) 中的定义进行解释。
1.7. 配合开展过渡研究。如果ICANN 启动或委托开展有关WHOIS 数据目录服务向RDAP 目录服务过渡的研究，注册管理运行机构应合理配合开展此类研 究，包括向开展此类研究的ICANN 或其指定方提供与其在从WHOIS 数据目
录服务过渡到RDAP 数据目录服务方面的经验相关的定量和定性数据。如果数据请求不属于注册管理运行机构在正常运营过程中收集的数据，也不属于注册管理运行机构根据本协议要求收集和向ICANN 组织提供的数据，则注册管理运行机构应自愿配合提供所请求的信息，或者向ICANN 说明注册管理运行机构无法提供所请求信息的原因。如果不是注册管理运行机构根据本协议其他部分有义务向ICANN 提供的数据，本节的条款不要求注册管理运行机构向ICANN 提供此类数据。根据本节向ICANN 或其指定方提供的所有数据，如果根据本协议的保密条款适当标记为机密，则应根据本协议的保密条款将其视为注册管理运行机构的机密信息，但除本协议规定之外，如果 ICANN 或其指定方对此类数据进行了汇总和匿名处理，则可以向第三方披露此类数据。完成注册管理运行机构提供了相关数据的过渡研究后，ICANN将根据本节规定销毁注册管理运行机构提供的所有未经汇总和匿名处理的数据。
1.8. 政策和培训材料。注册管理运行机构应在TLD 的主要网站（即提供给 ICANN 以便在ICANN 网站上发布的网站）上为ICANN 指定的包含RDDS 政策和培训材料的网页提供一个链接。
2. 区文件访问
2.1. 第三方访问
2.1.1 区文件访问协议。注册管理运行机构将与任何互联网用户签署协
议，以允许这类用户访问互联网主机托管服务器或注册管理运行机构指定的服务器来下载区文件数据。该协议将由集中的域数据访问提供商进行标准化、促进其发展并对其进行管理，而该提供商可能为 ICANN 或ICANN 指定的提供商（“CZDA 提供商”）。注册管理运 行机构（也可选择通过CZDA 提供商）将按照本规范第 2.1.3 节为区文件数据提供访问服务，并使用本规范第 2.1.4 节中描述的文件格式提供此服务。尽管有上述规定，(a) CZDA 提供商可能会拒绝不符合本规范第 2.1.2 节凭证要求的任何用户的访问请求；(b) 注册管理运 行机构可能会拒绝未按照本规范的第 2.1.2 节提供正确或合法凭证的任何用户的访问请求，或者注册管理运行机构可能会拒绝其合理认为会违反本规范第 2.1.5 节规定的任何用户提出的访问请求；(c) 如果注册管理运行机构有证据表明用户违反了本规范第 2.1.5 节的规定，则可以取消任何用户的访问。
2.1.2 凭证要求。通过CZDA 供应商提供的帮助，注册管理运行机构将要求各个用户提供足以正确识别和定位用户的信息。此类用户信息包括但不限于公司名称、联系人姓名、地址、电话号码、传真号码、电子邮件地址和IP 地址。
2.1.3 访问授权。每个注册管理运行机构（可选择通过CZDA 提供商）将为
ICANN 指定和管理的URL（尤其是<TLD>.zda.icann.org，其中
<TLD> 是注册管理机构负责的TLD）提供区文件SFTP（或其他注册管理机构支持的）服务，以便用户能够访问注册管理机构的域数据存档。注册管理运行机构将授予用户非独占、不可转让的有限权利，允许用户访问注册管理运行机构的（也可以是CZDA 提供商的）区文件托管服务器，并以不高于每 24 小时一次的频率，使用SFTP 或 ICANN 可能规定的其他数据传输和访问协议，传输顶级域区文件及所有相关的加密校验和文件副本。对于每个区文件访问服务器，区文件位于名为<zone>.zone.gz 的顶级目录中，<zone>.zone.gz.md5 和
<zone>.zone.gz.sig 用于验证下载项。如果注册管理运行机构（或 CZDA 提供商）还提供历史数据，则使用<zone>-yyyymmdd.zone.gz等命名形式。
2.1.4 文件格式标准。注册管理运行机构（也可选择通过CZDA 提供商）将使用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 认证注册服务机构的系统大批量发送查询或数据提供便利；或(iii) 中断、打扰或 干扰任何注册人的正常业务运营。
2.1.6 使用条款。注册管理运行机构将通过CZDA 提供商为每个用户提供访问区文件的权限，该访问期限不少于三(3) 个月。注册管理运行机构将允许用户续延其访问授权。
2.1.7 免费访问。注册管理运行机构将允许用户免费访问区文件，CZDA 提供商也将为此提供便利。
2.2. 合作
2.2.1 协助。注册管理运行机构将与ICANN 和CZDA 提供商合作并向其提供合理的协助，以便于得到允许的用户能够按照本时间表的预先安排高效地访问区文件数据。
2.3. ICANN 访问。注册管理运行机构应持续地以ICANN 可能不时指定的合理方式，向ICANN 或其指定方提供TLD 区文件的批量访问权限。访问服务至少应每日提供。区文件将尽可能包括 00:00:00 UTC 前提交的SRS 数据。
2.4. 紧急运行机构访问。注册管理运行机构应持续地以ICANN 可能不时指定的合理方式，向ICANN 指定的紧急运行机构提供TLD 区文件的批量访问权限。
3. 对 ICANN 的批量注册数据访问。
3.1. 对简略注册数据的周期性访问。为了证实和确保注册管理机构服务的运营稳定性，分析DNS 的运营稳定性，同时也为了促进对认证注册服务机构的合规性检查，注册管理运行机构将按如下规定每周（具体日期由ICANN 指定）向ICANN 提供最新的注册数据。数据将包括截至ICANN 指定的检索日期前一天 00:00:00（世界协调时）提交的数据。
ICANN 每一年都会发布上一年度利用此数据的研究项目摘要，以及为开展研究而与之共享原始数据的所有组织名单。
3.1.1 内容。注册管理运行机构将为所有注册的域名提供以下数据：域名、域名存储库对象ID (ROID)、注册服务机构ID (IANA ID)、状
态、上次更新日期、创建日期、到期日期和域名服务器名称。对于支持注册服务机构，注册管理运行机构将提供：注册服务机构名称、注册服务机构ID (IANA ID)、注册服务机构WHOIS 服务器的主机名
（在WHOIS 服务终止日期之后可能会省略此数据元素）以及注册服务机构的URL。注册管理运行机构不得提供任何其他数据元素。
3.1.2 格式。数据将按照数据托管规范 2 中规定的格式（包括加密、签名 等）提交，但是其中仅包括前一节中提到的字段，即文件中将仅包含带上文所述字段的域名和注册服务机构对象。注册管理运行机构可以选择提供完全寄存文件，而不按照规范 2 中的规定提供。
3.1.3 访问。注册管理运行机构将自ICANN 指定的检索日当天的 00:00:00 UTC 起准备好文件供下载。文件可以通过SFTP 下载，但是ICANN 未来可能会要求使用其他方法。
3.2. 对详尽注册数据的特殊访问。如果因为注册服务机构出现故障、被取消认 证资格或者法院指令等原因提出将其域名临时或永久地转让给其他注册服务机构，则在ICANN 的请求下，注册管理运行机构将为ICANN 提供有关转出注册服务机构的域名的最新数据。数据将按照数据托管规范 2 中规定的格式提供。文件中将仅包含与转出注册服务机构的域名相关的数据。注册管理运行机构应该在商业可行条件下尽快提供数据，但在任何情况下均不得迟于 ICANN 提出请求后的五(5) 个日历日。除非注册管理运行机构和ICANN 同意其他方式，否则将按照本规范第 3.1 节中指定的数据提供方式将文件提供给ICANN 以供下载。
规范 5
保留名称的安排
除非ICANN 通过其他方式提供明确的书面授权，根据本规范的条款和条件，注册管理运行机构将在TLD 中保留以下标签而不允许在初次注册（即除续订之外）时申请使用。如果使用自分配，注册管理运行机构必须在RDDS 中显示相关注册记录。如果是IDN 名称
（如下所述），将根据注册管理运行机构IDN 注册政策（如适用）标识IDN 变体。
1. Example。ASCII 标签“EXAMPLE”应在注册管理运行机构提供注册的 TLD 的二 级和所有其他级别（此类二级和所有其他级别统称为“所有级别”）保留不予注册或分配到注册管理运行机构。此类标签不得在DNS 中激活，也不得释放，以防除注册管理运行机构之外的任何个人或实体进行注册。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，应按照ICANN 的规定转让此类保留或分配的标签。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。
2. 双字符标签。所有双字符 ASCII 标签均应在TLD 的二级保留不予注册或分配到注 册管理运行机构。此类标签不得在DNS 中激活，也不得释放，以防除注册管理运行机构之外的任何个人或实体进行注册。但是，在注册管理运行机构和相关政府及国家和地区域名经理人签订了相应协议后，即可释放这类双字符标签字符串，具体规定详见《ISO 3166-1 alpha-2 标准》。注册管理运行机构在为避免相应国家和地区代码出现混淆而要采取相应措施的情况下，也可以在获得ICANN 批准后提议释放这些保留域名。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，所有此类保留不予注册或分配到注册管理运行机构的标签均应按照ICANN 的规定进行转让。注册管理运行机构可以自行分配和续订此类域名，无需使用 ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。
3. 为注册管理机构运营保留的标签。
3.1. 以下 ASCII 标签必须在所有级别不予注册或分配到注册管理运行机构，以用于TLD 注册管理机构运营的相关活动：WWW、RDDS 和WHOIS。必须在授权给所有级别的根区后，将以下 ASCII 标签分配给注册管理运行机构以便用于TLD 的注册管理机构运营：NIC。为了运营TLD，注册管理运行机构必须在DNS 中激活NIC，而 WWW、RDDS 和WHOIS 属于可选激活项（根据附录A 的条款，必须在DNS 中使用NS 资源记录将 ASCII 标签NIC 作为区域片段提供）。WWW、RDDS、WHOIS 或NIC 都不能发布，也不能注册给任何人（除注册管理运行机构之外）或第三方。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，应按照ICANN 的规定转让所有此类保留或分配的域名。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。此类域名应以注册服务机构ID 9999 进行标识。
3.1.1 如果本协议的附录A 中特别指出，注册管理运行机构可以提供注册 IDN 的服务，那么，根据注册管理运行机构的IDN 表和IDN 注册规则，注册管理运行机构还可以在DNS 中激活术语“NIC”的特定语言的翻译或音译，或术语“网络信息中心”的翻译的缩写。除了标签 NIC 之外，注册管理运行机构还可以保留和使用此类翻译、音译或缩写，以提供任何所需的注册管理机构职能。根据规范 5 的第 3.1 节中的规定，为了避免产生疑问，注册管理运行机构需要激活 ASCII 标签 NIC。
3.2. 出于TLD 运营或推广的需要，注册管理运行机构可在DNS 的所有级别激活最多一百(100) 个域名（加上其IDN 变体，如适用）。注册管理运行机构必须作为此类域名的注册域名持有人，该术语的定义详见当时生效的ICANN注册服务机构认证协议(RAA)。根据协议第 6.1 节中的目的，这些激活操作将被视为交易。注册管理运行机构必须 (i) 通过ICANN 认证注册服务机构注册此类域名；或 (ii) 自行分配此类域名，且负责将此类域名提交给ICANN 并对其负责，遵循在当前最新的RAA 中第 3.7.7.1 至 3.7.7.12 小节中规定的 ICANN 共识性政策和义务（或任何其他规定注册服务机构和注册域名持有人之间的注册协议条款的替代条款）。如果注册管理运行机构选择上述第
(ii) 项，将使用注册服务机构ID 9998 来标识这些交易。注册管理运行机构可以根据本协议的所有其他条款，包括规范 7 中规定的RPM，自行决定是否释放此类域名，以便可以将这些域名注册给其他个人或实体。
3.3. 注册管理运行机构可根据本协议第 2.6 节，在所有级别将域名（包括其IDN变体，如适用）保留不予注册或分配给注册管理运行机构。此类域名不能在 DNS 中激活，但可以由注册管理运行机构自行决定释放，以注册给注册管理运行机构或其他个人或实体，但需遵守本协议中的所有条款，包括规范 7中规定的适用RPM。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，应按照ICANN 的规定转让所有此类保留不予注册或分配到注册管理运行机构的域名。根据本协议第 2.6 节的规定，应ICANN 的请求，注册管理运行机构应提供所有保留或已分配给注册管理运行机构的域名列 表。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。
3.4. 自规范 6 第 6.1 节中指定的不激活期结束起，注册管理运行机构应将域名 “icann-sla-monitoring.<tld>”分配到 ICANN 测试注册服务机构（此类注册服务机构如规范 10 第 8.2 节中所述）。如果此域名在TLD 中不可用于注 册，或不符合TLD 的注册政策，注册管理运行机构可在咨询ICANN 后将其他域名分配到ICANN 测试注册服务机构。咨询以后应将任何此类替代域名分配事宜告知ICANN。将域名“icann-sla-monitoring.<tld>”分配给 ICANN测试注册服务机构的行为 (i) 根据本协议第 6.1 节的规定，不被视为交易；
(ii) 根据规范 5 的第 3.2 节规定，不计入注册管理运行机构可用的一百个域名之内；或者 (iii) 根据规范 13（有关.BRAND 通用顶级域的条款），因此
对注册管理运行机构申请.BRAND 通用顶级域的资格产生负面影响（如果有）。
4. 国家和地区域名。下列国际认可列表中包含的国家和地区域名（包括其IDN 变体，如适用）应在所有级别保留不予注册或分配到注册管理运行机构：
4.1. ISO 3166-1 列表（以当时的最近更新为准）中包含的所有国家和地区域名的简写形式（英文），包括“欧盟”；ISO 3166-1 列表中特别保留了“欧盟”这个名称，其范围在 1999 年 8 月扩展到任何需要代表“欧盟”的域名申请https://www.iso.org/iso-3166-country-codes.html；
4.2. 联合国地名专家小组撰写的《地名标准化技术参考手册》之第 3 部分“世界各国名称”；以及
4.3. 联合国地名标准化会议国家名称工作组编制的 6 种联合国官方语言版本的联合国成员国列表；
然而，如果注册管理运行机构与相应政府达成协议，保留的特定国家和地区域名
（及其符合注册管理运行机构IDN 注册政策的IDN 变体，如适用）也可释放。注册管理运行机构不得在DNS 中激活此类域名；然而，注册管理运行机构可提议释放这些保留名称，但需经ICANN 政府咨询委员会审核和ICANN 批准。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，应按照ICANN 的规定转让所有此类保留不予注册或分配到注册管理运行机构的域名。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1节中的规定，此行为不被视为交易。
5. 国际奥林匹克委员会；国际红十字和红新月运动。根据ICANN 的不时指示，网站 https://www.icann.org/reserved-names 中列出的与国际奥林匹克委员会、国际红十字和红新月运动相关的域名（包括其IDN 变体，如适用）应在TLD 的二级不予注册或分配到注册管理运行机构。ICANN 可能向此列表添加其他国际奥林匹克委员会、国际红十字和红新月运动名称（包括其IDN 变体），但需要提前十(10) 个日历日向注册管理运行机构发出通知。此类名称不得在DNS 中激活，也不得释
放，以防除注册管理运行机构之外的任何个人或实体进行注册。注册管理运行机构作为TLD 注册管理机构运营商的委任期结束时，要按照ICANN 的规定转交所有此类保留注册或分配到注册管理运行机构的名称。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。
6. 国际政府间组织。根据ICANN 的指示，注册管理运行机构需要落实ICANN 董事会就保护政府间组织的标识符而制定的保护机制。如需第 6 节的保留名称列表，请访问https://www.icann.org/reserved-names。ICANN 可能向此列表添加其他名称
（包括其IDN 变体），但需要提前十(10) 个日历日向注册管理运行机构发出通知。任何此类受保护的国际政府间组织标识符都不得在DNS 中激活，也不得释
放，以防除注册管理运行机构之外的任何个人或实体进行注册。在将注册管理运行机构指定为TLD 的注册管理机构运营商后，所有此类受保护的标识符都应根据 ICANN 规定进行转让。注册管理运行机构可以自行分配和续订此类域名，无需使用ICANN 认证注册服务机构，根据本协议第 6.1 节中的规定，此行为不被视为交易。
规范 6
注册管理机构互用性和连续性规范
1. 标准合规性
1.1. DNS。注册管理运行机构应遵循现有的相关RFC 和今后由互联网工程任务组(IETF) 发布的相关RFC，包括与DNS 和域名服务器运营有关的所有后续标准、修改或补充，包括但不限于RFC 1034、1035、1123、1982、 2181、2182、3226、3596、3597、4343、5966 和 6891。DNS 标签中仅
可以在第三和第四个字符间有连字符，前提是这些标签在其 ASCII 编码中代表有效的IDN（如上所示）（例如“xn--ndk061n”）。
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 区文件。为了避免产生疑问，注册管理运行机构应签署<TLD> 区文件和用于顶级域的DNS 服务器辖区内粘合记录的区文件。在此期限内，注册管理运行机构应遵守RFC 4033、4034、4035、4509 及其后续规定，并遵循RFC 6781 及其后续规定中描述的最佳做法。如果注册管理运行机构实施用于DNS 安全扩展的哈希鉴定否定存在，它应该遵循RFC 5155 及其后续规定。注册管理运行机构应根据行业最佳实践，以安全的方式接受子域名的公钥材料。注册管理机构还应在其网站中发布域名系统安全扩展(DNSSEC) 实践声明(DPS)，说明密钥材料存储的重要安全控制措施和程序、自有密钥的访问和使用，以及注册人公钥材料的安全接受。注册管理运行机构应按照RFC 6841 中规定的格式发布其DPS。DNSSEC 验证必须处于活动状态，并使用IANA DNS 根密钥签名密钥集（可在 https://www.iana.org/dnssec/files 上找到）作为注册管理运行机构的注册管理机构服务的信任锚，通过DNS 响应利用获得的数据。
1.4. IDN。如果注册管理运行机构提供国际化域名（“IDN”），则需要遵守 RFC 5890、5891、5892、5893 及后续规定。注册管理运行机构应遵守位于https://www.icann.org/en/topics/idn/implementation-guidelines.htm 的 ICANN IDN 指导原则（这些指导原则可能随时被修订、修改或取代）。注册
管理运行机构应在IANA IDN 库的实践操作中，发布并随时更新其IDN 列表和IDN 注册规则。
1.5. IPv6。注册管理运行机构应能够接受IPv6 地址作为注册系统中的粘合记录，并在DNS 中公布它们。注册管理运行机构应至少为根区中列出的两个注册管理机构域名服务器（具有在IANA 中注册的相应IPv6 地址）提供公共IPv6 传输。注册管理运行机构应遵循BCP 91 中所述的“DNS IPv6 传输
运营指南”，以及RFC 4472 中提供的建议和注意事项。除了提供IPv4 传输之外，注册管理运行机构还应为其注册数据目录服务提供公共IPv6 传输
（如本协议规范 4 中定义）；例如WHOIS (RFC 3912)、基于网络的WHOIS和RDAP。收到 gTLD 认证注册服务机构希望通过IPv6 运营共享注册系统 (SRS) 的第一个书面申请之后，注册管理运行机构应在六(6) 个月内为该注册服务机构提供用于其SRS 的公共IPv6 传输。
1.6. IANA 根区数据库。为了确保有关TLD 的权威信息可供公众访问，注册管理运行机构应向IANA 职能运营商提交变更请求，更新TLD 所有已过时或不准确的DNS、WHOIS 或者RDAP 服务记录的RDAP 基准URL。注册管理运行机构应在任何此类DNS、WHOIS 或者RDAP 服务记录的RDAP 基准URL 变得过时或不准确之后的七(7) 个日历日内，使用合理的商业方法提交此类变更请求。注册管理运行机构必须根据https://www.iana.org/domains/root中规定的程序提交所有变更请求。
1.7. 网络输入流量筛选。注册管理运行机构应根据BCP 38 和BCP 84 中的规 定，对其注册管理机构服务执行网络输入流量筛选检查，ICANN 也应该实施此项检查。
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. 高可用性。注册管理运行机构应使用网络和分布于不同地域的冗余服务器
（包括网络级冗余、终端节点级冗余和实施的负载均衡方案，如适用）进行运营，以确保在发生技术故障（广泛或局部）或超出注册管理运行机构控制能力的非常情况时仍然能够持续运营。注册管理运行机构的应急运营部门应随时可对非常情况作出响应。
3.2. 非常事件。如果发生超出注册管理运行机构控制能力的非常事件，注册管 理运行机构应通过合理的商业措施在此类事件结束后二十四(24) 小时内恢复注册管理机构的关键职能，并在此类事件结束后最多四十八(48) 小时内恢复全部系统功能（具体取决于受影响的关键职能类型）。因此类事件而发生的宕机不属于缺乏服务可用性的情况。
3.3. 业务连续性。注册管理运行机构应制定一个业务连续性计划，以便在发生 超出注册管理运行机构控制能力的非常事件或注册管理运行机构倒闭时继续维持注册管理机构服务，可在此类计划中指定继续提供注册管理机构服务的提供商。如果此类计划指定了继续提供注册管理机构服务的提供商，注册管理运行机构应向ICANN 提供此类提供商的名称和联系信息。如果发生超出注册管理运行机构控制能力的非常事件，并且无法联系到注册管理运行机 构，则注册管理运行机构同意ICANN 联系指定的继续提供注册管理机构服务的提供商（如有）。注册管理运行机构每年至少应执行一次注册管理机构服务连续性测试。
4. 滥用缓和
4.1. 滥用问题联系人。注册管理运行机构应向ICANN 提供准确详细的联系人信息并在其网站上发布此信息，联系人信息包括有效的电子邮件地址或网页表单、邮寄地址以及处理与TLD 中恶意行为（包括DNS 滥用）有关的报告的主要联系人，并应向ICANN 提供有关此类联系信息任何更改的及时通知。收到此类报告时，注册管理运行机构应向报告者提供已收到报告的确认函。
就本协议而言，“DNS 滥用”是指恶意软件、僵尸网络、网络钓鱼、网址嫁接和垃圾邮件（当垃圾邮件充当本节所列的其他DNS 滥用形式中的某种传递机制时），这些术语在SAC115 (<https://www.icann.org/en/system/files/files/sac-115-en.pdf>) 第 2.1 节中进行了定义。
4.2. DNS 滥用问题缓和。如果注册管理运行机构根据可操作证据合理认定该 TLD 的注册域名被用于实施DNS 滥用行为，则注册管理运行机构必须立即采取合理必要的适当缓和措施，这些措施有助于阻止或以其他方式中止域名被用于实施DNS 滥用行为。此类措施应至少包括：(i) 将正被用于实施DNS滥用行为的域以及相关证据转交给赞助注册服务机构；或 (ii) 注册管理运行机构在认为合适时采取直接措施。考虑到DNS 滥用行为所造成损害的严重程度以及相关间接损害的可能性，采取的措施可能会根据各个案例的具体情况而有所不同。
4.3. 恶意使用孤立粘合记录。有书面证据表明某些孤立粘合记录（如 https://www.icann.org/en/committees/security/sac048.pdf 中定义）遭恶意使用时，注册管理运行机构应采取措施删除此类记录。
5. 支持的初始和续订注册期
5.1. 初始注册期。可按一(1) 年为单位在注册管理机构进行注册域名的初始注册，最长可注册十(10) 年。为避免疑义，注册域名的初始注册期不得超过十(10) 年。
5.2. 续订期。可按一(1) 年为单位进行注册域名的续订，最长可续订十(10)年。为避免疑义，注册域名的续订期不得超过十(10) 年（自续订之日起）。
6. 域名冲突事件管理
6.1. 不激活期。本协议生效日期起至少 120 个日历日内，注册管理运行机构不得在注册管理机构TLD 的DNS 区中激活任何域名（“NIC”除外）。仅在注册管理运行机构明确通知注册人不激活期结束前无法激活域名的情况下，注册管理运行机构才可在此期间分配域名（根据以下第 6.2 小节）。
6.2. 域名冲突事件评估
6.2.1 除非符合ICANN 提供的有关注册管理机构TLD 的域名冲突事件评 估，否则注册管理运行机构不得在注册管理机构TLD 的DNS 区中激
活任何域名。注册管理运行机构将(A) 在激活二级域名前执行其域名冲突事件评估中所述的缓和措施，或 (B) 阻止未执行其域名冲突事件评估中所述的缓和措施的二级域名，并继续激活评估中未列出的域名。
6.2.2 尽管有第 6.2.1 小节的规定，注册管理运行机构可以不执行第 6.2.1节中规定的措施而继续在DNS 区中激活域名，前提是(A) ICANN 确定注册管理机构TLD 适用于此种激活域名的替代方法；且 (B) 注册管理运行机构阻止ICANN 在
https://newgtlds.icann.org/en/announcements-and- media/announcement-2-17nov13-en 中指定的所有二级域名（ICANN 可能不时修改此类列表）。注册管理运行机构可根据本小节激活域名并稍后根据第 6.2.1 小节激活域名。
6.2.3 需要根据第 6.2.1 和 6.2.2 节缓和或阻止的域名集将基于ICANN 的 DNS 信息分析来确定，这些信息包括由DNS 运营、分析和研究中心 (DNS-OARC) 维护的“互联网生活中的一天”（Day in the Life of the Internet，DITL）数据https://www.dns-oarc.net/oarc/data/ditl。
6.2.4 注册管理运行机构可参与ICANN 社群的相关流程制定活动，以确定这些被阻止的域名是否可以以及应如何释放。
6.2.5 如果ICANN 确定TLD 不适用于激活域名的替代方法，ICANN 可选择不授权相应TLD，而等待完成相应TLD 的最终域名冲突事件评估以及等待注册管理运行机构完成各种所需的缓和措施。注册管理运行机构了解，ICANN 要求作为在TLD 的DNS 区激活域名之条件的缓和措施可包括但不限于，ICANN 董事会新gTLD 项目委员会(NGPC) 在 2013 年 10 月 7 日批准的新gTLD 冲突事件管理计划第 3.2 节中所述的缓和措施，请参阅 https://www.icann.org/en/groups/board/documents/resolutions- new-gtld-annex-1-07oct13-en.pdf。
6.3. 域名冲突报告处理
6.3.1 授权TLD 后的前两年，注册管理运行机构的应急运营部门应可收到由ICANN 传达的相关报告，其中明确记录因在权威DNS 之外重叠使用域名而导致的冲突所产生的严重危害。
6.3.2 注册管理运行机构应制定内部流程以快捷方式处理根据第 6.3.1 小节收到的报告，在该流程下，注册管理运行机构可在必要且适当的范围内，从TLD 区域中删除最近两年内激活的名称以使相关方可更改其系统。
规范 7
对于权利保护机制的最低要求
1. 权利保护机制。根据本规范的要求，注册管理运行机构应实施并遵守权利保护机制（“RPM”）。除了这些RPM 之外，注册管理运行机构还可制定并应用其他的 RPM，以阻止或预防注册违反或滥用对方合法权利的域名。注册管理运行机构应 将本规范 7 中要求的所有RPM，以及注册管理运行机构制定和实施的所有其他 RPM 包含在注册管理机构-注册服务机构协议中，该协议由有权注册TLD 域名的 ICANN 认证注册服务机构签署。注册管理运行机构应遵循 https://www.icann.org/en/resources/registries/tmch-requirements 上的商标信息交换中心内规定的每项强制RPM 中列出的要求（“商标信息交换中心要求”）， ICANN 可能会随时对此要求进行修订。除了ICANN 指定的商标信息交换中心，注册管理运行机构不得要求任何适用知识产权的所有者使用任何其他商标信息收集、通知或验证服务。如果本协议中的条款和条件与“商标信息交换中心要求”有冲 突，那么应遵循本协议中的条款和条件。注册管理运行机构必须与至少一家 ICANN 认证注册服务机构签订具有约束力和强制执行力的注册管理机构-注册服务机构协议（授权此类注册服务机构在TLD 中注册域名），具体要求如下：
a. 如果注册管理运行机构开展合格启动项目或在ICANN 授权下开展批准启动项目（此类术语在“商标信息交换中心要求”中定义），注册管理运行机构必须在根据此类合格启动项目或批准启动项目（视情况而定）分配任何域名前，与至少一家ICANN 认证注册服务机构签订具有约束力和强制执行力的注册管理机构-注册服务机构协议；
b. 如果注册管理运行机构不执行合格启动项目，或者没有得到ICANN 的授权来执行批准启动项目，注册管理运行机构必须在通用顶级域的优先注册阶段到期至少三十(30) 个日历日前，与至少一个ICANN 认证的注册服务机构签署具有约束力和强制执行力的注册管理机构-注册服务机构协议（根据“商标信息交换中心要求”中定义的条款）；或
c. 如果本协议中包含规范 13，注册管理运行机构必须在通知开始日期之前，与至少一个ICANN 认证注册服务机构签署具有约束力和强制执行力的注册管理机构-注册服务机构协议（根据规范 13 中的定义）。
规范 7 中的任何内容均不能限制或免除本协议中适用于注册管理运行机构的任何其他义务或要求，包括第 2.9(a) 节和规范 9。
2. 争议解决机制。注册管理运行机构将遵循以下争议解决机制（可能不时修订）：
a. ICANN 通过的商标授权后争议解决程序(PDDRP) 和注册限制争议解决程序 (RRDRP)（分别发布于https://www.icann.org/pddrp 和 https://www.icann.org/rrdrp）。经PDDRP 或RRDRP 小组裁定后，注册管
理运行机构同意实施和遵守由ICANN 提出的所有补救措施（其中可包括任何合理的补救措施，包括为避免存疑而根据本协议第 4.3(e) 节终止注册管理机构协议），并受此类裁定约束；以及
b. ICANN 通过的统一快速中止程序（“URS”）（发布于
https://www.icann.org/urs），包括URS 审查人员发布的实施决定。
规范 8
持续经营方案
1. “持续经营方案”应(a) 保障充足的资金来源，确保本协议规范 10 第 6 节中规定的TLD 相关的关键注册管理机构职能，在本协议距生效日期满五年时终止或距生效日期未满五年即终止的情况下能够持续运营三(3) 年，或在本协议距生效日期满五年但距生效日期未满或刚满六(6) 年时终止的情况下能够持续运营一(1) 年；(b)采用 (i) 不可撤销的备用信用证(LOC) 或 (ii) 不可撤销的现金托管存款，两种形式均需符合ICANN 在本协议日期前发布并补充的gTLD 申请人指导手册（通过引用 纳入本规范 8）中第 2 单元－ 评估问题和标准－ 附件 50(b) 中规定的要求。注册管理运行机构要尽全力采取所有必要或合适的举措，使“持续经营方案”在本协议生效日期后六(6) 年内保持有效，并且要保持ICANN 为其第三方受益人。如果注册管理运行机构选择不可撤销的备用信用证但很难达到上述条款要求，在满足 ICANN 于本协议签订日期之前发布并补充的gTLD 申请人指导手册中第 2 单元－评估问题和标准－ 附件 50(b) 中规定要求的情况下，注册管理运行机构可取得为期一(1) 年的信用证和“常青条款”（规定LOC 在无修订的情况下可以逐年无限延期，直到开证银行通知受益人LOC 最终失效或受益人书面证明LOC 解付为止）；但是如果开证银行在本协议生效日期满六(6) 年之前通知ICANN 相关信用证即将到期，则此类信用证必须授权ICANN 在到期之前提取由信用证保障的资金。信用证必须要求开证银行在信用证到期或无任何延期之前至少提前三十(30) 个日历日通知ICANN。如果信用证在协议生效日期未满六(6) 年的任何时间到期或终止，注册管理运行机构需要取得替代性持续经营方案。如果原信用证到期之前替代性持续经营方案未到位，ICANN 可取出原信用证下的资金。注册管理运行机构要向 ICANN 提供与“持续经营方案”相关的所有最终文件的副本，并在合理的范围
内，向ICANN 及时告知与“持续经营方案”相关的材料编撰情况。事先未经 ICANN 书面同意（不应无理拒绝同意），注册管理运行机构不应同意或允许修改或放弃持续经营方案或与之关的其他文件。
2. 如果注册管理运行机构已尽全力履行上述规定义务，但持续经营方案过期，或者持续经营方案因故在距本协议生效日期未满六年时即由持续经营方案的另一方部分或全部终止，则在此情况下，注册管理运行机构应及时 (i) 将过期情况或终止情况及其原因通知ICANN，并 (ii) 安排替代经营方案，保障充足的资金来源，确保本协议规范 10 第 6 节中规定的TLD 相关的关键注册管理机构职能，在本协议距生效日期满五年时终止或距生效日期未满五年即终止的情况下能够持续运营三(3) 年，或在本协议距生效日期满五年但距生效日期未满或刚满六(6) 年时终止的情况下能够持续运营一(1) 年（“替代经营方案”）。任何此类替代经营方案赋予ICANN 的权益应不低于原有持续经营方案的水平，或者其形式和内容应是ICANN 可以合理接受的。
3. 无论本规范 8 有何相反规定，注册管理运行机构都可以随时使用替代经营方案来代替原有的持续经营方案，但替代经营方案需符合以下条件：(i) 保障充足的资金来
源，确保本协议规范 10 第 6 节中规定的TLD 相关的关键注册管理机构职能，在本协议距生效日期满五年时终止或距生效日期未满五年即终止的情况下能够持续运营三(3) 年，或在本协议距生效日期满五年但距生效日期未满或刚满六(6) 年时终止的情况下能够持续运营一(1) 年；(ii) 赋予ICANN 的权益应不低于原有持续经营方案的水平，或者其形式和内容应是ICANN 可以合理接受的。如果注册管理运行机构根据上述第 2 段或本第 3 段使用任何替代经营方案代替了原有的持续经营方案，
则本协议本规范 8 中的条款将不再适用于原持续经营方案，但将适用于之后的替代经营方案，且此类替代经营方案之后应视为持续经营方案。
规范 9
注册管理运行机构行为准则
1. 在开展有关TLD 注册管理机构的运营活动时，注册管理运行机构不应且不得允许其任何母公司、子公司、附属机构、转包商或其他相关实体（只要此类相关方参与提供TLD 相关的注册管理机构服务）（均称为“注册管理机构相关方”）按以下方式行事：
a. 对于注册管理机构系统和相关注册管理机构服务的运营访问，直接或间接表现出对某注册服务机构的偏好或给予特殊考量，除非在大致相似的条款和条件下对所有注册服务机构进行比较以肯定此类偏好或考量。
b. 出于自身利益注册域名，通过ICANN 认证注册服务机构注册的域名除外；但是，注册管理运行机构(a) 可根据本协议第 2.6 节将某些域名保留不予注册，且(b) 可根据规范 5 第 3.2 节将最多一百(100) 个域名保留不予注册，或分配给注册管理运行机构；
c. 通过独有途径获得消费者对未注册域名的搜索或解析请求信息后，在TLD
或TLD 子域中注册域名（俗称“抢先注册”）；或
d. 允许任何附属注册服务机构向注册管理运行机构或任何注册管理机构相关方披露注册人的个人资料（出于TLD 管理和运营合理需要的情况除外），除非所有无关的第三方（包括其他注册管理运行机构）对于此类用户资料在大致相似的条款条件下有等效的访问权限。
2. 如果注册管理运行机构或注册管理机构相关方同时还身为注册服务机构服务或注册服务机构分销商服务的提供商，注册管理运行机构将促使此类注册管理机构相关方确保此类服务通过独立于注册管理运行机构的合法实体提供，并针对其注册服务机构或注册服务机构分销商运营开设独立的会计账簿。
3. 如果注册管理运行机构或注册管理机构相关方还身为注册服务机构服务或注册服务机构分销商服务的提供商，注册管理运行机构将每年至少执行一次内部审查，确保符合本行为准则。在每个日历年结束后的二十(20) 个日历日内，注册管理运行机构需将内部审查结果连同注册管理运行机构高管签发的表明注册管理运行机构符合本行为准则的相关证明文件通过电子邮件发送到ICANN 指定的地址。（ICANN 未来可以指定此类报告的形式和内容，或者指定其他的合理发送方式。）注册管理运行机构同意，ICANN 可公开发布此类结果和证明文件；但前提是ICANN 不得披露此类结果中所含的机密信息，符合本协议第 7.15 节的情况除外。
4. 此处的规定不得：(i) 限制ICANN 针对相关投诉调查注册管理运行机构是否遵守本行为准则；或 (ii) 为注册管理运行机构提供理由拒绝ICANN 针对相关投诉调查注册管理运行机构是否遵守本行为准则。
5. 此处的规定不得限制任何注册管理运行机构或注册管理机构相关方在正常业务活动中就完全与TLD 无关的产品和服务与注册服务机构或分销商达成公平交易。
6. 注册管理运行机构可要求对本行为准则的豁免，如果注册管理运行机构向ICANN合理证明(i) TLD 中的所有域名注册均注册到注册管理运行机构并由其维护以供注册管理运行机构或其附属机构专用；(ii) 注册管理运行机构不向非其附属机构的任何第三方出售、分配或转让TLD 中注册域名的控制或使用权；(iii) 遵守本TLD 行为准则并非保护公共利益的必要前提，则可由ICANN 酌情授予豁免。
规范 10
注册管理机构执行规范
1. 定义
1.1. DNS。指RFC 1034、1035 和相关RFC 中指定的域名系统。
1.2. DNSSEC 正常解析。存在从根区信任锚到某个特定域名的有效DNSSEC 信任链，如TLD、在TLD 下注册的域名等。
1.3. EPP。指RFC 5730 和相关RFC 中指定的可扩展供应协议。
1.4. IP 地址。指IPv4 地址或IPv6 地址，不对二者加以区别。如果需要区别二者，则使用IPv4 或IPv6。
1.5. 探测器。位于全球各地的、用于执行（DNS、EPP 等）测试（见下文）的网络主机。
1.6. [已故意删除]
1.7. RTT。往返时间(RTT) 指从发送数据包序列中第一个数据包的第一个位数
（用于提出请求）开始，到收到数据包序列中最后一个数据包的最后一个位数（用于接收响应）为止的这段时间。如果客户端未收到表明收到响应的整个数据包序列，则该请求将被视为未响应。
1.8. SLR。服务水平要求(SLR) 是服务水平协议(SLA) 中对正在测量的特定参数所要求的服务水平。
1.9. RDAP-RDDS。指本协议规范 4 中定义的注册数据访问协议(RDAP) 目录服务。
1.10. WHOIS-RDDS 和 WHOIS 数据目录服务。指本协议规范 4 中定义的WHOIS
和基于网络的WHOIS 服务的集合。
2. 服务水平协议矩阵
2.1. 就TLD 而言，注册管理运行机构应满足或超过以下与DNS、EPP 和RDAP- RDDS* 服务相关的每一项SLR：
参数 | SLR（按月衡量） | |
DNS | DNS 服务可用性 | 0 分钟中断= 100% 可用性 |
DNS 域名服务器可用性 | ≤ 432 分钟中断(≈ 99%) | |
TCP DNS 解析RTT | ≤ 1500 毫秒（对于至少 95% 的查询） | |
UDP DNS 解析RTT | ≤ 500 毫秒（对于至少 95% 的查询） | |
DNS 更新时间 | ≤ 60 分钟（对于至少 95% 的探测器） | |
EPP | EPP 服务可用性 | ≤ 864 分钟中断(≈ 98%) |
EPP 会话命令RTT | ≤ 4000 毫秒（对于至少 90% 的命令） | |
EPP 查询命令RTT | ≤ 2000 毫秒（对于至少 90% 的命令） | |
EPP 转换命令RTT | ≤ 4000 毫秒（对于至少 90% 的命令） | |
RDAP-RDDS* | RDAP 可用性 | ≤ 864 分钟中断(≈ 98%) |
RDAP 查询RTT | ≤ 4000 毫秒（对于至少 95% 的查询） | |
RDAP 更新时间 | ≤ 60 分钟（对于至少 95% 的探测器） |
*在RDAP 启动期到期之前，RDAP-RDDS 的这些SLR 不是强制性的。
2.2. 当每项服务的统计流量较低时，建议注册管理运行机构为各项服务提供维护。但请注意，本协议不考虑计划中断或任何类似的不可用或较慢服务时段；出于维护目的或由于系统故障导致的中断将被直接视为中断并计入SLR衡量范围。
2.3. 就TLD 而言，在WHOIS 服务终止日期之前，注册管理运行机构应满足或超过以下与WHOIS 数据目录服务相关的每一项SLR：
参数 | SLR（按月衡量） | |
WHOIS-RDDS | WHOIS-RDDS 可用性 | ≤ 864 分钟中断(≈ 98%) |
WHOIS-RDDS 查询RTT | ≤ 2000 毫秒（对于至少 95% 的查询） | |
WHOIS-RDDS 更新时间 | ≤ 60 分钟（对于至少 95% 的探测器） |
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 探测器放置。ICANN 将采用商业上合理的措施在每个ICANN 地理区域内具有运营商级连接的数据中心内，部署用于衡量DNS 参数的探测器。
4. RDDS
4.1. RDAP-RDDS
4.1.1 RDAP 可用性。指TLD 的RDAP-RDDS 服务通过提供相关注册系统中的相应数据来响应互联网用户查询的能力。如果在给定时间内，有 51% 或更多的RDAP 测试探测器认为RDAP-RDDS 服务不可用，则 RDAP-RDDS 服务将被视为未答复。
4.1.2 RDAP 查询 RTT。指从RDAP-RDDS 测试探测器的TCP 连接开始到结束（包括只收到一个HTTPS 请求的HTTPS 响应）这一期间的数据包序列的RTT。如果RTT 是相应SLR/绩效规范的 5 倍或更多，则RTT将被视为未定义。
4.1.3 RDAP 更新时间。指从收到对某个域名、主机或联系人的转换命令的 EPP 确认开始，到至少 51% 的RDAP-RDDS 测试探测器检测到所做更改为止的这一段时间。
4.1.4 RDAP 测试。指发送到RDAP-RDDS 服务的某个服务器的某个特定IP地址的一条查询。查询应针对注册系统中的现有对象，且响应必须包含相应信息，否则查询将被视为未答复。高于相应SLR 5 倍的查询将被视为未答复。RDAP 测试的结果可能为：与RDAP 查询RTT 对应的数字（以毫秒为单位）或未答复。
4.1.5 衡量 RDAP 参数。对于被监控TLD 的RDAP-RDDS 服务，RDAP- RDDS 探测器每 5 分钟都将从服务器在公共DNS 中注册的所有“IP 地址”中选择一个IP 地址并执行“RDAP 测试”。如果RDAP 测试结果为未答复，该探测器将认为相应的RDAP-RDDS 服务不可用，直至执行新的测试。
4.1.6 整理来自RDAP-RDDS 探测器的结果。在任意给定的衡量期间内，判定衡量有效的最小活动测试工作RDAP-RDDS 测试探测器数量为 10，否则衡量将被弃置并视为“无结果”；在这种情况下不会根据 SLR 标记故障。
4.1.7 RDAP-RDDS 探测器放置。ICANN 将采用商业上合理的措施在每个 ICANN 地理区域内具有运营商级连接的数据中心内，部署用于衡量 RDAP 参数的探测器。
4.2. WHOIS-RDDS。在 WHOIS 服务终止日期之前，注册管理运行机构应遵守本
4.2 节中的条款。
4.2.1 WHOIS-RDDS 可用性。指TLD 的所有WHOIS-RDDS 服务通过提供相关注册系统中的相应数据来响应互联网用户查询的能力。如果在给定时间内，有 51% 或更多的WHOIS-RDDS 测试探测器认为有任何 WHOIS-RDDS 服务不可用，则WHOIS-RDDS 将被视为不可用。
WHOIS 查询RTT。指从TCP 连接开始到结束（包括收到WHOIS 响应）这一期间的数据包序列的 RTT。如果 RTT 是相应SLR 的 5 倍或更多，则该 RTT 将被视为未答复。 | |||
基于网络的 WHOIS 查询RTT。指从TCP 连接开始到结束（包括只收到一个HTTP 请求的HTTP 响应）这一期间的数据包序列的 RTT。 | |||
如果注册管理运行机构执行多步骤流程来获取信息，则只衡量最后一 | |||
步。如果 RTT 是相应SLR 的 5 倍或更多，则该 RTT 将被视为未答 | |||
复。 | |||
WHOIS-RDDS 查询RTT。指“WHOIS 查询RTT”和“基于Web 的 WHOIS 查询RTT”的集合。 | |||
WHOIS-RDDS 更新时间。指从收到对某个域名、主机或联系人的转换命令的EPP 确认开始，到WHOIS-RDDS 服务的服务器反映出所做 | |||
更改为止的这一段时间。 | |||
WHOIS-RDDS 测试。指发送到某个WHOIS-RDDS 服务的某个服务器的特定“IP 地址”的一条查询。查询应针对注册系统中的现有对 象，且响应必须包含相应信息，否则查询将被视为未答复。RTT 高于相应SLR 5 倍的查询将被视为未答复。WHOIS-RDDS 测试的结果可能为：与 RTT 对应的数字（以毫秒为单位）或未答复。 | |||
衡量 WHOIS-RDDS 参数。对于被监控TLD 的每项WHOIS-RDDS， WHOIS-RDDS 探测器每 5 分钟都将从服务器在公共DNS 中注册的所有“IP 地址”中选择一个IP 地址并对其执行“WHOIS-RDDS 测 试”。如果“WHOIS-RDDS 测试”测试结果为未答复，该探测器将认为相应的WHOIS-RDDS 服务不可用，直至执行新的测试。 | |||
整理来自 WHOIS-RDDS 探测器的结果。在任意给定的衡量期间内，判定衡量有效的最小活动测试探测器数量为 10，否则衡量将被弃置并视为无结果；在这种情况下不会根据SLR 标记故障。 | |||
WHOIS-RDDS 探测器放置。ICANN 将采用商业上合理的措施在每个 ICANN 地理区域内具有运营商级连接的数据中心内，部署用于衡量 WHOIS-RDDS 参数的探测器。 | |||
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 探测器放置。ICANN 将采用商业上合理的措施在每个ICANN 地理区域内具有运营商级连接且邻近互联网注册服务机构接入点的数据中心内，部署用于衡量EPP 参数的探测器。
6. 紧急情况阈值
6.1. 下表显示了紧急情况阈值，如果某个TLD 与DNS、EPP、RDAP-RDDS* 和数据托管相关的任何一项服务达到这个范围，将引发如本协议第 2.13 节中所述的注册管理机构TLD 紧急移交。
关键职能 | 紧急情况阈值 |
DNS 服务 | 总计 4 小时中断/周 |
DNSSEC 正常解析 | 总计 4 小时中断/周 |
EPP | 总计 24 小时中断/周 |
RDAP-RDDS* | 总计 24 小时中断/周 |
数据托管 | 达到规范 2 第B 部分第 6.2 节至第 6.6 节中所述的寄存转让标准。 |
*RDAP-RDDS 紧急情况阈值会在RDAP 启动器到期后生效。
6.2. 下表显示了紧急情况阈值，如果在RDAP 启动期到期之前某个TLD 与 WHOIS-RDDS 相关的任何一项服务达到这个范围，将引发如本协议第 2.13节中所述的注册管理机构TLD 紧急移交。
关键职能 | 紧急情况阈值 |
WHOIS-RDDS | 总计 24 小时中断/周 |
7. 紧急呈报
呈报的目的严格限制为通知并调查与被监控服务有关的可能或潜在的问题。任何呈报的发起和后续的合作调查本身并不意味着被监控的服务已经不能达到其执行要求。
呈报应在ICANN 和注册管理运行机构、注册服务机构和注册管理运行机构、以及注册服务机构和ICANN 之间展开。注册管理运行机构和ICANN 必须提供如前所述的应急运营部门。ICANN 和注册管理运行机构之间必须保持最新的联系信息，并且，当在呈报中存在与注册服务机构的职能相关的信息时，必须在所有相关方对紧急呈报进行任何处理之前向注册服务机构公布这些联系信息。同时，这些联系信息必须始终保持为最新信息。
7.1. 由 ICANN 发起的紧急呈报
一旦达到本规范第 6 节所述的紧急情况阈值的 10%，ICANN 的应急运营部门就将向相关的注册管理运行机构发起紧急呈报。紧急呈报至少由以下要素组成：向注册管理运行机构的应急运营部门发送电子（即电子邮件或短信息）和/或语音联系通知，提供与待呈报问
题相关的详细信息，包括监控故障证据、ICANN 工作人员和注册管理运行机构对监控故障的合作故障排除，以及承诺启动监控服务或被监控服务的问题纠正流程。
7.2. 由注册服务机构发起的紧急呈报
注册管理运行机构将常设一个应急运营部门，随时处理来自注册服务机构的紧急请求。当注册服务机构因注册管理机构服务故障而无法通过注册管理机构为TLD 执行EPP 交易，并且无法联系（通过ICANN 规定的通信方式）注册管理运行机构，或者注册管理运行机构无法或不愿解决故障时，注册服务机构可向ICANN 的应急运营部门发起紧急呈报。然后，ICANN 可以按照如前所述的方式向注册管理运行机构发起紧急呈报。
7.3. 中断和维护通知
注册管理运行机构计划进行维护时，至少会提前二十四(24) 小时向ICANN 应急运营部门提供通知。ICANN 的应急运营部门将记录计划维护的时间，并在预定的维护中断期间暂停被监控服务的紧急呈报服务。
如果注册管理运行机构按照与ICANN 的合同义务，宣布中断服务水平协议和执行要求下的服务，注册管理运行机构将会通知ICANN 应急运营部门。在宣布的中断期间，ICANN的应急运营部门将针对所涉及的被监控服务，记录并暂停紧急呈报服务。
8. 绩效衡量约款
8.1. 不干预。注册管理运行机构不应干预衡量探测器，包括对被监控服务的请 求进行任何形式的优先处理。在响应本规范所述的衡量测试时，注册管理运行机构应采用与响应来自互联网用户（对于DNS 和RDDS）或注册服务机构
（对于EPP）的其他任何请求相同的方式。
8.2. ICANN 测试注册服务机构。注册管理运行机构同意，ICANN 可设立测试注册服务机构，以用于衡量上述 SLR。注册管理运行机构同意除不对交易计费外，不为测试注册服务机构提供任何其他差别待遇。ICANN 不会使用该注册服务机构来为自己或他人注册域名（或其他注册管理机构对象），除非是出于使用本协议中所述的条件来验证合同合规的目的。注册管理运行机构将使用注册服务机构ID 9997 来标识这些交易。
规范 11
公共利益承诺
1. 注册管理运行机构将只通过ICANN 认证注册服务机构（即签订了ICANN 董事会于 2013 年 6 月 27 日批准的注册服务机构认证协议的注册服务机构）注册域名。ICANN 应在其网站上发布此类注册服务机构的名单。
2. 注册管理运行机构将遵循注册管理运行机构在向ICANN 提交的TLD 运营申请的以下章节中陈述的所有承诺、意向书和商业计划来运营TLD 注册管理机构，其承诺、意向书和商业计划通过引用纳入本协议。本段规定的注册管理运行机构义务应可由ICANN 通过ICANN 制定并可能不时对其进行非重大修订的公共利益承诺争议解决流程（“PICDRP”）（发布于 https://www.icann.org/picdrp）落实。注册管理运行机构应遵守PICDRP。经PICDRP 小组裁定后，注册管理运行机构同意实施和遵守由ICANN 提出的所有补救措施（其中可包括任何合理的补救措施，包括为避免存疑而根据本协议第 4.3(e) 节终止注册管理机构协议），并受此类裁定约束。
[注册管理运行机构在此插入特定申请章节，如适用]
3. 注册管理运行机构同意履行以下特定公共利益承诺，这些承诺应可由 ICANN 通过ICANN 发布并可能不时对其进行非重大修订的公共利益承诺争议解决流程（“PICDRP”）（发布于https://www.icann.org/picdrp）落实。注册管理运行机构应遵守PICDRP。经PICDRP 小组裁定后，注册管理运行机构同意实施和遵守由ICANN 提出的所有补救措施（其中可包括任何合理的补救措施，包括为避免存疑而根据本协议第 4.3(e) 节终止注册管理机构协议），并受此类裁定约束。
a. 注册管理运行机构将在其注册管理机构-注册服务机构协议中纳入如下规定，要求注册服务机构在其注册协议中禁止注册域名持有人散布恶意软件、滥用僵尸网络、网络钓鱼、盗版、商标或版权侵权、诈骗或欺骗、造假以及以其他方式从事违反适用法律的活动，并（依据适用法律和任何相关程序）注明这些行或活动会带来的后果，包括暂停域名的使用。
b. 注册管理运行机构将定期启动技术分析，以评估TLD 中的域名是否被用于实施DNS 滥用。注册管理运行机构将定期执行安全检查，并对已发现的DNS 滥用及所采取的应对措施编制一份统计报告。注册管理运行机构将在协议有效期内保存这些报告（除非法律要求或 ICANN 批准保存更短时间）并根据要求提供给ICANN。
c. 注册管理运行机构将制定、发布并遵守明确的注册政策，坚持公开、非歧视的一般原则，以透明的方式运营TLD。
d. “通用字符串”TLD 的注册管理运行机构不得在TLD 中强加注册域名的资格标准，使注册仅限于单独的个人或实体以及/或者该个人或实体的“附属机构”（如注册管理机构协议第 2.9(c) 节中定义）。 “通用字符串”是指由一个定义或描述通用类商品、服务、团体、组织或事物的词或术语组成的字符串，与其相对的是由可区分特定品牌商品、服务、团体、组织或事物的词或术语组成的字符串。
规范 12
社群注册政策
注册管理运行机构应实施并遵守下述和/或本规范 12 随附的所有社群注册政策。
[插入注册政策]