附录a－工作方向主题gnsoicann.pdfVIP

附录A －工作方向主题 工作方向1 －整体流程、支持和外展 1.1 （注册管理机构服务提供商）认证计划（维客页面：/ x/KT2AAw ） 背景信息：GNSO 建议7 指出，“申请人必须能够证明，就其所述目的而言，申请人具备开展注册 管理运营所需的技术能力。”为了支持这一政策建议，《申请人指导手册》中纳入了许多技术和运 营问题(24 - 44) ，用于帮助ICANN 评估申请人是否有能力运营顶级域(TLD) 注册管理机构。 在评估流程中，有一点变得很明显，那就是申请人就众多技术问题提供的答案全都由为数不多的 注册管理机构服务提供商(RSP) 准备。据ICANN 在项目实施审核中估计，在收到的1,930 份申请中， 90% 所使用的技术基础设施都落在了13 个技术基础设施的范围内。尽管答案完全相同，ICANN 仍 然需要单独评估每一份申请。一旦通过理论评估，各注册管理运行机构将进入授权前测试阶段 (PDT)，这就导致这些为数不多的RSP 需要针对每个注册管理运行机构重复执行相同的测试。 工作组认为，这一流程的效率有很大的提升空间，可以通过向申请人提供多种不同选项来回应申 请中的技术要求，包括允许他们从预先批准（或认证）的 RSP 列表中选择 RSP，来达到提高效率的 目的。而且，采用这一方法还可以让申请人在选择 RSP 时感到放心，同时，通过对冗余度、容量、 监测、对威胁的响应时间、报告和统计流程控制提出最低标准要求，这还可以提高域名系统(DNS) 的安全性和稳定性。另外，预先批准或许还能带来以下好处：促进RSP 市场中的竞争和扩大对RSP 的选择范围；鼓励发展中地区那些符合RSP 明确标准的实体成为新RSP，从而增加RSP 的多样性； 以及简化注册管理机构从一家RSP 转向另一家 RSP 的流程。另一方面，如果审批标准定得太高， 则会给进入市场造成批准/认证壁垒，使当前的RSP 群体较进入市场的新竞争者更有优势，从而削弱 RSP 市场中的竞争和减少选择范围。一些人还说，设定最低技术要求将会造成竞相降低技术能力 门槛的恶性竞争。 第 1 页 按照工作组目前的设想，此类项目应基于自愿的原则，不排除批准注册管理运行机构充当自己的 RSP，或是批准增加新的RSP。 1.1.1 －工作组已在上面的“背景信息”部分指出了风险和益处。您认为在执行此类项目时还有什 么其他风险或益处？是否还应该考虑其他因素？ 1.1.2 －如果为新gTLD 制定 RSP 计划，您对该计划的部分细节或要求是否有任何建议？例如，如 何在数量不断变化的注册管理机构中衡量RSP 的可扩展性？ 1.1.3 －谁应该负责评估RSP 是否符合计划要求？ 1.1.4 －已获批准的RSP 是否应持续履行任何义务，例如高阶认证要求？这些要求是否应根据RSP 将要服务的TLD 类型或其他因素进行区分？请予以说明。 1.1.5 －RSP 与ICANN 之间是否应签订协议？如是，则应该制定什么强制执行机制，使ICANN 能够 在该协议被违反的情况下采取相应行动？ 1.1.6 －RSP 计划对 ICANN 认证注册服务机构有哪些潜在影响（若有的话，无论是正面还是负面）？ 如果有任何负面影响，可以采取什么办法减轻这些影响？ 1.1.7 －是否应制定一项流程以便定期重新评估 RSP？如是，应多久进行一次评估以及重新审批的 流程应是怎样的？ 1.1.8 －如果要执行RSP 计划，该计划应在下一个申请期开始之前提前多久启动？ 1.1.9 －是否应设定RSP 申请“截止”日期，以便给寻求批准的RSP 留出足够的时间，让他们能在 下一个申请期开始之前获得批准？ 1.1.10 －如果任何RSP 计划中存在预先批准的 RSP 列表，那么针对作为现有已授权TLD 的RSP 的 组织，是否应该作出任何规定？如是，该规定如何发挥作用？如否，ICANN 是否可以根据RSP 的 目前表现，来判断其是否符合审批流程中的任何技术要求和/或测试？ 1.1.11 －如果要制定 RSP 计划，该计划的运转资金应从何处来？例如，由于该计划将减少相关的 ICANN 评估费用及相应的申请费用，因此是否应由注册管理机构支付计划费用？ 1.2 申请人支持（维客页面：/x/NT2AAw） 1.2.1 －有人认为通过以下方式扩大申请人支持(AS) 计划的适用范围是有益的： 1. 扩大对IDN 或其他标准的支持 2. 在申请人支持计划中