模块 3：申请提交

本模块概述了提交新 gTLD 申请的主要里程碑节点和预期事项，重点介绍提交期和限制、备用申请流程以及申请排队和优先级排序等关键内容。

模块 3 还涵盖其他重要主题，包括：

• DNS 稳定性和根区标签生成规则。

• 申请和字符串类型。

• 费用和付款。

• 变更请求。

本模块信息旨在阐明申请流程，使申请人能够充分准备并自信地完成申请。

3.1 提交申请

3.1.1 申请提交期

申请提交期预计最迟于 2026 年 4 月 30 日协调世界时 23:59 开启，持续 105 天，至 2026 年 8 月 12 日协调世界时 23:59 截止。

所有申请必须在申请提交期截止前提交方可获审，系统不接受逾期提交。建议申请人在申请提交期开放后尽快提交完整的申请材料。如果等到提交期临近结束时才启动流程，将没有足够时间完成所有必要步骤并按时提交完整的申请。

为使申请获得审议，申请人必须在收到发票后支付 gTLD 评估费，且付款不得晚于申请提交期结束后的七日内，详见第 3.3 节：费用和付款。

提交申请后，除依据第 3.8 节：申请变更请求所述流程进行变更外，申请人不得进行其他任何更改，且变更请求只能在字符串确认日之后提交。

3.1.2 TLD 申请管理系统

申请必须通过 TLD 申请管理系统 (TAMS) 以电子方式提交。不允许使用纸质申请。建议申请人在提交申请前查阅新 gTLD 项目网站上的 TAMS 用户指南¹，获取如何使用该系统的指导说明以确保理解正确。

3.1.3 申请问题

申请将包含以下部分，供用户在注册时填写：

1. 组织信息。

2. 财务信息。

3. gTLD 申请信息。

为完成申请，用户必须回答附录 1：申请问题中列出的一系列问题，并按要求提供相关支持文件。系统将验证所有必填字段是否包含回复内容，确认之后申请人才能提交申请。

如果申请人打算提交多个申请，TAMS 将在创建组织记录时只接受一次组织和财务信息。对于申请人希望提交的任何其他申请，TAMS 只会提示申请人输入 gTLD 申请信息。

这意味着申请实体的组织及财务信息将在首次提交申请后被锁定。申请人应确保组织信息准确无误，并在提交首份申请前确认财务信息已涵盖申请人计划提交的所有申请。

提交后，在申请提交期内不得修改申请。申请提交期结束后，申请人可根据第 3.8 节：申请变更请求所述程序对申请进行修改。

3.1.4 申请的字符串

每份申请对应一个 gTLD，并且在适用情况下，可包含一个或多个可分配变体字符串。一份申请也可针对现有 gTLD 的一个或多个可分配变体字符串提出。²

3.1.5 替代字符串选择

为尽可能减少字符串争用情况的出现，申请人还可选择提交替代字符串，如第 5.1 节：替代字符串中所述。

3.1.6 申请和字符串类型

本节概述了新 gTLD 申请的各种申请类型，包括通用、社群、地理名称、保留名称、“.Brand”、IDN、现有 gTLD 的变体、新 gTLD 的主 IDN 变体，以及来自政府、国际政府间组织 (IGO) 和受支持申请人（政府/IGO 申请人和申请人支持计划申请人）等申请类型。每种类型可能都有其独特的要求和处理步骤，申请人在提交涉及第 7.1 节：字符串和申请类型的申请时应予以注意。

下表列出了各种申请类型，以及可能适用不同要求的具体方面。有关详细信息，参阅表 3-1 中链接的相应部分。

表 3-1：申请类型概述及处理过程中的主要差异

3.1.7 专用字符串（封闭型通用域名）

基准《注册管理机构协议》（附录 4）对“通用域名”的定义是：“由一个表示或描述通用类商品、服务、团体、组织或事物的词语或术语组成的字符串，而不是由可区分特定品牌商品、服务、团体、组织或事物的词语或术语组成的字符串”。根据基准《注册管理机构协议》中的相关内容，“专用”字符串对注册设定了资格标准，使注册仅限于单一的个人或实体，以及/或者该个人或实体的“附属机构”。注册管理运行机构不得运营供专属使用的 gTLD。这通常被称为禁止“封闭型通用”顶级域。潜在通用字符串的示例包括“.tree”和“.banana”，但需注意这些示例也可能符合“.Brand”顶级域的资格。

ICANN 董事会已做出决议，除非且直至制定并批准了相应方法和标准来评估拟议的封闭型通用域名是否符合公共利益，否则将不批准封闭型通用字符串。在申请过程中，申请人必须确认其未申请封闭型通用字符串，也无意运营封闭型通用字符串。

“.Brand”顶级域名不描述商品、服务、团体、组织或事物的一般类别，因此不受封闭型通用域名的禁令约束。基准《注册管理机构协议》规范 13 第 9.3 节⁹规定：“‘.Brand’TLD 是指满足以下条件的顶级域：(ii) 仅注册管理运行机构、其附属机构或商标被许可人可以是顶级域中域名的注册人，并控制与顶级域中任何级别的域名相关的 DNS 记录；”有关更多信息，请参阅第 7.3 节：“.Brand”TLD 资格评估。

3.1.8 提交前字符串验证

3.1.8.1 禁用名称识别

系统在允许申请人继续申请前设有内置检查机制。当申请人填写申请字符串时，系统将自动检查申请人选择的字符串（包括任何变体字符串）是否出现在第 7.2.1 节：禁用域名所述的禁用域名列表中。如果字符串出现在该列表中，系统将阻止申请人继续使用该字符串。要继续申请，申请人必须进行修改，选择其他未被禁用的字符串。

3.1.8.2 保留名称识别

当申请人输入申请字符串时，系统将自动检查该字符串（包括任何可分配变体字符串）是否出现在保留名称列表中。若出现此情况，将触发例外流程，要求申请人上传支持文件以证实其确为该预留名称所属实体。

3.1.8.3 DNS 稳定性审核

新 gTLD 字符串不得对 DNS 的安全性或稳定性造成不利影响。DNS 稳定性审核将确定所申请的 gTLD 字符串是否符合 DNS 和其他相关标准。此项评估包括验证字符串是否符合 gTLD 字符串的技术要求。只有成功通过这些检查，申请才能继续。

申请的 gTLD 字符串必须符合以下要求：

