A. Add new value to the Internet name space

Use of the sTLD will not eliminate spam across the Internet. Spam will still be sent using other TLDs and there are many efforts to reduce spam. The SO can guarantee that message sent using names in the sTLD will be very nearly spam-free. Usage of the sTLD can dramatically increase the number of non-spam messages that get through to their destination, and indirectly reduce the number of spoofed senders (messages that say they come from a domain but actually, do not), and make spam messages sent using other TLDs more easily identifiable, then that is of significant value to the Internet at large. What is the value of increasing the likelihood of your message actually reaching its destination? Whatever value that is, and the SO believes it to be significant, that is the value that will be added to the namespace for each message sent that utilizes each name registered. Name value: The sTLD string Though the core community the sTLD is aimed at is the group of technical mail server operators (both the senders and the receivers), the broader Internet community benefits because that wider community sends and receives email. The only part of the Internet community that will not benefit are the people who send email but do not send it according to the policies of this sTLD, and even those people are not prohibited from sending mail. They are still able to send it, they just cannot use the sTLD to help the mail reach its destination. We would like the sTLD string to be as generic as possible because then the wider community of Internet users have an easy, and more important, memorable, way to 1) visit the site of the mail sender with verified information regarding the sender displayed there, and 2) to complain about sent mail by submitting an abuse complaint. Just add ".mail" to the domain to send an abuse or to see information about the sender. Additionally it adds value to the other parts of the name space because the whois information for the other TLDs would be validated for some portion of those names that are also registered in this sTLD. Also, if adoption becomes widespread, because the other registries' would need a contract with ICANN in order for its TLD to be used as second-level-domain in this sTLD, it provides a slight incentive/benefit for the ones that do not have a contract to make a contract with ICANN. Enhanced diversity of the Internet name space Due to its uniqueness, this sTLD adds to the diversity of the Internet name space. It expands the number of dimensions for which a domain name can be used. In this case, the name both represents a validated identification and also an underlying system that enriches one of the most basic functionalities of the Internet: email. The sTLD provides an additional "layer" to other parts of the namespace increasing their utility by allowing them to participate in a responsible email community. Since the registration of a domain in the sTLD is based upon the prior existence of the key domain, only the registered user of the key domain may register the sTLD domain. What this means is that any registered name in the sTLD will, by definition, be put into active use, and will remain as long as the registrant follows the policies. Furthermore, this ensures that there is very little chance that a domain in the sTLD may be cybersquated hijacked or defensively registered. This also means that there will not be, indeed, cannot be any land rush or sunrise headaches. Part of this sTLD's mission is to distinguish one group of users from another group. A TLD is intended to be an easily remembered, clear, logical, classification of a community of Internet users not already classified. It makes them easily identifiable by other users. By using a second level domain, this community of users would be mixed-in with the other TLD's users, and this clarity is lost. The SO realizes that the risks of not using a TLD are severe. If, for whatever reason, there was a service interruption in the delegation of the SLD, the entire, now established, trust system would be neutralized. * There is a risk that the TLD in which the SLD was registered, goes under. * The second-level-name we select is revoked. Many if not all registration contracts reserve the right of the registry to remove the name for any reason. * A legal proceeding could be filed against the registry compelling them to suspend the domain at best and delete it at worst, this could be something as simple as a UDRP proceeding. The SO, being delegated a sTLD, would be in complete control in all these circumstances and would not have to rely on another party for security. To illustrate, with an SLD, were it to be taken out of the TLD zone for any reason, validation queries (by the receiving mail server) will return NXDOMAIN, the DNS response for “domain not found.” In this case the receiving mail server is instructed to distrust the source of mail. This is the response we will send when the mail source is, in fact, not trusted. Therefore, the effect of being removed from the TLD zone would be that all trust verifications would actively fail. If this were to happen, all receiving mail servers that were using the SLD would break and they would have to change their code. A failure of the DNS itself results in a time-out, which is not an active failure, and in this case the receiving mail server is instructed to fall back on alternative methods of verification. With a TLD, as we would not take ourselves out of the root zone for any reason, an NXDOMAIN would not be generated falsely. Also, it is desirable for the string to be an easy memorable mnemonic because the public, if it remembers the sting, can use it to easily find information on the mail sender or to easily send abuse messages to the SO by simply appending the string to the end of the key domain. With a second-level name this benefit is greatly reduced. Reach and enrich broad global communities Internet users who have not registered names in the sTLD benefit from the sTLD because their receiving mail servers can more easily distinguish messages that are not spam. Also, as adoption increases, the price can decrease, so that not only are more and more receivers able to partake in the benefits of spam-free email from more people using the domains in the sTLD, but also more and more senders, are able to get their non-spam messages through.

B. Protect the rights of others

Any domain name registered in the sTLD must first be registered in another TLD, the rights and obligations of every other TLD are reflected and made more secure. Information producers and consumers will be able to interact with greater confidence, free(er) from trespass and with the basic knowledge that a registrant has a verified mailing address. The rights of everyone in all TLDs will be enhanced. In terms of compliance with ICANN policies designed to protect the rights of others, the sTLD will add to WHOIS compliance across all TLDs. While this sTLD, by itself, will not end all illegal and abusive email practices on the Internet, it adds to the ways such practices can be avoided. WHOIS policies inevitably attempt to balance competing interests such as reliable identification versus free speech and anonymity, while also creating the potential for misuse of WHOIS information itself. This sTLD adds to the diversity of ways to balance these dilemmas and creates a new incentive for compliance: more reliable email communication. This sTLD risks no derogation of the rights of others and only furthers reliable self-identification and communication among all interests, groups and constituencies, proprietary or otherwise. In addition, spam, much like a telemarketing phone call, can be considered an invasion of ones privacy rights, one of the purposes of the sTLD is to help protect the rights of people to receive spam-free email.

C. Assurance of charter-compliant registrations and avoidance of abusive registration practices

