.NET 注册管理机构协议
(2023 年 7 月 1 日)
image_0a.jpg

注册协议

本注册协议(以下简称 “协议”)自2023年7月1日起由加利福尼亚非营利性公益机构互联网名称与数字地址分配机构(“ICANN”)与特拉华州的一家公司威瑞信公司(“VeriSign”)签订。本协议对ICANN和VeriSign之间于2017年7月1日签订的经ICANN和VeriSign之间签订的经2020年4月27日.NET注册管理机构协议第一修正案修正(统称为 “先前协议”)的全部修订案,并全部重申了该协议。

第一篇简介

第 1.1 节生效日期。就本协议而言,“生效日期” 应为 2023 年 7 月 1 日。

第 1.2 节顶级域。本协议适用的顶级域名是.net(“TLD”)。

第 1.3 节指定为注册管理运营商。自本协议生效之日起和整个期限(定义见本协议第 4.1 节),除非根据本协议第 6 条提前终止,否则 ICANN 将继续指定 VeriSign, Inc. 为该顶级域的唯一注册管理运营商(“注册管理运行机构”)。

第 II 条的陈述和保证

第 2.1 节注册管理运行机构的陈述和保证。

(a) 组织;正当授权和执行。注册管理运行机构是一家根据特拉华州法律正式组建、有效存在且信誉良好的公司,注册管理运行机构拥有签订本协议的所有必要权力和权限。注册管理运行机构加入本协议所需的所有公司批准和行动均已获得,本协议已由注册管理运行机构正式有效执行和交付。

(b) 谈判过程中发表的声明。双方在谈判本协议时以书面形式作出的事实陈述在所有重要方面都是真实和正确的。违反或违反本小节的行为不得作为终止、撤销或其他公平救济的依据,而只能引起损害赔偿索赔。

第 2.2 节 ICANN 的陈述和保证。

(a) 组织;正当授权和执行。ICANN 是一家非营利性公益机构,组织完善,存在有效,信誉良好



加州法律。ICANN 拥有签订本协议所需的所有公司权力和权力。ICANN 加入本协议所需的所有企业批准和行动均已获得,本协议已由 ICANN 正式有效执行和交付。

第三条盟约

第 3.1 节《注册管理运行机构契约》。注册管理运行机构与 ICANN 的承诺和协议如下:

(a) 维护安全与稳定。

(i) ICANN 临时规范或政策。如果 ICANN 董事会以至少三分之二的成员投票通过,注册管理运行机构应临时遵守和实施由 ICANN 董事会制定的所有规范或政策,前提是 ICANN 董事会合理地确定有必要立即临时制定有关该主题的规范或政策,以维护注册管理机构服务的稳定性或安全性(定义见第 3.1 (d) (iv) (G) 节)DNS(“临时规范或政策”)。为实现这些目标,应尽可能严格地制定此类拟议规格或政策。在根据本条款制定任何规范或政策时,ICANN 董事会应说明临时采用该规范或政策的时限,并应立即实施 ICANN 章程中规定的共识政策制定流程。ICANN 还应发布一份咨询声明,详细解释其采用临时规范或政策的理由,以及董事会为何认为该规范或政策应获得互联网利益相关方的共识支持。如果该规范或政策的通过期限超过 90 天,ICANN 董事会应每 90 天重申一次临时采用,总期限不超过一年,以保持该政策的有效性,直至其成为下文第 3.1 (b) 节所述的共识性政策。如果在这样的一年期内,临时政策或规范未成为符合下文第 3.1 (b) 节中规定的标准的共识政策,则无需再要求注册管理运行机构遵守或实施此类临时政策或规范。

(b) 共识政策。

(i) 在本协议期限内的任何时候,在遵守本协议条款的前提下,注册管理运行机构将完全遵守和实施所有共识性政策,这些政策自生效之日起,将来可能根据 ICANN 章程和下文所述制定和通过,载于 https://www.icann.org/consensus-policies。

(ii) “共识政策” 是指根据 ICANN 章程和正当程序中规定的程序制定的规格或政策,以及
(2) 涵盖下文第 3.1 (b) (iv) 节中列出的主题。ICANN 章程中规定的共识政策制定流程和程序可能是
2


根据 ICANN 章程不时修订以及通过此类修订流程通过的、涵盖下文第 3.1 (b) (iv) 条所列主题的任何共识政策均应被视为本协议的共识政策。

(iii) 出于本协议的所有目的,https://www.icann.org/consensus-policies 中确定的政策应与 “共识政策” 以相同的方式对待,具有相同的效力。

(iv) 共识政策及其制定程序的设计应尽可能使互联网利益相关方(包括 gTLD 的运营商)达成共识。共识政策应涉及以下一项或多项:(1) 为促进互联网或 DNS 的互操作性、安全性和/或稳定性而合理需要统一或协调解决的问题;(2) 提供注册服务所需的功能和性能规范(定义见下文第 3.1 (d) (iii) 节);(3) TLD 注册数据库的安全性和稳定性;(4) 实施与注册管理机构相关的共识政策所合理必要的注册管理政策业务或注册商;或 (5) 争议的解决关于域名的注册(而不是使用此类域名)。前一句中提及的此类问题应包括但不限于:

(A) 顶级域中注册名称的分配原则(例如,先到先得、及时续订、到期后的保留期);

(B) 禁止注册管理机构或注册服务机构仓储或投机域名;

(C) 在顶级域中保留最初可能无法注册或由于以下合理原因而无法续订的注册名称:(a) 避免混淆或误导用户,(b) 知识产权,或 (c) 域名系统或互联网的技术管理(例如,对注册后的域名进行保留);

(D) 维护和访问有关域名注册的准确和最新的信息;

(E) 避免因注册管理运营商或注册商暂停或终止业务而导致域名注册中断的程序,包括在受此类暂停或终止影响的顶级域中为注册域名提供服务的责任分配程序;以及

(F) 解决有关特定当事方是否可以注册或维持特定域名的注册的争议。

(v) 除了对共识政策的其他限制外,它们不得:

(A) 规定或限制注册局服务的价格;

3


(B) 修改用于考虑拟议注册管理服务的标准,包括安全性和稳定性的定义(见下文)以及 ICANN 适用的标准;

(C) 修改本协议续订或终止的条款或条件;

(D) 根据第 3.2 (a)、(b) 和 (c) 条修改 ICANN 对注册管理运行机构的义务;

(E) 修改共识政策或临时规范或政策的限制;

(F) 修改注册局服务的定义;

(G) 修改下文第 7.2 和 7.3 节的条款;以及

(H) 更改根据本协议第 3.1 (d) 节实施的服务(除非基于安全性和稳定性有令人信服的正当理由)。

(vi) 考虑到所涉及的任何紧迫性,在发出共识政策或临时规范或政策的通知后,应给予注册管理运行机构一段合理的时间来遵守此类政策或规范。

如果注册局服务(定义见下文第 3.1 (d) (iii) 节)与根据本第 3.1 (b) 节制定的共识政策或根据上文第 3.1 (a) (i) 节制定的任何临时规范或政策发生冲突,则无论本协议中包含任何其他条款,均应以共识政策或临时规范或政策为准。

(c) 注册表数据的处理。

(i) 数据托管。注册管理运行机构应自费为注册管理运行机构汇编的注册表数据制定数据托管或镜像站点政策。本协议中使用的注册表数据是指以下内容:(1) 所有注册商赞助的域名数据,包括域名、每个域名服务器的服务器名称、注册商 ID、更新日期、创建日期、到期日期、状态信息以及 DNSSEC 委托签名者 (“DS”) 数据;(2) 由所有注册服务商赞助的域名服务器数据,包括服务器名称、每个 IP 地址、注册商 ID 更新日期、创建日期、到期日期和状态信息;(3) 赞助注册域名和域名服务器的注册服务商的数据,包括注册商 ID、注册商地址、注册商电话号码、注册商电子邮件地址、Whois 服务器(在附录 5A 中定义的 WHOIS 服务终止日期之后可以省略此数据元素)、推荐 URL、更新日期以及所有注册商管理、账单和技术联系人的姓名、电话号码和电子邮件地址;以及,(4) 注册管理运行机构在域名注册过程中或之后从注册服务商那里收集的域名注册人数据。这个
4


托管代理人或镜像站点管理人及其义务应由 ICANN 和注册管理运行机构根据商业上合理的标准共同商定,这些标准在技术和实践上都足以让继任注册管理运行机构接管 TLD 的管理。注册管理运行机构应遵守附录 1(数据托管规范)中规定的注册管理机构数据托管规范,各方将基本上以附录 2(托管协议(模板格式))的形式遵守已执行的托管协议。

(ii) 个人数据。注册管理运行机构应将注册服务机构向注册管理机构提交的个人数据(定义见下文)的目的(如果有)、此类个人数据的预期接收者(或接收者的类别)以及访问和更正此类个人数据的机制通知注册服务商。注册管理机构应采取合理措施保护个人数据免遭丢失、滥用、未经授权的披露、更改或破坏。注册管理运行机构不得以与向注册服务机构提供的通知不一致的方式使用或授权使用个人数据。“个人数据” 是指有关任何已识别或可识别自然人的所有数据。

(iii) 批量区域文件访问。注册管理运行机构将根据附录 3(区域文件访问权限)的条款,向第三方和 ICANN 提供区域文件的批量访问权限。

(iv) 月度报告。在每个日历月结束后的二十 (20) 个日历日内,注册管理运行机构应按照附录 4(注册管理运行机构月度报告的格式和内容)中规定的格式准备并向 ICANN 提交提供此类数据的报告。

(v) 注册数据目录服务。注册管理运行机构应提供附录 5A(注册数据发布服务规范)和附录 5B(注册数据访问协议服务规范)中规定的与所运营的顶级域名类型(例如 “详尽” 或 “精简” 注册管理机构模型)相关的注册数据。自生效之日起,TLD 是一种 “精简” 注册管理模式。

(vi) [保留的]

(vii) 公共利益承诺。注册管理运行机构应遵守附录 11(公共利益承诺)中规定的公共利益承诺。

(d) 登记处业务。

(i) 注册限制。注册管理运行机构应保留但不得注册出现在本文附录 6 所附的保留 TLD 字符串清单上的任何 TLD 字符串。
    
5


(ii) 功能和性能规格。TLD 运行的功能和性能规格应符合本协议附录 7、附录 5B 第 3 节和附录 5B 第 4.5 节的规定,并应涉及但不限于 DNS 服务、共享注册系统的运营、RDDS 和域名服务器操作。注册管理运行机构应保留足够的技术和运营记录,以证明遵守此类规格至少一年。

(iii) 注册服务。就本协议而言,注册服务定义如下:(a) 两者兼而有之的服务:(i) 注册管理机构的运作,对以下任务至关重要:接收注册商提供的有关域名和域名服务器注册的数据;向注册商提供与顶级域区域服务器相关的状态信息;传播顶级域区域文件;管理区域服务器的运营;以及传播与域名服务器有关的联系信息和其他信息根据本协议的要求在 TLD 中注册;以及 (ii) 注册管理运行机构自生效之日起为.net 注册管理机构提供的产品,包括附录 9 中规定的内容(视情况而定);(b) 注册管理运行机构因制定共识政策(定义见上文第 3.1 (b) 节)而需要提供的其他产品或服务;(c) 由于注册管理运行机构被指定为注册管理运行机构,只有注册管理运行机构才能提供的任何其他产品或服务;以及 (d) 在上述 (a)、(b) 或 (c) 范围内对任何注册服务进行重大更改。

(iv) 拟议注册服务审议流程。在注册管理运行机构向ICANN发出书面通知后,注册管理运行机构可以在前一段的范围内对注册管理机构服务进行更改:

(A) ICANN 应在 15 个日历日内做出 “初步决定” 注册管理服务是否需要ICANN进一步考虑,因为它合理地确定此类注册管理服务:(i) 可能引发重大的安全性或稳定性问题,或 (ii) 可能引发重大竞争问题。

(B) 注册管理运行机构在通知ICANN时必须提供足够的信息,说明其可能会实施此类拟议的注册管理服务,以使ICANN能够做出明智的 “初步决定”。ICANN 应将注册管理运行机构提供并标记为 “机密” 的信息视为机密信息。注册管理运行机构不会指定描述拟议注册局服务的目的以及对 DNS 用户的影响所必需的 “机密” 信息。

(C) ICANN 可在初步裁定期内(向受保密协议约束的实体或个人)就注册管理局的竞争、安全或稳定性影响寻求专家建议,以作出 “初步决定”。在 ICANN 决定向任何此类专家披露机密信息的范围内,它将向注册管理运行机构通知专家的身份及其打算传达的信息。

(D) 如果 ICANN 在 15 个日历日的 “初步裁定” 期内确定拟议的注册管理机构服务未提高
6


重大安全性或稳定性(定义见下文)或竞争问题,注册管理运行机构可根据此类决定自由部署。

(E) 如果 ICANN 在 15 个日历日的 “初步裁定” 期内合理地确定注册管理局可能提出重大竞争问题,ICANN 应在做出决定后的五个工作日内或在这 15 天期限到期后的两个工作日内(以较早者为准)将问题提交给相应的政府竞争主管机构,并通知注册管理运行机构。任何此类推荐信函应在发送之日在 ICANN 的网站上发布。此类移交后,ICANN 将不再对与注册管理机构服务相关的任何竞争问题承担进一步的责任,注册管理运行机构也不会对 ICANN 承担进一步的义务。如果出现此类转介,注册管理运行机构要等到移交后的45个日历日后才会部署注册管理服务,除非事先得到相关政府竞争主管机构的批准。

(F) 如果 ICANN 在 15 个日历日的 “初步裁定” 期内合理地确定拟议的注册管理服务可能引发重大的稳定性或安全问题(定义见下文),ICANN 将在做出决定后的五个工作日内,或在这个 15 天期限到期后的两个工作日内(以较早者为准)将提案转交常设专家小组(定义见下文),同时征求公众对该提案的意见。常设小组应在推荐后的 45 个日历日内就拟议的注册管理服务对安全性或稳定性的影响编写书面报告(定义见下文),该报告(以及任何公众意见摘要)应转交给 ICANN 理事会。该报告应提出常设小组的意见,包括但不限于详细陈述该小组得出结论时所依据的分析、理由和信息,以及对 ICANN 工作人员转介中包含的任何具体问题的回应。ICANN 转介给常设专家组后,注册管理运行机构可以提交有关注册管理机构服务安全性或稳定性可能产生的影响的其他信息或分析。

(G) 在对拟议的注册管理服务进行评估后,常设小组将报告拟议注册服务对安全性或稳定性的可能性和重要性,包括拟议的注册服务是否构成对安全性或稳定性产生重大不利影响的合理风险,定义如下:

安全:就本协议而言,拟议的注册局服务对安全的影响是指 (1) 未经授权披露、更改、插入或销毁注册数据,或 (2) 按照所有适用标准运行的系统未经授权访问或披露互联网上的信息或资源。

稳定性:就本协议而言,对稳定性的影响意味着拟议的注册管理服务 (1) 不符合适用的相关标准,这些标准具有权威性,并由公认的机构发布
7


权威标准机构,例如由 IETF 赞助的相关标准轨道或最佳现行实践 RFC,或 (2) 根据权威的适用相关标准运行,如相关的标准跟踪或最佳现行实践 RFC,依据注册管理运行机构的授权信息,按照权威的适用相关标准运行,对互联网服务器或终端系统响应的吞吐量、响应时间、一致性或连贯性产生不利影响,或配置服务。

(H) 收到常设小组的报告后,ICANN 董事会将在 30 个日历日内做出决定,该报告将予以公布(在与注册管理运行机构磋商后进行适当的保密修订)并征询公众意见。如果 ICANN 董事会合理确定拟议的注册管理机构服务存在对稳定性或安全性产生重大不利影响的合理风险,则注册管理运行机构将不提供拟议的注册管理机构服务。常设小组报告的未经编辑的版本应在报告发布后提供给注册管理运行机构。注册管理运行机构可以回应常设小组的报告,或以其他方式向ICANN董事会提交有关注册管理机构服务安全性或稳定性可能产生的影响的其他信息或分析。

(I) 常设小组应由总共20人组成,他们是设计、管理和实施互联网基础设施和域名系统中使用的复杂系统和标准协议的专家(“常设小组”)。常设小组的成员将由其主席选出。常设小组主席将由一个同意 ICANN 和当时负责通用顶级域名注册管理机构政策的支持组织的注册管理机构选区同意的人担任。常设小组的所有成员和主席应签署一项协议,要求他们根据安全与稳定的定义中立地考虑小组面前的问题。对于移交给常设小组的每个事项,主席应从常设小组中选出不超过五名成员来评估所涉事项,其中任何一个事项都不应存在竞争、财务或法律利益冲突,同时应适当考虑移交时提出的特定技术问题。

(e) 费用和付款。根据本协议第 7.2 节,注册管理运行机构应按季度向 ICANN 支付注册管理机构级别的费用。

(f) 交通数据。本协议中的任何内容均不妨碍注册管理运行机构出于以下目的对域名或不存在的域名进行商业使用或收集流量数据:但不限于确定互联网的可用性及安全性和稳定性、查明具体故障点、描述攻击和错误配置、识别受感染的网络和主机,以及促进域名的销售;但是,这种使用不会泄露域名注册人、最终用户信息或其他第 3.1 (c) (ii) 节中定义的个人数据,用于本协议未另行授权的任何目的。在这方面,如果 TLD 注册管理机构是 “详尽” 注册管理机构模型,则注册管理运行机构可以访问和使用的流量数据应仅限于可访问的数据
8


改为在 “精简” 登记模式下运作的登记处。引入新的注册表服务的过程不适用于此类流量数据。本第 3.1 (f) 节中的任何内容均不应被视为构成 ICANN 同意或默许注册管理运行机构重新引入注册管理运行机构先前在 2003 年 9 月 15 日当天或前后推出的 SiteFinder 服务,或引入任何使用通用通配符功能的其他服务,但本句不禁止为除注册服务以外的域名或区域提供域名服务或任何其他非注册服务由单一实体(包括其关联公司)用于通过 ICANN 认可的注册商注册的域名。只要提供受本规定约束的交通数据,访问的条件应是非歧视性的。

第 3.2 节 ICANN 的契约。ICANN 与注册管理运行机构签订协议并达成以下协议:

(a) 公开透明。根据ICANN明确的使命和核心价值观,ICANN应以开放和透明的方式运作。

(b) 公平待遇。ICANN 不得任意、不合理或不公平地适用标准、政策、程序或做法,除非有充分和合理的理由,否则不得将注册管理运行机构单独列为不同的待遇。

(c) TLD 区域服务器。如果ICANN获授权制定有关权威根服务器系统的政策,它将确保:(i) 在本协议有效期内,权威根将指向注册管理运行机构为注册管理机构顶级域指定的顶级域名区域服务器;(ii) 注册管理运行机构向ICANN提交的TLD区域服务器名称的任何变更将在提交后的七天内由ICANN实施。

(d) 域名服务器变更。注册管理运行机构可以要求更改注册管理机构顶级域的域名服务器授权。任何此类请求都必须以某种格式提出,并且必须符合 ICANN 不时规定的技术要求。ICANN 将采取商业上合理的努力,在提交后的七个日历日内在权威根服务器系统中实施此类请求。

(e) 根区信息发布。ICANN 公布的注册管理机构顶级域根区联系信息将包括注册管理运行机构及其行政和技术联系人。任何修改注册管理运行机构联系信息的请求都必须按照 ICANN 不时规定的格式提出。

3.3合作。双方同意相互合作并在必要时共享数据,以完成本协议的条款。

3.4合同和运营合规性审计。

9


(a) ICANN 可不时(每个日历季度不超过一次)进行合同合规性审计,或聘请第三方进行合同合规性审计,以评估注册管理运行机构对本协议第二条所载陈述和保证以及本协议第三条所载承诺的遵守情况。此类审计应量身定制,以实现评估合规性的目的,ICANN 将 (i) 合理地提前通知任何此类审计,该通知应合理详细说明 ICANN 要求的文件、数据和其他信息的类别,以及 (ii) 采取商业上合理的努力进行此类审计,以免不合理地干扰注册管理运行机构的运营。作为此类审计的一部分,应ICANN的要求,注册管理运行机构应及时提供所有必要的响应性文件、数据和任何其他信息,以证明注册管理运行机构遵守本协议。在收到不少于五 (5) 个工作日的通知后(除非注册管理运行机构另有约定),ICANN 可以在正常工作时间进行实地考察,以评估注册管理运行机构对第 3.1 节中所载承诺的遵守情况,这是任何合同合规性审计的一部分。

(b) 根据第 3.4 (a) 条进行的任何审计费用将由 ICANN 承担,除非 (i) 审计与注册管理运行机构遵守第 3.1 (c) (iv) 条的情况有关,且此类审计显示注册管理运行机构提供的数据存在重大差异或差异,或 (ii) 审计与注册管理运行机构根据本协议支付的费用差异超过 5% 有关,对 ICANN 不利。无论是上述 (i) 或 (ii),注册管理运行机构都应向 ICANN 偿还与此类审计相关的所有合理成本和开支,此类报销将与下一次注册管理机构级别费用一起支付,该费用将在提交此类审计的费用报表之日后支付。

第四条协议期限

第 4.1 节期限。本协议自生效之日起至2029年6月30日(“到期日”),但根据第 4.2 节续约时可延长该期限(初始和任何续订条款共同构成 “期限”)。注册管理运行机构同意,在 (i) ICANN 根据下文第 VI 条终止本协议或 (ii) 到期日,以较早者为准,它将不再是 TLD 的注册管理运行机构,除非注册管理运行机构和 ICANN 在到期日之前就协议的续订条款达成协议,如下文第 4.2 节所述。

第 4.2 节续订。本协议应在上文第 4.1 节规定的初始期限和本协议的每个续订期限到期时续订,除非出现以下情况:(i) 在根据第 6.1 节向注册管理运行机构发出违约通知且未能在第 6.1 节规定的期限内纠正此类违规行为后,仲裁员或法院裁定注册管理运行机构从根本上和实质上违反了第 3.1 (a)、(b) 节规定的注册管理运行机构的义务)、(d) 或 (e);第 5.2 节或第 7.3 和 (ii) 节在该仲裁员或法院做出最终裁决后,注册管理运行机构未能在十天内遵守仲裁员的裁决或
10


法院,或在仲裁员或法院规定的其他期限内。续约时,如果本协议的条款与五个最大通用顶级域的注册管理机构协议中的普遍有效条款(由续订时管理的域名注册数量决定)不相似,则续订应根据合理必要的条款进行续约,以使本协议的条款与这些其他 gTLD 的注册管理机构协议中的条款相似。但是,前一句不适用于本协议中关于注册管理机构服务价格的条款;拟议注册管理机构服务的考虑标准,包括安全性和稳定性的定义以及 ICANN 在考虑过程中适用的标准;续订或终止本协议的条款或条件;第 3.2 (a)、(b) 和 (c) 节中ICANN对注册管理运行机构的义务;对共识政策或临时或规范政策的限制;注册表的定义服务;或第 7.3 节的条款。续订后,可以合理修改注册管理机构级别交易费用,前提是此类费用的增加幅度不超过前三年内5个最大通用顶级域名(按上文确定)的注册管理机构级交易费用增长百分比的平均值。双方同意在协议到期日前至少六 (6) 个月就协议的每次续订启动谈判。

第 4.3 节的更改。在本协议生效期间,双方同意定期(自生效之日起至少每三个日历年进行一次)就协议条款的可能变更进行真诚的谈判,包括关于向ICANN支付费用和付款的第7.2节。

第 4.4 节未能本着诚意行事。如果注册管理运行机构一再故意从根本上和实质上违反注册管理运行机构在第 3.1 (a)、(b)、(d) 或 (e) 节;第 5.2 节或第 7.3 节中规定的义务,并且仲裁员根据本协议第 5.1 (b) 节一再认定注册管理运行机构在根本和实质上违反本协议,包括在至少三项单独的裁决中,则仲裁员应作出此类裁决惩罚性、惩戒性或其他损害赔偿,视情况而定。

第五条争议解决

第 5.1 节争议的解决。

(a) 合作参与。如果注册管理运行机构与 ICANN 之间因本协议或因本协议而出现分歧,任何一方均可向另一方发出通知,援引本第 V 条的争议解决条款,但是,在任何一方按照下文第 5.1 (b) 节的规定启动仲裁之前,ICANN 和注册管理运行机构必须尝试通过本第 5.1 (a) 节所述的合作参与来解决争议。如果任何一方按照本第 5.1 (a) 节的规定向另一方提供书面通知,则双方将在根据第 8.8 节视为收到该书面通知后的七个日历日内发出书面通知
11


因此,根据本第 5.1 (a) 节,指定一名执行官作为其代表,完全有权代表该方采取行动解决争议。指定的代表应在被指定后的两个工作日内通过电话或当面进行协商,试图解决争议。如果他们无法在此类电话会议或会议期间解决争议,则他们应在该首次电话会议或会议之后的 7 个日历日内在 ICANN 合理指定的地点进一步亲自会面,各方应在该次会议上尝试达成最终解决方案。对于任何争议,本第 5.1 (a) 节中规定的时间表和流程可以修改,但前提是双方事先以书面形式同意修改后的时间表或程序。本款范围内的和解通信在当事方之间的任何仲裁或诉讼中均不可受理。

(b) 仲裁。根据国际商会国际仲裁法院(“ICC”)的规则,根据本协议第 5.1 (b) 节的规定通过具有约束力的仲裁来解决本协议或与本协议相关的争议,包括具体履行请求。仲裁应以英语进行,只有在未能根据上文第 5.1 (a) 节所述的合作参与讨论解决争议后,才能在美国加利福尼亚州洛杉矶县进行仲裁。应有三名仲裁员:各方应选择一名仲裁员,如果两名仲裁员无法就第三名仲裁员达成协议,则应由国际商会选择第三名仲裁员。仲裁的胜诉方有权收回其费用和合理的律师费,仲裁员应将这些费用和律师费纳入其裁决中。任何寻求确认或撤销根据本第 5.1 (b) 节发布的仲裁裁决的一方只能根据适用的仲裁法规这样做。在涉及 ICANN 与本协议相关的任何诉讼中,此类诉讼的司法管辖权和专属审理地应位于美国加利福尼亚州洛杉矶县的法院进行;但是,双方也有权在任何具有司法管辖权的法院执行此类法院的判决。为了在仲裁待决期间协助仲裁和/或维护当事方的权利,当事方有权向仲裁小组或法院寻求临时中止或禁令救济,这不应是对本仲裁协议的放弃。