1. ASCII 标签必须是 NR-LDH 标签¹⁰ 或有效的 A-标签，如 RFC 5890 第 2.3 节所述¹¹。

2. NR-LDH 标签必须遵循 RFC1123 第 2.1 节的规定，完全由字母（字母字符 a-z）组成。¹²

3. IDN gTLD 字符串必须符合 IDNA2008¹³ (RFC 5890-5893) 以及所有对 IDNA2008 加以更新的标准通道 RFC。

4. IDN gTLD 字符串必须符合适用的根区标签生成规则。¹⁴有关 RZ-LGR 和申请处理的更多信息，请参阅第 3.1.8.3.1 节：根区标签生成规则。

5. 如果某个 gTLD 字符串被归类为根区中现有 gTLD 或已申请的主 gTLD 的变体字符串，则它必须是该主 gTLD 的可分配变体字符串（请参阅第 3.1.9 节：国际化域名）。RZ-LGR 是计算主 gTLD 的变体字符串及其处置值（无论是可分配字符串还是禁用字符串）的唯一依据。

上述验证已纳入并通过 TAMS 实施。这意味着，当申请人将字符串输入其申请时，将自动进行所述验证。

如果字符串未通过上述任何一项验证，申请人将收到一条错误消息说明检测到的问题，且申请将无法继续。

请注意，在第 7.7 节：域名冲突和第 2.5 节：安全性与稳定性部分，介绍了与稳定性和安全性审核相关的其他问题和要求。

3.1.8.3.1 根区标签生成规则

3.1.8.3.1.1 适用的 RZ-LGR 版本以及支持的文字和语言

IDN 对于实现多语言互联网至关重要。为确保 DNS 的安全和稳定，制定了根区标签生成规则 (Root Zone Label Generation Rules, RZ-LGR)¹⁵，以确定使用不同文字申请的主字符串及其可分配变体字符串的有效性。

DNS 用于标识符，而非用于书写语言或其文献，因此 RZ-LGR 不应要求在 DNS 中完整表达任何自然语言，同时由 RZ-LGR 生成的任何字符串也无需是某种语言中的词语。

将使用 RZ-LGR 第 6 版，该版本根据由基于社群的文字生成专家组（即“生成专家组”）制定、并经专家审核小组（即“整合专家组”）整合的提案，整合了以下文字和书写系统¹⁶。

阿拉伯文、亚美尼亚文、孟加拉文、中文（汉字）、西里尔文、梵文、埃塞俄比亚文、格鲁吉亚文、希腊文、古吉拉特文、果鲁穆奇文、希伯来文、日文（平假名、片假名、日文汉字[汉字]）、埃纳德文、高棉文、韩文（朝鲜文和韩文汉字[汉字]）、老挝文、拉丁文、马来亚拉姆文、缅甸文、奥里雅文、僧伽罗文、泰米尔文、泰卢固文、塔安娜文和泰文。

RZ-LGR 为每种文字或书写系统提供一套独特的 LGR。一种书写系统可能包含多种文字，例如，日语书写系统由日语平假名、日语片假名和日语汉字（汉字）三类文字组成。

3.1.8.3.1.2 不受支持的文字申请

RZ-LGR 仅验证已整合至该规则的文字或书写系统中的字符串。对于未整合至 RZ-LGR 适用版本的文字中的字符串，申请人将无法提交申请。

在这种情况下，潜在申请人应首先与语言文字社群合作，按照 RZ-LGR 程序将相关文字整合到 RZ-LGR 中。¹⁷ICANN 将积极支持此流程。潜在申请人可随时发送电子邮件至 globalsupport@icann.org，向 ICANN 发起此流程。如果相关文字已整合并在适用版本的 RZ-LGR 中可用，则申请人可在后续申请阶段提交申请。

3.1.8.3.1.3 使用 RZ-LGR 选择主字符串和或变体字符串

主字符串是申请人提交的主要字符串，该字符串必须根据 RZ-LGR 计算是有效的。主字符串的变体字符串也通过 RZ-LGR 进行计算，标记为可分配和禁用变体字符串。主字符串、可分配变体字符串和禁用变体字符串统称为“变体字符串集”。对于现有 gTLD，它被视为计算和提交其变体字符串集的主字符串。

如果申请人正在申请某个主字符串，那么该申请人还可以在单次申请中申请该主字符串的其他可分配变体字符串，但不能申请该主字符串的禁用变体字符串。现有 gTLD 的注册管理运行机构也可以在单次申请中申请该 gTLD 的可分配变体字符串，但不能申请该 gTLD 的禁用变体字符串。

从变体字符串集选择主字符串（前提是主字符串不是现有 gTLD）不会改变该变体字符串集当中的总字符串数量，但可能会改变此集合中可分配和禁用变体字符串的子集。因此，在选择主字符串时，申请人应考虑将要创建的相应可分配和禁用变体字符串。ICANN 在 https://lgrtool.icann.org 中提供的 LGR 工具可用于确定主字符串的可分配变体字符串。

3.1.8.3.1.4 使用 RZ-LGR 计算的结果

RZ-LGR 将应用于主字符串，以根据 RZ-LGR 来确定主字符串作为 TLD 是否有效。

RZ-LGR 将应用于主字符串或现有 gTLD 的变体字符串，以便：

1. 根据 RZ-LGR，确定变体字符串作为 gTLD 是否有效。

2. 确定该字符串是否是申请人指定的主字符串或现有 gTLD 的变体字符串。

3. 确定该字符串是否是主字符串或现有 gTLD 的可分配变体字符串。

混合了 LGR 不同文字码点的字符串可能会被标记为无效。

3.1.8.4 对提交前字符串验证提出质疑

如果申请人认为，由于提交前字符串验证被错误应用或编码错误，导致其无法提交申请或必须提供补充文件，则申请人有机会提出质疑，但提出质疑的时间不得晚于申请提交期截止前 14 天，¹⁸具体如下所述：

• 禁用名称识别：“禁用名称识别”自动化流程出现系统错误，导致申请人的字符串被错误归类为禁用名称，进而无法继续提交申请。请参阅第 3.1.8.1 节。

• 保留名称识别：“保留名称识别”自动化流程出现系统错误，导致申请人的字符串被错误归类为保留名称，进而申请人需按照保留名称例外条款的规定，提供必要的支持文件，方可继续提交申请。请参阅第 3.1.8.2 节。

