Supplemental Question #11 to .org Applicants

Supplemental Question #11 to .org Applicants

Supplemental Question No. 11:
(posed to all applicants on 9 September for response by 12 September 2002)

Criterion 7 states in part: "The specific registry services proposed should allow uninterrupted provision of all services presently provided to .org registrants. In addition, plans and provisions for additional registry services that will benefit .org registrants will be considered. Consideration will be given to proposed quality-of-service commitments. Any proposal should match or improve on the performance levels of the current .org registry."

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 <http://www.icann.org/tlds/agreements/name/registry-agmt-appd-29jun01.htm> 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.

In responding to this supplemental question, please adhere to these guidelines:

1. Each applicant should respond to this supplemental question by filling in the "commitment" and "location and proposal" columns in the table below.

2. All data given in your supplemental response must have been included in your .org proposal submitted on or before 18 June 2002 (or be subject to being derived from that proposal in conjunction with well-known incorporated references such as RFCs).

3. The "commitment" column should be filled in to give the service commitment, if any, set forth in your proposal, stated in a manner consistent with the entries in the "service attribute" and "unit of measure" columns. Please note that a satisfactory service-commitment definition may be stated even though your proposal did not specify all service attributes in the table below.

4. The "location in proposal" column should be filled in with one or more citations to the portion(s) of your proposal where the service commitment was stated. If the commitment you insert in the "commitment" column cannot readily be derived from the cited portion(s) of your proposal, your commitment may be disregarded in connection with evaluation of your proposal.

5. No more than 500 words of textual explanation (if needed) may be included with the table that is submitted.

Thank you for your cooperation.

Responses to Supplemental Question No. 11:

The DotOrg Foundation
The Global Name Registry, Limited
Internet Multicasting Service, Inc. and Internet Software Consortium, Inc.
The Internet Society (ISOC)
NeuStar, Inc.
The .Org Foundation
Organic Names Ltd.
Register ORGanization, Inc.
SWITCH Swiss Academic and Research Network
Union of International Associations
Unity Registry

The DotOrg Foundation

