V. PROPOSED REGISTRY SERVICES

C25. Describe each Registry Service (as defined in subsection 1.16 of the model .org Registry Agreement) that you propose to provide for a fee.

For an example of a description of this type, see http://www.icann.org/tlds/agreements/name/registry-agmt-appc-1-03jul01.htm.

Domain name registration service. The policies for name registration and renewal (extending a registration) in the .org TLD will remain exactly the same. Some of which are:

• Names are registered on a first-come-first-served (FCFS) basis.
• Equal access for all ICANN registrars, and only ICANN registrars.
• No eligibility requirements to register a name.
• The initial registration term may be from one to ten years, in one-year increments.
• Domain name registrations may be renewed prior to their expiration for a period of years up to ten years (in one-year increments), provided that the expiration date of a domain-name registration can never be more than ten years in the future. A renewal that would set the expiration date further than ten years in the future will lead to the expiration date being set to ten years in the future. Any remaining time will be forfeited.
• All domain-name registrations must be made pursuant to the requirements of the Approved Registrar's RRA with the Registry Operator. Among other things, the RRA requires that the registrar and registrant have a registration agreement.
• The Approved Registrar will collect registration information from the registrant and do quality checking of the data to ensure the validity of the domain-name registration. The registrar must submit through the Shared Registration System complete, accurate, and valid registration data, and must update that data when changes occur.

During the registry contract period, the service interface will change from RRP to EPP but this basic service offering will remain the same.

Re-registering deleted names using daily mini-sunrise service

Because most names registered in other EPP registries will not expire for some time, the .org registry will likely be the first registry using EPP to have a large number of names deleted.

This service functions much like the .us sunrise did, but occurs each day. When a delete command is issued by a registrar, the name is not made immideately available, it will be placed on a new "sundown" status, and as before, the registar is no longer the registrar-of-record for the domain.

A list of to-be-deleted names is defined as names that have changed to a status of "sundown" during a day. This list will be maintained and published on the registry's ftp site a week in advance of when they actually will be deleted (and are after an Redemption Grace Period or other ICANN imposed delay between when it is requested to be deleted by the registrar and when it can be made available for reregistration). All the names on the list will be deleted simultaneously at the start of the sunrise period, and be immediately available for re-registration. At the start of the period, registrars are able to request a registration for a name on the list. Requests for any to-be-deleted name outside the period will be given a "sundown" response by the EPP (it has not really been deleted yet). A request for any name not on the to-be-deleted list is processed as normally. The requests are processed on an equivalent access FCFS basis, as all requests are. A request during the period to register a name (on the list) is either granted and the name is registered, or it is not granted, which means another registrar already registered the name earlier in the sunrise period. Response codes are as normal. The sunset will occur when all the names on the list are registered, or there are no more requests, or 1 hour before the next sunrise, whichever is earliest. Any leftover names not registered during the sunrise will be then made available for normal registration.

This new RRP service will commence immedately upon transition to the new registry operator.

With this method there is no large incentive for a registrar to submit the name repeatedly or even more than once, because for example, the list of to-be available names is known in advance so there is no need to run "check" commands. Transfers for names registered during the sunrise period will not be allowed before a 30-day period, as normal (see free transfer service). ICANN's registrar advisory concerning inappropriate lending of registry access posted at http://www.icann.org/announcements/advisory-12feb02.htm will continue to apply.

C26. State the maximum price you propose for each Registry Service identified in item C25.

The maximum price proposed is $4.95 per name-year for each of the two services listed in C25. Supporting financials are included in The .Org Foundation's proposed budget (see Appendix B).

Reasoning is as follows:

$4.95 to registrars, (or a difference of $1.62 to the Foundation):

1. 1. $3.33 + $1.62 = $4.95 is what it costs to provide excellent service and reflects the cost of improving the service over what exists today, for example, the responsiveness to .org registrants, via the extended EPP polling mechanism, and the real-time DNS.
2. Foundation administration and IT costs.
3. Slight marketing, legal costs.
4. ICANN registry fee (fixed and variable components)

