模块 7：字符串和申请评估程序

2026 轮次新 gTLD 项目代表着互联网基础设施进入了一个关键的演进阶段。各方对潜在的新域名后缀充满热情，而字符串和申请评估流程的设计，旨在保障 DNS 稳定性的同时，回应各利益相关方的关切。每一个字符串都必须经过细致分析，保证其唯一性和清晰度，防止与现有字符串或商标可能存在的混淆，从而确保其不会损害整个 DNS 的完整性。

对于特定申请类型而言，对申请人的社群参与度及其透明度和问责制承诺进行评估尤为重要。

模块 7 概述了相关评估流程，包括：

• 申请类型和处理方式概述。

• TLD 的类型审查，例如地理名称和国际化域名。

• 域名冲突缓和策略。

• 字符串相似性评估。

本模块将详细介绍为确保 DNS 稳定性和安全性而精心设计的这一必要流程。

7.1 字符串和申请类型

申请人可能会面临不同的流程要求和步骤，具体取决于申请类型和申请的字符串。这些差异可能会对以下方面产生影响：

• 申请问题：某些申请类型会要求申请人在申请过程中回答特定的问题（例如，与申请人社群目标相关的问题）。

• 优先级：某些申请类型可能会在优先级抽签中获得优先权（例如，IDN）。¹

• 评估：申请的性质、重点或目标可能需要进行专项评估（例如，地理名称）。

• 争用：争用解决程序可能会根据申请类型的不同而采用专项流程（例如，社群优先评估）。

• 《注册管理机构协议》：某些申请类型可能被视为可豁免遵守协议中的某些条款，而其他申请类型则可能需要在其基准《注册管理机构协议》中纳入专项条款（例如，行为准则豁免）。

• 费用：可能需要支付额外的评估费用或申请费用（例如，社群优先评估等有条件评估）。

申请人应查看本节信息，以了解不同申请类型可能存在的不同要求。²

7.1.1 普通申请

普通申请是指不属于第 7.1.2 节：特殊申请中定义的任一申请类型，且须遵守本《申请人指导手册》所规定的标准要求的申请。

7.1.2 特殊申请

特殊申请是指根据申请类型（如社群 gTLD 申请）、字符串类型（如 IDN）或申请人类型（如 IGO 或申请人支持计划申请人）的不同，可能需满足不同要求的申请。本节将简要介绍这些特殊申请类型。一个申请可能同时符合多个认定标准；例如，一个申请可能同时被归类为 IDN 申请和社群申请。

7.1.2.1 社群 gTLD 申请

提交申请时，申请人可以将所申请的 gTLD 字符串指定为社群 gTLD。³此类申请人必须以明确界定的社群利益为目的运营该字符串（请参阅第 5.4 节：社群优先评估）。提交社群申请的申请人在申请周期的各个阶段需遵守一些额外要求，具体包括以下方面：

• 申请问题：申请人要将其申请指定为社群申请，必须回答社群申请所特有的一系列问题。⁴如果选择参与社群优先评估 (CPE)，则申请人对这些问题的回答将纳入评估范围。请参阅附录 1：申请问题（第 7 组问题：社群 gTLD）。

• 评估：拟纳入《注册管理机构协议》、涉及所申请的“社群 gTLD”运营的“社群注册政策”，将通过“注册管理机构承诺评估 (RCE)”在申请评估期间完成评估；除非社群申请人选择参加“社群优先评估 (CPE)”，而该选项仅供社群申请用于解决字符串争用。如果申请人选择参与 CPE，RCE 将提前至申请评估阶段之前进行，因为该评估必须在申请有资格参与 CPE 之前完成。请参阅第 7.8 节：公共利益承诺、注册管理机构自愿承诺和社群注册政策。

• 争用：如果针对同一字符串与其他申请存在争用问题，申请人可选择参与社群优先评估（请参阅第 5.4 节）以及可能的 ICANN 拍卖。请参阅第 5.2 节：字符串争用和争用解决程序。

• 签约：申请人必须在其基准《注册管理机构协议》规范 12 中，列明经 ICANN 评估并批准的社群注册政策；若适用，还应列明在 CPE 过程中接受过评估的社群注册政策。请参阅第 1.2.15 节：签约。另请参阅下文第 7.8.4 节：社群注册政策中关于社群注册政策评估的内容。

• 费用：申请人如果选择参与 CPE，则必须支付额外的评估费用。请参阅第 3.3 节：费用和付款。

ICANN 将在申请评估阶段，对社群 gTLD 申请人拟纳入适用《注册管理机构协议》的所有社群注册政策进行评估。这些政策必须至少涵盖注册人资格和域名选择两方面内容。为确保一致性，对社群注册政策的评估，将遵循 ICANN 评估申请人所提出的所有补充承诺时采用的统一框架。有关此框架的更多信息，请参阅第 7.8 节：公共利益承诺、注册管理机构自愿承诺和社群注册政策。

若要在 CPE 期间对拟纳入《注册管理机构协议》的社群注册政策进行审议，则必须先在 CPE 之前的注册管理机构承诺评估 (RCE) 中，对这些政策进行评估。此举旨在确保申请人与 ICANN 能够就承诺达成一致，从而将其纳入适用的《注册管理机构协议》中。如果无法就上述承诺达成一致，这些政策将不纳入 CPE 的审议范围。

如果申请人将其申请指定为社群申请且该申请获得批准，则必须将申请评估期间与 ICANN 达成一致的社群注册政策纳入适用的基准《注册管理机构协议》规范 12 中。即使不存在竞争申请人，或者提交社群申请的申请人选择不参与 CPE 来解决争用问题，此要求依然适用。总而言之，社群注册政策的获批不仅是社群申请参与 CPE 的必要条件，也是该申请在 RCE 之后继续推进申请流程的必要条件。如果没有经 ICANN 批准纳入《注册管理机构协议》的社群注册政策，则无论社群申请是否存在争用问题，也无论申请人是否选择参与 CPE，该社群申请均无法继续推进。⁵

有关社群优先评估的更多信息，请参阅第 5.4 节：社群优先评估；另请参阅第 7.8 节：公共利益承诺、注册管理机构自愿承诺和社群注册政策。⁶

另外，规范 12 的注册管理机构承诺评估 (RCE) 流程也需要支付一定费用（请参阅第 3.3 节：费用和付款）。

7.1.2.2 地理名称申请

申请人可以将其申请指定为地理名称申请。⁷申请人须负责确认其所申请的 gTLD 字符串是否属于任何已界定的地理名称类别（请参阅第 7.5 节：地理名称），咨询相关政府或公共权威机构，并确定所需的政府支持级别。

此外，作为初始字符串评估的一部分，ICANN 将审核所有申请，以确定所申请的字符串是否符合地理名称的认定标准（本节后续内容将对此标准进行说明）。若申请人未自行将其申请指定为地理名称申请，但 ICANN 后续将其认定为地理名称申请，则该申请仍需遵守地理名称类别的额外要求。申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：申请人将被要求回答与所申请地理名称相关的额外问题。请参阅附录 1：申请问题。

• 评估：地理名称申请人必须提交相关政府机构出具的支持文件或无异议文件。地理名称专家组 (GNP) 将确定所申请的字符串是否代表地理名称；如有必要，还将对支持文件的相关性和真实性进行验证。请参阅第 7.5.3.2 节：地理名称审核。

• 费用：地理名称审核（第 7.5.3.2 节）将产生有条件费用。请参阅第 3.3 节：费用和付款。

7.1.2.3 保留名称申请

所有申请的 gTLD 字符串都会与保留名称列表和禁用名称列表进行对比。虽然禁用名称不可申请，但符合条件的实体可以申请保留名称，具体规定详见第 7.2 节：禁用名称和保留名称。⁸要申请此类名称，申请人必须遵循第 7.2.2.2.1 节：申请保留名称的例外流程中规定的流程。提交保留名称申请的申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：申请人将被要求回答与所申请保留名称相关的额外问题。请参阅附录 1：申请问题。

• 评估：保留名称的申请人必须提交相关文件，包括公司注册证书和母公司出具的函件，以及支持或无异议文件（如适用，此类文件可包含签字函件）。请参阅第 7.2.2 节：保留名称。

7.1.2.4 “.Brand”TLD 申请

申请人可自行将其申请指定为“.Brand”TLD。此申请类型允许申请人将其公司或品牌名称用作 TLD。⁹“.Brand”TLD 是与适用法律下有效的注册商标的文字元素（例如，名称、单词或短语）完全相同的字符串，¹⁰由申请人作为“.Brand”TLD 运营。¹¹提交“.Brand”TLD 申请的申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：申请人将被要求回答与“.Brand”TLD 申请相关的额外问题（例如其品牌/商标）。请参阅附录 1：申请问题。

• 评估：“.Brand”TLD 的申请将接受审核，以确认其是否有资格获得“.Brand”TLD 资质。¹²请参阅第 7.3 节：“.Brand”TLD 资格评估。

• 争用：如果某个申请与其他申请所申请的字符串相同，出现争用情况，则“.Brand”TLD 申请人可请求变更其申请的字符串以解决争用问题。请参阅第 5.2 节：字符串争用和争用解决程序。¹³

• 签约：如果符合资格，规范 13 将被纳入其基准《注册管理机构协议》中，以供签署执行。¹⁴请参阅第 1.2.15 节：签约。

• 费用：“.Brand”TLD 资格评估将产生有条件费用。请参阅第 3.3 节：费用和付款。

如果“.Brand”TLD 的申请人符合“.Brand”TLD 的资格，则规范 13 将被纳入其适用的《注册管理机构协议》中，且申请人还将获得行为准则 (CoC) 豁免。但在某些情况下，“.Brand”TLD 的申请人可能获得行为准则豁免，但不符合规范 13 的资格要求。

7.1.2.5 国际化域名申请

申请人可申请国际化域名 (IDN)。IDN 申请必须符合第 3.1.9 节：国际化域名中规定的要求，且申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 优先级：根据第 3.7 节：申请处理顺序和优先级抽签中确定的限制和要求，相对于非 IDN 申请，IDN 申请可能会获得优先处理。

7.1.2.6 现有 gTLD 的变体申请

现有注册管理运行机构将有机会申请现有 gTLD 的可分配变体字符串。¹⁵这些变体字符串的申请必须符合第 3.1.9 节：国际化域名中规定的要求，且申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：申请人将被要求回答与所申请变体字符串相关的额外问题。请参阅附录 1：申请问题。

• 优先级：根据第 3.7 节：申请处理顺序和优先级抽签中确定的限制和要求，相对于非 IDN 申请，可分配变体字符串的申请可能会获得优先处理。

• 评估：现有 gTLD 可分配变体的申请人将接受专家组审核，并需说明申请该变体的必要性（例如，解释为何将主字符串和变体字符串视为相同）。¹⁶其他要求可能包括：变体注册管理机构使用与主注册管理机构相同的注册管理机构服务提供商 (RSP)。请参阅附录 1：申请问题和第 7.10 节：字符串相似性评估。

• 签约：规范 14 将被纳入基准《注册管理机构协议》中，以供签署执行。请参阅第 1.2.15 节：签约。

• 费用：现有注册管理运行机构申请现有 gTLD 的可分配变体字符串时，最多可免除 4 个变体字符串的基本申请费；¹⁷超过四个变体字符串的申请会产生额外费用。请参阅第 3.3 节：费用和付款。¹⁸

7.1.2.7 包含一个或多个变体的新 IDN TLD 申请

申请人将有机会申请新的 IDN TLD 及其可分配变体字符串。新 IDN TLD 及其可分配变体字符串的申请必须符合第 3.1.9 节：国际化域名中规定的要求，且申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：申请人将被要求回答与所申请 IDN TLD 及其可分配变体字符串相关的额外问题。请参阅附录 1：申请问题。

• 优先级：根据第 3.7 节：申请处理顺序和优先级抽签中确定的限制和要求，相对于非 IDN 申请，IDN TLD（包括可分配变体字符串）的申请可能会获得优先处理。

• 评估：新 IDN TLD 及其变体字符串的申请人将接受专家组审核，并需说明申请该变体的必要性（例如，解释为何将主字符串和变体字符串视为相同）。¹⁹此外，还可能适用其他要求，例如变体注册管理机构与主注册管理机构使用相同的 RSP，以及确保主字符串和变体字符串的 TLD 类型一致。请参阅第 7.10 节：字符串相似性评估。

• 签约：规范 14 将被纳入基准《注册管理机构协议》中，以供签署执行。请参阅第 1.2.15 节：签约。

• 费用：申请主字符串及其变体字符串的新申请人，若申请的变体字符串数量不超过 4 个，除基础费用外，无需缴纳额外申请费。但是，除主字符串外，若申请的变体字符串数量超过 4 个，则会产生额外费用。请参阅第 3.3 节：费用和付款。²⁰