第 5.2 节特定性能。注册管理运行机构和 ICANN 同意,如果本协议的任何条款未按照其具体条款执行,可能会造成无法弥补的损失。因此,双方同意,他们都有权要求仲裁员具体履行本协议的条款(以及各方有权获得的任何其他补救措施)。

第 5.3 节责任限制。ICANN 因违反本协议而承担的总金钱责任不得超过注册管理运行机构在过去十二个月内根据本协议第 7.2 节向 ICANN 支付的注册管理机构级别费用金额。注册管理运行机构因违反本协议而对 ICANN 承担的总金钱责任仅限于前十二个月内根据本协议应向 ICANN 支付和应付的费用和第 4.4 条规定的金钱制裁(如果有)。在任何情况下任何一方都不得
12


除非本协议第 4.4 节另有规定,否则对因本协议或履行或不履行本协议中承担的义务而产生的或与之相关的特殊、间接、附带、惩罚性、惩戒性或间接损害承担责任。除非本协议中另有明确规定,否则注册管理运行机构不对本身、其雇员或其代理人提供的服务或其工作结果作出任何明示或暗示的保证,包括但不限于对适销性、非侵权性或特定用途适用性的任何暗示担保。

第六条终止条款

第 6.1 节 ICANN 的终止。在且仅在以下情况下,ICANN 才可以终止本协议:(i) 注册管理运行机构未能在 ICANN 向注册管理运行机构发出书面违规通知后的三十个日历日内纠正注册管理运行机构在第 3.1 (a)、(b)、(d) 或 (e) 节中规定的任何根本和重大违规行为;以及 (ii) (a) 仲裁员或法院最终确定注册管理运行机构存在或曾经存在根本和实质性违规行为,但未能纠正此类违规行为在规定的期限内,以及 (b) 在该仲裁员或法院作出裁决后,注册管理运行机构未能遵守仲裁员或法院的裁决。

第6.2节破产。ICANN 可在通知注册管理运行机构后终止本协议,前提是:(i) 注册管理运行机构为债权人进行转让或采取类似行动;(ii) 对注册管理运行机构启动扣押、扣押或类似程序,这些程序对注册管理运行机构运营 TLD 注册管理机构的能力构成重大威胁,并且在启动后的六十 (60) 个日历日内未被解雇;(iii) 受托人、接管人、清算人或同等人员被指定代替注册管理运行人或保持对任何注册管理机构的控制权注册管理运行机构的财产,(iv) 执行是针对注册管理运行机构的任何重大财产征收的,如果征收,有理由预计将对注册管理运行机构运营顶级域注册管理机构的能力产生重大不利影响,(v) 注册管理运行机构根据任何破产、破产、重组或其他与债务人救济有关的法律提起或针对注册管理运行机构的诉讼,并且此类程序在启动后的六十 (60) 个日历日内未被撤销(如果此类诉讼由注册管理机构或其提起关联公司)或其启动后的一百八十(180)个日历日(如果此类诉讼是由第三方对注册管理运营商提起的),或(vi)注册管理运行机构根据《美国破产法》、11 U.S.C. 第101条及以下条款申请保护,或外国等效物或清算人,解散或以其他方式终止其运营或TLD的运营。

第 6.3 节协议终止后注册管理机构的过渡。在第4.1节规定的本协议到期或根据第6.1和6.2节的规定终止本协议时,双方同意工作
13


根据本第 6.3 节合作促进和实施 TLD 注册管理机构的过渡。除了根据本协议第 3.1 (c) (i) 节托管的数据外,注册管理运行机构应同意向ICANN或任何可能为该顶级域指定的继任注册管理机构提供维持运营所必需的有关该顶级域注册管理机构运营的任何数据,这些数据是合理要求的。

第 6.4 节数据中的权利。注册管理运行机构无权在注册表数据中主张任何知识产权。如果注册管理机构数据按照第 3.1 (c) (i) 节的规定从托管中释放,则注册管理运行机构在数据中持有的权利(如果有)应在非排他性、不可撤销、免版税、付费的基础上自动许可给 ICANN 或 ICANN 书面指定的当事方。

第 6.5 节不予赔偿。注册管理运行机构与本协议相关的任何和所有支出、资本投资或其他投资均应由注册管理运行机构自担风险,ICANN 没有义务向注册管理运行机构偿还任何此类费用、资本支出或投资。在 (i) 本协议终止或到期或 (ii) 注册管理机构移交之前,不应因为向注册管理运行机构支付注册费而要求注册管理运行机构向继任注册管理运行机构支付任何款项,除非注册管理机构向继任运营商过渡的任何延迟是由于注册管理运行机构的行动所致。

第七条特别条款

第 7.1 节《注册管理机构与注册商协议》。

(a) 访问注册服务。注册管理运行机构应向所有 ICANN 认证的注册服务机构提供对注册管理机构服务(包括共享注册系统)的访问权限,但须遵守本文附录 8 中所附的《注册管理机构-注册服务商协议》的条款。在遵守第 7.1 (e) 节的前提下,注册管理运行机构应在执行《注册管理机构-注册服务商协议》后,向所有经ICANN认证的注册服务商提供注册管理机构服务的操作权限,包括顶级域的共享注册系统,前提是注册服务商遵守此类协议。这种非歧视性准入应包括但不限于以下内容:

(i) 所有注册服务商(包括任何隶属于注册管理运营商的注册商,如果有的话)都可以使用相同的最大数量的 IP 地址和 SSL 证书身份验证,通过互联网连接到 TLD 的共享注册系统网关;

(ii) 注册管理运行机构已向所有注册服务机构提供当前版本的注册服务商工具包软件,并按相同的时间表向所有注册服务机构提供了所有更新;

(iii) 所有注册服务机构均可通过电话、电子邮件和注册管理运行机构网站与客户支持人员取得相同级别的联系;

14


(iv) 所有注册服务商对注册管理机构资源的访问权限均相同,以解决注册管理机构/注册商或注册服务商/注册商的争议以及技术和/或行政客户服务问题;

(v) 所有注册服务机构对注册管理运行机构生成的数据具有同等的访问权限,以协调其来自注册管理运行机构网络和ftp服务器的注册活动;

(vi) 所有注册服务机构均可使用注册管理运行机构向所有注册服务机构提供的相同注册商工具执行基本的自动注册商账户管理功能;以及

(vii) 为了提供歧视性准入的目的,共享注册系统不包括任何在功能方面区分注册服务商的算法或协议,包括数据库访问、系统优先级和整体性能。

注册管理运行机构可以不时修订此类注册管理机构-注册服务商协议,但前提是任何此类修订必须事先获得 ICANN 的批准。

(b) 特别方案。尽管有第 7.1 (a) 条的规定,注册管理运行机构可以为支持服务不足的地理区域(一个或多个国家)的互联网发展,根据注册服务机构的独特需求提供培训、技术支持、营销或激励计划,前提是注册管理运行机构不区别对待处境相似的注册服务商或任意应用此类计划。此外,注册管理运行机构可以针对特定地理区域(一个或多个国家/地区)内的注册服务商实施此类计划,前提是 (i) 该地区的定义足够宽泛,允许多个注册服务机构参与,并且此类计划可供所有此类注册服务机构使用,并且 (ii) 此类计划不有利于任何注册管理运行机构可能拥有所有权的注册服务商。就本节而言,注册管理运行机构根据对相关指标的分析,包括但不限于宽带渗透率、信息和技术支出、域名渗透率、注册商渗透率、虚拟主机渗透率、互联网使用情况和互联网用户数量,在合理的判断下,服务不足的地理区域是指注册管理运营商服务不足的地理区域。在提供任何此类计划后的五 (5) 个日历日内,注册管理运行机构应在注册服务机构面向注册管理运行机构网站的通信工具(该通知至少应包括此类计划的条款和条件,并指明该计划所依据的服务不足的地理区域),发布该计划的提供通知。

(c) 注册管理机构不得充当自己的注册商。注册管理运行机构不得担任 TLD 的注册商。这不应妨碍注册管理运行机构通过向 ICANN 认可的注册服务商提出请求在顶级域中为自己注册域名。此外,如果顶级域名或互联网的安全和稳定面临迫在眉睫的威胁,则本条款不得
15


为了保护顶级域名或互联网的安全和稳定,禁止注册管理运行机构暂时阻止一个或多个名称的注册;前提是注册管理运行机构尽快但不迟于采取此类行动后的 3 个工作日内,向 ICANN 提供一份关于此类行动的书面通知,该通知应列出所有受影响的名称,说明此类名称无法注册的预期时长,并解释注册管理运行机构采取此类行动的原因行动。在法律允许的范围内,应将此类通知的内容视为机密内容。如果 ICANN 不同意此类行动,它将指示注册管理运行机构公布此类名称,注册管理运行机构应在收到 ICANN 的此类书面指示后立即公布此类名称。

(d) 对获得注册商所有权或控股权的限制。注册管理运行机构不得直接或间接获得任何 ICANN 认可的 TLD 注册机构的控制权或超过 15% 的所有权权益。

(e) 合规行动。注册管理运行机构承认,所有 ICANN 认可的注册服务商都必须与 ICANN 签订注册服务商委任协议(“RAA”),ICANN 可能会采取某些合规行动以应对紧急情况或根据 RAA 的条款采取某些合规行动,包括暂停或终止注册服务商的认证,或暂停注册商创建新注册名称或启动注册域名入站转移的能力。ICANN 可以要求注册管理运行机构采取与 RAA 条款下的 ICANN 授权相一致的具体行动,以:(i) 暂停或终止注册服务商创建新注册名称的权限或 (ii) 将注册域名转让给 ICANN 指定的注册服务商。

第 7.2 节应向 ICANN 支付的费用。

(a) 注册表级别的交易费和同步交易费。注册管理运行机构应向ICANN支付注册管理机构级别交易费,金额等于0.75美元,用于初始或续订域名注册的年度增量,以及在注册管理机构级交易费所涉日历季度内将域名注册从一家 ICANN 认可的注册服务商转移到另一个 ICANN 认可的注册服务商。ICANN 打算将这笔费用用于以下用途:(a) 为发展中国家互联网社群提供特别限制性基金,以使发展中国家的利益相关者能够进一步参与 ICANN 的使命;(b) 用于增强和促进 DNS 安全与稳定的特别限制性基金;(c) 一般运营资金,以支持 ICANN 确保域名系统稳定和安全运营的使命;前提是,ICANN 无需为任何此类目的分离资金或设立此类资金的单独账户。对于注册管理机构在 2020 年 5 月 1 日当天或之后根据注册管理运行机构的合并/同步服务(“同步服务”)(参见附录 9(批准的服务))在 TLD 中进行注册期限的每个域名注册,注册管理运行机构应根据域名注册通过同步服务延长到期日的天数向ICANN支付额外费用,从 0.75 美元中按比例分摊费用(“同步交易”)费用”)。为避免疑问,双方同意同步交易费将
16


不可追溯适用,向ICANN付款的计算自2020年5月1日起开始。

(b) 付款时间表。注册管理运行机构应在每个日历季度结束后的第20个日历日(即截至3月31日、6月30日、9月30日的日历季度的4月20日、7月20日、10月20日和1月20日)之前,支付第 7.2 (c) 节中规定的固定注册机构级别费用和第 7.2 (d) 节规定的可变注册机构级别费用(如适用)第 7.2 (a) 节规定的注册管理机构级别交易费和同步交易费,以及当年的 12 月 31 日)存入 ICANN 指定的账户。

(c) 固定注册机构级别费用。注册管理运行机构应向ICANN支付季度固定注册管理机构级别费用,金额相当于每季度37,950美元。此后,此类费用将在每年7月1日增加,金额由ICANN董事会确定,但不得超过相当于上一年度费用115%的金额。注册机构级别交易费用每年超过2,000,000美元,每1美元,将免除一美元(美元)的固定注册机构级别费用。

(d) 可变注册机构级别费用。对于ICANN不向所有注册服务机构收取可变委任费的财政季度,在收到ICANN的书面通知后,注册管理运行机构应向ICANN支付可变注册管理机构级别的费用。费用将由 ICANN 计算,由注册管理运行机构根据第 7.2 (b) 节中的付款计划支付给 ICANN,注册管理运行机构将开具发票并向与注册管理运行机构签订注册管理机构-注册服务商协议的注册服务商收取费用。费用将由两个部分组成;每个部分将由 ICANN 为每个注册商计算:

(i) 可变注册管理机构级别费用的交易部分应由ICANN根据ICANN董事会通过的每个财年预算具体规定,但不得超过0.25美元。

(ii) 可变注册管理机构级别费用的每个注册商部分应由ICANN根据ICANN董事会通过的每个财政年度的预算来规定。

(e) 逾期付款的利息。对于根据第 7.2 节逾期十天或更长时间的任何付款,注册管理运行机构应按每月 1.5% 的利率支付逾期付款的利息,或适用法律允许的最高利率(如果更少)。

第 7.3 节域名注册和注册服务定价。

(a) 定价。ICANN 认可的注册服务商注册新域名和续订域名注册服务商以及将域名注册从 ICANN 认可的注册服务商转移到另一家 ICANN 认可的注册服务商的价格不得超过 10.67 美元的总费用,该费用包括 (A) 相当于 9.92 美元的注册管理运行机构服务费(“服务费”),以及 (B) 相当于 0.75 美元的 ICANN 费用。在一个日历年内,每增加一次新的和年度增量时收取的服务费
17


续订域名注册以及将域名注册从 ICANN 认可的注册商转移到另一个 ICANN 认可的注册服务商,不得超过前一个日历年收取的最高服务费乘以 1.10。应向所有 ICANN 认证的注册服务机构收取相同的服务费。如果所有 ICANN 认可的注册服务机构都有同样的机会获得这些折扣、营销支持和激励计划的资格,则可以提供批量折扣、营销支持和激励计划。为避免疑问,第 7.1 (b) 节明确允许的程序不得违反本第 7.3 (a) 节。

(b) 调整域名注册定价。注册管理运营商应在域名注册价格上涨之前至少提前六个月发出通知,并应继续提供域名注册,期限最长为十年。

第八条其他

第 8.1 节 ICANN 的赔偿。

(a) 注册管理运行机构应赔偿、捍卫ICANN(包括其董事、高级职员、雇员和代理人)免受任何和所有第三方索赔、损害、负债、成本和开支,包括合理的律师费用和开支,这些索赔和开支是由以下原因引起的或与之相关的合理律师费用和开支:(a) ICANN 在决定将顶级域名委托给注册管理运行机构或签订本协议时,依赖注册管理运行机构中提供的信息其对 TLD 的申请;(b) 注册管理运行机构对注册机构的建立或运营对于顶级域名;(c) 注册管理运行机构提供的注册管理机构服务;(d) 注册管理运行机构收集或处理个人数据;(e) 与在域名注册管理机构注册域名有关的任何争议;以及 (f) 注册管理运行机构在运营该顶级域注册管理机构方面的职责和义务;前提是注册管理运行机构没有义务在以下范围内赔偿、捍卫ICANN或使其免受损害因ICANN违反本协议中包含的任何义务而产生的索赔、损害、责任、成本或费用,或ICANN 的任何故意不当行为。为避免疑问,本第 8.1 节中的任何内容均不应被视为要求注册管理运行机构偿还或以其他方式赔偿 ICANN 与谈判或执行本协议中各方各自义务相关的费用。此外,本节不适用于与当事人之间或当事人之间的任何诉讼或仲裁有关的任何律师费申请。

(b) 对于因多个注册管理运行机构(包括注册管理运行机构)参与导致索赔的作为或不作为而由ICANN提出的任何赔偿索赔,注册管理运行机构就此类索赔向ICANN提供赔偿的总责任应限于ICANN索赔总额的百分比,计算方法是除以顶级域内注册管理运行机构注册的域名总数(注册名称的计算应与第7.2节一致)此处(适用于任何适用的季度)乘以总数内注册的域名数量
18


所有与其注册管理机构运营商有相同行为或不作为而导致此类索赔的顶级域。为避免疑问,如果注册管理运行机构从事了引起上述索赔的相同作为或不作为,但此类注册管理运行机构对ICANN没有相同或相似的上文8.1(a)规定的赔偿义务,则此类注册管理运行机构管理的域名数量仍应包含在前一句的计算中。

第 8.2 节赔偿程序。如果 ICANN 收到根据上文第 8.1 条获得赔偿的任何第三方索赔的通知,ICANN 应立即将此类索赔通知注册管理运行机构。如果注册管理运行机构选择这样做,则有权在及时向ICANN发送的通知中立即控制此类索赔的辩护和调查,并雇用和聘请受赔方合理接受的律师来处理和辩护,费用和费用由赔偿方自行承担,前提是在任何情况下,ICANN都有权自行承担成本和费用控制与ICANN的有效性或解释有关的问题的诉讼政策或行为。ICANN 应在所有合理的方面自费与注册管理运行机构及其律师合作,对此类索赔及由此产生的任何上诉进行调查、审判和辩护;但是,受赔方可通过其律师或其他方式自费参与对此类索赔以及由此产生的任何上诉的调查、审判和辩护。未经 ICANN 的同意,对于涉及影响 ICANN 的补救措施的索赔,除了支付赔偿金额外,不得达成任何和解。如果注册管理运行机构无法完全控制根据本节进行抗辩的索赔的辩护,则注册管理运行机构可以参与此类辩护,费用和费用由注册管理运行机构自行承担,ICANN 有权以其认为适当的方式为索赔进行辩护,费用和费用由注册管理运行机构承担。

第 8.3 节没有偏移量。无论注册管理运行机构与 ICANN 之间仍有任何争议(金钱或其他争议)悬而未决,本协议项下的所有应付款项均应在本协议的整个期限内及时支付。

第 8.4 节 ICANN 名称和徽标的使用。ICANN 向注册管理运行机构授予非独家免版税许可,声明其被 ICANN 指定为注册管理机构顶级域的注册管理运行机构,并使用 ICANN 指定的徽标来表示注册管理运行机构是 ICANN 指定的注册管理机构。该许可证不得由注册管理运行机构分配或再许可。

第 8.5 节转让和分包。本协议的任何转让只有在受让人与另一方达成书面协议,承担转让方在本协议下的义务后才生效。此外,未经另一方事先书面批准,任何一方均不得转让本协议,不得无理拒绝。尽管有上述规定,ICANN可以在重组或重组ICANN的同时,将本协议转让给为相同或基本相同目的而组建的另一家非营利性公司。注册管理运行机构必须向
19


ICANN的任何分包安排以及任何分包顶级域部分运营的协议都必须要求注册管理运行机构遵守本协议下的所有契约、义务和协议。任何技术业务分包都应规定分包实体成为本协议第 3.1 (c) (i) 节规定的数据托管协议的当事方。

第 8.6 节修正和豁免。除非双方以书面形式签署,否则对本协议或其任何条款的任何修改、补充或修改均不具有约束力。除非有一方签署的放弃遵守该条款的书面证明,否则对本协议任何条款的放弃均不具有约束力。除非另有明确规定,否则对本协议任何条款的放弃或未能执行本协议任何条款均不应被视为或不构成对本协议任何其他条款的放弃,也不得构成持续放弃。

第 8.7 节无第三方受益人。本协议不得解释为 ICANN 或注册管理运行机构对本协议的任何非缔约方(包括任何注册服务商或注册域名持有人)产生任何义务。

第 8.8 节通知、名称和规范。根据本协议发出的或与本协议有关的所有通知均应 (i) 以书面形式发送至下文所述相应方的地址,或 (ii) 通过下文规定的电子邮件发送,除非该方根据本协议的规定发出了更改邮政地址或电子邮件地址的通知。以下通知的联系信息的任何变更均应由当事方在变更后的 30 天内提供。本协议要求的任何通知均应被视为已正确发出(i)如果是纸质形式,当面交付或通过快递服务并确认收货时,或(ii)在收件人的电子邮件服务器确认收货后,通过电子邮件发送。每当本协议为某些信息指定 URL 地址时,当以电子方式在指定 URL 上发布任何此类信息时,注册管理运行机构均应被视为已收到任何此类信息的通知。如果其他通知方式切实可行,例如通过安全网站发出通知,则双方应共同努力实施本协议规定的此类通知方式。

如果寄给 ICANN,请寄至:

互联网名称与数字地址分配机构 12025 号水滨大道,300 号套房
加利福尼亚州洛杉矶 90094-2536 美国
电话:+1 310 301 5800
注意:总裁兼首席执行官
附上必填副本发送至:总法律顾问电子邮件:(不时指定。)
如果寄给注册管理运营商,寄至:VeriSign, Inc.
20


12061 Bluemont Way
弗吉尼亚州雷斯顿 20190
电话:1-703-948-4524
注意:高级副总裁、副总法律顾问
附上所需副本寄至:总法律顾问
电子邮件:(不时指定。)

第 8.9 节语言。根据本协议做出的通知、名称、决定和规格应使用英语。

第 8.10 节对应项。本协议可以在一个或多个对应方中执行,每个对应方均应被视为原始协议,但所有对应方共同构成同一份文书。

第 8.11 节完整协议。本协议一经执行,将对先前协议的全部内容进行修订和重申。本协议(包括构成其一部分的附录)构成本协议各方与顶级域运营相关的完整协议,并取代双方先前就该问题达成的口头或书面协议、谅解、谈判和讨论。如果本协议正文中的规定与其附录中的任何条款发生冲突,则以本协议正文中的规定为准。


[签名页面如下]




21


为此,本协议各方促使本协议由其正式授权的代表执行,以昭信守。


互联网名称和号码分配公司

作者:/s/ Sally Costerton
莎莉·科斯特顿
临时总裁兼首席执行官
日期:2023 年 6 月 29 日

VeriSign, Inc.

作者:/s/ D. James Bidzos
D. James Bidzos
执行主席兼首席执行官
日期:2023 年 6 月 29 日



























22


.NET 注册管理机构协议附录 1
数据托管规范
注册管理运行机构将聘请一个独立实体作为数据托管代理人(“托管代理”),根据一项实质上以附录2形式达成的协议,提供与协议相关的数据托管服务,ICANN、注册管理运行机构和托管代理之间可能会不时修订该协议。
只有在 ICANN 和注册管理运行机构双方书面同意(任何一方都不得无理拒绝)或通过制定《协议》第 3.1 (b) 节所述共识性政策后,才能更改此处规定的时间表、内容、格式和程序。托管应根据协议进行,协议基本上采用附录2的形式,ICANN、注册管理运行机构和托管代理人之间可能会不时修改该协议。
技术规格
1. 存款。将有两种类型的存款:全额存款和差额存款。对于这两种类型,需要考虑进行数据托管的注册表对象范围是提供所有经批准的注册服务所必需的对象。
1.1 “全额存款” 将包括在向托管代理提交全额存款当天 00:00:00(世界协调时间)之前注册表中的数据。
1.2 “差额存款” 是指反映上一次全额或差额存款中未反映的所有交易的数据(视情况而定)。每笔差额存款将包含自上次存款完成以来的所有数据库交易,包括截至每天 00:00:00 UTC的数据,但周一。差额存款必须包括自最近一次全额存款或差额存款(即自上次存款以来数据的所有增加、修改或删除)以来未包括或更改的完整托管记录,如下所述。
2.存款时间表。注册管理运行机构将每天提交一组托管文件,如下所示:
2.1每周一,必须在世界标准时间 23:59 之前向托管代理人提交全额存款。
2.2一周中的其他六 (6) 天、全额存款或相应的差额存款必须在世界标准时间 23:59 之前提交给托管代理。
3.托管格式规范。
23


3.1存款格式。域名、联系人、域名服务器、注册商等注册表对象将按照 RFC 8909 中的说明编译成文件,参见本附录第 9 节参考文献 1 和 RFC 9022,参见本附录第 9 节参考文献 2(统称为 “DNDE 规范”)。DNDE 规范将某些元素描述为可选元素;如果这些元素可用,注册管理运行机构将包括在存款中。将使用 UTF-8 字符编码。
3.2 扩展。如果注册管理运行机构提供需要提交额外数据(未包括在上文中)的额外注册管理机构服务,则应根据具体情况定义额外的 “扩展架构” 来表示该数据。将按照本附录第 9 节参考文献 2 中所述指定这些 “扩展架构”。与 “扩展架构” 相关的数据将包含在本附录第 3.1 节所述的存款文件中。ICANN 和注册管理运行机构应共同商定此类新对象的数据托管规范。
4. 处理存款文件。建议使用压缩以减少电子数据传输时间和存储容量要求。数据加密将用于确保注册表托管数据的隐私。根据 OpenPGP 消息格式——RFC 4880,经过压缩和加密处理的文件将采用二进制 OpenPGP 格式,参见本附录第 9 节参考文献 3。公钥加密、对称密钥加密、哈希和压缩的可接受算法是在 RFC 4880 中列举的算法,在 OpenPGP IANA 注册表中未标记为已弃用的算法,参见本附录第 9 节参考文献 4,这些算法也是免版税的。原始文本格式的数据文件应遵循的过程是:
1) 本附录第 9 节参考文献 1 中描述的存款 XML 文件必须按照第 5 节的规定命名为包含文件,但扩展名为 xml。
2) 数据文件聚合到一个名为 (1) 但扩展名为 tar 的 tarball 文件中。
3) 使用压缩包文件作为唯一输入来创建压缩和加密的 OpenPGP 消息。根据 RFC 4880,建议的压缩算法是 ZIP。压缩后的数据将使用托管代理的公钥进行加密。根据RFC 4880,建议的公钥加密算法是Elgamal和RSA。根据 RFC 4880,建议的对称密钥加密算法是 TripleDES、AES128 和 CAST5。
4) 如果文件在压缩和加密后大于与托管代理商定的文件大小限制,则可以根据需要拆分。在本节中,拆分文件的每个部分,或整个文件(如果未拆分)都将被称为已处理文件。
24


