Table of Contents

1. Supplemental Question No. 1

According to the Criteria for Assessing Proposals, "ICANN will place significant emphasis on the demonstrated ability of the applicant or a member of the proposing team to operate a TLD registry of significant scale in a manner that provides affordable services with a high degree of service responsiveness and reliability." In various parts of the written proposals submitted, and in the presentations given at the ICANN Public Forum on the evening of 26 June 2002 in Bucharest, applicants frequently made references to the number of domain names they (or their team members) support as either a registry operator or a registrar that interacts with a registry. For consistency sake, we are asking all applicants to clarify their responses and presentations by providing details, including the number of domain names, they (or their team members) support in each registry or registrar operation they wish to have considered in the course of the evaluation.

Specifically, please give the following details separately for each registry or registrar operation you wish to have considered:

We wish to have considered a single registry operation, the .org is a public trust registry as described in our proposal to ICANN.

This is a registry. As stated in C20: Provisions for Equivalent Access by Accredited Registrars of our proposal, we do not and will not operate a registrar.

As of the 8/8/2002 submission date of this response our production registry contains 2,348,156 delegations, 5,112,317 nameserver records, and 50,159 glue (A) records and is based on serial number 2002080800 of the VeriSign zone file. Data that are not provided as part of our live mirror (e.g., registrar for an assigned object) are simulated as test data until VeriSign can start providing us full data feeds.

Our test registry, which is an identical hardware platform to our production registry, currently contains 5 million fully-populated objects. Extensive testing on this environment has been conducted up to the level of 8 million fully-populated objects.

Our current production and test systems are both HP AlphaServer ES40s, each with 16 GBytes of RAM and four EV6 processors. Our network infrastructure is based in two major telco hotels and IP exchange points. We have gigabit-speed public peering connections as well as diverse OC3 (155Mbit/sec) private transit arrangements. We peer with more than 80 networks, of which several are global carriers.

Our registry software, currently named OpenReg pending suggestions from our users on a better name, has several key components as detailed in C17.1: General Description of Proposed Facilities and Systems. The core database server handles bulk loading, registry-to-registry replication, generation of Whois and DNS files, and the RRP/EPP based transactions with registrars. Our Whois server is a separate software module. The DNS files generated by the core database server is used to feed a series of primary and secondary DNS servers, as detailed in C17.5 Zone File Distribution and Publication.

We are currently entering our beta test period on the RRP, Whois, and DNS components of our system:

• On 8/19/2002, we enter beta test with registrars. Beginning 9/2/2002, daily statistics on this test environment will be published for the public to examine using the metrics established in C17.13: System Reliability of the proposal. Beginning 10/1/2002, we will be supporting all ICANN-accredited registrars when our formal OT&E program opens.
• The Whois component of our system is currently operational with test data. As soon as VeriSign is able to provide real data, we are prepared to make this service available for general public testing. In addition, we will begin publishing test data measurements on 9/2/2002 for the public to examine.
• The DNS component of our system is currently operational with the VeriSign zone file in both BIND8 and BIND9. On 8/25/2002, we will begin deployment of the zone file and will open that environment up for public testing on 9/1/2002. The public will be able to compare resolution of .org names in our mirrored proxy and compare that to the live data in the real registry. A group of testers will run scripts in a globally distributed environment to compare metrics such as query resolution times for our .org proxy as well as live .org data in the VeriSign registry.

In addition continuing deployment of our operational systems for RRP, DNS, and Whois, we are also beginning deployment of our community support through a variety of mechanisms. The beginnings of a .org community can be found at http://not.invisible.net/signals/ where (as of 8/8/2002) 267 web sites have participated in our spread the dot and 443 individuals have voiced their support. Additional community efforts include the distributed testing environment we are releasing to the public on 9/1/2002 and an effort to support the ccTLD Secretariat in 2003 with nameserver training and OpenReg software.

Not applicable. See question Q1b.

Our registry uses RRP version 1.1 as the external interface to registrars as this is the version that VeriSign currently uses in production. Our core implementation includes all RRP 2.0 and EPP objects as specified in C17.12: Compliance With Specifications of our proposal. As specified, we are prepared to go live with RRP 2.0 and/or EPP support as part of our OT&E and registrar testbed if VeriSign puts those protocols into production. If they do not put those protocols in production, we propose to use the phased-in approach detailed in 3.18.1.5: RRP/EPP and Thin/Thick Transition of our proposal.

There are no differences. However, we are carefully tracking the deployment of EPP and RRP 2.0 and are comparing implementations and specifications with our own code. We note that not all implementations of EPP are currently interoperable. We intend to provide the community with EPP test suites and interoperability testing as a contribution to the IETF standardization process.

The IMS/ISC team is providing all of the functions of the registry. We do not outsource any of the core functions. This is an integrated team with a single point of accountability. Please see our Joint Statement of Authoirity and C11: Statement of Capabilities for more on the single point of accountability and Appendix E: Biographies of Key Personnel for the names of the people who are accountable for making this work.

