Skip to main content

新 gTLD 授权前测试提供商 - RFP 问题和答案

本页面还提供其他语种:

受访者需要对意见征求书作出回应,回复地址为:pre-delegation-testing-bid@icann.org。有关此 RFP 的问题的提交时间现已结束。对此 RFP 的最终回应将在 2012 年 11 月 20 日截止。

下列问题已于 2012 年 10 月 30 日至 11 月 7 日之间提交。为了方便各位受访者,全套问题和回应已公布在 ICANN 网站上。

根据接收到的相似问题或与多个问题相关的相同答案,对所有问题进行分组。

下列内容以潜在 RFP 受访者提交的问题为基础,并已根据独立于供应商的原则重新编写。

问题 1: Q.16:ICANN 将哪些内容明确定义为"三个重要阶段"?

它们是第 2.2 节("范围")中定义的三个不同部分。

问题 2: 预计每个注册管理机构系统中的 web 界面也需要接受测试吗?

Whois 界面应该按 2.3.4.1 中所述接受测试。AGB 表示:

"ICANN 将确认能否利用 TCP 端口 43 和 web 界面,通过 IPv4 和 IPv6 访问 Whois数据,并审核有关 Whois 交易能力的自我认证文件。ICANN 将通过 IPv4 和 IPv6 从互联网上的多个点远程测试注册管理机构协议规定 4 中规定的回应格式和对 Whois 的访问(端口 43 和通过 web)。"

问题 3: 如果出现问题,在设计和实施阶段是否会有专用 ICANN 资源供测试提供商进行协商?

是的。

问题 4: RFP 指出,流程将向"一个或多个"提供商授予合同,而这会影响定价。那么,ICANN 能对此提供更多指导吗?

如 Q.24、Q.25 和 Q.26 中要求,供应商应该为所列的这每个项目提供单独定价。

问题 5: 需要对后方注册管理机构服务提供商还是申请人进行测试?

授权前测试提供商应确认各申请人是否履行了按照 gTLD《申请人指南》(AGB) 建立注册管理机构的承诺。

问题 6: 鉴于只申请了大约 1400 个独特的字符串,预计是否仍将按照每周 20 次测试的速度完成大约 2000 次测试?

我们计划按照每周 20 次测试的初始速度测试 1400 个申请人。但是请注意,如果 ICANN 要求,我们还要求提供商能够增加到每周 100 次测试。

问题 7: ICANN 能对预计最少数量的授权前测试发布明确声明吗?

目前尚不清楚将获得批准的字符串申请总数。因此,我们不能断定将接受测试的注册管理机构的最少数量,只能确定最多为 1,400 个。我们预计,所测试的注册管理机构的实际数量应该接近最大值。

问题 8: ICANN 要求,授权前测试软件应以源代码格式提供给 ICANN,且可作为开源软件由 ICANN 发布。请阐明此要求。

投标时应明确说明对交付所提供的软件或许可权的各种限制。ICANN 至少会要求获得非独家、永久免税许可权的授权,以使用所提供的软件进行授权前测试。

问题 9: "授权前测试软件"是指在授权前测试系统中使用的所有软件,还是执行技术测试所用的软件?

提供授权前测试服务所需的所有软件。

问题 10: RFP 要求授权前测试提供商审核将接受测试的注册管理执行机构所提供的"自我认证"文件。ICANN 会确认此次审核旨在确保完整性,没有反映用来验证自我证明的其他测试吗?

授权前测试提供商应审核自我认证文件,验证完整性、真实性以及是否符合在 gTLD 申请中做出的具体结论。

问题 11: 对于将通过授权前测试系统生成的报告,授权前测试提供商将向各申请人提供报告,还是只需要向各后方注册管理机构服务提供商的技术平台提供一套统一报告?

是的,对于测试的各 gTLD,预计提供商将提供一份报告反映注册管理执行机构遵守授权前测试要求的情况。

问题 12: 在此 RFP 流程中,是 gTLD 申请人的征求书还是与新 gTLD 申请人签约的后方注册管理机构服务提供商和/或 DNS 服务提供商的征求书将丧失资格或以其他方式接受处罚?

