Supplemental Questions 

Table of Contents

Supplemental Question No. 1
Supplemental Question No. 2
Supplemental Question No. 3
Preliminary Evaluation Report
Supplemental Question No. 11
Certification of Answers
Authors' Addresses
Document Formats   DOC  


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:

Q1a. Identify 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.

Q1b. State whether it is a registry, a registrar, or both.

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.

Q1c1. If it is a registry, state the number of domain names and registrars supported by the registry.

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:

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 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.

Q1c2. If it is a registrar, state the number of domain names supported by the registrar, and state what registries it interacts with.

Not applicable. See question Q1b.

Q1d. State which of the following protocols the registry or registrar operation uses for registry-registrar communications: EPP and RRP. If both protocols are used, please provide details regarding which communications employ each protocol.

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 RRP/EPP and Thin/Thick Transition of our proposal.

Q1e. Identify all differences between the protocols identified in your response to item (d) above (i.e. as implemented in the registry or registrar operation concerning which you are responding) and the protocol you propose to use for the .org registry.

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.

Q1f. Name which of the applicant and members of the proposing team is/are responsible for the operation of the registry or registrar, and describe the role(s) under which it is/they are responsible.

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:

Q2a. The nature of the tax (e.g., value-added tax);

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.

Q2b. The rate or amount of the tax (e.g., 15.0% of the registry price) that you propose to add to the price;


Q2c. The services to which the tax collection will apply (e.g., initial and renewal registrations);


Q2d. If you will collect the tax on charges to only registrars in one or more jurisdictions, please specify the jurisdiction(s).


Q2e. If you will collect the tax on charges to only ultimate customers (such as registrants) in one or more jurisdictions, please specify the jurisdiction(s).



3. Supplemental Question No. 3

From: "Milton Mueller" <>
To: <>
cc: <>, <>, <>,
<>, <>, <>,
Subject: Question from the evaluation committee
Date: Wed, 07 Aug 2002 21:36:42 -0400

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

Q3. Can you explain better how would you "encourage the use of deep domains" and "encourage .org registrants to operate as public utilities" while adhering to the policy of open and unrestricted registration within .org?

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 service, which provides transmission of facsimile and pager messages over the Internet ( 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, 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

PE1. As previously announced, comments on the preliminary evaluation report posted on 19 August 2002 should be submitted by e-mail to <> no later than Friday, 29 August 2002. Comments received at this address will be sorted and posted at <>. They will be considered in finalizing the .org evaluation report. The final .org evaluation report is scheduled to be posted on Thursday, 5 September 2002. It will then be open for comment until late September, at which time the ICANN Board is expected to select one of the applicants to become the successor operator of .org, subject to entry of a satisfactory registry agreement.

Although commentary on the data, methodology, and conclusions in the preliminary evaluation report is invited, applicants should not use the comment period to amend their proposals through their comments. The deadline for proposals was 18 June 2002, and changes to proposals after that deadline would be unfair to the other applicants. Clarifications of misinterpretations that may appear in the evaluation reports are appropriate, but applicants are urged to carefully support those clarifications by citations to the proposals as originally submitted.

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:

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 <> and invite your comments as well as those of our fellow .organisms.


5. Supplemental Question No. 11

Q11. Item C28 of the proposal form requested details regarding each applicant's proposed technical performance and quality-of-service commitments:

C28. Describe the technical performance (including quality-of-service commitments) you propose to make. See <> for an example. The successor operator will be expected to meet the Cross-Network Nameserver Performance Requirements set forth in section 2.1 of the document at the above URL.

In the various applicants' proposals, however, the proposed commitments are scattered among various sections, stated in terms of different units, and based on different measurement methods. For consistency sake, we are asking each applicant to fill in the table below with key data on the service commitments it proposes.


Service Attribute                 Committment         Location in

DNS service availability from     99.99%              3.14.4
each nameserver, minimum

DNS service availability from     99.999%             3.14.6 [A]
any nameserver (i.e. at least
one nameserver available),

DNS query response rate for       347 query/s         3.14.6 [B]
all nameservers combined,
minimum absolute

DNS query response rate for       100%                3.14.6 [C]
each nameserver, minimum

DNS query response time,          150ms               3.14.6 [D]
maximum, locally measured

Cross-network nameserver          300ms               3.14.4 [E]
round-trip time, maximum

Cross-network nameserver          10%                 3.14.4 [E]
packet loss, maximum

DNS update interval, maximum      5 minutes           3.14.6 [F]

SRS service availability,         99.9%               3.14.6 [G]

SRS processing time, maximum      95% < 1500ms        3.14.6
for query operations

SRS processing time, maximum      95% < 3000ms        3.14.6
for write operations

SRS service planned outage        8 hours per         3.14.6
duration, maximum                 month

SRS service planned outage        not specified       [H]

SRS service planned outage        3 days              3.14.6
notification, minimum

SRS service extended planned      4.5 hours per       3.14.6 [I]
outage duration, maximum          quarter

SRS service extended planned      not specified       [H]
outage timeframe

Whois service availability,       99.5%               3.14.6 [J]

Whois query processing time,      95% < 1500ms        3.14.6

Whois update interval, maximum    5 minutes           3.14.6 [K]

Whois service planned outage      8 hours per         3.14.6
duration, maximum                 month

Whois service planned outage      not specified       [H]

Whois service planned outage      3 days              3.14.6
notification, minimum

In 3.14.6[5] we specified at least 99.999% uptime per calendar year.
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.
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.
In 3.14.6[5] we specified 150ms for at least 95% of queries.
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].
In 3.14.6[5] we specified 5 minutes, at least 95% of the time.
In 3.14.6[5] we specified 99.9% per calendar year.
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.
In 3.14.6[5] we specified 18 hours per calendar year, giving (18 / 4) = 4.5 hours per quarter.
In 3.14.6[5] we specified 99.5% per calendar year.
In 3.14.6[5] we specified 5 minutes, at least 95% of the time.


6. Certification of Answers

        /Carl Malamud/

        Carl Malamud
        Internet Multicasting Service
        August  8, 2002 
        August 11, 2002 
        August 29, 2002 
        September 12, 2002 



[1] ICANN, "Supplemental Question #11 to .org Applicants", September 2002.
[2] ICANN, "Cross-Network Performance Requirements", June 2001.
[3] IMS/ISC, "3.12.3 Maintenance", June 2002.
[4] IMS/ISC, "3.14.4 Nameserver Availability and Performance Measurements", June 2002.
[5] IMS/ISC, "3.14.6 Performance Specifications Summary", June 2002.
[6] IMS/ISC, "IMS/ISC .org Proposal", June 2002.


Authors' Addresses

  Internet Multicasting Service
  P.O. Box 217
  Stewarts Point, CA 95450
Phone:  +1.707.847.3720
Fax:  +1.415.680.1556
  Internet Software Consortium
  950 Charter Street
  Redwood City, CA 94063
Phone:  +1.650.779.7000
Fax:  +1.650.779.7055


Appendix A. Document Formats

This document is available in the following formats: