Skip to main content
Resources

RSEP 实施说明

注:所有语种版本中,英文版为官方版本,其他语种版本仅供参考.

生效日期:2019 年 6 月 17 日

经过几个月的讨论,RySG RSEP 改进讨论小组与 ICANN 组织就一系列运营改进事项达成了共识,以期在遵守相应政策的前提下提高流程效率和增强可预测性。在这份 2019 年版的"RSEP 实施说明"中,体现了达成共识的流程改进事项。这些实施说明已于 2019 年 6 月 17 日生效。

单击此处可返回到 RSEP 流程网页。

简介

2005 年 11 月 8 日,ICANN 董事会下达指示,要求实施 GNSO 针对如何审议新注册管理机构服务请求所建议的流程,该流程要求根据 .NET《注册管理机构协议》中与注册管理机构服务定义相关的规定来指导审议工作。本实施说明是对注册管理机构服务评估政策 (RSEP) 流程的概要说明,旨在概要介绍 ICANN 组织对此类政策的实施情况。ICANN 组织可以根据相关注册管理运行机构和选区提供的意见定期对此实施流程的有效性进行审核。

2019 年,注册管理机构利益相关方团体 (RySG) 讨论小组与 ICANN 组织携手合作,以期在不更改现有政策的前提下对实施说明进行修改。对实施说明进行修改是为了让 RSEP 流程更易于理解,增强可预测性,以及确保流程始终符合基本政策。

通用顶级域 (gTLD) 注册管理运行机构可以向 ICANN 组织提交 RSEP 请求,请求 ICANN 组织增加拟定的注册管理机构服务、修改现有的注册管理机构服务或取消注册管理机构服务。如果 ICANN 组织判定 RSEP 请求中的拟定服务不符合《注册管理机构协议》中定义的注册管理机构服务的要求,那么 ICANN 组织将会通知注册管理运行机构,并关闭其请求。注册管理运行机构可以随时撤销请求。

为了解决 RSEP 共识性政策与某些传统 gTLD《注册管理机构协议》中的合同条款所存在的分歧,ICANN 组织制定了共识性政策与涉及评估流程的 gTLD 协议合同条款间的分歧解决意见。这一分歧解决意见旨在说明因实施共识性政策而启动的流程既不符合共识性政策,也不符合任何当前 gTLD 协议所涵盖的条款。对于任何 RSEP 请求,如果共识性政策与《注册管理机构协议》间存在分歧,ICANN 组织将考虑采用该解决意见。

除非另有规定,否则所有对天数的引用均指的是日历天数。

第 1 步 - 提交

注册管理运行机构可以使用适当的申请表向 ICANN 组织提交 RSEP 请求,在此过程中需遵循以下标准:

  1. RSEP 请求标准申请表:在提出 RSEP 请求以要求增加拟定的注册管理机构服务、取消现有的注册管理机构服务或大幅修改现有的注册管理机构服务时,注册管理运行机构必须回答一系列标准问题,以便向 ICANN 组织提供充足的信息来帮助其对请求进行评估。注册管理运行机构可以将 RSEP 请求中提交的信息指定为"机密",但为了说明拟定注册管理机构服务的目的以及对 DNS 用户的影响而必需提供的信息不能指定为"机密"。

    为了满足政策所规定的时间要求并增强可预测性,政策及 ICANN 组织建议注册管理运行机构在提交 RSEP 请求标准申请表之前先向 ICANN 组织咨询相关事宜。这一步骤并不是为了增加注册管理运行机构的负担,而是为了帮助确保注册管理运行机构可以提前准备好 ICANN 组织审议 RSEP 请求所需的信息。与此同时,通过提前咨询,注册管理运行机构与 ICANN 组织可以有机会探讨提出的请求是否符合政策规定,发现并澄清在正式审核过程中可能会出现的问题,并尽早就适当的授权文件达成共识。

  2. RSEP 请求简略申请表:对于一些熟知的服务(包括 ICANN 组织为确保安全性和稳定性而反复审核的服务、未引起重大安全性或稳定性问题的服务、之前已批准的服务,以及拥有已公开发布的修订模板的服务),注册管理运行机构需填写简略申请表,并确认按原样一字未改地使用了标准修订模板。执行该步骤可缩短针对熟知服务的 RSEP 请求从提交到授权所经历的时间。

第 2 步 - ICANN 完整性检查