7.1.2.8 来自国际政府间组织或政府实体的申请

我们将接受来自国际政府间组织 (IGO)²¹ 或政府实体²²的申请。此类别的申请人应考虑第 7.5 节：地理名称中规定的地理名称相关要求，以及第 7.2 节：禁用名称和保留名称中规定的保留名称相关要求。申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 申请问题：这些实体可能会被要求回答与其特定组织有关的额外问题。请参阅附录 1：申请问题。

• 评估：任何此类实体均须提供相关文件，来证明其国际政府间组织或政府组织的身份（如适用）。请参阅第 7.5.3.2 节：地理名称审核和第 7.2.2.2 节：保留名称审核。

7.1.2.9 符合“申请人支持计划”资格的申请人的申请

在本轮申请开启前，潜在申请人有机会申请参与“申请人支持计划”。申请参与的申请人将依据《申请人支持手册》中规定的标准接受评估。“申请人支持计划”的申请不同于新 gTLD 申请。“申请人支持计划”申请人还必须符合本《申请人指导手册》中规定的新 gTLD 申请的相关要求和资格标准。

符合“申请人支持计划”资格的申请人需注意，在申请周期的以下环节，该类申请可能存在特殊要求：

• 争用：参与 ICANN 拍卖的“申请人支持计划”申请人将获得竞标积分。请参阅第 5.6.5 节：申请人支持计划申请人在拍卖中获得的竞标积分。

• 签约：如果申请人成功获得“申请人支持计划”的支持，且其申请在拍卖中胜出，则该申请人在至少三年内不得转让《注册管理机构协议》，也不得进行任何控制权变更。请参阅第 1.2.15 节：签约。

• 费用：符合“申请人支持计划”资格的申请人将有资格享受申请费用及有条件评估费用的减额。有关更多信息，请参阅第 3.3 节：费用和付款以及《申请人支持计划手册》。²³

7.1.3 变更申请类型

在某些情况下，申请人可能希望变更其申请类型。允许或不允许进行此类变更，具体取决于申请类型。例如，不允许申请人变更社群 gTLD 的申请类型。如需详细了解允许对申请类型或字符串类型进行哪些变更，请参阅第 3.8 节：申请变更请求。

7.2 禁用名称和保留名称概述

部分名称被纳入禁用名称范围，因此不得作为 gTLD 字符串使用。禁用名称列表的制定参考了各种来源和意见反馈，如下文所述。另有部分名称根据共识性政策保留在顶级域层级，由 ICANN 负责维护此列表。²⁴

注：在 2012 年《申请人指导手册》中，名为“不符合授权资格的字符串”的列表现在称为“保留名称列表”，之前名为“顶级保留名称列表”的列表现在称为“禁用名称列表”。

如第 3.1.8 节：提交前字符串验证中所述，所有申请的 gTLD 字符串及其变体字符串都将与保留名称列表和禁用名称列表进行对比。该比对流程可确保所申请的 gTLD 字符串未被列入这两份列表。申请人可在 TAMS 中输入拟议字符串，以检查该字符串是否出现在禁用名称列表或保留名称列表中。

此外，不符合 DNS 允许字符框架要求的禁用名称和保留名称将根据共识性政策转换为仅包含字母、数字和连字符的 DNS 标签。²⁵

7.2.1 禁用名称

根据共识性政策，已列入禁用名称列表的 gTLD 字符串及其可分配变体不符合当前轮次或未来任何申请轮次的申请资格。但该列表不适用于已授权到根区的 gTLD。

以下 gTLD 字符串及其可分配变体字符串已列入禁用名称列表（具体列表详见脚注），因此不得进行申请：

• 特殊用途域名：此类字符串是依据相关技术标准而保留，用于与授权不一致的目的，并在 IANA 的“特殊用途域名”(Special-Use Domain Names) 注册表中明确注明。^26,27,28

• 技术标准：有关更多详情，请参阅第 3.8.3 节：DNS 稳定性审核。

• 与地理名称相关的国家或地区域名：请参阅第 7.5 节：地理名称。

• ICANN、IANA 和 IETF 相关机构及互联网基础设施：此类机构包括 ICANN 的支持组织 (SO) 和咨询委员会 (AC)、²⁹地区互联网注册管理机构、³⁰IETF 机构，³¹以及通过共识性政策纳入的系统标识符等等。^32,33

表 7-1：ICANN、IANA 和 IETF 相关机构及互联网基础设施：

• 其他非获准字符串：

  • 已授权 TLD。³⁴

  • 已在之前的 gTLD 申请轮次中提交且仍在处理中的 gTLD 字符串。³⁵

  • 已成功通过评估的现有 ccTLD。

  • 当前作为 IDN ccTLD 申请的字符串。

  • 所有其他单字母或双字母 ASCII 字符串。

7.2.1.1 禁用名称识别

当申请人填写申请字符串时，系统将自动检查申请人选择的字符串（包括任何变体字符串）是否出现在禁用名称列表中。如果字符串出现在该列表中，系统将阻止申请人继续使用该字符串。要继续申请，申请人必须进行修改，选择其他未被禁用的字符串。

7.2.1.1.1 禁用名称识别质疑

若申请人认为，因“禁用名称识别”自动流程出现系统错误，导致其字符串被错误归类为禁用名称，进而无法提交申请或需补充文件，则申请人有机会提出质疑，但提出质疑的时间不得晚于申请提交期截止前 14 天³⁶（请参阅第 1.2.14.2 节：评估质疑和第 3.1.8.4 节：对提交前字符串验证提出质疑）。

7.2.2 保留名称

保留名称评估流程分为两部分：一是保留名称识别，即通过自动检查确定申请的字符串是否出现在保留名称列表中；二是保留名称审核，其中包括申请人申请有限国际 IGO-INGO 名称的例外流程，以及对所需文件的核验环节。³⁷

以下有限国际 IGO-INGO 字符串已列入保留名称列表，仅可由相关实体通过例外流程进行申请，但申请实体须按下文第 7.2.2.2 节：保留名称识别中详述的要求，提交相应文件：

• 根据 IGO-INGO PDP 工作组³⁸关于保护所有 gTLD 中 IGO-INGO 标识符的建议而添加的名称，^39,40包括其可分配变体字符串，经核实后可获得授权资格。具体包括：红十字会与红新月会 (RCRC)、⁴¹国际奥林匹克委员会 (IOC)⁴² 以及国际政府间组织 (IGO) ⁴³–国际非政府间组织 (INGO) 名称。⁴⁴

7.2.2.2 保留名称识别

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

除这项检查之外，系统还将验证该字符串是否为保留名称的变体。若为保留名称的变体，申请人只有在以下两种情形下才能继续推进申请：一是该保留名称本身已作为主字符串申请，二是申请人能够提供确认材料，证实自己是与该保留名称匹配的 TLD 的注册管理运行机构。

7.2.2.2.1 保留名称识别质疑

如果申请人认为自动进行的保留名称识别流程出现系统错误，导致其字符串被错误归类为保留名称，则可以发起评估质疑。质疑提交日期不得晚于申请提交期截止前七天。

ICANN 将对该评估质疑进行审核。如果 ICANN 确定是因系统错误导致字符串被错误归类为保留名称，则会更正系统错误，使申请能够进入流程的下一个相应阶段。如果没有发现错误，申请可以继续推进，但必须在保留名称审核阶段满足保留名称相关标准。与保留名称相关的评估质疑不会产生任何有条件费用。即使在出现系统错误的情况下，申请人也有责任确保遵守所有与保留名称相关的要求。

7.2.2.3 保留名称审核

7.2.2.3.1 申请保留名称的例外流程

申请人可通过例外流程来申请保留名称列表中的字符串。在保留名称审核期间，专家组将评估例外情况，并核实申请人的支持文件，以确认申请人是有资格运营该保留名称的实体。有关保留名称列表中包含的具体字符串，请参阅第 7.2.2 节：保留名称。

要通过例外流程申请保留名称，申请人必须在申请时提交以下类型的文件：

• 公司注册证书和（如适用）母公司出具的函件。

• 支持或无异议文件，包含一封相关公共权威机构出具的签字函件（如适用）。

7.2.2.3.1.1 提交文件的验证

如果来自上述某家有限国际 IGO-INGO 的申请人使用例外流程申请保留名称列表中的名称（包括其可分配变体字符串），则将启动一项验证流程。此流程将确认申请人已提交符合要求的文件，证明其有资格申请该特定 TLD。对申请组织/实体采取的验证流程将在申请评估阶段进行。

ICANN 可能会咨询相关权威机构以进一步核实。

如果适用，为进一步帮助确定哪些相关政府或公共权威机构可作为请求的对象，请求者可以咨询相关的 GAC 代表。⁴⁵

7.2.2.3.2 保留名称审核的扩展评估

如果申请人没有提供足够的文件来证明其有资格申请保留名称列表中列出的 TLD，则将无法通过保留名称审核。

但是，如果申请被认定不符合保留名称审核的标准，申请人可请求进行扩展评估。在扩展评估期间，可能会提出澄清问题以获取更多信息。为确保及时处理，建议申请人尽快回复，最迟不得晚于收到澄清问题后的 21 天。如果提供的补充信息仍不满足保留名称相关标准，则申请将不会通过审核，且不会继续推进。

7.3 “.Brand”TLD 资格评估

申请人可自行将申请指定为“.Brand”TLD。此申请类型允许企业或公司将其公司或品牌名称用作 TLD。请参阅第 3.1.6 节：申请和字符串类型。

7.3.1 “.Brand”TLD 资格评估的条件

若申请人希望将所申请字符串指定为“.Brand”TLD，则必须接受“.Brand”TLD 资格评估。此评估的目的在于核验申请人是否符合“.Brand”TLD 的认定标准。对于通过“.Brand”TLD 资格评估的申请，如果进入授权阶段，则会将规范 13 添加到适用的基准《注册管理机构协议》中。有关规范 13 的条款，请参阅附录 4：基准《注册管理机构协议》。⁴⁶

申请人可以在申请中或通过提交申请变更请求来请求进行“.Brand”TLD 资格评估。请参阅第 3.8 节：申请变更请求。

7.3.2 “.Brand”TLD 资格评估的有条件费用

请求进行“.Brand”TLD 资格评估的申请人必须按照第 3.3 节：费用和付款中的规定，支付额外的评估费用。“.Brand”TLD 资格评估将在 ICANN 收到相关费用后进行。

7.3.3 “.Brand”TLD 资格评估的评估过程和结果

要获得“.Brand”TLD 认定资格，申请人必须提供一个或多个商标信息交换中心 (TMCH) 签名商标数据包 (SMD) 文件。有关资格要求，请参阅 TMCH 相关指南。⁴⁷

7.3.3.1 提交“.Brand”TLD 申请前与商标信息交换中心的接洽

计划将所申请字符串指定为“.Brand”TLD 的申请人，应在启动申请之前做好充分准备，确保在提交申请时能够证明其具备相应资格。

“.Brand”TLD 申请必须包含一个或多个商标信息交换中心 (TMCH) 签名商标数据包 (SMD) 文件，以支持“.Brand”认定。由于新增或调整 TMCH 备案可能需要数月时间才能完成，且可能涉及需直接向 TMCH 支付的费用，因此“.Brand”TLD 申请人应仔细核查其现有的 TMCH SMD 文件，或在实际可行的情况下尽快获取新的 SMD 文件。“.Brand”TLD 申请人在申请“.Brand”TLD 之前，应就 TMCH 相关事宜采取以下步骤（如适用）：

• 如果“.Brand”TLD 申请人尚未与 TMCH 建立联系，或 SMD 文件未涵盖其拟申请的字符串，则应启动 TMCH 审查流程。⁴⁸

• 确保任何所需的 TLD 标签均已列入 SMD 文件的 <mark:label> 元素中。“.Brand”TLD 申请人希望申请的任何字符串，都必须与申请提交前有效的 SMD 文件中的相应 <mark:label> 元素完全匹配。

• 确保主“.Brand”字符串的任何所需变体标签均已列入 SMD 文件的 <mark:label> 元素中。所有申请的“.Brand”TLD 变体字符串，都必须与申请提交前有效的 SMD 文件中的相应 <mark:label> 元素完全匹配。

• 确保 <mark:goodsAndServices> 元素正确且完整，并且包含申请人根据“.Brand”字符串变更请求（请参阅第 5.3 节）希望在“.Brand”字符串变更中使用的词语。用于补充所申请“.Brand”字符串的其他词语，应出现在提交“.Brand”字符串变更请求前有效的 SMD 文件的 <mark:goodsAndServices> 元素中。

如果用于补充所申请字符串的词语未出现在 SMD 文件中，申请人仍可使用其他替代文件来提交“.Brand”字符串变更请求。请参阅第 5.3.2 节：“.Brand”字符串变更请求的相关要求。