The DotOrg Foundation (DOF) is pleased to note that its application provides for the highest SLAs of any .org proposal. Our registry services provider, Registry Advantage, has validated these SLAs by extensively testing its systems using the current .org registry information. We are confident of our ability to deliver on these metrics based on these tests. In some cases, our commitments are more rigorous than anticipated by ICANN’s question, as described in notes 3-5 below.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.95%	C28
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	100%	C28 (see note #3)
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	140,000 (See Note #1)	C10, Test Results Attachment
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	360% (See Note #2)	C10, Test Results Attachment
DNS query response time, maximum, locally measured	milliseconds	300	C28
Cross-network nameserver round-trip time, maximum	milliseconds	300	C28, referencing established ICANN CNNP guidelines
Cross-network nameserver packet loss, maximum	percentage	10%	C28, referencing established ICANN CNNP guidelines
DNS update interval, maximum	minutes	5	C28
SRS service availability, minimum	percentage uptime	99.95%	C28
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 400	C28
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 800	C28
SRS service planned outage duration, maximum	hours/month	8 (1.67 when yearly maximum is considered; see note #3)	C28
SRS service planned outage timeframe	days and hours	To be determined in consultation with ICANN. See Note #5.
SRS service planned outage notification, minimum	days	3	C28
SRS service extended planned outage duration, maximum	hours/quarter	12 (3 when yearly maximum is considered; see note #4)	C28
SRS service extended planned outage timeframe	days and hours	To be determined in consultation with ICANN.
Whois service availability, minimum	percentage uptime	99.95%	C28
Whois query processing time, maximum	a% < b milliseconds	95% < 800	C28
Whois update interval, maximum	minutes	15	C28
Whois service planned outage duration, maximum	hours/month	8 (1.67 when yearly maximum is considered; see note #3)	C28
Whois service planned outage timeframe	days and hours	To be determined in consultation with ICANN. See Note #5.
Whois service planned outage notification, minimum	days	3	C28

Notes to DotOrg Foundation Response:

1. Because our SLA commitments make no exceptions for high load situations, we are fully committed to providing DNS service under the peak load conditions that may exist for .org at the service levels outlined in our applications. No specific commitments were set out in our application as to query rate, but we view such an attempt at quantification as actually limiting the scope of the SLA.

However, as part of the testing regimen that Registry Advantage performed in preparation for the .org application, we have demonstrated the proven capacity to serve over 18,000 queries per second from a single nameserver. Extrapolating this across the eight total DNS POPs yields a combined global capacity of over 140,000 queries per second. Additionally, DOF proposes deploying multiple servers per POP, yielding even higher total query rates.

2. As part of the testing regiment that Registry Advantage performed, we have demonstrated the proven capacity to serve over 18,000 versus an anticipated peak requirement on the most loaded nameserver of only 5,000 queries per second. (See the attachment on Test Results for the derivation of the anticipated peak requirement.)

3. As described in C28, DOF will commit that at least half of all nameserver clusters will be available 100% of the time; this significantly exceeds the requirement that only a single nameserver be available.

4. In theory, a two-hour scheduled maintenance window could be used once per week. However, as described in C28, DOF would be limited to a total of ten scheduled maintenance windows per year. Averaging the yearly maximum across the twelve month period yields an average monthly limit of 1.67 hours of scheduled downtime.

5. In theory, the two six-hour extended maintenance window could be used in the same quarter. However, DOF would be limited to a total of two such windows per year, resulting in a quarterly average of 3 hours of extended outage time.

6. No specific dates or times for maintenance windows were laid out within the application. DOF expects to determine specific windows in conjunction with ICANN. As an example, Registry Advantage's current maintenance windows are laid out below (times in US Eastern Standard Time):

• For critical infrastructure maintenance or updates, where possible impact to more than once system or service may be involved, 4AM-8AM Sundays is a reserved maintenance window.
• For non-critical infrastructure maintenance or updates, 8PM-12Midnight Wednesday is a reserved maintenance window.
• For critical application maintenance or updates, 6AM-8AM Monday and Thursday are reserved maintenance windows.
• For non-critical application maintenance or updates, 11AM-2PM Monday and Thursday are reserved maintenance windows.

The Global Name Registry, Limited

We provide the information on the service levels commitments contained in our original application in response to Supplemental Question 11. However, having reviewed such commitments against our actual performance in running the .name registry over the last nine months, we have determined that we can offer enhanced service commitments, as described below.

As required by each question, we provide each commitment and its respective location in the application; moreover, to the extent we can offer enhanced capabilities on any service component, we list such capabilities and label them "REVISED" under the Commitment column. Through our operation of the .name registry, we have proven that we can attain such service levels, and we are confident that we can continue to do so. We believe that by offering .org registrants and the Internet community this greater level of commitments, we will continue to improve and create new standards for the Internet.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.9%	not available in the application
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.999% (.org application) REVISED: 99.9999% (actual .name number which GNR can commit to at present)	Printed document reference: "Section C19-C37", (Section C28), page 30 Quote: "99.999% per month across the nameserver constellation"
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	187,200	RFP reference: C17.10, figure 29 and subsequent table Printed document reference: "Section C17.2-16", page 115
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	The answer to this depends on the definition of "most loaded server", and "hourly peak", which are not clearly defined in the RFP Each Global Name Registry nameserver performs a response rate of 8,000 queries/second. As calculated in Global Name Registry's response to ICANN Supplemental Question #5, the current request volume for .org volume is about 7000 queries per second, with peaks at approximately 20,000 queries per second. Assuming such peaks are "hourly peaks", the Global Name Registry DNS capacity is approximately 187/20=935% of the hourly peak. Since Global Name Registry loadbalances all of its nameservers, the query response rate for each nameserver should never exceed 20/187=10.6% of the measured hourly peak.	Number not directly available, but can be calculated from numbers at: Printed document reference: "Section C17.2-16", page 115
DNS query response time, maximum, locally measured	milliseconds	95% < 0.400ms (400 microseconds) locally measured Maximum: 300ms ¹	not available in application
Cross-network nameserver round-trip time, maximum	milliseconds	300ms	Printed document reference: "Section C19-C37", (Section C28), page 30
Cross-network nameserver packet loss, maximum	percentage	10% REVISED: 1%	Printed document reference: "Section C19-C37", (Section C28), page 30
DNS update interval, maximum	minutes	15 minutes ²	Printed document reference: "Section C19-C37", page 43 Quotes: "zone files and WHOIS records being up to date within 15 minutes of registration or modification" (Section C19-C37, page 43) "For the purpose of the zone file residing on the Master DNS, this is more a matter of latency than of frequency [...]The update latency under normal operating conditions would in most cases be measured in seconds" (Section C17.2-16, Page 40)
SRS service availability, minimum	percentage uptime	99.4% REVISED: 99.8%	Printed document reference: "Section C19-C37", (Section C28), page 30 (Section C28)
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 3000ms	Printed document reference: "Section C19-C37", (Section C28), page 30 Other relevant quote: "[the query capacity] can be scaled horizontally as described further below in this section to serve hundreds or even thousands of requests per second. This greatly relieves the main database from the load experienced during Add Storms" ("Section C17.2-16", page 110) See also: "Section C17.2-16", page 34 ("Database design parameters")
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 3000ms	Printed document reference: "Section C19-C37", (Section C28), page 30 Other relevant quote: "[the query capacity] can be scaled horizontally as described further below in this section to serve hundreds or even thousands of requests per second. This greatly relieves the main database from the load experienced during Add Storms"("Section C17.2-16", page 110)
SRS service planned outage duration, maximum	hours/month	8	Printed document reference: "Section C19-C37", (Section C28), page 30
SRS service planned outage timeframe	days and hours	0600-1500 GMT Sunday	Printed document reference: "Section C19-C37", (Section C28), page 30
SRS service planned outage notification, minimum	days	7 days	Printed document reference: "Section C19-C37", (Section C28), page 30
SRS service extended planned outage duration, maximum	hours/quarter	48 hours per quarter	Printed document reference: "Section C19-C37", (Section C28), page 30
SRS service extended planned outage timeframe	days and hours	0600-1500 GMT Saturday or Sunday	Printed document reference: "Section C19-C37", (Section C28), page 30
Whois service availability, minimum	percentage uptime	99.4% REVISED: 99.99%	Printed document reference: "Section C19-C37", (Section C28), page 30
Whois query processing time, maximum	a% < b milliseconds	95% < 1500ms ¹	Printed document reference: "Section C19-C37", (Section C28), page 30 Other relevant quote: "Whois Service will, on average, be able to handle 200 queries per second" ("Section C19-C37", Page 28)
Whois update interval, maximum	minutes	95% < 1 minute maximum 15 minutes	Printed document reference: "Section C17.2-16", page 32 Quote: "will usually be updated within seconds of changes to the main database, and at most within 15 minutes" ("Section C17.2-16", page 32)
Whois service planned outage duration, maximum	hours/month	8	Printed document reference: "Section C19-C37", (Section C28), page 30
Whois service planned outage timeframe	days and hours	0600-1500 GMT Sunday	Printed document reference: "Section C19-C37", (Section C28), page 30
Whois service planned outage notification, minimum	days	7 days	Printed document reference: "Section C19-C37", (Section C28), page 30

Notes to GNR Response: ¹ In evaluating this information, it is important to note that there is a distinct difference between maximum processing time for a single query, which reflects only one query, and the average processing time per query. Latency in the system, including firewalls, network interfaces, TCP/IP packeting, memory access and operating system context switching will always result in a difference between single query time and average query time. Network interfaces and context switching are inherently batch processes and can parallel process many queries in one "latency timeunit". The Global Name Registry system is designed to scale to more than 50 million domain names, and can achieve the stated single query times even under hard load and when processing thousands of transactions per second.

² The question has been evaluated as the time until the DNS update will resolve on each Global Name Registry DNS location, worldwide, as opposed to only on a (set of) master servers, where the timespan is measured in seconds, like for Whois.

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

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.99%	3.14.4
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.999%	3.14.6 [A]
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	96,000 query/s	3.14.6 [B]
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	100%	3.14.6 [C]
DNS query response time, maximum, locally measured	milliseconds	150ms	3.14.6 [D]
Cross-network nameserver round-trip time, maximum	milliseconds	300ms	3.14.4 [E]
Cross-network nameserver packet loss, maximum	percentage	10%	3.14.4 [E]
DNS update interval, maximum	minutes	5 minutes	3.14.6 [F]
SRS service availability, minimum	percentage uptime	99.9%	3.14.6 [G]
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 1500ms	3.14.6
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 3000ms	3.14.6
SRS service planned outage duration, maximum	hours/month	8 hours per month	3.14.6
SRS service planned outage timeframe	days and hours	not specified	[H]
SRS service planned outage notification, minimum	days	3 days	3.14.6
SRS service extended planned outage duration, maximum	hours/quarter	4.5 hours per quarter	3.14.6 [I]
SRS service extended planned outage timeframe	days and hours	not specified	[H]
Whois service availability, minimum	percentage uptime	99.5%	3.14.6 [J]
Whois query processing time, maximum	a% < b milliseconds	95% < 1500ms	3.14.6
Whois update interval, maximum	minutes	5 minutes	3.14.6 [K]
Whois service planned outage duration, maximum	hours/month	8 hours per month	3.14.6
Whois service planned outage timeframe	days and hours	not specified	[H]
Whois service planned outage notification, minimum	days	3 days	3.14.6

Notes to IMS/ISC Response:

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

[B] Based on benchmarks and operational experience with similar hardware and software, three server clusters of 2-4 systems each as specified in the proposal.

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

The Internet Society (ISOC)

In response to question #11, provided below are the service commitments requested:

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.73%	C28.3 – Fig. 54 & 55
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.999%	C17.13.1
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	Min. 10,000 (Maximum 300,000/sec)1,3	C17.5.3.a
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	Not Included in our June 18 proposal	N/A
DNS query response time, maximum, locally measured	milliseconds	Not Included in our June 18 proposal	N/A
Cross-network nameserver round-trip time, maximum	milliseconds	300	Appendix N, Sec 2
Cross-network nameserver packet loss, maximum	percentage	<10%	Appendix N, Sec 2
DNS update interval, maximum	minutes	15	C27.c.1.a
SRS service availability, minimum	percentage uptime	99.45%	C28.3 – Fig. 54 & 55
SRS processing time, maximum for query operations	a% < b milliseconds	a) No % included in our June 18 proposal; b) 400ms	C28.3 – Fig 54 & 55
SRS processing time, maximum for write operations	a% < b milliseconds	a) No % included in our June 18 proposal; b) 800ms	C28.3 – Fig. 54 & 55
SRS service planned outage2 duration, maximum	hours/month	8 hrs/month (includes WHOIS)	C28.2.10
SRS service planned outage2 timeframe	days and hours	01:00 to 09:00 UTC on Sunday	Appendix D, Exhibit G 1.9
SRS service planned outage2 notification, minimum	days	7 days	Appendix D 5.12
SRS service extended planned outage duration, maximum	hours/quarter	0 hrs3	C28.2.10
SRS service extended planned outage timeframe	days and hours	01:00 to 09:00 UTC on Sunday	Appendix D, Exhibit G 1.9
Whois service availability, minimum	percentage uptime	99.45%	C28.3 - Fig. 54 & 55
Whois query processing time, maximum	a% < b milliseconds	a) No % included in our June 18 proposal; b) 800 ms4	C28.3 – Fig. 54 & 55
Whois update interval, maximum	minutes	"near real-time"	C17.8
Whois service planned outage2 duration, maximum	hours/month	8 hrs/month (includes SRS)	C28.2.10
Whois service planned outage2 timeframe	days and hours	01:00 to 09:00 UTC on Sunday	Appendix D, Exhibit G 1.9
Whois service planned outage2 notification, minimum	days	7 days	Appendix D 5.12