在完整性检查过程中,将不公布 RSEP 请求,且 ICANN 组织与注册管理运行机构之间围绕 RSEP 请求展开的所有互动信息都将保密。请求提交后,ICANN 组织将进行完整性检查,检查应在 15 天以内完成。提交的请求必须满足以下条件,才能进入第 3 步"ICANN 审核":

  1. 信息充足:请求必须包含充足的信息,以便 ICANN 组织能够在 ICANN 审核阶段做出合理的初步裁定。完整的 RSEP 请求标准提交表中应包含对所有相关问题的详尽回答,其中包括对拟定服务的全面介绍、对外部用户所造成影响的评估、受新服务影响的合同条款列表及相关说明(若有)、拟定修订内容(若需要修订)、外部相关方和社群提供的反馈(若有)以及任何其他有助于做出初步裁定的支持文件。

  2. 授权文件:在第 2 步完成后,ICANN 组织和注册管理运行机构应就授权文件的类型以及要对《注册管理机构协议》(RA) 进行的修订内容达成共识,在此之后,请求才会进入"ICANN 审核"阶段。如果拟定服务不符合 ICANN 共识性政策或 ICANN 董事会的指示要求,那么 ICANN 组织将不能同意发布授权文件。

    授权文件类型及标准:

    • RA 修订:用于以下两种情况:(i) 拟定服务与 RA 中的现有条款相冲突;或 (ii) 拟定服务不在 RA 的涵盖范围内,因此需要将其添加到 RA 的附件 A 中,和/或将其作为附录添加到 RA 中。

    • "自由部署"函件:用于以下情况:拟定服务在 RA 的涵盖范围内,且与现有的合同条款不存在任何冲突。

ICANN 组织可能会发现 RSEP 请求中的信息不够充分全面,无法帮助其开展评估,也无法公布请求,如要公布,则需要提供更多信息。在这种情况下,ICANN 组织可以与注册管理运行机构协商和/或要求注册管理运行机构补充信息并重新提交请求,这可能会延长第 2 步"完整性检查"所需的时间。在此过程中,ICANN 组织将本着真诚的原则与注册管理运行机构进行合作。

2A - 要求继续审核的请求

如果注册管理运行机构和 ICANN 组织一致认为第 2 步中的第 1 个条件已满足,但双方未能就授权文件类型和/或修订内容达成共识,那么注册管理运行机构可以在最终确定授权文件之前提交继续进入第 3 步"ICANN 审核"的请求。ICANN 组织将及时审议所有"要求继续审核的请求",并将本着真诚的原则评估协商进程。

如果注册管理运行机构提交了"要求继续审核的请求",ICANN 组织可以采取下列某项措施:

  • 如果协商即将结束,ICANN 组织可以批准此"要求继续审核的请求",以允许 RSEP 请求进入第 3 步"ICANN 审核",届时 ICANN 组织将公布 RSEP 请求。双方将在第 3 步中继续开展协商,以便在 ICANN 审核结束之前达成共识。

  • 如果协商离结束还相去甚远,ICANN 组织可以请求将问题升级至 ICANN 组织领导层,以便开展进一步协商。此升级过程将在 RSEP 请求进入第 3 步之前进行。在升级过程结束后,如果 ICANN 组织批准"要求继续审核的请求",且拟定的注册管理机构服务开创了先例或对 ICANN、第三方或域名系统具有重大影响,那么 ICANN 组织可以公布拟定的授权文件,以征询公众意见。公共评议将在第 3 步"ICANN 审核"结束之后进行。

  • 如果 ICANN 组织认为注册管理运行机构未本着真诚的原则进行协商,那么 ICANN 组织可以拒绝注册管理运行机构提出的"要求继续审核的请求"。

第 3 步 - ICANN 审核

如果 ICANN 组织在第 2 步中确定请求是完整的或批准了"要求继续审核的请求",那么 ICANN 组织将启动为期 15 天的审核流程并公布拟定的注册管理机构服务。

在 ICANN 审核期间,ICANN 组织将就拟定的注册管理机构服务是否会引起重大的安全性、稳定性或竞争方面的问题做出初步裁定。ICANN 组织将遵循与竞争问题初步裁定相关的已发布指导原则,ICANN 组织也可以征询相关机构或个人的专业意见,但提供意见的机构或个人必须遵守保密协议,对拟定的注册管理机构服务在安全性、稳定性或竞争方面所造成的影响予以保密。可提供专业意见的人员包含注册管理机构服务技术评估小组 (RSTEP) 的成员。根据政策要求,审核时间不能超过 15 天。

在第 3 步"ICANN 审核"结束时,ICANN 组织会将他们对拟定的注册管理机构服务做出的初步裁定告知提交请求的注册管理运行机构。

第 4 步 - 批准或转介

在第 3 步中做出的初步裁定包括以下几种结果:

  1. 批准 RSEP 请求;

  2. 转介给注册管理机构服务技术评估小组 (RSTEP);

  3. 转介给相应的政府竞争权威机构;或

  4. 同时转介给 RSTEP 及相应的政府竞争权威机构。

如果初步裁定的结果是 2 至 4,那么注册管理运行机构将收到相应通知,届时注册管理运行机构必须确认是要继续推进审核流程还是撤消其 RSEP 请求。如有需要,注册管理运行机构可以与 ICANN 组织就裁定结果进行协商。

结果

裁定

后续步骤

