Skip to main content

域名 RESTful Whois 服务器的开源参考实现 - 针对 RFP 问题的回应

本页面还提供其他语种:

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

以下 26 个问题已于 2012 年 5 月 16 日至 6 月 5 日之间提交到 rws-opensource@icann.org。从所有受访者的利益出发,全部问题与回应将在 ICANN 网站上发布。

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

要求

问题:在"要求"部分,此 RFP 包含至 http://tools.ietf.org/id/weirds 的链接。在此 URL 下方,列出了一些与典型 TLD 域名 Whois 对象模式(通常允许在注册管理机构的当地对象存储库中对注册服务商、域名、主机和联系人进行查询)没有密切关系的草案。具体地说,draft-fiorelli-weirds-rws 涉及 RIPE 数据库,draft-newton-et-al-weirds-rir-json-response 和 draft-newton-et-al-weirds-rir-query 涉及地区互联网注册管理机构 (RIR),draft-newton-weirds-arin-whoisrws 涉及 ARIN Whois,而 draft-lacnic-weirds-restwhois-redirects 则处理从全球 Whois 服务器的重新定向。对于 RFP 的要求,我们能因此假定根据参考实现的要求,只有剩余文档(draft-designteam-weirds-using-http、draft-kucherawy-weirds-requirements 及 draft-sheng-weirds-icann-rws-dnrd)– 其中两个还在 RFP 的"参考"部分明确引用 – 是相关的吗?如果不是,请指明还要求支持 http://tools.ietf.org/id/weirds 下的哪些其它草案及其原因。

回应:是的,这一假定正确。预期范围仅涵盖域名注册管理机构。

问题:WEIRDS 小组正在为查询 RIR 数据创建两个 IETF 标准,以及查询域名注册数据的标准。参考实现必须实施所有这些标准,还是只需实施与该域名注册数据有关的标准?

回应:鉴于只有 5 个 RIR,而且他们中的大部分已经参与 WEIRDS 并正在处理他们自己的实现,我们只关注域名方面。由于有一千多个 ICANN 认可的注册服务商、数百个潜在的新 gTLD 加上现有 ccTLD 并考虑到资金限制,我们决定重点关注主流服务器人口。

问题:第 2.4.4 节中说明了,实现应包含端口 43"代理",使用 RESTful Whois 回答问题并相应地翻译端口 43 的查询和回应。虽然这是一种可能的途径,但我们当前的 Whois 服务器实现包括*直接*访问 Whois 服务器数据库(即它不会向/从不同前端转发请求/回应)的端口 43 实现,它能达到更出色的端口 43 性能。只要实现提供以与"代理"模式中相同的方式回答查询的端口 43 Whois,参考实现是否可以使用此直接方法而不是 RFP 中描述的"代理"方法?

回应:否。这里要澄清一下,我们想要的是所有核心服务基于 RESTful,并实现某些客户端仍可查询端口 43,我们希望端口 43 代理能够将那些客户端请求翻译成 RESTful 查询并通过端口 43 返回结果。

问题:参考实现是否同时为 gTLD 和 ccTLD 服务?

回应:正确,预期参考实现可同时用于 gTLD 和 ccTLD。

问题:WHOIS 服务器基本上是一个数据库查询系统。此数据库是注册管理机构和注册服务商所拥有的关于域名的信息集合,查询语言是 WHOIS 服务器接受的任何语言,而输出是从底层数据库中进行选择。此数据库包含哪些内容,以及查询语言支持哪些查询?

虽然可以从现有的各种 WHOIS 注册管理机构协议的 WHOIS 附录得出这些问题的答案,但这些附录并非都是一样的。例如,.INFO 协议规定了部分匹配的查询,而 .BIZ 协议没有。.AERO 注册管理机构具有 ENS_Authid 字段和隐私标签,而 .ASIA 具有 ENS_Authid 但没有隐私标签。.XXX 协议涉及 DNSSEC 信息,而早先的协议并非如此。.POST 协议涉及"维护者"字段而不是其它协议中涉及的"电子邮件"字段。.NAME 协议描述了多个访问级别和保护性注册对象。

我们明白,不同注册管理机构将继续存在多少有所不同的要求,但协议之间的许多差异似乎更多地源于对需要的进一步了解而非不同的慎重决定,例如部分查询对精确查询、DNSSEC 及维护者对电子邮件。ICANN 能否就底层数据库中的预期内容和需要支持的查询种类提供一些指引?

回应:底层数据库的内容和所支持的查询取决于您在以上描述中高亮显示的注册管理机构/注册服务商政策制定机构。

换言之,我们预期此 RWS 开源实现能够处理(可配置)其允许查询的领域。

问题:RFP 没有阐明输出结构。对数据元素定序是否有任何期望?如果有,是怎样的?

回应:预期将在 IETF 协议中定义输出结构。当前 RFP 中所述的互联网草案具有域名结构。

问题:对系统性能是否有任何具体要求?例如,对于具体的硬件规格是否有最低每秒请求次数要求。

回应:此时,我们只有 RFP 中所述的那一套要求。我们有兴趣了解潜在提供商可就此方面提出的提案。

问题:是否有一个必须支持 Whois 数据的受支持编码的具体列表?例如,将请求和回应限制为 UTF-8 是否足够,还是必须支持大量编码?注册管理机构/注册服务商数据是否有可能需要在编码之间转换?

回应:这取决于协议,当前尚为定义。我们预计它需要 UTF-8,但也可能支持其他编码。

问题:对于必须支持的线格式类型是否有最低要求?例如,参考实现能否仅实施 JSON 然后允许添加其他格式,还是它必须支持最低限度的一组表示法?