Registered names in the sTLD are of the form "key.sTLD" where "key" is a domain name that is already registered in another TLD. The list of applicable TLDs is constrained to TLD registries that either have contract with ICANN and comply with the UDRP and other ICANN policies or are ".mil", ".edu", ".gov", ".int" which are restricted TLDs. There are three basic elements of a charter-compliant registration in this sTLD: 1) Registration and listing of one's WHOIS information in the Key Domain in another TLD; 2) No spam; and 3) Confirmed WHOIS. The registration and WHOIS listing of the Key Domain and the spam policies of this sTLD are discussed elsewhere in this application. WHOIS compliance will be verified by requiring the mailing of all application materials and the matching of WHOIS with the correspondence address. Existing WHOIS information will be verified at the following times: on any change in the Key Domain's WHOIS information, upon the lodging of a substantiated ("Substantiated" means that the WHOIS information itself is patently false or incomplete based on addressing standards for the claimed jurisdiction or that the WHOIS is demonstrated to be false through the presentation of evidence of mail returned "undeliverable" or "addressee unknown," or similar.) allegation of false WHOIS, and otherwise a minimum of once a year or as otherwise directed by ICANN's WHOIS policies. At least one contact each will be attempted via email, telephone, and facsimile and two attempts at contact via mail will be attempted before a name is de-listed from the zone one month after the first attempted contact. A successful non-mail contact in the last week of the month will give the registrant one additional week to succeed in achieving a mail contact. The sTLD will not be an additional forum for hearing disputes regarding the registration of domain names in other TLDs -- each TLD will rightly retain its own jurisdiction over its own policies. Significantly, the sTLD creates a new incentive -- more confident communication -- for compliance with WHOIS, UDRP, every other policy or law the violation of which results in a change in a domain name's WHOIS information. IP Rights Registrations that infringe on the intellectual property rights of others will not only be discouraged, they will be not allowed, because only the registrant of the key domain will be allowed to register that domain in the sTLD. If there is an intellectual property dispute with the key domain, the new registrant of the key domain is also the new registrant of the sTLD domain. We do not expect there will be a trademark dispute over, for example "example.com.mail", and not over "example.com". Charter-compliant persons or entities that are allowed to register names: This is nearly the entire purpose of the SO: to determine which registrants (and their domains) are members of the community who follow the policies and send spam-free email. It is part of the registration process that determines if the key domain is compliant with the policies and also, once in the sTLD zone, that the key domain and email sent using the sTLD continues to comply. Reservation list All the names in the entire namespace are reserved because, all the names on the second level are reserved for future use. Only those strings that match stings of approved TLDs, will be utilized on the second level. All the names on the third level are reserved for use by the second-level registrant at another TLD registry. Minimize abusive registrations Abusive registrations will be minimized for two reasons: 1) The high per name-year fee 2) The key domain must already be registered in the key domain TLD for at least 6 months. Additionally, all abuse messages for each domain will be received by the SO, not by the registrant. These messages will be used to determine if the registrant's registration is abusive, and if it is, it will be removed from the zone by the SO. There will be no "rush" on the names when the registry opens based on the trademark or other value of the name itself because only the registrant of the key domain will be the registrant of the key.sTLD domain Comply with trademark and anti-cyber squatting legislation The SO expects to fully comply with whatever applicable trademark and anti-cyber squatting legislation that might exist or be enacted during the course of our sTLD administration. Provide protections for famous names and trademarks Famous names and trademarks are protected because no name will be registered in the sTLD that has not already been registered in the key domain TLD. The disputes regarding names in the other TLD have very likely already been settled because the key name must have been registered for at least six months there. Nevertheless, if there are any disputes, the SO and the registrars making registrations will agree to abide by any UDRP or other (court-order) dispute resolution mechanism. No disputes are anticipated. Also, there is no need for a sunrise period in which to provide these protections because only the registrant of the key name may obtain the key.sTLD domain name.

D. Assurance of adequate dispute-resolution mechanisms

Because a Key Domain is a pre-requisite to listing a domain name in the zone of this sTLD, UDRP, start-up (sunrise), and similar dispute resolution procedures are not required, though if a UDRP is brought it will be complied with. Dispute resolution mechanisms relating to WHOIS and spam are covered elsewhere in this application.

E. Provision of ICANN-policy compliant WHOIS service

The whois information is integral to the operation of this sTLD because even with technologies that prevent sender spoofing (Sender Authentication Technologies that prevent forged "from" and other addresses), the registrant can still spam, and if the whois information is not validated or checked at all, then it is very difficult to find out who, really, is behind it. Part of the per-name-year fee is to be used to perform various validity checks on the whois information of the underlying ("key" domain, as we call it) domain name. Also, a requirement is that this key domain must be registered for at least 6 months before the sTLD domain will be placed in the zone. Validity checks include 1) sending postal mail using either a governmental postal system or courier such FedEx to the registrant or administrative contact and providing a system whereby the registrant can confirm receipt of the postal mail and 2) Sending email to verify that the email address in the whois works and that mail sent to that address is received by the registrant. The SO reserves the right to also perform other whois information verifications such as calling the phone number listed in the whois, sending faxes to the fax number, contacting the other whois contacts such as the technical contact, as well as on-site in-person visits to the location listed in the whois, and other investigations. Due to the fact that many large companies and other members of the Sponsored Community list only their corporate address in the whois for the key domain, two optional fields can be entered when registering sTLD names. These will be communicated by the registrars to the registry using the EPP protocol. These fields are a "Care Of" name, which is the name of a contact person at the address where the postal mail will be sent, and an "Alternative Email" address, which email address must be in the key domain. If these optional fields are used by the registrant, postal mail will be sent to the address listed in the whois with "Care of" line as the person's name, and mail sent to the optional email address will also be sent to the email address listed in the whois output. Registrants will not be transmitting the whois to the sTLD operator (the RO) via the registrars. This information will be provided to the RO by the XO who will use the zone file generated by the RO to determine those key domains for which to obtain whois information at the other TLDs. This information will then be transmitted from the XO to the RO for insertion into the RO's ICANN compliant whois database, and as the current whois policy states, is accessible to the public. The XO will monitor the zone files and the whois of the other TLDs daily so that any modifications made there will be transmitted and noted, with little delay, by the RO (one of the policies by the SO is that if the key domain is removed from the zone of the other TLD it is also removed from the zone of the sTLD). If the whois information on the key domain changes, then the SO reserves the right to re-validate the new whois information at no charge to the registrant, and it would if the changes were significant. If the whois information was seen to be changing often, the sTLD domain may be removed from the zone. The registrant agrees to allow the whois information that was validated to appear at the website "example.com.mail" (in a graphical format) which is maintained by the XO for the RO. This allows the members of the community the opportunity to see the most recently validated whois information for each domain by simply using a browser and adding ".mail" to the end of the domain name in question. The method described will be modified, if necessary, by changes in ICANN's whois policy, as well as any changes that would need to be made to the output of the whois database (port-43 or otherwise) by the RO, if those are required by changes in ICANN's whois policies.