By analysing prices offered by registrars to the public, we found a slightly lower (than $6) registration price, such as the price offered for .biz or .info names, offered by a registry to registrars is not generally reflected in the cost to registrants. Nevertheless, a $4.95 price, plus the partial endowment, allows the registry to perform on a break-even basis. We believe a very much lower price, for example, $2 or even free, would probably be reflected by registrars to some degree in the price to registrants, especially in high volumes, but probably not in low volumes, however, this significantly lower price would be below cost and leave no contingency funds, increasing the risk to stability.

$3.33 price to registry operator charged by the registry service provider:

1. The registry service provider is not charging any up-front development cost to build the necessary infrastructure. So part of the $3.33 fee is to cover these costs. The registry service provider must immediately service names that are already registered, but for which the registry service provider has not been paid, therefore, the initial build-out is more extensive than if it otherwise would have been if it were a pure TLD startup.
2. The registry service provider will be providing the following additional services, which are included in the $3.33 fee:
   1. a. Transition the registry to EPP from RRP, and compliance with other IETF RFCs and ICANN policies.
   2. b. Upgrade the DNS from 24 hour zone file update to real-time updates.
   3. Orderly and fair re-registration of deleted names.
   4. EPP extensions for self-identification and polling.
3. The registry service provider is not charging a registrar transfer fee.
4. A $3.33 price is competitive with the fee charged by other registry service providers for other TLDs, even though those new registries had no legacy conversion and legacy DNS service (for names registered previously) to perform.
5. The registry service provider is performing the billing, invoicing and reconciliation technical functions.
6. No part of the $5M ICANN endowment, (even if applied for, and received) will be paid to the registry service provider. The registry operator (The .Org Foundation) will own any assets these funds are used to purchase.

C27. Describe each Registry Service (as defined in subsection 1.16 of the model .org Registry Agreement) that you propose to provide without charging a fee.

No fees will be charge for any service that is currently provided by the registry, such as registering name server names. The following are the other free services offered:

Free Transfer Service
EPP registries require an authorization code in order for the registrant to transfer names. The code allows the holder of the code to take the code to the gaining registrar to initiate a transfer. The gaining registrar cannot unilaterally initiate a transfer without this code as the regisrars can with an RRP registry.

Domain name transfers between registrars will be free and will not add a year to the registration period. The gaining registrar will still need the auth-code from the registrant in order to initiate the transfer. To prevent abusive transfers, the process will be slowed down so that a transfer cannot occur within 15 days of the previous transfer, unless it is back to the original registrar. Transfers within 30 days of a new registration will not be allowed.

This service will commence after the transition to the EPP. RRP transfers will remain as-is and will cost $4.95 as long as RRP is used. This will help to encourage registrars to move to EPP in a timely fashion.

Free Compliance
No fee will be charged, or any fees increased, in exchange for complying with all future registry/DNS related IETF RFCs BCPs and ICANN policies, including transition from RRP to EPP.

Support
Free technical support to registrars will be available via email and via the telephone 24x7. Support will be available in English 24x7 and French during business hours.

Zone file publication
To reduce load on the registry's whois service, and for other reasons, the zone file will be published to an FTP site, with registrar-of-record data included.

Voluntary self-categorization and matching service
The registry will provide, via an enhanced EPP interface, a service whereby registrants will be able to specify for each domain, the registrant category. In some ways this is similar to the .us Nexus information, but will not be used to restrict registrations or settle disputes. The category selection will consist of:

• Individual
• Non-profit organization (such as a cahrity, or an NGO),
  Registrants who select this can enter the local government identifier, for example, a 501c(3) number for non-profits in the US, as well as "grant making" or "grant receiving" information
• · Other non-commercial organization (such as a government organization)
• For-profit organization
• Other commercial organization
• None of the above

Supplying the information is voluntary and is not required. This information will be displayed in the whois output and used to provide a search/match service so that non-profit grant making organizations, and others, can more easily find and contact non-profit grant-receiving organizations and visa-versa.

Polling EPP enhancement

To be better able to be responsive to the non-commercial Internet community, the registry proposes a polling mechanism, which will allow the community to provide feedback that can be fairly and accurately measured by the registry and then acted upon to create policy.

The EPP interface will be very simply extended so that each domain has one "vote" to express for issues relating to the registry. For example, this may be used in electing The .Org Foundation board members, or in helping them to decide or ratify issues that may from time to time arise.

