[council] Open-Source Reference Implementation of a Domain Name RESTful Whois Server - Responses to RFP Questions

[Glen de Saint Géry <Glen@xxxxxxxxx>]

http://www.icann.org/en/news/announcements/announcement-08jun12-en.htm

Open-Source Reference Implementation of a Domain Name RESTful Whois Server - 
Responses to RFP Questions
8 June 2012

Respondents are requested to respond to the Request For 
Proposals<http://www.icann.org/en/news/announcements/announcement-3-16may12-en.htm>
 by replying to: rws-opensource@xxxxxxxxx<mailto:rws-opensource@xxxxxxxxx>. The 
period to submit questions about the RFP is now closed. The final response to 
the RFP is due on 15 June 2012.

The following 26 questions were submitted to 
rws-opensource@xxxxxxxxx<mailto:rws-opensource@xxxxxxxxx> between 16 May and 5 
June 2012. The full set of questions and responses are being posted on ICANN's 
website for the benefit of all the respondents.

Questions are grouped together where similar questions were received, or where 
the same answer is relevant to multiple questions.

Requirements

Question: In The "Requirements" section, the RFP contains a link to 
http://tools.ietf.org/id/weirds. Under this URL, quite a few drafts are listed 
which are not strictly related to the classic TLD domain name Whois object 
model (which usually allows queries for registrars, domains, hosts and contacts 
in the registry's local object repository). In particular, 
draft-fiorelli-weirds-rws refers to the RIPE database instead, 
draft-newton-et-al-weirds-rir-json-response and 
draft-newton-et-al-weirds-rir-query refer to Regional Internet Registries 
(RIRs), draft-newton-weirds-arin-whoisrws refers to the ARIN Whois, and 
draft-lacnic-weirds-restwhois-redirects deals with redirection from a global 
Whois server. As for the RFP's requirements, may we therefore assume that only 
the remaining documents (draft-designteam-weirds-using-http, 
draft-kucherawy-weirds-requirements and draft-sheng-weirds-icann-rws-dnrd) - 
two of which are also explicitly referenced in the RFP's "References" section - 
are relevant as requirements for the reference implementation? If not, please 
specify which other drafts under http://tools.ietf.org/id/weirds are also 
required to be supported and why.

Response: Yes, that's a correct assumption. The expected scope only covers 
domain name registries.

Question: The WEIRDS group is creating two IETF standards for querying RIR 
data. AND Standards for querying domain name registration data. Must the 
reference implementation implement all of these standards or only the standards 
related to the domain name registration data.

Response: Given that there are only 5 RIRs and most of them are already 
involved in WEIRDS and working on their own implementations, we are focusing 
only on the domain name side. With 1k+ ICANN-accredited registrars, potentially 
hundreds of new gTLDs plus existing ccTLDs and given the limits on funding we 
decided to focus on the mainstream server population.

Question: In section 2.4.4, it is stated that the implementation should include 
a port 43 "proxy" that uses the RESTful Whois to answer requests and translates 
port 43 queries and responses accordingly. While this is a possible approach, 
our current Whois server implementation includes a port 43 implementation that 
*directly* accesses the Whois server database (i.e., it does not forward 
requests/responses to/from a different frontend), which allows for a much 
better port 43 performance. Is it OK for the reference implementation to use 
this direct approach instead of the "proxy" approach described in the RFP, as 
long as the implementation provides a port-43 Whois that answers queries in the 
same fashion as it would in "proxy" mode?

Response: No. To clarify, what we want is all the core services should be 
RESTful based, and realizing that some clients may still query port 43, we want 
the port 43 proxy to be able to translate those client requests into RESTful 
queries and return the result via port 43.

Question: Shall the reference implementation serve both gTLDs as well as ccTLDs?

Response: Correct, it is expected that the reference implementation be usable 
for both gTLDs and ccTLDs.

Question: A WHOIS server is basically a database query system. The database is 
the collection of information that a registry or registrar has about the 
domains, the query language is whatever the WHOIS server accepts, and the 
output is selected from the underlying database. What does the database 
contain, and what queries does the query language support?

While it is possible to intuit answers to these questions from the WHOIS 
appendixes of existing thick WHOIS registry agreements, the appendixes are not 
all the same. For example, the .INFO agrement specifies partial match queries, 
while the .BIZ agreement doesn't. The .AERO registry has an ENS_Authid field, 
and has privacy labels, while .ASIA has ENS_Authid but no privacy labels. The 
.XXX agreement refers to DNSSEC information, while earlier agreements don't. 
The .POST agreement refers to a Maintainer field rather than the Email field in 
other agreements. The .NAME agreement describes multiple levels of access and 
Defensive Registration objects.

We understand that different registries will continue to have somewhat 
different requirements, but it appears that many of the differences among the 
agreements are due more to evolving understanding of the needs rather than 
deliberate decisions to be different, e.g., partial vs. exact queries, DNSSEC, 
and Maintainer vs. Email. Can ICANN offer some guidance about what's expected 
to be in the underlying database and what sorts of queries need to be supported?

Response: What is in the underlying database and what queries are supported is 
up to the registry/registrar policy-making body as you highlighted in your 
description above.

In other words, we'd expect this RWS open-source implementation to be able to 
handle (be configurable) regarding the fields that it allows querying.

Question: The RFP does not clarify the output structure. Is there any 
expectation of data elements sequencing? If so, what are they?

Response: It is expected that the output structure will be defined in the IETF 
protocol. Currently the Internet Drafts cited in the RFP have a structure for 
domain names.

Question: Are there any specific requirements for the system performance? For 
example, is there a minimum requests-per-second requirement given specific 
hardware specifications?

Response: At this point we only have the set of requirements described in the 
RFP. We'd be interested in learning the proposals on this respect that 
potential providers can propose.

Question: Is there a specific list of supported encodings for Whois data that 
must be supported? For example, would it be sufficient to constrain requests 
and responses to UTF-8 or must there be support for a large number of 
encodings? Is it possible that registry/registrar data will need to be 
converted between encodings?

Response: This is dependent on the protocol, which is not yet defined. We 
foresee it would require UTF-8, but may also support other encodings.

Question: Is there a minimum requirement for what types of wire formats must be 
supported? For example, could the reference implementation only implement JSON 
and then allow other formats to be added on or must it support a minimum set of 
representations?

Response: Similar to the encodings question, this is dependent on what the 
protocol requires.

Question: Is there a minimum requirement for policy options? The RFP specifies 
the following: "The implementation should allow for parameter configuration of 
policy options" but this is fairly broad. Are there examples of the types of 
policies that may be required? For example, would this include policies such as 
request throttling, response filtering (i.e. extended details for whois 
requests from certain clients), etc.?

Response: We'd expect configuration options for the functionality that is 
defined in the protocol specifications. Things that are not defined in the 
protocol we don't expect them to be implemented. However, we'd expect the 
implementation to be done in a modular way that would allow an interested 
registry/registrar to modify it with a minimum effort to include extra 
functionality.

Question: Is security testing part of the requirements and if so is the 
contractor developing the reference implementation required to execute those 
security tests?

Response: We expect the final implementation to be production-quality code. 
Therefore, we'd expect, at least, some basic security testing and we'd expect 
the contractor to propose it.

Question: Are there any requirements about the overall management of the 
project or will this be left up to the contractor? For example, where will the 
code be hosted? What about issue tracking and development workflows?

Response: No, there are no requirements on this respect outside of what is 
described in the RFP.

Question: In order to minimize integration work, the RFP document specifies as 
an example that the various layers could be separated, see 2.4.2. of the RFP. 
Are you looking for a modular implementation so that there are separate 
products for the presentation, business logic and data access layer that can be 
used in combination or stand-alone?

Response: We'd not call them separate products, but having them as separate 
modules could make sense, or at least being able to configure them separately 
would be good.

Question: In terms of the parameter configuration according to section 2.5. of 
the RFP, shall the implementation only provide for the possibility of being 
configured or would ICANN be open to suggestions of e.g. an interface to 
configure various options that could already be included in the implementation? 
Could such approach be offered as an additional and optional module?

Response: We are open to suggestions.

Question: Shall the product, the documentation and support be in English only 
or shall more languages be covered? If so, please specify.

Response: At least English, and it would be great if there is the possibility 
of having other languages.

Question: The inclusion of third party code (2.6.) may lead to unpredictable 
costs in terms of quality control and documentation. Would ICANN be open to a 
cost model that includes such additional work on a time and material basis? The 
same would apply to the unspecified need for releases according to 2.2 or 
support.

Response: Yes, we are open to suggestions. But to clarify the idea of inclusion 
of third party code is only when it makes sense (from a cost perspective) for 
the provider to use it instead of doing the work from scratch itself.

Project Timeline

Question: What is the project timeline? The RFP specifies a one-year support 
period however it does not specify any expectations around deadlines for the 
working group to create the final specification nor does it specify any time 
expectations for delivery of the initial implementation.

Response: The current timeline in the IETF says that the specs will be ready by 
August 2013, however that might change.

Question: What is the expected time between iterative spec releases and 
delivery of changes to the system?

Response: We don't expect the selected provider to implement each and every one 
of the Internet-Drafts. We are planning to get together with the provider every 
time we believe it makes sense to do a new release and then agree with the 
provider on the delivery time and scope.

Evaluation of the RFP and Contracting

Question: Who is the audience reviewing the RFP? And selection committee?

Response: A selection committee composed of technical experts will review the 
proposal.

Question: Is there a budgeted amount for the project?

Response: We have some budget for the remaining of this fiscal year and we 
requested more for next fiscal year. We'd like to review the proposals from the 
interested providers.

Question: What is the total budget for the project? Is ICANN interested in 
fixed price offers or would ICANN also be open to a phased approach whereby 
requirements are first gathered and specified and costs are then estimated or 
offered on the basis of the findings of such interaction with ICANN?

Response: We'd like to review the proposals from the interested providers. And 
we are open to hear options.

Question: Is there a preferred contract type (Time & Materials, Firm Fixed 
Price, etc)?

Response: We are open to both, but perhaps the firm fixed price could be better 
aimed at a release instead of the whole project in recognition of the variable 
timeline.

Question: In the "Assessment and Award" section, the RFP notes that the exact 
timing of the award may depend on the IETF standardization process. In what way 
does ICANN expect the timing of the award to depend on the IETF process? 
Specifically, is the award likely to occur within, say, a month or so of the 
RFP response deadline, or could it be delayed until after November 2012 or 
August 2013 (the range of dates provided in the WEIRDS WG milestones)?

Response: We intend to award the contract as soon as possible. We expect the 
provider to produce releases before the RFCs are out, once there are somewhat 
stable specifications and with previous ICANN direction.

Others Questions

Question: The RFP requires that "the final product must conform to the relevant 
RFCs that will be standardized in the IETF WEIRDS WG." Does ICANN expect or 
require that the contractor participate in and/or contribute to the WEIRDS WG 
in order to ensure that the open source project maintains alignment with the WG?

Response: There is no requirement to contribute, but it would probably make 
sense for the contractor to, at least, follow the WEIRDS mailing list.

Question: ICANN has just published a Roadmap to Implement SAC 051 
(http://www.icann.org/en/news/announcements/announcement-6-04jun12-en.htm), 
which embraces the IETF work on a new protocol but also anticipates 
contributions from the ICANN community, particularly ccTLD and gTLD registries 
and registrars and the GNSO: "[t]his roadmap recommends a multipronged approach 
for the adoption of a replacement for the WHOIS protocol." Is the scope of the 
reference implementation project limited to the protocol specifications that 
will be produced by the IETF?

Response: Yes, it must conform to RFCs produced in the IETF, but it is also 
expected to be production quality.

Question: Can we expect registries to be involved during development and 
testing processes?

Response: There might be some registries/registrars involved, but the selected 
provider should not count on that.


Glen de Saint Géry
GNSO Secretariat
gnso.secretariat@xxxxxxxxxxxxxx
http://gnso.icann.org