Notes to ISOC Response: 1. The ISOC proposal cited a minimum capacity of 10,000 queries per second. The UltraDNS managed DNS service is capable of performing at rated SLA levels up to 300,000 queries per second.

2. The total maximum Planned Outage Time of 8 hrs/month includes both WHOIS and SRS outage times.

3. Planned Outage Time can be used as Extended Planned Outage Time; the total planned outage time per period is the sum of Planned Outage and Extended Planned Outage.

4. The .INFO WHOIS system, upon which the .ORG WHOIS system is intended to be modeled, currently performs at under 200 ms response time on average.

NeuStar, Inc.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	The availability of each nameserver is a component of overall DNS service availability (see below).	Section C28, table 1, line 1 (pg. V-9)
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.999% per calendar year.	Section C28, table 1, line 1 (pg. V-9)
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	Configured for 1,200 queries/sec per nameserver * 8 nameservers = 9,600 queries/sec. Sized to handle 5,000 queries/sec per nameserver * 8 nameservers = 40,000 queries/sec.	Section C17.10 (pg. III-64) Section 17.1.1 (pg. III-4)
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	Configured for 1,200 queries/sec per nameserver. Sized to handle 5,000 queries/sec per nameserver.	Section C17.1.3.2 (pg. III-16).
DNS query response time, maximum, locally measured	milliseconds	95% < 1,500 ms	Section C28, table 1, line 5 (pg. V-9)
Cross-network nameserver round-trip time, maximum	milliseconds	300 ms	Section C28, table 1, line 13 (pg. V-10)
Cross-network nameserver packet loss, maximum	percentage	10%	Section C28, table 1, line 13 (pg. V-10)
DNS update interval, maximum	minutes	95% < 15 min	Section C28, table 1, line 6 (pg. V-9)
SRS service availability, minimum	percentage uptime	99.9% per calendar month	Section C28, table 1, line 1 (pg. V-9)
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 1500 ms	Section C28, table 1, line 3 (pg. V-9)
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 3000 ms	Section C28, table 1, line 2 (pg. V-9)
SRS service planned outage duration, maximum	hours/month	8 hours/ calendar month	Section C28, table 1, line 7 (pg. V-9)
SRS service planned outage timeframe	days and hours	Sun: 0600-1400 UTC	Section C28, table 1, line 8 (pg. V-9)
SRS service planned outage notification, minimum	days	3 days	Section C28, table 1, line 9 (pg. V-10)
SRS service extended planned outage duration, maximum	hours/quarter	18 hours per calendar quarter	Section C28, table 1, line 10 (pg. V-10)
SRS service extended planned outage timeframe	days and hours	Sat or Sun: 0600-1400 UTC	Section C28, table 1, line 11 (pg. V-10)
Whois service availability, minimum	percentage uptime	99.95% per calendar month	Section C28, table 1, line 1 (pg. V-9)
Whois query processing time, maximum	a% < b milliseconds	95% < 1500 ms	Section C28, table 1, line 4 (pg. V-9)
Whois update interval, maximum	minutes	95% < 15 minutes	Section C28, table 1, line 6 (pg. V-9)
Whois service planned outage duration, maximum	hours/month	8 hours per calendar month	Section C28, table 1, line 7 (pg. V-9)
Whois service planned outage timeframe	days and hours	Sun: 0600-1400 UTC	Section C28, table 1, line 8 (pg. V-9)
Whois service planned outage notification, minimum	days	3 days	Section C28, table 1, line 9 (pg. V-10)

