|
ICANN Questions:
ICANN is in the process of reviewing Diebold's TLD Application. As outlined in the October 23, 2000 TLD Application Review Update which
appears at http://www.icann.org/tlds/tld-review-update-23oct00.htm, ICANN may
"gather the additional information [it] require[s] by posing specific
questions to applicants in e-mail and requesting a written response."
Keeping in mind the goal to evaluate applications to operate or sponsor
new TLDs in as open and transparent a manner as possible, both the questions
posed by ICANN and the Applicant's responses will be publicly disclosed
on the ICANN website.
Accordingly, ICANN requests your reponses to the following questions:
1. Identify and summarize Applicant's assumptions with respect to the
existence of other general purpose TLDs in determining the total number
of registrations in your application.
2. Identify and describe in detail your estimated DNS availability.
3. Identify and describe in detail the DNS service level to which your
are willing to contractually commit.
4. Identify and describe in detail your estimated registrant access availability.
5. Identify and describe in detail the registrant access service level to which you are
willing to contractually commit.
6. Identify and describe in detail your estimated Whois service
availability.
7. Identify and describe in detail the Whois service level to which you
are willing to contractually commit
8. If you intend to provide bulk Whois service,identify and provide a
summary of the party or parties who will provide that service.
9. Identify and describe in detail the your average and worst case
transaction times for the following:
10. Identify and describe in detail the service level to which you are
willing to contractually commit for the following:
11. Identify and describe in detail your projected level of Whois query
traffic.
12. Identify and describe in detail the projected query traffic level to
the Whois function to which you are willing to contractually commit.
Note: It is ICANN's assumption, from your application, that Diebold does
not intend to support independent registrars. If this is in fact the case,
then part or all of questions 13, 14, and 16 may not apply.
13. Assuming you receive a new TLD, identify and describe in detail the
timetable for the availability of the following services:
14. Identify the service availability timetable to which you are willing
to contractually commit for the following:
15. Assuming your primary site experiences a catastrophic failure,
identify and describe in detail the timetable required to restore:
16. Identify whether you will provide a test-bed for registrars to
validate their protocol software.
Diebold Responses:
1. Our application is based on the belief that new gTLDs should be allowed to grow organically; that is, creating the market of value and allowing market players to participate where they feel there is value. This model offers the Internet community the highest potential value, regardless of the number of TLDs approved.
We believe the number of TLDs (that are in models similar to ours) are a major element in our business model, and will materially affect it. We based our projections of potential registrations on the ICANN Names Council recommendation of the initial introduction of 6-10 new TLDs, and assumed, for that purpose, that they would all be un-sponsored.
Diebold is interested in fostering the organic development of financial, security and global affinity groups across the Internet. If ICANN pursues its originally stated path, there will likely be many more TLDs at some point in the future, decreasing the number of registrations for any one TLD and increasing the potential functional value of a specific TLD. While this approach would likely affect the revenue potential of our model, it works well into our view of certain TLDs and their value to the Internet community and Diebold.
2. Diebold has designed a system where the potential for downtime (meaning the inability to access DNS for resolution of names within the TLD) is extremely small. Our initial rollout utilizes three coordinated sites worldwide (North America, Europe, Asia-Pacific), with the potential for rollout to additional sites around the globe as need dictates (please see our application for additional detail on our system design, and our web page at http://www.diebold.com for more information). Our design also employs all available redundancy practices for systems, communications and power.
Diebold estimates our uptime for DNS resolution during the “start-up period” of approximately 150 days will exceed 99%. This estimate could vary due to adjustments necessary during the “start-up period”.
Diebold estimates our operational uptime for DNS resolution will exceed 99.9087% (less than 8 hours aggregate downtime per year), including what time might be necessary for the update of systems software, database systems, etc.
3. While we believe the numbers quoted in the response to Question 2 accurately represent the capabilities of our system, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate Service Level Agreement with ICANN per the ICANN posting at http://www.icann.org/tlds/application-process-03aug00.htm: “After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.”
4. Diebold has designed a system where the potential for downtime is extremely small. Our initial rollout utilizes three coordinated sites worldwide (North America, Europe, Asia-Pacific), with the potential for rollout to additional sites around the globe as need dictates (please see our application for additional detail on our system design, and our web page at http://www.diebold.com for more information).
Diebold estimates our uptime for registrant access during the “start-up period” of approximately 150 days will exceed 99%. This estimate could vary due to adjustments necessary during the “start-up period”.
Diebold estimates our operational uptime for registrant access will exceed 99.863% (less than 12 hours aggregate downtime per year), including what time might be necessary for the update of systems software, database systems, etc.
5. While we believe the numbers quoted in the response to Question 3 accurately represent the capabilities of our system, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate Service Level Agreement with ICANN per the ICANN posting at http://www.icann.org/tlds/application-process-03aug00.htm: “After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.”
6. Diebold has designed a system where the potential for downtime is extremely small. Our initial rollout utilizes three coordinated sites worldwide (North America, Europe, Asia-Pacific), with the potential for rollout to additional sites around the globe as need dictates (please see our application for additional detail on our system design, and our web page at http://www.diebold.com for more information).
Diebold estimates our uptime for Whois during the “start-up period” of approximately 150 days will exceed 99%. This estimate could vary due to adjustments necessary during the “start-up period”.
Diebold estimates our operational uptime for Whois will exceed 99.817% (less than 16 hours aggregate downtime per year), including what time might be necessary for the update of systems software, database systems, etc.
7. While we believe the numbers quoted in the response to Question 5 accurately represent the capabilities of our system, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate Service Level Agreement with ICANN per the ICANN posting at http://www.icann.org/tlds/application-process-03aug00.htm: “After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.”
8. Diebold does not intend to provide bulk Whois service at this time.
9. b. The Diebold registration system provides initially for updates to the Whois database every 8 hours. More frequent updates are possible if deemed necessary, and may be done more frequently under exceptional load conditions.
c.
10.
While we believe the numbers quoted in the response to Question 9 accurately represent the capabilities of our system, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate Service Level Agreement with ICANN per the ICANN posting at http://www.icann.org/tlds/application-process-03aug00.htm: “After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.”
b. See above
c. See above
11. Diebold anticipates a highly variable Whois query traffic load.
Whois traffic load capabilities could be described in three areas of capability: Anticipated load, sustained (pressure) load, and peak (pulse) load.
12. While we believe the numbers quoted in the response to Question 10 accurately represent the capabilities of our system, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate Service Level Agreement with ICANN per the ICANN posting at http://www.icann.org/tlds/application-process-03aug00.htm: “After approval by the Board, ICANN to announce selections for negotiations toward entry of agreements with registry sponsors and operators.”
Diebold Response to Note:
Diebold does not intend to support independent registrars initially, as specified in our application. We believe there could be value in the support of independent registrars at some point in the future. Diebold believes the best potential for success and stability of the Internet during the introduction of new TLDs exists in an initial model where Diebold is both registry operator and registrar.
We have, therefore, not responded to portions of questions 12, 13 and 14. Diebold would look forward to readdressing these questions at a later date as required.
13. Specific dates for the availability of systems would not be appropriate , however Diebold anticipates the following timeframes for registry systems availability.
a. Not applicable.
b. The beginning of the “sunrise period” would commence approximately 60 days after the signing of a contractual agreement with ICANN.
c. For the purposes of this response, Diebold assumes “full operation” to mean full system functionality after the sunrise period. Diebold has stated, within the TLD Policy Description portion of our application, that we are proposing a sunrise period of 90 days. By the definition above, our timetable goal for “full operation” would be approximately 150 days after reaching contractual agreement with ICANN.
Please note that this timetable differs slightly from the 120 days suggested in our application as an initial TLD's "start-up period," during which special procedures should apply for pricing.
Diebold anticipates our systems will be fully functional on the first day of the sunrise period, and will consider this to be the beginning of the “pilot period”, during which systems modifications and fine tuning will be possible. The “pilot period” will end on or before the end of the “sunrise period”.
Diebold is flexible and would welcome working openly with ICANN to further refine the timetables suggested in this response.
d. Not applicable.
14. While we believe the timetables quoted in the response to Question 12 accurately represent our ability to deliver, Diebold is not prepared to enter into a contractual agreement in this response.
We are, however, prepared to negotiate an appropriate operational date and Service Level Agreement with ICANN per the ICANN posting at 15. Diebold has designed a system that is highly tolerant of any single site experiencing catastrophic failure. (see response to Question 2 and design information in our application at http://www.icann.org/tlds/cash1/tld-app-registry-operator-proposal-15aug00-diebold-1.htm
b. Diebold has designed our registration system so that, once cut-over takes place, full registrant access system functionality is available through the fail-over sites.
Depending on the nature of the system failure, the failed site would be restored in as little as one hour but, in any event, less than 24 hours.
16. Not applicable.
|