5) 将使用注册管理机构的私钥为每个处理过的文件生成一个数字签名文件。根据RFC 4880第9节参考文献3,数字签名文件将采用二进制OpenPGP格式,不会进行压缩或加密。根据RFC 4880,建议的数字签名算法是DSA和RSA。数字签名中哈希值的建议算法是 SHA256。
6) 然后,经处理的文件和数字签名文件将通过安全的电子机制(例如SFTP、SCP、HTTPS文件上传等)传输到托管代理机构,这是托管代理人和注册管理机构之间商定的那样。经过 ICANN 的授权,可使用通过 CD-ROM、DVD-ROM 或 USB 存储设备等物理介质进行非电子交付。
7) 然后,托管代理将使用本附录第8节中描述的程序验证每个(已处理的)传输的数据文件。
5. 文件命名规范。文件将根据以下约定命名:{gTLD} _ {YYYY-MM-DD} _ {type} _S {#} _R {rev}。{ext} 其中:
5.1 {gTLD} 替换为通用顶级域名;如果是 IDN-TLD,则必须使用兼容 ASCII 的表格(A-Label);
5.2 {YYYY-MM-DD} 由与用作交易时间线水印的时间对应的日期所取代;即,对于对应于 2009-08-02T 00:00 Z 的全额存款,使用的字符串将是 “2009-08-02”;
5.3 {type} 替换为:
1) “全额”,如果数据代表全额存款;
2) “差异”,如果数据代表差额存款;
3) “thin”,如果数据代表批量注册数据访问文件,如附录 5A 第 2.1 节所述;
4) “thick-{gurid}”,如果数据代表来自特定注册商的详细注册数据,如附录 5A 第 2.2 节所定义。{gurid} 元素必须替换为与数据关联的 IANA 注册商 ID。
5.4 {#} 替换为文件在一系列文件中的位置,以 “1” 开头;如果是孤立的文件,则必须替换为 “1”。
5.5 {rev} 替换为以 “0” 开头的文件的修订版(或重新发送)数:
25


5.6 如果 {ext} 是准同音文件的数字签名文件,则替换为 “sig”。否则,它将被替换为 “ryde”。
6. 公钥的分发。每个注册管理运行机构和托管代理人将通过电子邮件将其公钥分发给另一方(视情况而定,注册管理运行机构或托管代理人),发送到一个待指定的电子邮件地址。各方将通过回复电子邮件确认收到另一方的公钥,分发方随后将再次确认通过离线方式(例如面对面会议、电话等)传输的密钥的真实性。这样,公钥传输将向能够通过分发方运营的邮件服务器发送和接收邮件的用户进行身份验证。托管代理人、注册管理运行机构和 ICANN 将通过相同的程序交换公钥。
7. 存款通知。除了每笔存款的交付外,注册管理运行机构还将向托管代理和ICANN(使用草稿-lozano-icann-registry-interface中描述的API,参见本附录第9节参考文献5(“接口规范”))提供注册管理运行机构的书面声明(可以通过经过身份验证的电子邮件发送),其中包括存款创建时生成的报告的副本,并指出存款已由注册管理运行机构检查并已完成而且准确。本声明的编制和提交必须由注册管理运行机构或其指定人员执行,前提是该指定人不得是托管代理人或托管代理的任何附属机构。注册管理运行机构将在其声明中包括存款的 “ID” 和 “重新发送” 属性。这些属性在本附录的第 9 节参考文献 1 中进行了说明。
如果尚未成为 RFC,注册管理运行机构将使用自 2023 年 7 月 1 日起的最新接口规范草案版本。2023 年 7 月 1 日之后,注册管理运行机构可以选择使用接口规范的更新版本。接口规范作为 RFC 发布后,注册管理运行机构将在发布后的一百八十 (180) 个日历日内实施该版本的接口规范。
8. 验证程序。
1) 每个已处理文件的签名文件都经过验证。
2) 如果处理后的文件是较大文件的一部分,则将后者放在一起。
3) 然后对上一步中获得的每个文件进行解密和解压缩。
4) 然后,根据本附录第 9 节参考文献 1 中定义的格式,对上一步中包含的每个数据文件进行验证。
5) 数据托管代理扩展验证流程(定义见本附录第 9 节参考文献 2),以及该参考文献中包含的任何其他数据托管验证流程。
26


如果在任何步骤中发现任何差异,则存款将被视为未完成。
27


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

28


.NET 注册管理机构协议附录 2
托管协议(模板格式)

image_1a.jpg

本托管协议(“托管协议”)自订立之日起 [],由 VeriSign, Inc.(“注册管理运营商”)以及威瑞信公司(“注册管理运营商”) [](“托管代理”)和互联网名称与数字地址分配机构(“ICANN”)。

初步声明。注册管理运行机构打算按照本文的定义和规定将 “存款” 交付给托管代理。注册管理运行机构希望托管代理人持有存款,并在发生本文所述的某些事件时,根据本协议条款将存款(或其副本)交付给 ICANN。

因此,鉴于前述情况,考虑到下文提出的相互承诺,并为了其他有益和宝贵的报酬,特此确认这些承诺的收到和充足性,双方商定如下:

1. 由注册管理运行机构交付。根据 “数据托管规范” 的定义和描述,注册管理运行机构应全权负责向托管代理交付存款,该规范作为注册管理运行机构与 ICANN 之间的.net 注册管理机构协议(“注册管理机构协议”)附录 1 附录 1 附录,并通过本参考文献纳入此处(“附录 1”)。注册管理运行机构可以选择根据附录1或以托管代理人和注册管理运行机构共同商定的方式将存款交付给托管代理人。收到存款后,托管代理应立即根据附录1处理存款并生成文件清单,托管代理应在每个日历月结束后的十(10)个工作日内通过电子邮件或美国邮件将该清单转发给注册管理运营商。在收到存款后的两(2)个工作日内,Escrow Agent应通过执行附录1中规定的验证程序来验证存款的格式是否正确且看似完整。Escrow Agent 应在每个月的最后一个工作日向 ICANN 提供书面认证,证明其已对上个月收到的所有存款执行了附录 1 中描述的验证程序,并应向 ICANN 交付该程序生成的验证报告的副本。如果托管代理发现任何存款未通过验证程序,则托管代理应在四十八 (48) 小时内将此类不合格情况通知ICANN和注册管理运行机构。然后,托管代理人应根据本协议的条款和条件持有存款。

2. 复制。为了遵守本托管协议的条款和规定,托管代理人可以通过任何方式重复存款。或者,通过通知注册管理运行机构,托管代理可以合理地要求注册管理运行机构立即复制存款并将其转发给托管代理人。
29



3. 存款通知;公钥的分发。

(a) 在向托管代理人交付每笔存款的同时,注册管理运行机构还应根据附录 1 第 7 节(存款通知)的条款和条件,向托管代理和 ICANN 交付注册管理运行机构的书面声明。托管代理应在收到任何存款后的两 (2) 个工作日内,通过电子邮件、传真或电话,或按照注册管理运行机构的要求向注册管理运行机构发送通知,并使用注册管理机构接口规范 “互联网草案” 中所述的API以电子方式向ICANN发送通知,通知截至本托管协议生效之日,网址为 https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces。此外,Escrow Agent还应附上验证报告的副本,以确认其已运行验证流程。

(b) 每个注册管理运行机构和托管代理人将通过电子邮件将其公钥分发给另一方(视情况而定,注册管理运行机构或托管代理人),发送到一个待指定的电子邮件地址。各方将通过回复电子邮件确认收到另一方的公钥,分发方随后将再次确认通过离线方式(例如面对面会议、电话等)传输的密钥的真实性。这样,公钥传输将向能够通过分发方运营的邮件服务器发送和接收邮件的用户进行身份验证。托管代理人、注册管理运行机构和 ICANN 将通过相同的程序交换公钥。

4. 由托管代理交付

4.1由托管代理向 ICANN 交付。只有在以下情况下,托管代理才应向 ICANN 交付存款或存款的完整副本:
(a) 注册管理运行机构通知托管代理在特定地址向 ICANN 进行此类交付,通知中附有一张应付给托管代理人的金额为一百美元(100.00 美元)的支票;或

(b) 托管代理从 ICANN 收到:

(i) 根据《注册管理机构协议》第 6 条最终、有效且合法地终止注册管理机构协议的书面通知,并且没有从仲裁员或法院获得禁令或类似命令,禁止 ICANN 保护该托管中的数据(“注册管理机构终止”);

(ii) ICANN 之前以书面形式将此类注册管理机构终止一事通知注册管理运行机构的书面声明;

(iii) 要求发放存款并将其交付给 ICANN 的书面要求;

30


(iv) ICANN 的书面承诺,提供给 ICANN 的存款将仅在《注册管理机构协议》条款允许的范围内使用;

(v) ICANN 对此次交付的具体指示;以及

(vi) 注册管理运行机构或 ICANN(随后将由注册管理运行机构向其报销)开具的支票,金额为一百美元(100.00 美元),应付给托管代理人;或

(c) 根据下文第 8 (b) 节进行释放。

4.2应注册管理运行机构的要求交付。如果上述第4.1(a)节的规定得到满足,则托管代理人应在收到第4.1(a)节规定的通知和支票后的二十四(24)小时内,根据适用的指示交付存款。

4.3应ICANN的要求交付。如果上述第 4.1 (b) 或 4.1 (c) 节的规定得到满足,则托管代理人应在收到这些部分中规定的所有文件后的二十四 (24) 小时内向注册管理运行机构交付所有此类文件的副本;(ii) 按照ICANN的特别指示,向ICANN提供存款的电子副本;但是,如果根据第4.1 (c) 条开始交付如上所述,注册管理运行机构可以在上述二十四 (24) 小时内向托管代理支付欠款,并向托管代理付款此后不得向 ICANN 交付上述本节第 (ii) 小节中规定的材料。在收到根据本节 (i) 小节向注册管理运行机构发出的通知后,注册管理运行机构应在收到此类文件之日起三十 (30) 天内(“异议期”)通知托管代理人其对向ICANN发放存款的异议(“异议通知”),并要求根据以下规定将存款副本的权利问题提交仲裁:

(a) 异议通知的发送不应延迟向ICANN交付存款。

(b) 如果注册管理运行机构在异议期内向托管代理人发送异议通知,则该问题应提交美国仲裁协会根据美国仲裁协会的规则选定的三 (3) 名仲裁员组成的小组进行仲裁并通过仲裁解决。仲裁员应适用加利福尼亚州的法律,但不包括其法律冲突规则。至少一 (1) 名仲裁员应对互联网行业相当熟悉。仲裁员的裁决对所有当事方均具有约束力和决定性,其裁决可以在具有司法管辖权的法院作出。托管代理人产生的所有仲裁费用,包括合理的律师费和费用,应由不在仲裁中占上风的一方支付;但是,如果仲裁在仲裁员作出裁决之前达成和解,则参与仲裁的各方应支付所有此类费用的等额百分比。
31



(c) 尽管有上文第4.3 (b) 节的规定,但双方同意,根据本第4.3节提起的任何仲裁均不得重新评估、重新考虑或以其他方式审查涉及本协议各方的仲裁或法院裁决中就注册管理机构协议和/或合作协议作出的任何问题、诉讼原因或其他索赔,并且在根据第4.3节提起的仲裁中有关此类问题或索赔的任何决定均无效、不可执行,而且不具有约束力。注册管理机构协议和/或合作协议下的任何终止或诉讼的适当性、有效性、合法性或效力只能通过相应协议规定的程序和补救措施来确定,不得通过根据第 4.3 节提起的任何仲裁来确定。根据第 4.3 节提起的任何仲裁程序应仅限于确定第 4.1 (b) 和 (c) 节是否得到满足。
(d) 注册管理运行机构可在仲裁程序开始之前随时通知托管代理机构注册管理运行机构已撤回异议通知。收到注册管理运行机构的任何此类通知后,托管代理应根据ICANN提供的指示,立即将存款交给ICANN。

(e) 如果在根据第4.3节提起的任何仲裁中认定根据第4.3条向ICANN发布材料是适当的,则托管代理应根据上文第4.1 (b) (v) 节规定的指示,立即向ICANN交付任何先前未交付的存款。所有各方同意,在向托管代理人支付所有此类费用之前,无需要求托管代理人交付此类存款。

(f) 如果在根据第 4.3 条提起的任何仲裁中认定根据第 4.3 条发放给 ICANN 的存款是不恰当的,ICANN 应根据注册管理运行机构自行决定立即退还或销毁 ICANN 根据第 4.3 款收到的存款。

4.4由托管代理向注册管理运营商交付。根据本协议第7(a)或7(b)节,在本托管协议终止后,托管代理人应发放存款并将其交付给注册管理运行机构。

32


5. 赔偿。

一般赔偿。在遵守下文第 11 (a) 条规定的限制的前提下,注册管理运行机构和 ICANN 应就任何和所有索赔、诉讼、诉讼、责任、义务、成本、费用、收费和任何其他开支,包括合理的律师费和任何其他开支,包括合理的律师费和费用,第三方可能向与本次托管相关的任何托管代理受保人主张的费用本协议下的托管代理人或任何托管代理受保人的协议或业绩,但因信托代理及其董事、高级职员、代理人、员工或承包商的虚假陈述、疏忽或不当行为而产生的任何索赔、诉讼、责任、义务、成本、费用、收费或任何其他费用除外。在遵守第 11 (a) 条规定的限制的前提下,Escrow Agent 同样应对注册管理运营商和 ICANN 及其各自的每位董事、高级职员、代理人和员工(“受保人”)进行绝对和永久的赔偿,使其免受任何和所有索赔、诉讼、诉讼、责任、义务、成本、费用、收费以及任何其他支出,包括合理的律师费和成本由第三方就虚假陈述、疏忽或向任何受保人提出申诉托管代理人及其董事、高级职员、代理人、员工和承包商的不当行为。

33


6. 争议和辩护人。

(a) 托管代理人可以将本托管协议项下的任何争议提交给任何具有司法管辖权的法院,但托管代理人收到根据上文第 4 节提出的异议通知后,本托管协议下的各方将该事项提交给本托管协议第 4 节所述的仲裁除外,其他事项除外。托管代理为此产生的所有费用,包括合理的律师费和成本,应由注册管理运行机构和 ICANN 各承担 50%。

(b) 托管代理人应执行任何具有司法管辖权的法院下令执行的任何行为,不因此类行为而对本协议规定的任何一方承担任何责任或义务。

7. 期限和续期。

(a) 本托管协议的初始期限应从本协议发布之日开始,一直持续到 [日期](“初始期限”).本托管协议将在初始期限结束时和本协议下每个额外期限结束时自动延长一年(均为 “额外期限”)。初始期限和每个附加期限应统称为 “期限”。经ICANN同意,单独行事的托管代理人或注册管理运行机构可在通知其他各方九十 (90) 天后随时终止本托管协议。

(b) 如果注册管理运行机构根据上述第 7 (a) 条发出终止意向的通知,而 ICANN 不同意第 7 (a) 条,ICANN 应负责支付所有后续费用,并有权要求注册管理运行机构偿还此类费用,并在通知其他各方九十 (90) 天后随时终止本托管协议。

(c) 如果根据本协议第 7 (a) 或 7 (b) 条终止本托管协议,注册管理运行机构应支付所有应付的托管代理费用,并应立即通知 ICANN 本托管协议已终止,该托管代理应将其持有的存款的所有副本退还给注册管理运行机构。

8. 费用。注册管理运行机构应向托管代理支付适用的费用,以补偿托管代理在本托管协议下提供的服务。第一年的费用应在收到签订的合同或存款时支付,以先到者为准,并应以美元支付。

(a) 发票付款。接受后,注册管理运行机构应在该发票开具之日起三十 (30) 天内支付有效且正确提交的发票;但是,注册管理运行机构没有义务真诚地支付任何有争议的款项。如果注册管理运行机构真诚地对发票或任何发票提出异议,注册管理运行机构应以书面形式通知托管代理人
34


其中一部分阐述了此类争议的原因,双方同意本着诚意就此类争议发票的解决方案进行谈判;但是,如果双方无法就有争议的费用达成合理的协议,则双方应将此类争议上报到适当的董事/副总裁级别以解决此类争议。向托管代理人支付的款项应发送到托管代理发票上列出的汇款地址。

(b) 不付款。如果不支付托管代理开具的发票上的任何费用或收费,托管代理应通知注册管理运营商未支付本协议项下应付的任何费用,在这种情况下,注册管理运行机构有权在收到托管代理的通知后的十 (10) 个工作日内支付未付费用。如果注册管理运行机构未能全额支付在这十天(10)天内到期的所有费用,则托管代理应通知ICANN未支付本协议项下应付的任何费用,在这种情况下,ICANN有权在收到托管代理的此类通知后的十 (10) 个工作日内支付未付费用。在注册管理运行机构或 ICANN 支付未付费用后(视情况而定),本托管协议将持续完全有效,直至适用期限结束。如果注册管理运行机构或 ICANN 或注册管理运行机构未根据第 4.3 条支付本第 8 (b) 条规定的未付费用,则托管代理应按第 4.3 节的规定行事,就像 ICANN 已要求交付存款一样。

(c) 发票提交地址。在本托管协议的期限内,托管代理人同意按以下地址向注册管理运行机构提交详细而及时的发票,频率不超过每月一次,也不迟于根据此类发票进行的工作完成后的九十(90)天,地址如下所述。根据本协议开具的所有发票均应参考分配给根据本托管协议执行的工作的采购订单号。托管代理不得向注册管理运行机构提交任何未提及适用采购订单号的发票,前提是注册管理运行机构应负责及时向托管代理提供此类适用的采购订单号。托管代理只能通过以下邮寄或电子邮件地址向注册管理机构的应付账款部门提交原始发票:
发票提交地址:VeriSign, Inc.
12061 Bluemont Way
弗吉尼亚州雷斯顿 20190
收件人:应付账款

或者可以通过电子方式将发票提交至:accountspayable@verisign.com

35


9. 存款的所有权。双方承认并承认,在本托管协议的有效期内,存款的所有权应始终归注册管理运行机构所有。

10. 保留和保密。

(a) 保留。Escrow Agent应在安全、锁定和环境安全的设施中存放和维护存款,该设施只有托管代理的授权代表才能访问。托管代理应采取商业上合理的努力来保护存款的完整性。ICANN和注册管理运行机构均有权在合理的事先通知和正常工作时间内检查托管代理人与本托管协议有关的书面记录。

(b) 保密。托管代理应始终保护存款的机密性。除非本托管协议另有规定,否则托管代理不得披露、转让、提供或使用任何存款(或任何存款的任何副本)。如果托管代理被告知根据政府机构、立法机构、有司法管辖权的法院或具有约束力的仲裁机构的法规、规则、规章、命令或其他要求(本托管协议第 4 或 8 (b) 条规定的任何要求除外),托管代理应在七 (7) 天内或在可行的情况下尽快通知 ICANN 和注册管理运行机构,并与注册管理机构和/或运营商进行合理合作在任何披露竞赛中。如果任何竞赛被证明不成功,Escrow Agent对根据此类政府、立法、司法或仲裁命令、法规、规则、法规或其他要求进行的任何披露不承担任何责任。

11. 其他。

(a) 补救措施;责任限制。

(i) 除 (i) 死亡或人身伤害;或 (ii) 注册管理运行机构和/或 ICANN 与托管代理人之间的任何争议中的重大过失或故意不当行为所产生的责任外,托管代理、注册管理运行机构和/或 ICANN 与本托管协议相关的所有责任(如果有),无论是合同、侵权(包括疏忽)还是其他原因引起的,均应限于等于以下金额:当时根据本托管协议向托管代理支付的年费。

(ii) 在注册管理运行机构与 ICANN 之间,《注册管理机构协议》的责任限制也适用。

(iii) 在任何情况下,本托管协议的任何一方均不对另一方承担任何附带性、特殊性、惩罚性或间接损失、利润损失、采购替代服务(不包括替代托管服务)的任何成本或开支或任何其他间接损失,无论是合同、侵权行为(包括疏忽)还是其他原因引起的,即使一方或多方事先知道其可能性。

36


(iv) 各方明确保留在法律或衡平法上执行本托管协议条款的所有权利,但仅受本第 11 (a) 节中规定的限制的约束。

(b) 允许的依赖和弃权。托管代理人可以信赖并应受到充分保护,可以根据托管代理人善意认为是真实的、由适当的个人或实体签署或出示的任何通知或其他文件采取行动或不采取行动。除此处明确规定的义务或责任外,托管代理人不承担任何义务或责任。

(c) 独立承包商。Escrow Agent 是独立承包商,不是注册管理运行机构或 ICANN 的员工或代理人。
(d) 修正案。除非本协议各方签署另一项书面协议,否则不得修改或修改本托管协议。

(e) 分配。注册管理运行机构或 ICANN 均不得转让或转让本托管协议(通过合并、出售资产、法律运作或其他方式),但注册管理运行机构或 ICANN 的权利和义务应自动转移给其中一方在《注册管理机构协议》下的权利和义务的受让人。但是,除非托管代理收到有关各方变更的明确、权威和确凿的书面证据,否则托管代理在履行本托管协议时没有义务承认注册管理运行机构或ICANN的任何继任者或受让人。未经注册管理运行机构和 ICANN 事先书面同意,托管代理不得转让或转让本托管协议,不得无理拖延或拒不给予同意。

(f) 完整协议。本托管协议,包括本协议中的所有证物(如果有),取代了托管代理人与其他各方先前就此处所含事项进行的所有讨论、谅解和协议,构成了托管代理与其他各方之间就此处所考虑事项达成的完整协议。注册管理机构协议的附录 1 通过此引用成为本托管协议的一部分,并纳入此处。

(g) 对应方;适用法律。本托管协议可以在对应方中签署,每份协议在签订时均应被视为原始协议,所有协议合在一起构成相同的协议。本托管协议应受加利福尼亚州法律管辖,并根据加利福尼亚州法律进行解释,不考虑其法律冲突原则。除本协议另有明确规定外,所有各方还同意加利福尼亚州的属人管辖权,承认加利福尼亚州任何州和联邦法院的审理地点是适当的,同意在其中一个法院以适当方式提起与本托管协议相关的任何诉讼,并放弃其对上述任何内容已经或将来可能提出的任何异议。

(h) 通知。本托管协议要求或允许发出的所有通知、请求、要求或其他通信均应采用书面形式
37


并应通过提供收据的商业隔夜送达服务交付,或通过挂号邮件邮寄,要求退货收据,预付邮费。如果是亲自交付或通过商业隔夜送达服务交付,则通知、请求、指示或文件的交付日期应视为交付之日;如果通过邮件送达,则收到此类通知、请求、指示或文件的日期应视为交付之日。出于本托管协议的目的,任何一方均可根据本协议的规定向其他各方发出书面通知,更改其地址。

(i) 生存。本托管协议终止后,第 5、6、8、9、10 和 11 节将继续有效。

(j) 无豁免。本协议任何一方未行使任何权利、权力或任何一方拖延行使任何权利、权力或单一或部分行使任何权利、权力或补救措施均不妨碍任何其他或进一步行使这些权利、权力或补救措施,或任何其他权利、权力或补救措施的行使。本协议任何一方对本托管协议任何条款或条件中任何违反或违约行为的明确放弃或同意,均不构成对本协议相同或任何其他条款或条件中任何后续违反或违约行为的豁免或同意。

为此,各方已要求其正式授权官员自上述第一天和第一天起执行本托管协议,以昭信守。
[]
作者:_____________________
标题:___________________
打印名称:_______________________
地址:_____________________
            _____________________________
电话:_____________________
电子邮件:_____________________




VeriSign, Inc.

作者:_____________________
标题:___________________
打印名称:_______________________
地址:_____________________
        _____________________________
电话:_____________________
电子邮件:_____________________


38



互联网名称与数字地址分配机构

作者:_____________________
标题:___________________
打印名称:_______________________
地址:_____________________
        _____________________________
电话:_____________________
电子邮件:_____________________





39



.NET 注册管理机构协议附录 3
区域文件访问权限

image_2.jpg



