Supplemental Questions #3 - #6 to .org Applicants (With Responses)

Supplemental Questions #3 - #6 to .org Applicants (With Responses)

Supplemental Question No. 3:
(posed to Internet Multicasting Service, Inc. and Internet Software Consortium, Inc. on 9 August for response by 12 August 2002)

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?

Response to Supplemental Question No. 3:

Internet Multicasting Service, Inc. and Internet Software Consortium, Inc.

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.

---

Supplemental Question No. 4:
(posed to Union of International Associations on 4 September for response by 7 September 2002)

In your proposal (last paragraph of item C17.10) you state:

The UIA Team's existing constellation of DNS nameservers is capable of handling more than 500,000 DNS transactions per second, even though the normal load is less than 100,000 per minute.

[a] Please confirm that the stated "normal load" of "100,000 per minute" is what you intended to state. (Please note that, in its third-to-last paragraph, item C17.10 suggests that in January 2001 "DNS transactions on the global .com, .net and .org DNS constellation [were at] an average of 60,000 per second.")

[b] Is this stated "normal load" for the DNS constellation supporting (a) .com, .net, and .org or (b) just .org?

[c] Can you reference a publicly available report/reference that confirms your assertion of the normal load?

Response to Supplemental Question No. 4:

Union of International Associations

[a] VeriSign's "normal load" is less than "100,000 transactions per second", not "per minute".

This "normal load" value should have been stated as "per second", as were the maximum DNS capabilities earlier in the sentence and the actual average DNS transactions in C17.10.

[b] The stated "normal load" is for .com, .net, and .org.

[c]  We do not have readily available public access to this information. But in the VeriSign Second Quarter 2002 Earnings Report, it is stated that there are 7.5 billion look-ups per day and 7,500,000,000/day equals 86,805 per second. Also, attached is a snapshot from the VeriSign gtld Monitoring tool showing the actual load as of Thursday, September 5, 2002 at 11:22 EDT.

Supplemental Question No. 5:
(posed to Global Name Registry on 4 September for response by 7 September 2002)

In your Comments on Preliminary Staff Report on Evaluation of the Proposals you state:

In evaluating the capabilities of each of the top contenders, it is important to note that VeriSign receives more than 6 billion DNS queries per day, equal to roughly 70,000 queries per second (see http://www.verisign-grs.com/mdns/ha/haDatasheet.pdf, http://www.nwfusion.com/news/2002/0306verisign.html, and http://www-1.ibm.com/servers/eserver/pseries/news/pressreleases/2000/apr/network_solutions.html). This equates to approximately 7,000 queries per second for .org alone, and peak demand is likely to be 200-300% higher than this average query rate.

Please provide substantiation for your estimate that .org queries are equal to 10% of the 70,000 queries per second experienced by the .com, .net, and .org registries combined.

Response to Supplemental Question No. 5:

Global Name Registry

We made our estimates using the publicly available data contained in the sources listed above and using two different methods, as explained below.

VeriSign currently operates the top-level domains .com, .net and .org, and according to several publicly available sources, serves approximately 6 billion DNS queries per day on its DNS network. These 6 billion queries are spread across the three TLDs, and the number of queries per second to .org domain names can be estimated using various methods, two of which are described below.

First, we used a method which allowed us to extrapolate a number on the basis of the TLD zone sizes. Here, we assume that the query volume for .org is dependent on the size of the .org zone relative to the total .com, .net and .org zone size. This method does not take into account that the actual usage of .org domain names (email usage, web site usage, and usage of other services such as FTP) that may vary across the three TLDs. Using this assumption, the total number of queries (69,444 queries per second) can be broken down to 6,104 queries per second for .org, since .org currently constitutes 8.79% of the total zone size.

However, this result represents an average volume of queries and assumes that queries spread evenly throughout the day, while typical traffic patterns actually exhibit spikes of varying degrees. Network traffic is cyclical, often giving rise to peaks of 200-300% of average volume. This is extremely important to account for when designing a high-reliability system like DNS for a generic TLD. Peaks of this magnitude could require that the .org DNS network serve up to 15,000 queries per second in certain circumstances.

The table below summarizes the calculation of method 1:

Calculation on the basis of TLD zone sizes
Parameter	Value	Metric
Total daily volume reported on VeriSign network	6.0 billion	queries per day*
Equivalent average volume per second	69,444	queries per second
.org zone size as percentage of total .com, .net, .org zone size	8.79%	of total VeriSign zone**
Resulting pro-rata average query volume to .org	6,104	queries per second
Typical peak-volume demands	250%	of average volume
Likely peak query volume per second	15,260	queries per second
* source: http://www.verisign-grs.com/mdns/ha/haDatasheet.pdf ** source: http://www.gtldregistries.org/reports/2002/june/figure3.html

Second, realizing the limitations of the first method, we also estimated numbers on the basis of usage of the .org namespace since usage varies across the three TLDs. We arrived at this conclusion using Google, a large search engine that uses an algorithm to index pages. The algorithm primarily indexes pages that (a) contain text, (b) are linked to from other pages, or (c) are actively used. Google has indexed approximately 77 million pages for .com, 21 million for .net, and 24 million for .org.

Assuming that web page usage results in DNS queries, the 69,444 average queries per second to .com/.net/.org can be split pro-rata based on the number of web pages, resulting in an average of 13,502 queries per second for .org.

Using the same assumption on peak usage described above, this means that the DNS network must be able to resolve 33,000 queries per second in certain periods.

The table below summarizes the calculation of method 2:

Calculation on the basis of .org web population size and usage
Parameter	Value	Metric
Total daily volume reported on VeriSign network	6.0 billion	queries per day*
Equivalent average volume per second	69,444	queries per second
.org zone size as percentage of total .com, .net, .org zone size	8.79%	of total VeriSign zone**
Number of .com sites reported by Google	77,100,000	pages indexed**
Number of .net sites reported by Google	21,100,000	pages indexed**
Number of .org sites reported by Google	23,700,000	pages indexed**
.org web population size as percentage of total .com, .net, .org size	19.44%	of total .com/.net/.org web size
Resulting pro-rata average query volume to .org	13,502	queries per second
Typical peak-volume demands	250%	of average volume
Likely peak query volume per second	33,754	queries per second
* source: http://www.verisign-grs.com/mdns/ha/haDatasheet.pdf ** source: www.google.com

In our comment to the ICANN Preliminary Report, Global Name Registry weighted these two methods conservatively and extrapolated a DNS query capacity of 7,000 per second on average, or 14,000-21,000 in peak periods. A much higher number also could be derived, depending on the weight attributed to the different methods above.

Global Name Registry believed 7,000 queries per second to be a fair estimate for the purpose of demonstrating to ICANN that Global Name Registry has very seriously contemplated DNS query capacity and taken into account the needs of the new registry operator in operating .org, whereas other bidders' estimations, and therefore, registry specifications, have fallen short of DNS query needs.

Global Name Registry has allowed for ample room in our DNS network for variable peak loads and can serve more than 120,000 queries per second using our DNS network, operated internally and owned by Global Name Registry. In addition, as we have pointed out, our DNS network is both BIND run and IETF compliant.

Supplemental Question No. 6:
(posed to Global Name Registry on 4 September for response by 9 September 2002)

(a) In the Criterion 7 "Outsourcing" section of your Comments on Preliminary Staff Report on Evaluation of the Proposals you state:

In fact, the .name registry has been largely developed and deployed using software created by Global Name Registry and hardware designed by our Operations Team.

In connection with this statement:

(i) Please describe in full detail each and every aspect of the software employed in the SRS that currently serves the .name registry that was not "created by Global Name Registry".

(ii) Please describe in full detail each and every aspect of the software employed in the SRS that currently serves the .name registry that was supplied by or through VeriSign.

(iii) Please identify each item of hardware operating as part of the SRS that currently serves the .name registry and, for each such item, identify all designers of that item.

(b) Please state whether Global Name Registry operates the EPP front end for the system that currently serves the .name registry. If Global Name Registry does not, please identify the company that does operate that EPP front end. (For purposes of this subpart (b), the"EPP front end" refers to the registry facility that receives EPP commands on a real-time basis from registrars.)

(c) Please state the date on which the .name registry began receiving from registrars real-time EPP commands that query or modify entries in its production database.

(d) Please state the date on which VeriSign began providing outsourced services for the .name registry.

(e) In the Criterion 3 section of your Comments on Preliminary Staff Report on Evaluation of the Proposals you acknowledge that "Global Name Registry worked with VeriSign to provide certain SRS services for .name to provide for additional stability and redundancy during the start-up period". Please specify the beginning and end of the "start-up period" during which Global Name Registry has worked or intends to work with VeriSign to provide services for .name. Please also specify in detail the SRS services for .name regarding which Global Name Registry has worked or intends to work with VeriSign.

(f) Please state the location of the primary SRS data center currently used for the .name registry and identify what company is responsible for operating it.

(g) Please state the location of the authoritative SRS database currently used for the .name registry and identify what company is responsible for operating it.

(h) To allow ICANN to fully evaluate your application, please provide to ICANN a copy of the Registry Services Agreement that Global Name Registry has entered with VeriSign, Inc. in connection with the provision of services for the .name registry, as well as any amendments or supplemental agreements concerning registry operations.

Response to Supplemental Question No. 6:

Global Name Registry

Global Name Registry welcomes ICANN Staff looking even more closely at our technical capabilities. We believe that our responses to the questions below will clearly demonstrate the strength and depth of our technical abilities, and why we are the candidate most qualified overall to operate the .org registry.

Response to 6 (a)(i) Aside from the open-source software used (including Linux and several open-source tools described in Response C15 of our application and proprietary software developed by Global Name Registry, VeriSign is the only other entity to contribute software to the .name SRS. Further information on VeriSign's involvement is provided in Response 6(a)(ii) below.

Response to 6 (a)(ii) At the outset it should be noted that we do not intend to use any VeriSign software in the transition or operation of .org.

Current operation of the .name SRS is divided into two segments: (1) SRS governing registrar interactions, and (2) SRS governing fulfilment services, including DNS, Whois, and MX, as well as consistency validation, backup, reporting, billing and zone file access, among other components. VeriSign operates the former segment based on Global Name Registry specifications pursuant to an agreement of limited duration signed in 2001; Global Name Registry operates and controls the latter segment.

VeriSign has provided the following software for, and operates, the SRS segment governing registrar interactions, which:

• Allows for EPP connections by the registrars and serves EPP requests from registrars
• Modifies data for the registrars in the registrar-authoritative database
• Replicates the registrar-authoritative database to the Global Name Registry main site in London

For a .name registration or modification, the VeriSign system therefore governs the following interaction between the .name SRS and registrars:

• A registrar EPP client, based on the toolkit created and distributed by Global Name Registry, connects to the EPP gateway operated by VeriSign in Virginia.
• The EPP client performs a set of EPP operations towards the gateway (i.e., a .name registration). The registration is inserted into the SRS database, together with its associated information, contacts and nameservers.
• Instantly following this interaction, a business logic unit in Virginia initiates a connection to a similar business logic function in London. The new domain name and all associated data are packaged and transferred to the Global Name Registry database in London.

It is highly relevant – for purposes of evaluating Global Name Registry's technical capabilities – and much more significant – in terms of importance and as a percentage of the entire .name registry system – to describe the software components that we run and that we have designed ourselves. This description also provides a full picture of the cooperation between VeriSign and Global Name Registry, including our limited reliance on VeriSign in running the .name registry.

Following the interaction with the registrars, the software that Global Name Registry has written and designed, and which we currently operate independently, performs the following functions for .name SRS:

• Allows registrars to connect to the EPP gateway, through the EPP toolkit in C++ distributed by Global Name Registry to registrars
• Allows updates of DNS on all worldwide locations in near-real time
• Mirrors data with VeriSign registrar-authoritative database
• Modifies data in the authoritative database for DNS, Whois and MX
• Updates Whois on all locations in near-real time
• Updates MX on all locations in near-real time
• Validates consistency of, and scrubs, all DNS, Whois and MX data
• Allows high-volume Whois queries through Global Name Registry custom hierarchical object database specifically created for high performance Whois
• Powers the .name MX servers for all .name email services
• Powers the .name DNS through DNS software (using a BIND9 implementation customized with an MQ to DNS interface allowing for near-real time updates)
• Allows for protocol independent layers and SRS business logic (used for .name land rush and would be identical for Live SRS, but has been replaced by VeriSign equivalents to coordinate with the VeriSign systems in the current .name configuration)
• Provides for backup of all systems both on-site and off-site
• Provides for escrow of authoritative data for the .name zone
• Bills registrars and allows for receipt and integration of funds in the SRS
• Generates .name reports, including ICANN reporting for Appendices T and U
• Ensures failover of all resolution services to Disaster Recovery site
• Provides zone file access service
• Generates Namewatch reports and distributes reports to Namewatch users
• Creates and operates the QA environment
• Monitors network traffic and systems

Thus, following the registrar interaction enabled by VeriSign's systems, described above, the .name registry system continues as follows under the control of Global Name Registry:

• The business logic in London completes final validation and consistency checking of the .name registration.
• A Whois package is created in near-real time in London, which is instantly distributed to all Whois servers through MQ for assured communication. The Whois servers distill the package contents and make the new information available to the Internet.
• A MX package is created in near-real time in London, which is instantly distributed to all MX servers through MQ for assured communication. The MX servers distill the package contents and make the new information available to the Internet.
• A DNS package is created in near-real time in London, which is instantly distributed to the stealth, master DNS server through MQ for assured communication. The stealth master DNS server then distributes the new information to all worldwide locations.
• The new data is replicated into the SRS database in London.
• The SRS database in London is replicated onto three different servers (also in London): (1) main database, (2) reporting database, (3) scrubbing database. Each of these three databases contains a full, authoritative dataset for DNS, Whois, MX and reporting and data scrubbing functions.
• Backup systems in London back up the entire data set for both on-site and off-site storage.
• Global Name Registry systems also continuously fulfill all .name email services, currently serving approximately 150,000 emails per week to .name addresses.

Clearly, notwithstanding VeriSign's contributions to the .name SRS, Global Name Registry continues to operate a majority of the system. This, coupled with proven and existing technology internally developed by our development team and independently operated during the seven-month land rush period for .name, provides an extremely solid foundation on which to operate the .org registry.

First, it is important to recall that Global Name Registry has designed and from December 2001 through the end of June 2002, operated an entire registry system, including the protocol layer, the registration/modification business logic and the database back-end, independent of any other operator, including VeriSign. This experience serves as a solid foundation for the world class Live SRS design as described in Response C15, C17 and C22 of the .org application. Also, we continue to operate the .name fulfillment services, including DNS, Whois and MX services and their near-real time updates, using our in-house Operations team and proprietary software designs. Working with the VeriSign team has also provided us with unique experience that can be applied to the .org transition.

Second, the in-house Global Name Registry system is designed to be a Live SRS system. To enable the system to function independently as a real-time SRS requires replacing the batch front-end with the EPP front-end using the Global Name Registry proprietary design that has been developed, used and proven during the batch process. This replacement works because the front-end code that Global Name Registry developed internally for .name SRS was designed to be independent of whether the registry operates on a live basis or not, and therefore works in both a batch and live system. The code, therefore, with slight modifications, is capable of powering .name in live SRS as well as powering .org.

Indeed, modifiying the front-end protocol comprises only a small percentage of the registry system that would comprise makes up the proposed .org registry relative to the development and operation process that we undertook in connection with launch of the .name registry. In addition, this is a small percentage relative to the development that other applicants would have to undertake to transition and operate an entire registry system. Modifications to the registry system will be required of any successor .org registry operator, including ISOC/Afilias and NeuStar, specifically to the front-end that must support the legacy RRP. No other gTLD registry, other than VeriSign, operates such a system today.

Third, Global Name Registry has designed and documented an EPP and RRP protocol specific layer in Responses C17.1, C17.2 and C22 of our application. Gartner reviewed the design and documentation of our protocol handling and gave Global Name Registry the highest marks in this category of any candidate. This confirms Global Name Registry's demonstrated experience with protocol handling both for EPP and RRP, as well as the important protocol migration from RRP to EPP.

Finally, Global Name Registry's software inventory demonstrates our technical capabilities with respect to all aspects of running a registry. If it would assist ICANN, we are willing to release certain proprietary information about the code that our developers have written for the .name registry. This code would be applicable to the .org registry and would be another concrete illustration of our level of sophistication in development, as well as in operation of a registry system.

In sum, the effort required by Global Name Registry to add an RRP/EPP gateway to its registry system is a task that can be incorporated safely into the existing design and capabilities of the Global Name Registry technical systems.

Response to 6 (a)(iii) The following description illustrates the hardware network independently run by Global Name Registry.

VeriSign, which is also applying to operate the .org registry as part of the UIA application, has declined to waive the confidentiality provisions of the registry services agreement we signed in 2001, which prohibits us from describing the hardware it contributes. Since we do not intend to use any VeriSign hardware or software in the operation of .org, it is probably more helpful in any case to describe (1) the existing architecture of the .name registry that is operated solely by Global Name Registry, and (2) the incremental hardware that will be added to enable the network to also handle .org with ease. The current network consists of:

Current Installation by Global Name Registry for .name
Location	Number of servers	Designed, operated and owned by
London - operations	58	Global Name Registry (see diagram for more details)
Hong Kong - operations	16	Global Name Registry (see diagram for more details)
Norway - operations	47	Global Name Registry (see diagram for more details)
London - QA environment	40	Global Name Registry
London - development environment	13	Global Name Registry
SUM	174

The following diagrams illustrate the structure of the network and how the hardware interacts:
(Note that some are large files >100kb and may be better viewed by downloading in separate image viewer)

• Global site structure
• Network Latency design (.org design)
• Main site design (London)
• Disaster recovery site design (Norway)
• Hong Kong site design

To complete the hardware network that would be capable of operating .org (and/or .name) completely independently, Global Name Registry would add the following:

Installation required for Global Name Registry to fully operate .org
Location	Number of servers	Designed, operated and owned by
London - operations	9	Global Name Registry
Hong Kong - operations	0	Global Name Registry
Norway - operations	2	Global Name Registry
London - QA environment	0	Global Name Registry
London - development environment	0	Global Name Registry
SUM	11

As evidenced by the two tables above, the addition of hardware to our current system to operate .org is minimal. Indeed, on a hardware network basis, to make our system complete for .name or .org we would require an expansion of the system by approximately 6% (11/(174+11) = 5.9%). Thus, the incremental additions to the network and hardware do not pose a significant challenge to us in modifying our systems to incorporate the .org registry.

The diagrams linked to above describe in more detail how the hardware is configured on each of the sites. Given the existing infrastructure of Global Name Registry, the solutions already developed for operation of a complete registry, and the incremental changes needed to establish a live registry entirely operated by Global Name Registry, we are confident that we can ensure a smooth transition later this year and the continuing stability of the .org registry. Notably, our cooperation with the VeriSign team has given us unique and valuable experience to facilitate a seamless .org transition.

Response to 6 (b) With respect to the .name registry, Global Name Registry produced the toolkit that (1) specifies how registrars connect to the EPP front-end, and (2) allows registrars to connect to the EPP front-end. VeriSign, pursuant to the agreement of limited duration described above, operates the EPP front-end.

With respect to our ability to operate the EPP front-end ourselves, we note that prior to assuming operation of the .name registry, our systems were theoretically 100% unproven. Since then, our virtually flawless operation of the .name registry has proven that we can build a system of the highest quality and reliability. It is only a small portion of our proposed solution for .org that must still be proven. This element of uncertainty - while extremely small - puts us in no different position than any of other top contenders, which also will be required to add technical and operational solutions to their hardware systems.

Response to 6 (c) The .name registry began receiving real-time EPP commands from registrars on 26 June 2002.

Response to 6 (d) VeriSign began providing outsourced services for the .name registry on 26 June 2002.

Response to 6 (e) The start-up period began at the end of June 2002 and will conclude on the date specified in the limited term agreement provided to ICANN in response to Question 6(h).

The SRS services for .name that Global Name Registry "has worked or intends to work with VeriSign" have been fully and completely described above in Response 6(a)(ii). As we have clearly stated before: VeriSign will not play any role whatsoever in the operation of .org.

Response to 6 (f) Operation of the primary SRS data centre for .name is divided between VeriSign and Global Name Registry. As described above, VeriSign operates the portion of the SRS governing registrar interaction, while Global Name Registry operates the portion of the SRS governing fulfilment services, such as DNS, Whois, MX, and backup.

Response to 6 (g) The .name registry consists of two co-authoritative databases, which are continuously replicated to ensure consistency of the .name systems.

The location of the database that is authoritative for DNS, Whois and MX for .name is operated by Global Name Registry in London, England, with a Disaster Recovery site in Norway. (VeriSign is unable to update any of these services.) The location of the database that is authoritative for registrar interactions and operated by VeriSign is in Virginia, USA.

Response to 6 (h) We have sent by international courier a hard copy of the Registry Services Agreement, dated September 28, 2001, between VeriSign and Global Name Registry, together with two amendments thereto and a request for confidential treatment. VeriSign, which is also applying to continue to operate the .org registry as part of the UIA application, has declined to waive the confidentiality provisions of the agreement we signed, other than allowing us to provide the agreement to ICANN with a request for confidential treatment.

Conclusion

ICANN should not be concerned about Global Name Registry's limited cooperation with VeriSign on aspects of the .name registry because:

• The .name registry is likely the most complex domain name registry currently in operation. This is due to the fact that the registry offers domain names on the third level, which means that we must operate DNS on both the second and third levels. We also offer email as a registry service, defensive registrations, dual registrations and consent, all of which add layers of complexity that no other registry encompasses.
• We alone have designed, developed and operated most of the SRS solutions internally, ranging from the EPP toolkit, protocol independent business logic and near-real time updates on DNS, Whois and MX.
• We have significant experience in developing technical solutions and operating the systems derived therefrom, including high volume, live transaction systems, large databases, database migrations, protocol interfaces and protocol transitions.
• Our previous experience in operating a technology system with strikingly similar characteristics to a live registry is significant: Nameplanet.com hosted more than 1.5 million users only 18 months after launch.
• Gartner's detailed analysis of all eleven applicants ranked Global Name Registry as one of the top contenders after concluding that we understand the demands of operating a live registry and have the significant technical knowledge and experience required.

Global Name Registry is the best - and most reliable - organization to succeed in the operation of .org. We believe this because of our sound operation of the .name registry, our strong financial position, our established corporate and employee infrastructure and our firm commitment to serving the needs of the .org and broader Internet communities. Unlike ISOC/Afilias, and other applicants, we have no intention whatsoever of outsourcing any portion of the .org registry.

Page updated 13-Sep-2002
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.