<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Klavika Medium";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
line-height:normal;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
h1
{mso-style-priority:9;
mso-style-link:"Titre 1 Car";
margin-top:11.25pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;
line-height:normal;
font-size:17.0pt;
font-family:"Klavika Medium";
color:#569FCC;
font-weight:normal;}
h3
{mso-style-priority:9;
mso-style-link:"Titre 3 Car";
mso-margin-top-alt:auto;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;
line-height:normal;
font-size:13.5pt;
font-family:"Klavika Medium";
font-weight:normal;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
margin-top:0cm;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;
line-height:17.4pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.Titre1Car
{mso-style-name:"Titre 1 Car";
mso-style-priority:9;
mso-style-link:"Titre 1";
font-family:"Klavika Medium";
color:#569FCC;
mso-fareast-language:FR;}
span.Titre3Car
{mso-style-name:"Titre 3 Car";
mso-style-priority:9;
mso-style-link:"Titre 3";
font-family:"Klavika Medium";
mso-fareast-language:FR;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.date-display-single2
{mso-style-name:date-display-single2;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=FR link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><h1 style='background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif"'><a href="http://www.icann.org/en/news/announcements/announcement-08jun12-en.htm">http://www.icann.org/en/news/announcements/announcement-08jun12-en.htm</a><br><br>Open-Source Reference Implementation of a Domain Name RESTful Whois Server - Responses to RFP Questions<o:p></o:p></span></h1><p class=MsoNormal style='line-height:17.4pt;background:white'><span class=date-display-single2><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'>8 June 2012</span></span><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'><o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Respondents are requested to respond to the <a href="http://www.icann.org/en/news/announcements/announcement-3-16may12-en.htm">Request For Proposals</a> by replying to: <a href="mailto:rws-opensource@icann.org">rws-opensource@icann.org</a>. The period to submit questions about the RFP is now closed. The final response to the RFP is due on <strong><span style='font-family:"Arial","sans-serif"'>15 June 2012</span></strong>.<o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>The following 26 questions were submitted to <a href="mailto:rws-opensource@icann.org">rws-opensource@icann.org</a> 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.<o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Questions are grouped together where similar questions were received, or where the same answer is relevant to multiple questions.<o:p></o:p></span></p><h3 style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'>Requirements<o:p></o:p></span></h3><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>In The "Requirements" section, the RFP contains a link to <a href="http://tools.ietf.org/id/weirds">http://tools.ietf.org/id/weirds</a>. 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 <a href="http://tools.ietf.org/id/weirds">http://tools.ietf.org/id/weirds</a> are also required to be supported and why.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Yes, that's a correct assumption. The expected scope only covers domain name registries.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Shall the reference implementation serve both gTLDs as well as ccTLDs?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> Correct, it is expected that the reference implementation be usable for both gTLDs and ccTLDs.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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?<o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>The RFP does not clarify the output structure. Is there any expectation of data elements sequencing? If so, what are they?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Are there any specific requirements for the system performance? For example, is there a minimum requests-per-second requirement given specific hardware specifications?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> This is dependent on the protocol, which is not yet defined. We foresee it would require UTF-8, but may also support other encodings.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> Similar to the encodings question, this is dependent on what the protocol requires.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Is security testing part of the requirements and if so is the contractor developing the reference implementation required to execute those security tests?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> No, there are no requirements on this respect outside of what is described in the RFP.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>We are open to suggestions.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Shall the product, the documentation and support be in English only or shall more languages be covered? If so, please specify.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>At least English, and it would be great if there is the possibility of having other languages.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p class=MsoNormal style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'><o:p> </o:p></span></p><h3 style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'>Project Timeline<o:p></o:p></span></h3><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> The current timeline in the IETF says that the specs will be ready by August 2013, however that might change.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>What is the expected time between iterative spec releases and delivery of changes to the system?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p class=MsoNormal style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'><o:p> </o:p></span></p><h3 style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'>Evaluation of the RFP and Contracting<o:p></o:p></span></h3><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Who is the audience reviewing the RFP? And selection committee?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> A selection committee composed of technical experts will review the proposal.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Is there a budgeted amount for the project?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> We'd like to review the proposals from the interested providers. And we are open to hear options.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Is there a preferred contract type (Time & Materials, Firm Fixed Price, etc)?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> 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.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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)?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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.<o:p></o:p></span></p><p class=MsoNormal style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'><o:p> </o:p></span></p><h3 style='line-height:17.4pt;background:white'><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif";color:#555555'>Others Questions<o:p></o:p></span></h3><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>There is no requirement to contribute, but it would probably make sense for the contractor to, at least, follow the WEIRDS mailing list.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>ICANN has just published a Roadmap to Implement SAC 051 (<a href="http://www.icann.org/en/news/announcements/announcement-6-04jun12-en.htm">http://www.icann.org/en/news/announcements/announcement-6-04jun12-en.htm</a>), 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?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response:</span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'> Yes, it must conform to RFCs produced in the IETF, but it is also expected to be production quality.<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Question: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Can we expect registries to be involved during development and testing processes?<o:p></o:p></span></p><p style='background:white'><strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>Response: </span></strong><span lang=EN style='font-family:"Arial","sans-serif";color:#555555'>There might be some registries/registrars involved, but the selected provider should not count on that.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN style='font-size:12.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:12.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Arial","sans-serif";mso-fareast-language:FR'>Glen de Saint Géry <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Arial","sans-serif";mso-fareast-language:FR'>GNSO Secretariat <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Arial","sans-serif";mso-fareast-language:FR'><a href="mailto:gnso.secretariat@gnso.icann.org">gnso.secretariat@gnso.icann.org</a> <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Arial","sans-serif";mso-fareast-language:FR'><a href="http://gnso.icann.org">http://gnso.icann.org</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Arial","sans-serif"'><o:p> </o:p></span></p></div></body></html>