7.3.3.2 “.Brand”TLD 资格评估标准

“.Brand”TLD 资格评估将由“.Brand”TLD 资格评估专家组执行。申请“.Brand”TLD 的申请人必须证明其申请符合以下标准：

1a.所申请的 gTLD 字符串必须与提供的 SMD 文件中、经 TMCH 验证的注册商标的文字元素完全匹配；或者

1b.如果申请人使用“.Brand”字符串变更请求（第 5.3 节）更改了所申请的字符串，则最终字符串必须满足该请求中规定的所有要求。

2.申请人和最终字符串（包括所有可分配变体字符串）必须满足基准《注册管理机构协议》规范 13 所规定的所有要求。请参阅附录 4：基准《注册管理机构协议》。

申请人须在其申请中进行自我证明，确认其符合上述标准以及基准《注册管理机构协议》规范 13 中规定的标准（请参阅附录 4：基准《注册管理机构协议》）。此外，申请人还必须在其申请中确认不会将所申请的字符串用于通用用途。请参阅附录 1：申请问题中的第 13 组问题：“.Brand”TLD 及行为准则豁免。

7.3.3.3 “.Brand”TLD 资格评估澄清问题

ICANN 可能会在“.Brand”TLD 资格评估期间提出澄清问题。申请人需在 7 天内对行政方面的澄清问题做出回复，在 21 天内对实质性澄清问题做出回复。如果申请人未能在规定期限内回复，则可能失去机会，从而无法解决评估专家组发现的问题。

7.3.3.4 “.Brand”TLD 资格评估结果

“.Brand”TLD 资格评估结果将包含在申请与申请人评估报告中，如第 1.2.13 节：申请与申请人评估报告的发布中所述。

如果申请通过了“.Brand”TLD 资格评估，并进入授权阶段，则会将规范 13 添加到适用的基准《注册管理机构协议》中。

如果“.Brand”TLD 资格评估未成功，申请人可选择继续推进申请，但不能指定为“.Brand”TLD，即不添加规范 13。

如果“.Brand”TLD 申请是在申请提交窗口期之外通过申请变更请求提出的，或者申请人希望撤回其“.Brand”TLD 认定资格申请，则会开放一个为期 30 天的评议窗口期。

7.3.4 “.Brand”TLD 资格评估的质疑和扩展评估

如果初次提交的所需文件不符合要求，申请人可以重新提交。因此，扩展评估或质疑机制不适用于此评估。

7.3.5 字符串争用和字符串变更

成功完成“.Brand”TLD 资格评估的申请人可能会获准更改其主字符串，以避免字符串争用情况。有关“.Brand”TLD 字符串变更请求程序的更多信息，请参阅第 5.3 节：“.Brand”字符串变更请求。

7.4 注册管理运行机构行为准则豁免评估

基准《注册管理机构协议》的规范 9 包含注册管理运行机构行为准则。该行为准则的目的是保护 gTLD 注册人。在某些情况下，可以请求行为准则豁免。

7.4.1 行为准则豁免评估的资格条件

如果注册管理运行机构在 gTLD 中注册的所有域名仅供自身或其附属机构使用（具体规定详见附录 4：基准《注册管理机构协议》），且注册管理运行机构希望放弃对自身及其附属机构的保护，则 ICANN 可授予该注册管理运行机构行为准则豁免资格，前提是该 gTLD 不是通用字符串（请参阅第 3.1.7 节：封闭型通用域名），且该注册管理运行机构能够满足所有豁免标准。有关规范 9 的文本内容，请参阅附录 4：基准《注册管理机构协议》。

申请人可在其申请中请求行为准则豁免，也可在提交申请后使用“申请变更请求”来提出行为准则豁免。行为准则豁免请求将通过申请评议期向公众公开，供公众审阅并提出意见（请参阅第 4.1.3 节：评估流程中的申请评议）。

7.4.2 变体字符串的行为准则豁免评估

如果申请人就其所申请的主 gTLD 字符串申请可分配变体字符串，并希望获得行为准则豁免，则行为准则豁免评估将涵盖所申请的主字符串和变体字符串。

7.4.3 行为准则豁免评估的有条件费用

请求进行行为准则豁免评估的申请人必须按照第 3.3 节：费用和付款中的规定，支付额外费用。只有在 ICANN 收到相关费用后，才会执行行为准则豁免评估。

7.4.4 行为准则豁免评估标准

行为准则豁免评估将由行为准则豁免评估专家组执行。ICANN 是否授予行为准则豁免资格，需通过对豁免请求中的主张进行审查来判定，以确认若申请人成为注册管理运行机构，是否会满足所有三项豁免标准：

1. 该 gTLD 和（如适用）变体字符串下的所有域名注册，均将注册到注册管理运行机构并由该注册管理运行机构维护，且仅供该注册管理运行机构或其附属机构使用（具体规定详见基准《注册管理机构协议》）；

2. 注册管理运行机构不会向任何第三方（非注册管理运行机构的附属机构）出售、分发或转让该 gTLD 和（如适用）变体字符串下任何注册域名的控制权或使用权。

3. 对该 gTLD 和（如适用）变体字符串适用行为准则，并非保护公共利益所必需。

请求行为准则豁免的申请人需在其申请中进行自我证明，确认符合上述标准。此外，使命和目标声明必须证明不会用于通用用途。也就是说，为确保行为准则豁免的批准不会与基准《注册管理机构协议》规范 11 相冲突（该规范禁止以排他性方式运营通用 gTLD 和变体字符串），所申请字符串不得是第 3.1.7 节：封闭型通用域名中定义的封闭型通用域名。

7.4.5 行为准则豁免评估澄清问题

在行为准则豁免评估过程中，ICANN 可能会提出澄清问题。申请人需在 7 天内对行政方面的澄清问题做出回复，在 21 天内对实质性澄清问题做出回复。如果申请人未能在规定期限内回复，则可能失去机会，从而无法解决评估专家组发现的问题。

7.4.6 行为准则豁免评估结果

行为准则豁免评估结果将包含在申请与申请人评估报告中，如第 1.2.13 节：申请与申请人评估报告的发布中所述。

如果申请通过了行为准则资格评估，则将授予行为准则豁免资格。

如果申请未能成功完成行为准则豁免评估，则该申请可以继续推进，但规范 9 仍然有效。

7.4.6 行为准则豁免评估的质疑和扩展评估

如果初次提交的所需文件不符合要求，申请人可以重新提交。因此，扩展评估或质疑机制不适用于此评估。

7.5 地理名称

申请人必须审慎考量各国政府或公共权威机构在地理名称方面的利益。以下部分概述了 ICANN 在评估流程中将遵循的相关要求和程序。即使申请人认为其打算申请的 gTLD 字符串并不符合地理名称资格，也应查看这些要求。无论申请中是否注明为地理名称，所有申请的 gTLD 字符串及其可分配变体字符串都将根据本节中的要求接受审核。

地理名称的处理步骤包括：

• 地理名称识别：字符串级别的检查，属于字符串评估的一部分。

• 地理名称审核：对于确定为地理名称的字符串，对其申请回复进行验证和实质性审核。此审核在申请评估阶段进行。

此外，地理名称字符串的申请人可以申请其可分配变体字符串。在此类情况下，所有可分配变体字符串必须遵循与相关主地理名称字符串相同的申请要求和评估标准。具体而言，适用相同的文件要求。请参阅第 3.1.9 节：国际化域名。

7.5.1 国家或地区名称的处理

国家或地区名称字符串的申请不会得到批准。⁴⁹如果字符串符合以下任意标准，则它会被视为国家或地区名称：

1. 该字符串为 ISO 3166-1 标准所列出的三字母代码。⁵⁰

2. 该字符串为 ISO 3166-1 标准所列出的全称，或是该全称在任意语言下的翻译版本。

3. 该字符串为 ISO 3166-1 标准所列出的简称，或是该简称在任意语言下的翻译版本。

4. 该字符串为与 ISO 3166 维护机构指定为“特别保留”的代码相关联的简称或全称。

5. 该字符串为“可拆分的国家及地区名称列表”中指定的国家或地区名称的可拆分部分，或为该列表中出现的名称在任意语言下的翻译版本。请参阅附录 2：与地理名称相关的材料。

6. 以下字符串的置换和调换形式均为保留字符串，不可授权：

1. ISO 3166-1 标准中列出的全称。

2. ISO 3166-1 标准中列出的简称。

3. 与 ISO 3166 维护机构指定为“特别保留”的代码相关联的简称或全称。

4. “可拆分的国家及地区名称列表”中指定的国家或地区名称的可拆分部分，或该列表中出现的名称在任意语言下的翻译版本。

ISO 3166-1 标准所列出的三字母代码的置换和调换形式所生成的字符串可进行授权，除非置换和调换形式所生成的字符串本身位于该列表中。⁵¹

7. 该字符串为一个国家或地区被普遍知晓的名称，有证据表明该国家或地区通过该名称被国际政府间组织或条约组织所认可。

7.5.2 需提供政府或公共权威机构文件的地理名称

某些所申请的字符串类型（包括其可分配变体字符串）将被视为地理名称，必须随附相关政府或公共权威机构出具的支持或无异议文件。这类字符串包括：

1. 以任何语言表示的、对应于 ISO 3166-1 标准所列任何国家或地区首都城市名称的字符串。

2. 城市名称类（即申请人声明，拟将该 gTLD 用于与该城市名称相关的用途）。

城市名称可能会引发争议，因其可能同时属于是通用术语或品牌名称，且通常不具有唯一性。与其他类型的地理名称不同，城市名称并无既定列表可作为评估过程中的客观参考依据。因此，城市名称并未受到普遍保护。但是，此流程确实为城市和申请人在需要时进行合作提供了方法。

如有以下情形，城市名称的申请将受地理名称要求的约束（即，要求提供相关政府或公共权威机构出具的支持或无异议文件）：

1. 申请人在申请中明确声明，申请人将所申请的 TLD 主要用于与城市名称相关的目的；并且

2. 所申请的字符串是官方城市文件中所列的城市名称。⁵²

3. 与 ISO 3166-2 标准所列出的国家以下一级地名（如县、省、州）完全匹配的字符串。

4. 被列为联合国教科文组织 (UNESCO) 认定的地区⁵³或出现在“统计用标准国家或地区代码 (M49)”的“地理区域”部分的字符串。⁵⁴

上述列表中所列地区的翻译版本将仅限于该列表中指定的语言。不符合 DNS 允许字符框架要求的地区名称将转换为仅包含字母、数字和连字符的 DNS 标签，如根区标签生成规则 (RZ-LGR) 中所述。⁵⁵

要申请这些列表中的字符串，需要提供该地区至少 60% 的相应国家政府出具的支持或无异议文件，并且该地区的相关政府或者与该大洲或地区相关联的公共权威机构对该申请的书面异议不得超过一份。

如果 60% 规则适用，并且两个列表中有共同的地区，则以“统计用标准国家或地区代码 (M49)”中包含的地区构成为准。

如果所申请的 gTLD 字符串符合上述所列类型 1 至类型 4 中的任何情况，则该字符串将被视为代表地理名称。如果不能确定，建议申请人在提交申请前，与相关政府和公共权威机构进行协商，以获得他们的支持或无异议表态。这种主动举措有助于避免潜在反对意见，并澄清与字符串及适用要求相关的所有模糊之处。

包含本节所定义的地理名称但并未与之完全匹配的字符串，将不视为地理名称。因此，此类字符串在评估流程中无需提供政府支持或无异议文件。

对于每份申请，地理名称专家组将根据申请人、政府的意见以及专家组自己的研究和分析来确定与哪些政府或公共权威机构相关。如果所申请的 gTLD 字符串涉及多个相关政府或公共权威机构，申请人必须提供所有相关政府或公共权威机构出具的支持或无异议文件。预计这一点适用于国家以下一级地名的情况。

申请人有责任：

• 确定其所申请的 gTLD 字符串是否属于上述任何类别。

• 确定相关政府或公共权威机构的具体范围并与之协商。

• 确定需获得哪一级政府的支持。

注：需由哪一级的政府和行政机构提交支持或无异议函件，这由各国家或地区行政管理部门来决定。申请人应在相关司法管辖区内协商，以确定适当的支持级别。

某些申请需提供支持或无异议文件这一要求，并不排除或豁免这些申请因社群理由而被提出异议（请参阅第 4.5.1.4 节：异议理由：社群）。如果目标社群对申请存在强烈反对，且该异议获得支持，申请仍可能被拒绝。

7.5.2.1 文件要求