• DNS 稳定性审核：“DNS 稳定性审核”自动化工具计算出现系统错误，且该已识别的该系统错误导致申请人未通过 DNS 稳定性审核，进而无法继续提交申请。此质疑机制不适用于 RZ-LGR 不支持的文字。请参阅第 3.1.8.3 节和第 3.1.8.3.1.2 节：不受支持的文字申请。

质疑专家组将在申请人提出质疑后五天内，告知提交前字符串验证的结果。

3.1.9 国际化域名

国际化域名 (IDN) 是指由非 ASCII 字符（对于顶级域名而言，ASCII 字符即 a-z 的字母）表示的域名。此类域名使用 ASCII 以外的文字（例如阿拉伯文或中文）字符构成。

ICANN 期望新 gTLD 的申请能够呈现多样性，IDN 即在此列；这不仅有望为全球互联网用户带来诸多新的用法和益处，同时还能促进选择多样性和数字包容性。

3.1.9.1 IDN 及其变体的规则

申请的 IDN 必须符合 IDNA2008¹⁹ (RFC 5890-5893²⁰) 及其所有后续版本。IDN 还必须符合适用版本的 RZ-LGR 规则。请参阅第 3.1.8.3.1 节：根区标签生成规则。

根据 IDNA2008，IDN 可以用 Unicode 字符表示（称为“U-标签”），也可以使用以“xn--”为前缀的等效 ASCII 映射字符表示（称为“A-标签”）。申请的 IDN（U-标签格式）必须长于一个字符。这意味着“U-标签”必须至少包含两个码点，且其通用类别值²¹需符合统一码标准定义的“L”属性。通用类别值为“M”的码点不会计入长度，以确定所申请的 IDN 是否为单个字符。有关其他字符串要求，另请参阅第 3.1.8.3 节：DNS 稳定性审核。

RZ-LGR 是计算所有现有 gTLD 和所有申请主字符串的变体字符串及其处置值（可分配字符串或禁用字符串）的唯一来源。

ICANN 提供的 LGR 工具可用于确定主 gTLD 或所申请字符串的可分配变体字符串。²²

3.1.9.2 IDN 申请提交

符合强制性字符串要求（包括 IDNA 2008）以及 RZ-LGR 的所申请 IDN 可通过 TAMS 提交。在算法检查过程中，如果 RZ-LGR 计算判定所申请的 gTLD 为“无效”或“禁用”（例如，申请的字符串为变体字符串），则申请提交系统将不接受此类不符合要求的字符串申请。有关更完整的检查项列表，请参阅第 3.1.8.3 节：DNS 稳定性审核。申请人可以对申请提交系统计算的 RZ-LGR 提出质疑。请参阅第 3.1.8.3.1 节：根区标签生成规则。

3.1.9.2.1 新的主 IDN 及其变体字符串的申请提交

申请人可以申请新的主 IDN 及其一个或多个可分配变体字符串。这些变体字符串将仅分配给与主 IDN gTLD 相同的申请人，并且在授权期间，必须使用相同的后端注册管理机构服务提供商。

可分配变体字符串可从使用 RZ-LGR 生成的字符串集当中申请。可分配变体字符串的申请不得先于其主 IDN gTLD 的申请。在同一轮次中申请的主 IDN gTLD 及其任何可分配变体字符串必须通过同一份申请提交。成功通过评估后，主 gTLD 及其申请的可分配变体字符串将通过同一《注册管理机构协议》分配给同一注册管理运行机构。申请人不得为新的主 IDN 申请禁用变体字符串（是否为禁用字符串由 RZ-LGR 计算判定）。有关可分配变体字符串申请费用的详细信息，请参阅第 3.3 节：费用和付款。

一旦主 IDN gTLD 提交申请，通常无法更改，但处于争用状态的“.Brand”国际化域名 gTLD 申请中所申请的主字符串除外（请参阅第 5.3 节：“.Brand”顶级域字符串变更请求）。²³

提交申请后，申请人可通过提交申请变更请求（第 3.8 节）撤回该申请中任何已申请的变体字符串，但不得添加该申请中最初未申请的任何其他可分配变体字符串。如果申请人撤回其主 IDN gTLD 的申请，则所有申请的变体字符串也将被撤回。

3.1.9.2.2 现有 gTLD 的变体字符串申请提交

申请人必须与现有 gTLD 的注册管理运行机构属于同一法人实体，才能申请该现有 gTLD 的变体字符串。所有变体字符串在授权期间必须与现有 gTLD 使用同一后端注册管理机构服务提供商。后端注册管理机构服务提供商必须通过 RSP 评估项目获得批准。²⁴

现有 gTLD 的可分配变体字符串可以从使用 RZ-LGR 生成的字符串集当中申请，并且必须在一份申请中提交。成功通过评估后，申请的可分配变体字符串将分配给现有 gTLD 的注册管理运行机构。注册管理运行机构需要过渡到 2026 轮次基准《注册管理机构协议》，且现有 gTLD 和所有变体字符串都将通过一份《注册管理机构协议》 进行分配。申请人不得为现有 gTLD 申请禁用变体字符串（是否为禁用字符串由 RZ-LGR 计算判定）。有关可分配变体字符串申请费用的详细信息，请参阅第 3.3 节：费用和付款。

提交申请后，申请人可撤回任何已申请的变体字符串，但不得添加该申请中最初未申请的任何其他可分配变体字符串。

3.1.9.3 要求和处理

3.1.9.3.1 现有 gTLD 变体字符串的处理优先级

作为特例，对于 2012 轮次中现有 gTLD 可分配变体字符串的申请，其处理将优先于所有其他申请人，包括选择参与优先级抽签的 IDN 申请人。请参阅第 3.7 节：申请处理顺序和优先级抽签。

3.1.9.3.2 同一主字符串或其变体字符串的多个申请人

如果不同的申请人申请同一变体字符串集当中的字符串，则此类申请将处于争用状态，并且只有一名申请人能够通过争用解决程序最终获选。这意味着，所申请的主字符串及其所申请的可分配变体字符串将作为一个字符串集参与任何争用解决程序，即社群优先评估（第 5.4 节）或 ICANN 新 gTLD 拍卖（第 5.6 节）（请参阅模块 5：字符争用集解决程序）。

对现有 gTLD 可分配变体字符串的任何申请，如果其申请人并非该现有 gTLD 的注册管理运行机构，则申请将被拒绝。