The .Org Foundation

In Section C28 we committed to the performance specifications listed within ICANN’s Unsponsored TLD Agreement: Appendix D (.name) found at the following ICANN website: http://www.icann.org/tlds/agreements/name/registry-agmt-appd-29jun01.htm. Additional (more restrictive and higher) performance commitments are stated in the rest of Section C28 and elsewhere in our proposal.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.999%	C28 See note 1 below
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	100%	C28, C17.13
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	32,233/sec	C28 See note 2 below
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	300%	C28
DNS query response time, maximum, locally measured	milliseconds	5	C15.2, C17.12 See note 3 below
Cross-network nameserver round-trip time, maximum	milliseconds	300	C28
Cross-network nameserver packet loss, maximum	percentage	10%	C28
DNS update interval, maximum	minutes	0.16	C28
SRS service availability, minimum	percentage uptime	99.5%	C17.13, C28
SRS processing time, maximum for query operations	a% < b milliseconds	100%<3000 milliseconds	C28
SRS processing time, maximum for write operations	a% < b milliseconds	100%<3000 milliseconds	C28
SRS service planned outage duration, maximum	hours/month	4	C17.13 See note 4 below
SRS service planned outage timeframe	days and hours	0600-1500 GMT Sunday	C28
SRS service planned outage notification, minimum	days	7	C28
SRS service extended planned outage duration, maximum	hours/quarter	36	C28
SRS service extended planned outage timeframe	days and hours	0600-1500 GMT Saturday or Sunday	C28
Whois service availability, minimum	percentage uptime	99.4%	C28
Whois query processing time, maximum	a% < b milliseconds	100%<1500	C28
Whois update interval, maximum	minutes	0.16	C28
Whois service planned outage duration, maximum	hours/month	4	C17.13 See note 4 below
Whois service planned outage timeframe	days and hours	0600-1800 GMT Saturday or Sunday	C28
Whois service planned outage notification, minimum	days	7	C28