Much like changing the name servers for a name, this feature will allow registrants to vote on issues, or to ratify pending decisions to be taken by the board. The domain name holders will have been validated as the authority for the domain by the registrar using the registrar's normal procedure just as they must be validated to change name servers.

The "ballot" will be posted on the registry's website and in the output for the registry's whois for each name at the start of the poll. This will get the word out that polling is beginning and disseminate (without intrusion such as an email to the registrant would cause) the information of exactly what is being ratified. The question will be open for voting for a period of time, say a month. A maximum of 10 questions can be asked at a time, so for example only 10 persons can run for a board seat at a time. An EPP field will exist for each of the 10 questions. This field can be "yes" or "no" or "abstain". The domain name holders can change their votes anytime until the end of the polling period. The last vote is the one that counts. They can verify their vote by looking up the name in the registry whois because the result of the vote will appear in the port 43 whois output for each domain, at least for a short period of time, and longer for the registry's web-based whois.

If a registrant feels strongly on an issue and would like to vote, but the current registrar does not provide this functionality, that registrant can switch (see free transfers) to a registrar that does provide the functionality. This provides an incentive/reward to any registrar to build a Graphical User Interface (GUI) that provides the voting functionality to the registrants and interfaces to the registry.

A report will be generated for the board of the Foundation (and published for all the .org registrants to inspect) so that they can use the result of the poll to create policy that is responsive to the needs of the community.

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.

The registry will comply with all the technical performance specifications listed at http://www.icann.org/tlds/agreements/name/registry-agmt-appd-29jun01.htm including the cross-network nameserver performance requirements. Additionally, we will perform zone updates for any domain with an average update of 10 seconds. The service level section of the document is copied below with our responses inserted.

4.1 DNS Service. Registry Operator considers the DNS Service to be the most critical service of the Registry, and will ensure that unavailability times are kept to an absolute minimum. The hardware, software and geographic redundancy built into the DNS Service will reduce unavailability times to a minimum.

4.1.1 DNS Service Availability = 99.999%. Registry Operator will provide the above-referenced DNS Service Availability. Registry Operator will log DNS Service unavailability (a) when such unavailability is detected by monitoring tools described in Exhibit A [of the model registry agreement], or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F [of the model registry agreement]. The committed Performance Specification is 99.999% measured on a monthly basis.

The monitoring tools we use are different than those described in Exhibit A [of the model registry agreement] but perform the same function.

4.1.2 Performance Level. At any time, 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.
Comply. And also with the rest of RFC2870. This load is estimated by the following calculation: 6.5B .com .net and .org queries a day means 650 million for .org since .org is 10% of the number of registrations in .com and .net. These queries occur across 10 name servers IPs, so 65 million each. Multiply by 2 to get peak, since the original number (6.5B) is an average, then by 3 to get the number for this requirement. This yields 390 million per day per nameserver IP for .org. Using this number and eNom's DNS software capacity, we estimate that seven name server IPs with 4 or 5 servers behind each will easily handle this requirement. One clustered database server that contains the zone information will service each of the DNS clusters (which are addressed by the shared IP), which is exactly the architecture with eNom's current DNS. The zone information will be replicated to each of the seven database clusters in real-time using proven database replication. If the database replication fails, the nameserver cluster will continue to function normally.
Also it should be noted that the queries that eNom's nameservers are currently answering now are more complex than those that eNom will be answering as the .org registry. For example, CNAME records, that point to other records recursively and so on, and as another example, the .org name servers will only have NS and A records, with the vast majority being NS records, and the A records (the "glue" records) are being removed. This simplification will speed up the DNS service.

4.1.3 Response Time. The DNS Service will meet the Cross-Network Nameserver Performance Requirements described in Section 2 of Exhibit A [of the model registry agreement] to this Appendix D [of the model registry agreement].
Comply.

4.2 SRS Service. Registry Operator provides built-in redundancy into the SRS Service in the form of 2 databases capable of running the SRS Service. Such redundancy will ensure that SRS Unavailability is kept to an absolute minimum.
Comply. We have a) 4 clustered database servers and b) a replicated standby data center with the same hardware setup.