Business Plan - Current Operations

I. Full description of registry services to be provided.

The primary registry service is 1) the registration of domains within the selected sTLD through accepted ICANN-accredited registrars and 2) ongoing policy compliance and operations. This section primarily describes the second because the first is well-known and the sTLD will deviate little, if any, from standard practice in this area. The sTLD is both the platform as well as the community in which responsible use of email can be monitored and enforced, but is also technology-agnostic in how that responsible use is accomplished. By providing a secure DNS zone for the sTLD, the appropriate records to implement a wide variety of sender-authentication and authorization (SA) technologies may be entered and maintained. All of the major, current SA proposals are suitable for use in the sTLD. In this light, we are confident that the sTLD will play a key role in the proving and use of these technologies, and a solution can and will be found to the ongoing spam problem. Domains will take the format of key.sTLD, where key is any existing registered domain in any other namespace that meets the criteria in this proposal. For instance, if example.com is a currently registered domain, it is considered the key domain for the example.com.sTLD registration. The primary use of the domain lies within the need to authoritatively administer the sTLD zone, which will contain DNS records utilized by authentication and anti-spam technology. The domain name is used, among other things, during the HELO/EHLO phase of the SMTP protocol. This name format also prevents any land rush and removes domain speculation and trademark issues. In addition to the published policies of the Sponsoring Organization (SO), the criteria that must be met by a registrant in order to be inserted and remain in the sTLD zone shall include: 1. The key domain must be in an ICANN-approved TLD and have publicly-available ICANN-approved Whois or be within the edu, gov, mil or int TLDs. Therefore, the initial allowed key domain TLDs will be com, net, org, info, biz, edu, gov, mil, and int. The Whois information will be used, with optional additional information (OAI) to verify the responsible contacts for the registration. All means of contact, per policy, will be verified before the zone records are provisioned by the Extra Services Operator (XO). 2. A substantial registration fee will be required to: * Encourage domain registrations from only those registrants who have the intention to follow the sTLD’s policies * Cover the initial verification costs * Cover ongoing costs associated with monitoring the abuse mailbox for every sTLD domain on a daily basis * Cover the system build-out costs and other expenses of the SO * Support ongoing research and development towards the responsible use of email 3. The key domain must have a creation date at least 6 months prior to sTLD registration. 4. The registrant must support and maintain SO-defined policies and procedures including, but not limited to: * Abuse monitoring: Registrant must respond in a timely manner to bona-fide reports of abuse and have operational policies for handling abuse. * Technical use policies: The key domain must remain active in its respective TLD zone and must properly resolve all records referenced by the sTLD zone file. * Responsible use policies: Registrant must abide by the SO’s policies regarding responsible email sending practices throughout their entire organization. In essence, no spamming (please see the detailed definition of "spam" outlined elsewhere in this application). Any deliberate, irresponsible use will result in the removal of the sTLD domain’s applicable records from the zone. * Maintenance of accurate contact information: Changes to key domain Whois information may result in the need for re-verification. The XO will monitor key domain Whois and re-verification may be necessary at the discretion of the SO. A large number of whois changes, judged to be an effort to avoid other policies, may result in the domain being removed from the zone. Policies will be set forth by the SO and may change from time to time as necessitated by the changing electronic mail landscape. The issues of responsible use require an SO that is ready, willing and able to make these rapid adjustments to changing issues. Please see Section B regarding policy input by the community. 5. The registrant must warrant their Whois information along with registrant-supplied OAI for the key domain is correct. This combination of Whois and OAI will become the Whois information for the sTLD domain. All Whois information for the sTLD domain is maintained by the "thick-model" Registry Operator (RO). 6. All DNS records for sTLD domains will be governed by SO policy and managed by the XO. For example, DNS "A" records will be inserted for each sTLD domain, pointing to the XO-operated web site. This site displays the validated Whois information, the current status of the domain, abuse information and instructions for public use. MX records will be inserted for each sTLD domain, pointing to mail servers administered by the XO, on behalf of the SO, so that any abuse messages sent to the sTLD domain will be received by the SO. Most importantly, appropriate DNS records implementing protocols such as SPF, Microsoft Caller-ID, or Yahoo! DomainKeys, collectively called sender authentication technologies (SAT) will be inserted. The use of these complementary technologies falls into the SO’s mission to enable responsible email practices and it creates trust in the sTLD even before its implementation by all recipient systems. The registration process begins by first verifying that the key domain is at least 6 months old, and the current Whois information of the key domain is accurate, complete and sufficient to allow the receipt of the verification materials. The OAI may be provided to the ICANN accredited registrar during the registration process in order to ensure that verification materials are delivered to the appropriate individual. This information may include the name of an authorized person at the organization with which contact will be made, the email address of the authorized person at the organization who will receive validation communications, and a voice telephone number of an authorized person at the organization if it is different than what is displayed in the registrant contact information of the key domain Whois. Any email address must be within the domain or sub-domain of the key domain for which the sTLD is being registered. If an additional email address is supplied, validation email will be sent to both the additional email address as well as the registrant email address specified in the Whois of the key domain. The registrar communicates with the RO using EPP. The registrar will check the initial availability of the domain and if available, continue the registration process by requesting the RO add the domain. If OAI was provided, the registrar will transmit this information along with the add request. The RO will add the domain to the DNS sTLD zone and immediately give it a status of HOLD. All DNS records from the sTLD zone will be delegated to the XO DNS system which will not contain any registrant-supplied resource records. XO and registrant supplied DNS resource records will only be added and status changed to ACTIVE after the verification process has been completed. During the 5 day grace period the name may be deleted from the RO and the registration fee will be refunded. The verification process does not begin until after the grace period has expired. The entry in the registry, however, is made at the time of registration to ensure that an erroneous report of ‘available’ cannot be given during the grace period. During the grace & validation period the sTLD domain will not be available for use by the registrant. During this time, however, the sTLD domain will resolve in the RO zone to an informational web site displaying all public information as well as allowing secure access by the registrant for the purpose of the validation process. The registration period of one calendar year shall begin when the domain is added to the RO database at the start of the grace period. The only registration period available is one calendar year. The renewal process may require a re-verification of all registration data to remain in the sTLD zone. Using the public RO zone information, the XO will detect new registrations and begin the verification process. The XO will collect and merge the public Whois information for the key domain along with any OAI. It is the responsibility of the registrant to ensure that the public Whois information for the key domain is current and correct throughout the verification process. The XO WILL NOT have any access to non-public information. All registrations in the sTLD shall undergo a rigorous validation process of the physical mailing address, the email address and optionally the voice/fax numbers. Details of the validation process are outlined in Part E. Section 2.d (Technical Specification) After registration and upon validation of all criteria, the name is made active by provisioning the following XO/RO services described here in brief: 1. Entry of DNS A, PTR and MX records for mail servers under the key domain 2. Entry of SAT records 3. Creation of an informational and maintenance web site for both public and private interaction for the sTLD domain 4. Provisioning of port 43 Whois service 5. Continuous monitoring throughout the registration period of key domain in its zone, key domain ownership, Whois, and dispute status (if any), abuse reports, sending mail server IP addresses. The DNS records (including SAT records) are maintained by the XO, thereby ensuring the integrity and security of the zone and its functional stability. This control of the zone and its operation encompasses one of the core values of this sTLD.