For the deliverables detailed above in Supplemental Question No. 1, several of the team members listed in our proposal are taking a lead role. The OpenReg core server is under the program management of Suzanne Woolf, with key roles being played by Joe Abley, Michael Graff, and Rick Wesson. That team has been joined by Olafur Gudmundsson. Olafur, formerly of Neustar and Network Associates Laboratories, is a well-known DNS and DNSSEC expert who presently co-chairs the IETF DNS Extensions (DNSEXT) working group and has contributed to a number of DNS-related RFC's.

The DNS deployment and testing component is under the program management of Paul Vixie. Our newest team member, Mark K. Lottor, will be helping to oversee the public testing components. Mark, a veteran staffer of the SRI NIC, is best known as the author of the Internet Domain Survey and of RFC 1033: The Domain Administrators Operations Guide.

2. Supplemental Question No. 2

According to the Criteria for Assessing Proposals: "In view of the noncommercial character of many present and future .org registrants, affordability is important. A significant consideration will be the price at which the proposal commits to provide initial and renewal registrations and other registry services." Some applicants have proposed that, in addition to the price they propose to charge, they intend to collect taxes (such as value-added tax) with respect to services provided to registrars or ultimate consumers (e.g., registrants) in particular jurisdictions.

To clarify the proposals and allow them to be more readily compared, we are asking each applicant to provide details about the taxes (if any) they propose to collect. For each tax you propose to collect and add to the price you charge, please state:

We are proposing no taxes and the prices as listed in proposal section C26 is the final price to registrars. There are no hidden charges or surcharges and our only charge is for the basic service of maintaining a name object for a year. Additional services are all provided to our registrars, registrants, and the Internet community free of charge. We believe a simple pricing model is the best for the marketplace.

We are aware of and track carefully legal decisions related to the establishment of substantial nexus, both associational and direct, for state or international tax jurisdiction purposes, and are also aware of unrelated business income provisions for U.S. Federal and California exempt organizations. We consider those to be business risks and have taken them into account in the financial model underlying our consolidated financial statements before establishing our proposed maximum prices for services.

N/A.

N/A.

N/A.

N/A.

3. Supplemental Question No. 3

From: "Milton Mueller" <mueller@syr.edu>
To: <carl@media.org>
cc: <faia@amauta.rcp.net.pe>, <amsiat@bow.intnet.bj>, <hfeld@mediaaccess.org>,
<yjpark@myepark.com>, <vandrome@renater.fr>, <marc@schneiders.org>,
<ermanno@ula.ve>
Subject: Question from the evaluation committee
Date: Wed, 07 Aug 2002 21:36:42 -0400

Carl:
This is an "official," but hopefully not officious, question from the NCDNHC evaluation team with respect to "differentiation" and "unrestricted" policy goals:

The language we used in C38: Differentiation of the .org TLD was "we will also work with other .org registrants to encourage them to develop their domains to include broad communities of users or to become general-purpose public utilities." Your question strikes at the heart of one of the issues most important to our team: creating a coherent vision for the .org TLD.

We took as a basic assumption that there would not be and should not be any changes to the open and unrestricted registration policy. We agree such changes would, in the words of the NC Dot Org Task Force, "disenfranchise entire classes of communication online." (For that reason, we also view with skepticism efforts to provide "validation" or other certification schemes that attempt to create special status for certain classes of institutional users as a core part of the registry without giving the matter some real thought.)

The crux of your question has to do with how one differentiates .org. We've identified two levels at which this can happen:

1. By building the best public infrastructure we can for the operation of .org.
2. By building a true community around .org that does things that are useful to .org registrants.

Details on the public infrastructure can be found in the proposal and in Supplemental Question No. 1. Details on the large and active community that has already formed around the IMS/ISC .org effort can be found in our spread the dot campaign. As you can see, a large amount of discussion,debate, and discourse has sprung up in a short period of time.

Some of the differentiation of .org will come from activities that we have initiated to make the .org TLD more functional. For example, we've advanced some technical proposals on the deployment of secure DNS, investigation of a possible future transition of the registry from thin to thick, a new scripting language for transforming semi-structured information (such as some of the present namspaces in Whois and at the IANA), and a new service for providing management of allocation and distribution of such namspaces. As these initiatives (and others around the community) mature, and if a consensus materializes that they are useful, and if the initiatives can be provisioned in an open, reliable, and useful fashion, we want to try and carefully roll them into the operation of the registry service.

However, we view ourselves as part of the larger .org community, so when we look at ways to differentiate the TLD, we want to make sure to consider the activities of those around us as well as our own. Our fellow .organisms range across a vast variety of different kinds of users of the Internet. In many cases, with a bit of coordination and some support in the form of people, bandwidth, or machines, we can help make sure that useful services for the .org community get implemented and supported. "Deep domains" is thus a marketing term to encourage people to band together and use a single domain to provide a variety of related services that are useful to the .org community. This particular campaign is aimed at developers and service providers; needless to say, other messages will be used to market the .org TLD to broader communities.