4.2.1 SRS Service Availability = 99.4%. Registry Operator will provide the above-referenced SRS Service Availability. Registry Operator will log SRS unavailability once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F [of the model registry agreement]. The committed Performance Specification is 99.4% measured on a monthly basis.
Comply.

4.2.2 Performance Level. The Registry Operator will, on average, be capable of processing 40 Transactions per second.
Comply.

4.2.3 Response Time. The SRS Service will have a worst-case response time of 3 seconds, not including network delays, before it will be considered Unavailable.
Comply. See below for response time with eNom's current production reseller API that serves more than 2,000 resellers. These times include the response time for the various registries that are utilized during the execution of the command. Most times are below 3 seconds and the ones that are not below 3 seconds either perform multiple commands at the registry or perform real-time credit card transactions at a merchant processor. All the commands that operate solely on eNom's database (which is what the SRS' RRP/EPP commands would do) execute much faster than 3 seconds, and worst case do not take longer than 3 seconds. eNom logs timing information only for API calls that modify data, timing of commands such as the check command is not logged.

API Call	Time in Seconds
REFILLACCOUNT	11.03
MODIFYNS	10.22
CREATEACCOUNT	7.29
EXTEND	6.97
TP_CREATEORDER	5.35
UPDATEACCOUNTINFO	3.88
TP_SUBMITORDER	2.79
ADDTOPURCHASE	2.72
TP_GETORDERSTATUSES	2.63
PURCHASE	2.22
SETREGLOCK	2.16
CONTACTS	1.64
TP_RESUBMITLOCKED	1.55
SETPAGEURL	1.20
PURCHASEPREVIEW	1.16
INSERTNEWORDER	0.96
PRECONFIGURE	0.59
GETACCOUNTPASSWORD	0.56
SETHOSTS	0.53
UPDATECART	0.46
UPDATEPUSHLIST	0.45
ADDTOCART	0.24
ADDBULKDOMAINS	0.22
SETRENEW	0.21
TP_GETORDERDETAIL	0.20
FORWARDING	0.19
TP_AUTHORDER	0.16
TP_GETORDER	0.15
SETPASSWORD	0.13
TP_GETORDERREVIEW	0.11
TP_GETAUTHORDER	0.11

Notes:

• REFILLACCOUNT is lengthy because it does a credit card transaction for retail transactions. Large resellers do not typically perform many of these transactions because they write checks or wire the funds.
• CREATEACCOUNT is lengthy if the account creator passes credit card info: the system will validate the credit card number with a "pre-auth" at our merchant processor. Note that it is either fast or slow, but not in between.
• MODIFYNS calls the RRP command "status domain", builds a list of name servers to delete, and the list of name servers to add, and then calls the "modify name server" command at the registry. Status and modify take a relatively long time at the registry. The command could be made quicker, by utilizing data in the local database, not real-time data from the registry, but on occasion, if the local database is different than the registry, that method would cause erroneous name servers to be on the name.
• EXTEND: this command, depending on its use, could possibly invoke a credit card transaction.
• The timing may vary for commands depending on the number of names supplied. Unlike the RRP (and EPP expect the "check" command) eNom's API commands are capable of operating on multiple names.

4.3 Whois Service. Registry Operator provides built-in redundancy into the Whois Service in the form of multiple servers running in 2 different data centers. Such redundancy will ensure that unavailability of the Whois Service is kept to an absolute minimum.
Comply.

4.3.1 Whois Service Availability = 99.4%. Registry Operator will provide the above-referenced Whois Service Availability. Registry Operator will log Whois Service unavailability (a) when such unavailability is detected by monitoring tools described in Exhibit (a), or (b) once an ICANN-Accredited Registrar reports an occurrence by phone, e-mail, or fax as described in the customer support escalation procedures described in Appendix F [of the registry agreement]. The committed Performance Specification is 99.4% measured on a monthly basis.
Comply.

4.3.2 Performance Level. The Registry Operator will offer a Whois Service to query certain domain name information. Whois Service will, on average, be able to handle 200 queries per second.
Comply.

4.3.3 Response Times. The Whois Service will have a worst-case response time of 1.5 seconds, not including network delays, before it will be considered unavailable.
Comply.

C29. Intentionally omitted.