II. Demonstrate current business operations including core capabilities particularly in registry/database and Internet related operations; the services and products offered; duration of provision of services and products in current business. Demonstrate capacity to provide ongoing registry services.

Registry Operator (RO) The selected Registry Operator is VeriSign, Inc. Extensive detail about VeriSign and their current operations and core capabilities are described in Part E. Technical Specification. VeriSign’s Technical Capabilities VeriSign brings proven and unequaled operating experience, business and technical skills, world class infrastructure, and an unsurpassed global footprint to successfully build and operate the proposed Sponsored Top Level Domain (sTLD). It will apply its core assets, including registry operating and outsourcing experience, DNS Constellation, and telecom and security service experience to ensure a reliable, responsive, and scalable design and operation. VeriSign Inc., headquartered in Mountain View, California, employs approximately 3,000 people and has an operational presence in more than 30 countries. The company reported total revenues of $1.1 billion (U.S.) for our most recent fiscal year, which ended December 31, 2003. VeriSign serves as a gateway to establish an online identity, maintaining the definitive database of more than 31 million Web addresses registered in .com and .net top-level domains (TLDs) on a powerful platform. Responding to billions of DNS look-ups daily, the platform serves all of the world's domain name registrars that process .com and .net domain name registrations. VeriSign’s operational infrastructure consists of secure data centers in Mountain View, California; Dulles and Ashburn, Virginia; Seattle, Washington; and Tokyo, Japan. In addition, VeriSign leases secure data center space across the globe to house its international infrastructure. VeriSign personnel operate and maintain this infrastructure. The key features of our operational infrastructure include the following: Distributed Servers. We deployed a large number of high-speed servers to support capacity and availability demands that offer automatic failover, global and local load balancing, and threshold monitoring on critical servers in conjunction with our proprietary software. Network Security. We incorporated network security features such as protected domains, restricted nodes, and distributed access control in our system architecture. We also developed proprietary communications protocols within and between software modules that prevent most known forms of electronic attacks. In addition, we employ firewalls and intrusion detection software, and contract with security consultants who perform periodic attacks and security risk assessments. Call Center and Help Desk. We provide customer support services through our phone-based call centers, e-mail help desks, and Web-based self-help systems. Our Virginia call center is staffed 24x7 to support the Naming and Directory Services business. Operations Support and Monitoring. We have an extensive monitoring capability that enables us to track the status and performance of our critical database systems at 60-second intervals, and our global resolution systems at four-second intervals. Our distributed Network Operations Centers (NOCs) are staffed 24x7. Disaster Recovery Plans. Our disaster recovery and business continuity capabilities address the loss of entire data centers and other facilities. Our Naming and Directory Services business unit maintains dual mirrored data centers that allow rapid failover with no data loss and no loss of function or capacity. Our critical data services (including digital certificates, domain name registration, telecommunications services and global resolution) use advanced storage systems to provide data protection through mirroring and replication. VeriSign’s Credentials as a Registry Operator VeriSign operates both the Shared Registration System (SRS) and Domain Name System (DNS) resolution systems for .com and .net the world’s largest TLD with over 31 million domain names in active use. In addition, we operate .net, the critical resource underpinning the world’s leading Internet infrastructure providers. Name servers in the .net domain are used by the major ccTLDs and support more than one third of all e-commerce transactions. VeriSign operates Registry and Resolution services for a number a gTLDs and ccTLDs including .name, .edu, .cc, .tv, and .bz Sponsoring Organization (SO) The founding Sponsoring Organization is the Spamhaus project. Spamhaus tracks the Internet's worst Spammers, known Spam Gangs and Spam Services, provides real-time anti-spam protection for Internet networks, and works with Law Enforcement Agencies to identify and pursue spammers worldwide. Spamhaus is a not-for-profit anti-spam advocacy group. We research spam and spammers and have, for several years, offered solutions ranging from the technical to advice to government agencies as to how to slow the growth and hopefully one day put an end to spam. Spamhaus offers free online databases that give details on who is spamming and what areas of the internet spam is coming from. These databases are used by a large portion of the worldwide internet community to aid them in implementing their email polices in regards to spam. The most used of these is the Spamhaus Block List which is a database of IP addresses Spamhaus (based on the knowledge its staff have of the world's daily spam email flow) is suggesting others do not accept email from. Extra Services Operator (XO) The selected initial Extra Services Operator (XO) is eNom Inc., a for profit company and an ICANN accredited registrar. Formed in Washington State in the USA in 1997 as literally a garage start-up and it became one of the first registrars accredited after the test bed in 1999 when the registrar industry was fully opened to competition by ICANN. eNom is now one of the largest registrars with over 2.8 million names sponsored across a number of TLDs and has established a reseller channel of over 7,000 resellers. eNom has consistently increased its market share amongst registrars, especially in recent months, by performing from between eight to eighteen percent of all net new registrations in the most popular TLDs each month worldwide. As an XO eNom will be committed to continue to provide superior service and value for the registrar customers, the registry operator, and ultimately for the sTLD registrants and the Internet community. eNom’s current offerings include: 1. A domain name registration in all the most popular TLDs, or renewal, re-registration of a deleted name, or transfer. 2. Name server service with real-time zone updates. 3. Web site hosting available to retail as well as the reseller market. 4. Web and port-43 Whois service with customizable output. 5. Sub-domain creation for up to 100 hosts per domain. 6. URL redirection. 7. Customizable parking page. 8. Domain name management, with sub-account creation. 9. Online transaction reports. 10. Email address creation and forwarding for 100 email addresses for each domain. 11. Free 10 page website with web-based website builder tool. 12. Name-your-phone where users can name their text-messaging enabled device to enable others to send messages to it by name. 13. Online global changes, for example, to change the name servers for 1000's of names at the same time. 14. Email and phone tech support. 15. API interface ability (equivalent to an EPP-type interface) 16. A domain name registration aftermarket product Compared to the XO requirements set forth, eNom’s service offering list is more extensive and clearly shows its capability to fulfill the role. Potential conflict eliminated: All XO functions fulfilled by eNom Inc. will be performed using public information. This eliminates potential conflict by using only information available to any other entity. Protocol: support, function, and adapt eNom has extensive experience in complying with Internet protocols. It has built software that complies with the protocol specifications for: DNS POP3 and SMTP RRP EPP Various 3rd party protocols of various complexity DNS eNom, and a number of other large DNS providers no longer use BIND for nameserver software. "Having everyone run the same name server is a screaming invitation for bad things to happen,'' says David Conrad, CTO at Nominum, a DNS service provider (http://www.nwfusion.com/news/2002/133242_06-10-2002.html). We agree and apply the idea to the other software running on the name server hardware, too, including the OS and the database software. A variety of running software, as long as they all comply with the same protocol standards, makes the entire domain name system more robust and less susceptible to a flaw in any one instance of the protocol's implementation. eNom's real-time DNS was written from scratch in C++. It was built with a modular "plug-in" architecture that lends itself to adoption of modifications to the RFCs above and for feature enhancements and monitoring. Aside from manual testing for the nameserver software's compliance with applicable RFCs, a test application was developed to determine performance and accuracy of the eNom DNS service. The test application used a 48-hour capture of millions of live queries sent to a server running BIND 9.1, and the server's response. The test application then flooded the eNom DNS service with the same queries, recording the responses. A byte level compare between the answers given by the two servers was used to determine that the eNom DNS service did, in fact, give the expected responses when under a load. This is important because one of the role’s of the XO is to provide the DNS resolution services of all sTLD domains. eNom’s DNS service answers approximately 500 million DNS queries on an average day. The current DNS system configuration has peak capacity of 1.82 billion queries per day.

III. Demonstrate the qualifications and experience of financial and business officers and other relevant senior employees. Show the current size of their staff and demonstrate their ability to expand the employee base and recruit employees with specialized skills as necessary.

Registry Operator – Verisign, Inc. Approximately 3,000 employees Aristotle Balogh — Senior Vice President, Operations and Infrastructure Mr. Balogh led the invention of VeriSign’s award winning ATLAS platform. A highly reliable look-up infrastructure used for DNS and other telecom look-up services. ATLAS was ranked number 8 in the 2002 InfoWorld 100 list of innovative technology solutions. As Senior Vice President of Operations and Infrastructure for VeriSign Corporation, Mr. Balogh is responsible for delivering secure, highly reliable, and highly available core Internet services critical to the operation of the Internet and e-commerce, including security services such as web server certificates, the payment gateway, and the DNS. Mark R Gathje — Vice President of Technical Operations Mr. Gathje has successfully overseen the operation of VeriSign’s .com and .net infrastructure to consistently deliver 100 percent availability. Mr. Gathje brings more than 25 years of experience running large-scale technical operations for leading organizations such as VeriSign, AMS, TRW, and the U.S. Air Force. As leader of the Technical Operations group within the VeriSign Naming and Direction Services (VNDS) division, he is responsible for the planning, deployment, and daily operation of VeriSign's products at their Northern Virginia facilities, as well as assets spread across 12 other locations worldwide.  Mark Kosters — Vice President of Research Mr. Kosters leads VeriSign’s technical strategy and is a recognized leader in driving industry standards. He brings more than 15 years of experience as an applications developer and technical manager. Over the last 11 years, he was a senior engineer at Data Defense Network (DDN) NIC, and chief engineer and Principal Investigator under the NSF- sponsored Internet NIC (InterNIC). He has represented both network information centers in technical forums such as the IETF, RIPE, APNIC, and NANOG. Mr. Kosters has been involved in Internet standards development; he co-authored RFCs on RWhois (RFC 1714 and 2167), Internet Registry IP Allocation Guidelines (RFC 2050), and Root Name Server Operational Requirements (RFC 2870). Scott Hollenbeck — Technical Director of COM NET Registry Mr. Hollenbeck is the author of the Extensible Provisioning Protocol (EPP), an Internet protocol for the registration and management of Internet infrastructure data including domain names. Mr. Hollenbeck is the Technical Director for the VeriSign COM NET Registry. His role as EPP author required extensive coordination with members of the Internet Engineering Task Force (IETF). He is also a co-author of RFC 2832, the VeriSign Registry-Registrar Protocol (RRP), a precursor of EPP developed for use in the VeriSign Shared Registration System (SRS). He has been a contributor to several industry efforts related to domain names and Internet security, including internationalized domain names (IDN), ENUM, public key cryptography, S/MIME, the Extensible Markup Language (XML), and the Transport Layer Security (TLS) protocol. Extra Services Operator - eNom, Inc. Approximately 50 employees Paul Stahura - CEO Mr. Stahura, the founder of eNom, Inc. has served as the company's President and CEO continuously since 1997. He started the company in his garage in late 1997, grew the company during 1998-2000, sold it in 2000 and then bought the company back in early 2002. The company now employs more than 50 people, is one of the top five registrars, and will have revenues of over $30 million (cash-based) for 2004. Mr. Stahura has 10 years of entrepreneurial business experience as well as 17 years of technical experience designing, implementing and commercializing complex software development projects in management positions. Prior to eNom Paul co-founded Syllogistics, LLC and was a Principal at this information technology consulting company. He was instrumental in its growth from 5 to 55 employees and from no office to offices in three states. Paul sold the company to WebVision in June 2000. While at Syllogistics, Paul managed groups of consultants that performed IT development services at a number of web startups and other companies. Paul is an inventor and has been granted one patent, with another filed. He holds both Master of Science and Bachelor of Science degrees in Electrical Engineering from Purdue University. James L. Beaver -VP Operations As one of the co-owners, Jim brings 16 years of management and software development experience to eNom. His background in IT for manufacturing, telecommunications and biomedicine allows Jim to be effective in providing the best available solutions for eNom and its customers. Jim is responsible for the productions systems, finance/accounting, IS, legal and human resources. In addition to being the principal consultant in the Northwest Region, Jim co-managed the operations and staff of the Redmond Development Center for Webvision, a web development, hosting, and management company, from 2000 to 2001. Jim then joined the eNom team to help grow and finance the company, as it was still a wholly owned subsidiary of Webvision. From 1996 to 2000, Jim was a Principal of Syllogistics, LLC, a nationwide professional services firm specializing in distributed, integrated business solutions. Jim co-founded the company, helped establish the west-coast office, and was instrumental in the growth the company. While at Syllogistics, Jim, on a 2-year contract for Boeing Corporation, was a Lead Architect of Application Integration for the largest distributed-IT project that any company was undertaking at the time. The project was a business process reengineering effort, involving hundreds of developers, which integrated over 400 disparate systems worldwide and migrated from over 1,000 legacy systems. The migration involved: * 500 gigabytes of airplane production data. * 700 million records. * 900,000 parts. * 31,000 users. Before Syllogistics, Jim grew Vetronics, Inc, a small veterinary electronic product company, from startup phase to profitability and an eventual sale. He managed technical development, production, sales, operations and international customer support. Jim holds a Bachelor of Science in Electrical Engineering from Purdue University. Matthew Stearn Vice President of Business Development with oversight of Customer Service, and Policy Mr. Stearn joined eNom in March of 2000, as it's first employee. Primary responsibilities include all aspects of the customer experience. He manages the Business Development and Marketing department. The department is the engine behind eNom's growing network of resellers and retail customers. The reseller network has propelled eNom into the 5th position among ICANN accredited registrars with 2.8 million active domains. eNom is recognized month after month as one of the industry's fastest growing registrars. In his oversight of Customer Service he heads a department that services the needs of over 35,000 retail domain holders and over 7,000 resellers, with 3,000 of these resellers using eNom's API. Mr. Stearn sets policy and service levels enjoyed by eNom's customers. He is responsible for transforming customer feedback into market innovations, products, and tools. Mr. Stearn began his career at the corporate headquarters of Pacific Life Corp. As Director of Business Development and Marketing, he grew the small group health division from $1 million in annual sales to a $20 million per year profit center and industry leader. In 1993, he founded Pacific Coast Properties, a real estate investment and management company in Los Angeles. The PCP portfolio includes residential and commercial investment properties in excess of $100 million dollars. He sold PCP in 1996 but remains an advisor. In 1997, he opened the Northwest regional office of employeeservice.com, an out-sourced human resource application service provider headquartered in San Francisco. He was instrumental in securing partnerships with employeeservice.com's largest customers, and was recognized for managing employeeservice.com's most profitable region. Mr. Stearn has been a consultant to Boeing, the McDonalds Corp and Zones International and still consults to PCP and Calamaris, a Washington technology start-up. He graduated from the University of California at Santa Barbara with a degree in Political Science. See "Business Plan Registry Requirements V" for planned SO management formation.

IV. Describe whether the business currently provides domain name registration services through an accredited ICANN registrar. Describe how the registry would augment base level registry services with value-added services or products associated with the registry.

The SO does not currently provide domain name registration services. It is proposed that the SO contract with an ICANN registrar subsidiary to perform the "extra registry services" which are defined as the particular value-added services for this sTLD contemplated in this proposal which is not the registry services. The ICANN accredited registrar will NOT have access to any confidential or proprietary registry information, but will nevertheless setup a separate entity in which to perform the extra registry services operational activities. Equal access to the registry for all ICANN accredited registrars will be maintained by the RO. The SO is proposing one value-added service that would be required to be bundled and sold with each registration at the registry. This service would determine if the domain name should be entered into or pulled from the zone for policy violations (beyond those typical, for example IP disputes, for other registries such as .com). The XO would provide those extra technological tools and systems, the operations beyond normal registry operations, to allow the SO to make these decisions. These are categorized into 3 groups, 1) whois/zone related 2) information input and output, and 3) monitoring Whois Related Each name's whois information will be validated by sending postal mail and email to contact supplied in the whois output of the "key" domain's registry. The XO will obtain this whois, combine it with the OIA (optional additional information), and perform the validation. It will transmit the whois to the RO so that the RO can serve it in its "fat registry" whois output. The XO will monitor the whois for those names that appear in the sTLD zone file at other registries/registrars. If the whois for the key domain changes, it will notify both the RO and the SO. The SO will make a decision as to revalidate it or not. It will archive the historical whois information. The XO will also monitor the key domain's zone for changes such as removal of the key domain from the zone. If a key domain is removed from the zone for its TLD, it will either be removed from the sTLD zone by the XO signaling the RO or by the XO making it inactive in its local name server (the one pointed to by the RO). Information Input and Output The XO will maintain a website, for example both at "www.example.com.mail" and "example.com.mail" that will serve as a place to input information from the registrant and to output information to the members of the Sponsored Community and the wider Internet community. On the output side, it provides the ability to examine the validated whois information for the domain as will as other information about the domain. On the input side, it gives the registrant (after passing security checks) the ability to input certain records that will be entered into the name servers of the XO for the domain in question. The "A" records (and other records) will be used by the email recipient server during the "HELO" SMTP process to help determine whether to let the message pass unencumbered. Monitoring The XO will also enter MX records into the name servers for each domain in the sTLD zone. These will direct all mail to mail servers in the control of the XO. These servers will accept only mail for the "abuse" email box for each domain, for example "abuse@example.com.mail". These messages will be monitored on a daily bases by SO personnel. They will use this information as well as other information, for example spam traps and other monitoring, to determine if the policies of the sTLD have been violated. If so, they will utilize tools built by the XO to remove the violators from the XO's (and sTLD zone) name servers.