支持或无异议文件应该包含一封相关政府或公共权威机构出具的签字函件。鉴于不同司法管辖区的情况有所不同，该函件可由负责域名管理、信息和通信技术、外交事务或者相关司法管辖区内的首相或总统办公室事务的部长签字；或由负责域名管理、信息和通信技术、外交事务或者首相办公室事务的机构或部门的高级代表签字。为帮助确定潜在地理名称对应的相关政府或公共权威机构，申请人可考虑咨询相关政府咨询委员会 (GAC) 代表。⁵⁶

该函件中必须清楚地表达政府或公共权威机构对申请表示支持或无异议，并证明政府或公共权威机构对所申请的字符串及其用途有所了解。

该函件还应该表明政府或公共权威机构对正在通过 gTLD 申请流程申请的字符串以及申请人愿意接受可使用字符串的相关条件（即与 ICANN 签订《注册管理机构协议》要求申请人遵守共识性政策并支付相应费用）有所了解。有关 gTLD 注册管理运行机构义务的说明，请参阅第 1.2.16 节：签约后阶段和第 2.10 节：注册管理运行机构对注册服务机构的基本义务。

政府实体/公共权威机构的支持或无异议函件的示例在附录 2：与地理名称相关的材料中提供。

申请人和政府可随时就政府对申请的支持或无异议意见展开讨论。鼓励申请人尽早开始此类讨论，以便政府能够遵循可能需要的流程来审议、批准和生成支持或无异议函件。如果支持或无异议函件的日期距新 gTLD 项目申请提交期开放之日已超过四个月，则需要提供一份新的支持或无异议函件。但是，申请人应提供指定人员的联系信息，以防地理名称专家组 (GNP) 需要澄清或有疑问。

政府或公共权威机构无义务应申请人的请求提供支持或无异议文件。如果支持或无异议文件在申请流程中被撤回，则申请将无法通过地理名称审核。

申请人应了解，ICANN 已向各国政府承诺，⁵⁷如果政府（或公共权威机构）与提交了该政府或公共权威机构支持文件的申请人之间，或者与授权后的注册管理运行机构之间发生争议，ICANN 将遵守由支持申请的政府或公共权威机构所在司法管辖区内的法院发出的具有法律约束力的指令。如果通过具有法律约束力的法院指令撤回支持文件，申请人或注册管理运行机构将不再拥有必备文件，且申请人将无法继续进行申请流程中的后续步骤；或者，如果在授权后发生这种情况，将遵循《注册管理机构协议》中提及的注册管理机构移交流程⁵⁸。

7.5.3 地理名称处理

7.5.3.1 地理名称识别

作为地理名称识别的一部分，地理名称专家组将审核所有申请的字符串，以确定哪些字符串可以被视为地理名称。此流程有别于地理名称审核期间进行的更具实质性的验证流程，且先于该验证流程执行；地理名称审核是申请评估（请参阅模块 7）和申请人评估（请参阅模块 6）的一部分。

不属于“需提供政府或公共权威机构文件的地理名称”第 1、3 和 4 条（请参阅第 7.5.2 节）所定义类别的城市名称，在地理名称识别过程中不会被归类为地理名称。但是，如果申请人表明其有意按“需提供政府或公共权威机构文件的地理名称”第 2 节（请参阅第 7.5.2 节）所述，将所申请的字符串用作城市名称，则该申请将在申请与申请人评估阶段接受地理名称专家组的评估。此评估将包括对预期用途和任何所需文件的评估。

7.5.3.2 地理名称审核

地理名称专家组 (GNP) 将判定每个所申请的 gTLD 字符串是否代表地理名称；如有必要，还将对支持文件的相关性和真实性进行验证。

GNP 将审核收到的所有申请，而并非仅审核申请人已注明其所申请的 gTLD 字符串为地理名称的那些申请。对于 GNP 确定所申请的 gTLD 字符串为国家或地区名称（如本模块中所定义）的任何申请，该申请将无法通过地理名称审核并会遭到拒绝。不会进行其他审核。

对于 GNP 确定所申请的 gTLD 字符串不是需要政府支持或无异议的地理名称（如本模块中所述）的任何申请，该申请将通过地理名称审核，而无需执行额外步骤或支付额外费用。

对于 GNP 确定所申请的 gTLD 字符串为需要政府支持或无异议的地理名称的任何申请，GNP 将确认申请人是否提供了所要求的相关政府或公共权威机构文件，还将确认来自政府或公共权威机构的信件是否合法并包含所要求的内容。ICANN 可通过咨询相关外交机构或 ICANN 政府咨询委员会成员，向有关政府或公共权威机构的主管当局及其行政部门的相应联络点了解通信情况，来确认函件的真实性。

GNP 会与签署函件的实体沟通，以确认其用意以及对申请所获得的支持或无异议相关条款的理解。

7.5.3.2.1 地理名称审核的扩展评估

在以下情况，地理名称审核将有资格进行扩展评估：

• 所提供文件存在问题：如果申请人尚未提供所要求的文件，相关人员将与该申请人联系并告知其要求以及提供文件的限定期限。如果申请人能够在评估期结束前提供相应文件，并且文件满足相应要求，申请人将通过地理名称审核。否则，申请人可以选择扩展评估，这将给予其额外时间来获得所要求的文件；但是，如果申请人未能如期（通知之日起至少 90 天内）提供所要求的文件，则在当前申请轮次中，申请人将不再享有补交文件的额外时间或机会。如果愿意，申请人可以在后续申请轮次中重新申请，并遵守特定申请轮次的付费要求和其他规定。有关更多信息，请参阅模块 6：申请人评估程序和模块 7：字符串和申请评估程序中的“评估质疑”部分。

• 同一地理名称存在冲突的支持或无异议文件：如第 5.5 节：地理名称申请的争用解决所述，若代表同一地理名称的字符串存在多份申请，且经地理名称专家组确定，这些申请分别获得了不同政府或公共权威机构出具的支持或无异议文件，则这些申请也将接受扩展评估。如果在扩展评估期间，地理名称专家组确认所有相关申请的支持机构均符合规定标准，并同意这些申请进入争用解决阶段，则这些申请将进入拍卖流程，或者将进行社群优先评估（如果其中一个申请是社群申请并选择参与社群优先评估）。

7.6 变体字符串评估

变体字符串是指，根据根区标签生成规则 (RZ-LGR) 的定义，语言文字社群认为与所申请主 gTLD 字符串或现有 gTLD（“主字符串”）“相同”的字符串。⁵⁹RZ-LGR 中的规则集可确定有效的顶级域及其变体字符串。⁶⁰如果申请人要为所申请的主 IDN 字符串或现有 gTLD 申请一个或多个可分配变体字符串，则必须为每个变体字符串的必要性提供理由说明。该理由说明将由专家组结合所申请的主 IDN gTLD 或现有 gTLD，依据以下标准，按照合理性通用标准进行评估：

1. 每个所申请变体字符串的含义或（对于非字典词汇）预期含义均具有一致性，且这一点可通过申请人提供的来源材料予以证明。

2. 变体字符串被目标用户社群视为（与主字符串）等效。

3. 引入所申请的变体字符串将带来哪些益处，以及哪些用户社群会因该变体字符串的引入而获益。

4. 申请人将采取哪些措施，以最大限度降低会影响注册服务机构、分销商或注册人的变体 gTLD 及由此产生的变体域名的运营与管理复杂性。

申请人为降低所指运营和管理复杂性所作出的承诺，将成为纳入适用《注册管理机构协议》的合同要求基础。

申请人所申请的每一个变体字符串均须满足上述每一项标准，方可继续参与本项目。任何一个所申请变体字符串的评估结果都不会影响相应的所申请主 IDN 或任何其他所申请变体字符串的评估结果。

对于管理所申请变体字符串以及所申请主 IDN 或现有 gTLD 的能力，将从技术和运营两个角度进行评估，如 RSP 手册中所述。⁶¹

7.6.1 变体字符串的额外申请要求

所申请变体字符串将遵循与相关所申请主 IDN 或现有 gTLD 相同的申请要求和评估标准。具体而言，所申请的主 IDN 及其所申请的变体字符串均适用相同的文件要求。为明确起见，所申请的主字符串及其所申请的变体字符串将作为一个集合共同接受评估，但根据需要，每个变体字符串还需提供相关文件。

关于以下三种特殊申请类型：

• 社群 IDN 及其变体字符串的申请人，必须为所申请变体字符串提交与主 IDN 相同的支持文件。如果某个社群 IDN 存在争用（请参阅第 5.2 节：字符串争用和争用解决程序），且申请人选择参与社群优先评估 (CPE)，则该社群 IDN 及其所申请的变体字符串将作为一个集合共同接受评估（请参阅第 5.4 节：社群优先评估）。

• 地理名称 IDN 及其变体字符串的申请人，必须提交相关政府或公共权威机构对其申请的主字符串和变体字符串出具的支持或无异议文件。也就是说，所需提交的支持或无异议文件中，应同时提及所申请的 IDN 及其所申请的变体字符串。请参阅第 7.5 节：地理名称。

• 申请作为“.Brand”的 IDN 及其变体字符串的申请人，必须提交证明材料，证明其申请的主字符串和变体字符串与其拥有和使用的注册商标完全相同。也就是说，所申请的任何变体字符串也必须提供证明材料，证明其与申请人拥有和使用的注册商标完全相同。请参阅第 7.3 节：“.Brand”TLD 资格评估。

7.6.2 保留名称列表的变体字符串申请

当主字符串是保留名称时，只有与该保留名称（请参阅第 7.2.2 节：保留名称）关联的组织才能申请其顶级域变体字符串。虽然变体字符串可以不是保留名称，但它应该是使用 RZ-LGR 生成的保留名称的变体字符串。保留名称的变体字符串申请不得早于该保留名称的申请，因为该保留名称是用于生成变体字符串的主字符串。

7.6.3 变体字符串的额外依附性要求

所有变体字符串均依附于其主 IDN 进行申请评估。如果所申请的主 IDN 因任何原因（如本节或《指导手册》其他相关章节所述）被判定不具备资格，则所有与之关联的变体字符串也将被判定为不具备资格。在此情况下，整个申请将不得继续推进。

但是，如果所申请的任何变体字符串被判定不具备资格且无法继续推进，则申请人必须提交申请变更请求 (ACR) 以删除不合格的所申请变体字符串，以便申请继续推进。如果 ACR 成功，则相应的所申请主 IDN 以及任何未被判定为不具备资格的其余所申请变体字符串仍可继续推进。

7.7 域名冲突

几乎所有新 gTLD 的授权均存在一定的域名冲突风险。域名冲突是指这样一种情况：原本应在一个域名系统中解析的资源名称，⁶²却意外在另一个域名系统中解析，这可能导致意外行为，例如通信中断或者从原定接收方被重定向。⁶³

为评估和降低全球 DNS 与其他命名系统之间发生域名冲突的风险，依据 ICANN 董事会于 2024 年 9 月 7 日下达的指示，ICANN 根据域名冲突分析项目研究报告 2 中的建议，⁶⁴ 实施了域名冲突风险管理框架。⁶⁵

所有申请的 gTLD 字符串在获准进行签约和授权之前，均须依据此框架进行评估。本节将对这一框架进行介绍，并说明用于评估与此类字符串有关的任何域名冲突风险、并在必要时缓和该风险的相关程序。

7.7.1 申请人获取纵向风险数据

在申请提交期开放之前，ICANN 将发布所有查询量超过一定阈值的字符串的相关数据集，以帮助申请人评估域名冲突风险。

所申请字符串的衡量标准，只是评估该字符串相关风险时需考虑的若干定量和定性因素之一。

在上一轮次申请的约 1,400 个唯一字符串中，仅三个字符串（“.CORP”、“.HOME”和“.MAIL”）被评估为高风险。⁶⁶尽管如此，申请人也不应想当然地认为，如果数据集所显示发生域名冲突的概率较低，该字符串就会被评估为可以安全授权。

7.7.2 域名冲突初步评估

每一个所申请字符串及其任何可分配变体字符串都将接受域名冲突初步评估。该评估将使用可获取的相关数据集（如根服务器日志和 DNS 递归服务器日志），综合考虑查询量和查询多样性、来源、查询名称（标签）和查询类型，结合标识符技术健康指标 (ITHI)⁶⁷ 数据集，并参考有助于推断危害严重程度的定性证据。此评估将按照“域名冲突初步评估操作程序”⁶⁸进行，旨在初步识别高风险字符串。

初步评估将在字符串确认日（第 3.6 节）之后进行，并由技术审核小组 (TRT) 监督。评估完成后，ICANN 将发布一份初步评估报告，在其中说明评估过程、方法和结果。该报告将开启公共评议期，以便社群就评估方法和结果提供反馈意见。

7.7.3 临时授权和最终评估

