2. CORE has been chartered on the basis of a series of principles specifically related to TLDs:

CORE's position is that nobody can make a valid claim to a "right" in a TLD, be it on the basis of patent, trademark or other legislation. CORE has demonstrated that it is prepared to successfully defend this view in court. By the same token, CORE does not claim any rights to be held by CORE in .nom, for which it currently applies with ICANN, nor in any other TLD CORE has endeavoured to be entrusted with.

3. If ICANN entrusts CORE with the adminstration of the .nom TLD, CORE will indemnify ICANN against claims of third parties based on alleged trademark, patent or other violations of purported rights in the .nom TLD. As CORE has been able to demonstrate when litigation was brought against it by a party claiming to own .web, CORE has access to adequate financial resources and legal competencies to defeat such a claim in court. (See http://www.icann.org/tlds/correspondence/iod-v-core-22jun00.htm .)

CORE feels that it would inappropriate to constitute and announce ex ante a legal "war chest" financial reserve because this could lead to miscalulations by potential claimants. CORE's mechanism of cost-recovery funding from the membership has demonstrated its viability over the three years of its existence.

4. Expected availability specification:

The systems are deemed available as long as the expected response time specification (see response to third question in this set, further below) is met.

CORE expects its systems SRS back-end to be available on a 24x7 basis at a rate of at least 99 percent except for previously announced maintenance. Under normal circumstances, planned maintenance should not exceed 8 hours for a given instance and normally account for less than 1 hour per week. Planned maintenance is announced by electronic mail at least two weekdays prior to its start.

As CORE's whois servers will be updated within 30 seconds after the back-end database, the whois servers are available for check queries. CORE expects to have at least two separate whois servers in operation on a 24x7 basis, each of which is expected to be fully available at a rate of at least 95 percent except for previously announced maintenance. Moreover, based on recent experience, complex whois queries (requesting potentially long lists of domains or contacts) will be throttled or handled on separate machines in order to ensure uninterrupted availability for standard whois requests.

5. CORE is largely able to commit to the expected availability specification stated above largely within the budgets shown in most economical variant of its financial projections for .nom (see http://www.icann.org/tlds/nom1/CORE-NOM-D-RO-Projections-Expected.htm ). Note: As a member-funded organisation, CORE makes its decisions by consensus. This principle applies to service level specifications and the associated budget implications in the same fashion as it does to architectural options.

6. Expected response time specification:

Based on the experience with its existing installation, CORE expects to achieve at least the following response-time features for the future registry SRS within the budget shown in the financial projections. (These figures are currently being met by CORE the existing SRS handling over 900,000 domains and having to deal with the additional complexity of mirroring data with the VGRS/NSI registry through the RRP protocol.)

For SRS back end update and inquire requests, the CORE expects the average round-trip response time to remain at less than to 1 second for 95 percent of the requests measured over one calendar month. (Note: in the current CORE SRS, this includes an additional round trip between CORE and the VGRS registry through a single serialised link. As this would not be the case in the .nom registry, the response time would at least be cut in half. The system can accept multiple requests at the same time and relies on queuing mechanisms at various stages within the SRS. The response time is therefore strongly influenced by the read frequency of the SRS. The setting of these parameters is a matter of policy and not of performance. As CORE is an association of registrars, the setting of system parameters is decided by consensus amongst registrars using the system.

As far as check transactions are concerned, CORE currently updates its whois server within 30 seconds after the master database. The registry SRS is expected to have several whois servers updated in the same fashion. As a result, the SRS itself is not saddled with domain check requests and several whois servers are available for these transactions. For each machine, the response time should be below 1 second for 95 per cent of single-domain whois queries.

As discussed under D15.2.3. in the .nom Registry Operator's Proposal, (see http://www.icann.org/tlds/nom1/CORE-NOM-D-RO-Proposal-100.htm#_Toc494908619 ), the CORE SRS performance measurements are not appropriate for comparison with RRP performance measurements because of the fundamental differences in architecture.

As described above, the CORE SRS is based on internal queues which are currently read once per second. This implies a parameter-controlled floor of the response time of currently .5 seconds. This parameter can of course be changed, although this has not been requested up to now. The read process picks up multiple requests, so that several transactions can be executed in the same one-second interval.

In case a transaction cannot be completed, it is queued until it can be executed. The "worst" transaction time is not artificially limited by way of a time-out parameter. However, experience with CORE's current hardware set-up shows times as remaining consistently below 1 second, including the additional serialised round trip between CORE and VGRS, a detour not needed when the SRS acts as a registry.

7. Given the conservative nature of the expected response time specification stated above, CORE is able to commit to that specification largely within the budgets shown in most economical variant of its financial projections for .nom (see http://www.icann.org/tlds/nom1/CORE-NOM-D-RO-Projections-Expected.htm ).

Note: As a member-funded organisation, CORE makes its decisions by consensus among members. This principle applies to service level specifications and the associated budget implications in the same fashion as it does to architectural options.

CORE expects to develop a more distinctive service level specification by member consensus. This may have budget or architectural implications, or it may call for incentives for members to avoid unnecessary performance- threatening practices.