ICANN|ARCHIVES
Internet Corporation for Assigned Names and Numbers
Please note:
You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.
NET RFP Application
Responses to Questions
5 January 2005
These questions were submitted by prospective applicants following the procedures described in the .NET RFP. Some of the questions have been edited for clarity and/or combined to avoid duplication. Questions and responses are being posted online in order to provide all prospective applicants with the same information. The .NET RFP question period closed on 6 January 2005. ICANN will continue to provide technical support via this question and answer forum during the entire application period. (Send technical support questions to <net-rfp@icann.org>.)
NOTE: Additional questions and/or responses may be posted. Please check back.
Responses to questions
The web-based application form for the .NET RFP will be available shortly, as soon as testing and finalization has been completed. Bona fide potential applicants may request a password and the URL for the application form by emailing a request to net-rfp@icann.org. Requests should include the organization name, contact person's name, e-mail address and telephone number.
2. Will questions to net-rfp be answered on a rolling basis, or all together at the end of the question period?
Questions will be answered on a rolling basis.
3. Throughout the RFP there are numerous references to any potential bidders having no contact with the ICANN staff, Board or independent evaluators. Please confirm, however, that an entity that contacts ICANN Staff in its normal course of business (i.e., to comply with any existing contractual obligations), if such contacts are wholly unrelated to issues surrounding the .net RFP, would not result in the disqualification of such entity?
Confirmed.
ICANN will identify the company that will conduct the independent evaluation and, depending upon the degree and type of contribution to the process, certain individuals that participate.
5. Will bidders be required to submit their entire application via the web-based form? How will charts, graphs and other graphics be submitted as described in the application? What are the size and format limitations of the graphics? (The application states: "Diagrams, charts and other similar material may be submitted in response to specific provisions where so indicated in the RFP as posted. In certain sections of the web-based form, applicants are permitted to make non-textual submissions together with, and as part of, their application (e.g., graphs, flowcharts, models and diagrams").
The initial application, in its entirety, will be submitted via the web-based form. As indicated in the application, ICANN may request supplemental materials in hard copy at a later date. Graphics can be uploaded for certain questions via the web-based form. Those questions are:
Graphics can be in the following formats: GIF, PNG, and JPEG; and will be displayed at a width of 640 pixels. Document formats such as .pdf or .doc cannot be uploaded (*except as indicated in answer #11 below -- updated 3 January 2005).
- Part Two, Question Four: Revenue and Pricing Model; Financial Strength and Stability.
There will be an opportunity to upload graphics separately for all parts of the question, i.e., sub-section (a), sub-section (b)i, sub-section (b)ii, sub-section (b)iii, sub-section (b)iv, sub-section (b)v.- Part Two, Question Five: Technical Competence
There will be an opportunity to upload graphics separately for all parts of the question, i.e., sub-section (a), and one each for sub-sections (b)i through (b)xix.
6. In what ways will the web-based application ensure that completeness of responses is not unduly limited? Will there be options for submitting applications other than the web-based form?
The application is designed to solicit information that is necessary and sufficient for knowledgeable, competent evaluators to select a .net successor. This method has been verified during the similar (but admittedly different) sTLD process. In the event that additional information is required, that information will be solicited through an intermediary so that the interaction between applicants and evaluators will be at arm's length. All applications must be submitted using this form.
7. The .NET RFP, under 'Part 2, Section 4: Revenue and Pricing Model', states: "All applicants should note that registration fees paid to VeriSign prior to the actual transfer of operational responsibility will not be transferred to a subsequent registry operator." Please clarify what is meant by this statement regarding the transfer of registration fees.?
The current .NET Registry Agreement between ICANN and VeriSign does not provide for VeriSign, in the event that it is not selected as the successor, to make any payment to the successor .NET registry operator to account for revenues VeriSign has already received by the turnover date for registration periods in the future. Correspondingly, it does not provide for the successor registry operator to make any payment to VeriSign to account for the value of the existing customer base at turnover.
8. There is a text limit on the web-based form of 20000 characters, including spaces. That works out to roughly seven pages of text per answer box. While this is plenty of space to adequately discuss and detail an applicant's solution for some components, other components will require more space to be adequately evaluated, including, but not limited to Section 8: Transition. Was it ICANN's intent to limit the text and if so, will ICANN reconsider allowing applicants unlimited space to respond to the RFP?
Yes, the 20000 character limit was intentional; see answer #6 above. However, in order to allow applicants to fully respond to each of the eight sub-questions in Part 2, Section 8 (Transition), the character limit for that text box only will be set at 160000 characters.
9. The web-based form text indicates that graphics are allowed in Part 2, Section 5, Technical Competence, but the mechanism to upload graphics is only part of Subsection 5.b.xiii, System security and physical security. Will ICANN change the form to allow the upload of graphics for the remainder of Part 2, Section 5?
Yes.
10. Currently, the web-based form provides no mechanism to upload graphics for Part 2, Section 8, Transition and Migration Plans. We believe that graphics will be essential to adequately articulate and properly evaluate this section. Will ICANN change the form to allow the upload of graphics for Part 2, Section 8?
Yes.
11. In Part II, section 4 (a) the application form requests copies of audited financial statements. How should this information be submitted into the web based application form?
The application form is being modified to allow the upload of PDF documents for Part II, section 4 (a) only.
12. Point 4 of the "RFP Checklist" indicates that a copy of the application should be printed, signed and sent to ICANN. By when and how should the copy be sent?
Please send the printed, signed copy of the completed application to ICANN via postal mail or delivery service (e.g. DHL or FedEx) no later than close of business on 21 January 2005.
13. I'm not sure whether the login info can be used by multiple personnel. Should we request additional login info for each person?
You should not request additional logins -- a separate login would specify a different application. A single login can be used by multiple people at the same time. However, it's important to be aware that there is a risk of inconsistency if multiple people are editing the forms simultaneously, or even if a single person edits the same page in multiple windows.
In more detail, when you click on the "Update" button at the bottom of a page, ALL the form elements on that particular page are updated. If you have an old version of the page sitting in a window (perhaps by clicking the "back" button several times), and click on the "Update" button, the old information will overwrite any new information.
As long as these concerns are kept in mind, it should be OK for different people to work on different pages at the same time.
Text input boxes use a fixed-width font, and white space will be preserved, so simple purely text-based tables can be used.
Please see the technical information page (link can be found on application form).
16. The provided space in the form for many chapters is not sufficient for a qualified answer. Additionally, it appears that only one graphic per box is allowed. For some sections, several graphics would be helpful to both properly articulate and evaluate applicants' solutions. Will ICANN modify the web-based form to allow more than one graphic per box?
Please refer to question numbers 6 and 8 above regarding the character limit on text boxes. Note that the width is fixed at 640 pixels, but the height is not specified, so you can paste several images into one long graphic. An interface to allow multiple graphics per text box would make the form significantly more complex for the user. In addition, multiple images would complicate the format of the document when producing the final result.
17. Part 2 Section 5 of the .net RFP reads, "the applicant should include its own proposed versions of appendices C, D, E, O, P, Q, and R based on the current. NET registry agreement <http://www.icann.org/tlds/agreements/verisign/net-index.htm> which the applicant would be willing to have included in the subsequent. NET registry agreement." Changes to the existing .net appendices are also appropriate for several other appendices but there is no provision for submitting those in the web-based form. Will provision be added to the web-based form to allow this?
Any changes to other appendices would be addressed during the contract negotiation phase.
18. Do you therefore plan to provide the applicants with a communication channel regarding the web based form after January 6?
Yes, ICANN will continue to provide technical support via this question and answer forum during the entire application period. (Send to net-rfp@icann.org.)
"Restart capability" refers to the ability to bring registry operations back on-line after an unanticipated outage.
The submission deadline is 18 January 2005 at 23:59 UTC.
The "users" are registry staff authorized to make changes to the zone file.
22. The Final .NET Request for Proposals (see, http://www.icann.org/tlds/dotnet-reassignment/net-rfp-final-10dec04.pdf) indicated that the planned date for the Announcement of Successor .NET Registry Operator would be March 2005. The registry agreement between ICANN and VeriSign will expire on the 30th of June 2005. This leaves approximately three months in order for the successful operator to have built, tested, deployed and transitioned the .NET registry, including such things as an OT&E environment at least one month before the “go live” date and the technical accreditation of all registrars. This also implies that any “back out” plan for the transition could not rely on the incumbent to continue registry services. Can you please confirm that this is correct?
Confirmed. The target date for the announcement of the designated successor .NET registry operator is March 2005. The current .NET Registry Agreement (see, http://www.icann.org/tlds/agreements/verisign/registry-agmt-net-25may01.htm) does expire on 30 June 2005. Section 5.2.3 of the current .NET Registry Agreement provides that if the incumbent is not designated as the successor Registry Operator, that the incumbent, "shall cooperate with ICANN and with the successor Registry Operator in order to facilitate the smooth transition of operation of the registry to successor Registry Operator," but does not specifically require the incumbent to make its registration or resolution facilities available to the successor operator following 30 June 2005.
23. I cannot find the link to technical information page on the application form. Can you provide more details on this?
The link to the technical information page appears at the very bottom of the index page of the application; the URL can also be found towards the end of the email that furnished your user name and password to enter the web-based application form.
24. I understand that that multiple graphics can be pasted below each other into one long graphic. Our browsers do not allow for an accurate way of printing graphics longer than one page. For the final printed version of the application, will you accept graphics that are printed out individually and handed in with the printout of the completed application form?
Yes. However, the purpose of the printed application is only to provide a signed, hard copy of the application. The independent evaluators will not see the furnished hard copy you provide but will rely on the uploaded files. Truncated graphics in the printed copy of your application will not affect the evaluation of the application. If you wish, you can adjust the printed appearance by adjusting the size of each file.
25. In Section 2 #5b, xvii, applicants are asked to detail their, "...[a]bility to support the current feature functionality of .NET, including IDNs, support of IPv6, DNSSEC," and "[m]aintaining existing functional capabilities..." is also included in Section 8. Will ICANN require the incumbent to detail these feature functionalities such that a comparison can be made?
The incumbent is not obligated by the current registry agreement to provide additional functional detail. As indicated in section 2 #5b, xvii, applicant responses should be based on information “publicly or otherwise available to the applicant.” Similarly, applicant responses to section 8 should be based upon publicly or otherwise available information.
26. Part 1 of the RFP asks applicants to supply the following information: "Also identify any persons or entities who own or will own or otherwise control, directly or indirectly, 5% or more of the outstanding voting power held by all persons or entities entitled to participate in the election (or other selection) of the applicant's board of directors or other governing body."
As a point of clarification, and in an effort to better understand what is intended by the term "indirect" ownership or control, does the above cited language require the applicant to disclose the names of the following:
a. A majority shareholder (or some other ownership threshold) of an entity that owns more than 5% of the voting power of the applicant? In the case of public companies as opposed to private companies, is there a certain ownership threshold that would give rise to a disclosure obligation?
b. The CEO (or other senior officers) of an entity that owns more than 5% of the voting power of the applicant?
The ultimate goal is to understand what natural persons exercise control over the applicant, so if the disclosure in response to this instruction reveals a chain of entities without a natural person at the end of the chain, we may request additional information about the ownership of the entities in the chain until we reach a natural person.
If the applicant is a public company, with registration similar to that required by the U.S. Securities and Exchange Commission, it will be sufficient to provide the information about the applicant regarding security ownership of certain beneficial owners that the company includes in the periodic reports it files with the governmental registry.
If the applicant is not such a public company, then please identify each natural person and each entity whose holdings of applicant's equity securities exceed the 5% threshold. Please also provide for each such entity the name of the CEO (or managing director or other person who performs the functions of a CEO) and the names of any equity holders whose equity ownership of such entity exceeds 30%.
27. RFP Part 2, Section 5 states, " the applicant should include its own proposed versions of appendices C, D, E, O, P, Q, and R based on the current .NET registry agreement which the applicant would be willing to have included in the subsequent .NET registry agreement." Is it acceptable to provide draft appendices based on .biz, .info, .name or .pro, the ICANN-accredited thick registries?
The application calls for the applicant to propose the text of appendices that will become part of the new .NET agreement. .Based on the current .NET agreement,. refers to the subject matter (that must be adequately covered) in of each of those appendices indicated. The text of the proposed appendices is not required to match the existing .NET text.
ICANN has performed additional testing to ensure that PNG files can be uploaded into the application form. An earlier problem with certain browsers and PNG files was resolved. Please refer to the technical page for additional details on graphic image uploads.
29. The answer box for Section 7, Additional Relative Criteria, allows 20,000 characters for the three Roman numeral subsections (in total). Will ICANN allow 20,000 characters for each Roman numeral or a total of 60,000 characters for the one box?
No. The box will continue to be limited to 20,000 characters.
30. Part 2, Section 5 of the RFP states, "Along with providing the information requested below, the applicant should include its own proposed versions of appendices C, D, E, O, P, Q, and R based on the current .NET registry agreement . . ." The web-based application form only provides input boxes for C.4 and C.5. Is it correct to assume that only C.4 and C.5 should be submitted?
Submit proposed text for C.4 (Nameserver Functional Specifications) and C.5 (Patch, Update, and Upgrade Policy) only.
31. Some of our proposed answers to the .NET RFP Part 2.5, Technical Competence, exceed the character limitations of the respective fields. How should the proposed appendix be submitted?
The answers to this section, i.e., the proposed appendices, should be limited to 20,000 characters each.
32. The response in question 8 to the NET RFP Application Responses to Questions dated 5 January 2005 indicates that "the 20000 character limit was intentional," the web form is not enforcing a 20,000 character limit but is instead enforcing a 20,000 byte limit. Returns are counted as two characters by the web form, this can impact the response length by 15% or greater. When will the web form be adjusted to support character limits instead of byte limits?
No further modifications to the web-based form are contemplated at this time. Embedded character count methodologies vary among systems. The web-based form has consistently counted bytes and characters as equivalents throughout the application process.
33. The web form does not have word-wrapping or other boundary constraints on text box width, when printing a web page that scrolls to the right, the text is truncated. How do we make sure this text is not lost?
Text boxes are implemented with "textarea" html elements set to do hard wrap at 80 columns. Different browsers may handle these elements differently. Applicants can view the printed format by either clicking on the preview link at the bottom of each section or the "Preview Entire Application" at the bottom of the Index page.
34. Will technical support be available over the weekend and on Monday, 17 January were an applicant to have problems submitting text or graphics?
Yes. Technical support will be available via net-rfp@icann.org.
35. We encountered a problem when trying to upload graphics in section Part 2, No. 8. We tried with different graphics of different file sizes, formats, names etc. but nothing was uploaded. Would you please check if there is a technical problem on your side?
This has been fixed.
36. We encountered "Content too big" errors when uploading a graphic. Our file was within the 640 pixel limit. Is there a problem?
We believe this has been fixed. The error message has been enhanced to give more information. If you continue to see problems please let us know immediately. (Note that the 640 pixel limit is not a size limit for file uploads. The size limit is set at about 4,000,000 bytes.)
This has been fixed.
38. We filled in some of the checkboxes in the "Final Steps" checklist, and then went back and edited some of our previous answers. The checkboxes we had earlier checked were no long checked. Is this intentional?
Yes. The checkboxes should reflect the final version of the form, and should be filled in last.
39. One of our responses has an extremely long URL that exceeds the 80 column word-wrap setting. This causes problems with the formatting of the output. What can we do?
Manually break the long string into multiple lines, none of which exceeds the 80 character limit. For example, a URL like this:
http://www.my-company-with-a-very-long-name.com/Very-long-first-level-name/Very-long-second-level-name/file.htmlcan be presented as:http://www.my-company-with-a-very-long-name.com/ Very-long-first-level-name/ Very-long-second-level-name/file.htmlThis problem can occur with any unbroken string of characters that exceeds the word-wrap limit; the formatting that results is a function of the browser's formatting algorithms, which we cannot control. In all such cases you must manually wrap the string.