在域名冲突初始评估（第 7.7.2 节）过程中未被认定为高风险的字符串（包括变体字符串），将进入临时授权队列。一旦初始评估结束，即使字符串评估环节的其他评估仍在进行中，临时授权也会立即启动。临时授权的优先级将由申请所分配到的优先级编号来确定。⁶⁹临时授权的期限将在“域名冲突临时授权操作程序”中列出。⁷⁰临时授权并非其他评估或解决争用问题的必要条件。但是，只有在临时授权完成且缓和计划（如适用）实施后，申请才能继续进入签约阶段。

字符串的临时授权速度将受到限制，以确保 DNS 根区中授权的 TLD 数量每月增幅不超过 5% 左右。按照该速度限制，预计最初每月临时授权数量为 75 个左右，之后随着更多新 gTLD 获得临时授权，这一数量将会逐步增加。但是，由于永久授权优先于临时授权，因此每月的实际数量可能会有所浮动。

在临时授权阶段，所申请的 gTLD 字符串将授权给 ICANN 管理的 DNS 域名服务器，以收集有关该字符串的 DNS 流量数据，包括流量规模和流量性质。临时授权期间将采用四种不同的评估方法，用于通知和数据生成。这些方法在《域名冲突分析项目第二项研究报告》的附录 2 中有所阐述，分别为：无中断 (NI)；控制性中断 (CI)；可见中断 (VI)；以及可见中断和通知 (VIN)。评估将由技术审核小组 (TRT) 监督，该审核小组由来自 ICANN 相关部门的内部专家组成。TRT 将根据每件个案的具体情况，确定每次评估将采用哪种或哪几种方法。

TRT 将评估临时授权期间收集的数据（包括对 TLD 服务器的 DNS 查询、查询多样性、来源、限定名称（标签）、查询类型等），以及使用评估方法收集的数据，以确定该字符串是否：

1. 被认定为高风险字符串；如果是，则会立即从根区中删除该字符串。

2. 有资格继续进行剩下的申请处理工作。

无论临时授权的结果如何，TRT 都将生成一份临时授权报告来概述评估结果，并发布该报告以供申请人和其他相关方查阅。

7.7.4 冲突字符串列表

ICANN 将维护一份冲突字符串列表，在其中列出 ICANN 认定为存在高域名冲突风险的字符串。

当申请字符串出现以下任一情况时，将被纳入冲突字符串列表：(1) 未针对所申请的字符串提交缓和计划；(2) 缓和计划未通过缓和计划评估；(3) 缓和计划无效。

7.7.5 域名冲突高风险缓和计划评估

对于冲突字符串列表中的字符串，如果已解决争用问题，则申请人可以修改申请以添加“高风险字符串缓和计划”，该计划之后将接受评估。此评估将按照“域名冲突高风险缓和计划评估操作程序”⁷¹进行，并需支付额外费用。请参阅第 3.3 节：费用和付款。

申请人必须在以下任一情形发生后的 90 天内（可根据合理要求延长至 180 天），提交申请变更请求以添加缓和计划：(a) 字符串被认定为高风险字符串，或 (b) 争用问题已解决（若存在争用问题）。如果未在此期限内提交申请变更请求，申请状态将变更为“已终止”。请参阅第 3.9 节：申请状态。

在遵守适用数据保护要求的前提下，将向申请人提供字符串初始评估或临时授权期间生成的相关数据，以协助其制定缓和计划。如果数据包含个人信息，且无法有效应用匿名化或聚合等技术保障措施，ICANN 可能会要求与申请人签订数据处理协议 (Data Processing Agreement, DPA)。

申请人提交的缓和计划必须至少包含以下内容：

1. 初步评估结果摘要，以及（如适用）技术审核小组在临时授权期间的调查结果摘要。

2. 根本原因分析和任何其他相关证据，用于确定字符串可能发生域名冲突的根本原因。

3. 缓和计划，在其中概述申请人为缓和域名冲突风险而采取的具体预防和纠正措施，包括与受影响最终用户进行的任何沟通活动。每项缓和措施都必须有具体的实施时限，且总时限不得超过两年。

缓和计划将由技术专家小组进行评估，该小组可能会向申请人提供可能的改进建议。如果需要修改，将再给予 90 天的时间进行此类修改。评估将确定该计划 (a) 是否正确识别冲突的根本原因，以及 (b) 是否具备较高的有效实施可能性。

ICANN 将发布缓和计划与缓和计划评估结果以征求意见。专家组将审核收到的任何意见，并在做出最终决定之前充分考虑这些意见。在缓和计划中，若某些章节包含的信息一旦公开则可能损害计划有效性（例如，可能会使恶意行为者有机可乘来干扰缓和措施的实行），则申请人可指明这些章节，并标注为需做编辑修订处理。如果专家组同意，标记的章节将在发布前进行节选修订处理。

如果缓和计划包含须在字符串授权之前进行的缓和活动，则只有在这些活动已完成，且评估专家组采用与初步评估中的相同标准确认这些活动的有效性之后，申请才能继续推进。

如果评估专家组认定，缓和措施由于技术原因必须在注册管理运行机构获得字符串运营授权之后（评估最终完成后）方可实施，例如，如果域名冲突问题仅限于注册管理机构同意永不授权的二级域名，则只要申请人同意将缓和计划中的适用要求纳入其《注册管理机构协议》，便可继续进行剩下的申请处理工作。

如果评估专家组发现缓和计划 (a) 未能正确识别冲突的根本原因，或 (b) 不太可能有效，则该申请将无法继续推进，且申请状态将变更为“已终止”。

7.7.5.1 对缓和计划评估提出质疑

如果申请人认为专家组在认定缓和计划 (a) 未能正确识别冲突的根本原因，或 (b) 不太可能有效时，存在事实错误或程序错误，则申请人将有机会对与其申请相关的缓和计划评估结果提出质疑。要启动评估质疑程序，申请人必须在评估裁定结果送达之日起 21 天内提出质疑。质疑审查将由质疑专家组负责开展，该小组由最初负责缓和计划评估的同一批人员组成。

对质疑的评估将根据“明显错误”审查标准进行。具体而言，质疑专家组必须接受评估专家组的裁定，除非评估专家组：(1) 未能遵循相应程序，或 (2) 未能考虑/征求必要的实质性证据或信息。

提交质疑的截止日期为申请人收到拟提出质疑的评估结论通知之日起 21 天内。质疑专家组将在申请人提出此类质疑后 30 天内，告知质疑处理程序的结果。

如果质疑专家组发现存在事实错误或程序错误，将重新评估缓和计划。评估专家组将重新进行评估，并将结果提交给 ICANN。ICANN 将公布结果并开启为期 30 天的评议期。评议期结束后，ICANN 将考虑所有可用信息，并最终决定是接受还是拒绝该缓和计划。如果该缓和计划被拒绝，申请状态将变更为“已终止”。

如果质疑专家组未发现对缓和计划的初步评估存在任何事实错误或程序错误，则申请将无法继续推进，且申请状态将变更为“已终止”。

7.7.6 变体字符串的影响

所有申请的主字符串（包括申请的可分配变体字符串）都将通过上述初步评估和临时授权流程进行域名冲突风险评估。

如果发现主字符串或可分配变体字符串存在高风险，则只有在缓和计划评估流程实施完成之后，申请才能继续推进。但是，如果是可分配变体字符串存在高风险，则可修改申请以删除该字符串，这样修改后的申请便可以继续推进。只要申请状态尚未变为“已终止”，即可随时删除可分配变体字符串。

7.8 公共利益承诺、注册管理机构自愿承诺和社群注册政策

ICANN 的使命是确保互联网唯一标识符系统的稳定安全运营。⁷²新 gTLD 项目通过多项内置保护措施为上述使命保驾护航，其中包括对所申请的 gTLD 字符串、申请和运营商进行严格的评估，以及强制要求遵守《注册管理机构协议》相关规定。

公共利益承诺 (PIC)，特别是强制性 PIC（请参阅第 7.8.1 节）和保障性 PIC（请参阅第 7.8.2 节），是新 gTLD 项目内置的一项重要保护措施。这些 PIC 是《注册管理机构协议》规范 11 中具有约束力的承诺，且 ICANN 强制要求遵守这些承诺。强制性 PIC 和保障性 PIC 在相关《注册管理机构协议》中保持统一，其实施是为了响应政府咨询委员会 (GAC) 对 2012 年申请轮次中的申请提出的关切。公共利益承诺应对的主要问题包括消费者保护、知识产权，以及金融、医疗、慈善等受监管的市场领域。⁷³

除了 PIC 外，申请人还可提出一项或多项注册管理机构自愿承诺 (RVC)（请参阅第 7.8.3 节），以针对所申请 gTLD 字符串的运营提供额外保障措施。申请人可以提出 RVC，解决强制性 PIC、保障性 PIC 或其他方式尚未覆盖的问题。正如第 7.8.3 节：注册管理机构自愿承诺中的进一步详述，拟议的 RVC 须接受单独的评估流程，即注册管理机构承诺评估 (RCE)。ICANN 仅在以下情况下才会批准拟议的 RVC：(1) RVC 满足 RCE 标准（请参阅第 7.8.3.3 节）；(2) 申请人和 ICANN 均同意，如果将拟议 RVC 纳入《注册管理机构协议》，则依据《ICANN 章程》并在实际操作层面，该承诺具备可执行性。与 PIC 一致，RVC 一旦获得批准并纳入《注册管理机构协议》，即成为基准《注册管理机构协议》规范 11 中具有约束力的承诺。⁷⁴

PIC 和 RVC 均受公共利益承诺争议解决流程 (PICDRP) 的约束。⁷⁵

如第 7.1 节：字符串和申请类型中所述，申请人可选择将所申请的 gTLD 字符串指定为社群 gTLD。如果申请人将所申请的 gTLD 字符串指定为社群 gTLD，则必须提出《注册管理机构协议》社群注册政策（请参阅第 7.8.4 节），以将其纳入适用的《注册管理机构协议》中，并由 ICANN 依据 RCE 标准（请参阅第 7.8.3.3 节）进行评估。

7.8.1 强制性公共利益承诺

每一份《注册管理机构协议》均包含强制性 PIC。强制性 PIC 要求每个注册管理运行机构采取措施，以便为 gTLD 注册人和互联网用户提供更广泛的保护，并包含与以下方面相关的义务：滥用行为缓和、安全检查以及运营透明度。强制性 PIC 包含在基准《注册管理机构协议》规范 11 第 3(a)-(d) 节（请参阅附录 4）中，即：

1. 注册管理运行机构将在其《注册管理机构-注册服务机构协议》中纳入如下规定，要求注册服务机构在其《注册协议》中禁止注册域名持有人散布恶意软件、滥用僵尸网络、网络钓鱼、盗版、商标或版权侵权、诈骗或欺骗、造假或以其他方式从事违反适用法律的活动，并（依据适用法律和任何相关程序）注明这些活动会带来的后果，包括暂停域名的使用。

2. 注册管理运行机构将定期开展技术分析，评估 TLD 中的域名是否被用于 DNS 滥用。注册管理运行机构将定期执行安全检查，并对已发现的 DNS 滥用及所采取的应对措施编制一份统计报告。注册管理运行机构将在协议有效期内保存这些报告（除非法律要求或 ICANN 批准保存更短时间）并根据要求提供给 ICANN。⁷⁶

3. 注册管理运行机构将制定、发布并遵守明确的注册政策，坚持公开、非歧视的一般原则，以透明的方式运营 TLD。

4. “通用字符串”TLD 的注册管理运行机构不得在 TLD 中强加注册域名的资格标准，使注册仅限于单独的个人或实体以及/或者该个人或实体的“附属机构”（如基准《注册管理机构协议》第 2.9(c) 节中定义）。“通用字符串”是指由一个定义或描述通用类商品、服务、团体、组织或事物的词语或术语组成的字符串，与其相对的是由可区分特定品牌商品、服务、团体、组织或事物的词语或术语构成的字符串。

有关通用字符串的更多信息，请参阅第 3.1.7 节：封闭型通用字符串/独占式通用字符串。

7.8.2 保障性公共利益承诺

除所有《注册管理机构协议》均需包含的强制性 PIC 之外，某些《注册管理机构协议》还要求包含有关保障性 PIC 的条款。

ICANN 将需要适用保障性 PIC 的 gTLD 按风险分为四组：

• 监管行业/开放式准入要求：唤起消费者信任但风险较高的字符串。

• 严格监管行业/封闭式准入要求：与需要许可或认证的行业相关的字符串。

• 潜在网络霸凌/骚扰：可能助长骚扰行为的字符串。

• 政府固有职能：与政府域名相关的字符串。

有关更多详细信息和示例，请参阅第 7.8.2.2 节：按字符串类别划分的适用保障性 PIC中的表格。

