新 gTLD 协议
新 gTLD 协议
提案（第 3 版）
本文件包含的注册管理机构协议草案涉及新 gTLD 的《申请人指南草案》（RFP 草案）。
gTLD 申请人应在授权新的 gTLD 之前与 ICANN 签署本注册管理机构协议以完成申请。本 版 协议 草 案 的 背 景 信 息 与 先 前 版 本 草 案 的 背 景 信 息 有 所 不 同 （ 请 参 阅xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx-xxxxx/xxxxx-xxx-xxxxx-00xxx00-xx.xxx ），说明备忘录
《基本协议变更摘要》中提供了该信息。
必须注意，本协议草案不代表 ICANN 的正式立场，并且未经 ICANN 理事会批准。发布本协议旨在供评审和群体讨论，ICANN 鼓励大家提出改进意见和建议。本草案仅供讨论。由于新的 gTLD 计划将来可能要进行意见征询和修订，潜在申请人不可完全依赖于其中的细则。
x《注册管理机构协议》（以下简称本“协议”）由加利福尼亚州非营利性公益组织“互联网名称与数字地址分配机构”（以下简称“ICANN”）与 （以下简称 “注册管理执行机构”）共同签署，自 （以下简称“生效日期”）起生效。
第 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 具备订立并正式签署和交付本协议所需的所有权利和权限并已通过所有必要的机构审批。
第 2 条
注册管理执行机构的约款注册管理执行机构与 ICANN 达成协议如下：
2.1 批准的服务；附加服务。注册管理执行机构应有权提供规范 6 中第 2 节第 1 条的 (a)和 (b) 款中所述的注册服务 [参见规范 6] 及附录 A 中规定的此类其他注册服务（统称为“批准的服务”）。如果注册管理执行机构意欲提供任何不属于批准服务的注册服务或批准服务的修改（分别称为“其他服务”），则注册管理执行机构应根据 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx 上载明的注册服务评估政策（此类政策可能不时有所修订，简称“RSEP”）提交此类附加服务审批申请。只有经过 ICANN 的书面批准，注册管理执行机构才能提供附加服务。ICANN 经过合理的判断，可能要求对本协议作出修订，以反映根据 RSEP 作出批准的任何附加服务的提供。
2.2 遵守共识性政策和临时政策。注册管理执行机构应遵守并执行本协议生效之日时 xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx 中的所有共识性政策和临时政策，以及将来按照 ICANN 章程可能制定和实行的政策，前提是此类共识性政策和临时政策按 [请参见规范 1]* 中的程序进行采纳、与其中的主题相关并遵守其中规定的限制。
2.3 数据托管。注册管理执行机构应遵守 [请参见规范 2]* 中公布的注册数据托管程序。
2.4 每月报告。在每个月结束后的二十 (20) 日之内，注册管理执行机构应以 [请参见规范 3]* 中公布的格式向 ICANN 提交报告。
2.5 注册数据的公布。注册管理执行机构应根据 [请参阅规范 4]* 中公布的规范提供公众访问注册数据的途径。
2.6 保留名称。除 ICANN 以书面形式另行明确授权外，注册管理执行机构应保留来自首次注册（即除续签之外）并在 [请参见规范 5]* 中公布的“保留名称安排”中出现的所有字符串。注册管理执行机构可自行决定拟订有关保留或阻止 TLD 中附加字符串的政策。如果注册管理执行机构是注册 TLD（而非规范 5 中规定的注册管理执行机构保留的二级域名）中任何域名的注册人，则此类注册必须通过 ICANN 认证的注册服务商进行。任何此类注册将视为交易（如第 6.1 节中定义），以便于根据第 6.1 节计算注册管理执行机构要支付给 ICANN 的注册管理机构交易费用。
2.7 功能和性能规范。用于运营 TLD 的功能和性能规范在 [请参见规范 6]* 中规定。注册管理执行机构应遵守此类功能和性能规范，并至少在一年内保留足以证明遵守此类规范的技术和运营记录。
2.8 第三方合法权利的保护。注册管理执行机构必须指定并遵守一个流程和程序，用于启动 TLD 以及在首次注册和后续过程中对第三方的合法权利提供持续保护，该流程和程序应至少包括 [请参见规范 7]* 中规定的条款。在本协议生效日期后对此类流程和程序作出的任何更改或修改均应由 ICANN 提前做出书面批准。
2.9 注册服务商的使用。注册管理执行机构只能使用 ICANN 认可的注册服务商来注册域名。注册管理执行机构必须一视同仁地为所有 ICANN 认可的、签订并遵守注册管理执行机构的
TLD 注册管理机构/注册服务商协议的注册服务商提供注册服务访问权限。对于所有经授权可以在 TLD 中注册名称的注册服务商，注册管理执行机构必须使用统一的协议，并且可经常对该协议进行修订；但是所有修订都要经过 ICANN 的事先批准。
[针对注册管理机构和注册服务商分离，有四种方案供机构群体讨论和考虑：
(a) 无交叉所有权限制，除非存在市场支配力和/或注册价格上限（如有法规需求，留给管制机构来处理）
(b) 新注册管理机构无交叉所有权限制，现有限制针对现有注册管理机构。
(c) 有限度地取消限制，增强机构分离：
(i) 注册服务商不得出售共有注册管理机构中的名称，或
(ii) 注册服务商可出售共有注册管理机构中数量极为有限的名称。
(d) 完 全 限 制 ：
(i) 注册管理机构不得拥有任何比例的注册服务商所有权，反之亦然。
(ii) 注册服务商不得提供后端服务（这可能伴随有相互限制，例如，注册管理机构不得为其他注册管理机构提供后端服务，且注册管理机构不得设有分销商）。]
2.10 注册管理机构服务定价。除非第 2.10 节有规定，否则注册管理执行机构针对域名初始注册或域名注册续约的任何提价举动 [（退款、回扣、折扣、产品搭售或其它计划）]，应分别至少提前三十 (30) 天和一百八十 (180) 天向每个 ICANN 认可的执行注册管理执行机构“注册管理机构-注册服务商协议”的注册服务商发布通知，并为注册服务商提供以当前价格（即任何提价通知之前的价格）取得为期一至十年（由注册服务商自行选择），但不超过十年的域名注册续约方案。尽管有上述规定，如果最终价格少于或等于注册管理执行机构过去十二 (12) 个月内通知的价格，注册管理执行机构仅需提前三十 (30) 天就域名注册续约的任何提价举动发布通知，而不需要就收取第
6.3 节规定的可变注册管理机构费用发布通知。[注册管理执行机构应以相同的价格提供所有域名注册续约，除非在注册管理执行机构清晰明确公开此续约价格后注册人在域名初始注册时同意更高的价格。] 注册管理执行机构应自费为 TLD 提供面向公共的基于查询的 DNS 查找服务。
2.11 合同和运营合规审核。ICANN 可能会不时（每季度不超过一次）进行合同合规性审核，以评估注册管理执行机构是否遵守本协议第 2 节的相应约款。此类审核应针对评估合规性的目标而设计，ICANN 应合理地提前通知任何此类审核，此通知中应适当详细说明 ICANN 所要求的文档、数据和其他信息的类别。在任何此类审核过程中，注册管理执行机构应根据 ICANN 的要求履行以下义务：及时提供所有必要的相关文档、数据和任何其他信息，以证明注册管理执行机构遵守了本协议。ICANN 应至少提前五 (5) 天通知（或经注册管理执行机构同意另行指定提前期），以便可以在任何合同合规性审核过程中在正常工作时间进行现场访问，以评估注册管理执行机构是否遵守本协议第 2 节的相应约款。任何此类审核的费用均由 ICANN 承担，除非此类审核发现，注册管理执行机构支付的费用不一致，并给 ICANN 造成了超过注册费用 5% 的损害。在后一种情况下，
注册管理执行机构应向 ICANN 赔偿与此类审核相关的所有合理成本和费用，这些赔偿应在此类审核成本声明发送之日起的下一个注册管理机构费用支付日，与注册费用一起支付。
2.12 持续运营法律文书。注册管理执行机构应遵守 [请参阅规范 8] 中规定的与“持续运营法律文书”相关的条款与条件。
2.13 [说明：仅限基于群体的 TLD] 注册管理执行机构对 TLD 群体的责任。注册管理执行机构应按照提交的关于 TLD 的申请就以下各项制定注册政策：(i) TLD 中的命名规则；(ii) TLD 群体成员的注册要求；和 (iii) 按照基于群体的 TLD 的确定目标对已注册域名的使用。注册管理执行机构的 TLD 运营方式应该是允许 TLD 群体讨论和参与 TLD 政策和做法的制定和修改。注册管理执行机构应制定 TLD 注册政策的执行程序和有关 TLD 注册政策合规性的争议解决程序，还应执行这些注册政策。对于根据第 2.13 节引发的争议，注册管理执行机构同意受 [insert applicable URL] 中规定的 “注册管理机构限制争议解决流程”的约束。]
第 3 条
ICANN 约款
ICANN 与注册管理执行机构达成协议如下：
3.1 公开和透明。ICANN 将按照其公示的使命与核心价值，以公开透明的方式行使职责。
3.2 公平待遇。除非有实质性的正当理由，否则 ICANN 不得以武断、不合理、不公正的方式应用自己的标准、政策、程序或做法，也不得对注册管理执行机构区别对待。
3.3 TLD 名称服务器。ICANN 将通过合理的商业行为确保由注册管理执行机构提交给 ICANN 的对 TLD 名称服务器指定的任何变更（使用 ICANN 在 xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ 中指定的格式并包含所需的技术要素），都会由 ICANN 在技术验证后七天之内或尽快实施。如果授权 ICANN 设置官方根服务器系统政策，ICANN 将确保此官方根在本协议期限内指向由注册管理执行机构为 TLD 指定的顶级域名服务器，除非之前根据第 4.3 或 4.4 节终止。
3.4 根区域信息的公布。ICANN 在公布注册管理机构 TLD 的根区域联系信息时，应包括注册管理执行机构及其管理和技术联系人的信息。注册管理执行机构修改联系人信息的任何请求，必须始终以 ICANN 在 xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ 上指定的格式提出。
第 4 条 期限和终止
4.1 期限。本协议的期限将自生效日期起持续十年（此期限可根据第 4.2 节延长，以下简称“期限”）。
4.2 续约。在上述第 4.1 节中规定的初始期限和各个后续期限到期后，本协议都将进行续约（期限为十年的倍数），除非：
(a) 注册管理执行机构从根本上和实质上违反本协议第 2 条中规定的注册管理执行机构约款或没有履行本协议第 6 条规定的付款责任，并且在收到 ICANN 就此违约行为向注册管理执行机构发出的通知（应详细说明所指控的违约行为）后三十 (30) 天内未纠正自己的违约行为；
(i) 仲裁机构和法院最终裁定注册管理执行机构从根本上和实质上违反此约款或没有履行此付款责任，和 (ii) 注册管理执行机构未遵守此裁定，在十 (10) 天或仲裁机构和法院规定的其它时间期限内未纠正自己的违约行为；或
(b) 现行“期限”期间，仲裁机构（根据本协议第 5.2 节）最少在三 (3) 次不同情况下发现注册管理执行机构从根本上和实质上违反本协议第 2 条中规定的注册管理执行机构约款或没有履行本协议第 6 条规定的付款责任（不管有没有纠正）。
(c) 出现第 4.2 (a) 或 (b) 节中规定的事件后，本协议将于现行期限到期时终止。
4.3 ICANN 终 止 协 议 。
(a) 如发生以下情形，ICANN 可终止本协议：(i) 注册管理执行机构从根本上和实质上违反本协议第 2 条中规定的注册管理执行机构约款或没有履行本协议第 6 条规定的付款责任，在收到 ICANN 就此违约行为向注册管理执行机构发出的通知（应详细说明所指控的违约行为）后三十 (30) 天内没有纠正违约行为；(ii) 仲裁机构和法院最终裁定注册管理执行机构从根本上和实质上违反此约款或没有履行此付款责任；和 (iii) 注册管理执行机构未遵守此裁定，在十 (10) 天或仲裁机构和法院规定的其它时间期限内未纠正自己的违约行为。
(b) 如果注册管理执行机构在生效日期起 12 个月内未完成将所有 TLD 授权到根区域必要的测试和程序，ICANN 可在通知注册管理执行机构后终止本协议。如果注册管理执行机构能向 ICANN 证明其正在为成功完成 TLD 授权必须的步骤而勤勉诚实地努力，且得到了 ICANN的合理认同，则注册管理执行机构可以请求延长授权期限，最多可以延长 12 个月。在此终止日期之前由注册管理执行机构向 ICANN 支付的所有费用，应由 ICANN 全额保留。
(c) 如果注册服务商违反本协议第 2.12 节中规定的注册管理执行机构责任，且未在 ICANN 发出此类违约通知之后的三十 (30) 天内纠正违约行为，或如果“持续运营法律文书”在生效日期之后的任何时间连续超过六十 (60) 天无效，ICANN 在通知注册管理执行机构后可终止本协议。
4.4 注册管理执行机构终止协议。
(a) 如果发生以下情形，注册管理执行机构可在通知 ICANN 后终止本协议：(i) ICANN 从根本上和实质上违反第 3 节中规定的 ICANN 约款，并在注册管理执行机构就此违反行为向 ICANN 发出通知（应详细说明所指控的违约行为）后三十 (30) 天内没有纠正此违约行为；(ii) 仲裁机构和法院最终裁定 ICANN 从根本上和实质上违反本协议；和 (iii) ICANN 未遵守此裁定，在十
(10) 天或仲裁机构和法院规定的其它此类时间期限内未纠正自己的违约行为。
(b) 如发生以下情形，注册管理执行机构可在通知 ICANN 后终止本协议：(i) 在第 7.2(d) 节规定的通知期内，注册管理执行机构根据第 7 条就其对本协议所提议实质性修改的反对意见向 ICANN 发出通知（应详细说明反对意见的详细信息）；和 (ii) 此类修改之后以注册管理执行机构反对的形式生效，但有两个前提：其一，只有当注册管理执行机构在此类修改生效日期后三十
(30) 天内向 ICANN 发出必要的终止通知，注册管理执行机构方可根据第 4.4(b) 节终止本协议；其二，本协议应在注册管理执行机构向 ICANN 发出终止通知后的第一百二十 (120) 天按照本协议第 4.4(b) 节终止。
止本协议。
(c) 注册管理执行机构可在提前一百八十 (180) 天通知 ICANN 后，因任何原因终
4.5 协议终止时的注册管理机构移交。本协议期限到期以及因任何原因终止时，如果 ICANN 或 ICANN 指定的任何继任 TLD 注册管理机构提出合理要求，注册管理执行机构应同意向 ICANN 或此类注册管理机构提供维持运营和注册管理机构职能必需的所有 TLD 注册管理机构运营数据（包括根据第 2.3 节托管的数据）。与注册管理执行机构讨论后，ICANN 可根据 2009 年 4 月 25 日制定的《ICANN gTLD 注册管理机构连续性计划》（该计划同样可能会不定期修改）自行决定是否将 TLD 的运营移交至继任注册管理机构。此外，不管本协议终止或到期的理由为何，ICANN或 ICANN 指定的一方应保留并可执行其根据“持续运营法律文书”和其他法律文书（如果适用）应享有的权利。
4.6 存续条款。本协议的到期和终止不能免除本协议各方在本协议到期或终止之前产生的任何义务或违约赔偿责任，包括但不限于根据第 6 条产生的所有应计付款义务。此外，第 5 条和第 8 条，第 2.12 节，第 4.5 节以及第 4.6 节在本协议到期或终止后继续生效。
第 5 条争议解决
5.1 合作约定。在任何一方依据下文第 5.2 节之规定启动仲裁程序之前，ICANN 和注册管理执行机构应该开始诚恳的沟通，然后，双方必须以诚恳的态度进行至少十五 (15) 天的商讨，以尝试解决争议。
5.2 仲裁。由本协议引起或与本协议有关的争议，包括针对具体履行的申请，将依据国际商会（以下简称“ICC”）国际仲裁法院的规则进行具有约束力的仲裁加以解决。仲裁将以英语在美国加利福尼亚州洛杉矶县进行，由一位仲裁人作出裁决。仲裁中胜诉一方有权要求获得成本和合理的律师费用的补偿，仲裁人应在其裁决中包含此项补偿。在任何诉讼程序中，如果仲裁人裁决注册管理执行机构一再蓄意从根本上和实质上违反本协议第 2 条、第 6 条和第 5.4 节中规定的注册管理执行机构义务，ICANN 均可向指定的仲裁人申请惩罚性或警告性赔偿，或对注册管理执行机构进行运营制裁（包括但不限于发出临时限制注册管理执行机构出售新注册的权利的指令）。在涉及 ICANN 且与本协议有关的任何诉讼中，此类诉讼的辖区和唯一审判地点将是位于美国加利福尼亚州洛杉矶县的法院；但是，协议双方均有权通过任何具备有效管辖权的法院来强制执行上述法院的审判结果。
5.3 责任限制。ICANN 在违反本协议时的总赔偿金额不得超过注册管理执行机构根据本协议在前十二个月期限内向 ICANN 支付的注册管理机构费用的金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内）。注册管理执行机构在违反本协议时对 ICANN 的总赔偿金额仅限于在前十二个月期限内向 ICANN 支付的费用的金额（如果有第 6.3 节中规定的可变注册管理机构费用，则不包括在内），以及第 5.2 节规定的惩罚性或警告性赔偿（如果有）。除第 5.2 节中规定的赔偿之外，在任何情况下，任意一方均无需承担因本协议引起或与本协议有关的特殊损害赔
偿、惩罚性损害赔偿、警告性损害赔偿或间接损害赔偿，也无需对履行或不履行本协议中规定的义务承担损害赔偿责任。
5.4 强制履行。注册管理执行机构和 ICANN 同意，不按照本协议的细则来履行本协议条款将可能造成无法挽回的损害。因此，双方同意各方均应有权请求仲裁人发出强制履行本协议条款的命令（此外，双方还有权采取其他任何补救措施）。
第 6 条费用
6.1 注册管理机构费用。注册管理执行机构应向 ICANN 支付注册管理机构费用，支付金额等于：(i) 每个季度 6,250 美元的注册管理机构固定费用；加上 (ii) 注册管理机构交易费用。注册管理机构交易费用等于：在适用的季度内首次域名注册或续签域名注册（一级或多级注册，包括与在 ICANN 认可的注册服务商之间迁移域名相关的续签，各为一个“交易”）每年递增的数量乘以
0.25 美元。但是，只有在 TLD 中注册的域名超过 50,000 个以后才应支付注册管理机构交易费，并且此后每个交易都应付费。如果适用，注册管理执行机构应在每个季度结束后的第 20 天（即 4 月 20 日、7 月 20 日、10 月 20 日和 1 月 20 日，分别对应于在 3 月 31 日、6 月 30 日、9 月 30 日和 12 月 31 日结束的季度）支付注册管理机构费用，即全年向 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 财年的最后一个季度）支付。注册管理执行机构可向与自己签订《注册管理机构/注册服务商协议》的注册服务商开具发票，并征收可变注册管理机构费用，但前提是如果向任何一个注册服务商开具发票，则应向 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) 天，则按适用法律允许的最大利率支付延迟付款的附加费用。
第 7 条修订
7.1 期限和规范的修订。在本协议期限内，ICANN 可依照本协议第 7 条规定的流程，根据变化的标准、政策和要求修改第 2 条（包括根据第 2 条并入本协议的规范）、第 6 条和第 8 条；但前提是 (i) ICANN 不得利用第 7 条增加应付费用的金额，除非 ICANN 能证明其有增加此类费用的财政需求；(ii) 所有修正案的适用均无追溯效力；和 (iii) ICANN 不得利用本协议第 7 条修改第 2.1节、第 2.2 节或 [请参阅规范 1] 中规定的用于采纳和执行新的或修改后的共识性政策或临时政策的流程。
7.2 变更流程。根据第 7.1 节修订本协议的流程如下：
(a) 在正式提议任何修正案之前，ICANN 将提供不少于三十 (30) 天的期限，以便与受此类修正案影响的注册管理执行机构商讨，并考虑这些运营商的意见；
(b) 进行此类商讨并考虑相关意见后，ICANN 应在其网站上就本协议的任何提议修正案（包括修正案的文本，且包括纳入本协议的规范的任何修正案）发布至少为期三十 (30)天的正式通知，注册管理执行机构可在此期间提交对修正案的意见；
(c) 在公共通知期过后及 ICANN 理事会批准修正案以后，ICANN 应通过在其网站上公布生效通知的形式，在此类修正案生效之日前至少九十 (90) 天通知注册管理执行机构此类修正案（包括纳入本协议的规范的任何修正案）的最终条款。
(d) 自获批修正案的公共通知日期开始，注册管理执行机构有六十 (60) 天的时间向 ICANN 发布对此类修正案的否决通知；
(e) 在此六十 (60) 天期间，如果受此修正案影响的多数顶级域注册管理执行机构（例如，本协议所述的注册管理执行机构和其他任何与 ICANN 签订包含与本协议第 7 条类似条款的注册管理机构协议的注册管理执行机构）向 ICANN 发布其对此类修正案的否决通知，则应视为该修正案遭到受影响的注册管理执行机构否决；
(f) 如果受影响的注册管理执行机构按照以上条款 (e) 中规定的流程否决了此类修正案，则在以下情形下，ICANN 理事会可通过三分之二多数成员投票同意的方式在三十 (30) 天内推翻此类否决动议：(i) 对于与向 ICANN 支付费用相关的任何修正案，如果该修正案的合理性得到 ICANN 财政需求的证明，和 (ii) 对于其他任何修正案，如果该修正案的合理性得到与互联网或域名系统安全性或稳定性（此类术语在第 8.3 节中有定义）有关的重要和紧迫需求的证明，则在此情况下，所提议修正案应在此三十 (30) 天到期后立即生效。如果 ICANN 理事会没有推翻此类否决动议，则所提议修正案无效。
第 8 条杂项
8.1 对 ICANN 的 补 偿 。
(a) 如果注册管理执行机构对 TLD 注册管理机构的运营或注册管理执行机构提供的注册管理机构服务引发任何第三方索赔、损害赔偿、债务、费用和开支（包括法律费用和开支），注册管理执行机构应为 ICANN 及其理事、官员、雇员和代理人（通称为“受补偿人”）提供补偿和辩护；但如果索赔、损害赔偿、债务、费用和开支是因 ICANN 违反本协议所含任何义务或 ICANN 的故意不当行为而产生，则注册管理执行机构对任何受补偿人均无补偿或辩护义务。本节不适用于任何与各方之间的诉讼或仲裁有关的律师费用请求。本节不应视为要求注册管理执行机构向 ICANN 偿还或补偿与本协议的协商或执行相关的成本或与监督或管理本协议各方各自的协议义务相关的成本。此外，本节也不适用于与本协议各方之间任何诉讼或仲裁相关的律师费的申请，该费用应由第 5 条规定或由法院或仲裁机构判定。
(b) 如果 ICANN 对参与引起索赔的同一行为或疏忽行为的多个注册管理执行机构（包括“注册管理执行机构”）提出补偿要求，注册管理执行机构对 ICANN 关于此类索赔的总补偿金额应限定于 ICANN 索赔总额的一部分，计算方法：将在 TLD 中注册管理执行机构注册的域名总数（注册域名总数的计算方法应与第 6 条规定的任何适用季度的计算方法一致）除以注册管理执行机构参与的引起索赔的同一行为或疏忽行为所涉及的所有顶级域中的注册域名总数。为了按照第 8.1(b) 节的规定减轻注册管理执行机构按照第 8.1(a) 节应承担的责任，注册管理执行机构应负责确定参与引起索赔的同一行为或疏忽行为的其他注册管理执行机构，并在得到 ICANN 合理认可的前提下证明这些注册管理执行机构存在参与此类行为或疏忽行为的过失。为避免疑义，如果注册管理执行机构参与了引起索赔的同一行为或疏忽行为，但此注册管理执行机构对于 ICANN 没有以上第 8.1(a) 节中规定的相同或类似的补偿义务，则上一句的计算中仍应包括由此类注册管理执行机构管理的域名数量。
8.2 补偿程序。如果发生属于以上第 8.1 节补偿范围的任何第三方索赔，则 ICANN 应尽快通知注册管理执行机构。注册管理执行机构可在自愿的基础上，通过迅速向 ICANN 发出通知而立即接管此类索赔的辩护和调查，并雇用 ICANN 理应接受的律师进行处理和辩护，有关费用和开支全部由注册管理执行机构承担；但无论是什么情况，ICANN 都可以自费控制与 ICANN 政策或行
为的合法性或阐释有关的问题的诉讼。在注册管理执行机构承担费用和开支的情况下，ICANN 应该与注册管理执行机构及其律师在此类索赔和由此产生的任何申诉的调查、审判和辩护中进行一切合理的合作；ICANN 也可以在自费的情况下，通过自身的律师或其他途径参与此类索赔和由此产生的任何申诉的调查、审判和辩护。未经 ICANN 同意，不得达成任何涉及影响到 ICANN 的赔偿的索赔和解，除非需要支付的金额完全由注册管理执行机构补偿。如果注册管理执行机构没有按照本协议第 8.2 节规定对此类索赔辩护取得完全控制权，则 ICANN 有权以它认为合适的方式对索赔进行辩护，费用和开支由注册管理执行机构承担。
8.3 术语定义。在本协议中，“安全性”和“稳定性”的定义如下：
(a) 在本协议中，对“安全性”造成影响是指 (1) 出现未经授权而泄露、篡改、插入或销毁注册数据的情况，或 (2) 遵照所有适用标准运行的系统出现未经授权而访问或泄漏互联网信息或资源的情况。
(b) 在本协议中，对“稳定性”造成影响是指 (1) 不符合由信誉卓著、业界公认的互联网标准组织发布的相关权威性适用标准，例如互联网工程任务组提出的相关标准通道或当前最佳实践意见征求稿（“RFC”)，或 (2) 对于遵守由xxxx、业界公认的互联网标准组织发布的相关权威性适用标准（例如 IETF 提出的相关标准通道或当前最佳实践 RFC）并依赖于注册管理执行机构的授权信息或提供的服务而运行的互联网服务器或终端系统，给其吞吐能力、响应时间、一致性或连贯性带来负面影响。
8.4 禁止抵销。不论注册管理执行机构与 ICANN 之间有无悬而未决的纠纷（金钱或其他方面），本协议规定的所有付款应在本协议期限内及时付清。
8.5 控制权变更；转让和分包。任何一方都不得在未经对方书面批准的情况下转让本协议，同时任何一方都不得无理地拒绝批准。尽管有上述规定，如 ICANN 发生重组或再合并， ICANN 可将本协议转让给另一家出于相同或基本相同的目的而组建的非营利性公司或相似实体。注册管理执行机构必须至少提前三十 (30) 天将所有重要分包安排通知 ICANN，有关分包部分 TLD运营业务的协议必须遵守注册管理执行机构在本协议中的所有约款、义务和协议。如果预计有任何完成的交易可能导致注册管理执行机构的所有权或控制权发生直接或间接变更，注册管理执行机构应在该交易完成前至少十 (10) 天向 ICANN 发布通知。此类所有权或控制权变更通知应包括一项声明，确认获取此所有权和控制权一方的最高总部遵守 ICANN 为注册管理执行机构标准制定的规范和政策，并确认注册管理执行机构遵守本协议的义务。在收到此通知三十 (30) 天内，ICANN 可向注册管理执行机构索取更多信息以遵守本协议，对此，注册管理执行机构必须在十五 (15) 天内提供所要求的信息。
8.6 修订和弃权。除第 7 条规定的情况外，未经协议双方签字生效，本协议的任何修订、补充、更改或这些改动中的任何条款均无约束力。尽管有第 7 条之规定，ICANN 和注册管理执行机构可随时通过仅在双方之间进行的谈判中，达成对本协议的双边修订和更改。除非放弃遵守条款的一方出具已经过签字的书面材料，否则对本协议任何条款的放弃均不具有约束力。除非弃权方另外明确表示，否则对本协议中任何条款的放弃或未执行本协议中任何条款的事实，均不应视为或构成对本协议中任何其他条款的放弃，也不应构成持续的弃权。
8.7 无第三方受益人。本协议不应解释为 ICANN 或注册管理执行机构给本协议之外的任何一方（包括任何注册服务商或已注册名称持有人）施加任何义务。
8.8 一般通知。除了根据第 7 条规定做出的通知，有关本协议的所有通知的发送形式为：(i) 按照下面列出的地址以书面形式发往相应当事方；或 (ii) 通过传真或电子邮件发出。除非相应当事方已通知变更邮政地址、电子邮件地址或传真号码，否则将按照本协议提供的下列地址或传真号码发送有关本协议的所有通知。应通过在 ICANN 的网站上发布相关信息，并通过电子邮件将此类信息发送至注册管理执行机构，来发布第 7 条要求的通知。如一方要更改下文的通知联系信息，必须在此类变更发生后三十 (30) 天内通知对方。所有根据本协议发出的所有通知、任命、决议和说明均以英语书写。除根据第 7 条规定做出的通知以外，在下列情况中，本协议要求的任何通知都将视为已适当提供：(i) 如果是纸面通知，当面递送或通过快递服务递送并收到送达确认；(ii) 如果是传真或电子邮件形式的通知，收到接收方传真机或电子邮件服务器的送达确认，但前提是，通过传真或电子邮件传送通知后应在两 (2) 个工作日之内由正常邮递服务传送一份副本。对于第 7 条要求的任何通知，如果在 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
收件人：总裁兼首席执行官 同时必须将副本送至：总顾问
电子邮件：（按当时的指定地址。）
注册管理执行机构的通信地址如下：
[ ]
[ ]
[ ]
电话： 传真： 收件人：
同时必须将副本送至：
电子邮件：（按当时的指定地址。）
8.9 协议完整性。本协议（包括通过引用本协议中的 URL 地址而并入的规范和文档）构成双方就 TLD 的运营而达成的完整协议，取代双方此前在该问题上的所有口头或书面协议、谅解、谈判和讨论。
8.10 英语语言控制。虽然注册管理执行机构可能会收到本协议（和/或规范）的翻译版本，但本协议（及其所有引用规范）的英语版是约束协议双方的正式版本。如果本协议的任何翻译版本和英语版本存在冲突或差异，则以英语版本为准。所有根据本协议发出的所有通知、任命、决议和说明均以英语书写。
* * * * *
双方兹派其正式授权代表签署本协议，特此为证。互联网名称与数字地址分配机构
代表：
[ ]
总裁兼首席执行官
日期：
[注册管理执行机构]
代表：
[ ]
[ ]
日期：
附录 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.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.2 ICANN 还应发表咨询声明，详细阐明采用临时政策的原因，以及董事会为何认为此类临时政策会得到互联网利益主体的一致同意。
2.3 如果采用临时政策的持续时间超过 90 天，董事会应每 90 天重申暂时采用该临时政策，总持续 时间不得超过 1 年，以使此类临时政策在上述期限内始终有效，直到成为合意政策时为止。如果持续时间超过 1 年，或者如果在此 1 年内，临时政策没有成为合意政策，并且董事会没有重申采用该政策，则注册运营商不再需要遵守或实施此类临时政策。
3. 通知和冲突。考虑到可能存在的紧急情况，注册运营商在收到确立合意政策或临时政策的通知后，应 获得一段合理的时间来逐步适应此类规范或政策。如果注册服务与合意政策或任何临时政策发生冲突，应以合意政策或临时政策为准，但仅限于发生冲突的主题。
规定 2
数据托管要求
注意：ICANN 与多家注册管理机构的技术团队正在制定本规定的中期草案。
注册管理执行机构将根据与注册管理机构协议相关的数据托管服务的规定，指定某一独立实体作为数据托管代理（以下简称“托管代理”）。注册管理执行机构与托管代理之间达成的任何数据托管协议，均应包含以下第一部分中规定的技术规范，以及第二部分中规定的法律要求，并且必须将 ICANN 认定为第三方受益人。除以下要求外，数据托管协议还可以包含其他规定，但这些规定不能破坏下面提供的必要条款，或与这些条款相抵触。
第一部分 － 技术规范
1. 寄存。寄存分为两种：完全寄存或增量寄存。
1.1 “完全寄存”是指符合以下条件的注册管理机构数据：反映当前的整个注册管理机构数据库，其中包含的数据反映了到每个星期日 0000 UTC 为止的注册状态。在此时刻的未决交易
（即尚未提交到注册管理机构数据库中的交易）不会反映在完全寄存中。
1.2 “增量寄存”是指符合以下条件的数据：反映所有涉及数据库，但根据具体情况未在上次完全寄存或增量寄存中反映的交易。每个增量文件将包含完成上次寄存（到 0000 UTC 为止）后的所有数据库交易。如有要求，增量寄存必须包括下文规定的完整托管记录，这些记录自最近一次完全寄存或增量寄存之后没有添加或更改（即，新添加或修改的名称）。
2. 寄存程序。每个具有特定格式的完全寄存和增量寄存均须进行适当处理，并以加密形式发送给托管代理。这些特定格式的寄存文件在经过加密和签名后，必须在指定的时限内通过经过验证的安全文件发送到托管代理的服务器。请参阅第二部分 － 法律要求。
3. 寄存时间表。注册管理执行机构有义务根据以下要求每日提交一组托管文件：
3.1 每周必须提交一次注册管理机构中整组对象的完全寄存。这些文件均须使用“full”类型标注。
3.2 在每周的其他六天中，均须提交包括已创建、删除或更新对象的增量寄存。这些文件均须使用“inc”类型标注。
3.3 每次增量提交必须涵盖自生成上次提交以来的时间段。
3.4 增量寄存之间允许有一部分重叠，尽管我们希望这是例外情况。
4. 托 管 格 式 规 范 。
4.1 文件命名规则。文件应该根据以下规则命名：
<gTLD>_<YYYY-MM-DD>_<FILE>_<type>_<comp>_<encrypt>_S<#>_R<rev>.<ext>，其中：
4.1.1 <gTLD> 将替换为 gTLD 名称；如果是 IDN-TLD，则必须使用 ASCII 标签；
4.1.2 <YYYY-MM-DD> 将替换为与交易时间线水印对应的日期，例如，对于与 2009-08- 02T00:00Z 对应的完全寄存，使用的字符串应该为“2009-08-02”；
4.1.3 <FILE> 将替换为下面 4.8 所示的文件类型；
4.1.4 <type> 将替换为：
(1) “full”（如果数据代表完全寄存）；
(2) “inc”（如果数据代表增量寄存）；
4.1.5 <comp> 将替换为所用压缩算法的名称，请参阅 4.10 部分：
4.1.6 <encrypt> 将替换为所用的对应加密算法，请参阅 4.10 部分：
4.1.7 <#> 将替换为该文件在一系列文件中的位置，以“1”开头；如果是单独的文件，则 <#>
将替换为“1”。
4.1.8 <rev> 将替换为文件修订（或重新发送）的次数，以“0”开头：
4.1.9 <ext> 将替换为“data”（如果文件包括可能压缩和/或加密的实际数据）；或将替换为 “sig”（如果是对应数据文件的数字签名文件）。
4.2 对象句柄。对于每种对象类型（域、联系人、名称服务器、DNSSEC 授权签名者记录和注册服务商），ID 或“句柄”将用于允许以紧凑方式引用来自其他文件的对象。
4.2.1 这些句柄可以使用字母数字值表示，以提供最大的灵活性。
4.2.2 注册管理执行机构可以使用域名作为域句柄。
4.3 日期。指示“日期”的多个字段，如域的创建日期或到期日期。这些字段应该包含以某种格式指示日期和时间的时间戳，以及在托管寄存中的所有此类字段之间保持一致的时区。时间戳应该相对于 UTC 来表示，与 RFC 4930 EPP [1] 中使用的日期/时间处理方式一致。
4.4 CSV 格式。如 RFC 4180 [5] 中所述，托管数据应编译为 CSV 文本文件。这些文件的字符编码应为 UTF-8。一旦压缩和/或加密，这些数据文件将转换为二进制形式。签名文件不得压缩或加密。
4.5 对象状态。RFC 4930 (EPP) 和相关的 RFC（请参阅 [1]、[2]、[3]、[4]）指示允许用于各种注册管理机构对象的状态代码。此外，域可使用“reserved”状态；用于指示代表注册管理机构或 ICANN 的保留名称。
4.6 保留名称的处理。注册管理机构通常会为自己或 IANA 保留一组名称。保留名称必须包括在 DOMAIN 文件中，并在 DOMSTATUS 文件中有与其相关的特殊“reserved”状态来指示此名称已保留。
4.7 变量的处理。如果注册管理执行机构提供 IDN，变量表和注册政策必须寄存在 IANA IDN 实践方法库 [9] 中。在某些情况下，一个特定名称可能有多个“变量”，此时保留域名意味着要以相应的语言表示法保留一个或多个等效的其他名称。根据实施情况，有数种可能的托管方法，注册管理机构应根据需要使用最适当的方法：
(1) 可以在注册管理机构中表示多个名称变量，并存在于 DNS 区域中；每个此类名称
都应存储在 DOMAIN 和 DOMIDN 文件中，below。
(2) 在某些情况下，可以使用上述“DOMIDN”文件的形式存储变量，其中变量名称以 Unicode 形式表示，并与“父/正则”域名相关联。
(3) 有时会使用某种算法生成变量名称，若变量的数目过于巨大，将无法进行存储或直接提交进行托管。在这种情况下，带外文档必须提供有关变量生成算法的详细信息。还可能需要添加扩展文件，以指示（对于包含变量名称的域）用于计算变量的算法和任何其他参数。
4.8 详细文件格式。
每个对象显示其字段的顺序指示这些字段在各自记录中的预期显示顺序。所有文件的第一行必须包含字段名称。
4.8.1 域。指示文件类型“DOMAIN”
以下字段应存储在 DOMAIN 文件中：
(1) 域句柄；
(2) 域名；
(3) 当前赞助注册服务商的注册服务商句柄；
(4) 创建日期；
(5) 初始赞助注册服务商的注册服务商句柄；
(6) 到期日期；
(7) 域的 Authinfo；以及
4.8.2 国际化域名 (IDN)。对于国际化域名，应在域名字段（例如“xn-11b5bs1di.tld”）中引用
IDN 字符串的 ASCII 兼容形式 (A-Label)，而不是 Unicode 标签 (U-Label)。以下字段应存储在 DOMIDN 文件中：
(1) 域句柄；
(2) Unicode 标签/U-Label；
(3) 语言标记（基于 ISO 639-1）；以及
(4) 脚本标记（基于 ISO 15924）。
4.8.3 联系人。指示文件类型“CONTACT”。以下字段应存储在 CONTACT 文件中：
(1) 联系人句柄；
(2) 赞助注册服务商的注册服务商句柄；
(3) 创建日期；
(4) 联系人的 Authinfo；
(5) 语音电话号码；
(6) 语音电话分机号码；
(7) 传真电话号码；
(8) 传真分机号码；
(9) 电子邮件地址；
(10) 创建者注册服务商的注册服务商句柄；
(11) 上次更新联系人信息的注册服务商的注册服务商句柄；
(12) 上次更新日期；
(13) 上次传输日期；
4.8.4 联系人地址。指示文件类型“CONADDR”。包含联系人地址。如果是不同的类型，则每个联系人仅允许使用两个地址。以下字段应存储于 CONADDR 文件中：
(1) 联系人句柄；
(2) 地址类型：int / loc，请参阅 RFC 4933 [4]；
(3) 联系人名称；
(4) 联系人的组织；
(5) 邮政地址 1；
(6) 邮政地址 2；
(7) 邮政地址 3；
(8) 城市；
(9) 州/省/区域；
(10) 邮政编码；
(11) 国家/地区；
4.8.3 和 4.8.4 的注意事项：
标准文档可以使用以下字段来指示验证要求。具体来说，EPP 联系人映射 [4] 要求引用其他标准文档，如下所示：
国家/地区
国家/地区标识符使用 ISO 3166 中指定的两个字符标识符表示。电话号码
电话号码（语音和传真）的格式基于 ITU 标准 E164a 中定义的结构。电子邮件地址
电子邮件语法在 RFC 2822 中定义。
4.8.5 名称服务器。指示文件类型“NAMESERVER”。以下字段应存储在 NAMESERVER 文件中：
(1) 名称服务器句柄；
(2) 名称服务器名称；
(3) 创建日期；以及
(4) 赞助注册服务商的注册服务商句柄。
4.8.6 名称服务器 IP 地址。指示文件类型“NSIP”以下字段应存储在 NSIP 文件中：
(1) 名称服务器句柄；以及
(2) IP 地址。
注意事项。对于 IPv4 地址，IP 地址必须符合 RFC 791；对于 IPv6 地址，IP 地址必须符合 RFC 4291。
4.8.7 注册服务商。指示文件类型“REGISTRAR”以下字段应存储在 REGISTRAR 文件中：
(1) 注册服务商句柄；
(2) 根据 IANA 注册服务商 ID [8] 表示的注册服务商 IANA ID；以及
(3) 注册服务商名称；
4.8.8 域/状态关联。指示文件类型“DOMSTATUS”以下字段应存储在 DOMSTATUS 文件中：
(1) 域句柄；
(2) 状态值（详见上述“对象状态”一节）；以及
(3) 原因代码。
4.8.9 联系人/状态关联。指示文件类型“CONSTATUS”
以下字段应存储在 CONSTATUS 文件中：
(1) 联系人句柄；
(2) 状态值（详见上述“对象状态”一节）；以及
(3) 原因代码。
4.8.10 名称服务器/状态关联。指示文件类型“NSSTATUS”以下字段应存储在 NSSTATUS 文件中：
(1) 名称服务器句柄；
(2) 状态值（详见上述“对象状态”一节）；以及
(3) 原因代码。
4.8.11 域/联系人关联。指示文件类型“DOMCONTACT”以下字段应存储在 DOMCONTACT 文件中：
(1) 域句柄；
(2) 联系人句柄；以及
(3) 联系人类型。
可能的类型 | 缩写 |
注册人联系人 | R、REG |
管理联系人 | A、ADMIN |
付费联系人 | B、BILL |
技术联系人 | T、TECH |
4.8.12 域/名称服务器关联。指示文件类型“DOMNS”以下字段应存储在 DOMNS 文件中：
(1) 域句柄；以及
(2) 名称服务器句柄。
4.8.13 域删除。指示文件类型“DOMDEL”。仅增量托管寄存（例如文件类型“inc”）需发送此文件；此文件表示已删除的上次寄存中的域的列表。
(1) 域名；以及
(2) 删除日期。
4.8.14 联系人删除。指示文件类型“CONTDEL”。仅增量托管寄存（例如文件类型“inc”）需发送此文件；此文件表示已删除的上次寄存中的联系人列表。
(1) 联系人句柄；以及
(2) 删除日期。
4.8.15 名称服务器删除。指示文件类型“NSDEL”。仅增量托管寄存（例如文件类型“inc”）需发送此文件；此文件表示已删除的上次寄存中的名称服务器列表。
(1) 名称服务器名称；以及
(2) 删除日期。
4.8.16 域/DNSSEC 授权签名者记录关联。指示文件类型“DOMDS”。仅前五个字段为必填字段，其余字段可保留为空。这些字段与 RFC 4310 [10] 中所述的字段相关。
以下字段应存储在 DSDEL 文件中：
(1) 域句柄；
(2) 密钥标记；
(3) 算法；
(4) 摘要类型；
(5) 摘要；
(6) 签名最长存储时间；
(7) DNSKey 标志；
(8) DNSKey 协议；
(9) DNSKey 算法；
(10) 公钥；
4.8.17 DNSSEC 授权签名者记录删除。指示文件类型“DSDEL”。仅增量托管寄存（例如文件类型“inc”）需发送此文件；此文件表示上次寄存中曾拥有 DNSSEC 授权签名者记录而现在已没有此类记录的域的列表。
以下字段应存储在 DSDEL 文件中：
(1) 域句柄；以及
(2) 删除日期。
4.8.18 联系人信息披露。指示文件类型“CONDISCL”。除联系人句柄以外，本文件中的所有字段仅能为“true”、“false”或为空。
以下字段应存储在 CONDISCL 文件中：
(1) 联系人句柄；
(2) 国际化名称；
(3) 本地化名称；
(4) 国际化组织；
(5) 本地化组织；
(6) 国际化地址；
(7) 本地化地址；
(8) 语音；
(9) 传真；
(10) 电子邮件。
4.8.19 EPP 服务器数据收集政策。指示文件类型“DCP”。这些文件类型与 EPP 中的第 2.4 节相关，请参阅 [1]。所有字段仅能为“true”、“false”或为空。
以下字段应存储在 DCP 文件中：
(1) 全部访问；
(2) 无任何访问；
(3) 空访问；
(4) 个人访问；
(5) 个人和其他访问；
(6) 其他访问；
(7) 管理员声明；
(8) 联系人声明；
(9) 条款声明；
(10) 其他声明； |
(11) 其他收件人； |
(12) 我们的收件人；
(13) 公共收件人； |
(14) 同一收件人； (15) 无关收件人； |
(16) 业务保留； |
(17) 不定保留； (18) 法律保留； |
(19) 无保留； |
(20) 声明保留； (21) 绝对到期； |
(22) 相对到期； |
4.8.20 支持的 EPP 版本。指示文件类型“EPPVERSIONS”。列出注册管理机构支持的 EPP 版本。以下字段应存储在 EPPVERSIONS 文件中：
(1) 支持的版本；
4.8.21 文本响应语言。指示文件类型“LANGS”。列出服务器已知的文本响应语言的标识符。以下字段应存储在 LANGS 文件中：
(1) 支持的语言；如 RFC 4646 和 4647。
4.8.22 支持的 EPP 对象。指示文件类型“EPPOBJECTS”。列出服务器可管理的 EPP 对象。以下字段应存储在 EPPOBJECTS 文件中：
(1) 对象名称；
(2) 对象 URI；
4.8.23 支持的 EPP 扩展名。指示文件类型“EPPEXTENSIONS”。列出注册管理机构支持的
EPP 扩展名。
以下字段应存储在 EPPEXTENSIONS 文件中：
(1) 扩展名名称；
(2) URI 扩展名；
4.9 扩展名。如果某一特定注册管理执行机构的合同要求提交上文未包含的附加数据，则应逐个定义附加的“扩展”文件以表示该数据，该数据可以使用域、联系人、名称服务器和注册服务商句柄，以便使该数据与这些对象关联起来。此外该数据还可以引入新的对象，再通过这些新对象自身的句柄，让扩展文件指示对这些新对象的引用。ICANN 和各自的注册管理机构应共同协作，就此类新对象的数据托管规范达成一致。
4.10 压缩和加密。应使用压缩来缩短注册管理机构与托管代理之间的传输时间，并减少存储容量要求。应使用数据加密来保护注册管理机构托管数据的隐私性。
经压缩和加密处理的文件应按照 OpenPGP 消息格式（RFC 4880）转换为二进制 OpenPGP 格式，请参阅 [6]。公钥加密、对称密钥加密、哈希和压缩可接受的算法为 RFC 4880 中列举的算法，而不是 OpenPGP IANA 注册管理机构 [7] 中标记为不支持的算法（同样也免版税）。
4.11 数据文件处理。原始文本格式的数据文件的处理流程如下：
(1) 文件应进行压缩。对于此操作是否与加密过程一起执行，本规范不作要求。根据 RFC 4880，压缩算法推荐使用 ZIP。
(2) 压缩数据应使用托管代理的公钥进行加密。根据 RFC 4880，公钥加密算法推荐使用 Elgamal 和 RSA。根据 RFC 4880，对称密钥加密算法推荐使用 TripleDES、AES128 和 CAST5。
(3) 文件在压缩和加密后如果超过托管代理同意的文件大小限制，必要时可进行分割。在本部分，分割文件的各个部分或整个文件（如果未对文件进行分割）将称为已处理文件。
(4) 应使用注册管理机构私钥为每一个已处理文件生成一个数字签名文件。根据 RFC 4880，数字签名算法推荐使用 DSA 和 RSA。数字签名中的哈希算法推荐使用 SHA256。
(5) 此后，已处理文件和数字签名文件应传输给托管代理。本规范不要求任何特定的传输机制，但最好采用电子形式传输；可接受的方案包括（但不限于）：经托管代理同意，通过 SFTP 等协议进行电子传输，或通过 CD-ROM、DVD-ROM 或 USB 存储设备等物理介质进行传输。
(6) 托管代理应通过验证对应签名文件中包含的数字签名，来验证所传输的每一个（已处
理）数据文件。请参阅 7。
5. 公钥分发。每个注册管理执行机构和托管代理将按照指定的电子邮件地址将公钥分发给另一方（注册管理执行机构或托管代理，根据具体情况而定）。各方应该通过回复电子邮件确认收到另一方的公钥，分发方随后将重新确认通过脱机方法（如面对面、电话等）所传输密钥的真确性。通过这种方式，可确认公钥被传输给能够通过分发方使用的邮件服务器收发邮件的用户。托管代理、注册管理机构和 ICANN 之间均应按照上述程序交换密钥。
6. 寄存通知。注册管理执行机构每提交一个寄存，都必须同时向托管代理和 ICANN 提交一份书面声明（可以通过经验证的电子邮件提交），其中要包含在创建寄存时生成的报告副本，并声明该寄存经过注册管理执行机构检查，是完整而准确的。托管代理将在收到每个寄存后两个工作日内将寄存情况通知 ICANN。
7. 验 证 程 序 。
{有待在后续版本中开发。}
8. 参 考 信 息 。
[1] 可扩展供应协议 (EPP)，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[2] EPP 域名映射，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[3] EPP 主机映射，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[4] EPP 联系人映射，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[5] 逗号分隔值 (CSV) 文件的通用格式与 MIME 类型，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[6] OpenPGP 消息格式，xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
[7] OpenPGP 参数，xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx-xxxxxxxxxx/xxx-xxxxxxxxxx.xxxxx
[8] IANA 注册服务商 ID，xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx/
[9] IANA IDN 实践方法库，xxxx://xxx.xxxx.xxx/xxxxxxx/xxx-xxxxxx/
[10] 可扩展供应协议 (EPP) 的域名系统 (DNS) 安全扩展映射，
xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
第二部分 － 法律要求
1. 托管代理。注册管理执行机构在签订托管协议前，必须联系 ICANN 并通报托管代理的身份，同时向 ICANN 提供联系信息和相关托管协议副本以及所有相关修正。必须明确将 ICANN 指定为此类协议的第三方受益人。
2. 费用。注册管理执行机构必须直接或让其代表代为向托管代理付费。如果注册管理执行机构未能在截止日期前付清任何费用，托管代理将向 ICANN 发出有关未付费情况的书面通知，而 ICANN 可在收到托管代理的书面通知后十个工作日内支付过期未付费用。在 ICANN 支付过期未付费用后，ICANN 应向注册管理执行机构索要该笔费用，而注册管理执行机构必须将该笔费用连同按注册管理机构协议需交纳的下一笔费用提交给 ICANN。
3. 所有权。在注册管理机构协议有效期内，寄存所有权始终归注册管理执行机构所有。因此，注册管理执行机构应将此类寄存的任何所有权（视具体情况而定，可能包括知识产权）分配给 ICANN。在注册管理机构协议期限内，如果托管向 ICANN 让渡任何寄存，则注册管理执行机构对此寄存的知识产权将在非独家、永久、不可撤销、免版税和已付费的基础上自动授予 ICANN 或 ICANN 书面指定的一方。
4. 完整性和保密性。托管代理必须 (i) 将寄存保管于有保卫措施、经锁定和对环境安全的设施内，该设置只能由托管代理的授权代表访问；(ii) 使用在商业上合理的措施保护寄存的完整性和保密性。ICANN 和注册管理执行机构将有权检查托管代理的相应记录，此类检查应有事先的合理通知，并且须在正常工作时间进行。
如果托管代理从法院或其他司法仲裁庭收到与寄存披露或让渡相关的传票或其他任何命令，除非有法律禁止，否则托管代理应立即通知注册管理执行机构和 ICANN。通知注册管理执行机构和 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。
6.6 托管代理在注册管理机构协议或托管协议终止时必须将所有寄存交付给 ICANN，除非托管代理先前已将注册管理执行机构的寄存让渡给 ICANN 或 ICANN 指定的一方。
7. 寄 存 验 证 。
7.1 在收到每个寄存后两个工作日内，托管代理必须验证每个寄存的格式和完整性，并向
ICANN 提交一份为每个寄存生成的验证报告（可以通过经验证的电子邮件提交）。
7.2 如果托管代理发现有任何寄存不能通过验证程序，托管代理必须在发现后四十八小时内，以电子邮件、传真或电话的形式，向注册管理执行机构和 ICANN 通报此类不合规定的情况。注册管理执行机构在获悉此类验证失败的情况时，必须开始开发寄存的修改、更新、修正和其他修补程序，以使寄存能够通过验证程序，并将此类修补程序尽快提交给托管代理。托管代理必须验证所有此类经修正的寄存的准确性或完整性，并在验证成功后二十四小时内通知 ICANN。
8. 修正。在本“规定 2”受到任何修正或修改后十 (10) 个日历日内，托管代理和注册管理执行机构应修正托管协议的条款，使其符合本“规定 2”。如果本“规定 2”与托管协议之间有冲突，以本“规定 2”为准。
9. 保障。如果第三方对托管代理及其董事、高管、代理人、员工、成员和股东（以下统称 “托管代理受保障人”）提出了与托管协议相关或者与托管代理或任何“托管代理受保障人”履行协议相关的任何索赔、起诉、损害赔偿、诉讼、责任、义务、成本、费用、收费及其他任何费用（包括合理的律师费和成本），注册管理执行机构应确保托管代理及其 “托管代理受保障人”绝对永久性免于承担任何此类费用或责任（因托管代理及其董事、高管、代理人、员工、承包商、成员和股东的失实xx、疏忽或不当行为而引发的任何索赔除外）。如果第三方对注册管理执行机构和 ICANN 及其各自的董事、高管、代理人、员工、成员和股东（以下统称“受保障人”）提出了与托管代理及其董事、高管、代理人、员工和承包商的失实xx、疏忽或不当行为相关的任何索赔、起诉、损害赔偿、诉讼、责任、义务、成本、费用、收费及其他任何费用（包括合理的律师费和成本），托管代理应确保“受保障人”绝对永久性免于承担任何此类费用或责任。
规范 3
注册管理执行机构每月报告的格式和内容
针对每个 gTLD，注册管理执行机构应向 xxxxxxxx-xxxxxxx@xxxxx.xxx 提供两份包含以下内容的月度报告。将来 ICANN 可能会要求以其他方式递交报告。ICANN 将采用合理的商业措施对所报告的信息保密，直至报告相关月份结束后三个月。
1. 服务水平协议性能。将报告月份的 DNS、EPP 和 RDPS 服务性能与“规范 6”第 4 部分所述的 SLA 进行比较。应该使用 RFC 4180 中指定的逗号分隔值格式文件，将此报告以电子形式传送给 ICANN。应将文件命名为“gTLD_sla_yyyy-mm.csv”，其中“gTLD”是 gTLD 名称；如果是 IDN-TLD，应使用 A 标签；“yyyy-mm”是所报告的年份和月份。文件应包含以下字段：
字段号 | 字段名称 | 注释 |
01 | epp-service-dt-min | EPP 服务中断时间（以分钟表示）它应该是一个整数。 |
02 | epp-session-cmds-rtt-pct | 符合相关 SLR 的 EPP 会话命令 RTT 采样率。它应该是 一个实数：带两位小数的一位数或两位数，不含 % 号。 |
03 | epp-query-cmds-rtt-pct | 符合相关 SLR 的 EPP 查询命令 RTT 采样率。它应该是 一个实数：带两位小数的一位数或两位数，不含 % 号。 |
04 | epp-transform-cmds-rtt-pct | 符合相关 SLR 的 EPP 传输命令 RTT 采样率。它应该是 一个实数：带两位小数的一位数或两位数，不含 % 号。 |
05 | rdps-dt-min | RDPS 中断时间（以分钟表示）。它应该是一个整数。 |
06 | rdps-query-rtt-pct | 符合相关 SLR 的 RDPS 查询 RTT 采样率。它应该是一 个实数：带两位小数的一位数或两位数，不含 % 号。 |
07 | rdps-update-time-pct | 符合相关 SLR 的 RDPS 更新采样率。它应该是一个实 数：带两位小数的一位数或两位数，不含 % 号。 |
08 | dns-service-dt-min | DNS 服务中断时间（以分钟表示）它应该是一个整数。 |
09 | dns-tcp-resolution-rtt-pct | 符合相关 SLR 的 TCP DNS 查询 RTT 采样率。它应该是 一个实数：带两位小数的一位数或两位数，不含 % 号。 |
10 | dns-udp-resolution-rtt-pct | 符合相关 SLR 的 UDP DNS 查询 RTT 采样率。它应该是 一个实数：带两位小数的一位数或两位数，不含 % 号。 |
11 | dns-update-time-pct | 符合相关 SLR 的 DNS 更新采样率。它应该是一个实 数：带两位小数的一位数或两位数，不含 % 号。 |
12 | dns-ns-dt-min-<name1>-<ip1> | 名称服务器 IP 地址中断时间（以分钟表示）。它应该是一个整数。在此字段名称结构中，应该用其中一个名称服务器的名称替换 <name1>，用其中一个相应的 IP 地址替换 <ip1>。 |
13 | dns-ns-dt-min-<name1>-<ip2> | " " |
14 | dns-ns-dt-min-<name2>-<ip1> | " " |
… | … | " " |
第一行应包括与上表完全相同的字段名称，用作“标题行”，如 RFC 4180 第 2 部分中所述。应根据需要添加“dns-ns-dt-min…”类型的字段，以包括所有名称服务器的名称以及相应的 IP 地址。除了上述行，不应包括任何其他行。
2. 每个注册服务商的活动报告。应该使用 RFC 4180 中指定的逗号分隔值格式文件，将此报告以电子形式传送给 ICANN。应将文件命名为“gTLD_activity_yyyy-mm.csv”，其中“gTLD”是 gTLD名称；如果是 IDN-TLD，应使用 A 标签；“yyyy-mm”是所报告的年份和月份。针对每个注册服务商，文件应包含以下字段：
字段号 | 字段名称 | 注释 |
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-names | 准许的 AGP（追加宽限期）豁免请求所影响的名称总数 |
第一行应包括与上表完全相同的字段名称，用作“标题行”，如 RFC 4180 第 2 部分中所述。每份报告的最后一行应包括每列所有注册服务商的总数；本行第一个字段应该为“总数”，第二个字段应该留空。除了上述行，不应包括任何其他行。
规定 4
有关注册数据发布服务的规定
1. WHOIS 服务 在 ICANN 指定不同格式和协议之前，注册管理执行机构将依据 RFC 3912 同时通过端口 43 和网站 <whois.nic.(TLD)> 运营注册数据发布服务，为公众免费提供以下格式且至少包含以下内容的查询访问：ICANN 保留指定替代格式和协议的权利，包括互联网注册管理机构信息服务（IRIS – RFC 3981 和相关 RFC），一旦此类指定生效，注册管理执行机构将尽快实施此类替代规定。
1.1. 域名数据：
1.1.1. 查询格式：whois EXAMPLE.TLD
1.1.2. 响应格式：
Domain Name: EXAMPLE.TLD Whois Server: whois.example.tld Referral URL: xxxx://xxx.xxxxxxx.xxx Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z Expiration Date: 2010-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555
Status: DELETE PROHIBITED Status: RENEW PROHIBITED Status: TRANSFER PROHIBITED Status: UPDATE PROHIBITED
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT Registrant Organization: EXAMPLE ORGANIZATION Registrant Street1: 123 EXAMPLE STREET
Registrant City: ANYTOWN Registrant State/Province: AP Registrant Postal Code: A1A1A1 Registrant Country: EX
Registrant Phone: x0.000.000.0000 Registrant Phone Ext: 1234 Registrant Fax: x0.000.000.0000
Registrant Email: XXXXX@XXXXXXX.XXX Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION Admin Street1: 123 EXAMPLE STREET
Admin City: ANYTOWN Admin State/Province: AP Admin Postal Code: A1A1A1 Admin Country: EX
Admin Phone: x0.000.000.0000
Admin Phone Ext: 1234 Admin Fax: x0.000.000.0000
Admin Email: XXXXX@XXXXXXX.XXX Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC Tech Street1: 123 EXAMPLE STREET
Tech City: ANYTOWN Tech State/Province: AP Tech Postal Code: A1A1A1 Tech Country: EX
Tech Phone: +1.1235551234 Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Name Server: NS01.EXAMPLEREGISTRAR.TLD Name Server: NS02.EXAMPLEREGISTRAR.TLD
>>> Last update of whois database: 2009-05-29T20:15:00Z <<<
1.2. 注册服务商数据：
1.2.1. 查询格式：whois "registrar Example Registrar, Inc."
1.2.2. 响应格式：
Registrar Name: Example Registrar, Inc.
Address: 1234 Admiralty Way, Marina del Rey, CA 90292, USPhone Number: x0.000.000.0000
Fax Number: x0.000.000.0000
Whois Server: whois.example-registrar.tld Referral URL: www. example-registrar.tld Admin Contact: Xxx Registrar
Phone Number: x0.000.000.0000
Fax Number: x0.000.000.0000
Email: xxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx Admin Contact: Xxxx Registrar
Phone Number: x0.000.000.0000
Fax Number: x0.000.000.0000
Email: xxxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx Technical Contact: Xxxx Xxxx
Phone Number: x0.000.000.0000
Fax Number: x0.000.000.0000
Email: xxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
>>> Last update of whois database:2009-05-29T20:15:00Z <<<
1.3. 名称服务器数据：
1.3.1. 查询格式：whois "NS1.EXAMPLE.TLD" 或 whois "nameserver (IP 地址)"
1.3.2. 响应格式：
Server Name: NS1.EXAMPLE.TLD IP Address: 192.65.123.56
Registrar: Example Registrar, Inc.
Whois Server: whois.example-registrar.tld Referral URL: xxxx://xxx. example-registrar.tld
>>> Last update of whois database: 2009-05-29T20:15:00Z <<<
2. 根文件访问
2.1. 第三方访问
2.1.1 根文件访问协议。注册管理执行机构将与任何互联网用户签署协议，以允许这类用户访问互联网主机托管服务器或注册管理执行机构指定的服务器来下载根文件数据。此类协议的条款与条件应该依据由注册管理执行机构出于善意决定的商业合理的条款。
请求。
注册管理执行机构可以拒绝其合理认为会违反以下 2.1.4 条款规定的任何用户提出的访问
2.1.2. 用户信息。注册管理执行机构可能会要求每个用户向它提供足以识别用户身份及其指定服务器的信息。这类用户信息包括但不限于公司名称、联系人姓名、地址、电话号码、传真号码、电子邮件地址以及互联网主机名称和 IP 地址。
2.1.3. 访问授权。注册管理执行机构将授予用户非独占、不可转让的有限权限，使其可以访问注册管理执行机构的服务器，以及通过 FTP 或 HTTP 方式以每 24 小时不超过 1 次的频率将顶级域名根文件副本和任何关联的加密校验和文件传输到其服务器上。
2.1.4. 用户使用数据。注册管理执行机构将允许用户以合法的目的使用根文件；但必须符合以下条件：(a) 用户要采取所有合理的措施来防止未经授权访问、使用和公布数据；(b) 任何情况下，用户都不能利用数据 (x) 允许、促成或以其他任何方式支持通过电子邮件、电话或传真向用户现有客户之外的实体强行大批量发送商业广告或招揽生意的信息材料，或者 (y) 为采用电子手段自动向注册管理执行机构或任何 ICANN 认可的注册服务商的系统大批量发送查询或数据提供便利。
2.1.5. 使用期限。注册管理执行机构将允许每个用户访问根文件，其允许期不少于
三 (3) 个月。
2.1.6. 免费访问。注册管理执行机构将允许用户免费访问根文件。
2.2 ICANN 访问。
2.2.1. 一般访问。注册管理执行机构应持续地以 ICANN 可能不时合理指定的方式，向 ICANN 或其指定方提供访问 TLD 注册管理机构区域文件的批量访问。
2.2.2. 中央区域文件存储库。如果 ICANN 或其指定方建立了一个中央区域文件存储库，注册管理执行机构会应 ICANN 要求将所有区域文件数据提供给 ICANN，或提供给由 ICANN 指定的此类存储库的第三方运营商。一旦建立了此类中央区域文件存储库，ICANN 可以自行决定放弃遵守此规定 4 的条款 2.1。[注意：条款 2.2.2 旨在供群体讨论，此条款是之前群体关于减少恶意行为讨论的结果。根据此条款，ICANN 可以承担当前由注册管理执行机构执行的职责，即审查及监督相关负责方出于合法目的对区域文件数据的访问。]
规范 5
GTLD 注册机构二级保留名称明细表
[注意：本明细表的内容是后续社群讨论的主题]
除 ICANN 另行以书面形式明确授权外，注册运营商应保留以 TLD 中来自首次（即并非续签）注册的下列标签组成的名称：
1. Example。标签“EXAMPLE”应在第二级和注册运营商进行注册的 TLD 的其他所有级别保留。
2. 二字符标签。应在一开始就保留所有二字符标签。如果注册运营商与政府和国家/地区代码管理者达成协议，对二字符标签字符串的保留可以取消。注册运营商也可以在实施措施以避免与相应国家/地区代码混淆的前提下，提议取消这些保留。
3. 有标记的域名。如果标签的 ASCII 编码表示有效国际化域名，则连字号只能位于标签的第三位和第四位（例如“xn--ndk061n”）。
4. 用于注册机构运营的二级保留。应保留下列名称，用于与 TLD 注册机构的运营有关的方面。注册运营商可以使用它们，但自 TLD 注册机构成立后，注册机构运营商的指定资格结束，就应按 ICANN 的要求将它们转让：NIC、WWW 和 WHOIS。
5. 国家和地区名称。下面这些国际认可的列表中所包含的国家和地区名称，将在二级域名以及注册管理执行机构提供注册的 TLD 中的所有其他级别域名中对初次的注册予以保留：
5.1. ISO 3166-1 列表中包含的所有国家和地区名称的短写形式（英文）， 内容会不时更新；
5.2. 联合国地名专家小组撰写的《地名标准化技术参考手册》之第 3 部分“世界各国名称”；以及
5.3. 联合国地名标准化会议国家名称工作组准备的 6 种联合国官方语言版本的联合国成员国列表。
规定 6
注册管理机构互操作性、连续性和性能规定
1. 标准合规性
注册管理执行机构应实施并遵循与以下内容有关的现有 RFC 和今后由互联网工程任务组 (IETF) 发布的 RFC，包括所有后续标准、修改或补充：(i) DNS 和名称服务器运营，包括但不限于 RFC 1034、1035、1982、2181、2182、2671、3226、3596、3597、3901、4343 和 4472；以及 (ii) 遵循
RFC 3735、3915、5730、5731、5732、5733 和 5734，使用可扩展供应协议 (EPP) 供应和管理域名。
注册管理执行机构应实施域名系统安全扩展（简称“DNSSEC”）。在此期限内，注册管理执行机构应遵循 RFC 4033、4034、4035、4509 和 4310 及其后续规定，并遵循 RFC 4641 及其后续规定中描述的最佳做法。如果注册管理执行机构实施用于 DNS 安全扩展的“哈希鉴定否定存在”，它应遵循 RFC 5155 及其后续规定。注册管理执行机构应按照行业最佳做法，以安全方式从子域名接受公钥材料。注册管理机构还应在其网站上发布做法和政策文件（也称为 DNSSEC 政策声明或 DPS），说明密钥材料存储、其自身密钥的访问和使用，以及注册人的信任锚材料。
如果注册管理执行机构提供国际化域名（简称为“IDN”），它应该遵循 RFC 3490、3491 和 3492及其后续规定，以及位于 <xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx> 的 ICANN IDN 指导原则（它们可能随时会被修正、修改或取代）。如 ICANN IDN 指导原则中所述，注册管理执行机构应在 IDN 做法的 IANA 存储库中发布 IDN 表和 IDN 注册规则，并持续更新。
注册管理执行机构应该能够接受 IPv6 地址作为注册系统中的粘合记录，并在 DNS 中公布它们。注册管理执行机构应至少为根区域中列出的两个注册管理机构名称服务器（具有在 IANA 中注册的相应 IPv6 地址）提供公共 IPv6 传输。注册管理执行机构应遵循 BCP 91 中所述的“DNS IPv6 传输运营指南”。注册管理执行机构应为本协议规定 4 中定义的“注册数据发布服务”提供公共 IPv6 传输，例如 Whois (RFC 3912)、基于 Web 的 WHOIS、IRIS（RFC 3981 及相关 RFC）。注册执行管理机构在收到任何来自 TLD 委任注册服务商的希望通过 IPv6 运营共享注册系统 (SRS) 的第一个请求之后的六个月内，应为该注册服务商提供用于 SRS 的公共 IPv6 传输。
2. 注册管理机构服务和连续性
注册管理机构协议中的“注册管理机构服务”定义如下：(a) 对于完成下列任务至关重要的注册管理机构运营服务：从注册服务商处接收有关域名和名称服务器注册的数据；向注册服务商提供与 TLD区域服务器有关的状态信息；分发 TLD 区域文件；运行注册管理机构 DNS 服务器；按照本协议的要求分发与 TLD 中域名服务器注册有关的联系人信息和其他信息；(b) 根据规定 1 中规定的合意政策要求注册管理执行机构提供的其他产品或服务；(c) 作为注册管理执行机构，提供只能由注册管理执行机构提供的任何其他产品或服务；(d) 在以上 (a)、(b) 或 (c) 条范围内对任何注册管理机构服务的材料变更。
注册管理执行机构应使用网络和分布于不同地域的冗余服务器（包括网络级冗余、终端节点级冗余和实施负载xx方案）进行运营，以确保在发生技术故障（广泛或局部）、企业破产或超出注册管理执行机构控制能力的非常情况时仍然能够持续运营。
如果发生超出注册管理执行机构控制能力的非常事件，注册管理执行机构应通过合理的商业措施在此类事件结束后 24 小时内恢复注册管理机构的关键职能，并在此类事件结束后最多 48 小时内恢复全部系统功能（具体取决于有关的关键职能类型）。因此类事件而发生的宕机不属于缺乏服务可用性的情况。
注册管理执行机构应准备一个包括指定注册管理机构服务连续性提供商在内的应急计划，并必须向 ICANN 通报指定的提供商。
如果发生超出注册管理执行机构控制能力的非常事件，并且无法联系到注册管理执行机构，则注册管理执行机构同意 ICANN 联系指定的注册管理机构服务连续性提供商。
注册管理执行机构每年至少应执行一次注册管理机构服务连续性测试。
对于以下域名：不是由注册人注册的；注册人未提供要在 DNS 区域文件中列出的有效记录（如 NS记录）；域名状态不允许在 DNS 中公布这些域名，则禁止注册管理机构使用 RFC 4592 中所述的 DNS 通配符资源记录，或用于合成 DNS 资源记录和在 DNS 中使用重定向的何其他方法或技术。当查询此类域名时，权威性名称服务器必须返回“名称错误”响应（也称为 NXDOMAIN），如 RFC 1035 和相关 RFC 中所述的 RCODE 3。此规定适用于 DNS 树中所有级别的所有 DNS 区域文件，注册管理执行机构（或参与提供注册管理机构服务的附属机构）将为这些文件维护数据、安排此类维护或通过此类维护获取收入。
注册管理执行机构应在其网站上提供准确详细的联系信息，包括有效的电子邮件地址、邮寄地址以及处理与 TLD 中恶意行为有关的查询的主要联系人，并应向 ICANN 提供有关此类联系信息任何变更的提示通知。
3. 支持的初始和续签注册期
可以一 (1) 年为单位在注册管理机构进行注册名称的初始注册，最长可注册十 (10) 年。
可以一 (1) 年为单位进行注册名称的续签注册，最长可注册十 (10) 年。
4. 性能规定
参数 | SLR（按月衡量） | |
DNS | DNS 服务可用性。 | 0 分钟中断 = 100% 可用性 |
DNS 名称服务器可用性 | ≤ 43 分钟中断 (≈ 99.9%) | |
TCP DNS 解析 RTT | ≤ 1500 毫秒（对于至少 99% 的查询） | |
UDP DNS 解析 RTT | ≤ 400 毫秒（对于至少 99% 的查询） | |
DNS 更新时间 | ≤ 15 分钟（对于至少 99% 的更新） | |
RDPS | RDPS 可用性 | ≤ 43 分钟中断 (≈ 99.9%) |
RDPS 查询 RTT | ≤ 1500 毫秒（对于至少 99% 的查询） | |
RDPS 更新时间 | ≤ 15 分钟（对于至少 99% 的更新） | |
EPP | EPP 服务可用性 | ≤ 43 分钟中断 (≈ 99.9%) |
EPP 会话命令 RTT | ≤ 3000 毫秒（对于至少 99% 的命令） | |
EPP 查询命令 RTT | ≤ 1500 毫秒（对于至少 99% 的命令） | |
EPP 传输命令 RTT | ≤ 3000 毫秒（对于至少 99% 的命令） |
SLR。服务级别要求是服务级别协议 (SLA) 中对正在测量的特定参数所要求的服务级别。
RTT。往返时间或 RTT 指从发送数据包序列中第一个数据包的第一个位数（用于提出请求）开始，到收到数据包序列中最后一个数据包的最后一个位数（用于接收响应）为止的这段时间。如果客户端未收到表明收到响应的整个数据包序列，则该时间将被视为未定义。
IP 地址。指的是 IPv4 地址或 IPv6 地址，二者没有任何区别。要说有什么区别，也只是名称上的不同。
DNS。指 RFC 1034、1035 和相关 RFC 中指定的域名系统。
DNS 服务可用性。指一组列为特定域名（例如，TLD）的权威性名称服务器在答复互联网用户 DNS 查询方面的能力。如果服务在某个时间点被视为可用，则在注册到 DNS 的名称服务器中，至少有两台服务器在对其已注册公共 DNS 的“IP 地址”通过（UDP 和 TCP）传输进行的“DNS测试”中具有定义的结果。如果在特定时间内，有 51% 或更多的 DNS 测试探测器认为通过任何传输（UDP 或 TCP）该服务都不可用，则 DNS 服务将被视为不可用。
DNS 名称服务器可用性。指某个特定服务器（被列为域名的权威性名称服务器）已注册公共 DNS的“IP 地址”在答复互联网用户 DNS 查询方面的能力。被监控的域名的所有名称服务器在公共 DNS 中注册的“IP 地址”都应单独进行测试。如果在给定时间内，有 51% 或更多的 DNS 测试探测器在对名称服务器“IP 地址”通过任何传输（UDP 或 TCP）进行的“DNS 测试”中都得到未定义的结果，则该名称服务器“IP 地址”将被视为不可用。
UDP DNS 解析 RTT。指由两个数据包序列（UDP DNS 查询和相应的 UDP DNS 响应）的 RTT。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
TCP DNS 解析 RTT。指从 TCP 连接开始到结束（包括只收到一个 DNS 查询的 DNS 响应）这一期间的数据包序列的 RTT。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。 |
DNS 解析 RTT。指“UDP DNS 解析 RTT”或“TCP DNS 解析 RTT”。 DNS 更新时间。指从收到某个域名的转变命令的 EPP 确认开始，到父域名的所有名称服务器用与所作更改一致的数据答复“DNS 查询”时为止衡量的这段时间。它只适用于对 DNS 信息所作的 |
更改。 DNS 测试。指发送到特定“IP 地址”的一个非递归 DNS 查询（通过 UDP 或 TCP）。如果所查询的 DNS 区域中提供 DNSSEC，则要确定查询已被答复，签名必须肯定通过验证（根据父区域中发布的相应 DS 记录，如果父区域未签名，则根据静态配置的信任锚）。查询应针对现有域名。对查询的答复必须包含注册系统中的相应信息，否则查询将被视为未答复。如果对查询的答复包含 TC 位组，查询将被视为未答复。“DNS 解析 RTT”高于相应 SLR 5 倍的查询将被视为未答复。DNS测试的结果可能为：与“DNS 解析 RTT”对应的数字（以毫秒为单位）或未定义/未答复。 |
测量 DNS 参数。对于被监控域名的名称服务器的每个已注册公共 DNS 的“IP 地址”，每个 DNS 探测器每分钟都应该对其执行 UDP 和 TCP“DNS 测试”。如果“DNS 测试”未得到答复，该探测器将认为所测试的 IP 对于相应传输（UDP 或 TC）不可用，直至执行新的测试。在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 20，否则测量将被弃置并视为无结果； 在这种情况下不会根据 SLR 标记故障。 |
DNS 探测器放置。用于测量 DNS 参数的探测器应尽可能放在跨不同地理区域、拥有大多数用户的网络上的 DNS 解析器附近；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。 RDPS。RDPS（注册数据公布服务）指本协议“规定 4”中定义的 WHOIS 和基于 Web 的 WHOIS |
服务的集合。 RDPS 可用性。指 TLD 的所有 RDPS 服务通过提供注册系统中的相应数据来响应互联网用户查询的能力。如果 RDPS 在某个时间点上被视为可用，则每项 RDPS 服务的一个 IPv4 地址和一个 IPv6 地址在“RDPS 测试”中都必须具有定义的结果。如果有 51% 或更多的 RDPS 测试探测器认为在特定时间内有任何 RDPS 服务不可用，则 RDPS 将被视为不可用。 |
WHOIS 查询 RTT。指从 TCP 连接开始到结束（包括收到 WHOIS 响应）这一期间的数据包序列的 RTT。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。 |
基于 Web 的 WHOIS 查询 RTT。指从 TCP 连接开始到结束（包括只收到一个 HTTP 请求的HTTP 响应）这一期间的数据包序列的 RTT。如果注册管理执行机构执行多步骤流程来获取信息，则只测量最后一步。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。 RDPS 查询 RTT。指“WHOIS 查询 RTT”和“基于 Web 的 WHOIS 查询 RTT”的集合。 |
RDPS 更新时间。指从收到某个域名上传输命令的 EPP 确认开始，到所有 RDPS 服务的所有服务器的所有“IP 地址”都反映出所作更改时为止的这一段时间。 |
RDPS 测试。指发送到某个 RDPS 服务的某个服务器的某个特定“IP 地址”的一条查询。查询应针对注册系统中的现有对象，且响应必须包含相应信息，否则查询将被视为未答复。RTT 高于相应 |
SLR 5 倍的查询将被视为未答复。RDPS 测试的结果可能为：与 RTT 对应的数字（以毫秒为单位）或未定义/未答复。
测量 RDPS 参数。对于被监控的 TLD 的每项 RDPS 服务，每个 RDPS 探测器每分钟都应该从服务器的所有已注册公共 DNS 的“IP 地址”中随机选择一个 Pv4 地址和一个 IPv6 地址并对其执行 “RDPS 测试”。如果“RDPS 测试”未得到答复，该探测器将认为 IPv4 或 IPv6（视具体情况而定）上的相应 RDPS 服务不可用，直至执行新的测试。在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 10，否则测量将被弃置并视为无结果；在这种情况下不会根据 SLR标记故障。
RDPS 探测器放置。用于测量 RDPS 参数的探测器应放在跨不同地理区域、拥有大多数用户的网络中；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。
EPP。指 RFC 5730 和相关 RFC 中指定的可扩展供应协议。
EPP 服务可用性。指 TLD EPP 服务器作为组，响应注册管理机构委任的注册服务商（已拥有服务器的凭据）所发出的命令的能力。响应应包括注册系统中的相应数据。“EPP 命令 RTT”高于相应 SLR 5 倍的 EPP 命令将被视为未答复。如果 EPP 服务在测量期间内被视为可用，则该组 EPP 服务器必须至少有一个 IPv4 地址和一个 IPv6 地址（如果通过 IPv6 提供 EPP）在“EPP 测试”中具有定义的结果。如果在给定时间内有 51% 或更多的 EPP 测试探测器认为 EPP 服务不可用，则 EPP 服务将被视为不可用。
EPP 会话命令 RTT。指以下数据包序列的 RTT：此数据包序列包括发送会话命令，和只接收一个 EPP 会话命令的 EPP 响应。对于登录命令，将包括用于启动 TCP 会话的数据包。对于注销命令，将包括用于关闭 TCP 会话的数据包。EPP 会话命令是指 EPP RFC 5730 中第 2.9.3 部分所述的命令。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
EPP 查询命令 RTT。指以下数据包序列的 RTT：此数据包序列包括发送查询命令，以及只接收一个 EPP 查询命令的 EPP 响应。它不包括启动和关闭 EPP 或 TCP 会话所需的数据包。EPP 查询命令是指 EPP RFC 5730 中第 2.9.2 部分所述的命令。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
EPP 传输命令 RTT。指以下数据包序列的 RTT：此数据包序列包括发送传输命令，以及只接收一个 EPP 传输命令的 EPP 响应。它不包括启动和关闭 EPP 或 TCP 会话所需的数据包。EPP 传输命令是指 EPP RFC 5730 中第 2.9.3 部分所述的命令。如果 RTT 是相应 SLR 的 5 倍或更多，则 RTT 将被视为未定义。
EPP 命令 RTT。指“EPP 会话命令 RTT”、“EPP 查询命令 RTT”或“EPP 传输命令 RTT”。
EPP 测试。指发送到某个 EPP 服务器的特定“IP 地址”的一条 EPP 命令。查询和传输命令（“创建”除外）应针对注册系统中的现有对象。响应应包括注册系统中的相应数据。EPP 测试的结果可能为：与“EPP 命令 RTT”对应的数字（以毫秒为单位）或未定义/未答复。
测量 EPP 参数。每个 EPP 探测器应该每 5 分钟从所监控的 TLD 的 EPP 服务器的所有“IP 地址”中随机选择一个 IPv4 地址和一个 IPv6 地址，并对每个地址执行“EPP 测试”（只有在提供 IPv6 传输时才会测试 IPv6）；探测器每次应该在 3 种不同类型的命令之间以及每种测试类型内部的命令之间随机变换。如果“EPP 测试”未得到答复，该探测器将认为 EPP 服务不可用，直至执行新的测试。
在任意给定的测量期间内，判定测量有效的最小活动测试探测器数量为 10，否则测量将被弃置并视为无结果；在这种情况下不会根据 SLR 标记故障。
EPP 探测器放置。用于测量 EPP 参数的探测器应放在注册服务商的互联网（跨不同地理区域）接入点内部或附近；请注意，不要将探测器部署在高传播延迟链接（如卫星链接）后面。
探测器列表。可以在 <reference> 中查看当前的 DNS、RDPS 和 EPP 探测器列表。注册管理执行机构必须采取必要措施，以确保所列出的探测器在测试时不被网络设备所阻止。ICANN 可以不时地更新此列表，但在更改前至少要提前 60 天向注册管理执行机构发送通知。在此期间，注册管理执行机构可以查看新探测器的读数（如有），但不会将这些测量值计入 SLA 考量。
维护窗口。当每项服务的统计流量较低时，建议注册管理执行机构为不同服务提供维护窗口。但请注意，不会提供计划宕机或任何类似中断。出于维护目的或由于系统故障导致的中断将被直接视为中断并计入 SLA 考量。
规定 7
对于权利保护机制的最低要求
1. 权利保护机制的制定。注册管理执行机构应实施并遵守 ICANN 不时规定的任何权利保护机制 (RPM)。除了这些 RPM 之外，注册管理执行机构可以制定并实施其他旨在防止或避免违反或滥用另一方合法权利的域名注册的 RPM。注册管理执行机构应将 ICANN 规定的和独立制定的所有 RPM 包括在与经授权可在 TLD 中注册名称的 ICANN 认可注册商达成的注册机构-注册商协议文件中。
2. 争议解决机制。注册管理执行机构将采用和实施争议解决机制，第三方可按此类机制对其他团体的域名注册提出质疑。此类争议解决机制应包括参与及遵守由 ICANN 批准并实施的 ICANN 商标授权后争议解决程序 (PDDRP)（发布在 [采纳最终程序后插入的 url]，不时会进行修订），包括实施由任何授权后争议解决服务机构所做的任何决议或决定。
《新 GTLD 协议规定草案》（2009 年 10 月）
公众意见征询稿
规定 8
持续运营措施
1. “持续运营措施”应 (a) 保障有充分的资金来源，确保在本《协议》生效之日后五年的协议终止之际或者提前终止之时，注册管理机构依照 [《申请人指南》终稿时将在此处插入相关的 url] 上公布的《申请人指南》第 [ ] 部分的规定而提供的与 TLD 相关的基本的注册数据库功能（《申请人指南》届时将通过这个 url 以引用的方式并入本“规定 8”），可以继续运营一个 3（叁）年期时段；“持续运营措施”(b) 应采用 (i) 不可撤销的备用信用证 (irrevocable standby letter of credit) 或 (ii) 不可撤销的现金托管存款 (irrevocable cash escrow deposit) 形式来履行，且无论采用何种形式，均需要符合 [《申请人指南》终稿时将在此处插入相关的 url] 上公布的《申请人指南》第 [ ] 部分所列要求（《申请人指南》届时将通过这个 url 以引用的方式并入本“规定 8”）。注册管理机构要尽全力采取所有必要或合适的举措，使“持续运营措施”在《协议》生效之日后 5（伍）年内保持有效，并且要保持 ICANN 为其第三方受益人。注册管理机构要向 ICANN 提供与“持续运营措施”相关的所有最终文件的副本，并在合理的范围内，向 ICANN 及时告知与“持续运营措施”相关的材料编撰情况。注册管理机构同意在未获得 ICANN 事先书面同意的情况下
（不应无理拒绝同意），不对“持续运营措施”及与之相关的其他文件做任何修改，并且认同在未获得 ICANN 事先书面同意的情况下（不应无理拒绝同意），不放弃履行“持续运营措施”及与之相关的其他文件中规定的职责。
2. 如果注册管理机构已尽全力履行上述规定义务，但“持续运营措施”过期，或者由于某种原因，“持续运营措施”在《协议》生效之日后未满五年即由“持续运营措施”的另一方部分或全部终止，在此情况下，注册管理机构应及时 (i) 将过期情况或终止情况及其原因通知 ICANN，并要 (ii) 安排替代措施，保障有充分的资金来源，能够确保在本《协议》生效之日后五年的协议终止之际或者提前终止之时，注册管理机构提供的与 TLD 相关的服务可以继续运营 3（叁）年。任何此类替代措施对 ICANN 的利益应不低于原有“持续运营措施”的水平，或者其形式和内容是 ICANN 可以合理接受的。
3. 无论本“规定 8”有何相反规定，注册管理机构都可以随时使用替代措施来代替原有的 “持续运营措施”，但替代措施需符合以下条件：(i) 保障有充分的资金来源，能够确保在本《协议》生效之日后五年的协议终止之际或者提前终止之时，注册管理机构提供的与 TLD 相关的服务可以继续运营 3（叁）年；(ii) 替代措施包含的条款对 ICANN 的利益应不低于原有“持续运营措施”的水平，或者其形式和内容是 ICANN 可以合理接受的。如果注册管理机构在运营中根据上述第 2 部分或第 3 部分，使用任何替代措施代替了原有的 “持续运营措施”，则本“规定 8”中的条款将不再适用于“持续运营措施”，但将适用于之后的替代措施。