We have three goals embedded in the "deep domains" campaign:

1. Encourage people to buy fewer domain names.
2. Encourage people to form true communities around domain names to solve common problems.
3. Encourage interoperability through the use of common meeting grounds for related services.

A simple example of a "deep domain" is the tpc.int service, which provides transmission of facsimile and pager messages over the Internet (tpc.int was an forerunner to services such as Enum). The service supports many different operators under a single domain and was used by operators and users all over the world. A less coordinated example of a deep domain is resource.org, which is a fairly loose collection of independent services all oriented around producing and maintaining large and important databases in XML. In the realm of the .org registry, a few areas that come to mind where we think this approach might be useful are the coordination of certification authorities, EPP interoperability testing, resources for nonprofits, and resources for open source developers.

The term "deep domains" is about bringing people together to solve problems. We are trying to leverage existing efforts on the Internet to provide new services for .org registrants. To us, deep domains are true community efforts that build something real. We think one of the most useful things we can do for .org, as we have done repeatedly in our past work, is to combine our own efforts with those of others to provide a level playing field for our community to work in.

Ultimately, differentiation of the .org domain will happen because the people providing the registry service are part of the .org community, understand that world, and have the energy and talent to provide useful contributions. We respectfully submit that IMS/ISC is the only bidding team that truly comes from and lives in that noncommercial world, with a proven track record of repeatedly creating, supporting in, and participating in such community efforts. We hope these personal commitments by team members, our collective commitment to open and transparent operation of all aspects of the registry, and our proven track record of working in this space will differentiate .org as a public service for the noncommercial world.

4. Preliminary Evaluation Report

The IMS/ISC team applauds ICANN and the three teams that participated in the process for generating a preliminary evaluation. The analysis was an impressive display of committee logistics and resulted in three different rating algorithms, which fed a staff meta-algorithm, which in turn produced a summary result. Unfortunately, your code didn't compile on our systems:

• There was no technical due diligence conducted as part of the evaluation. Past performance claims are not documented and no examination of code, logs, or configurations was conducted.
• The evaluation was all theory and no practice. Since the distance between theory and practice is so much smaller in theory than in practice, it is no surprise that the evaluations were able to boil complex problems down to simple metrics.

The IMS/ISC team also applauds ICANN for the open and methodical .org bid process. There have been several opportunities scripted for comment and open dialogue. Unfortunately, the next step in the process is based on a moderated bulletin board system at <http://forum.icann/org-eval> which does not allow allow on-line discussion and comment.

Rather than engage in a detailed point-by-point analysis and refutation of the evaluations and their methodologies, it seems appropriate to pull up to 50,000 feet and explain why there is a fundamental difference of opinion about how to do what we call in the trade "technical due diligence." We have thus posted an open letter at <http://not.invisible.net/signals/bin/000270.shtml> and invite your comments as well as those of our fellow .organisms.

5. Supplemental Question No. 11

ANSWER:

[A]

In 3.14.6[5] we specified at least 99.999% uptime per calendar year.

[B]

In 3.14.6[5] we specified a maximum processing time for a DNS query of 150ms, at least 95% of the time. An array of 13 quad-processor nameserver clusters serving a maximum of one query per CPU every 150ms would hence service queries at a minimum rate of (13 * 4 * 1/0.150) = 347 query/s.

[C]

The maximum query processing time specified in 3.14.6[5] corresponds to the theoretical case of near-total nameserver failure, where one single public, authoritative nameserver remains in service.

[D]

In 3.14.6[5] we specified 150ms for at least 95% of queries.

[E]

These figures are taken from the requirements described in section 2.1 of the document "Unsponsored TLD Agreement: Appendix D (.name)"[2], which we stated we would meet in 3.14.4[4].

[F]

In 3.14.6[5] we specified 5 minutes, at least 95% of the time.

[G]

In 3.14.6[5] we specified 99.9% per calendar year.

[H]

We understand this question to be a request for clarification of the timing of maintenance windows. In 3.12.3[3] we commit to establishing regular maintenance windows, in accordance with common industry practice, for routine, non-outage, minor changes to software, systems, or network configuration. The specific days and hours of these maintenance windows were considered to be a low-level detail not necessary for explicit inclusion in the proposal.

[I]

In 3.14.6[5] we specified 18 hours per calendar year, giving (18 / 4) = 4.5 hours per quarter.

[J]

In 3.14.6[5] we specified 99.5% per calendar year.

[K]

In 3.14.6[5] we specified 5 minutes, at least 95% of the time.

6. Certification of Answers

References

Authors' Addresses

Appendix A. Document Formats

This document is available in the following formats:

• [html] This document.
• [xml] XML
• [txt] ASCII
• [nroff] NROFF
• [word] Word
• [pdf] PDF