1.第三方区域文件访问
1.1Zone 文件访问协议。注册管理运行机构将与任何互联网用户签订协议,这将允许该用户访问注册管理运行机构指定的一个或多个互联网主机服务器和下载区域文件数据。该协议将由集中区域数据访问提供商进行标准化、促进和管理,该提供商可以是 ICANN 或 ICANN 的指定人员(“CZDA 提供商”)。注册管理运行机构(可选择通过 CZDA 提供商)将根据本附录第 1.3 节提供对区域文件数据的访问权限,并使用本附录第 1.4 节所述的文件格式进行访问。尽管有上述规定,(a) CZDA 提供商可以拒绝任何不满足本附录第 1.2 节认证要求的用户的访问请求;(b) 注册管理运行机构可以拒绝任何未根据本附录第 1.2 节提供正确或合法凭据的用户的访问请求,或者注册管理运行机构有理由认为将违反本附录第 1.5 节的条款;以及,(c) 注册管理运行机构可以撤销任何用户的访问权限用户(如果注册管理运行机构有证据支持该用户有)违反了本附录第 1.5 节的条款。
1.2 认证要求。注册管理运行机构将在 CZDA 提供商的协助下,要求每位用户向其提供足以正确识别和定位用户的信息。此类用户信息将包括但不限于公司名称、联系人姓名、地址、电话号码、传真号码、电子邮件地址和 IP 地址。
1.3 授予访问权限。每个注册管理运营商(可选择通过 CZDA 提供商)将为 ICANN 指定和管理的 URL(具体而言,
.zda.icann.org 在哪里 是注册局负责的 TLD,用户可以访问注册局的区域数据档案。注册管理运行机构将授予用户非排他性、不可转让、有限的访问注册管理运行机构(可选 CZDA 提供商)区域文件托管的权利
40


服务器,并使用 SFTP 或 ICANN 可能规定的其他数据传输和访问协议,每隔 24 小时传输顶级域区域文件和任何相关的加密校验和文件的副本不超过一次。对于每个区域文件访问服务器,区域文件位于名为的顶级目录中 .zone.gz,和 .zone.gz.md5 和
.zone.gz.sig 用于验证下载。如果注册管理运行机构(或 CZDA 提供商)也提供历史数据,它将使用命名模式 -yyyymmdd.zone.gz 等
1.4 文件格式标准。注册管理运营商(可选通过 CZDA 提供商)将使用最初在 RFC 1035 第 5 节中定义的标准主文件格式的子格式提供区域文件,包括公共 DNS 使用的实际区域中存在的所有记录。子格式如下:
1. 每条记录必须在一行中包含所有字段,如:
.
2.Class 和 Type 必须使用标准助记符并且必须为小写。
3.TTL 必须以十进制整数的形式出现。
4. 允许在域名内部使用\ X 和\ DDD。
5. 所有域名必须为小写。
6. 必须仅使用一个制表符作为记录内字段的分隔符。
7. 所有域名必须完全合格。
8. 没有 $ORIGIN 指令。
9. 不使用 “@” 表示当前来源。
10. 不得在记录开头使用 “空白域名” 来继续使用前一条记录中的域名。
11. 没有 $INCLUDE 指令
12. 没有 $TTL 指令。
13. 不使用圆括号,例如,在记录中跨越直线边界继续列出字段列表。
14. 不使用评论。
41


15. 没有空行。
16. SOA 记录应出现在区域文件的顶部和(重复的)末尾。
17. 除 SOA 记录外,文件中的所有记录都必须按字母顺序排列。
18. 每个文件一个区域。如果 TLD 将其 DNS 数据划分为多个区域,则每个区域将分成一个单独的文件,如上所示,所有文件使用 tar 组合成一个名为的文件 .zone.tar。
1.5 用户对数据的使用。注册管理运行机构将允许用户将区域文件用于合法目的;前提是 (a) 用户采取一切合理措施防止未经授权的访问、使用和披露数据,以及
(b) 在任何情况下都不要求或允许注册管理运行机构允许用户将数据用于 (i) 允许、支持或以其他方式支持向用户现有客户以外的实体开展任何营销活动,无论使用何种媒介(此类媒体包括但不限于通过电子邮件、电话、传真、邮政、短信和无线向实体发送大量未经请求的商业广告或招标警报),
(ii) 启用大量自动化电子流程,向注册管理运行机构或任何 ICANN 认可的注册机构的系统发送查询或数据,或 (iii) 中断、干扰或干扰任何注册人的正常业务运营。
1.6 使用条款。注册管理运行机构将通过 CZDA 提供商为每位用户提供不少于三 (3) 个月的区域文件访问权限。注册管理运行机构将允许用户续订其访问授权。
1.7 不收取访问费。注册管理运营商将免费向用户提供区域文件的访问权限,CZDA提供商将为其提供便利。
42


2. 合作
2.1 援助。注册管理运行机构将合作并向 ICANN 和 CZDA 提供商提供合理的协助,以促进和维护本附录中规定的许可用户对区域文件数据的高效访问。

2.2 ICANN 访问权限。注册管理运行机构应按照 ICANN 可能不时合理规定的方式,持续向 ICANN 或其指定人员提供对 TLD 区域文件的批量访问权限。将至少每天提供访问权限。区域文件将包括尽可能接近世界标准时间 00:00:00 提交的 SRS 数据。
43


.NET 注册管理机构协议附录 4
注册管理运行机构的格式和内容
月度报告
image_2.jpg


注册管理运行机构应提供以下顶级域名月度报告,每份报告详见本附录:(1) 服务级别协议绩效报告;(2) 每份注册服务商交易报告;(3) 注册管理机构职能活动报告。服务等级协议绩效报告应通过电子邮件提交给 ICANN,发送至 。每个注册商的交易报告和注册管理机构职能活动报告应使用草稿-lozano-icann-registry-interfaces中描述的API提交给ICANN,请参阅 https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces(“注册管理机构接口规范”)。如果还没有 RFC,注册管理运行机构将使用自 2023 年 7 月 1 日起发布的《注册管理机构接口规范》的最新草案版本。2023 年 7 月 1 日之后,注册管理运行机构可以选择使用注册管理机构接口规范的更新版本。注册管理机构接口规范作为 RFC 发布后,注册管理运行机构将在发布后的一百八十 (180) 个日历日内实施 RFC 版本。
ICANN 将来可能会要求通过其他方式和使用其他格式提交报告。对于每份报告,ICANN 将采取合理的商业努力来保护所报告信息的机密性,直至报告所涉月底后的三 (3) 个月。除非本附录 4 中另有规定,否则任何提及特定时间均指协调世界时 (UTC)。月度报告应包含反映月底 (UTC) 登记册状态的数据。

1. 服务级别协议绩效报告。本报告应将服务等级协议要求与报告月份的实际绩效指标进行比较:(a)根据附录7第7.2节;(b)根据附录5B第3.2节,在RDAP加速期(定义见附录5B第3.5节)到期之后。

2. 每个注册商的交易报告。该报告应按照 RFC 4180 的规定以逗号分隔值格式的文件进行编译。该文件应命名为 “网络交易-yyyymm.csv”。该文件应包含每个注册商的以下字段:

44


字段 #
字段名
描述
01
注册商名称
注册商在 IANA 注册时的公司全名
02
iana-id
对于注册管理运行机构充当注册服务商(即不使用 ICANN 认可的注册服务商)的情况,应根据注册类型使用 9998 或 9999,否则应按照 https://www.iana.org/assignments/registrar-ids 中的规定使用主办注册服务商 IANA ID
03
域名总数
除 PendingCreate 以外,处于任何 EPP 状态的赞助域名总数,但尚未清除
04
域名服务器总数
与 TLD 注册但处于待创建状态但尚未清除的域名关联的域名服务器总数(主机对象或域名服务器主机作为域名属性)
05
净添加量 1 年
初始期限为一 (1) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
45


06
净添加量 2 年
初始期限为两 (2) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
07
net-adds-3 年
初始期限为三 (3) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
08
净添加 4 年
初始期限为四 (4) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
09
5 年净添加量
初始期限为五 (5) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
10
净添加量 6 年
初始期限为六 (6) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
46


11
net-adds-7 年
初始期限为七 (7) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
12
8 年净添加量
初始期限为八 (8) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
13
net-adds-9 年
初始期限为九 (9) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
14
10 年净添加量
初始期限为十 (10) 年(且未在添加宽限期内删除)成功注册(即未处于 EPP 待定创建状态)的域名数量。交易必须在添加宽限期结束的当月报告。
15
净续订 1 年
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为一 (1) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
47


16
净续订 2 年
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新的续订期为两 (2) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
17
净续订 3 年
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为三 (3) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
18
净续订 4 年
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新的续订期为四 (4) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
19
5 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为五 (5) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
48


20
6 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为六 (6) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
21
7 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为七 (7) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
22
8 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为八 (8) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
49


23
9 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为九 (9) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
24
10 年净续订
自动或命令成功续订(即未处于 EPP 待续订状态)的域名数量,新续订期为十 (10) 年(且未在续订或自动续订宽限期内删除)。交易必须在续订或自动续订宽限期结束的当月报告。
25
转账成功获得
该注册商发起的已成功完成(明确或自动批准)且未在转移宽限期内删除的域名转移数量。交易必须在转移宽限期结束的当月报告。
26
转会获得 nacked-nacked
该注册商发起但被其他注册商拒绝的域名转移数量(例如,EPP 转移 op= “reject”)
27
传输-丢失-成功
由其他注册商发起并成功完成(明确或自动批准)的域名转移数量
50


28
转会失败了
由另一注册商发起但该注册商拒绝的域名转移数量(例如,EPP 转移 op= “reject”)
29
转会争议赢了
该注册商占上风的转让争议数量(在裁决作出的当月报告)
30
转账争议已丢失
该注册商丢失的转让争议数量(在裁决发生的当月报告)
31
转让有争议无决定
涉及该注册服务商但有分歧或未作决定的转让争议数量(在裁决当月报告)
32
已删除域名 grace
在添加宽限期内删除的域名(不包括处于 EPP 待定创建状态时删除的域名)。必须在姓名被清除的当月报告删除情况。
33
已删除的域名 nograce
在添加宽限期之外删除的域名(不包括处于 EPP 待定创建状态时删除的域名)。必须在姓名被清除的当月报告删除情况。
34
恢复的域名在报告期内恢复的域名
35
已恢复-无报告
注册局要求提交还原报告但注册商未能提交还原报告的已恢复名称总数
36
agp 豁免申请
AGP(添加宽限期)豁免请求总数
37
已授予 agp 豁免
批准的 AGP(添加宽限期)豁免请求总数
51


38
agp 豁免域名
受已批准的 AGP(增加宽限期)豁免请求影响的名称总数
39
尝试添加
尝试的(成功和失败)域名创建命令的次数
40
合并交易天数
通过合并/同步交易添加到所有域名的到期日期的总天数。必须在交易发生的当月在此处报告合并/同步交易的天数。
41
合并交易
合并/同步交易总数。交易必须在交易发生的当月报告。

第一行应包含与上表中所述完全相同的字段名称,如 RFC 4180 第 2 节所述,作为 “标题行”。每份报告的最后一行应包括所有注册服务机构每栏的总数;该行的第一个字段应为 “总计”,而该行的第二个字段应留空。除上述行以外,不得包括任何其他行。换行符应为 如 RFC 4180 中所述。

3. 注册表职能活动报告。该报告应按照 RFC 4180 的规定以逗号分隔的值格式文件编译。该文件应命名为 “net-activity-yyyymm.csv”。该文件应包含以下字段:

字段 #
字段名
描述
01
运营注册商
报告期结束时生产系统中运营登记员的数量
52


02
zfa-密码
报告期结束时活动区域文件访问密码的数量;如果使用集中区域数据服务 (CZDS) 向最终用户提供区域文件,则可以使用 “CZDS” 代替活动区域文件访问密码的数量
03
whois-43 查询
报告期内回复的 WHOIS(端口 43)查询数量;如果在该日期之后未提供 WHOIS(端口 43)服务,则在 WHOIS 服务终止日期(定义见附录 5A)之后,应使用空值
04
web-whois查询
报告期内回复的基于 Web 的 WHOIS 查询数量,不包括可搜索的 WHOIS;如果在该日期之后未提供基于 WHOIS 的服务,则应在 WHOIS 服务终止日期之后使用空值
05
可搜索的 whois 查询
报告期内回复的可搜索 WHOIS 查询的数量;如果在报告期内未提供可搜索的 WHOIS 服务,则应使用空值
06
dns-udp 查询已收到
报告期内通过 UDP 传输收到的 DNS 查询数量
07
dns-udp 查询已响应
报告期内通过 UDP 传输收到的得到回复的 DNS 查询的数量
08
dns-tcp 查询已收到
报告期内通过 TCP 传输收到的 DNS 查询数量
09
dns-tcp 查询已响应
在本报告所述期间,通过 TCP 传输收到并得到回复的 DNS 查询的数量
53


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 还原报告
报告期内回复的 SRS(EPP 和任何其他接口)域名 RGP “恢复” 请求的数量,提供还原报告
16
srs-dom-rgp 还原请求
报告期内回复的 SRS(EPP 和任何其他接口)域名 RGP “恢复” 请求的数量
17
srs-dom 转移批准
报告期内回复的批准转移的 SRS(EPP 和任何其他接口)域名 “转移” 请求的数量
54


18
srs-dom-转移-取消
报告期内回复的取消转移的 SRS(EPP 和任何其他接口)域名 “转移” 请求的数量
19
srs-dom 转移查询
报告期内回复的 SRS(EPP 和任何其他接口)域名 “转移” 请求的数量
20
srs-dom-传输-拒绝
报告期内回复的拒绝转移的 SRS(EPP 和任何其他接口)域名 “转移” 请求的数量
21
srs-dom 转移请求
报告期内回复的 SRS(EPP 和任何其他接口)域名 “转移” 请求转移请求的数量
22
srs-dom-update
报告期内回复的 SRS(EPP 和任何其他接口)域名 “更新” 请求(不包括 RGP 恢复请求)的数量
23
srs-host-check
报告期内回复的 SRS(EPP 和任何其他接口)主机 “检查” 请求的数量
24
srs-host-创建
报告期内回复的 SRS(EPP 和任何其他接口)主机 “创建” 请求的数量
55


25
srs-host-删除
报告期内回复的 SRS(EPP 和任何其他接口)主机 “删除” 请求的数量
26
srs-host-info
报告期内回复的 SRS(EPP 和任何其他接口)主机 “信息” 请求的数量
27
srs-host-更新
报告期内回复的 SRS(EPP 和任何其他接口)主机 “更新” 请求的数量
28
srs-cont-check
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “检查” 请求的数量
29
srs-cent-create
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “创建” 请求的数量
30
srs-cont-delet
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “删除” 请求的数量
31
srs-cont-info
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “信息” 请求的数量
32
srs-cont-transfer-a
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “转移” 批准转账请求的数量
56


33
srs-cont-transfer-c
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “转移” 请求的数量
34
srs-cont-transfer 查询
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “转移” 查询转账请求的数量
35
srs-cont-transfer-re
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “转移” 请求的数量
36
srs-cont-transfer-请求
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “转移” 请求的数量
37
srs-cont-updat
报告期内回复的 SRS(EPP 和任何其他接口)联系人 “更新” 请求的数量
38
rdap 查询
报告期内回复的 RDAP 查询数量。

第一行应包含与上表中所述完全相同的字段名称,如 RFC 4180 第 2 节所述,作为 “标题行”。除上述行以外,不得包括任何其他行。换行符应为 如 RFC 4180 中所述。

对于属于单实例共享注册系统的 TLD:(1) 注册局职能活动报告中的 whois-43 查询、web-whois-queries、searchable-whois-queries 和 rdap-queries 字段应与单实例共享注册系统中报告的域名查询总和相匹配,以及
57


注册管理运行机构可以灵活选择如何使用单实例共享注册管理系统在各顶级域中分配这些查询,(2) 如果与上述 (1) 中的字段相关的查询,而注册管理运行机构无法确定要计算查询的顶级域名(例如,注册管理机构在多个共享相同的 RDAP 基本 URL 的顶级域中运营的注册商查询查询),则注册管理运行机构可以灵活地选择如何分配这些查询使用单实例共享注册系统的 TLD,以及 (3) 注册局职能活动报告可能包括系统中所有顶级域的联系人或主机交易总额。

58



.NET 注册管理机构协议附录 5A
注册数据发布服务
规格

image_1a.jpg

A. 定义。

i. 注册数据目录服务。注册数据目录服务或 “RDS” 是指 WHOIS 数据目录服务(定义见本附录 5A)和 RDAP 目录服务的集合,定义见附录 5B。

二。WHOIS 数据目录服务WHOIS 数据目录服务是指根据 RFC 3912 通过端口 43 提供的 WHOIS 服务的集合,以及一项基于 Web 的 WHOIS 服务,该服务提供基于公共查询的免费注册数据访问权限。

三。WHOIS服务终止日期.WHOIS 服务终止日期是指《2023 年注册管理机构协议全球修正案》第 20 节所定义的 WHOIS 服务终止日期,该修正案修订了规范 4 第 1.1.6 节,前提是 ICANN 和注册管理运行机构可以共同同意推迟 WHOIS 服务的终止日期。如果 ICANN 或注册管理运行机构希望讨论推迟 WHOIS 服务终止日期,ICANN 或注册管理运行机构(如适用)应向另一方提供书面通知,其中应以合理的细节说明延期提议。

1.WHOIS 数据目录服务。在 WHOIS 服务终止日期之前,注册管理运行机构将根据 RFC 3912 运营通过端口 43 提供的 WHOIS 服务,并在以下地址运营基于 WHOIS 的服务 以以下格式提供对至少以下元素的基于公共查询的免费访问权限。
1.1. 答复的格式应遵循下文概述的半自由文本格式,然后是空行和法律免责声明,说明注册管理运行机构和查询数据库的用户的权利。
1.2. 每个数据对象应表示为一组键/值对,各行以键开头,后接冒号和空格作为分隔符,然后是值。
1.3. 对于存在多个值的字段,应允许使用具有相同键的多个键/值对(例如列出多个域名服务器)。空行之后的第一个键/值对应被视为新记录的开始,应被视为
59


识别该记录,用于将诸如主机名和 IP 地址或域名和注册人信息之类的数据组合在一起。
1.4. 以下指定的字段规定了最低输出要求。注册管理运行机构必须仅实施注册管理机构注册数据目录服务一致标签和显示政策(https://www.icann.org/ resources/pages/rdds-labeling-policy-2017-02-01-en)中与运营的顶级域类型相关的部分,例如 “详尽” 或 “精简” 注册管理机构模式(例如,不包括来自任何联系人的信息:注册人、管理员、技术、账单等)。自生效之日起,.net TLD 被视为 “精简” 注册管理模式。
1.5. 域名数据
1.5.1 查询格式:whois EXAMPLE.TLD
1.5.2 响应格式:
域名:EXAMPLE.TLD
注册域名 ID:D1234567-TLD
注册商 WHOIS 服务器:whois.example.tld
注册商网址:http://www.example.tld
更新日期:2009-05-29T 20:13:00 Z
创建日期:2000-10-08T 00:45:00 Z
注册表到期日期:2010-10-08T 00:44:59 Z
注册服务商注册到期日期:2010-10-08T 00:44:59 Z11
注册商:示例注册商有限责任公司
注册商 IANA ID:5555555
注册商滥用行为联系人电子邮件:email@registrar.tld
注册服务商滥用联系电话:+1.1235551234
经销商:示例 RESELLER12
域名状态:禁止用户删除
域名状态:ClientRenRewObrib
域名状态:禁止客户转移
域名状态:禁止服务器更新
注册注册人 ID:5372808-ERL
注册人姓名:示例注册人
注册人组织:示例组织
注册人街道:范例街 123 号
注册人城市:ANYTOWN
注册州/省:美联社
注册人邮政编码:A1A1A1
注册人国家:EX
注册人电话:+1.5555551212
注册人电话分机:1234
1 字段是可选字段。
2 字段是可选的。
60



注册人传真:+1.5555551213
注册人传真分机:4321
注册人电子邮件:EMAIL@EXAMPLE.TLD
注册管理员 ID:5372809-ERL
管理员名称:注册人管理示例
管理组织:示例注册人组织管理街:123 EXAMPLE STREET
管理城市:ANYTOWN
管理州/省:美联社
管理员邮政编码:A1A1A1
管理国家:EX
管理员电话:+1.5555551212
管理员电话分机:1234
管理员传真:+1.5555551213
管理员传真分机:
管理员电子邮件:EMAIL@EXAMPLE.TLD
注册局技术 ID:5372811-ERL
技术名称:注册商技术示例
科技组织:示例注册商有限责任公司科技街:123 EXAMPLE STREET
科技城:ANYTOWN Tech 州/省:AP Tech 邮政编码:A1A1A1 科技国家:EX
科技电话:+1.1235551234 科技电话分机:1234
科技传真:+1.5555551213
科技传真分机:93
科技邮箱:EMAIL@EXAMPLE.TLD
域名服务器:NS01.EXAMPLE REGISTRAR.TLD
域名服务器:NS02.EXAMPLEREGISTRAR.TLD
DNSSEC:签署的代表团
DNSSEC:未签名
ICANN Whois 不准确投诉表的网址:https://www.icann.org/wicf/
>>> WHOIS 数据库的最后更新:2009-05-29T 20:15:00 Z
1.6.注册商数据
1.6.1查询格式:whois “注册商示例注册商公司”
1.6.2 响应格式:
注册商:示例 Registrar, Inc.
街道:金钟道1234号
城市:玛丽娜德尔雷州/省:加利福尼亚州邮编:90292 国家:美国
电话号码:+1.3105551212
传真号码:+1.3105551213
电子邮件:registrar@example.tld
61


注册商 WHOIS 服务器:whois.example-registrar.tld
注册商网址:http://www.example-registrar.tld 管理员联系人:Joe Registrar
电话号码:+1.3105551213
传真号码:+1.3105551213
电子邮件:joeregistrar@example-registrar.tld
管理员联系人:Jane 注册员
电话号码:+1.3105551214
传真号码:+1.3105551213
电子邮件:janeregistrar@example-registrar.tld 技术联系人:John Geek
电话号码:+1.3105551215
传真号码:+1.3105551216
电子邮件:johngeek@example-registrar.tld
>>> WHOIS 数据库的最后更新:2009-05-29T 20:15:00 Z
1.7. 域名服务器数据:
1.7.1 查询格式:whois “域名服务器(域名服务器名称)” 或 whois “域名服务器(IP 地址)”。例如:whois “域名服务器 NS1.EXAMPLE.TLD”。
1.7.2 响应格式:
服务器名称:NS1.EXAMPLE.TLD IP 地址:192.0.2.123
IP 地址:2001:0 DB8:: 1
注册商:示例 Registrar, Inc.
注册商 WHOIS 服务器:whois.example-registrar.tld
注册商网址:http://www.example-registrar.tld
>>> WHOIS 数据库的最后更新:2009-05-29T 20:15:00 Z
1.8. 以下数据字段的格式:域名状态、个人和组织名称、地址、街道、城市、州/省、邮政编码、国家、电话和传真号码(如上所示,扩展名将作为单独字段提供)、电子邮件地址、日期和时间应符合 EPP RFC 5730-5734 中规定的映射,以便可以统一显示这些信息(或在 WHOIS 响应中返回的值)已处理并理解。
2.RDS 政策和教育材料。注册管理运行机构应在顶级域的主网站(即提供给 ICANN 供其在 ICANN 网站上发布的网站)上提供指向 ICANN 指定的包含 RDDS 政策和教育材料的网页的链接。
62


3.可搜索性。为通过 RDDS 提供的注册数据提供可搜索功能是可选的,但如果由注册管理运行机构提供,则必须符合本节中描述的规范。
3.1.注册管理运营商将以网络服务形式提供可搜索性。
3.2. 注册运营商将为以下每个字段提供部分匹配功能:域名、联系人和注册人姓名以及联系人和注册人的邮政地址,包括 EPP 中描述的所有子字段(例如街道、城市、州或省等),并可能在其他字段提供部分匹配功能,在每种情况下均受适用法律约束。
3.3.注册管理运营商将至少在以下字段提供精确匹配功能:注册商 ID、域名服务器名称和域名服务器的 IP 地址(仅适用于注册局存储的 IP 地址,即粘合记录)。
3.4. 注册管理运营商将提供布尔搜索功能,至少支持以下逻辑运算符加入一组搜索条件:AND、OR、NOT。
3.5. 搜索结果将包括符合搜索条件的域名。
3.6. 注册管理运行机构将:1) 采取适当措施避免滥用此功能(例如,仅允许合法的授权用户访问);2)确保该功能符合所有适用的隐私法和 ICANN 共识政策和临时政策。
3.7.注册管理运行机构只能在RDAP目录服务中提供RDAP技术实施指南和RDAP响应概要中要求的可搜索功能,如附录5B第2.1节所述。
4.WHOIS 服务终止日期之后的 WHOIS 数据目录服务。注册管理运行机构可自行决定在 WHOIS 服务终止日期之后继续提供 WHOIS 数据目录服务。如果注册管理运行机构在 WHOIS 服务终止日期之后继续提供 WHOIS 数据目录服务,则以下要求将适用:
63


4.1 如果注册管理运行机构继续通过端口 43 提供 WHOIS 数据目录服务,则注册管理运行机构应按照 RFC 3912 提供该服务。
4.2注册管理运行机构应向IANA职能运营商提交变更申请,更新附录7第1.6节所述的过时或不准确的顶级域WHOIS记录。
4.3注册数据中包含的个人数据必须按照 ICANN 共识政策和临时政策进行编辑。
4.4如果注册管理运行机构选择添加数据字段,则注册管理运行机构必须遵守一致标签和显示共识政策中与附加字段相关的要求。
4.5 如附录 5B 第 1.4 节所定义,如果注册管理运行机构在 WHOIS 数据目录服务中提供的注册数据少于 RDAP 目录服务中提供的注册数据,则注册管理运行机构必须在 WHOIS 输出页脚中添加以下免责声明:“该服务中可用的注册数据是有限的。更多数据可在 https://lookup.icann.org 获得。”
64


4.6在 WHOIS 服务终止日期之后,如果 WHOIS 数据目录服务要求与共识政策或 WHOIS 服务终止日期之后生效的任何临时政策发生冲突,则以共识政策或临时政策为准,但仅限于冲突的标的并符合协议第 3.1 (b) 节(共识政策)。
4.7在 ICANN 董事会于 2019 年 5 月通过的《通用顶级域注册数据临时规范快速政策制定流程》第 1 阶段 GNSO 共识政策建议对共识性政策和程序进行更新并生效之前,此类政策中的以下术语将解释如下:
4.7.1 除 “可搜索的 Whois” 和 “Whois 联系人查询服务” 外,以下术语:“WHOIS”、“Whois”、“Whois 服务”、“可公开访问的 Whois” 及其变体应解释为指本附录中定义的 RDS。
4.7.2 “Whois 数据”、“WHOIS 信息”、“Whois 联系信息”、“WHOIS 查询数据”、“WHOIS 详细信息”、“Whois 输出”、“Whois 记录”、“Whois 输入” 及其变体应解释为指本附录中提及的注册数据。
4.8 与过渡研究合作。如果ICANN发起或委托进行一项关于将WHOIS数据目录服务过渡到RDAP目录服务的研究,注册管理运行机构应合理配合该研究,包括向进行此类研究的ICANN或其指定人员提供与其从WHOIS数据目录服务过渡到RDAP数据目录服务的经验相关的定量和定性数据。如果数据请求超出了注册管理运行机构在其正常运营过程中收集的数据,也超出了注册管理运行机构根据本协议必须收集和提供给 ICANN 组织的数据,则注册管理运行机构应自愿合作提供所请求的信息或向 ICANN 解释注册管理运行机构为何无法提供所请求的信息。本节的条款不要求注册管理运行机构向 ICANN 提供超出注册管理运行机构根据本协议其他部分有义务向 ICANN 提供的数据。根据本节向ICANN或其指定人员交付的任何被适当标记为机密的数据应被视为注册管理运行机构的保密信息,前提是尽管有协议,但如果ICANN或其指定人员汇总和匿名此类数据,ICANN或其指定人员可以向任何第三方披露此类数据。注册管理运行机构已提供数据的过渡研究完成后,ICANN 将销毁注册管理运行机构根据本节提供的未经汇总和匿名的所有数据。
65