回应:类似于编码问题,这取决于协议的要求。

问题:对于政策方案是否有最低要求?RFP 说明如下:"实现应允许政策方案的参考配置",但这概括性太强。对于可能要求的政策类型,是否有示例?例如,这是否包括诸如请求限制、请求过滤(即来自特定客户端的 whois 请求的扩展详细信息)等的政策?

回应:我们期望针对协议规范中定义的功能提供配置选项。对于协议中未定义的内容,我们不期望它们会实现。但是,我们期望以模块化的方式完成实现,允许感兴趣的注册管理机构/注册服务商轻松地进行修改以纳入额外的功能。

问题:安全性测试是否为要求的一部分?如果是,制定参考实现的承包商是否需要执行那些安全性测试?

回应:我们期望最终实现是生产级质量的代码。因此,我们期望,至少完成一些基本的安全性测试,并且我们希望由承包商来提出。

问题:对于项目的总体管理是否有任何要求,还是让承包商来决定?例如,此代码存放在何处?问题跟踪和发展工作流程又如何?

回应:没有,除 RFP 中所述内容之外,对这方面没有要求。

问题:为了尽量减少整合工作,RFP 文档举例详细说明了各层可相互分离,请参见 RFT 第 2.4.2. 节。你们是否在寻求一个模块化的实现,以使得有可组合或独立用于表示法、业务逻辑和数据访问层的不同产品?

回应:我们不会将其称为单独的产品,将其视作单独的模块更为合理,或者至少能够单独配置它们就很好。

问题:根据 RFP 第 2.5 节,关于参考配置方面,此实现仅提供被配置的可能性,还是 ICANN 乐于接受建议,例如对于配置可能已经包含在实现中的各种选项的界面?此类方法能否作为附加和可选模块提供?

回应:我们接受建议。

问题:产品、文档和支持仅以英文提供还是涵盖更多语言?如果是,请指明。

回应:至少有英文,如可能提供其他语言则更佳。

问题:纳入第三方代码 (2.6.) 可能导致质量控制和文档方面的无法预测的成本。考虑到时间和材料,ICANN 是否会乐于接受纳入此类额外工作的成本模式?根据 2.2 或支持,同样的模式适用于发布的未指明需要。

回应:是,我们接受建议。但需要澄清,纳入第三方代码的想法仅在提供商使用它而不是从头开始工作更合理(从成本方面来说)时才适用。


项目时间表

问题:项目时间表是怎样的?RFP 规定了长达一年的支持期,但却没有为工作组创建最终规范指定任何预计截止日期,也没有为最初实现的交付指定任何预计时间。

回应:IETF 中的当前时间表显示,该规范将于 2013 年 8 月准备就绪,但可能有变。

问题:迭代规范发布与变更至系统的传递之间的预计时间是?

回应:我们并未期望所选提供商实施每一个互联网草案。我们计划在每次我们认为需要做一个新版本的时候将提供商聚集到一起,然后就交付时间和范围与提供商达成协议。


RFP 评估和签约

问题:审阅此 RFP 的读者有哪些?评选委员会是?

回应:由技术专家组成的评选委员会将审阅此提案。

问题:此项目是否有预算成本?

回应:我们在本财年的剩余预算中占有一定额度,并且我们为下一财年申请了更多预算。我们期待审阅来自感兴趣提供商的提案。

问题:此项目的总预算是多少?ICANN 是否对固定价格感兴趣,还是 ICANN 也接受分阶段方法,即先收集和指定要求,然后根据与 ICANN 的此类互动的成效来估算或提供成本?

回应:我们期待审阅来自感兴趣提供商的提案。我们愿意听取各种方案。

问题:是否有首选的合同类型(时间和材料、严格固定价格等)?

回应:这两种都可以接受,但是按照可变时间表,较之整体项目而言,也许严格固定价格更适合某个版本。

问题:在"评估和授予"部分,RFP 写明授予的准确时间可能取决于 IETF 标准化流程。ICANN 以何种方式预计授予时间取决于 IETF 流程?具体地说,授予可能在 RFP 回应截止日期后的一个月左右进行,还是可能延迟到 2012 年 11 月或 2013 年 8 月后(WEIRDS 工作组里程碑中提供的日期范围)?

回应:我们希望尽快授予合同。一旦有某种稳定的规范并凭借之前的 ICANN 指导,我们期望提供商在 RFC 出来之前完成版本。


其他问题

问题:RFP 要求"最终产品必须符合将在 IETF WEIRDS 工作组中标准化的相关 RFC"。ICANN 是否期望或要求承包商参加和/或协助 WEIRDS 工作组,以确保开源项目与工作组保持一致?

回应:不要求协助,但承包商可能有必要至少遵照 WEIRDS 邮件列表。

问题:ICANN 刚刚发布了实施 SAC 051 (http://www.icann.org/zh/news/announcements/announcement-6-04jun12-zh.htm) 的路线图,其中包含有关新协议的 IETF 工作,但也预计了 ICANN 机构群体,特别是 ccTLD 和 gTLD 注册管理机构和注册服务商及 GNSO 的协助:"这个路线图为采纳 WHOIS 协议的替代建议了一种多管齐下的方法。"参考实现项目的范围是否局限于将由 IETF 制定的协议规范?

回应:是,它必须符合 IETF 中制定的 RFC,而且预计它具有生产级质量。

问题:我们能否期望注册管理机构参与制定和测试流程?

回应:可能有某些注册管理机构/注册服务商参与,但所选提供商不应依靠这一点。


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