Notes to .Org Foundation Response:

Note 1: We proposed at least 5 physical DNS servers behind each of 7 virtual IPs. We interpreted the specification we cited in section C28 “across name servers” to mean for each name-server IP address, therefore we committed to 99.999% uptime (or approx 30 seconds of downtime per month) for each nameserver IP. This in essence represents the uptime for the particular data center where the DNS server shared IP and associated name servers are located (for example, rackspace.com, offer 99.999% uptime SLAs). We commit to having at least one of the 5 physical servers behind that IP up 100% of the time.

Note 2: The number of DNS queries performed on the current .org name server constellation was not disclosed in the confidential information given to us. Therefore, in section C28, we estimated that the current .org name server constellation is sized to handle 390 million requests per day per name server on each of 10 name servers (see C28 4.1.2 Performance Level). We proposed 7 name server virtual IPs, and therefore committed (in compliance with RFC2870) to a capacity of 557 million queries per day for each shared name server IP. Since we committed to 99.999% uptime for each shared name server IP, it is extremely unlikely that more than one name server shared IP will be completely down at the same time. If this unlikely event happens and two are completely down at the same time, the remaining 5 IPs (25 physical servers) will support 2.785 billion queries per day, therefore the minimum committed amount is 32,233 per second. Each DNS server (not shared IP, but physical box) has been measured to perform approximately 1200 queries per second (max sustained capacity) consistently, so if any 10 out of the proposed minimum 35 physical servers are down or unreachable, the minimum commitment will still be met. The maximum, or the capacity when all name servers (all 35 proposed servers) are functioning and reachable, is 3.9 billion queries per day or 45,138 per second.

Note 3: In our proposal we commit to being compliant with all RFCs and BCPs. RFC2870 replaces RFC2010, which specifies a 5 milliseconds response time. RFC 2870 does not specify a DNS response time.

Note 4: SRS and Whois service planned outage duration combined will not exceed 4 hours per month. A maximum of 4 hours per month will be scheduled for downtime, which can be used for whois or SRS, or both (if both are scheduled for downtime during the same period). This 4-hour downtime commitment for whois and SRS includes the scheduled downtime required for the switchover from the prior registry operator to The .Org Foundation as registry operator (see proposal section C18.4).

Organic Names Ltd.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.9999%	p66
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.9999%	p66
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	65,000	Derived - See note 1 below
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	1300%	Derived - See note 1 below
DNS query response time, maximum, locally measured	milliseconds	500ms	p65
Cross-network nameserver round-trip time, maximum	milliseconds	500ms	p65
Cross-network nameserver packet loss, maximum	percentage	0.1%	p65
DNS update interval, maximum	minutes	180	p52
SRS service availability, minimum	percentage uptime	99.5%	p66
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 2000ms	p65
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 2000ms	p65
SRS service planned outage duration, maximum	hours/month	12hrs	p66
SRS service planned outage timeframe	days and hours	0400-1200 GMT Sundays	p66
SRS service planned outage notification, minimum	days	7	p66
SRS service extended planned outage duration, maximum	hours/quarter	36hrs/qtr	p66
SRS service extended planned outage timeframe	days and hours	0400-1500 GMT Sundays	p66
Whois service availability, minimum	percentage uptime	99.5%	p66
Whois query processing time, maximum	a% < b milliseconds	95% < 1500ms	p66
Whois update interval, maximum	minutes	5 minutes	p57
Whois service planned outage duration, maximum	hours/month	8hrs/month	p66
Whois service planned outage timeframe	days and hours	0400-1200 GMT Sunday	p66
Whois service planned outage notification, minimum	days	7 days	p66

Note to Organic Names Response:

Note 1: We are assuming that under normal conditions .org generates approximately an average of 2,500 queries per second, peaking at twice this, i.e. 5,000 queries per second. We have committed that any single server from our constellation can handle the load of the entire constellation, thus the maximum capacity we have committed to across a fully operative constellation of servers is 13 x 5,000 or 65,000 queries per second, and the each name-server has capacity of at least 13 times the peak hourly load (1300%).