5.ICANN 的批量注册数据访问权限
5.1定期访问精简注册数据。为了验证和确保注册管理机构的运行稳定性,分析 DNS 的运行稳定性并促进对经认证的注册服务机构的合规性检查,注册管理运行机构将每天向 ICANN 提供本第 5.1 节中规定的最新注册数据。数据将包括截至前一天 00:00:00 UTC 提交的数据。ICANN将每年发布前一年使用这些数据的研究项目摘要,以及与之共享原始数据进行研究的所有组织的清单。
5.1.1 内容。注册管理运营商将为所有注册域名提供以下数据:域名、域名存储库对象 ID (roid)、注册商 ID (IANA ID)、状态、上次更新日期、创建日期、到期日期和域名服务器名称。对于赞助注册商,注册管理运行机构将提供:注册商名称、注册商 ID (IANA ID)、注册商 WHOIS 服务器的主机名(在 WHOIS 服务终止日期之后可以省略此数据元素)和注册商的 URL。注册管理运行机构不得提供任何其他数据元素。
66


5.1.2 格式。数据将以附录 1 数据托管规范(包括加密、签名等)中指定的格式提供,但仅包括上一节中提到的字段,也就是说,该文件将仅包含具有上述字段的域名和注册商对象。
5.1.3 访问。注册管理运行机构将在 UTC 时间 00:00:00 之前准备好文件可供下载,以供 ICANN 检索。尽管ICANN将来可能会要求其他方式,但这些文件将由SFTP提供下载。
5.2出色地访问大量注册数据。本第 5.2 节仅在 TLD 作为 “详尽” 注册管理模式(如果有)运营之日或之后适用。如果注册服务商失败、取消认证、法院命令等导致其域名暂时或最终转让给其他注册商,应ICANN的要求,注册管理运行机构将向ICANN提供失败注册商域名的最新数据。数据将以附录 1 数据托管规范中规定的格式提供。该文件将仅包含与失败注册商的域名相关的数据。注册管理运行机构将在商业上可行的情况下尽快提供数据,但绝不迟于ICANN提出请求后的五 (5) 个日历日。除非注册管理运行机构和 ICANN 另行同意,否则 ICANN 将以与本附录第 5.1 节中规定的数据相同的方式提供文件供下载。

67


.NET 注册管理机构协议附录 5B
注册数据访问协议服务
规格
image_2.jpg

1. 范围和定义。

1.1。“附录 5B 生效日期” 是指 2023 年 7 月 1 日。

1.2    [保留的]

1.3。“注册数据访问协议” 或 “RDAP” 是一种互联网协议,它提供 “RESTful” 网络服务,用于从域名注册管理机构和区域互联网注册管理机构检索注册元数据。

1.4。“RDAP目录服务” 或 “RDAP-RDS” 是指附录5A中定义的注册数据目录服务,使用STD 95(https://www.rfc-editor.org/refs/ref-std95.txt)中描述的RDAP及其后续标准。
1.5。“RDAP-Query RTT” 是指从RDAP-RDS测试探测器的TCP连接开始到其结束的序列数据包的往返时间(“RTT”),包括仅接收一个HTTPS请求的HTTPS响应。如果 RTT 是相应的 SLR/性能规格的 5 倍或更多,则 RTT 将被视为未定义。
1.6。“RDAP 可用性” 是指 TLD 的 RDAP-RDS 服务使用来自相关注册系统的适当数据来回应互联网用户的查询的能力。如果有51%或更多的RDAP测试探测器在给定时间内认为RDAP-RDS服务不可用,则RDAP-RDS服务将被视为未得到答复。

1.7。“RDAP 更新时间” 是指从收到 EPP 确认到对域名、主机或联系人发出转换命令的时间,直到至少 51% 的可验证工作的 RDAP-RDS 测试探针检测到所做的更改。


2.RDAP 目录服务。

2.1注册管理运行机构应实施在 https://icann.org/gltd-rdap-profile 上发布的最新版本的RDAP技术实施指南和RDAP回应概况。注册管理运行机构将在ICANN发出通知后的一百八十 (180) 个日历日内实施新版本的《RDAP 技术实施指南》和《RDAP 回应概要》。

68


2.2注册管理运营商应为以下内容提供查询支持:

2.2.1 域信息,如 RFC 9082 的 “域路径分段规范” 部分所述。

2.2.2域名服务器信息,如 RFC 9082 的 “域名服务器路径段规范” 部分所述;但是,如果注册管理运行机构在 EPP 中将域名服务器指定为域名属性,则不要求注册管理运行机构(但仍可以选择)支持域名服务器查询。

2.2.3 注册商信息,如 RFC 9082 的 “实体路径分段规范” 部分所述。

2.2.4 帮助信息,如 RFC 9082 的 “帮助路径分段规范” 部分中所述。

3. 服务级别要求。注册管理运行机构应满足以下每项服务级别要求:

3.1 服务级别要求矩阵

参数
服务级别要求 (SLR) /性能规范(按月计算)
RDAP-RDS*RDAP 可用性
≤ 864 分钟的停机时间 (98%)
RDAP 查询 RTT
≤ 4000 毫秒,适用于至少 95% 的查询
RDAP 更新时间
≤ 60 分钟,用于至少 95% 的更新

*在 RDAP 升级期到期之前,这些 RDAP-RDS 的服务级别要求不是强制性的。
3.2. 注册运营商应使用威瑞信监控探测器监控和衡量其对上文第 3.1 节中规定的 RDAP-RDS 服务等级要求的表现,其唯一目的是:(a) 确定注册管理运行机构在计算注册服务商 SLA 积分(如果有)时使用 RDAP-RDS 服务的表现;以及 (b) 提供 RDAP
69


根据附录 4 第 1 节(服务级别协议绩效报告)向 ICANN 提供的服务级别要求绩效数据。

3.3.鼓励注册运营商在每个参数的流量统计较低的时间和日期维护RDAP。但是,没有为计划内停机或类似的不可用时间编列经费;任何停机,无论是维护还是系统故障导致的停机,都将仅记作停机时间,并计入服务级别要求的衡量目的。

3.3.1如果注册管理运行机构计划维护 RDAP,它将至少在维护前二十四 (24) 小时向 ICANN 紧急运营部门发出通知。ICANN 的紧急运营部门将记录计划维护时间,并在预期的维护中断期间暂停受监控服务的紧急上报服务。

3.4. 对于未能满足第 3.1 节中规定的 RDAP 服务级别要求的补救措施应等同于本协议中针对未能满足 WHOIS 服务相应性能规范的补救措施,但前提是 (i) 如果在 WHOIS 服务截止日期之前的给定月份内 RDAP 服务和WHOIS服务出现故障,注册服务商的服务级别协议积分(如果适用)不得超过总金额完全归因于 WHOIS 服务级别要求未达到 SLA 积分的百分比服务,根据注册管理运行机构协议;以及 (ii) 自 WHOIS 服务终止之日起,附录 7 中规定的 WHOIS 服务的性能规格以及因附录 10 中规定的 WHOIS 服务等级要求失败而产生的 SLA 积分不适用,也没有进一步的效力;但是,SLA 积分归因于 RDAP 的 RDAP 服务等级要求的失败就好像附录10中规定的服务一样,将在之后继续完全有效WHOIS服务终止日期.

3.5. 关于第 3.1 节中确定的服务级别要求,注册管理运行机构不得因在附录 5B 生效日期(“RDAP 加速期”)后的前 180 天内未能满足这些服务级别要求而被视为违反了此类服务级别要求,包括在 SLA 积分方面。

3.6. 双方同意,上文第 3.4 节所述的 SLA 抵免额是可以向注册管理运行机构评估的抵免额、罚款和/或负债总额,也是注册管理运行机构未能满足 RDAP-RDS 服务等级要求时注册服务商可以获得的唯一补救措施。

70


3.7.注册运营商将在不可抗力事件终止后的24小时内采取商业上合理的努力恢复RDAP-RDS服务功能。就附录 7 或服务级别要求而言,不可抗力造成的中断不被视为服务不可用。
3.8. 如果注册管理运行机构因遵守生效日期之后制定的任何共识性政策而未能满足 RDAP 服务的服务级别要求,则注册管理运行机构不对任何抵免额或罚款向ICANN或注册服务机构承担任何责任,也不会被视为违反了协议规定的任何义务,但前提是商业上合理的努力无法满足RDAP服务的服务水平要求查看注册管理运行机构对此类共识政策的遵守情况。

3.9. 本附录 5B 第 3 节中对 RDAP-RDS 服务规定的服务级别要求以及本附录 5B 第 4.5 节中规定的 RDAP 服务测量参数应被视为 “性能规范”,就本协议而言,“RDAP-RDDS” 服务应被视为 “系统服务”,应视为附录 7 中规定的服务。

3.10. 为了确定适当的信用等级以及由于注册管理运行机构未能满足服务水平要求而计算服务级别协议抵免额,信用等级和计算应基于下表中列出的等效参考并符合本协议。

RDAP-RDS 服务级别要求用于计算 SLA 信用等级的等效参考
RDAP 可用性服务可用性--Whois
RDAP 查询 RTT处理时间--Whois 查询
RDAP 更新时间更新频率--Whois

3.11.在RDAP上调期之后,附录7第8.1节中由亏损的注册商在部分投资组合收购后的批量转让中提供的通知要求应包括描述此类批量转让发生后RDDS记录将如何变化。
4.RDAP 测量参数。
4.1.RDAP 测试。表示向 RDAP-RDS 服务其中一台服务器的特定 IP 地址发送一个查询。查询应针对登记系统中的现有对象,答复必须包含相应的信息,否则将考虑查询
71


未答复的。RTT 比相应的 SLR 高 5 倍的查询将被视为未答复。RDAP 测试的可能结果是:一个以毫秒为单位的数字,对应于 RDAP 查询 RTT 或未得到答复。

4.2. 测量 RDAP 参数。每隔5分钟,每个RDAP-RDS探测器将从受监控的顶级域名RDAP-RDS服务的服务器的所有公共DNS注册 “IP地址” 中选择一个IP地址,并进行 “RDAP测试”。如果 RDAP 测试结果未得到答复,则在进行新的测试之前,该探测器将认为相应的 RDAP-RDS 服务不可用。

4.3. 整理来自 RDAP-RDS 探测器的结果。在任何给定的测量周期内,有效测试有效的 RDAP-RDS 测试探针的最小数量为 10 个,否则测量结果将被丢弃并视为 “尚无定论”;在这种情况下,不会在 SLR 上标记任何故障。

4.4. 放置 RDAP-RDS 探头。ICANN 将采取商业上合理的努力,部署探测器,以测量 ICANN 每个地理区域中具有运营商级连接的数据中心的 RDAP 参数。

4.5. 无干扰。注册管理机构不得干扰测量探测器,包括对受监控服务的请求给予任何形式的优惠待遇。注册管理运行机构应对本附录中描述的测量测试做出回应,就像回应互联网用户提出的 RDAP 的任何其他请求一样。

4.6. 紧急升级。出于本节的目的,注册管理运行机构和 ICANN 应向另一方提供各自紧急业务部门的联系信息,注册管理运行机构和 ICANN 应随时维护和更新此类联系信息。ICANN 应发布紧急升级通知,向注册管理运行机构通报与受监控的 RDAP-RDS 服务相关的任何可能或潜在的问题。紧急上报通知发布后,注册管理运行机构和 ICANN 应合作并采取商业上合理的努力来诊断和/或解决已发现的问题,包括共享适当的测量数据。启动任何紧急情况上报以及随后合作诊断和/或解决已发现的问题,其本身并不意味着或以其他方式确定受监控的 RDAP-RDDS 服务未达到上文第 3.1 节中规定的适用服务级别要求。


5。ICANN 保留通过适用的 IETF 流程就所引用的注册数据指定批准为 “互联网标准”(而不是信息或实验标准)的替代格式和协议的权利
72


在附录 5A 和附录 5B 中。根据此类规定,ICANN 应:(a) 与注册管理运行机构、其他 gTLD 注册管理机构以及 ICANN 认证的注册服务机构合作,确定实施适用标准所需的所有运营要求;(b) 如果适用,启动与注册管理运行机构的协商,以确定所有报告要求(如果有),以及与处境相似且适用于 TLD 的合理服务级别要求。

73


.NET 注册管理机构协议附录 6
保留名称一览表
image_6a.jpg

除非 ICANN 另有明确的书面授权,否则注册管理运行机构应保留在 TLD 内初始(即续期除外)注册时使用以下标签组成的名称:

A. 所有级别均保留标签。以下名称应保留在注册管理运行机构注册的 TLD 中的第二级和所有其他级别:

与 ICANN 相关的名称:
所以
gnso
ICANN
内部的
ccnso
与 IANA 相关的名字:
afrinic
惊慌失常
arin
示例
gtld 服务器
iab
伊安娜

iana服务器
iesg
ief
74


irtf
istf
简洁的
拉丁美洲的
rfc 编辑器
成熟
根服务器

B. 其他二级预订。此外,以下名称应保留在第二级:

所有单字符标签。

最初应保留所有双字符标签。在注册管理运行机构与政府和国家/地区代码管理机构或 ISO 3166 维护机构达成协议的情况下,保留的两个字符的标签字符串应予以释放。注册管理机构还可根据其为避免与相应的国家代码混淆而采取的措施提议解除这些保留。

C. 带标签的域名。所有在第三和第四个字符位置带有连字符的标签(例如,“bq--1k2n4h4b” 或 “xn--ndk061n”)

D. 注册管理机构业务的二级保留意见。以下名称保留用于注册管理机构顶级域名注册机构的运作。它们可以由注册管理运行机构使用,但在注册管理运行机构被指定为注册管理机构 TLD 的注册管理机构运营商后,它们应按照 ICANN 的规定进行转移:

不错的 whois
万维网
75



.NET 注册管理机构协议附录 7 功能和性能规范
image_2.jpg

    
注册管理机构顶级域的这些功能规范由以下部分组成:

1. 标准合规性;
2. 支持的初始和续订注册期;
3. 宽限期政策;
4. 通配符禁令;
5. 补丁、更新和升级政策;
6. 性能规范;
7. 双方的责任;以及
8. 附加服务

1. 标准合规性

1.1DNS。注册管理运行机构应遵守现有的相关RFC以及互联网工程任务组(IETF)将来发布的RFC,包括与RFC 1034、1035、1123、1982、2181、2182、3226、3596、3597、4343、5966和6891的域名和域名服务器运营有关的所有后续标准、修改或增补。只有当 DNS 标签以 ASCII 编码(例如 “xn--ndk061n”)表示有效的 IDN(如上所述)时,它们才能在第三和第四位置包含连字符。
1.2EPP。注册管理运行机构应遵守现有的相关RFC以及互联网工程任务组(IETF)将来发布的RFC,包括与使用可扩展配置协议(EPP)配置和管理域名有关的所有后续标准、修改或增补,这些标准符合RFC 5910、5730、5731、5732(如果使用主机对象)、5733和5734。尽管有上述规定,但此处的任何内容均不要求注册管理运行机构遵守附录 7 第 1.2 节中与 EPP 相关的信息 RFC。如果注册管理运行机构实施注册管理机构宽限期 (RGP),它将遵守 RFC 3915 及其后续协议。如果注册管理运行机构需要使用基本 EPP RFC 之外的功能,则注册管理运行机构无需向 IETF 提交有文件的 EPP 扩展,但注册管理运行机构必须按照 RFC 3735 中描述的指导方针,以互联网草稿格式记录 EPP 延期。注册管理运行机构将在部署之前提供和更新ICANN支持的所有 EPP 对象和扩展的相关文档。
1.3DNSSEC。注册管理运行机构应签署其实施域名系统安全扩展(“DNSSEC”)的 TLD 区域文件。为毫无疑问,注册管理运营商应签署的区域文件 以及用于 TLD DNS 服务器的辖区内粘合剂的区域文件。在期限内,注册管理运行机构应
76



遵守 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.4IDN。如果注册管理运行机构提供国际化域名(“IDN”),则应遵守RFC 5890、5891、5892、5893及其后续域名。注册管理运行机构应遵守 ICANN IDN 指南,网址为
https://www.icann.org/en/topics/idn/implementation-guidelines.htm,因为它们可能会不时被修改、修改或取代。注册管理运行机构应在 IANA IDN 惯例资料库中发布并不断更新其 IDN 表格和 IDN 注册规则。
1.5IPv6。注册管理运行机构应能够接受 IPv6 地址作为其注册系统中的粘合记录,并将其发布在 DNS 中。注册管理运行机构应至少为根区域中列出的两台注册管理机构域名服务器提供公共 IPv6 传输,这些域名服务器具有在 IANA 注册的对应 IPv6 地址。注册管理运行机构应遵守 BCP 91 中所述的 “DNS IPv6 传输操作指南” 以及 RFC 4472 中描述的建议和注意事项。除IPv4传输外,注册管理运行机构还应为其注册数据目录服务提供公共IPv6传输,如本协议附录5A中所定义;例如WHOIS(RFC 3912)、基于网络的WHOIS和RDAP。注册管理运行机构应在收到愿意通过 IPv6 使用 SRS 的 gTLD 认证注册服务商的第一份书面请求后的六 (6) 个月内向任何注册服务商提供其共享注册系统 (SRS) 的公共 IPv6 传输。
1.6IANA 根区数据库。为了确保有关 TLD 的权威信息保持公开状态,注册管理运行机构应向 IANA 职能运营商提交变更申请,更新该顶级域的 RDAP 目录服务记录中任何过时或不准确的 DNS、WHOIS 或 RDAP 基本 URL。注册管理运行机构应尽商业上合理的努力,在 RDAP 目录服务记录的任何此类 DNS、WHOIS 或 RDAP 基本 URL 过时或不准确之日起七 (7) 个日历日内提交任何此类变更请求。注册管理运行机构必须按照 https://www.iana.org/domains/root 中规定的程序提交所有变更申请。
1.7 网络入口过滤。注册管理运行机构应按照 BCP 38 和 BCP 84 的规定对其注册管理机构服务实施网络入口过滤检查,ICANN 也将实施这些检查。

77



2. 支持的初始和续订注册期

2.1注册名称的初始注册(如果根据功能规格和其他要求可用)可以在注册处进行,有效期最长为十年。

2.2注册名称的续期注册(如果根据功能规范和其他要求可用)可以在注册处进行,总期限不超过十年。

2.3根据《ICANN 注册服务商之间注册转移政策》第 A 部分,注册域名的注册担保权从一家注册服务商变更到另一家注册商后,注册域名的注册期限应延长一年,前提是截至赞助变更生效之日的最长注册期限不超过十年。

2.4根据《ICANN 注册服务商之间注册转移政策》第 B 部分,注册域名注册的担保权从一个注册服务商变更到另一个注册服务商,不会导致注册期限的延长,注册管理运行机构可以协助进行此类担保变更。

3.宽限期政策
本节介绍注册管理运行机构在 “宽限期” 和 “待处理” 期限方面的做法,包括在给定时间范围内发生的顺序操作之间的关系。宽限期是指注册管理机构运营后的指定日历天数,在此期间,可以撤销域名诉讼并向注册商发放抵免额。这方面的相关注册管理业务有:

•注册新域名,
•续订现有域名,
•自动续订现有域名;
•转让现有域名;以及
•删除现有域。

使用 EPP RENEW 命令或通过自动续订完成注册期的延长;使用 EPP CREATE 命令完成注册;使用 EPP DELETE 命令完成删除/删除;使用 EPP TRANSFER 命令完成移交;如果 ICANN 根据《ICANN 注册服务商之间注册转移政策》第 B 部分批准批量转让,则使用该部分规定的程序。使用 EPP UPDATE 命令完成恢复。

注册管理机构的共享注册系统提供五个宽限期:添加宽限期、续订/延长宽限期、自动续订宽限期、转移宽限期和赎回宽限期。

78



待处理期是指注册管理机构运作后的指定日历天数,在此期间,注册管理机构的最终行动在操作完成之前被推迟。注册管理机构在这方面的相关业务是:

•转移现有域名,
•删除现有域,以及
•在兑换宽限期内恢复域名。

3.1. 宽限期

3.1.1添加宽限期

添加宽限期是域名初始注册后的指定日历天数。所有注册商的添加宽限期的当前值为五个日历日。如果在五个日历日内执行 “删除”、“延期”(EPP Renew 命令)或转移操作,则适用以下规则:

删除。如果域名在添加宽限期内被删除,则在删除时的主办注册服务商将记入注册金额;但是,注册管理运行机构有权按照其《注册管理机构-注册服务商协议》的规定,就添加宽限期内不成比例的删除向注册服务商收取费用。该域名将从注册局数据库中删除,任何注册商都可以立即注册。有关重叠宽限期异常的描述,请参见第 3.2 节。

扩展(EPP 续订命令)。如果在添加宽限期内扩展了域名,则添加的积分不计入任何积分。根据注册商请求的延期操作的规定,域名注册的到期日按年数延长,总共最多十年。

转移(ICANN 批准的批量转移除外)。在 “增加宽限期” 期间,不得在 ICANN 注册服务商之间转移注册政策 A 部分下的转移,也不得在首次注册后的前 60 天内的任何其他时间进行。强制执行是担保域名注册的注册商的责任,由SRS执行。

批量转移(经 ICANN 批准)。根据 ICANN 注册服务商之间注册转移政策 B 部分中的程序,经过 ICANN 批准的批量转让可以在增加宽限期内进行。转让注册的到期日期不受影响。丢失的注册商账户将按初始添加金额收费。

3.1.2续订/延长宽限期

续订/延期宽限期是通过 EPP Command Renew 续订域名注册期续订/延长后的指定日历天数。续订/延期宽限期的当前值为五个日历日。如果
79



a 删除、延期或转移发生在这五个日历日内发生,以下规则适用:

删除。如果在续订/延期宽限期内删除域名,则在删除时,主办注册商将获得续订/延期费的抵免额。该域名立即进入赎回宽限期。有关重叠宽限期异常的描述,请参见第 3.2 节。
扩展(“EPP 命令 “续订”)。域名注册可以在续订/延期宽限期内最多延长十年。额外延期时担保书记官长的账户将按登记延期的延期年数收费。

转移(ICANN 批准的批量转移除外)。如果域名在续订/延期宽限期内转移,则没有积分。域名注册的到期日期延长一年,因延期而增加的年限最多可延长 10 年。

批量转移(经 ICANN 批准)。根据 ICANN 注册服务商之间注册转移政策 B 部分中的程序,经过 ICANN 批准的批量转让可以在续订/延期宽限期内进行。转让注册的到期日期不受影响。将向丢失的注册商账户收取续订/延期操作的费用。

3.1.3自动续订宽限期

自动续订宽限期是自动续订后的指定日历天数。如果域名注册未在到期日之前续订,则会自动续订;在这种情况下,注册将在到期日后的第一天由系统自动续订。自动续订宽限期的当前值为 45 个日历日。如果删除、延期或转移发生在自动续订宽限期内,则适用以下规则:

删除。如果在自动续订宽限期内删除域名,则在删除时,主办注册商将获得自动续订费用的抵免额。该域名立即进入赎回宽限期。有关重叠宽限期异常的描述,请参见第 3.2 节。

扩展。在自动续订宽限期内,域名最多可以延长十年。额外延期时担保书记官长的账户将按登记延期的延期年数收费。

转移(ICANN 批准的批量转移除外)。如果域名在自动续订宽限期内转移,则自动续订费用将记入失败的注册商,自动续订操作增加的年份将被取消。域名的到期日期延长一年,总共最多十年
80



而且即使由于最长注册期限为10年而没有增加一整年, 也要向新增的注册登记官收取额外一年的费用.

批量转移(经 ICANN 批准)。根据 ICANN 注册服务商之间注册转移政策 B 部分中的程序,经ICANN批准的批量转让可以在自动续订宽限期内进行。转让注册的到期日期不受影响。将向丢失的注册商账户收取自动续订费用。

81



3.1.4传输宽限期

根据 ICANN 注册服务商之间注册转移政策第 A 部分,转让宽限期是域名转让后的指定日历天数。转移宽限期的当前值为五个日历日。如果删除、延期或转移在该五个日历日内发生,则适用以下规则:

删除。如果域名在转移宽限期内被删除,则在删除时,主办注册商将获得转移费抵免。该域名立即进入赎回宽限期。有关重叠宽限期异常的描述,请参见第 3.2 节。

扩展。如果域名注册在转移宽限期内延长,则转移没有积分。将根据注册延期的年数向注册商的账户收费。根据注册商请求的延期操作的规定,域名注册的到期日期按年数延长,最长可延长十年。

转移(ICANN 批准的批量转移除外)。如果域名在转移宽限期内转移,则没有积分。域名注册的到期日延长一年,最长为十年。ICANN 关于注册服务商之间注册转移的政策不允许在另一次转让后的前 60 天内进行转移;注册服务商有责任执行这一限制。

批量转移(经 ICANN 批准)。根据 ICANN 注册服务商之间注册转移政策 B 部分中的程序,经过 ICANN 批准的批量转让可以在转让宽限期内进行。转让注册的到期日期不受影响。对于批量转移之前发生的转移操作,将向丢失的注册商账户收取费用。
3.1.5 批量传输宽限期

没有与批量传输操作相关的宽限期。批量转移完成后,任何相关费用均不予退还。

3.1.6赎回宽限期

当注册商要求删除不在添加宽限期内的域名时,域名将处于 REDEMPTIONPERIOD 状态。处于 REDEMPTIONPERIOD 状态的名称将不包含在区域文件中。注册商无法修改或清除处于 REDEMPTIONPERIOD 状态的域名。注册商在REDEMPTIONPERIOD中可以对域名采取的唯一行动是要求恢复该域名。任何其他注册商修改或以其他方式更新域名的请求都将被拒绝。除非恢复,否则该域名将在指定的日历天数内保持赎回期状态。此兑换期的当前长度为 30 个日历日。

3.2 重叠的宽限期
82




如果执行的操作属于多个宽限期,则适用于每个宽限期的操作(但有一些例外情况,如下所述)。

•如果在 “添加宽限期” 和 “延期” 宽限期内删除了域名,则考虑到注册和延期的年限,注册和延期金额将记入注册商账户。
•如果域名在延期宽限期内自动续订,然后延期,然后删除,则收取的自动续订费用和延期年数将记入注册商账户。

3.2.1 重叠异常

•如果域名注册在转让宽限期内延长,则将根据注册延期的年数向当前注册商的账户收费。

注意:如果对一个域名执行了多项计费操作(包括一次转移),并且该域名在每项操作的宽限期内被删除,则只有在最近一次转移(包括最近一次转移)之后执行的操作才会记入当前注册商。
3.3 待处理期

3.3.1转移待处理期

待转让期是注册商(注册商 A)提出域名转让请求后的指定日历天数,在该请求中,该域名的当前注册商(注册商 B)可以明确批准或拒绝转让请求。所有注册商的转移待处理期限的当前值为五个日历日。移交将在收到当前注册商(注册商 B)的明确批准或拒绝后完成。如果当前注册商(注册商 B)未明确批准或拒绝注册商 A 发起的请求,则注册管理机构将在转移待处理期结束后自动批准该请求。

在转移待处理期间:

.epp 传输请求或 EPP 续订请求被拒绝。
b.sync 不允许。
cepp 删除请求被拒绝。
d. 允许进行批量传输操作。
e.epp 更新请求被拒绝。

域名转移后,EPP 转移请求可能会在 60 天内被拒绝。

83



3.3.2待删除期

如果域名在兑换宽限期内未恢复,则该域名将处于 “待删除” 状态。处于 “待删除” 状态的名称将不包含在区域文件中。所有注册商修改或以其他方式更新处于 “待删除” 状态的域名的请求都将被拒绝。域名在处于 “待删除” 状态后,将在指定的日历天数内从注册数据库中清除。此待删除期限的当前长度为五个日历日。

84



4. 通配符禁令

对于未注册的域名,或者注册人未提供有效记录(例如在 DNS 区域文件中列出的 NS 记录),或者其状态不允许在 DNS 中发布的域名,禁止使用 RFC 1034 和 4592 中所述的 DNS 通配符资源记录,或者注册局禁止使用任何其他方法或技术来合成 DNS 资源记录或在 DNS 内使用重定向。当查询此类域名时,权威域名服务器必须返回 “名称错误” 响应(也称为 NXDOMAIN)、RFC 1035 中所述的 RCODE 3 以及相关的 RFC。本规定适用于注册管理运营商(或从事提供注册服务的关联公司)维护数据、安排此类维护或从此类维护中获得收入的域名树中所有级别的所有 DNS 区域文件,但本规定不适用于单一实体(包括其关联公司)为非关联第三方注册域名提供的域名服务或任何其他非注册服务,该域名或区域用于向非关联第三方提供域名注册服务以外的域名服务或任何其他非注册服务通过 ICANN 认可的注册服务商。

5. 补丁、更新和升级政策

注册管理运行机构可以定期对根据注册管理机构-注册商协议(“协议”)许可的软件、EPP 或 API(“许可产品”)发布补丁、更新或升级,以增强协议下的共享注册系统的功能或以其他方式改进。就附录 7 第 5 节而言,以下术语具有此处规定的相关含义。

5.1A “补丁” 是指注册运行机构在提供错误更正服务期间对许可产品所做的细微修改。补丁不构成版本。

5.2 “更新” 是指许可产品的新版本,其中可能包含错误更正、小幅改进,在某些情况下还包括重大增强,并由许可产品版本号小数点右侧数字的变化来表示。

5.3 “升级” 是指许可产品的新版本,其中涉及增加实质性或大幅增强的功能,并以许可产品版本中小数点左侧数字的变化来表示。

5.4A “版本” 是指由任何单一版本号标识的许可产品。

每次更新和升级都会导致版本更改。
*补丁不需要对每个注册商开发、实施和维护的客户应用程序进行相应的更改。
*更新可能需要每个注册商更改客户应用程序,以便利用新的特性和/或功能并继续访问共享注册系统。
85



*升级需要每个注册商更改客户应用程序,以便利用新的特性和/或功能,并继续访问共享注册系统。

注册管理运营商将自行决定在计划和宣布的共享注册系统维护期内部署补丁。

对于更新和升级,注册管理运行机构将在将更新和升级部署到生产环境之前通知每个注册商。通知应至少持续九十 (90) 天。此类通知将包括部署更新之前的初步通知,该更新要求更改客户端应用程序或升级到所有注册服务商都有权访问的运营测试和评估(“OT&E”)环境。注册管理运行机构将在 OT&E 环境中维护更新或升级至少三十 (30) 天,让每个注册商都有机会修改其客户应用程序并完成测试,然后再在生产环境中实施新代码。

本通知期不适用于以下情况:注册管理运行机构的系统面临即将发生的故障或重大安全威胁的威胁、发现重大安全漏洞或拒绝服务 (DoS) 攻击,注册管理运行机构的系统因以下情况而无法访问:

i) 数据流量过大
ii) 未经授权的流量
iii) 数据流量不符合注册局使用的协议