V. Describe the location of facilities available to house staff and equipment necessary to operate the registry.

Registry Operator - Verisign, Inc. VeriSign Inc., headquartered in Mountain View, California, employs approximately 3,000 people and has an operational presence in more than 30 countries. VeriSign's operational infrastructure is in place and consists of secure data centers in Mountain View, CA; Dulles and Ashburn, VA; Seattle, WA; and Tokyo, JP. In addition, VeriSign leases secure data center space across the globe to house its international infrastructure. These locations and facilities are sufficient to house the staff and equipment required to provide the projected RO requirements of the sTLD. Sponsoring Organization - The Spamhaus Project The Spamhaus Project, based in London, England currently has a volunteer staff of 22 located throughout the world. Spamhaus' main infrastructure is located in England and it has servers distributing its free-real-time spam blocklist data located throughout the world. These servers answer over a billion DNS (via DNSBL) queries per day. The SO staff will be housed at their current locations which are distributed around the world, unless the need arises for a central location. If so, that location would be London, England. The staff's equipment which will predominantly consist of desktop computers that interface to the RO and SO datacenters will be co-located with each staff member. Extra Services Operator - eNom, Inc. eNom's has a total of six data centers throughout the U.S. with one in the U.K. These are: San Jose, CA; Seattle, WA; Dallas, TX; Washington DC; Chicago, IL and London. These datacenters are highly secure with physical security: badge readers with PIN, security cameras, escorted access and guards. The primary datacenter in San Jose, CA houses the main OLTP database, eNom.com web site, our reseller API and other key systems. Each of the datacenters offer abundant space available to us for housing additional servers as necessary. eNom's business, development and operations staff are located in Bellevue, WA. eNom's existing staff at this location consists of over 50 employees. eNom has at its disposal additional space in its current facilities available for XO use. Any additional staff that may be required, though none is anticipated, would be situated in this location. These locations and facilities are sufficient to house the staff and equipment required to provide the projected XO requirements of the sTLD. More detail regarding the equipment required is contained in "Part C Business Plan - Registry Requirements III"