如果 ICANN 在评估过程中确定所申请的 gTLD 字符串属于第 7.8.2.2 节：按字符串类别划分的适用保障性 PIC中列出的一个或多个类别，则适用的保障性 PIC（请参阅第 7.8.2.3 节）必须不经修改地纳入适用的基准《注册管理机构协议》规范 11。⁷⁷

制定和实施保障性 PIC 是为了回应《ICANN46 北京公报》⁷⁸中提出的 GAC 共识性建议以及 2012 轮次新 gTLD 项目期间发布的后续 ICANN 董事会决议⁷⁹。⁸⁰

7.8.2.1 字符串分组判定

在申请中，申请人必须回答一些问题，以评估《注册管理机构协议》中需要纳入哪些保障性 PIC（如有）（请参阅附录 1：申请问题中的第 10 组问题：安全保障评估/使命和目标）。申请人的回答将随申请文件一并公布。

申请评议期结束后，ICANN 将判定每个所申请的 gTLD 字符串是否属于四个保障性 PIC 分组之一。该判定标志着评估的结束，并会作为签约程序的参考依据。根据扩展评估和评估质疑（第 1.2.14 节），不能对该判定提出质疑，因为它不会影响申请的进度。

有关申请评议期的更多信息，请参阅第 4.1 节：申请评议。

7.8.2.2 按字符串类别划分的适用保障性 PIC

ICANN 将使用以下框架来判定所申请的 gTLD 字符串是否需要保障性 PIC，如果需要，则确定适用哪些保障性 PIC。该框架确定了根据《ICANN46 北京公报》中 GAC 共识性建议而设立的四个字符串分组，并提供了各组别的相应说明和示例。⁸¹如果所申请的 gTLD 字符串被认定属于 GAC《ICANN46 北京公报》中列出的字符串分组，则 ICANN 将对该字符串应用保障性 PIC。

该框架确定了十项保障性 PIC 分别适用于四个字符串类别中的哪些具体类别。

表 7-2：保障性 PIC 框架

7.8.2.3 保障性 PIC

十项保障性 PIC 包括适用于注册人的多项要求和义务，例如，遵守适用法律法规、实施适当的安全措施、提供联系信息、拥有必要的凭证、报告凭证的重大变更等。下表列出了各项保障性 PIC：

表 7-2：保障性 PIC 的类型

7.8.3 注册管理机构自愿承诺

在某些情况下，申请流程和《注册管理机构协议》中涵盖的众多保障措施（包括强制性 PIC 和保障性 PIC）可能无法完全解决申请或拟议《注册管理机构协议》中的特定问题。在此类情况下，申请人可考虑提出注册管理机构自愿承诺 (RVC) 以帮助解决潜在问题。

申请人提出 RVC 的决定通常是自愿做出，但 ICANN 认定需通过该承诺解决异议或响应 GAC 共识性建议的情况除外（请参阅第 7.8.3.2.3.1 节：情境 1：为化解异议或响应 GAC 共识性建议而做出的承诺）。这些承诺如果获得批准并纳入《注册管理机构协议》，将具有合同约束力。RVC 的具体内容可灵活调整，既可以是强化与公共利益相关的承诺，也可以是将利益相关方的承诺规范化。RVC 还可设立一系列保障措施，以帮助消除第三方对所申请的 gTLD 字符串或申请本身存在的疑虑。例如，申请人可以针对异议、GAC 成员早期预警或 GAC 共识性建议、申请评议或其他可能对申请评估流程产生负面影响的问题提出 RVC。有关这些主题的更多详细信息，请参阅第 3.8 节：申请变更请求和模块 4：社群意见、异议和申诉。

申请人可在申请中包含拟议 RVC，也可以稍后通过申请变更请求流程添加拟议 RVC（请参阅第 3.8 节），该流程包含申请评议期及其他相关条件。

所有随申请文件一并提交或作为申请变更请求提交的拟议 RVC 都将出现在新 gTLD 项目网站⁸⁶的公开申请部分中，并在申请评议期内向公众开放，以供审核和评议（请参阅第 4.1 节：申请评议）。

7.8.3.1 提出 RVC 前需要考虑的因素

在决定提出 RVC 之前，建议申请人查阅以下文件：ICANN 章程；相关的 ICANN 协议，包括但不限于《注册管理机构协议》和《注册服务机构认证协议》(RAA)；以及 ICANN 的共识性政策和临时政策。申请人及任何对申请提出关切的第三方应考量，现有的标准化条款是否能够为所申请的 gTLD 字符串提供充分保障——若现有条款足以满足需求，则无需评估和实施定制化的 RVC。⁸⁷

ICANN 社群建议 ICANN 在每份《注册管理机构协议》中纳入强制性 PIC，同时对于在评估流程中确定属于第 7.8.2 节：保障性公共利益承诺所述四个字符串分组的字符串，在其《注册管理机构协议》中纳入保障性 PIC（如适用）。在某些情况下，无需实施保障性 PIC 的申请人可提议将一项或多项已获批准的保障性 PIC 用作 RVC，以解决与所申请的 gTLD 字符串或申请本身相关的问题或顾虑。

此外，申请人应考虑是否需要运营额外的注册管理机构服务才能履行拟议的 RVC。⁸⁸如果需要，申请人应与其选定的注册管理机构服务提供商 (RSP) 协商实施此类额外注册管理机构服务，该服务必须通过 RSP 项目进行评估并获得 ICANN 批准。如果 ICANN 确认拟议 RVC 需运营额外的注册管理机构服务才能实施，且申请人选定的 RSP 尚未获批此类注册管理机构服务，则该 RSP 必须先通过 RSP 项目寻求 ICANN 的批准，然后 ICANN 才会考虑将拟议承诺作为 RVC 予以批准。⁸⁹

任何与 ICANN 章程、政策和协议不符的拟议 RVC 均不会获得批准，如第 7.8.3.3 节：注册管理机构承诺评估标准中所述。

建议申请人考虑除《注册管理机构协议》之外，是否可通过其他方式帮助解决与所申请的 gTLD 字符串或申请本身相关的问题。例如，申请人可以与提出顾虑的第三方协商，并考虑通过以下方式消除其顾虑：在申请人自身的注册管理机构政策、使用条款中纳入相关承诺，或与该第三方达成单独的协议。任何此类单独协议均不得由 ICANN 强制执行，且任何此类第三方均不得成为与 ICANN 签订的《注册管理机构协议》的“第三方受益人”。⁹⁰

7.8.3.2 注册管理机构承诺评估

对于每个所申请的 gTLD 字符串（及其申请的可分配变体字符串，如适用），所提议的每一项 RVC 均需通过注册管理机构承诺评估 (RCE) 接受 ICANN 的评估和审批。RCE 的目的是判断拟议承诺是否符合 RCE 标准（请参阅第 7.8.3.3 节）中规定的所有评估标准，以确定该承诺是否可纳入《注册管理机构协议》。

每项拟纳入适用《注册管理机构协议》的社群注册政策也需接受注册管理机构承诺评估（请参阅第 7.8.4 节：社群注册政策）。有关变体字符串评估的更多信息，请参阅第 7.8.3.5 节：变体字符串的拟议 RVC。

在申请中，希望提交拟议 RVC 和社群注册政策以纳入《注册管理机构协议》的申请人，必须回答一系列旨在协助 ICANN 开展评估的问题（请参阅附录 1：申请问题）。

提交 RVC 或社群注册政策的申请人需缴纳一笔固定的一次性费用，以支付注册管理机构承诺评估的费用。有关 RCE 相关费用的详细信息，请参阅第 3.3.2 节：有条件评估。

7.8.3.2.1 申请人须确定拟议 RVC 的用途

申请人必须提供背景信息，以说明其拟议 RVC 对于支持申请所具有的相关性、重要性和必要性。当申请人提出 RVC 后，ICANN 将在开展注册管理机构承诺评估之前，针对此项要求进行完整性检查。此类信息将有助于提供拟议 RVC 的背景，并且在某些情况下，如果需要调整 RVC 条款以实现拟议承诺的目标，同时又符合 RVC 纳入《注册管理机构协议》的标准，此背景信息可能会有所帮助，如第 7.8.3.3 节：注册管理机构承诺评估标准中所述。

例如，如果拟议 RVC 是为了回应第三方异议而提出，申请人应明确具体的异议和异议人，提供与该异议相关的参考资料或链接，并补充其他相关细节。这些细节信息可能包括但不限于：申请人如何制定拟议 RVC 来解决相关问题，申请人在拟定该 RVC 时是否与异议人进行了协商，以及建立了哪些措施和系统来确保遵守该 RVC。

7.8.3.2.2 一般规则：注册管理机构拟议 RVC 的承诺评估不影响申请进度

除第 7.8.3.2.3 节：例外：注册管理机构拟议 RVC 的承诺评估影响申请进度中所述情况外，对注册管理机构拟议 RVC 进行的承诺评估不会影响申请的继续进行。除这些例外情况外，注册管理机构承诺评估不会影响对申请人或申请继续进入签约阶段的资格评估，它仅用于判断如果申请继续推进，拟议 RVC 是否符合纳入适用《注册管理机构协议》的标准。

评估不会判断拟议 RVC 是否可成功消除第三方的顾虑。尽管 ICANN 在评估过程中可能会参考与该申请相关的评议和其他意见反馈，也可能咨询第三方，但通常不会让第三方参与此项评估。

如果申请人有意通过提出 RVC 来解决异议或消除其他第三方顾虑，建议申请人先与相关方进行沟通。若能在提交申请变更请求前，就用于解决问题的 RVC 与相关方达成一致，那么 ICANN 可无需再评估第三方提出的“该拟议 RVC 无法充分消除所申请 gTLD 或申请相关顾虑”这一异议。如果申请人在异议程序期间提出 RVC 以解决异议或第三方顾虑，且该 RVC 已获得 ICANN 批准，则异议人或其他第三方必须各自独立决定是否以及如何继续推进其关切事项。

例如，如果申请人在“冷静期”提出 RVC 以解决异议，则一旦注册管理机构承诺评估结束（无论批准还是拒绝该 RVC），异议人即可决定是否继续推进该异议。再举一例：申请人在收到 GAC 成员早期预警后，可以通过申请变更请求的形式提出 RVC，以降低后续收到可能阻碍申请进展的 GAC 共识性建议的风险。在此情况下，评估不会判定拟议 RVC 是否有可能消除 GAC 成员早期预警中提出的顾虑，但 RVC 获批这一情况可为 GAC 在讨论就申请或所申请的 gTLD 字符串向董事会发布共识性建议时提供参考。

若申请人计划将 RVC 作为申请变更请求提出以消除第三方顾虑，并希望该 RVC 能够在异议、GAC 共识性建议、GAC 成员早期预警、申请评议等环节中被纳入考量，则需留意相应的时间表和流程（请参阅模块 4：社群意见、异议和申诉）。如前文所述，所有作为申请变更请求（请参阅第 3.8 节）提交的拟议 RVC 均需经过申请评议期。

7.8.3.2.3 例外：注册管理机构拟议 RVC 的承诺评估影响申请进度

注册管理机构拟议 RVC 的承诺评估结果仅在两种情况下才会影响申请进度。要了解在认定申请无法继续推进时会出现何种情况，请参阅第 3.9 节：申请状态。

7.8.3.2.3.1 情境 1：为化解异议或响应 GAC 共识性建议而做出的承诺

如果 ICANN 认定某项 RVC 能够解决异议或落实 GAC 共识性建议，则该 RVC 在申请流程期间和合同签订后，将受到更为严格的限制。

尽管在这种情况下提出的 RVC 被打上“自愿”的标签，但 ICANN 认为，此类 RVC 并非完全由申请人自行决定提出，而是申请继续推进的必要条件。

要解决异议或落实 GAC 共识性建议，RVC 必须通过注册管理机构承诺评估获得 ICANN 批准。未经 ICANN 批准，申请将无法继续推进。⁹¹请参阅第 4.5.8.13 节：异议和注册管理机构自愿承诺以及第 4.3.3 节：GAC 共识性建议和注册管理机构自愿承诺。

为化解异议或响应 GAC 共识性建议而提出的 RVC，将通过申请评议期向公众开放，以供审阅和评议。如果与 ICANN 的协商结果是进行变更以获得批准，则原始提案和 ICANN 批准的版本都将公布，以供评议。有关更多信息，请参阅第 3.8 节：申请变更请求。

由于此类 RVC 的特定目的，在 ICANN 批准后，除非出现特殊情况，否则申请人和注册管理运行机构通常无法对这些承诺进行实质性更改或删除。这些承诺应纳入规范 11 的一个单独小节中，以明确它们将受到更为严格的限制。请参阅第 7.8.3.4 节：RVC 的添加、变更和删除。

7.8.3.2.3.2 情境 2：拟议 RVC 被拒绝后，需提交申请变更请求