3.1.10 注册管理机构服务提供商选择

申请人必须指定哪些注册管理机构服务提供商 (RSP) 将在其申请进入授权阶段时提供关键的注册管理机构服务。已评估 RSP 列表可在“注册管理机构服务提供商 (RSP) 申请”页面上找到。²⁵

申请人可以聘请外部第三方 RSP，也可通过 RSP 评估项目寻求 ICANN 的批准，使自己作为 RSP 提供关键注册管理机构服务。

每个 RSP 无论其支持多少个 gTLD，只需评估一次，通过评估即可获得提供特定注册管理机构服务的资格。

3.1.10.1 提交申请时选择 RSP 的预期事项

建议申请人在提交申请时明确其 RSP 和预期的注册管理机构服务，以避免可能出现的处理延误。但是，申请人也可以在提交申请时不指定 RSP，而是选择在申请人评估和申请评估之前指定。

建议尽早进行选择 RSP 和注册管理机构服务，最好是在准备阶段，因为申请人可能会发现在申请提交期内与选定的 RSP 密切合作对于正确完成申请的这些环节非常重要。

如果申请人在申请人评估程序（模块 6）和字符串和申请评估程序（模块 7）时尚未确定能履行最低关键注册管理机构职能的 RSP，则可选择扩展评估，以便申请人有更多时间从其选择的 RSP 处提供所需信息。

申请人可以通过申请变更请求（第 3.8 节）流程，在提交 gTLD 申请后指定或更改其选择的 RSP。

在签约过程中，ICANN 将向申请人确定的 RSP 寻求确认，确认其知悉为该申请人和 gTLD 提供支持的计划。²⁶

3.1.10.2 注册管理机构职能和 RSP 类型

基准《注册管理机构协议》要求注册管理运行机构支持以下关键注册管理机构职能：域名系统 (DNS)、域名系统安全扩展 (Domain Name System Security Extensions, DNSSEC)、可扩展供应协议 (Extensible Provisioning Protocol, EPP)、注册数据访问协议 (Registration Data Access Protocol, RDAP) 和数据托管。RSP 分为四种类型，每种类型都提供一组独特职能，以完成关键的注册管理机构职能运作：

1. 主 RSP：负责运营 gTLD 的注册数据库、托管域名注册数据，并为 gTLD 运营 EPP 和 RDAP 服务。一个 gTLD 只能有一个主 RSP。

2. DNS RSP：负责为 gTLD 运营一个或多个 DNS 服务器。一个 gTLD 可以使用多个 DNS RSP。

3. DNSSEC RSP：负责执行 DNSSEC 所需的加密运营。一个 gTLD 只能有一个 DNSSEC RSP。

4. 代理 RSP：负责执行注册验证，以遵守指定司法管辖区内适用的当地法律要求。这是一项可选的附加注册管理机构服务，必须通过 RSP 评估项目获得 ICANN 批准。²⁷一个 gTLD 可以使用多个代理 RSP，每个 RSP 对接一个不同的司法管辖区。

一个组织可在 RSP 评估项目中接受一种或多种 RSP 类型的评估。²⁸

在申请流程中，申请人将被要求提供其计划使用的 RSP 以及拟在其申请的 gTLD 中提供的附加注册管理机构服务（如有）。申请人必须至少提供一个主 RSP、一个 DNSSEC RSP 和一个 DNS RSP。

3.2 行政核查和“揭晓日”筹备

申请提交期结束后，ICANN 将进行必要的行政核查，并核实是否已收到评估费用。ICANN 将审核已提交的申请列表，并将相同字符串的申请归入字符争用集，为“揭晓日”做准备。

针对所有申请进行的行政核查预计在约 8 周内完成，具体时间取决于申请总量。如果申请数量过多，导致 ICANN 无法在指定期限内处理所有申请，ICANN 将尽快发布更新的时间表。

3.3 费用和付款

本节介绍申请人应支付的费用，包括与付款相关的说明。

3.3.1 gTLD 评估费

收取 gTLD 评估费是为了让 ICANN 能够补偿与新通用顶级域项目关联的所有适用成本。这可确保本项目有充足的资金和收入，从而无需通过 ICANN 其他资金来源进行补贴（例如 gTLD 注册管理运行机构和注册服务机构支付的费用，以及来自 ccTLD 和地区互联网注册管理机构的捐款）。ICANN 估计，2026 轮次项目的评估、签约和授权流程将持续到 2030 年 6 月 30 日左右²⁹，届时提交的所有申请预计都将完成所述 申请人历程（模块 1）。gTLD 评估费用涵盖该时间范围内所有必需的评估，包括适用情况下的扩展评估。

ICANN 认识到可能会出现例外情况，需要针对少数申请将这些服务延长至 2030 年 6 月之后。

所有申请人申请的每个 gTLD 评估费均为 227,000 美元，但符合申请人支持计划 (ASP) 的申请人提交的申请以及符合下文所述标准的变体申请除外。该费用应于收到发票后缴纳，且 ICANN 须在申请提交期结束后七日内收到全额款项。如果申请人未在此七日内支付 gTLD 评估费，其申请通常将不再继续处理，并会被撤销。在极少数情况下，如果 ASP 申请人仍在等待 ASP 的评估结果，可能需要先提交一个申请而暂不付款。该 gTLD 申请将被搁置，直到确定相应的 gTLD 评估费并收到付款为止。

3.3.1.1 含变体字符串的申请的 gTLD 评估费

3.3.1.1.1 适用于新申请人

gTLD 评估费涵盖一个主 gTLD 和最多四个变体字符串的申请。如果申请人希望在一个主字符串下申请的变体字符串超过四个，则对于超出第四个之后的每个额外可分配变体字符串，申请人必须支付 227,000 美元 的评估费用。额外费用和有条件评估（请参阅第 3.3.2 节）可能适用。

3.3.1.1.2 适用于 2012 轮次的现有 gTLD 注册管理运行机构

在 2026 轮次中，2012 轮次的 gTLD 注册管理运行机构可以申请其现有 gTLD 的最多四个变体字符串，并可享受一次性的申请费豁免。如果申请的变体字符串超过四个，则对于超出第四个之后的每个额外可分配变体字符串，申请人必须支付全额 gTLD 评估费。额外费用和有条件评估（请参阅第 3.3.2 节）可能适用。