6. 性能规格

这些性能规范提供了一种衡量注册管理运行机构向注册管理机构顶级域提供的 SRS、DNS 域名服务器和 Whois 服务的方法,并作为附录 10 中规定的服务等级协议积分(“SLA 积分”)的基础。

6.1 定义。本第 6 节中使用但未另行定义的大写术语应具有《注册管理机构协议》中赋予它们的含义。

6.1.1 “核心互联网服务故障” 是指注册运营商无法控制的特殊且可识别的事件,该事件影响了根据下文第 6 节进行衡量的互联网服务。此类事件包括但不限于拥塞崩溃、分区、电网故障和路由故障。

6.1.2 “信用等级” 是指附录 10 第 2 节的 SLA 积分表中列出的信用等级,该表概述了注册管理运行机构可以评估的抵免额、罚款和/或负债总额,以及注册管理运行机构未能满足本附录 7 中列出的绩效规范的 ICANN 认证注册服务商可获得的唯一补救措施。

86



6.1.3 “DNS 域名服务器” 是指在注册管理运行机构所选服务器上的 TCP/UDP 端口 53 上提供的符合 RFC 1034、1035 和相关 RFC 的服务。

6.1.4 “ICANN 认可的注册服务商” 是指与注册管理运行机构签订了有效的《注册管理机构-注册服务商协议》的 ICANN 认可的注册服务商。

6.1.5 “每月时限” 是指以协调世界时 (UTC) 00点开始和结束的每个日历月。

6.1.6 “性能规格” 是指对特定系统服务的可衡量功能属性的描述。

6.1.7 “注册商社区” 是指与注册管理机构顶级域的注册管理运营商签订了有效的注册管理机构-注册商协议,并且在过去三十 (30) 个日历日内注册了超过 150 个净新.net 域名的所有 ICANN 认证注册服务商。

6.1.8 “往返” 是指参考查询从 SRS 网关通过 SRS 系统完整返回到 SRS 网关所花费的测量时间。

6.1.9 “服务等级协议 (SLA)” 指注册管理机构协议附录 10 所附的服务级别协议,概述了绩效标准水平。

6.1.10 “SRS” 指共享注册系统,该系统由注册管理运行机构通过定义协议 (EPP) 提供给注册服务商社区,用于注册管理机构与注册商之间的互动。具体而言,它指的是 ICANN 认可的注册服务商添加、修改和删除(创建、更新和删除)与注册域名和相关 DNS 名称服务器相关的信息的能力。
6.1.11 “系统服务” 是指已确定可用性和性能规格的注册管理机构顶级域的 SRS、DNS 域名服务器和 Whois 服务。

6.1.12 “Whois” 是指注册管理运行机构根据附录 5A 提供的 Whois 服务。

6.2。服务可用性。服务可用性定义为注册管理运行机构的系统服务分别响应其用户的时间(“服务可用性”),以分钟为单位,详见第 6.2.1 至 6.2.4 节。

6.2.1服务可用性的衡量标准如下:

服务可用性% = {[(MTM-POMU)-UOM]/(MTM-POMU)} *100 其中:

87



MTM = 每月时间框架分钟数,计算方法是该月的天数乘以 24 小时乘以 60 分钟。例如,一月份的 MTM 为 31 天 * 24 小时 * 60 分钟,或者 MTM = 44,640 分钟。

POMU = 已用计划停机分钟数等于每项单独系统服务的每月时间范围内计划停机(定义见下文第 6.3 节)或延长计划中断(定义见下文第 6.4 节)的分钟数。任何月度时间表均不得有计划内和延长计划内停机。

UOM = 计划外停机分钟数等于系统服务不可用的总分钟数,不包括该月时间范围内的任何计划内停机(定义见下文第 6.3 节)或计划外停机(定义见下文第 6.4 节)。

服务可用性计算应由注册管理运行机构计算,并报告每个月时间范围内的 SRS、Whois 和 DNS 域名服务器可用性的结果。对于按日历年衡量的服务可用性性能规范,在上述计算中,应使用年度时限分钟 (YTM) 取代每月时限分钟 (MTM)。年度时间框架分钟数计算为 365 天 * 24 小时 * 60 分钟 = 525,600 分钟。结果将通过电子邮件报告给注册服务机构社区,并根据附录4报告给ICANN。
6.2.2 服务可用性——每个日历年的 SRS = 99.99%。适用于 SRS 的服务可用性是指 SRS 回应通过 EPP 协议访问 SRS 的 ICANN 认证注册服务商的能力。除计划内停机(定义见下文第 6.3 节)和延长计划内停机(定义见下文第 6.4 节)外,SRS 的不可用性将作为计划外停机分钟数记录给注册管理运行机构。不可用性不包括任何影响当地个人 ICANN 认证注册服务商的事件。

适用于 SRS 的 SRS 不可用是指,由于 VeriSign 注册管理机构控制范围内的系统出现故障,ICANN 认可的注册服务商无法与 SRS 网关建立会话;但是,SRS 不可用不应包括 ICANN 认证的注册服务商无法与 SRS 网关建立会话,因为该网关超过其指定的会话次数。与 SRS 网关建立会话应定义为:

a) 成功完成 TCP 会话启动,

b) 成功完成 SSL 身份验证握手,以及

c) 成功完成可扩展配置协议 (EPP) 登录命令。

一旦 ICANN 认可的注册服务商按照注册管理运行机构要求的方式(即电子邮件、传真、电话)向注册管理运行机构的客户服务台报告某一事件,注册管理运行机构将记录 SRS 的不可用性。SRS 承诺的服务可用性为每个日历年 99.99%。SRS 服务可用性指标的信用等级为 2。
88




6.2.3 服务可用性——DNS 域名服务器 = 每个月的时间范围为 100%。适用于 DNS 域名服务器的服务可用性是指 DNS 域名服务器解析来自互联网用户的 DNS 查询的能力。DNS 域名服务器的不可用性将作为计划外停机分钟数记录给注册管理运营商。注册管理运行机构将记录 DNS 域名服务器的不可用性(a)当监控工具检测到此类不可用性时,或(b)一旦 ICANN 认可的注册服务商按照注册管理运行机构要求的方式(即电子邮件、传真、电话)向注册管理运行机构的客户服务台报告了事件,并且注册管理运行机构确认该事件并非报告注册机构独有的。
DNS 域名服务器不可用是指注册管理运行机构星座中只有不到八 (8) 个站点返回的查询答案在每月时间范围内平均丢包率低于 1% 或任意五分钟内丢包率低于 5%。

DNS 域名服务器的承诺服务可用性为每个月时间范围内的 100%。DNS 域名服务器服务可用性指标的信用等级为 1。

6.2.4服务可用性——Whois = 每个月的时间范围为 100%。适用于 Whois 的服务可用性是指互联网用户访问和使用 Whois 的能力。除计划内中断(定义见下文第 6.3 节)和延长计划内停机(定义见下文第 6.4 节)外,Whois 不可用将作为计划外停机分钟数记录给注册管理运行机构。注册管理运行机构将在以下情况下记录 Whois 不可用:(a) 当注册管理运行机构的监控工具检测到此类不可用性时,或 (b) 一旦 ICANN 认可的注册服务商按照注册管理运行机构要求的方式(即电子邮件、传真、电话)向注册管理运行机构的客户服务台报告情况。承诺的 Whois 服务可用性为每个月时间范围的 100%。Whois 服务可用性指标的信用等级为 2。

6.3 计划内停机。注册管理运行机构会不时要求停机以进行定期维护或增加新功能或功能(“计划内停机”)。

6.3.1 计划停机时间。计划中断持续时间定义了允许注册管理运行机构停止系统服务进行定期维护的最大允许时间(以分钟为单位)(“计划中断持续时间”)。计划内停机是提前计划的,在停机之前会向注册服务商社区发出通知。系统服务的计划中断时间如下所示:

(i) 计划停机时间-SRS = 每个月时间框架 45 分钟;

(ii) 计划中断持续时间-DNS 域名服务器 = 不允许计划内停机;以及

(iii) 计划停机持续时间-Whois = 不允许计划中断。

计划停机持续时间指标为信用等级 6。
89



6.3.2 计划停机时间框架。计划中断时间范围定义了计划内停机可能发生的时间和天数(“计划内停机时间范围”)。系统服务的计划中断时间表如下:

(i) 计划停机时间表——SRS = 世界标准时间星期日 0100-0900;

(ii) 计划中断时间框架-DNS 域名服务器 = 不允许计划中断;以及

(iii) 计划停机时间范围-Whois = 不允许计划中断。

计划停机时间范围指标为信用等级 5。

6.3.3计划中断通知。注册管理运行机构应将任何计划中断通知所有 ICANN 认证的注册服务商(“计划中断通知”)。计划中断通知应规定计划中断的日期和时间。注册管理运行机构应在计划中断前通知注册服务机构社区的天数如下:

(i) 计划停机时间-SRS = 一般维护 30 天,更新或升级 90 天,如本附录 7 第 5 节中的补丁、更新和升级政策所定义;

(ii) 计划中断时间框架-DNS 域名服务器 = 不允许计划中断;以及

(iii) 计划停机时间范围-Whois = 不允许计划中断。

计划中断通知指标的信用级别为 5。

6.4 延长计划内停机。在某些情况下,例如重大软件升级和平台更换,需要延长维护时间(“延长计划内停机”)。延长计划中断的频率将低于计划内中断的频率,但其持续时间可能会更长。

6.4.1延长计划停机时间。延长计划中断持续时间定义了允许注册管理运行机构因延长维护而停止系统服务的最大允许时间,以小时和分钟为单位(“延长计划停机时间”)。根据第 6.4.3 节,计划中的延长停机时间是提前规划的,并向注册服务商社区发出通知。延长计划停机时间可能与计划内停机不在相同的每月时间范围内。

系统服务的延长计划停机时间如下所示:

(i) 延长计划停机时间-SRS = 每个日历年 4 小时(240 分钟),每 3 年延长一次计划停机时间 8 小时(480)分钟;

90



(ii) 延长计划内停机时间-DNS 域名服务器 = 不允许延长计划内停机;以及

(iii) 延长计划停机时间-Whois = 不允许延长计划内停机。

延长计划停机时间指标的信用等级为 6。

6.4.2 延长计划停机时间。延长计划停机时间范围定义了延长计划中断可能发生的时间和天数(“延长计划停机时间范围”)。系统服务的延长计划停机时间表如下:

(i) 延长计划停机时限-SRS = 世界标准时间星期日 0100-1300;

(ii) 延长计划停机时间范围-DNS 域名服务器 = 不允许延长计划内停机;以及

(iii) 延长计划停机时间-Whois = 不允许延长计划停机。

延长计划停机时间范围指标为信用等级 5。

6.4.3延长计划内停机通知。注册管理运行机构必须将任何延长的计划中断通知注册服务机构社区(“延长计划中断通知”)。延长计划停机通知应规定延长计划停电的日期和时间。注册管理运行机构必须在计划中断延期之前通知经ICANN认证的注册服务商的天数如下:

(i) 延长计划停机时间-SRS = 90 天;

(ii) 延长计划停机时间范围-DNS 域名服务器 =不允许延长计划中断;以及
(iii) 延长计划停机时间-Whois = 不允许延长计划停机。

计划中断延期通知指标的信用等级为 5。

6.5 处理时间。处理时间是服务可用性的衡量标准,等于系统服务的往返行程(“处理时间”)。注册管理机构将记录所有协议事务(即检查、添加/创建、修改/更新和删除)的处理时间。处理时间将按月时间框架计算,并根据附录 4 每月向 ICANN 报告。如果所有 ICANN 认可的注册服务机构在每月时间范围内增加的协议交易总量(单独衡量)超过注册管理运行机构在之前的月度时间框架内的实际协议交易量超过 20%,则 ICANN 认可的注册服务商没有资格获得任何 SLA 抵免额,注册管理运行机构对于 ICANN 不承担任何责任,如果
91



注册管理运行机构未能满足本第 6.5 节中规定的处理时间性能规范。

6.5.1 处理时间——检查域 = 25 毫秒,保持 95%。

(i) Check Domain 的处理时间适用于通过注册管理机构与注册商互动的定义协议 (EPP) 访问的 SRS,并衡量特定域名可用性检查的处理时间。

(ii) Check Domain的性能规格为每月时间范围内95%的交易往返25毫秒。

Check Domain 的处理时间指标为信用等级 3。

6.5.2处理时间--添加/创建 = 50 毫秒,占比 95%。

(i) 添加/创建的处理时间适用于通过注册管理机构与注册商互动的定义协议 (EPP) 访问的 SRS,并衡量添加/创建与域名相关的交易的处理时间。

(ii) 对于每月时间范围内处理的 95% 的交易,添加/创建的性能规格为往返50毫秒。
“添加/创建” 指标的处理时间为信用等级 3。

6.5.3 处理时间--修改/更新和删除域 = 100 毫秒,持续 95%。

(i) 修改/更新和删除的处理时间适用于通过注册管理机构与注册商互动的定义协议 (EPP) 访问的 SRS,用于衡量与域名相关的修改/更新和删除交易的处理时间。

(ii) 对于每月时间范围内处理的 95% 的交易,修改/更新和删除的性能规格为往返100毫秒。

修改/更新和删除指标的处理时间为信用等级 3

6.5.4处理时间—— Whois 查询 = 5 毫秒,占比 95%。

(i) Whois 查询的处理时间适用于 Whois,用于衡量 Whois 查询的处理时间。

(ii) 在每月时间框架内,95% 的交易的 Whois 查询性能规格为 5 毫秒。也就是说,从 Whois 收到查询到做出响应,在每月时间框架内,95% 的交易将花费 5 毫秒或更短的时间。

Whois 查询的处理时间指标为信用等级 3。
92




6.5.5处理时间——DNS 域名服务器分辨率 = 100 毫秒,占比 95%。

(i) DNS 域名服务器解析的处理时间适用于 DNS 名称服务器,用于衡量 DNS 查询的处理时间。

(ii) 在每月时间框架内,95% 的交易的 DNS 域名服务器解析性能规格为 100 毫秒。也就是说,从域名服务器接收 DNS 查询到提供响应,在每月时间框架内,95% 的交易将花费 100 毫秒或更短的时间。

DNS 域名服务器指标的处理时间为信用等级 3。
6.6 更新频率。注册管理运行机构及时更新 DNS 域名服务器上的数据,Whois ICANN 认证的注册服务机构通过 SRS 记录这些更新。然后,SRS 会更新 DNS 域名服务器和 Whois。注册管理运行机构近乎实时地处理这些更新。

在 DNS 域名服务器和 Whois 更新频率方面,95% 的交易的承诺性能指标均为 3 分钟。也就是说,在每月时间框架内,95% 的 DNS 域名服务器和 Whois 更新将在 3 分钟内完成。更新频率是从注册管理运行机构确认更新到更新出现在 DNS 域名服务器和 Whois 中开始计算的。根据附录 4,更新频率绩效将按月向 ICANN 报告。

6.6.1 更新频率——DNS 域名服务器 = 3 分钟,在每月时间范围内达到 95%。

DNS 域名服务器的更新频率指标为信用等级 4。

6.6.2 更新频率——Whois

每月更新频率-Whois = 3 分钟,持续时间为 95%。Whois 的更新频率指标为信用等级 4。
6.7 跨网络域名服务器性能要求。DNS 域名服务器往返和互联网丢包是注册管理运行机构提供的服务质量的重要因素。但是,这些特征受互联网性能的影响,因此无法受到注册管理运行机构的严格控制。因此,这些要求不受附录 10 中规定的服务级别协议下的 SLA 积分约束的事项,也不是注册管理运行机构可能据以违反《注册管理机构协议》的义务。

93



跨网络域名服务器性能的承诺性能规格是测得的往返时间低于 300 毫秒,测得的数据包丢失率在每月时间范围内的平均值低于 1%,在每月时间范围内的任何五 (5) 分钟内均不超过 5%。ICANN 可按以下方式在自己选择的时间进行跨网络域名服务器性能测量:
6.7.1可以通过将来自不同测量位置的DNS请求包字符串发送到每个.net DNS名称服务器并观察来自.net DNS域名服务器的响应来进行测量。(这些请求和响应串被称为 “CNNP 测试”。)测量位置将分布在互联网上。

6.7.2每串请求数据包将由请求任意选择的.net 二级域名的域名服务器 (NS) 记录的 UDP 或 TCP 数据包组成,这些数据包经过预先选择以确保名称存在于注册局顶级域中且可解析。可以记录数据包丢失(即未收到的响应数据包的百分比)和收到的响应数据包的平均往返时间。

6.7.3为了满足特定 CNNP 测试的丢包和往返要求,必须满足以下三项要求:

6.7.3.1从每个测量位置到至少一个.net域名服务器的往返和丢包量不得超过要求的值;

6.7.3.2来自至少一个测量位置的每台.net域名服务器丢失的数据包不得超过要求的值;以及

6.7.3.3在已确定的核心互联网服务故障期间获得的任何未通过的 CNNP 测试结果均不予考虑。

6.7.4为确保测试样本的多样化,ICANN将在不同的时间(即一天中的不同时间以及一周中的不同日期)进行CNNP测试。只有当.net DNS 域名服务器未通过 CNNP 测试(参见上文第 6.7.3 节)且连续不少于三次 CNNP 测试失败时,注册管理运营商才能被视为持续未能满足跨网络域名服务器性能要求。

6.7.5 如果CNNP测试持续失败,ICANN将向注册管理运行机构发出书面失败通知(附有备份数据),注册管理运行机构将有六十天的时间来纠正失败。

6.7.6根据本条款开始测试前六十天,ICANN将为注册管理运行机构提供评估测试工具、测量地点和程序的机会,以供ICANN使用。如果注册管理运行机构不同意此类工具和程序,ICANN 将直接与注册管理运行机构合作进行必要的修改。
94



7. 双方的责任

7.1除 DNS 域名服务器性能测量外,注册管理运行机构将从内部系统进行监控,以此来验证本文档中的可用性和性能指标是否得到满足。

7.2注册管理运行机构将根据附录4每月通过电子邮件向注册服务商社群和ICANN提供系统性能和可用性报告。

7.3注册管理运行机构将提供附录 5A 中规定的 Whois 服务。

7.4注册管理运行机构将做出商业上合理的努力,在不可抗力事件终止后的24小时内恢复系统服务的关键系统,并在不可抗力事件终止后的48小时内恢复全部系统功能。就本附录 7 或 SLA 而言,因不可抗力而导致的中断不被视为服务不可用。

7.5注册管理运行机构不对ICANN或ICANN认可的注册服务商承担任何积分或罚款的责任,如果由于注册管理运行机构遵守此类共识政策而无法满足绩效规范,则注册管理运行机构不承担任何抵免额或罚款的责任,也不会被视为违反了注册管理机构协议规定的任何义务。

7.6 缓解滥用

7.6.1滥用联系方式。注册管理运行机构应向 ICANN 提供并在其网站上公布其准确的联系方式,包括有效的电子邮件和邮寄地址,以及处理与 TLD 中恶意行为相关的查询的主要联系人,并将及时通知 ICANN 此类联系方式的任何变更。