VI. Commercial general liability insurance. Include the name and address of insurer/provider, amounts of insurance policy and, in general terms, the coverage of the policy, and any plans for obtaining additional insurance.

The XO has commercial general liability insurance provided by the Chubb Group of Insurance Companies, Federal Insurance Company, 15 Mountain View Road, Warren, NJ 07059. The amount of the policy is $1,000,000.00 per each occurrence, with an aggregate of $2,000,000.00. The RO similarly has commercial general liability insurance required by the RO’s various agreements with ICANN. If this sTLD application is granted, the SO will be formed and will apply for insurance for its own part. The XO and RO are financially stable companies with a proven track record; it is anticipated that the XO and RO will be able to provide sufficient information to private insurers to allow the insurers to evaluate the risks posed to the respective parties, thereby allowing the insurers to increase the levels of insurance, if necessary, and to allow the SO to obtain an appropriate level of insurance for its part. As time passes and the new sTLD develops a liability history, it will be desirable to review the insurance requirements. The Compliance Review and Monitoring Fee has initially been set high enough to cover potential premium increases. As stated in section h., upon award of the sTLD, The ANTI-SPAM COMMUNITY REGISTRY and VeriSign will work together to acquire, put into place and maintain (including payment of premiums) all insurance policy(ies) appropriate for registry operations of the sTLD, consistent with best industry practices.