3.3.1.2 符合申请人支持计划资格的申请人的 gTLD 评估费

合格的 ASP 申请人将获得 75-85% 的 gTLD 评估费减额。因此，合格 ASP 申请人减额后的 gTLD 评估费将在 34,500 美元至 56,750 美元之间（其中包含为确认 ASP 财务可行性而提交的 2,500 美元保证金）。具体金额将取决于合格 ASP 申请人的最终数量。ICANN 将通知符合资格的 ASP 申请人其可享受至少 75% 的折扣，最终折扣金额预计在 ASP 申请提交期结束后 12-16 周内公布。如第 3.3.1.1 节：含变体字符串的申请的 gTLD 申请费用中所述，gTLD 评估费的折扣最多涵盖四个变体字符串。申请超过四个变体字符串的受支持申请人将需要为超出第四个之后的每个额外变体字符串支付 227,000 美元的评估费用。

3.3.2 有条件评估

除了 gTLD 评估费涵盖的必需评估外，还有多项有条件评估，申请人可以选择或需要接受相应评估才能获得特定资质或豁免。申请人支付的有条件评估的费用同样旨在补偿与开展这些评估关联的费用，评估可能由第三方供应商执行或给予支持。这将确保本项目有充足的资金和收入，从而无需通过 ICANN 其他资金来源进行补贴（例如 gTLD 注册管理运行机构和注册服务机构支付的费用，以及来自 ccTLD 和地区互联网注册管理机构的捐款）。其中部分有条件评估，例如域名冲突高风险字符串缓和计划审核，仅在评估流程后期才会开放。有关其中每项评估的更多详情，请参阅下表中列出的相应部分，表 3-2：有条件评估和费用。

ICANN 将在需缴纳有条件评估费时通知申请人。通知时间可能在申请提交期结束后不久，也可能是在评估进行之时。如果申请人未能支付有条件评估费用，根据有条件评估的类型，申请人可能需要提交申请变更请求，以删除申请中的该部分内容以便继续。否则，必须按时支付所需的有条件评估费用，以免失去资格。³⁰

对于标有一个星号 (*) 的评估，合格 ASP 申请人将获得与其 gTLD 评估费相同的减额比例。在批准此项费用减额之前，ICANN 将要求 ASP 申请人验证其是否继续有资格获得进一步的财务支持（另请参阅“ASP 条款和条件”）。³¹

对于标有两个星号 (**) 的域名冲突高风险字符串缓和计划评估，必须对变体集当中标识为高风险的字符串进行此项评估。因此，变体集每个标识为高风险的字符串均须支付有条件费用。

表 3-2：有条件评估和费用

3.3.3 退款

3.3.3.1 gTLD 评估费退款

在某些情况下，申请人可以请求部分退还³²已在申请流程中支付给 ICANN 的 gTLD 评估费用，具体如下所述。退款金额将根据请求撤回或申请状态变更为“已终止”时所处的流程阶段而有所不同（请参阅 第 3.9 节：申请状态）。

此申请流程将包含三个不同的退款窗口期，具体如下：

1. 第一个窗口期为从收到申请人的 gTLD 评估费之日起，到字符串确认日之后的十天内；在此期间，可退还已支付 gTLD 评估费的 65%。

2. 第二个窗口期为从字符串确认日之后的第 11 天起，到申请评估和申请人评估启动之日止；在此期间，可退还已支付 gTLD 评估费的 35%。申请人将在申请评估与申请人评估预计启动时收到通知。该通知将在字符串评估阶段结束之后发出，若适用则在字符争用集解决程序完成后发出。

3. 第三个窗口期为从申请评估和申请人评估启动之日起，到申请人与 ICANN 签订《注册管理机构协议》之日止；在此期间，允许退还已支付 gTLD 评估费的 20%。

有关上述窗口期以及在这些窗口期内进行的评估和流程的更多详细信息，请参阅模块 1：申请人历程。

如果申请状态为“已撤回”、“不再继续”或“已终止”，则已支付但尚未开始评估的有条件评估费也可以退还。

3.3.3.1.1 申请人撤回

申请人可以在与 ICANN 签署《注册管理机构协议》之前的任何时间随时撤回申请。选择撤回申请的申请人可以请求部分退还已支付给 ICANN 的费用，具体规定如下。退款请求必须作为撤回请求的一部分提出。如果申请人当时未请求退款，将丧失以后请求退款的权利。

3.3.3.1.2 已终止的申请

如果申请人的申请不再继续且状态为“已终止”（请参阅第 3.9 节：申请状态），ICANN 将通知该申请人。收到 ICANN 通知后，申请人可按照退款窗口期和符合退款条件的 gTLD 评估费相应可退款比例申请退款，如下所述。要获得退款资格，申请人必须在收到“已终止”状态通知后的 90 天内请求退款。未在此 90 天期限内请求退款的申请人将被视为放弃其请求退款的权利。

3.3.3.1.3 因实质性变更产生的退款

任何因《申请人指导手册》或附录 6：可预测性框架中定义的项目流程发生实质性变更而撤回的申请均有资格获得退款。作为对《指导手册》或项目流程进行任何实质性变更决策的一部分，ICANN 董事会将确认申请人是否有资格获得退款，以及已支付的 gTLD 评估费中可获得退款的百分比。因该等变更而撤回申请的申请人必须提供正式声明并附上支持文件，以证明该变更：(1) 改变了其申请的状态；或 (2) 影响了其申请的评估结果；或 (3) 对申请人造成了重大的财务或运营影响；或 (4) 对其申请的处理和评估时间表造成了重大影响。³³根据第 3.3.3.1.1 节：申请人撤回的规定，因上述变更产生的退款必须作为撤回请求的一部分提出。

3.3.3.1.4 被认定为域名冲突高风险字符串的退款

如果申请人在其申请的字符串被认定为存在高风险域名冲突后的 90 天内决定撤回申请，并且未提交域名冲突高风险字符串缓和计划以供评估，则有资格获得已支付 gTLD 评估费 100% 的退款。任何在上一轮中被判定为存在高域名冲突风险和因此未获批准的字符串申请，则无资格获得此项退款（.HOME、.CORP、.MAIL）。

3.3.3.1.5 因 IDN ccTLD 申请流程导致字符串被淘汰时的退款