(1) 批准

不存在明显的安全性、稳定性或竞争方面的重大问题

请求被认为是完整的,可以进入第 6 步"授权"。

(2) 转介给 RSTEP

可能会引起重大的安全性或稳定性问题

如果注册管理运行机构确认希望继续推进请求审核流程,RSTEP(有关发布的 RSTEP 成员名单,请访问此处)将对拟定服务进行评估。将请求转介给 RSTEP 后,RSTEP 小组将在 45 天内对拟定服务进行审核,并撰写有关任何安全性或稳定性问题的报告。RSTEP 最终报告的未经节选修订版将会提供给注册管理运行机构。第 5 步 - 需要进行公共评议和 ICANN 审议。

(3) 转介给相应的政府竞争权威机构

可能会引起重大的竞争问题

如果注册管理运行机构确认希望继续推进请求审核流程,ICANN 组织会在确认后的 5 个工作日内将问题转介给相应的政府竞争权威机构或对所涉及问题具有管辖权的权威机构。第 5 步 - 需要进行公共评议和 ICANN 审议。

(4) 同时转介给 RSTEP 及相应的政府竞争权威机构

可能会引起重大的安全性或稳定性以及竞争方面的问题

如果注册管理运行机构确认希望继续推进请求审核流程,ICANN 组织将采取结果 2 和 3 中所述的步骤。

 

第 5 步 - 公共评议和 ICANN 审议(如果适用)

如果按照第 4 步将拟定的注册管理机构服务转介给 RSTEP 或相应的竞争权威机构,或者出现"2A – 要求继续审核的请求"中所述的情况,那么必须就 ICANN 组织针对 RSEP 请求所拟定的授权文件展开公共评议。

  • 转介给 RSTEP:在 RSTEP 展开审核的同时,ICANN 将公布拟定的注册管理机构服务及起草的授权文件以征询公众意见。在 RSTEP 完成评估报告后,评估报告也将进入正在进行的公共评议期。在公共评议期结束后,注册管理运行机构可以对公众意见做出回复,起草的授权文件也可以进行相应的更新。

  • 转介给竞争权威机构:在将问题转介给相应的政府竞争权威机构(转介期限为 45 天)的过程中,ICANN 将公布拟定的注册管理机构服务和授权文件以征询公众意见。

    • 如果竞争权威机构在 45 天的转介期限内提出问题,注册管理运行机构可以与 ICANN 组织一起解决提出的问题,起草的授权文件也可以进行相应的更新。

    • 如果竞争权威机构在 45 天的转介期限内未提出任何问题或请求在此之前已撤销,ICANN 组织会在分析公众意见时将这一点纳入考虑范围。

    • 在公共评议期结束后,注册管理运行机构可以对公众意见做出回复,起草的授权文件也可以进行相应的更新。

在公共评议期结束后,如果 RSEP 请求获得批准,ICANN 组织将对这一裁定结果进行审议,或者将其转介给 ICANN 董事会进行审议。

在转介给 ICANN 董事会后,ICANN 董事会将力图在 30 天内根据最终的公众意见汇总和分析报告做出决定。ICANN 董事会可能做出如下决定:1) 批准 RSEP 请求;2) 拒绝 RSEP 请求;或 3) 延迟 RSEP 请求以获取更多信息。

如果 ICANN 组织或 ICANN 董事会批准 RSEP 请求,注册管理运行机构和 ICANN 组织将进入第 6 步"授权"。如果 ICANN 董事会拒绝请求,那么请求将终止。

第 6 步 - 授权

正如之前的 ICANN 政策实施流程一样,在 RSEP 请求获得批准,且 ICANN 组织和注册管理运行机构就授权文件达成共识后,ICANN 组织将启动授权流程。如果满足这些条件,ICANN 组织将在 5 天内采取以下相应操作:

  1. 向注册管理运行机构发送"自由部署"函件(如第 2 步中所述),届时,注册管理运行机构便可以部署服务;
    或者

  2. 使用在第 2 步或第 5 步中一致同意的 RA 修订启动 RA 修订执行流程(如果在公共评议后,对 RA 进行了相应的更新)。在注册管理运行机构和 ICANN 组织执行所需修订后,注册管理运行机构便可以部署请求的服务。

ICANN 组织会将注册管理机构服务已获批准的通知及相应的授权文件发布到 RSEP 网页和特定于顶级域 (TLD) 的《注册管理机构协议》网页上。

如果注册管理运行机构在未获得授权文件的情况下部署服务,可认为注册管理运行机构违规。

RSEP 工作流程

请参阅 RSEP 工作流程,其中展示了大致的 RSEP 流程,并且引用了这些"实施说明"。

存档资料

作为 RSEP 流程运营改进事项的一部分,该网页已于 2019 年 6 月更新(请参阅 ICANN 组织的博客文章)。单击此处可查阅已存档的"实施说明"。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."