Business Plan - Registry Requirements

I. Revenue model. Provide a full description of the revenue model, including proposed rates to be charged for various registry services. Revenues should be forecast at low, medium, and high projected levels of demand.

All revenues come from the per-name fee, which, for legal reasons, is split into two parts. One is for the registration itself, which is free, and the other is for the validation and policy monitoring service (the "Compliance Review and Monitoring Fee"), which we propose will cost $1,995 per name-year. Registrants cannot register names without purchasing the validation and monitoring service. The risk in the revenue model depends solely on whether or not businesses and other members of the Sponsor Community will purchase names. The idea is that they will want to purchase and use the names so that their email has a better chance of reaching its destination. The better job the SO does at ensuring that messages sent using the sTLD are spam-free, then the more members of the community will implement and adopt the technology, to let those messages pass unencumbered, which will increase demand for registrations in the sTLD. We have four data points that indicate there will be demand. 1) Many hundreds of thousands of users (domains that are used to receive mail), representing over 200 million email accounts, already use Spamhaus' SBL list, and the SO expects that many of these will adopt the sTLD approach. 2) Many members (thousands) of the community already purchase high-end digital certificates, used for non-email purposes, for around $1,000 each. 3) Our informal polling indicates that many companies will go to great lengths (effort-wise and financially) to ensure their email reaches its destination. They believe $1-2K per year to ensure that corporate mail (if they follow the no-spam rules) will have a better chance to reach its destination is a relatively small price to pay. 4) Comparing to another TLD: one of the highest-priced top-level-domains is ".tm". These names are offered at $100 per name year, with a minimum 10-year registration, for a total of $1,000 each. According to domainworldwide.com, there are over 3,000 domains in the .tm zone. Therefore the SO believes that members of the spam policy software, ISP communities, and mail server software communities will adopt the use of the domain as a method to let mail sent using the domain pass through unencumbered. Low Level Demand Projection 1,000 domain name-years At this first-year level, $2M in revenues will be generated, along with a $100K commitment in startup funding, means $2.1M income is available for the first year. $500K goes to the RO, $715K to XO, and $65K to ICANN, leaves $815K budgeted for the SO. Salaries account for approximately $400K of this, with the remaining $415K for legal, marketing, travel, capex, rent, and other, smaller expenditures, with $60K remaining for contingencies. This is the minimum registration level necessary for the SO to remain viable without cutting the projected staff level of five (at this demand level). It should be noted that Spamhaus, in the tradition of the Internet and "open source", maintains its user base of an estimated 200 million mail boxes with an international volunteer staff of 20 core staff members. Medium Level Demand Projection 2,200 domain name-years This is the demand level used in the Financial Model section for the first year. At this first-year level, $4.4M in revenues will be generated, along with a $100K commitment in startup funding, means about $4.5M in income is available for the first year. $500K goes to the RO, $1.87M to XO, and $141K to ICANN, leaving a $1.97M budget for the SO. Salaries for 7 staff members account for approximately $555K of this, with the remaining $1.4M for legal, marketing, HR, travel, capex, rent, and other, smaller, expenditures, and $800K left over for contingencies. The SO, at this demand and price level, is easily sustainable. High Level Demand Projection 4,000 domain name-years At this first-year level, $7.9M in revenues will be generated. $500K goes to the RO, $3.61M to XO, and $257K to ICANN, leaving a $3.61M budget for the SO. Salaries for about 16 staff members account for approximately $1M of this, with the remaining $2.6M for legal, marketing, HR, travel, capex, rent, and other, smaller, expenditures, and about $1.66M left over for contingencies. At this demand level the SO may begin to lower the price, either for the initial and follow-on years or for only the follow-on years. At a medium demand level and at a $1,995 price level, the SO believes that 4,000 registrations will be registered by the end of the 2nd year.