如果 gTLD 申请人已获得相关政府或公共权威机构的支持或无异议表态，但该 gTLD 申请因与 IDN ccTLD 申请流程中申请的字符串视觉相似而无法继续，则应向该 gTLD 申请人全额退还 gTLD 评估费。此项退款适用的前提是，该 gTLD 申请是在成功通过评估的 ccTLD 公布之前提交的。

3.3.3.2 申请量达标退款

在收到任何申请之前，ICANN 采用保守方法对实施成本的回收进行了估算。为确保实施工作能够收回成本，gTLD 评估费当中与预估实施费用相关的部分是基于 1,000 份已全额付款申请这一假设计算得出。因此，若满足以下两个条件，则可能适用申请量达标退款：1) 收到超过 1,000 份申请；且 2) 2026 轮次的实施成本已收回。

申请人需在提交申请时表明，若符合适用条件，是否希望获得申请量达标退款。³⁴如果申请人未选择接收申请量达标退款选项，将被视为放弃接收该项退款的权利。在揭晓日之后，ICANN 将通知选择申请量达标退款选项的申请人（如适用）。申请量达标退款金额将根据收到的申请数量和最终实施成本计算。仅 2026 轮次中已缴费的申请人具备申请量达标退款资格，符合条件的 ASP 申请将按所缴费用比例获得相应退款。

3.3.4 某些情况下需要支付的费用

在需要进行特殊流程环节时，申请人可能会产生额外的费用和成本。更多详情，请参阅涉及这些特殊流程的相应章节。此类可能的额外费用包括：

• 异议和申诉成本。请参阅第 4.5.6 节：异议和申诉成本。

• 拍卖。请参阅第 5.6 节：ICANN 新 gTLD 拍卖。

• “.Brand”顶级域字符串变更请求文档验证。请参阅第 5.3 节：“.Brand”顶级域字符串变更请求。

3.3.5 注册管理机构运营期间的费用

对于通过全部申请流程并成为注册管理运行机构的申请人，其作为注册管理运行机构还需缴纳其他费用。这些费用在附录 4：基准《注册管理机构协议》中列出，包括注册管理机构固定费用和注册管理机构交易费用。

3.3.6 支付方式

必须通过电汇、自动清算所 (Automated Clearing House, ACH) 直接支付、国际 SWIFT 付款或 ICANN 批准的其他方式向 ICANN 付款。不接受支票、现金和信用卡付款。有关付款的说明可在 TAMS 中获取。

争议解决服务提供商 (DRSP) 的费用应按照该提供商的规则交纳。请参阅第 4.5.6 节：异议和申诉成本。

3.4 揭晓日

除非出现特殊情况，ICANN 预计将在申请提交期结束后的九周内，于揭晓日在新 gTLD 项目网站³⁵公布所有通过行政核查的申请清单，其中包含相关申请字符串及任何变体字符串和替代字符串（如适用）。每份申请的公开部分也将同步发布，同时公布包含相同字符串申请的字符争用集列表。自揭晓日开始，针对字符争用集中的申请，特定沟通与活动将被禁止。请参阅第 5.2.3.1 节：禁止的通信与活动。

3.5 替代期

申请人获得所有申请字符串、任何变体字符串和替代字符串的完整列表后，将有机会用替代字符串来替代原始申请字符串。已经选择了符合资格替代字符串的申请人，将拥有 14 天的更换周期，需通过 TAMS 向 ICANN 告知其替换意向（即用申请中指定的替代字符串替代原申请字符串）。请参阅第 5.1 节：替代字符串。

3.6 字符串确认日

在字符串确认日，ICANN 将发布更新后的申请列表及对应的选定字符串（如上所述，可为原始字符串或替代字符串）。由相同字符串申请组成的字符争用集更新列表也将同步发布。请参阅第 5.2.4.1 节：申请相同 gTLD 字符串导致争用。

3.7 申请处理顺序和优先级抽签

分配给申请的优先序号决定了 ICANN 处理申请流程后续各阶段的大致处理顺序。优先序号还将用于确定评估结果发布和签署《注册管理机构协议》的大致顺序。³⁶

申请的优先序号一旦分配将不会更改，也不能在申请人或申请之间转让。

IDN 申请的优先级排序另有特定的适用规则。请参阅第 3.7.3 节：IDN 申请的优先级排序。

3.7.1 优先级抽签

申请处理的优先次序将通过优先级抽签活动（简称“抽签”）确定，以现场直播的形式进行。在抽签活动中，系统将为抽签池中每份参与抽签的申请手动抽取一张纸质票签，并分配一个优先序号。

是否参与抽签为自愿选择。有关如何为未参与抽签的申请分配处理顺序的详细信息，请参阅第 3.7.4 节：未参与优先级抽签的申请。

3.7.2 参与抽签

优先级抽签预计将在字符串确认日后 30 天内进行。抽签的票签费用为 100 美元，且必须现场购买；不提供在线购买方式。如需参加抽签，申请人必须通过指定代表或代理人，现场为其希望优先处理的每份申请购买一张票签。

申请人不能亲自参加抽签活动，但可以在线观看现场直播。

ICANN 预计将至少提前 30 天公布抽签活动的全部细节。

每份申请只能购买一张票签。如果申请人提交了多份申请，则申请人必须为其希望参与抽签的每份申请分别购买票签。

3.7.3 IDN 申请的优先级排序

参与抽签的申请将按 500 份为一组随机抽签，直到所有申请都获得一个优先序号。在抽签中，IDN 申请将按照以下顺序和规则确定优先级排序：

1. 2012 轮次 IDN gTLD 可分配变体字符串的 IDN 申请。

   • 作为本申请轮次的例外，2012 轮次中 IDN gTLD 可分配变体字符串的申请将优先于其他新 gTLD 申请进行处理，包括所有其他已进入抽签环节的 IDN 主字符串申请。这些申请将自动参与抽签，无需申请人购买票签。这些申请将单独划分出来并优先进行抽签。

2. 2012 轮次 IDN gTLD 变体字符串的所有申请结束抽签后，如果选择参与抽签的剩余 IDN 申请少于 125 份：

   • 所有 IDN 申请将优先于任何非 IDN 申请进行抽签并分配优先序号。

3. 但是，若选择参与抽签的剩余 IDN 申请达到或超过 125 份：

   • 第一组 500 份申请中，25%（125 份）将为 IDN 申请，该部分 IDN 申请将通过随机抽选方式产生。这些被选中的 IDN 申请将优先进行抽签并分配优先序号。

   • 第一组抽取优先序号的申请中，其余 75%（375 份）的申请将包含 IDN 和非 IDN 申请。这些申请将从参与抽签的剩余申请池中随机抽选，并通过随机抽签方式确定优先级排序。