ICANN 将接受新 gTLD 申请人和/或新 gTLD 后方注册管理机构服务提供商的征求书。根据 Q.3 和 Q.6 的要求,受访者应明确声明所有利益冲突。利益冲突不会自动使受访者丧失资格或对其进行处罚。

问题 13: ICANN 会考虑让 EBERO 担任授权前测试提供商吗?

是的。

问题 14: 如果授权前测试提供商候选人是自己申请人的后方注册管理机构服务提供商,其能否根据 RFP 中的指南验证或测试自己的技术规范,或者还是有其他方法能处理这种情况?如有,请描述详情。

授权前服务提供商不能测试其向申请人提供的自己的规范或注册管理机构服务,因为这会构成利益冲突。

问题 15: ICANN 是否允许采用双供应商方法执行授权前测试任务(即,一个供应商开发授权前测试软件并托管授权前测试系统,其他供应商将提供授权前测试服务)?

是的。

问题 16: ICANN 会考虑向单一供应商授予合同,允许 a) 形成规模经济,以及 b) 全部采用持续测试模型吗?

单一供应商是 ICANN 比较青睐的方案。但是,如果有更好的替代方案,ICANN 也愿意考虑多个提供商。

问题 17: 可以对后方注册管理机构服务提供商执行单独测试吗(因为这将把要求限制在大约 80 次此类测试)?

AGB 为注册管理执行机构(ICANN 的签约方)指定了一个授权前测试。

问题 18: ICANN 将考虑提出一组授权前测试的征求书吗?更具体地说:鉴于其更具技术性且较为重要,ICANN 是否会考虑只提出 RFP 的 DNS 和 DNSSEC 部分的征求书?

不会。

问题 19: 对于作为新 gTLD 计划的一部分而提供给 ICANN 的其他应用评估服务所产生的利益冲突,ICANN 是否会有疑虑?

不会。

问题 20: Q.26:对于现场审计,进行一次现场审计需要多少人?

授权前测试提供商应该组建一个具备所需能力开展现场审计的小组。预计只需要进行一小部分这些测试。

问题 21: ICANN 能够阐明将在现场审计中检查的审计项目吗?

授权前测试提供商应验证是否符合 AGB 第 5.2 节中的要求以及在 gTLD 应用中做出的相关结论。

问题 22: Q.26:ICANN 是否预计测试数量将在合同期大幅增加?

据预测,授权前测试将以每周 20 次测试的初始速度执行,有可能增加到每周 100 次。如 Q.26(a) 中所述,定价应按照测试提供。

问题 23: R.6:如果授权前测试提供商在内部/专用网络环境下工作,能否接受不对授权前测试代理进行相互认证?

不能,授权前测试系统应该在开放环境(如通过公共互联网)下运行 - 相互认证和加密是必要条件。

问题 24: IPv6 是"通过 IPv4 和 IPv6 执行测试"的必要条件吗?

在适用时,可通过 IPv6 执行测试。请注意,有些服务(如 DNS 和 Whois)必须通过 IPv6 提供(按照新 gTLD 协议规定 6 的要求)。

问题 25: R.18:什么是"gTLD 合同"?

gTLD 合同是已签署的"新 gTLD 协议"。

问题 26: R.19:遗漏的脚注 1 是什么内容?

http://www.iana.org/procedures/idn-repository.html

问题27: 没有适当提出 Q.26(b)

"数据托管代理机构发布流程测试。预计 ICANN 将要求在合同期以 20 次测试的顺序发布。"

问题 28: R.25:ICANN 是否将为 DNSSEC 信任锚测试提供根服务器?

否。

问题 29: R.26:ICANN 能以DPS 的标准提供更多详情吗?

根据基本协议规定 6 第1.3 节,DPS 应符合描述 DPS 框架的即将公布的 RFC(目前正在起草 https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/),而且它还说明了关键的安全控制措施和程序,例如密钥材料存储、自身密钥的访问和使用以及安全接受注册人公钥材料。