7.6.2恶意使用孤儿胶水记录。注册管理运营商应采取行动删除孤儿胶水记录(定义见 http://www.icann.org/en/committees/security/sac048.pdf),前提是这些记录存在与恶意行为有关的书面证据。

8. 附加服务

8.1收购部分投资组合后的批量转账(BTAPPA)

部分投资组合收购后的批量转移 (BTAPPA) 是一项注册服务,适用于经ICANN认可的注册服务商通过股票或资产购买、合并或类似方式进行收购
95



交易是另一家 ICANN 认可的注册商在 DOT-net 顶级域名中的域名组合的一部分,但不是全部。

在完成BTAPPA前至少十五天,失败的注册商必须向所有参与批量转让的域名注册人提供赞助商批量变更的书面通知。该通知必须解释批量转移后Whois记录将如何变化,以及转让注册商的客户支持和技术联系信息。

如果在上文第 3 节所述的任何适用的宽限期内通过 BTAPPA 服务转移域名,则没有积分。转让注册的到期日期不受影响。

在提出转移请求时处于以下状态的域名将不会在 BTAPPA 中转移:“待转移”、“赎回宽限期 (RGP)” 或 “待删除”。处于自动续订宽限期内的域名需要进行批量转移,但是 VeriSign 可能会拒绝为批量转移后但在自动续订宽限期到期之前删除的域名提供积分。

如果有合理的证据表明,为了避免向威瑞信或ICANN支付的其他费用,或者拥有共同所有权或管理权或两者的注册服务商已经在过去六个月内申请了BTAPPA服务,则威瑞信有权酌情拒绝BTAPPA请求。








96



.NET 注册管理机构协议附录 8
.NET 注册管理机构-注册商协议
(2022年1月29日)
image_8a.jpg

本注册管理机构-注册商协议(以下简称 “协议”)由特拉华州的一家公司 VeriSign, Inc.(营业地点位于弗吉尼亚州雷斯顿 Bluemont Way 12061 号)及其全资子公司,包括 VeriSign Sarl 和 VeriSign 命名和目录服务有限责任公司(“VNDS LLC”)(统称为 “威瑞信”)签订,以及
,通过其授权代表,其主要营业地点位于(“注册商”),并于最后一方签署的日期(“生效日期”)生效。威瑞信和注册商可以单独称为 “当事方”,也可以统称为 “双方”。

鉴于,多个注册商在威瑞信运营和维护特定 TLD 服务器和区域文件的.NET 顶级域名内提供互联网域名注册服务;
鉴于,注册商希望在.NET TLD 的多注册商系统中注册二级域名。
因此,鉴于此处包含的相互承诺、利益和契约,以及其他良好和宝贵的对价,特此确认这些承诺的收到、充分性和充分性,威瑞信和注册服务商打算受法律约束,特此协议如下:

1. 定义
3.1。”机密信息” 是指披露方向接收方提供并标记或以其他方式标识为机密的所有信息和材料,包括但不限于计算机软件、数据、信息、数据库、协议、参考实施和文档以及功能和接口规格,前提是如果通信是口头的,披露方将在披露后的 15 天内以书面形式通知接收方。
3.2。”DNS” 指的是互联网域名系统。
3.3。”EPP” 是指可扩展配置协议。




3.4。”ICANN” 指互联网名称与数字地址分配机构。

3.5。”IP” 是指互联网协议。
3.6. “许可产品” 指访问支持协议所需的知识产权,以及 API 和软件的统称。
3.7。”个人数据” 是指有关任何已识别或可识别的自然人的数据。

3.8。”注册名称” 是指注册管理机构顶级域中的域名,不论该域名由两个或多个级别(例如 john.smith.name)组成,威瑞信或从事提供注册服务的附属机构在注册管理机构数据库中维护数据、安排此类维护或从此类维护中获得收入。注册数据库中的名称可以是注册名称,即使它没有出现在 TLD 区域文件中(例如,已注册但不活跃的名称)。

3.9。“注册域名持有者” 是指注册名称的持有者。
3.10。“注册服务商委任协议” 是指注册服务商与 ICANN 之间的某些注册服务商委任协议,根据该协议,ICANN 委任注册服务商担任一个或多个顶级域的注册商。

3.11。”注册局顶级域名” 指.NET 顶级域名。
3.12。”支持的协议” 是指威瑞信对系统支持的 EPP 或任何后续协议的实施。
3.13 “系统” 是指威瑞信运营的共享注册系统,用于在注册管理机构顶级域名中注册域名。
3.14.A “顶级域名” 是 DNS 的顶级域名。

2. 双方的义务
2.1. 系统操作和访问。在本协议的整个期限内,威瑞信应运营系统,并向注册商提供访问系统的权限,以便向系统传输注册管理机构顶级域的域名注册信息。本协议中的任何内容均未授权注册服务商执行威瑞信与 ICANN 之间的任何协议。



2.2. 维护注册服务商担保的注册。根据本协议的规定、ICANN 要求和威瑞信要求(包括但不限于 ICANN 授权的要求),威瑞信应在注册服务商支付第 5.1 款所要求费用的期限内,在系统中保留注册服务商担保的注册域名的注册。
2.3. EPP、API 和软件的分发。在本协议生效之日后的三 (3) 个工作日内,威瑞信应向注册服务商提供 (i) 支持协议的完整文档,(ii) 支持协议的 “C” 和/或 “Java” 应用程序接口 (“API”) 及文档,以及 (iii) 参考客户端软件(“软件”),允许注册商开发其系统,通过注册管理机构顶级域名系统注册二级域名。如果威瑞信选择修改或升级 API 和/或支持协议,威瑞信应在更新发布后立即向所支持协议提供更新的 API 以及文档和更新的软件。

2.4. 注册商对客户支持的责任。注册商应提供 (i) 支持以接受注册、取消、修改、续订、删除或转让注册名称的订单,以及 (ii) 向注册域名持有者提供客户服务(包括域名记录支持)以及账单和技术支持。注册服务商应按照 ICANN 的政策,为域名劫持等紧急情况向注册域名持有人提供紧急联系或全天候支持信息。

2.5. 数据提交要求。作为注册管理机构顶级域名注册和担保的一部分,注册服务商应在要求或允许的情况下提交完整的数据:(a) 根据威瑞信与 ICANN 签订的注册管理机构协议,该协议可能会不时修订;和/或 (b) 威瑞信不时向注册服务商提供的系统技术规范(统称为 “必填数据元素”)。注册商应及时向威瑞信提交注册域名持有人对注册域名注册信息所作的任何更正或更新。

2.6. 许可证。注册商向威瑞信授予威瑞信非独家、免版税、不可转让(根据威瑞信与 ICANN 的注册管理机构协议,ICANN 或其指定人员除外)对所需数据元素的全球有限许可:(a) 根据威瑞信不时向注册服务商提供的系统技术规范的要求或允许使用;和/或 (b) 根据威瑞信与 ICANN 的注册管理机构协议的要求或允许使用和展示,可能会不时修订到时候。

2.7注册服务商的注册协议和域名争议政策。



(a) 注册服务商应与每位注册域名持有人签订有效且可强制执行的电子或纸质注册协议,注册服务商可以不时修改该协议,前提是向威瑞信提供副本。注册服务商应根据威瑞信的要求提供注册商注册协议的副本。注册服务商应在其注册协议中包括本协议所要求的条款以及与注册商在本协议下对 Verisign 承担的义务相一致的其他条款。注册服务商应在其域名注册业务中采用 ICANN 董事会于 1999 年 8 月 26 日和 2008 年 11 月 7 日通过的《统一域名争议解决政策》和《注册服务商间转让政策》,并可能不时修改。
(b) 注册服务商与每位注册域名持有者的注册协议还应包括以下内容:

(i) 禁止注册域名持有人散布恶意软件、滥用僵尸网络、网络钓鱼、域名欺诈、盗版、商标或版权侵权、欺诈或欺骗行为、伪造或以其他方式从事违反适用法律的活动的条款,以及(根据适用法律和任何相关程序)为此类活动提供后果,包括暂停注册名称的注册;

(ii) 一项规定,要求注册域名持有人承认并同意,威瑞信保留在其认为必要时无限制地全权决定拒绝、取消、重定向或转让任何注册或交易,或将任何域名置于注册局锁定、保留或类似状态的权利:(1) 遵守任何公认具有权威性的互联网行业组织(例如 RFC)采用的规范,(2) 纠正威瑞信或任何注册商在域名注册方面犯的错误,(3)不向威瑞信支付费用,(4) 防范注册局顶级域名、系统、威瑞信域名服务器业务或互联网的安全和稳定面临的迫在眉睫的重大威胁,(5) 确保遵守适用的法律、政府规章或法规,或根据任何政府、行政或政府机构或有管辖权的法院的任何法律命令或传票,和/或 (6) 停止或防止任何违规行为本协议、运营要求或威瑞信的任何条款和条件与 ICANN 签订的注册管理机构协议;以及

(iii) 一项条款,要求注册域名持有人对威瑞信及其分包商及其董事、高级职员、员工、代理人和关联公司进行赔偿、辩护,使其免受任何和所有索赔、损害、责任、费用和损害



费用,包括合理的律师费和因注册域名持有人的域名注册而产生或与之相关的费用。注册协议还应要求该赔偿义务在注册协议终止或到期后继续有效。

2.8 安全连接。

(a) 注册商同意在其域名注册业务中开发和使用所有必要的技术和限制,以确保其与系统的连接安全。注册商系统与系统之间交换的所有数据均应受到保护,以避免意外泄露信息。注册商应采取商业上合理的措施,防止其对本协议授予的系统的访问权限被用于:(i) 允许、启用或以其他方式支持通过电子邮件、电话或传真向其现有客户以外的实体传输大量未经请求的商业广告或招标;或 (ii) 启用向威瑞信系统(根据与 ICANN 协议运营的任何其他注册管理机构)发送查询或数据的大量、自动化、电子流程,或任何 ICANN 认可的注册商,除非合情合理根据任何运营要求注册域名或修改现有注册所必需的。

(b) 每个 EPP 会话均应使用双向安全套接字层(“SSL”)协议进行身份验证和加密。注册商同意使用由注册管理机构认定的商业证书颁发机构颁发的 X.509 服务器证书及其注册商密码对每个 EPP 客户与系统的连接进行身份验证,注册商应仅向需要知道的员工披露该密码。注册商同意在得知其注册商密码以任何方式遭到泄露或者其服务器证书已被签发证书颁发机构吊销或以任何方式泄露后的四 (4) 小时内通知注册局。

(c) 在事先书面通知注册商后,威瑞信可能要求其他行业标准安全条款、做法或技术来确保系统的安全和稳定,威瑞信可能会不时自行决定采用这些条款、做法或技术。
2.8.1. 个人数据的处理。

威瑞信应将收集注册商提交给威瑞信的个人数据的目的、此类个人数据的预期接收者(或接收者的类别)以及访问机制通知注册商



对此类个人数据进行更正。威瑞信应采取合理措施保护个人数据免遭丢失、滥用、未经授权的披露、更改或破坏。威瑞信不得以与向注册商提供的通知不一致的方式使用或授权使用个人数据。威瑞信可能会不时使用收集的人口统计数据进行统计分析,前提是这种分析不会披露个人数据,并且这种使用符合向注册服务机构提供的有关此类使用的目的和程序的通知。

2.8.2. 授权码。注册服务商不得提供注册商生成的相同授权 由不同的注册域名持有人在同一注册商处注册的域名代码。威瑞信可自行选择修改 给定域名的代码,并应通过符合 EPP 的机制(即 EPP)将此类修改通知主办注册商或者 EPP)。威瑞信应向注册商提供这些机制的文件。注册商应向注册域名持有人提供及时访问授权码的权限,并允许其修改授权码。注册服务商应在五 (5) 个日历日内回复注册域名持有人有关访问和/或修改授权码的任何查询。

2.9 域名查询功能。注册商同意在其域名注册业务中使用威瑞信的注册局域名查询功能,以确定所请求的域名是否可用或当前不可注册。注册服务商还同意自费提供注册数据目录服务,提供基于查询的免费公开访问权限,获取有关注册服务商为注册管理机构顶级域名赞助的所有活跃注册域名的最新(即至少每天更新)数据。可访问的数据应包含根据 ICANN 通过的规范或政策或注册服务商与 ICANN 之间的《注册服务商委任协议》不时指定的要素。

2.10注册担保权的转移。注册服务商同意根据 ICANN 可能不时修订的《注册服务商间域名转让政策》(“转让政策”),将注册域名注册从其他注册服务商转移到注册服务商,反之亦然,或者从一个注册域名持有者转移到另一个注册域名持有者。
2.11时间。注册商同意,如果对域名注册进入注册管理机构数据库的时间发生任何争议,则以威瑞信记录中显示的时间为准。

2.12遵守运营要求。书记官长应遵守以下每项要求,还应在其注册中包括在内



与每位注册域名持有人达成协议(如适用),规定该注册域名持有人有义务遵守以下每项要求:

(a) 根据注册管理机构协议或与 ICANN 达成的其他安排,威瑞信负有监督责任的 ICANN 标准、政策、程序和惯例;以及
(b) 威瑞信不时以非任意方式制定的注册管理机构顶级域的运营标准、政策、程序和惯例(“运营要求”),包括威瑞信的附属机构,并符合威瑞信与 ICANN 的注册管理机构协议(如适用),前提是威瑞信向注册服务商发出这些条款和条件的制定通知。
2.13解决技术问题或违反协议。注册商同意雇用必要的员工、承包商或具有足够技术培训和经验的代理人,以应对和修复与支持协议、API 和威瑞信系统与注册商系统结合使用有关的所有技术问题。注册商同意,如果系统出现严重故障或其他紧急情况,或者注册商违反运营要求或违反本协议,威瑞信可自行决定暂时暂停或限制对系统的访问。此类临时停职或限制应以非任意方式适用,并应公平地适用于任何处境相似的登记员。

2.14 禁止的域名注册。除了遵守 ICANN 限制可注册域名的标准、政策、程序和惯例外,注册服务商还同意遵守限制可注册域名的适用法规和法规。注册商进一步承认并同意,威瑞信保留出于本协议第 2.7 (b) (ii) 节规定的目的,在必要时无限制地自行决定拒绝、取消、重定向或转让任何注册或交易,或将任何域名置于注册局锁定、保留或类似状态的权利。

2.15 ICANN 的要求。根据 ICANN 规定的要求,包括共识政策,威瑞信在本协议下的义务随时可能修改。尽管本协议中有任何相反的规定,注册服务商应按照 ICANN 规定的时间表遵守 ICANN 的任何此类要求。

2.16 认证注册商。在本协议期限内,注册服务商应保持注册服务商委任协议的全部效力和效力,以及ICANN对该协议作为注册管理机构顶级域注册商的认可。




3. 许可证
3.1. 许可授予。根据本协议的条款和条件,威瑞信特此授予注册服务商和注册服务商接受非排他性、免版税、不可转让的全球有限许可,允许其在本协议的条款和目的范围内使用许可产品及其更新和重新设计,仅在注册管理机构顶级域中提供域名注册服务,不得用于其他目的。许可产品及其更新和重新设计将使注册服务商能够代表其注册域名持有者在注册管理机构顶级域名中注册域名。使用许可产品及其更新和重新设计的注册商将能够在系统上调用以下操作:(i)检查域名的可用性,(ii)注册域名,(iii)重新注册域名,(iv)取消其注册域名的注册,(v)更新域名的域名服务器,(vi)将域名从其他注册商转移到注册商自行获得适当的授权,(vii)查询域名注册记录,(viii)注册域名服务器,(ix)更新域名服务器的 IP 地址,(x) 删除域名服务器,(xi) 查询域名服务器,以及 (xii) 建立和结束经过身份验证的会话。
3.2。使用限制。尽管本协议中有任何其他规定,除非获得 Verisign 的书面同意,否则注册商不得:(i) 再许可许可产品或以其他方式允许注册商以外的任何一方使用许可产品,(ii) 发布、分发或允许披露除注册服务商的员工、承包商和代理商之外的许可产品,(iii) 反编译、逆向工程、复制或出于任何未经授权的目的重新设计许可产品,(iv)在违反任何联邦、州或地方法规、法规或法律的情况下,或出于任何非法目的使用或允许使用许可产品。注册服务商同意采取必要措施,防止其对本协议授予的系统的访问权限被用于:(i) 允许、启用或以其他方式支持通过电子邮件、电话或传真向注册服务商客户以外的实体传输大量未经请求的商业广告或招标;或 (ii) 启用向威瑞信系统(根据与 ICANN 协议运营的任何其他注册管理机构)发送查询或数据的大量、自动化、电子流程,或任何 ICANN 认可的注册服务商,除非有合理的必要根据任何运营要求注册域名或修改现有注册。
3.3. 许可材料的变更。威瑞信可能会不时更换或修改本协议下许可的许可产品。威瑞信将在对本协议下许可的支持协议、API 或软件实施任何重大变更前至少九十 (90) 天向注册商发出通知。




4. 支持服务
4.1. 工程支持。威瑞信同意向注册商提供合理的工程电话支持(在美国东部时间上午 9 点至下午 5 点之间或双方可能商定的其他时间),以解决与注册商使用系统相关的工程问题。
4.2. 客户服务支持。在本协议期限内,威瑞信将向注册服务商(而不是注册域名持有人或注册商的潜在客户)提供合理的电话、网络和电子邮件客户服务支持,以解决仅与系统及其运行相关的非技术问题。威瑞信将向注册商提供电话号码和电子邮件地址,以便在实施支持的协议、API 和软件期间提供此类支持。第一级电话支持将提供 7 天/24 小时的服务。

5. 费用

5.1 注册费。

(a) 注册商同意向威瑞信支付附录 A 中规定的不可退还的费用,或根据下文第 5.1 (b) 节中规定的通知条款可能确定的其他金额,用于初始注册和续订注册以及威瑞信提供的其他附带和辅助服务(统称为 “注册费”)。

(b) 威瑞信保留调整注册费的权利,前提是任何提价只能在提前六 (6) 个月通知注册服务商(通过电子邮件、专人、挂号、快递或快递服务)的情况下进行,前提是此类调整符合威瑞信与 ICANN 的注册管理协议。

(c) 注册商应向威瑞信提供由不可撤销的信用证或现金存款(“支付担保”)组成的支付担保。支付担保金额确定了注册商在 Verisign 系统中的信用额度,并应基于预期的每月注册量和其他可计费交易量。注册商同意根据威瑞信信贷和账单政策的要求修改其支付安全,以支持计费交易量的增加。威瑞信将按月向注册商开具拖欠的注册费发票。所有注册费应在收到威瑞信的月度发票后立即支付。为了满足任何未清的账户余额,威瑞信可以提取注册商的付款担保。如果发生这种情况,注册商同意在抽奖完成后立即将支付保证金补充到预抽奖水平。如果注册商的支付担保已用尽,请注册



在支付安全补充之前,注册商的域名将被暂停,新的注册将不被接受。

(d) 根据本协议应缴的注册费不含税。任何政府或其任何政治分支机构对任何服务、软件和/或硬件的费用征收或授权的所有税款、关税、费用和其他政府费用(包括营业税、征税、销售税、营业税、服务税、使用税和增值税,但不包括基于威瑞信净收入的税款),均应由注册服务商承担,不得视为此类注册费的一部分、扣除或抵消。应付给 Verisign 的所有款项不得因任何税款、关税、收费或罚款而扣除或预扣任何款项,除非法律要求,在这种情况下,注册服务商应从中扣除或预扣的金额应增加到必要的程度,以确保在进行此类扣除或预扣后,威瑞信收到并保留(对此不承担任何责任)等于其本应金额的净金额已收到,但需要扣除或预扣税。

5.2更改注册商赞助域名。注册服务商可以遵循转让政策,承担注册域名持有者从其他注册商处注册的现有域名注册的担保。
(a) 对于根据转让政策进行的域名注册担保权的每一次转让,注册服务商同意向威瑞信支付与延期一年相关的续订注册费,如上所述。任何此类转让都不会退还亏损的注册商的注册费。
(b) 对于 ICANN 根据转让政策第 B 部分批准的转让,注册服务商同意向威瑞信支付 0 美元(对于不超过 50,000 个域名的转让)或 50,000 美元(转让超过 50,000 个域名)。

根据支付安全,本第 5.2 节规定的费用应在收到威瑞信发票后立即支付。
5.3 ICANN 费用的收费。注册服务商同意在到期之日起五 (5) 天内向威瑞信支付威瑞信向 ICANN 支付的任何可变注册管理机构级别费用,这些费用由支付安全机构担保。费用将由两个部分组成;每个部分将由 ICANN 为每个注册商计算:




(a) 可变注册管理机构级别费用的交易部分应由ICANN根据ICANN董事会通过的每个财年预算具体规定,但不得超过注册管理机构协议中规定的金额。

(b) 可变注册管理机构级别费用的每位注册服务商部分应由ICANN根据ICANN董事会通过的每个财政年度的预算来规定,但为所有注册服务商计算的每位注册服务商费用总额不得超过根据批准的ICANN预算确定的每注册服务商可变资金总额。

5.4不支付费用。及时支付根据本第 5 节应付的费用是履行本协议的重要条件。如果注册服务商未能在到期之日起五 (5) 天内支付费用,威瑞信可以:(i) 停止接受注册服务商新的初始或续订注册;(ii) 从注册管理机构数据库中删除与未全额支付的发票相关的域名;(iii) 根据下文第 6.1 (b) 节发出终止本协议的书面通知;(iv) 根据本协议寻求任何其他补救措施。

6. 其他

6.1协议期限和终止。
(a) 协议期限;修订。本协议各方的职责和义务应自生效之日起至生效之日起六十 (60) 个月(以下简称 “初始期限”)起的日历月的最后一天,适用。初始期限结束后,本协议的所有条款将自动续订连续五 (5) 年,直到协议按照本协议的规定终止、注册服务商选择不续订或威瑞信停止运营注册管理机构顶级域的注册管理机构为止。如果 ICANN 批准或通过对 Verisign 注册管理机构-注册商协议的修订,注册服务商应在发出任何此类修订的通知之日起三十 (30) 天内审查、评论和执行以修订后的协议取代本协议的修正案,或者注册服务商可在这三十 (30) 天期限内行使选择权,通过向威瑞信发出书面通知立即终止本协议;但是,前提是在这种情况下威瑞信未收到此类已执行的修正案或终止通知书记官长在通知发出之日起的三十 (30) 天期限内,应视为自通知之日起第三十一 (31) 天起执行了该修正案。




(b) 因故解雇。如果任何一方严重违反本协议的任何条款,包括其在本协议下的任何陈述和保证,并且此类违规行为在另一方发出书面通知后的三十 (30) 个日历日内未得到实质性纠正,则非违约方可以通过向另一方发出书面通知来终止本协议,自该终止通知中规定的日期起终止本协议。

(c) 由注册服务商选择终止。注册服务商可随时向威瑞信发出三十 (30) 天终止通知,终止本协议。

(d) 因失去注册服务商的委任而终止。如果 ICANN 或其继任者对注册管理机构 TLD 的注册服务商的认证终止或到期且无需续期,则本协议应立即终止。
(e) 如果指定了继任注册管理运营商,则终止。如果 ICANN 指定其他实体运营注册管理机构 TLD 的注册管理机构,则本协议将终止。

(f) 破产时终止。任何一方均可终止本协议,前提是另一方被判定破产或破产,或者一方根据任何与破产有关的法律寻求救济、重组或安排,或寻求为债权人的利益进行任何转让,或寻求指定一方财产或资产的接管人、清算人或受托人,或一方企业的清算、解散或清盘。

(g) 终止的影响。在本协议到期或终止时,威瑞信将在其授权的范围内,在到期或终止之日之前完成注册商处理的所有域名的注册,前提是注册服务商及时向威瑞信支付的注册费。在本协议到期或终止后,注册服务商应 (i) 根据转让政策 B 部分或 ICANN 制定或批准的任何其他程序,将其对注册域名注册的担保立即移交给注册管理机构的其他持牌注册商,并且 (ii) 退还威瑞信或向威瑞信证明其在本协议下收到的所有机密信息已销毁。如果终止,威瑞信保留立即联系所有注册域名持有者的权利,以促进注册域名持有人有序稳定地过渡到其他 ICANN 认可者



登记员。应付给威瑞信的所有费用应立即到期并支付。

(h) 生存。如果本协议终止,以下条款将继续有效:(i) 第 2.6 节(许可)、第 2.7 节(注册商注册协议和域名争议政策)、2.8.1(个人数据的处理)、6.1 (g)(终止的效力)、6.1(h)(存续)、6.2(无第三方受益人;双方关系)、6.6(律师费)、6.7(争议解决);法律选择;地点)、6.8(通知)、6.10(机密信息的使用)、6.11(延迟或遗漏;豁免)、6.12(责任限制)、6.13(解释)、6.14(知识产权)、6.15 (c)(免责声明)、6.16(赔偿)和 6.17(完整协议;可分割性);(ii) 如第 2.7 (b) (iii) 节所述,注册域名持有人有义务对威瑞信进行赔偿、辩护并使其免受损害;以及 (iii) 第 5 节规定的注册服务商对在此期间产生的费用的付款义务本协议的期限。

6.2没有第三方受益人;双方的关系。本协议不提供也不应解释为向第三方(即本协议的非缔约方),包括任何注册域名持有者,提供任何补救措施、索赔、诉讼理由或特权。本协议中的任何内容均不得解释为在双方之间建立雇主与雇员或代理关系、合伙关系或合资企业。
6.3不可抗力。任何一方均不对因任何天灾、罢工、停工、网络攻击而未能履行任何义务(付款义务除外)或提供本协议项下的服务承担责任,以防电信服务提供商遇到的对注册局顶级域名、系统、威瑞信域名服务器运营或互联网的安全和稳定构成迫在眉睫的重大威胁、政府行为或指令、战争、暴动或内乱、设备或设施短缺的影响一般来说,或其他类似的力量超出该方的合理控制范围。

6.4 进一步保证。本协议各当事方应签署和/或安排向本协议对方交付此类文书和其他文件,并应采取该另一方可能合理要求的其他行动,以执行或证明本协议所设想的任何交易。

6.5 书面修正案。除非本协议另有规定,否则本协议的任何修正或补充均应以书面形式由双方正式签署。任何经 ICANN 批准并由注册商购买的新服务都将受威瑞信通过本协议附录或注册商和 Verisign 签署的其他协议可能制定的条款和条件的约束。




6.6律师费。如果对本协议任何一方提起与履行本协议或执行本协议任何条款有关的任何法律诉讼或其他法律诉讼(包括仲裁),则胜诉方有权收回合理的律师费、费用和支出(以及胜诉方可能有权获得的任何其他救济)。

6.7争议解决;法律选择;地点。双方应在诉诸诉讼之前设法解决彼此之间的任何争端。本协议应根据美利坚合众国弗吉尼亚联邦的内部法律进行解释并受其管辖,但不影响任何可能导致除弗吉尼亚联邦内部法律之外的任何司法管辖区的法律适用于双方权利和义务的法律选择规则。与本协议或本协议任何条款的执行有关的任何法律诉讼或其他法律诉讼均应在弗吉尼亚联邦东区的任何州或联邦法院提起或以其他方式启动。本协议各方明确且不可撤销地同意并服从位于弗吉尼亚联邦东区的各州和联邦法院(以及位于弗吉尼亚联邦的每个上诉法院)对任何此类法律诉讼的管辖权和审判地管辖。

6.8通知。根据本协议要求或允许向任何一方交付的任何通知或其他通信均应采用书面形式,除非当事方以书面形式发出地址变更通知(手动、挂号、快递或快递服务、通过电子邮件或在工作时间通过电信复印机),否则应视为已正确送达、发出和接收:

如果给注册商:
客户姓名:
注意:
实际地址:
城市,州邮政:
电话号码:
传真号码:
电子邮件:

并将其副本发送至:
客户姓名:
注意:
实际地址:
城市,州邮政:
电话号码:
传真号码:



电子邮件:

如果是威瑞信:
VeriSign, Inc.
12061 Bluemont Way
弗吉尼亚州雷斯顿 20190
收件人:总法律顾问
电话:+1 703 948 3200
传真:+1 703 435 4921
电子邮件:legal@verisign.com


附上副本至(不构成通知):

VeriSign, Inc.
12061 Bluemont Way
弗吉尼亚州雷斯顿 20190
收件人:客户事务办公室
电话:+1 703 948 3200
传真:+1 703 948 3977
电子邮件:cao@verisign-grs.com

6.9转让/再许可。除非本协议中另有明确规定,否则本协议的条款应使本协议双方的继承人和获准受让人受益并具有约束力。未经威瑞信事先书面同意,注册商不得将其在本协议下的权利或义务转让、再许可或转让给任何第三方。未经注册商同意,威瑞信可将其在本协议下的权利或义务转让给关联公司。
6.9.1。与与 ICANN 协议转让相关的转让。如果威瑞信与 ICANN 签订的注册管理机构顶级域名注册管理机构协议得到有效分配,则威瑞信在本协议下的权利将自动分配给《注册管理机构协议》的受让人,前提是受让人承担本协议规定的威瑞信的职责。如果注册服务商与ICANN就注册管理机构顶级域签订的注册服务商委任协议得到有效分配,则注册服务商在本协议下的权利将自动分配给注册服务商的注册服务商委任协议的受让人,前提是后续注册服务商承担本协议项下的注册服务商职责。