4. 对于后续每组 500 份选择参与抽签的申请：

   • 每组前 10% 的申请将为随机选择的 IDN 申请，先行抽签并排序，直至没有剩余的 IDN 申请。

   • 每组剩余申请将从剩余的 IDN 和非 IDN 申请池中随机选择，通过随机抽签确定优先级排序。

3.7.4 未参与优先级抽签的申请

未参与抽签的申请也将以 500 份为一组随机抽取并分配一个优先序号，但前提是所有参与抽签的申请都已完成抽签和优先级排序。例如，如果参与抽签所分配的最后一个优先序号为 1000，则未参与抽签的申请可获得的排名最前的优先序号为 1001。

在每组 500 份申请中，前 10% 必须为 IDN 申请，直至没有要抽签的申请为止。每组中剩余的申请将从剩余的 IDN 和非 IDN 申请池中随机选择，并进行优先排序。

3.7.5 根据优先序号进行处理的例外情况

ICANN 致力于在各阶段处理申请时均遵循既定的优先顺序。但是，此顺序可能会受到运营能力和其他申请相关问题的影响，包括但不限于：异议、GAC 共识性建议、扩展评估、字符争用集、ICANN 问责机制或因申请变更请求而暂停的处理。正在进行的处理活动可能会暂停，直至这些流程完成。为避免延误并确保其他申请的持续进行，ICANN 将按照优先顺序继续处理下一份申请。一旦 ICANN 确定影响暂停申请的问题得以解决，将根据分配的优先序号恢复对该申请的处理。

3.8 申请变更请求

本节介绍申请人更新其申请中不准确或过时信息以及根据需要进行其他变更的相应流程。此类申请变更请求 (ACR) 将由 ICANN 根据变更请求判定标准（请参阅第 3.8.2 节：变更请求判定标准）进行审核，并由 ICANN 决定是否批准。

实质性 ACR 将按照第 3.8.3 节：申请变更请求类型和所需流程中的说明予以公布，启动一个为期 30 天的评议期，以便公众有机会提供意见。

3.8.1 申请变更请求概述

在整个申请处理过程中，从字符串确认日到《注册管理机构协议》的执行，申请人均可请求更改或更新组织信息、财务或申请信息。

若在项目实施期间，针对申请问题（附录 1）提交的信息或机构信息因评估结果（例如 ICANN 与申请人达成协议）等原因发生不实、不准或过时的情况，³⁷申请人必须立即提交申请变更请求（且无论如何须在知悉触发该义务的事实或情况后七日内提交）。如果发生³⁸ 实质性变更，ICANN 保留要求重新评估申请的权利，此举可能会产生额外费用。如果情况发生任何变化且该变化将会致使申请中提供的任何信息错误或造成误导，而未能通知 ICANN，则可能导致申请无法继续。

申请人可请求更改其申请的诸多方面，具体如第 3.8.3 节：申请变更请求类型和所需流程中所述。然而，申请人不得更改所申请的字符串，除非该申请人已获得“.Brand”顶级域的资格（请参阅第 7.3 节：“.Brand”资格评估）且处于字符争用集中。“.Brand”字符串变更请求遵循第 5.3 节：“.Brand”字符串变更请求所述流程。³⁹

某些 ACR 可能需要重新评估或执行其他流程，如第 3.8.3 节：申请变更请求类型和所需流程中所述，这可能会给申请人带来额外费用。有关评估与费用的详细信息，请参阅模块 6：申请人评估、模块 7：字符串与申请评估及第 3.3 节：费用和付款。

对于受支持申请人所提交的 ACR，还将结合其通过申请人资助计划获得进一步资金支持的资格进行考量。请参阅申请人支持计划条款和条件。⁴⁰

3.8.2 变更请求判定标准

在评估每个 ACR 时，ICANN 将根据七项标准考察所有可用信息，制定这些标准是为了在允许对申请人特定信息或申请内容进行必要更新的同时，确保所有申请人都能享有公平公正的流程。每项标准的权重可能因变更请求和申请的具体情况而异，包括相关的申请人和字符串。在判定是否批准变更时，将均衡考虑以下因素：

1. 更正提交错误：此标准适用于申请人请求变更以更正错误的情况。申请人必须提供足够的信息来支持该请求。此类请求很少见，但一旦提交，此项标准即拥有重大权重。

是否有证据支持所述声明或主张，即请求变更的唯一目的是更正错误？

2. 解释说明：此标准要求申请人对所请求的变更提供解释。如果未提供解释，申请人将获得补救机会。

是否提供了合理的解释？

3. 变更事由：

请求变更是否为了回应第三方的意见，例如申请评议、异议、GAC 共识性建议或 GAC 成员早期预警？请求变更是否为了反映组织变更（例如，组织名称或邮寄地址的变更）？

4. 先例：ICANN 会评估批准该项变更请求是否会开创新的先例，或是否与之前批准的类似请求相一致。在新通用顶级域项目的现阶段，开创新先例的请求不太可能获得批准。

该变更是否与其他已获批准的变更类似？该变更是否会导致其他人提出类似的变更请求，从而影响第三方或对项目造成不良影响？

5. 对第三方（包括其他申请人）的影响：ICANN 会评估变更请求是否对第三方（尤其是其他申请人）造成实质性影响。如果变更可能对其他申请人的状态造成实质性影响，则此项标准将拥有重大权重。

变更会对第三方（包括其他申请人）产生什么积极或消极的影响？这对广大社群而言公平吗？它会产生不公平的优势或劣势吗？

6. 实质性影响：ICANN 会评估变更请求将对申请状态及其竞争申请、字符串、字符争用集以及项目任何其他流程（如社群优先评估）产生何种影响。实质性变更不会自动造成申请被拒绝，但会影响其他标准的权重。

变更是否会影响评估结果、字符串争用或可能导致异议？

7. 时间影响：此标准用于确定变更请求是否会从时间上影响上述第 4-6 条标准。如果发现变更请求从时间上会对上述标准有影响，则此标准将拥有重大权重。

是否从时间上以某种方式干扰了对申请的处理？