Register ORGanization, Inc.

Below please find RegisterOrg's response to supplemental question 11. RegisterOrg is pleased to note that its application for the redelegation of the .org registry provides the highest SLAs of any .org proposal. Our registry services provider, Registry Advantage, has validated these SLAs by extensively testing its systems using the current .org registry information. We are confident in our ability to deliver on these metrics based on these tests. Indeed, in some cases, our SLA commitments are more rigorous than anticipated by the question posed by ICANN, as described in notes 3-5.

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.95%	C28
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	100%	C28 (see note #3)
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	140,000 (See Note #1)	C10, Test Results Attachment
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	360% (See Note #2)	C10, Test Results Attachment
DNS query response time, maximum, locally measured	milliseconds	300	C28
Cross-network nameserver round-trip time, maximum	milliseconds	300	C28, referencing established ICANN CNNP guidelines
Cross-network nameserver packet loss, maximum	percentage	10%	C28, referencing established ICANN CNNP guidelines
DNS update interval, maximum	minutes	5	C28
SRS service availability, minimum	percentage uptime	99.95%	C28
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 400	C28
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 800	C28
SRS service planned outage duration, maximum	hours/month	8 (1.67 when yearly maximum is considered; see note #3)	C28
SRS service planned outage timeframe	days and hours	To be determined in consultation with ICANN. See Note #5.
SRS service planned outage notification, minimum	days	3	C28
SRS service extended planned outage duration, maximum	hours/quarter	12 (3 when yearly maximum is considered; see note #4)	C28
SRS service extended planned outage timeframe	days and hours	To be determined in consultation with ICANN.
Whois service availability, minimum	percentage uptime	99.95%	C28
Whois query processing time, maximum	a% < b milliseconds	95% < 800	C28
Whois update interval, maximum	minutes	15	C28
Whois service planned outage duration, maximum	hours/month	8 (1.67 when yearly maximum is considered; see note #3)	C28
Whois service planned outage timeframe	days and hours	To be determined in consultation with ICANN. See Note #5.
Whois service planned outage notification, minimum	days	3	C28

Notes to RegisterORGanization Response:

1. Because our SLA commitments make no exceptions for high load situations, we are fully committed to providing DNS service under the peak load conditions that may exist for .org at the service levels outlined in our applications. No specific commitments were set out in our application as to query rate, but we view such an attempt at quantification as actually limiting the scope of the SLA.

However, as part of the testing regimen performed by Registry Advantage as part of our application, we have demonstrated the proven capacity to serve over 18,000 queries per second from a single nameserver. Extrapolating this across the eight total DNS POPs yields a combined global capacity of over 140,000 queries per second. Additionally, RegisterOrg proposes deploying multiple servers per POP, yielding even higher total query rates.

2. As part of the testing regiment that Registry Advantage performed, we have demonstrated the capacity to serve over 18,000 versus an anticipated peak requirement on the most loaded nameserver of only 5,000 queries per second. (See the Test Results attachment for the derivation of the anticipated peak requirement.)

3. As described in C28, RegisterOrg will commit that at least half of all nameserver clusters will be available 100% of the time; this significantly exceeds the requirement that only a single nameserver be available.

4. In theory, a two-hour scheduled maintenance window could be used once per week. However, as described in C28, RegisterOrg would be limited to a total of ten scheduled maintenance windows per year. Averaging the yearly maximum across the twelve month period yields an average monthly limit of 1.67 hours of scheduled downtime.

5. In theory, the two six-hour extended maintenance window could be used in the same quarter. However, RegisterOrg would be limited to a total of two such windows per year, resulting in a quarterly average of 3 hours of extended outage time.

6. Specific dates and times for maintenance windows were not stated in our application. RegisterOrg expects to establish specific windows in conjunction with ICANN. As an example, Registry Advantage’s current maintenance windows are provided (times noted are Eastern Standard Time):

• For critical infrastructure maintenance or updates, where possible impact to more than one system or service may be involved, 4AM-8AM Sundays is a reserved maintenance window.
• For non-critical infrastructure maintenance or updates, 8PM-12 AM Wednesday is a reserved maintenance window.
• For critical application maintenance or updates, 6AM-8AM Monday and Thursday are reserved maintenance windows.
• For non-critical application maintenance or updates, 11AM-2PM Monday and Thursday are reserved.
  

SWITCH Swiss Academic and Research Network

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99	Appendix C, Section 3
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	100	App. C, Section 3 and App. CA, Section 15, "GNS Feature Summary"
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	see reference [1]
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	see reference [1]
DNS query response time, maximum, locally measured	milliseconds	derived from service attribute no. 3	Comment: We interpret this service attribute to be understood as the time between reception of a query on a local interface and submission of a response, which is essentially given by the inverse of the maximum sustained query rate stated in [1].
Cross-network nameserver round-trip time, maximum	milliseconds	300, see reference [2]
Cross-network nameserver packet loss, maximum	percentage	10, see reference [2]
DNS update interval, maximum	minutes	120	App. C, Section 3 and App. CA, Section 6, "Updating the DotOrg Zone" Comment: This number is not a technical limitation (which is actually well below that, see App. C, Section 3, item 4), it is a design choice that takes into account the caching mechanism inherent in DNS (very low TTL values of NS records should be avoided).
SRS service availability, minimum	percentage uptime	99.4, see reference [3]	App. B, Section 7b
SRS processing time, maximum for query operations	a% < b milliseconds	Processing time = 100…200 ms (estimated) Maximum queuing delay (peak load) = (burstqueue + 1) * processing time <3000 ms	App. B, Section 8b App. B, Section 8b
SRS processing time, maximum for write operations	a% < b milliseconds	Processing time = 100…200 ms (estimated) Maximum queuing delay (peak load) = (burstqueue + 1) * processing time <5000 ms	App. B, Section 8b App. B, Section 8b
SRS service planned outage duration, maximum	hours/month	0	see reference [3]
SRS service planned outage timeframe	days and hours	0	see reference [3]
SRS service planned outage notification, minimum	days	0	see reference [3]
SRS service extended planned outage duration, maximum	hours/quarter	0	see reference [3]
SRS service extended planned outage timeframe	days and hours	0	see reference [3]
Whois service availability, minimum	percentage uptime	99.9
Whois query processing time, maximum	a% < b milliseconds	Processing time = 400 ms (estimated) Maximum processing time (substring search) <6000 ms	App. B, Section 6a App. B, Section 6a
Whois update interval, maximum	minutes	<1	immediate synchronization of WHOIS data base
Whois service planned outage duration, maximum	hours/month	0	see reference [3]
Whois service planned outage timeframe	days and hours	0	see reference [3]
Whois service planned outage notification, minimum	days	0	see reference [3]

References for SWITCH Response:

[1] Instead of service attributes 3 and 4 above, we provide maximum sustained query rates for each server as stated below:

Commitment	values between 1’500 and 30’000 queries/second
Location in Proposal	App. C, Section 11
Comment	The meaning of service attribute no. 4 is unclear to us. We make the commitment that all name servers will be able to handle at least three times the estimated average load which is 430 queries/sec (see App. CA, Section 7, “System Capacity"). Note that figures derived from real-world conditions have not yet been disclosed to us by VeriSign. Unfortunately, the figures in fields 17, 18, 19 in our tables in App. C, Section 11, are inconsistently assigned. The only relevant number, however, is the maximal sustained query rate, which is always the largest number in any of the three fields in all tables in App. C, Section 11.

[2] Comment:
We commit ourselves to the performance parameters as stated in http://www.icann.org/tlds/agreements/name/registry-agmt-appd-29jun01.htm. While these parameters are well defined and verifiable, we believe that they are not a meaningful measure for the quality of service as perceived by an "average user" in the Internet. Please refer to App. CA, Section 9, "Global Infrastructure and Connectivity" of our proposed DNS solution for statements with regard to this issue.

[3] Comment to planned outage times:
There are no planned outages for SRS and WHOIS services due to the redundant design of our data centers. During an update of one system the secondary system takes over all services. SRS availability = 99.4%. The probability of failure is comprised of the square of the sum of the probabilities of failure of components (data base, RRP/EPP server, gateway) plus the probability of failure induced by human interaction (see App. B, Section 7b).

Union of International Associations

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	–	–
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	99.999%	Appendix C Pg. 9 Sec. 7.3
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	5,000,000/sec.	Pg. 80 Sec. C17.10
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	300%	Appendix C Pg. 5 Sec. 4.1.2
DNS query response time, maximum, locally measured	milliseconds	300 ms	Appendix C Pg. 6 Sec. 4.1.3
Cross-network nameserver round-trip time, maximum	milliseconds	300 ms	Appendix C Exhibit A Pg. 10 Sec. 2.1
Cross-network nameserver packet loss, maximum	percentage	10%	Appendix C Exhibit A Pg. 10 Sec. 2.1
DNS update interval, maximum	minutes	3 min.	Pg. 66 Sec. C17.8
SRS service availability, minimum	percentage uptime	99.4%	Appendix C Pg. 9 Sec. 7.3
SRS processing time, maximum for query operations	a% < b milliseconds	95% < 3000 ms	Appendix C Pg. 9 Sec. 7.3
SRS processing time, maximum for write operations	a% < b milliseconds	95% < 3000 ms	Appendix C Pg. 9 Sec. 7.3
SRS service planned outage duration, maximum	hours/month	8 hrs./mo.	Appendix C Pg. 9 Sec. 7.3
SRS service planned outage timeframe	days and hours	0000-0400 GMT Sunday	Appendix C Pg. 9 Sec. 7.3
SRS service planned outage notification, minimum	days	7 days	Appendix C Pg. 9 Sec. 7.3
SRS service extended planned outage duration, maximum	hours/quarter	12 hrs.	Appendix C Pg. 9 Sec. 7.3
SRS service extended planned outage timeframe	days and hours	0000-1200 GMT Sat. or Sun.	Appendix C Pg. 9 Sec. 7.3
Whois service availability, minimum	percentage uptime	99.4%	Appendix C Pg. 9 Sec. 7.3
Whois query processing time, maximum	a% < b milliseconds	95% < 1500 ms	Appendix C Pg. 9 Sec. 7.3
Whois update interval, maximum	minutes	3 min.	Pg. 66 Sec. C17.8
Whois service planned outage duration, maximum	hours/month	8 hrs./mo.	Appendix C Pg. 9 Sec. 7.3
Whois service planned outage timeframe	days and hours	0000-0400 GMT Sunday	Appendix C Pg. 9 Sec. 7.3
Whois service planned outage notification, minimum	days	7 days	Appendix C Pg. 9 Sec. 7.3

Unity Registry

Service Attribute	Unit of Measure	Commitment	Location in Proposal
DNS service availability from each nameserver, minimum	percentage uptime	99.999%	Section C28
DNS service availability from any nameserver (i.e. at least one nameserver available), minimum	percentage uptime	100%	Section 17.5
DNS query response rate for all nameservers combined, minimum absolute	queries/sec	30,000 queries / sec (per server)	Section 17.5
DNS query response rate for each nameserver, minimum	% of measured hourly peak on most loaded server	300%	Section C28
DNS query response time, maximum, locally measured	milliseconds	1.5s	Section C28
Cross-network nameserver round-trip time, maximum	milliseconds	300ms	Section C28
Cross-network nameserver packet loss, maximum	percentage	10%	Section C28
DNS update interval, maximum	minutes	15mins (Though updates will be preformed "instantly" in real time using dynamic updates as per RFC-2136, 15 min max propagation to secondary servers)	Section C28, C17.4, C17.5
SRS service availability, minimum	percentage uptime	99.90%	Section C28
SRS processing time, maximum for query operations	a% < b milliseconds	97% < 4000ms	Section C28
SRS processing time, maximum for write operations	a% < b milliseconds	97% < 4000ms	Section C28
SRS service planned outage duration, maximum	hours/month	8hours / month	Section C28
SRS service planned outage timeframe	days and hours	0600-1400 Sunday UTC	Section C28
SRS service planned outage notification, minimum	days	7days	Section C28
SRS service extended planned outage duration, maximum	hours/quarter	18 hours / quarter	Section C28
SRS service extended planned outage timeframe	days and hours	0600-1400 Sunday UTC	Section C28
Whois service availability, minimum	percentage uptime	99.95%	Section C28
Whois query processing time, maximum	a% < b milliseconds	97% < 1.5s	Section C28
Whois update interval, maximum	minutes	15mins	Section C28
Whois service planned outage duration, maximum	hours/month	8hours / month	Section C28
Whois service planned outage timeframe	days and hours	0600-1400 Sunday UTC	Section C28
Whois service planned outage notification, minimum	days	7days	Section C28

Notes to Unity Registry Response:

• The above mentioned SLA’s do not make up the complete set of SLA's guaranteed by Unity Registry, see extra table below for remaining SLA’s. We would also call attention to the statement:
  
  "Unity Registry expects to enter into detailed discussion with ICANN about the technical performance commitments and as part of the process of drawing up the Registry Agreement" which is contained within section C28 of our tender.
  
  
• It is also worth noting that Unity Registry systems have been designed to perform as fast as possible without reducing stability and security, note the following statement:
  
  "The EPP Daemon design focused on performance and robustness, utilizing advanced features offered in the Linux Kernel. The software has been rigorously tested by both AusRegistry and an independent third party, Afilias, the current administrators of the .info registry and, on their own admission, has proved to exceptionally better and out perform other EPP registries."
  
  
• We would just like draw your attention to the fact that Unity Registry in some cases has specified higher response times then some applicants, these response times are specified as: "@ performance level" (at committed transaction performance level). These times are not indicative of the true high performance capabilities of the registry system, when severs are experiencing standard load levels, transaction times will significantly reduce. The current .au registry operated by AusRegistry provides exceptional performance on white box Intel hardware (performance figures available upon request) Unity is expecting similar industry leading performance from our .org registry design based on Sun/Intel hardware.

Additional SLA's

>

Service Attribute	Unit of Measure	Commitment	Location in Proposal
SRS Performance Level (RRP)	tx/s	400tx/s	Section C28
SRS Performance Level (EPP)	tx/s	200tx/s	Section C28
WhoIs Performance Level (WhoIs)	tx/s	400tx/s	Section C28
Admin Web Interface availability	percentage uptime	99.90%	Section C28
Admin Web Interface Response time	a% < b milliseconds	97% < 4000ms	Section C28
Admin Web Interface Planned Outages	hours/month	8hours / month	Section C28
Admin Web Interface Planned Outages timeframe	days and hours	0600-1400 Sunday UTC	Section C28
Admin Web Interface Extended Planned Outages	hours/quarter	18hours / quarter	Section C28
Admin Web Interface Extended Planned Outages Timeframe	days and hours	0600-1400 Sunday UTC	Section C28
Notification ALL planned outages	days	7days	Section C28
Notification ALL Extended planned outages	days	21days	Section C28

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