问题 30: 有关限制的问题

  1. 对于申请通过测试有时间限制吗?申请在 gTLD 向区域授权之前完成其技术测试有必要时限吗?
  2. 如果申请首次未能通过技术测试,在中止授权前测试程序之前还有多少次额外机会?
  3. 或者,如果还有其他测试,授权前服务提供商能向 ICANN 收取额外费用吗?

申请人应得到合理时间(所选提供商与 ICANN 商定),纠正技术问题或补充提交的信息。如果申请人无法在此时限内提供所需证据,测试应被视为失败。

问题 31: Q.5: 对于所列的分包商,需要任何具体信息吗?

如 Q.15(a) 所述,受访者应根据新 gTLD 申请人的当前列表提供利益冲突评估。

问题 32: 如果 TLD 运营商未能通过授权前测试中的部分测试,除了重新测试,ICANN 能否阐明授权前测试提供商预计向 TLD 运营商提供的支持程度?

预计授权前测试提供商将向申请人提供各失败测试的说明性答复,并允许申请人在最终无法通过测试之前,在合理时限内(所选提供商与 ICANN 商定)采取纠正措施。

问题 33: 由于必须列举名称和任播节点的 IPv4/IPv6 单播地址,如果 TLD 运营商不这么做,ICANN 希望在其正常运营过程中采取什么措施,使除了任播地址以外的任何其他公用 IP 地址可以到达任播组中的单独服务器?

如果 TLD 运营商无法允许授权前测试提供商对所有任播节点的单播地址进行查询,申请人将需要为所有不可测试的节点出示补偿可达性的结论。

问题 34: ICANN 能够阐明在审核自行认证加载测试时考虑的审计项目吗?

授权前测试提供商应审核自我认证文件,验证完整性、真实性以及是否符合在 gTLD 申请中做出的相关结论。

问题 35: 数据托管发布流程测试是否以数据托管代理向 ICANN 或向授权前测试提供商发布现有数据托管寄存为中心?

发布测试以 gTLD 数据托管代理向授权前测试提供商发布寄存为中心。

问题 36: 关于 2.3.4.4 中的数据托管,检查数据托管是否符合特定软件的要求是必要条件吗?

不是,授权前测试提供商应验证一个完全数据托管寄存和一个增量数据托管寄存的数据托管档案和数据托管格式。因此,该测试不依赖于特定软件。

问题 37: R.24:"验证可以在 24 小时内发布的数据"是指人工审核数据托管服务提供商与申请人之间的 SLA(由申请人提出),还是指必须由授权前测试提供商进行的实际测试,以确保采取符合数据托管要求的方式发布并返回数据?

在大多数情况下,ICANN 只希望审核 SLA,但是在某些情况下,ICANN 可以要求验证各数据托管服务提供商的实际发布能力。如 Q.26 中所述,ICANN 希望在合同期以 20 次该等测试的顺序发布。

问题 38: 只测试完全数据托管寄存可以接受吗?

不可以,AGB 规定了完全和增量寄存,说明这两种寄存都要接受测试。

问题 39: R.19 和 R.20:请阐明 IDN 表验证的要求

主要目标是验证申请人的 IDN 能力是否与所提供的 IDN 表中描述的一致。如果 IDN 表以可机读格式(即使用程序阅读)提供,将大大简化该等测试,但是 ICANN 认识到,可能存在其他格式的 IDN 表,例如更加复杂的变量生成算法。

问题 40: R.13:只需要为了所列的 EPP 命令测试 EPP 接口吗?

不是,应测试 EPP 接口的标准是否符合 gTLD《申请人指南》第 5.2 条中所述的要求,即"验证是否符合合适的 RFC(包括 DNSSEC 的 EPP 扩展部分)"。

问题 41: R.18:是否有审核申请人的 EPP 扩展部分所需的技术测试?

没有。

问题 42: 2.3.4.1:需要通过 HTTPS 测试 Whois web 界面吗?

如果 Whois web 界面通过 HTTPS 提供,应该进行测试。

问题 43: Q.26:"审计加载测试"是指人工审核申请人的自我认证文件,还是指授权前测试提供商必须独立运营,验证申请人做出的结论的实际测试。

Q.26(c、d、e)指授权前测试提供商进行的实际技术加载测试。预计只需要进行一小部分这些测试。


More Announcements
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."