II. Resources required to meet demand. Provide an estimate of all resources including financial, technical, staff, physical plant, customer service and any other requirements to meet demands, at low, medium, and high demand levels.

At all demand levels, the RO performs all physical plant operations (except for the SO's in-house physical plant that would be required to support the staff of the SO of less than 16 people, which are in the estimates below) for a fixed fee. The RO fee may increase but not until volumes exceed four times the highest demand level, then contemplated at a variable fee of $30/name until 50,000 names are registered at which point the RO fee is $6/name-year. The RO also performs all customer service and the other services listed in the Technical Specification and Business Plan. The XO performs all the extra-registry operations required, and maintains and services its physical plant to do so. The XO's fee is a variable fee that is proportional to the number of names registered. The estimates below that are not specifically for the RO, XO or ICANN apply to the SO itself. Low Demand Level (Dollar amounts in thousands) Staff (5)..........................$400 Marketing..........................$100 RO.................................$500 XO.................................$715 Finance, HR, Insurance, Other.......$45 Legal Services......................$50 Travel..............................$30 Rent & Utilities....................$75 Hardware, Software and Supplies.....$55 ICANN...............................$65 Contingency.........................$60 Total.............................$2095 Medium Demand Level (Dollar amounts in thousands) Staff (7)..........................$555 Marketing..........................$100 RO.................................$500 XO................................$1873 Finance, HR, Insurance, Other......$120 Legal Services.....................$200 Travel..............................$30 Rent & Utilities...................$112 Hardware, Software and Supplies.....$55 ICANN..............................$142 Contingency........................$801 Total.............................$4489 High Demand Level (Dollar amounts in thousands) Staff (16)........................$1005 Marketing..........................$300 RO.................................$500 XO................................$3611 Finance, HR, Insurance, Other......$125 Legal Services.....................$200 Travel..............................$30 Rent & Utilities...................$152 Hardware, Software and Supplies....$140 ICANN..............................$258 Contingency.......................$1659 Total.............................$7980

III. Plans for acquiring necessary systems and facilities. Describe plans for acquiring all necessary systems and facilities for providing the proposed services at each estimated demand level. Provide details as to the scope, cost, and vendor for any significant planned outsourcing, as well as brief detail on such vendor's capabilities.

The following applies to all (low, medium and high) demand levels. Registry Operator (RO) – Verisign, Inc. The o