导致申请可公开部分发生实质性变化的变更，将开放 30 天的公共评议期。⁴¹需进行 30 天公共评议的变更将发布在新 gTLD 项目网站上，更新后的信息也将在该网站上显示。⁴²

3.8.3 申请变更请求类型和所需流程

下表列出了部分可能的 ACR 类型，明确了各类变更请求是否被允许，并详细说明了每种类型所需的流程。该表还对不同 ACR 类型将触发的两种截然不同的工作流程进行了区分。更多信息，请见下文的第 3.8.4 节：申请变更请求工作流程。

除表中所列内容外，还将根据 ACR 所影响的特定领域，重新进行相关评估（如字符串和申请评估程序（模块 7）以及申请人评估程序（模块 6）），具体将视个案而定。

申请变更批准与否可能取决于 ACR 和相应申请的实际情况和具体环境，包括申请人以及所涉及的字符串。如果 ACR 的批准需要重新评估，可能会收取额外费用。

表 3-3：申请变更请求类型和所需流程

3.8.4 申请变更请求工作流程

不同类型的 ACR 会触发不同的工作流程，如下所述。具体而言，若无特殊情况，ACR 将遵循以下两个工作流程之一：

• 申请变更请求：工作流程 1：除社群注册政策和注册管理机构自愿承诺外，其余所有领域的 ACR 均遵循工作流程 1。请参阅第 3.8.4.1 节。

• 申请变更请求：工作流程 2：与社群注册政策和注册管理机构自愿承诺相关的 ACR 遵循工作流程 2。

每个工作流程均是为满足与相应 ACR 类型相关的特定要求和考量事项而量身定制的。请参阅第 3.8.4.2 节。

3.8.4.1 申请变更请求：工作流程 1

所有 ACR（与社群注册政策和注册管理机构自愿承诺相关的 ACR 除外）均遵循下述工作流程：

1. 提交：申请人提交 ACR。

2. 行政核查：根据第 3.8.3 节：申请变更请求类型和所需流程中的表格所列，ICANN 将确定通常情况下是否允许该 ACR 类型。如果变更不被允许，ICANN 将通知申请人 ACR 未获批准。

3. ICANN 审核：ICANN 将根据前文所述的七项变更请求判定标准来审核变更请求材料。如需补充信息，ICANN 将要求申请人提供。

4. 裁定：审核完成后，ICANN 将通过以下方式向申请人通知其决定：

   1. 如果 ACR 未获批准，ICANN 将通知申请人。

   2. 如果 ACR 获得批准，ICANN 将把拟议变更发布到新 gTLD 项目网站，更新申请，并通知申请人。此外，ICANN 还将告知申请人以下结果之一：

      1. 无需评议期或重新评估（流程至此结束）。

      2. 需要评议期（请参阅步骤 5）。

      3. 需要评议期和重新评估（请参阅步骤 5 和 6）。

5. 评议期：如果需要评议期，将发布 ACR 以进行为期 30 天的意见征询。在此期间，社群将有时间审核并提交有关该申请变更的意见。

6. 重新评估：ICANN 将开具重新评估的费用发票（如适用）。付款后，ICANN 将在评议期内，同时对受影响的评估领域进行重新评估。

图 3-1：申请变更请求：工作流程 1

3.8.4.2 申请变更请求：工作流程 2

与社群注册政策和注册管理机构自愿承诺 (RVC) 相关的 ACR 均遵循下述流程。

1. 提交：申请人提交 ACR。

2. 行政核查：根据第 3.8.3 节：申请变更请求类型和所需流程中的表格所列，ICANN 将首先确定通常情况下是否允许该 ACR 类型。如果变更不被允许，ICANN 将通知申请人 ACR 未获批准。

3. ICANN 审核：ICANN 将根据前文所述的七项变更请求判定标准来审核变更请求材料。如需补充信息，ICANN 将要求申请人提供。

4. 裁定：ICANN 确定变更是否为实质性变更，并采取以下步骤：

   1. 如果不是实质性变更，则将拟议变更发布到新 gTLD 项目网站，并通知申请人（流程至此结束）。

   2. 如果是实质性变更，请参阅步骤 5。

5. 注册管理机构承诺评估 (Registry Commitment Evaluation, RCE)：实质性变更需要 RCE。

6. 裁定：完成 RCE 后，ICANN 将就请求的变更做出裁定。裁定包括以下几种结果：

   1. 如果请求的变更通过了 RCE，则继续执行步骤 7。

   2. 如果请求的变更未通过 RCE，则申请将不会按照 ACR 的要求进行更新，并且将在不进行所请求变更的情况下继续。

   3. 如果请求的变更未通过 RCE，且该变更是根据 GAC 共识性建议或在出现异议的情况下由专家组裁定而提出，同时经判定该申请在不进行所述变更的情况下无法继续，则申请将不再继续。有关此类型 RVC 的更多信息，请参阅 第 7.8.3.4 节：RVC 的添加、变更和删除。

7. 发布：所有提交的 RVC 或社群注册政策，将在完成 RCE 之后，连同各自的 ICANN 裁定结果一起发布。如果提交的 RVC 或社群注册政策经申请人与 ICANN 协商后需要进行任何变更以获得 ICANN 批准，则已批准的 RVC 或社群注册政策将与申请人提交的原始版本一起发布。

8. 评议期：将启动为期 30 天的评议期。ICANN 保留就该期间收到的意见与申请人重新展开协商或进行讨论的权利。

图 3-2：申请变更请求：工作流程 2

3.9 申请状态

申请将处于以下状态之一：

• 进行中：申请正在新 gTLD 项目流程中推进。

• 暂停：申请存在可能影响其进展的未完成事项，例如问责机制或异议。

• 已撤回：申请由申请人自愿终止。此过程不可逆。

• 待终止：申请不符合《申请人指导手册》中规定的标准，无法在本项目中继续推进。申请人应在 60 天内撤回申请，否则 ICANN 可将其申请状态更改为“已终止”。

• 已终止：该申请将不再继续参与本计划，且申请人已用尽所有可用的申诉和质疑途径。⁴⁸

• 已停用：此状态适用于申请人在替代字符串期结束后未选择继续推进的任何申请。此类申请在计划中已失效，将不再进入评估或授权阶段。

• 已签约：在《注册管理机构协议》完全签署后，即赋予“已签约”状态。申请人随后成为所申请字符串的注册管理运行机构。

• 已授权：该 TLD 已添加到 DNS 根区。