6.10机密信息的使用。在本协议期限内,各方(“披露方”)均可向另一方(“接收方”)披露其机密信息。各方对以下披露的机密信息的使用和披露均受以下条款和条件的约束:




(a) 接收方应严格保密,并尽一切合理努力维护披露方所有机密信息的保密和保密性,包括实施合理的物理安全措施和操作程序。

(b) 接收方同意将披露方的任何机密信息仅用于行使本协议项下的权利或履行其义务,不得用于任何其他目的。
(c) 接收方不得向他人披露披露方的任何机密信息;但是,如果接收方是公司、合伙企业或类似实体,则允许向明显需要了解此类机密信息的接收方官员、员工、承包商和代理人披露,前提是接收方应告知此类人员机密信息的机密性质,并采取合理措施维护其机密性。

(d) 接收方不得修改或删除披露方的任何机密信息上出现的任何保密图例和/或版权声明。

(e) 接收方同意不根据机密信息准备任何衍生作品。

(f) 尽管有前述规定,本第 6.10 小节对以下信息不承担任何义务:(i) 在没有保密协议的情况下披露且披露方在披露之前以书面形式同意此类披露;或 (ii) 因接收方的过错而进入或已经进入公共领域;或 (iii) 在披露之前为接收方所知;或 (iv) 是由接收方在不使用机密信息的情况下独立开发;或 (v) 已制作通常由披露方提供,不受披露限制,或 (vi) 法律、法规或法院命令要求披露;前提是,如果法律、法规或法院命令要求接收方披露披露方的任何机密信息,则接收方将在进行任何此类披露之前立即以书面形式通知披露方,以方便披露方向有关当局寻求保护令或其他适当补救措施,网址为那个



披露方的开支。接收方同意与披露方合作寻求此类命令或其他补救措施。接收方进一步同意,如果披露方未能成功阻止提出请求的法律机构要求披露机密信息,则它将仅提供机密信息中法律要求的部分。

6.11延迟或遗漏;弃权。任何一方未能行使本协议下的任何权力、权利、特权或补救措施,以及任何一方未延迟行使本协议下的任何权力、权利、特权或补救措施,均不构成对该权力、权利、特权或补救措施的放弃;对任何此类权力、权利、特权或补救措施的单一或部分行使或放弃均不妨碍其或任何其他权力、权利的行使,特权或补救措施。除非在代表该方正式签署和交付的书面文书中明确规定了对此类索赔、权力、权利、特权或补救措施的放弃,否则任何一方均不得被视为放弃了因本协议或本协议下的任何权力、权利、特权或补救措施而产生的任何索赔;任何此类豁免均不适用或不具有任何效力。

6.12 责任限制。
(a) 在任何情况下,威瑞信均不对因本协议引起或与之相关的任何特殊、间接、附带、惩罚性、惩罚性、惩罚性或间接损失向注册商承担任何责任,即使 VERISIGN 已被告知此类损害的可能性。在任何情况下,双方的最高总赔偿责任均不得超过 (I) 前十二 (12) 个月期间根据本协议条款向威瑞信支付的总金额,或 (ii) 500,000 美元中较低者。

(b) 第6.12 (a) 节中规定的责任上限和损害赔偿排除不适用于第 6.10 节(使用机密信息)和第 6.16 节(赔偿)。
6.13施工。双方同意,任何旨在解决不利于起草方的歧义的解释规则均不适用于本协议的解释或解释。
6.14知识产权。在遵守上述第2.6节的前提下,各方将继续独立拥有其知识产权,包括所有专利、商标、商品名称、服务标志、版权、商业秘密、专有流程和所有其他形式的知识产权。




6.15陈述和保证
(a) 书记官长。注册服务商声明并保证:(1) 它是一家依法注册成立、有效存在且信誉良好的公司,(2) 它拥有执行、交付和履行本协议义务的所有必要公司权力和权力,(3) 根据《注册服务商委任协议》或 ICANN 批准的继任协议,在本协议期限内将继续获得 ICANN 或其继任者的认可,(4) 本协议的执行、履行和交付已获得注册商的正式授权,并且 (5) 注册商无需获得或获得任何政府或监管机构的进一步批准、授权或同意,即可签订和履行本协议规定的义务。

(b) 威瑞信。威瑞信声明并保证:(1) 它是一家根据特拉华州法律正式注册成立、有效存在且信誉良好的公司;(2) 它拥有执行、交付和履行本协议义务的所有必要公司权力和权力;(3) 本协议的执行、履行和交付已获得威瑞信的正式授权;(4) 没有任何政府或监管机构的进一步批准、授权或同意必须由威瑞信获取或制造才能加入和履行其在本协议下的义务。

(c) 免责声明。许可产品、支持的协议、EPP、API 和软件按 “原样” 提供,不提供任何形式的担保。威瑞信明确否认所有明示或暗示的担保和/或条件,包括但不限于对适销性、令人满意的质量和特定用途的适用性以及不侵犯第三方权利的暗示担保和条件。威瑞信不保证许可产品、支持的协议、EPP、API 或软件中包含的功能将满足注册商的要求,也不保证许可产品、支持的协议、EPP、API 或软件的运行不会中断或没有错误,也不保证许可产品、支持的协议、EPP、API 或软件中的缺陷将得到纠正。此外,威瑞信对使用或结果不作任何担保或陈述



许可产品、支持的协议、EPP、API、软件或相关文档的正确性、准确性、可靠性或其他方面。如果许可产品、支持的协议、EPP、API 或软件被证明存在缺陷,注册商将承担对注册商自己的系统和软件进行所有必要维护、维修或更正的全部费用。

6.16赔偿。注册服务商将自费在威瑞信根据本款提出要求后的三十 (30) 天内,针对因与注册商的任何产品或服务有关的索赔或指控而对威瑞信或威瑞信的任何关联公司提起的任何索赔、诉讼、诉讼或其他诉讼,对威瑞信及其员工、董事、高级职员、代表、代理人和关联公司进行赔偿、辩护,并使他们免受损害;(ii) 与任何注册域名持有人签订的任何协议(包括注册商的争议政策)有关注册商;或 (iii) 与注册商的域名注册业务有关,包括但不限于注册商的广告、域名申请流程、系统和其他流程、收取的费用、计费惯例和客户服务;但是,在任何此类情况下:(a) 威瑞信立即向注册服务商发出任何此类索赔的通知,并且 (b) 根据注册商的书面请求,威瑞信将向注册服务商提供注册商合理必要的所有可用信息和协助为此类索赔进行辩护,前提是书记官长向威瑞信偿还其实际和合理的费用。威瑞信有权通过自己选择的律师控制威瑞信对任何索赔或诉讼的辩护,律师的费用应按本协议的规定进行赔偿。未经威瑞信事先书面同意,注册商不得就任何此类应予赔偿的索赔达成任何和解或妥协,不得无理地拒绝同意。注册服务商将支付所有费用、损害赔偿和开支,包括但不限于合理的律师费和威瑞信因任何此类应予赔偿的索赔、诉讼、诉讼或诉讼而裁定或由威瑞信承担的其他费用。

6.17完整协议;可分割性。本协议包括附录A和B,构成双方之间关于本协议标的的的完整协议,并取代先前就本协议中明确规定的主题事项达成的任何口头或书面协议、陈述、谈判、谅解、提议或承诺。如果本协议的任何条款被认定为非法、无效或不可执行,则各方同意应在允许的最大范围内执行该条款,以实现双方的意图,并且本协议其余条款的有效性、合法性和可执行性不应因此受到任何影响或损害。如有必要实现双方的意图,双方应本着诚意进行谈判,修改本协议,以尽可能反映这种意图的可执行措辞取代不可执行的措辞。




6.18服务等级协议。《注册管理机构协议》附录 10(可能会不时修订)应纳入本协议,并作为附录 B 附于本协议中。





本协议双方自生效之日起执行本协议,以昭信守。
威瑞信
来自:

姓名:

标题:

日期:

注册商公司名称:
来自:

姓名:

标题:

日期:




附录 A
注册费
1.域名初始注册费
注册服务商同意按初始域名注册的年度增量支付 9.92 美元外加 0.75 美元的 ICANN 费用,或根据上文第 5.1 (b) 节中规定的通知条款可能确定的其他金额。

2.域名续订费
注册服务商同意按域名注册续订的年度增量支付 9.92 美元外加 0.75 美元的 ICANN 费用,或根据上文第 5.1 (b) 节中规定的通知条款可能确定的其他金额。

3.域名转移
注册服务商同意为从另一家 ICANN 认可的注册服务商转让给注册服务商的每个域名支付 9.92 美元外加 0.75 美元的 ICANN 费用,或根据上文第 5.1 (b) 节中规定的通知条款可能确定的其他金额。

4.EPP 更新以恢复名称
注册商同意每次使用 EPP Update 命令来恢复域名支付 40.00 美元,或根据上文第 5.1 (b) 节中规定的通知条款可能确定的其他款项。

5. 同步
注册商同意为每次使用支持的协议同步命令支付 2.00 美元,外加每月 1.00 美元的同步费用,或根据上文第 5.1 (b) 节中规定的通知条款可能确定的其他金额。



附录 B

服务等级协议(附录 10)
请参阅 .net 注册管理机构协议附录 10,该附录可能会不时修订。




NET 注册管理机构协议附录 9
批准的服务
image_2.jpg

《注册管理机构协议》规定了 “拟议注册管理机构服务的考虑流程”。在《注册管理机构协议》生效之日之前,ICANN 特别认定以下服务已获得 ICANN 的批准。因此,不管《注册协议》有任何其他规定,VeriSign 均可自由部署以下服务:

•根据注册管理运行机构的《注册商参考手册》提供整合/同步服务;
•国际化域名,根据鲁斯蒂·刘易斯于2003年10月13日给保罗·托米的信;
•根据威瑞信的《注册商参考手册》,赎回宽限期;
•恢复,允许在赎回宽限期内使用 EPP Update 命令检索先前删除的域名注册(由 ICANN 根据威瑞信的注册商参考手册批准);
•候补名单服务,根据约翰·杰弗里于2004年1月26日给罗素·刘易斯的信;
•DNS 更新服务,根据 2007 年 4 月 11 日发布的 https://www.icann.org/en/system/files/files/icann-to-verisign-04apr07-en.pdf;
•DNSSEC,根据 2009 年 11 月 7 日发布的 https://www.icann.org/en/system/files/files/icann-to-verisign-2009011-06nov09-en.pdf;
•根据2009年12月9日发布的 https://www.icann.org/resources/board-material/minutes-2009-12-09-en,恢复部分投资组合(“BTAPPA”)后的批量转账;
• 域名 WhoWas,根据 2009 年 7 月 16 日发布的 https://www.icann.org/en/system/files/files/verisign-whowas-16jul09-en.pdf;
•IDN DNS 更新,根据 2009 年 7 月 10 日发布的 https://www.icann.org/en/system/files/files/icann-to-verisign-200906-10jul09-en.pdf;
•注册表锁定服务,根据 2009 年 7 月 10 日发布的 https://www.icann.org/en/system/files/files/icann-to-verisign-200905-10jul09-en.pdf;



•注册局-注册商双重身份验证服务,根据 2009 年 7 月 10 日发布的 https://www.icann.org/en/system/files/files/icann-to-verisign-200904-10jul09-en.pdf;
•可扩展配置协议的验证码扩展,根据 2017 年 2 月 27 日发布的 https://www.icann.org/en/system/files/correspondence/papac-to-kane-27feb17-en.pdf
•根据2022年2月14日的 https://www.icann.org/en/system/files/files/weinstein-to-kane-14feb22-en.pdf 对可扩展配置协议的验证码扩展进行了修改。
•双重身份验证服务,根据 https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-27jul22-en.pdf,日期为 2022 年 7 月 27 日
•根据适用法律进行域名注册验证,根据 https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-08sep22-en.pdf,日期为 2022 年 9 月 8 日







.NET 注册管理机构协议附录 10
服务等级协议 (SLA)

VeriSign, Inc.(“注册管理运营商”)致力于为其客户提供世界一流水平的服务。如果注册管理运行机构的运营绩效低于附录 7 中确定的某些绩效规范,本服务等级协议(“SLA”)以 SLA 积分(定义见下文第 2 节)的形式提供补救措施。

1. 定义。

此处使用但未另行定义的大写术语应具有注册管理机构协议(包括但不限于附录 7)中规定的定义。

2.SLA 积分。

如果注册管理运行机构未能满足信用等级适用的附录 7 第 6 节中定义的绩效规范,则注册管理运行机构应根据针对此类不合格的绩效规范指标确定的信用等级向 ICANN 认可的注册服务机构支付积分,该信用等级是根据本第 2 节中规定的信用等级表(“SLA 积分”)计算得出的。应支付给每位 ICANN 认可的注册服务商的 SLA 抵免额度,以抵消 ICANN 认可的注册服务商应向注册管理运营商支付的注册费和其他费用。SLA 积分是指因违反附录 7 中规定的性能规范而向注册管理运行机构评估的抵免额、罚款和/或责任总额。所有 SLA 积分均应以美元支付。信用等级表(参见 SLA 积分表)指出了信用等级适用的每项绩效规范的相应信用等级。本 SLA 将按季度进行对账,除非本 SLA 中另有规定,否则将按季度发放 SLA 积分。

表 SLA 积分

应用程序 7 参考资料

性能规范

SRS
域名服务器

Whois
6.2.2, 6.2.3,
6.2.4

服务可用性
第 2 级

第 1 级
第 2 级




6.3.1

计划内停机-持续时间
第 6 级

不是

不是

6.3.2

计划内停机-时限
第 5 级

不是

不是

6.3.3

计划内停机-通知
第 5 级

不是

不是

6.4.1

计划内停机时间延长-持续时间
第 6 级

不是

不是

6.4.2
计划停机时间延长-时限
第 5 级

不是

不是

6.4.3
计划内停机时间延长-通知
第 5 级

不是

不是

6.5.1

处理时间-检查域
第 3 级

不是

不是

6.5.2
处理时间-添加/创建域
第 3 级

不是

不是

6.5.3
处理时间-修改/更新和删除域
第 3 级

不是

不是

6.5.4

处理时间-Whois 查询

不是

不是
第 3 级

6.5.5
处理时间-DNS 域名服务器解析

不是

第 3 级

不是

6.6.1
更新频率-DNS 域名服务器

不是

第 4 级

不是

6.6.2

更新频率-Whois

不是

不是
第 4 级

2.1. 信用等级 1-评估信用等级 1 时,DNS 域名服务器服务每月可用性低于 100%。如果未满足 DNS 域名服务器服务可用性性能规范,则信用等级 1 的 SLA 抵免额应在未满足服务可用性性能规范的适用日历月后 30 天支付给 ICANN 认证的活跃注册服务商。就本附录 10 而言,



“活跃” ICANN 认可的注册商是指在之前的每月时间范围内注册的净新.net 域名超过 150 个的注册商。

符合下文第 3 节要求的每位活跃的 ICANN 认可注册服务商将获得的金额等于该活跃的 ICANN 认证注册服务商在适用的月度期限内净新.net 域名注册量除以适用的月度时间框架内所有活跃的 ICANN 认证注册服务商的新.net 域名注册净额乘以表信用级别 1 中规定的每月信用额度。

表信用等级 1

秒。's
30-
秒。's
1-
分钟。's
2-
分钟。's
10
分钟。's
超过 30 分钟。's
SLA
信用金额

$ 100,000

$ 175,000

$250,000

$400,000

$750,000

$1,000,000

2.2. 信用等级 2-评分等级 2 的评估是针对每个日历年的 SRS 服务可用性低于 99.99% 以及 Whois 服务在每个月时间段的可用性低于 100% 的。如果未满足服务可用性性能规格指标,信用等级 2 的 SLA 抵免额将直接计入符合下文第 3 节要求的活跃的 ICANN 认证注册服务商,金额等于中断时间 (OT) 乘以前三 (3) 个月的平均每日注册量 (nraVG) 乘以.net 批发费除以每天的分钟数(1,440 分钟))。

ICANN 认可的活跃注册商将获得以下奖励:

(.net 注册费) * (OT) * (nRAVG)
(1,440 分钟)

此外,对于任何月份,如果 SRS 和 Whois 的计划外停机总时间超过 30 分钟,注册管理运行机构将向符合第 3 节要求的活跃的 ICANN 认证注册服务商存入一千美元(1,000 美元)以下。

2.3.信用等级 3-评估信用等级 3 是否符合支票域处理时间性能规范,



添加/创建修改/更新和删除域命令以及 DNS 域名服务器解析和 Whois 查询。如果未满足 “处理时间绩效规范” 指标,则应根据处理时间超过适用性能规范指标的时间百分比,向活跃的 ICANN 认证注册服务机构支付信用等级 3 的 SLA 积分(参见信用等级表 3)。

对于符合下文第 3 节要求的每位活跃的 ICANN 认可注册服务商,其金额等于在适用的月度期限内活跃的 ICANN 认可的注册服务商的.net 域名净注册量除以所有活跃的 ICANN 认证注册服务商在适用的月度时限内,在相应日历月后 30 天内表信用级别 3 中规定的服务级别协议抵免金额。

表信用等级 3

5 -
10 -
25 -
≥ 50%
SLA 积分金额
$500
$1,000
$2,000
$5,000

2.4. 信用等级 4-评估信用等级 4 是否符合域名服务器和 Whois 更新频率的性能规范。如果未满足 “更新频率绩效规范” 指标,则信用等级 4(参见表信用等级 4)的 SLA 积分应按金额支付给 ICANN 认证的活跃注册服务商
更新频率超过适用的性能规格指标的时间百分比。

符合下文第 3 节要求的每位活跃的 ICANN 认可注册商将获得一笔金额,金额等于该活跃的 ICANN 认可的注册服务商在适用的月度期限内的.net 域名注册净额除以所有活跃的 ICANN 认证注册服务商在适用的月度时限内注册的新.net 域名净额,乘以表信用级别 4 中规定的服务级别协议抵免金额。

表信用等级 4

最多
15 分钟到
1 小时到
≥12
小时



SLA 积分金额

$500

$1,000

$2,000

$5,000

2.5. 信用等级 5-评估信用等级 5 是否未满足 “计划中断时间框架”、“计划中断通知”、“延长计划中断时间框架” 和 “延长计划中断通知” 的性能规范。如果未满足绩效规范指标,则信用等级 5 的 SLA 抵免额应支付给符合下文第 3 节要求的每位活跃的 ICANN 认可注册服务商,其金额等于该活跃的 ICANN 认可注册服务商在适用的月度期限内新.net 域名注册服务商的净.net 域名注册量除以适用的月度时限内所有活跃的 ICANN 认证注册服务商的新.net 域名注册净额乘以一千美元 (1,000 美元)。

2.6. 信用等级 6-评估信用等级 6 是否符合计划停机时间和延长计划中断期的性能规范。如果未满足绩效规范,则信用等级6的SLA抵免额应直接支付给符合下文第3节要求的ICANN认可的注册服务商,金额等于过去三个月的平均每日净增量(ADM)乘以计划期限超额(PDO)乘以表信用等级6中规定的SLA信用累进财务罚款。就本附录 10 而言,PDO 的计算方法是从以小时和分钟为单位的总停机时间中减去计划停机时间或延长计划停机时间(如适用)的最大允许时间(以小时和分钟)为单位。

表信用等级 6

1 到
15 分钟到
1 到

3 -

≥6 小时
SLA
信用
ADM*PDO* $.25
ADM*PDO* 0.50 美元
ADM*PDO*$ 1.00
ADM*PDO* 1.50 美元
ADM*PDO*$ 2.00

3.注册商的责任。

为了让 ICANN 认证的注册服务商申请本附录 10 中概述的 SLA 积分,必须严格遵守本第 3 节的程序。



3.1. 受影响的 ICANN 认可的注册服务商必须报告注册管理运行机构涉嫌未能满足绩效规范的每起事件,并按照注册管理运行机构要求的方式(即电子邮件、传真、电话)向注册管理运行机构的客户服务台提出 SLA 积分申请,才有资格获得 SLA 抵免。受影响的 ICANN 认可注册服务商必须在出现未满足绩效规范的日历年结束后的三 (3) 个月内发起 SLA 积分申请。

3.2. 每位 ICANN 认可的注册服务商在预计其预计交易量(不包括支票域命令)将超过 ICANN 认可的注册服务商上个月的交易量超过 25% 时,都必须通知注册管理运营商。如果 ICANN 认可的注册服务商未能告知注册管理运行机构预计交易量将增长 25% 或以上,而 ICANN 认可的注册服务商的交易量比上个月增长了 25% 或以上,并且如果注册管理运行机构当月所有经 ICANN 认证的注册服务机构的交易总量超过注册管理运行机构上个月交易的实际交易量超过 20%,则 ICANN 认可的注册服务商不会有资格获得本 SLA 中列出的任何 SLA 积分每月时间表。ICANN 认可的注册服务商应在适用日历月的第一天前至少 30 天提供此类预测。注册管理运行机构同意通过电子邮件向 ICANN 认可的注册服务机构提供月度交易摘要报告。

3.3. 受影响的 ICANN 认可的注册服务商必须提供文件以支持其 SLA 抵免额度申请。ICANN 认可的注册服务商应以以下任一形式提供文件:

a) ICANN 认可的注册服务商向注册管理运行机构发送了关于超出 SLA 限制或未能满足 SLA 要求的性能规范的通知,包括注册管理运行机构签发的故障单号码。还应包括结算单,以确定总停机时间(除非故障单中包含此信息);或

b) 注册管理运行机构关于超出 SLA 限制或未能满足 SLA 要求的性能规范的通知(附有故障单号)。还应包括结算单,以确定总停机时间(除非故障单中包含此信息)。

3.4. 为了计算积分,受影响的 ICANN 认可的注册服务商必须包括过去三 (3) 个日历月的交易量数字(或者,如果更少,



ICANN 认可的注册服务商获准在 .net 注册机构中注册域名的时间长度),并证明这些数字准确反映了受影响期间将涵盖的最低注册数量。

3.5. 注册管理运营商应进行必要的测量,以证实 ICANN 认可的注册服务商申请的 SLA 积分总额。此类测量结果和相关文件应通过电子邮件发送给每个申请 SLA 抵免额的 ICANN 认证注册服务商。

3.6. 准确完成上述步骤后,注册管理运行机构应通知将输入受影响的 ICANN 认证注册服务商账户的 SLA 积分数量,这些积分可以立即用于.net 域名注册以及 ICANN 认可的注册服务商应向注册管理运行机构支付的其他费用。

4。义务。

4.1除跨网络域名服务器性能(不属于本服务级别协议的范围)外,注册管理运行机构将从至少两个外部位置和至少一个内部位置进行监控,以此来验证 a) 可以有效建立会话以及 b) EPP 命令能否成功完成。

4.2如果所有 ICANN 认证的注册服务商都受到 SRS 不可用的影响,注册管理运行机构有责任开具一揽子故障单,并立即将问题单的编号和详细信息通知所有 ICANN 认可的注册服务商。

4.3如果 ICANN 认证的个别注册服务商无法使用系统服务,注册管理运行机构将尽商业上合理的努力,在合理可行的情况下尽快为这个 ICANN 认证的注册服务商重建受影响的系统服务。任何由于 ICANN 认可的个别注册商导致的系统服务不可用,但不代表系统服务中断,都不会产生服务级别协议积分,也不会受本 SLA 的约束。

4.4ICANN 认可的注册服务商和注册管理运行机构同意通过合理的商业诚信努力来确定任何所谓的系统服务不可用的原因。如果双方确定是注册管理运行机构的问题,则系统服务不可用将受本 SLA 的约束。



4.5. 注册管理运行机构将做出商业上合理的努力,在不可抗力事件终止后的 24 小时内恢复任何系统服务,并在不可抗力事件终止后 48 小时内恢复全部系统功能。因不可抗力造成的中断不应被视为系统服务不可用,不会影响附录 7 中规定的性能规范,也不受本 SLA 的约束。

4.6. 注册管理运行机构将在商业上合理的时间内开立事件故障单,并将处理所有系统性能问题,以降低严重程度,并在商业上合理的时间内予以修复。测量系统标记的事件也将符合开票活动的资格,并将受本 SLA 的约束。

4.7. 注册管理运行机构将发布月度系统性能和服务可用性报告。

5。杂项。

5.1本 SLA 独立于《注册管理机构协议》中规定的任何权利、义务或义务。如果本 SLA 的条款和条件与《注册管理机构协议》存在任何冲突,则以《注册管理机构协议》为准。

5.2 作为《注册管理机构-注册服务商协议》(“RRA”)的附录,本 SLA 中的任何条款均无意取代 RRA 中的任何条款或条件。

5.3争议解决将按照 RRA 第 6.7 节处理。

5.4由于 RRA 第 2.13、5.4 或 6.3 条、RRA 中的任何其他适用条款或注册管理运行机构遵守生效日期之后制定的任何共识政策直接导致的系统服务中断均不受本 SLA 的约束,但仅限于注册管理运行机构遵守了 RRA 中的此类规定而通过商业上合理的努力不可避免的系统服务中断的程度和期限或生效日期之后制定的任何共识政策。




.NET 注册管理机构协议附录 11
公共利益承诺



注册管理运行机构同意自生效之日起履行以下公共利益承诺。

a.Registry Operator 将确保其《注册管理机构-注册服务商协议》中有一项条款,要求注册服务商在其注册协议中纳入一项条款,禁止注册域名持有人分发恶意软件、滥用僵尸网络、网络钓鱼、盗版、商标或版权侵权、欺诈或以其他方式从事违反适用法律的活动,以及提供(与适用法律和任何相关程序相一致)后果(由相应的注册服务商执行)根据该注册商的注册商委任协议)进行此类活动,包括暂停域名。

b.Registry Operator 将定期(不少于每月一次)进行技术分析,以评估域名中的域名是否被用于实施安全威胁,例如域名欺诈、网络钓鱼、恶意软件和僵尸网络。注册管理运行机构将保留统计报告,说明已发现的安全威胁数量以及根据定期技术分析所采取的任何行动。除非法律要求缩短期限或 ICANN 批准,否则注册管理运行机构将在协议当时的六年期限内保留这些报告,并将应要求将其提供给 ICANN。