如果申请人在初始提交中提出了 RVC，但未通过注册管理机构承诺评估，则申请人必须提交申请变更请求以修改或删除拟议 RVC，以便申请得以继续推进。ICANN 将根据发布的标准（请参阅第 3.8 节）审核申请变更请求。

除非出现特殊情况，否则若申请人在收到拟议 RVC 未通过评估的通知后 30 天内未提交申请变更请求，此申请将无法继续推进。

7.8.3.2.4 注册管理机构承诺评估时间安排和结果通知

对于以下两种情形下提出的 RVC，其注册管理机构承诺评估将在 ICANN 收到相应费用后尽快进行：一是根据“情况 1：为化解异议或响应 GAC 共识性建议而做出的承诺”而提出的 RVC（请参阅第 7.8.3.2.3.1 节）；二是参与社群优先评估 (CPE) 的社群申请人所提交的拟议社群注册政策（请参阅第 7.8.4 节）。ICANN 知悉及时进行 RCE 的重要性，这能确保相关流程能够按时进行，以防延迟。

在所有其他情况下，注册管理机构承诺评估预计将在申请流程的后期进行，即签约之前、ICANN 收到评估费之后。

如无特殊情况，RCE 阶段的时间预计为 60 至 90 天。

ICANN 将在新 gTLD 项目网站上发布并定期更新所有提交的 RVC 和社群注册政策的 RCE 结果，并向相应的申请人通知相关结果。⁹²

7.8.3.3 注册管理机构承诺评估标准

ICANN 将拒绝任何与《ICANN 章程》不符的拟议 RVC。⁹³详情请参阅下表中的标准 5。

ICANN 将根据以下标准评估每一项拟议的 RVC，且需满足所有标准方可获批。申请人在拟定 RVC 时应遵循相关指南，并考量各项标准与所拟 RVC 的相关性。

拟纳入适用《注册管理机构协议》的社群注册政策（请参阅第 7.8.4 节）中的每项承诺也必须满足所有注册管理机构承诺评估标准，方可获得批准。

有关拟议社群注册政策和注册管理机构自愿承诺（二者均将通过 RCE 进行评估）起草方法的详细要求和指导说明，请参阅附录 1：申请问题的第 7 组问题：社群 gTLD以及第 11 组问题：注册管理机构自愿承诺 (RVC) 中关于问题 150-155 的说明。

如第 7.8.3.1 节：提出 RVC 前需要考虑的因素中所述，申请人可以考虑在《注册管理机构协议》之外纳入某些承诺，例如以申请人自己的注册管理机构政策、使用条款等形式，或通过申请人与第三方之间单独签订协议的形式。任何此类未拟纳入《注册管理机构协议》的承诺，均无需接受注册管理机构承诺评估。⁹⁴

表 7-3：RVC 评估标准

7.8.3.4 RVC 的添加、变更和删除

如果在申请提交日之后、适用的《注册管理机构协议》签署之前添加或修改了拟议 RVC，则应遵循申请变更请求流程；该流程包含针对重大变更的申请评议期，具体规定详见第 3.8 节：申请变更请求。有关拟议 RVC 不同类型的申请评议期，请参阅第 3.8.3 节：申请变更请求类型和所需流程。

除非出现特殊情况，否则，根据“情况 1：为化解异议或响应 GAC 共识性建议而做出的承诺”（请参阅第 7.8.3.2.3.1 节）提出的 RVC，通常不得在合同签署前进行重大变更，也不得删除。

ICANN 目前尚未制定相关流程，供注册管理运行机构请求对已签署的《注册管理机构协议》中的 RVC 进行修改。对于注册管理运行机构在合同签署后请求修改 RVC 这一主题，ICANN 也许会拟定相应流程，以便社群就此提供意见和建议。

7.8.3.5 变体字符串的拟议 RVC

如果申请人寻求所申请主字符串的可分配变体字符串，并计划在其申请中或作为申请变更请求提出 RVC，则拟议 RVC 必须同时适用于主字符串和变体字符串，并接受同样的注册管理机构承诺评估。此要求也适用于针对所申请的社群 gTLD 主字符串和变体字符串而提出的社群注册政策，详见第 7.8.4 节：社群注册政策。

7.8.4 社群注册政策

《注册管理机构协议》社群注册政策（简称“社群注册政策”）是 gTLD 注册管理运行机构必须对社群 gTLD 中的注册人实施的《注册管理机构协议》条款。提交社群 gTLD 申请（“社群申请”）时，申请人必须拟定社群注册政策，以纳入适用的《注册管理机构协议》。这些政策必须至少涵盖注册人资格和域名选择两方面内容。

与拟纳入《注册管理机构协议》的 RVC 一样，申请人提出的拟纳入适用《注册管理机构协议》的社群注册政策也必须根据 RCE 标准进行评估（请参阅第 7.8.3.3 节）。其评估结果将影响社群申请能否继续推进。具体而言，申请人必须先具有已获批准的社群注册政策，然后其申请才能参与社群优先评估 (CPE)。CPE 是仅适用于社群申请、用于解决争用问题的一种可选机制。⁹⁹总之，社群注册政策的获批不仅是社群申请参与 CPE 的必要条件，也是该申请在 RCE 之后继续推进申请流程的必要条件。换言之，如果没有经 ICANN 批准纳入《注册管理机构协议》的社群注册政策，则无论社群申请是否存在争用问题，也无论申请人是否选择参与 CPE，该社群申请均无法继续推进。¹⁰⁰

如果申请的字符串进入授权阶段，则符合 RCE 标准（请参阅第 7.8.3.3 节）的社群注册政策将被纳入适用的《注册管理机构协议》。有关拟议社群注册政策（将通过 RCE 进行评估）起草方法的详细要求和指导说明，请参阅附录 1：申请问题的第 7 组问题：社群 gTLD 中关于问题 150-155 的说明。与 PIC 和 RVC 一样，获批的社群注册政策将接受 ICANN 合同合规部监督。纳入《注册管理机构协议》的社群注册政策受注册限制争议解决程序 (RRDRP) 和社群 gTLD 变更请求程序的约束。¹⁰¹

此外，社群 gTLD 的运营商可以根据需要，在《注册管理机构协议》之外实施任何其他注册政策，前提是这些政策不违反适用 ICANN 协议和政策的要求。¹⁰²

7.8.5 ICANN 的执行机制

对于已根据 RCE 标准（请参阅第 7.8.3.3 节）进行评估并获得批准、且作为其他合同义务纳入《注册管理机构协议》中的 PIC、RVC 和社群注册政策，ICANN 将对其遵守情况进行执行监督。对于注册管理运行机构可能未遵守一项或多项 PIC 或 RVC 的投诉，可通过 PICDRP 进行处理。对于社群 gTLD 运营商涉嫌违反《注册管理机构协议》所规定社群注册政策的情况，则可通过 RRDRP 进行处理。有关 PICDRP 和 RRDRP 的更多详细信息，请参阅第 1.2.17 节：授权后争议解决程序。

7.9 注册管理机构服务提供商审核

ICANN 将核实申请人是否已在其申请中选择了一家或多家经评估合格的 RSP。如果没有，申请人可通过扩展评估提交与所选 RSP 有关的所需信息。ICANN 还将审核 RSP 支持 gTLD 的意愿，包括其通过任何其他注册管理机构服务为 gTLD 提供支持的能力。请参阅第 3.1.10 节：注册管理机构服务提供商选择。

7.10 字符串相似性评估

字符串相似性评估的目的是，避免因授权存在视觉相似的字符串引发用户混淆，进而导致他们对 DNS 失去信任。字符串或其变体字符串不得与现有顶级域或其变体字符串，或者禁用名称或其变体字符串在视觉上相似（定义如下），具体规定详见第 7.10.1 节：字符串相似性评估范围（请参阅第 7.2.1 节：禁用名称）。变体字符串使用适用版本的根区标签生成规则来计算（请参阅第 3.1.8.3.1.1 节：适用的 RZ-LGR 版本以及支持的文字和语言）。¹⁰³

申请是基于所申请的主字符串或现有 gTLD。每个主字符串都会创建一个变体字符串集，并且是该变体字符串集的成员。¹⁰⁴根据申请人做出的选择和其他适用限制，一个申请可以包含来自同一变体字符串集的一个或多个字符串（请参阅第 3.1.9 节：国际化域名）。¹⁰⁵对于任何申请，无论申请人是否申请变体字符串集中的多个字符串，都会使用该变体字符串集中的所有字符串进行字符串相似性评估，详情如下文所述。

在此上下文中，“视觉上相似”指的是视觉上容易让人混淆的字符串，尤其是“这些字符串在视觉上十分相似，以致于如果将多个相似字符串授权到根区，就可能会导致用户混淆”。¹⁰⁶字符串相似性评估将由独立的字符串相似性评估专家组完成。如果专家组认定所申请的字符串或其变体字符串存在视觉相似，将对其进行标记，要么将其排除在申请流程之外，要么将其归入字符串争用集。字符串评估过程中进行的字符串相似性评估是对字符串混淆异议流程的补充。请参阅第 4.5 节：异议和申诉。

7.10.1 字符串相似性评估范围

字符串相似性评估会将每个申请的字符串及其变体字符串与相关类别中的对应字符串和变体字符串进行初步比对。如下文所述，评估将使用变体字符串集中的所有字符串进行，无论申请人是否申请了这些字符串。比对的目的是根据《字符串相似性评估指南》（请参阅第 7.10.2.3 节），确定字符串在视觉上是否相似到足以造成用户混淆的程度¹⁰⁷。

对于每个申请，主字符串（如果尚未授权）及其变体字符串集中的所有可分配变体字符串¹⁰⁸将与以下字符串进行比对：¹⁰⁹

• 现有的已授权 gTLD 及其所有可分配变体字符串和禁用变体字符串。

• 已在之前的 gTLD 申请轮次中提交且仍在处理中的 gTLD 字符串，¹¹⁰及其所有可分配变体字符串和禁用变体字符串。

• 现有的已成功完成评估¹¹¹或已授权¹¹²的 ccTLD 及其所有可分配变体字符串和禁用变体字符串。

• 当前作为 IDN ccTLD 申请的字符串¹¹³（请参阅第 7.10.3.3 节：字符串在视觉上与已成功完成评估或已授权的 ccTLD 或其变体字符串相似）及其所有可分配变体字符串和禁用变体字符串。

• 当前申请轮次中所申请的其他 gTLD 字符串及其所有可分配变体字符串和禁用变体字符串。

• 部分禁用名称¹¹⁴及其所有可分配变体字符串和禁用变体字符串。

• 所有其他双字母 ASCII 字符串¹¹⁵ 及其所有可分配变体字符串和禁用变体字符串。

此外，对于每个申请，其变体字符串集中的所有禁用变体字符串都将与以下字符串进行比对：

• 现有的已授权 gTLD 及其所有可分配变体字符串。

• 已在之前轮次的新 gTLD 项目中提交且仍在处理中的字符串，¹¹⁶及其所有可分配变体字符串。

• 现有的已成功完成评估或已授权的 ccTLD 及其所有可分配变体字符串。

• 当前作为 IDN ccTLD 申请的字符串（请参阅第 7.10.3.3 节：字符串在视觉上与已成功完成评估或已授权的 ccTLD 或其变体字符串相似）及其所有可分配变体字符串。

• 当前申请轮次中所申请的其他字符串及其所有可分配变体字符串。

• 部分禁用名称¹¹⁷及其所有可分配变体字符串。

• 所有其他双字母 ASCII 字符串及其所有可分配变体字符串。

作为上述比对的例外情况，在字符串相似性评估期间，字符串相似性评估专家组可决定省略一部分与禁用变体字符串的比对。任何此类决定都必须依据《字符串相似性评估指南》做出——如果根据该指南判定被比对文字之间的混淆风险较低，则此类省略是合理的。

下表总结了字符串相似性评估专家组将基于标记为“是”的类别而进行的比对。如前所述，对于标记为“是*”的灰色阴影单元格，如果字符串相似性评估专家组根据《字符串相似性评估指南》（第 7.10.2.3 节）得出文字不太可能产生混淆的结论，则可省略此类别的字符串比对。列为“否”的单元格则不进行比对。

表 7-4：字符串相似性评估专家组执行的比对范围

*对于标记为“是*”的灰色阴影单元格，如果字符串相似性评估专家组根据《字符串相似性评估指南》得出文字不太可能产生混淆的结论，则可省略此类别的字符串比对。

7.10.2 字符串相似性评估方法

7.10.2.1 相同的主字符串或变体字符串

ASCII 字母的大小写形式均考虑在内，且字符串字母大小写的任意组合均可用于字符串相似性评估，例如“EXAMPLE”、“Example”或“example”。

