Appendix 7 to Sponsored TLD Registry Agreement
Functional and Performance Specifications
Pursuant to the responsibility delegated to it in Appendix S, Registry will prescribe functional requirements for Registry Services provided by the Registry Operator for the Sponsored TLD. Those functional requirements shall ensure that at least the following minimum functional capabilities are provided.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.
The nameservers for the Sponsored TLD MUST be operated in compliance with the following Requests for Comments (RFCs): 1034, 1035, 1101, 2181, 2182. In clarification of the statement of host-name rules in these RFCs, all Registered Names SHALL comply with the following syntax in augmented Backus-Naur Form (BNF) as described in RFC 2234:
= %x2E ; "."
There MUST be nameservers for the Sponsored TLD on at least five different network segments. So that the IANA has zone-file access, zone-file transfers MUST be enabled at all nameservers for transfers to at least 126.96.36.199/16 and 188.8.131.52/20.
The registry system MUST enforce the name reservations and Charter requirements set forth in Appendix S.
The Registry MUST maintain no less than two geographically diverse SRS and whois data centers with the requisite back-up power to operate such data centers in the event of a power failure for the Sponsored TLD.
Whois service MUST meet at least the functional specifications set forth in Appendix 5.
Data escrow MUST meet at least the functional specifications set forth in Appendix 1. The registry shall be capable of storing the data to be escrowed.
The registry system MUST provide data sufficient to meet the reporting requirements set forth in Appendix 4.
DNS Service Availability. Service availability as it applies to the DNS Service refers to the ability of the Nameservers, as a group, to resolve a DNS query from an Internet user. The committed Performance Specification is 99.999% measured in Monthly Timeframes.
Performance Level. At any time at which it is available, each Nameserver (including a cluster of Nameservers addressed at a shared IP address) MUST be able to handle a load of queries for DNS data that is three times the measured daily peak (averaged over the Monthly Timeframe) of such requests on the most loaded Nameserver.
Cross-Network Nameserver Performance Requirements. The committed Performance Specification for cross-network Nameserver performance is a measured Round-trip time of under 300 ms and measured packet loss of under 10%. Cross-network Nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner:
The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the Nameservers and observing the responses from the Nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and Europe).
Each string of request packets will consist of 100 UDP packets at 10-second intervals requesting ns records for arbitrarily selected second-level domains in the Sponsored TLD, preselected to ensure that the names exist in the Sponsored TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received will be noted.
To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of day, as well as on different days of the week). The cross-network Nameserver performance requirement will be deemed to have not been met only if the Nameservers persistently fail the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.
If, following Registry's opportunity to cure, the Nameservers continue to persistently fail CNNP Tests and Registry fails to resolve the problem within thirty days after written notice of the continuing failures, Registry will be in breach of its obligations under the Registry Agreement.
Sixty days before the commencement of testing under this provision, ICANN will provide Registry with the opportunity to evaluate the testing tools and procedures to be used by ICANN. In the event that Registry does not approve of such tools and procedures, ICANN will work directly with Registry to make necessary modifications.
Whois Service Availability. The committed Performance Specification for Whois Service is 99.4% measured in Monthly Timeframes.
8. Failover. The Registry shall practice fail over between data centers not less frequently than once every two years
The domain names included within the scope of the Allocation Program shall be limited to one and two-character dot-TRAVEL domain names. Registry Operator reserves the right to not allocate all single and two-character dot-TRAVEL domain names.
Pursuant to the Allocation Program, Registry Operator may elect to allocate the domain names by applying one or more the following processes: 1) request for proposals and allocation based on evaluation criteria, 2) auction, or 3) first come, first served registration.