若不同申请人提交的申请中，其字符串来自同一变体字符串集，则字符串相似性评估专家组会将这些申请标记为相同。

7.10.2.2 字符串分批

如果需要分批，则将在确定评估优先批次之前，完成对所有申请的字符串的字符串相似性评估。对于被认定为属于某个字符争用集的申请，ICANN 将根据该字符争用集中优先级最高的字符串，将该字符争用集中的所有字符串放入同一批次。

7.10.2.3 字符串相似性评估指南

字符串相似性评估专家组将根据《字符串相似性评估指南》进行评估，该指南将发布在新 gTLD 项目网站上。

7.10.2.4 字符串相似性评估专家组流程

字符串相似性评估将由独立的字符串相似性评估专家组完成。所有申请的字符串及其变体都将根据申请的其他字符串及其变体、现有 gTLD 和禁用名称进行评估，详情请参阅第 7.10.1 节：字符串相似性评估范围。

字符串相似性评估专家组将按以下步骤开展字符串相似性评估：

1. 编制用于比对的字符串列表：

   1. 现有 gTLD

   2. 在之前轮次的新 gTLD 项目中申请但仍在处理中的字符串

   3. 现有 ccTLD

   4. 申请的 IDN ccTLD

   5. 申请的其他字符串

   6. 禁用名称

   7. 双字符 ASCII 字符串

2. 使用 RZ-LGR，考量上述字符串的所有可分配变体字符串。

3. 使用 RZ-LGR，考量上述字符串所有使用相同文字的禁用变体字符串（假名和汉字组成的混合文字字符串需符合 RZ-LGR 要求）。

4. 决定应从评估中排除哪些禁用变体字符串（如有），并记录做出此决定的理由。专家组做出的任何此类决定都必须依据《字符串相似性评估指南》（请参阅第 7.10.2.3 节），理由是被比对字符串文字之间的混淆风险较低。

5. 识别来自不同申请、但属于同一变体字符串集的字符串，以确定由相同字符串或变体字符串导致的字符争用集。

6. 根据《字符串相似性评估指南》（请参阅第 7.10.2.3 节）对字符串进行比对，以识别任何视觉上相似的各组字符串，并记录分析结果。此流程不将视觉相似性工具的结果作为参考依据，但字符串相似性评估专家组可能会使用相应语言文字社群提供的自动化工具和数据，以提高人工比对流程的效率。

7. 确定并记录字符串相似性评估的结果（并说明理由）。

7.10.3 字符串相似性评估结果

如上所述，字符串相似性评估专家组将进行分析并确定字符串相似性评估的结果。这些结果及其理由将依据对所有申请的 gTLD 字符串（包括其变体字符串集）进行的相似性比对，详情请参阅本节。可能的结果如下：

1. 字符串在视觉上与现有 gTLD 或其变体字符串相似。

2. 字符串在视觉上与之前轮次的新 gTLD 项目中申请但仍在处理中的字符串或其变体字符串相似。

3. 字符串在视觉上与现有 ccTLD 或其变体字符串相似。

4. 字符串在视觉上与申请的 IDN ccTLD 或其变体字符串相似。

5. 字符串与其他申请的字符串或其变体字符串相同。

6. 字符串在视觉上与其他申请的字符串或其变体字符串相似。

7. 字符串在视觉上与禁用名称或其变体字符串相似。

8. 字符串在视觉上与双字符 ASCII 字符串或其变体字符串相似。

9. 字符串在视觉上与上述任何类别均不相似。

ICANN 将在新 gTLD 项目网站的评估结果页面上发布字符串相似性评估结果。

变体字符串集中的所有字符串（包括主字符串及其所有可分配变体字符串和禁用变体字符串）将共享同一字符串相似性评估结果：

• 如果任何申请的字符串或其任何变体字符串由于视觉相似性原因而无法继续申请或被归入某个字符争用集，则该申请的字符串及其所有变体字符串（即整个变体字符串集）将共享同一评估结果。

• 如果字符争用集中的某个申请胜出，则该结果适用于整个变体字符串集，且胜出申请中的所有字符串都可进入申请流程的下一阶段。请参阅第 5.2.2 节：字符串争用解决。

7.10.3.1 字符串在视觉上与现有 gTLD 或其变体字符串相似

如果任何申请的字符串或其任何变体字符串被认定在视觉上与任何现有 gTLD 或其任何变体字符串相似，则该申请将无法继续推进，但下述情况除外。

例外情况适用条件如下：申请的字符串是现有 gTLD 的可分配变体，与现有 gTLD 属于同一变体字符串集，申请的字符串被认定在视觉上与该现有 gTLD 或其任何变体字符串相似，并且申请人也是该现有 gTLD 的注册管理运行机构。在此情况下，该申请可以作为变体字符串继续进行评估。

7.10.3.2 字符串在视觉上与之前轮次的新 gTLD 项目仍在处理中的字符串及其变体字符串相似

如果申请的主字符串或其任何变体字符串在视觉上与上一轮申请中遗留下来且仍在处理中的所申请主字符串或其任何变体字符串相似，则新提交的申请将被搁置，直到上一轮申请结果确定为止。

• 如果上一轮新 gTLD 项目的申请已成功完成评估并有资格签订基准《注册管理机构协议》，则新申请的主字符串的整个变体字符串集将失去继续推进申请流程的资格。

• 如果上一轮的相关申请被撤回或未通过评估，则新提交的申请有资格进入申请流程的下一阶段。

新申请人不得申请与上一轮新 gTLD 项目仍在处理中的字符串属于同一变体字符串集的字符串。

7.10.3.3 字符串在视觉上与已成功完成评估或已授权的 ccTLD 或其变体字符串相似

如果任何申请的字符串或其任何变体字符串被认定在视觉上与任何已成功完成评估或已授权的 ccTLD 或其变体字符串相似，则该 gTLD 申请将无法继续推进。

7.10.3.4 字符串在视觉上与申请的 IDN ccTLD 相似

IDN ccTLD 字符串可通过 IDN ccTLD 快速通道流程或其后续替代流程以滚动方式申请。¹¹⁸IDN ccTLD 字符串申请流程是单独的流程，独立于 gTLD 申请流程。如果申请的 gTLD 字符串被认定在视觉上与任何申请的 IDN ccTLD 相似，¹¹⁹字符串相似性评估专家组将报告其与申请的 IDN ccTLD 存在冲突，但不会形成字符争用集，因为字符争用集仅适用于申请的 gTLD 字符串。ICANN 将采取以下方法解决冲突。

如果申请的 gTLD 字符串被认定在视觉上与某个申请的 IDN ccTLD 相似，ICANN 将根据各自评估流程的完成情况确定结果。具体情形如下：

• 已成功完成所有相关评估阶段（包括争议解决和字符串争用，如适用）且符合条件签订基准《注册管理机构协议》的 gTLD 申请将被视为完成评估，因此，该 gTLD 申请（主字符串和申请的变体字符串，如适用）不会被新提交的 IDN ccTLD 申请取消资格。IDN ccTLD 申请人将收到相应通知。

• 已通过验证的所申请主 IDN ccTLD 字符串¹²⁰将被视为完成评估。因此，该 IDN ccTLD 字符串（主 IDN ccTLD 字符串和申请的变体字符串，如适用）不会被新提交的 gTLD 申请取消资格。

如果两个申请均未完成各自的评估流程，则 gTLD 申请（包括申请的变体字符串，如适用）将被搁置，同时 IDN ccTLD 申请（包括申请的变体字符串，如适用）将接受评估。搁置期限可能无法确定，具体取决于 IDN ccTLD 申请人是否提供了完成评估流程所需的充分的文件和信息，这完全受 IDN ccTLD 申请评估流程的约束。gTLD 申请人相应地将被告知以下两种结果之一：

• 如果申请的 IDN ccTLD 顺利通过评估，则该 IDN ccTLD 申请将优先获批，而 gTLD 申请将不予批准。

• 如果申请的 IDN ccTLD 未通过评估，或被 IDN ccTLD 申请人撤回，则 IDN gTLD 字符串可继续进行申请评估。

若 gTLD 申请人已获得相关政府或公共权威机构出具的支持函或无异议函，但其申请最终因与 IDN ccTLD 申请流程中申请的字符串在视觉上相似而被驳回，并且该 gTLD 申请是在该 ccTLD 公布之前提交的，则评估费用将全额退还。

申请人不得申请与已通过验证的所申请 ccTLD 字符串属于同一变体字符串集的 gTLD 字符串。

7.10.3.5 字符串与所申请的字符串及其变体相同或在视觉上相似

如果任何申请的主字符串及其任何变体字符串被认定在视觉上彼此相似，且这些字符串是在同一申请中申请的，则它们相互之间不存在争用关系，可以作为彼此的主字符串和变体字符串继续申请。

如果任何申请的字符串或其任何变体字符串被认定与任何其他申请的字符串或其任何变体字符串相同或视觉上相似，则字符串相似性评估专家组会将这些申请所对应的变体字符串集¹²¹归入一个字符争用集。一个字符争用集至少包含两个彼此或与其变体相同或视觉上相似的申请字符串。有关字符争用集和争用解决的更多信息，请参阅模块 5：字符争用集解决程序。

这些字符争用集还将包含以下关联信息：直接争用（字符串 A 与字符串 B 容易混淆）；通过字符串视觉相似性传递的间接争用（字符串 A 与字符串 B 容易混淆，字符串 B 与字符串 C 容易混淆，但字符串 A 和字符串 C 不易混淆），或通过字符串变体视觉相似性传递的间接争用（例如，字符串 A 与字符串 B 变体 1 容易混淆，字符串 B 变体 2 与字符串 C 容易混淆，但字符串 A 和字符串 C 不易混淆）。间接争用的解决机制如下：如果字符串 B 无法继续申请，则允许字符串 A 和字符串 C 继续申请；但如果字符串 B 能够继续申请，则字符串 A 和字符串 C 均无法继续申请。

7.10.3.6 字符串在视觉上与禁用名称相似

如果任何申请的字符串或其任何变体字符串被认定在视觉上与任何禁用名称¹²²或其任何变体字符串相似，则申请将无法继续推进。

7.10.3.7 字符串在视觉上与双字符 ASCII 字符串相似

如果任何申请的双字符字符串或其任何变体字符串被认定与任何双字符 ASCII 字符串或其任何变体字符串相似，则所申请的字符串将无法继续申请。

7.10.3.8 字符串相似性评估结果

下表汇总了上文讨论的结果。如果字符串被认定在视觉上与任何类别中的任何字符串均不相似，则该字符串可进入申请评估流程的下一阶段。

表 7-5：专家组对 gTLD 申请进行字符串相似性评估的结果

7.10.4 对字符串相似性评估提出质疑

可以对字符串相似性评估提出质疑。如果申请人认为字符串相似性评估专家组犯了事实错误或程序错误——例如，当专家组认定该申请人申请的字符串（或变体字符串）存在视觉相似问题，因此该字符串无法继续申请或应根据上文所述将其归入字符争用集时——则申请人可以提出质疑。

对质疑的审查将根据“明显错误”审查标准进行。具体而言，评估质疑服务提供商必须接受字符串相似性评估专家组的评估判定，除非：(1) 专家组未能遵循既定的评估程序，或 (2) 未能考虑或征求必要的实质性证据或信息。

申请人可在收到字符串相似性评估判定结果通知之日起 21 天内，提出评估质疑。字符串相似性评估专家组将在申请人提交此类质疑后的 30 天内，告知该评估质疑的结论。

如果字符串相似性评估专家组发现存在事实错误、程序错误或系统错误，将结合评估质疑的调查结果，重新对该申请进行字符串相似性评估。

如果字符串相似性评估专家组未发现任何事实错误、程序错误或系统错误，则：

• 如果质疑是基于申请的字符串在视觉上与以下字符串相似这一判定，则申请将无法继续推进：现有 gTLD、上一轮新 gTLD 项目中已申请的任何字符串、任何现有 ccTLD、已通过验证的所申请 IDN ccTLD、任何其他双字符 ASCII 字符串或任何其他禁用名称。

• 如果质疑是基于申请的字符串在视觉上与另一个申请的字符串相似这一判定，则申请仍保留在相关字符争用集中。

7.10.5 “.Brand”TLD 的例外

如果申请的字符串符合“.Brand”TLD 的资格标准（请参阅第 7.1.2.4 节：“.Brand”TLD 申请），并且根据上述表 7-5：专家组对 gTLD 申请进行字符串相似性评估的结果中的详细信息，发现这一申请的“.Brand”TLD 存在相似情况，导致其无法继续申请或被归入字符争用集，则该“.Brand”TLD 申请人将有机会更改其字符串。有关“.Brand”TLD 申请的字符串变更规则，请参阅第 5.3 节：“.Brand”字符串变更请求。¹²⁴