contact us about us
ICANN APPLICATION

Namestrings and Conventions

First sTLD choice: .mail
Naming Conventions:
The names registered will be of the form "key.mail" where "key" is of the form
"sld.tld" and where "tld" is an ICANN top-level-domain with certain attributes
and where "sld" is a second-level-domain which is already registered in "tld". 
The registrant of the "key" domain must be the same as for "key.sTLD"

Second sTLD choice: .tmail
Naming Conventions:
The names registered will be of the form "key.tmail" where "key" is of the form
"sld.tld" and where "tld" is an ICANN top-level-domain with certain attributes
and where "sld" is a second-level-domain which is already registered in "tld". 
The registrant of the "key" domain must be the same as for "key.sTLD"

Third sTLD choice: .mta
Naming Conventions:
The names registered will be of the form "key.mta" where "key" is of the form
"sld.tld" and where "tld" is an ICANN top-level-domain with certain attributes
and where "sld" is a second-level-domain which is already registered in "tld". 
The registrant of the "key" domain must be the same as for "key.sTLD"


Sponsoring Organization Structure
The Sponsoring Organization (SO) represents the community of individuals and
companies who wish to receive spam-free email and individuals and companies who
wish to send spam-free email and who do not want to be blocked, filtered or
inconvenienced when doing so.  The proposed sTLD will be limited for use by the
registrant only during the process of sending email. 

The function and mission of the Sponsoring Organization is solely to set policy
and rules for the names in the TLD and to deny entry into the zone or to remove
those names from the zone that violate those set policies and rules.  The
policies and rules are designed to insure the community that emails sent using
domains in this sTLD can be trusted to be spam-free.  

The SO will be a not-for-profit organization. The name of the SO is “The
Anti-Spam Community Registry”.  The SO will sub-contract to the Registry
Operator (RO) all of the typical registry operations (registration, zone file
generation, etc).  Because this proposal requires extra-registry services, the
SO will also subcontract another organization to perform these non-typical
services.  We are calling that organization the “extra services operator” (XO).
 Both the RO and XO are existing for-profit companies with many years of
experience in the Internet and domain name industry. Details of the duties and
capabilities of these organizations are presented later in the proposal.

Since the SO represents the community of senders and receivers of spam-free
email, it will consist of a board of advisors who each represent parts of this
community.  

For example, The Spamhaus Project, the founding member of the SO, represents a
very large number of organizations who, by virtue of their using the Spamhaus
Block List (SBL), have endorsed Spamhaus’ ability to aid them in determining
which email is spam and which is not. The SBL is used on approximately
200,000,000 email accounts worldwide, on millions of domains.  Looking at these
numbers and the fact that the blocklist receives over one billion queries per
day (not counting the high-volume users who transfer the zone and query it
locally) Spamhaus, by itself, represents a very large segment of the community.
This community will be represented on the SO board by Steve Linford, the
founder of Spamhaus, and who was recently named by the ISPA (The Internet
Service Providers Association of the UK at ispaawards.org.uk) the “United
Kingdom’s Internet Hero of the Year in 2003” for his tireless work in helping
define responsible emailing practices and encouraging the Internet community to
implement systems to make it so. 

All the board members will use their knowledge in their particular fields to
create and modify the policies of the sTLD using the procedures of policy
development of the SO.  Special advisors will also be used from time to time to
advise the board on relevant topics, to recommend policies and to recommend
additional board members from their field of expertise.  

Spamhaus personnel will help populate the staff of the SO, and will, on a daily
basis, be the ones to validate and enforce the sTLD’s stated responsible email
policies.  They will use the technology and tools provided by the XO and the
RO, combined with their expertise, and the policies of the SO, to accomplish
this task.

This sTLD will have all customary policies which apply to all other ICANN gTLD
registries, for example deletes and RGP.  The board will oversee the
email-specific, whois-specific polices and other policies that make this TLD
unique.  The SO will follow all ICANN directives and will not offer any other
registry services that are not detailed in this proposal or that do not assist
in the mission of the SO.  The SO, using 1) the rules, policies and procedures
outlined in this proposal (rules such as each name must have validated whois
contact information, and must have messages sent to abuse@key.sTLD received by
the SO, not the registrant) and 2) their knowledge of responsible emailing
practices and 3) their knowledge of those specific individuals and
organizations who violate those practices, will determine which domains are
accepted or removed from the zone.  Much in the same way that Spamhaus’ SBL
has, over the past years, gained the trust and acceptance of a large segment of
the world’s email providers so that it is now protecting an estimated 40% of
all active email accounts, the similar activities and participation of Spamhaus
will help the SO insure the trust and acceptance of this sTLD by the same large
segment of the world’s email providers (senders and receivers).  

The SO’s policy enforcement operations are carried out on a daily basis as is
required by the very mission of this sTLD, primarily centered around adding
names to the zone that comply with the policy and removing names from the zone
where the registrants have violated the policy.

Policy-formulation and modification activities will consist of quarterly
meetings, either in person or by teleconference, of the board of advisors and
other experts when needed.  These meetings will take as input an SO-maintained
publicly accessible email list where suggestions to improve the implementation
of the mission of the sTLD will be solicited.  Unlike a gTLD, the SO, due to
the sTLD’s designed technical structure, is in a unique position to receive all
abuse messages for each domain.  These messages are submitted to the SO from a
part of the community this sTLD represents (mail recipients).  These abuse
messages, in aggregate (besides each being used in the daily operation of the
sTLD policy enforcement), will be used by the board to both insure the
operation of the sTLD is following its stated polices and to aid in refining
policies where the need arises.

Appropriateness of Sponsored TLD Community
The Sponsored TLD Community is defined as responsible senders and receivers of
spam-free electronic mail.  

The Sponsored Community, although large, does not include senders of spam. For
the purposes of this community, the definition of spam is an electronic message
that is considered to be Unsolicited Bulk Email ("UBE").

(1)Bulk means that the message is sent as part of a larger collection of
messages, all having substantively identical content, of which the recipient's
personal identity and context are irrelevant because the message is equally
applicable to many other potential recipients; AND
(2)Unsolicited means that the Recipient has not verifiably granted deliberate,
explicit, and still-revocable permission to receive the message.

A message is defined as spam only if it is both Unsolicited and Bulk.  This
distinction is important because either unsolicited email or bulk email, on
their own, is not classified as spam under this definition.

* Unsolicited Email is not spam (examples include first contact enquiries, job
enquiries, sales enquiries, etc.)

* Bulk Email is not spam (examples include subscriber newsletters, discussion
lists, information lists, etc.).


Many people suffer the costs of spam which includes wasted time, wasted
capacity (cpu, bandwidth and storage), wasted manpower, hassle and aggravation.
 These people (who receive spam) have in front of their email client a mail
server that receives email.  The operator of this receiving email server and
the operator of the server that sends the email are the core community of
technical people for which the sTLD is intended. The sTLD is designed for mail
server operators who follow “the rules” to be able to identify each other.  The
sending server operator registers a name in the sTLD and the receiving server
operator uses the DNS to lookup information (IP address and other information)
about the name and hence the sending server.  Using this information, the
receiving server can easily determine if the sending server is spam-free, as
well as determine if the email was forged.  Also, using this sTLD, this
community (these technical people to a large extent, but also the public) can
send abuse messages to the domain and be assured that their message will not be
ignored because all abuse messages are received by a third-party (the SO), not
by the suspected abuser.  

No email messages will be seen to come from the sTLD, so that the public (the
non-technical people using email) will not know that the mail servers used the
sTLD.  These people will see no change whatsoever in the email in their inbox. 
The domains in the “from”, “to”, “reply-to”, and other data elements of the
email header will not include domains in the sTLD. The sTLD is behind the
scenes. The public will continue to see, for example, the domain “example.com”
being used.  However, as the sTLD becomes better known to the public, they will
become aware that they can simply type “example.com.mail” or
"www.example.com.mail" (just add the easily remembered ".mail" to the end of
any domain) into their browsers at anytime to obtain information regarding the
registrant and its email practices, or to send abuse mail simply use
"abuse@example.com.mail".  

Law enforcement, internet service providers and the intellectual property
communities are also served due to the fact that all the whois information for
each sTLD domain is validated and carries a paper trail (of postal address and
email confirmation). This accurate whois verification benefit will also now
apply to all the other TLDs, for example “.com”, due to the fact that the
registrant of “example.com.mail” is the same registrant as “example.com”.

As more and more receiving mail server operators, MTA (Mail Transfer Agent)
programs, and email policy programs (email filters) learn that mail sent using
the sTLD is spam-free, it will build trust in the sTLD so that more operators
will obtain domains in the sTLD and will let the spam-free mail pass
unencumbered.


Therefore, the sTLD’s main community is those core technical people who operate
mail servers that send and receive email, while the sTLD also serves the much
wider community.


The benefit to the broader community is that this sTLD facilitates the
unencumbered delivery of spam-free electronic mail communications for those
members of that community that choose to use it  either directly or indirectly.

The community of email senders and receivers is long-lasting because email is
here to stay.  People all over the world send email. It is geographically
independent.  Sadly, the desire and ability of a segment of mailers to send
spam will be with us as long as email exists.  This sTLD can greatly help solve
the major problem of this community; and because the SO generally represents
this community, then this sTLD is worthy of delegation to the SO for the
purposes of helping to solve the problem.

Representation
The SO represents the community because each member of the board represents
different sub-communities within the sponsored community.  It is self evident
that each of these communities has an interest in the unencumbered flow of
spam-free email and as such are all stakeholders. 
These sub-community categories are:

1) The community comprised of anti-spam advocacy groups and individuals
2) The community comprised of individuals and companies involved in the
creation of email-policy programs (anti-spam email filter software) and
systems.
3) The community comprised of individuals and companies involved in the
creation of email server software and systems
4) The community of university based network and email systems researchers
5) The community of internet service providers and large mail recipients

Each board seat will represent one of these sub-communities, for a total of
five board seats.

Special advisors who may also provide input or expertise to the SO may also be
selected from time to time.  These will be people who are active in the
Anti-Spam, email server, email policy, ISP, or spam-research arenas or from the
broader Internet community.

The following five entities are examples that the proposers believe could
contribute individuals, well known to the community, who would represent the
above five sub-communities at the SO board level:
1) Spamhaus.org, a worldwide anti-spam advocacy group based in the UK that is
trusted to protect over 200 million email accounts (estimated to be 30-40% of
the world's active email boxes)
2) SpamAssassin, the creators of one of the most popular email policy program
(email filter)
3) Sendmail, a leading mail server software
4) University of Oregon, a leading spam research institution
5) Outblaze.com, the world's leading outsourced email provider

To date, not all of these entities have committed to participate at the board
level.  Please refer to "Part B Application Form Initial Directors, Officers
and other Staff" for the list of board members and special advisors.

Since the goal of this sTLD is to aid in the unencumbered transmission of
spam-free email and to benefit email messaging into the future, input from the
community will be a vital and an integral part of the SO.  

Input Mechanisms 
1) An email list (discussion forum) will be setup so that any and all people
who consider themselves members of the community can easily communicate their
thoughts, ideas, suggestions, improvements and comments which the board will
review and make policy modifications based on this input.  The messages on the
email list will be made public via an SO website.
2) Also, a unique attribute of this sTLD is the input channel afforded to the
community by the implementation of a centralized email abuse messaging system. 
Because the SO controls the name server records for every domain, it will place
an MX record for each domain in the name servers, and this MX record will point
to a mail server under the control of the SO, and in the mail server the SO
will setup an “abuse” (and "postmaster" required by RFC 2821 & RFC 2142)
account for each domain.  Therefore, the SO will receive all abuse messages for
every domain sent by the broader community.  This input will be used in two
ways, first, on a daily basis to help determine any violations of the policies
of the sTLD, and second, as input, in aggregate, to the board of the SO to help
them determine future policy changes.
3) Polling will also be used to gauge the community on various issues of
interest 
4) The special advisors will also provide input in their areas of expertise

Informational services:
1) Each domain’s website will be controlled by the SO.  These sites will
display information regarding the registrant, for example, the registrant’s
contact information that was verified by the SO.  
2) On the main SO website, there will be information regarding implementation
of the sTLDs system across the entire spectrum of technology expertise. For
example, how to use the sTLD with mail servers such as Sendmail, Exchange,
QMail, or Postfix, email policy enforcement software such as SpamAssassin and
“how-to” information for registrants as well. 
3) The main SO website will also contain areas to provide up to date
information on activities regarding the sTLD.


In summary, we will provide the following community communication mechanisms:

1) Public open discussion forum
2) Abuse messages.
3) Polling and Special Advisors
4) Registrant’s informational website.
5) “How-to” informational website
6) Updates informational website.

Openness and Tansparency
The founding member of the SO, Spamhaus, has been a proponent of openness on
spam issues since its inception in 1998, and will insure this tradition
continues at the SO.  The Spamhaus.org website is probably the most referenced
repository of information on spam issues and spammers.  Spamhaus has felt that
openness and transparency helps the people who know there is a problem identify
the causes of the problem and the possible solutions.

The SO will allow public access to all meeting minutes.  Comments on policy
changes will be welcome and the input will be used to refine the policies where
needed.  The goal of this sTLD is to best serve the needs of the responsible
emailing community and the SO acknowledges that the input from the community is
the most important factor in determining how to implement and make changes to
the system and its policies in the future.

The SO will post public notice on the SO website explaining what policies are
being considered for adoption and why.  It will provide a reasonable
opportunity for parties in the community to comment on the adoption of the
proposed policies, to see the comments of others, and to reply to those
comments.

The following types of information will be published:
1) On the main SO website:
a. Mission statement of the SO
b. The policies of the SO and the sTLD registry
c. Detailed instructions and a FAQ on what is needed to obtain a domain in the
sTLD
d. Detail technical documentation on the correct usage of the domain to email
applications.
e. Board meeting minutes
f. Updated archive of the public forum email list
g. Latest events and news regarding the sTLD which would include changes and
additions to the board, links to stories in the press, etc.
h. The ICANN accredited registrars who are certified to make registrations in
the sTLD with links to their websites.
i. An admin tool for certified registrars and instructions on how to obtain
certification for ICANN accredited registrars.

2) On the registrant website:
a. Verified contact information for the registrant
b. Current status of the domain, for example if the domain has been removed
from the zone for a policy violation, a count of the number of days until the
registrant can reapply.
c. Abuse reporting procedures and addresses
3) The zone file
4) Whois information, via web and port-43 that follow all ICANN and IETF
specifications and directives

There may be certain details in the policies concerning the detection of
violations process that the SO will not make public because knowledge of the
underlying methodologies can be used by spammers in an attempt to circumvent
detection.

Initial Directors, Officers, and Other Staff
The initial board of directors will consist of:

Steve Linford, founder of Spamhaus.org, Representing Anti-Spam Advocacy.  

Linford was born in England. After moving to Rome and dropping out of
photography school, Steve purchased a motor home, parked it on beaches and made
his living by playing guitar in coffee shops. When artists such as Pink Floyd
toured Italy, Linford served as their road manager. 
In 1986, Linford drove his motor home to England where he set up a company with
the purpose of putting musical tours online. Then Linford started a web page
design and hosting business, called Ultradesign Internet.  After getting fed up
with receiving spam, he became an anti-spam activist. In 1998, he started the
Spamhaus project. Currently his spam list is used by many Internet providers
that collectively serve more than 200 million email accounts. 
Hero of the anti-spam movement, Steve Linford is a man on a mission. His
Spamhaus organization identifies and tracks the worst bulk emailing offenders
and works with ISPs to block their incessant traffic. Testimony as to how
successful he's been comes from an unlikely source - the spammers themselves.
His message is clearly getting through - and as a result, theirs aren't.


Joseph E. St. Sauver, Ph.D. Representing University Based Network and Email
Systems Research Community

Dr. Sauver is the Director, User Services and Network Applications (since 1987)
at the University of Oregon.  Dr. Sauver manages 17 professional staff plus
numerous part time student employees. Examples of his recent
research/writing/presentation work include:
* "The Open Proxy Problem: Should I Worry About Half a Million Trivially
Exploitable Hosts?" NLANR/Internet2 Joint Techs, August 2003. Following that
presentation and related efforts, the FTC announced creation of Operation
Secure Your Server (January 29, 2004)
* "Practical Issues Associated with 9K MTUs" NLNAR/Internet2 Joint Techs,
February 2003, Following that presentation and related efforts, the Federal JET
adopted a public policy endorsing increasing the MTU on the federal mission
networks (DREN, ESNET, NISN/NREN, etc.) to 9000 bytes.
* The November 2003 issue of Network Analysis Times (the issue distributed at
Supercomputing) included his piece regarding IPv6 measurement initiatives he is
involved with
* The March 2004 printed and online edition of Syllabus Magazine featured his
article, "What Are Portalized University Home Pages Rare?"
* Invited to facilitate the October 2003 NWACC Single Sign On Workshop at Reed
College
* Presentation "Winning the War on Spam" for NWACC in June 2003 
* Invited to speak at the 2004 Cornell/Educause Institute for Computer Policy
and Law
* Dr. Sauver was invited to sit on, and participate in the Internet2 Abilene
Network Technical Advisory Committee as well as a variety of other
Interne2-related groups such as the new SALSA (Security at Line Speed) advisory
group.
Dr. Sauver also performs private consulting for a variety of ISPs and
government agencies.  

At the time of this application, three board seats are yet to be filled.

Once this proposal is communicated to the wider community, we expect members of
the community to step forward and express their willingness and qualifications
to serve.  The existing board members will also actively recruit additional
candidates from the following non-exhaustive list: 

John Levine  
Chairman of the Anti-Spam Research Group (ASRG) of the Internet Research Task
Force (IRTF)
The IRTF focuses on longer term research issues related to the Internet.  Since
late 2003 John has been co-chair of the Internet Research Task Force's
Anti-Spam Research Group (ASRG, asrg.sp.am). He has re-chartered the ASRG,
established informal contacts with large Internet providers, and set up new
working groups.  Since 1997 he's been a board member of the Coalition Against
Unsolicited Commercial E-mail (CAUSE, cauce.org), a user advocacy group. He
also runs the Network Abuse Clearinghouse (abuse.net), a popular free service
that helps Internet users report and deal with on-line abusive behavior. John
has written or co-authored over twenty books, from the best selling Internet
for Dummies, now in its ninth edition, to technical works on compiler and
graphics software.

Wietse Zweitze Venema, Ph.D. 
A lead technologist behind Postfix 
Most people know Dr. Venema from software that he wrote to protect systems
against Internet intruders. He continues this fine tradition with IBM, at the
Thomas J. Watson Research Center, in the USA. The first result is Postfix. This
is mail server software that aims to be fast, easy to configure, and has a
reputation as being very secure. A second result is the Coroner's Toolkit,
written with Dan Farmer, primarily for the post-mortem analysis of computer
break-ins. Dr. Venema was awarded with the SAGE 1999 outstanding achievement
award, and with the NLUUG Award 2000 in recognition of outstanding achievements
for the users of UNIX and Open Systems.  In June 2002 he reached the legal
limit on his term as chair of the FIRST, an international association of
computer security teams with over 100 members world-wide in government,
industry, and academia. Previously he studied physics at Groningen University
in the Netherlands, where his Ph.D. dissertation was on work done at the KVI.
He spent 12 years at Eindhoven University, the Netherlands, as systems
architect at the Mathematics and Computing Science department. For 8 years,
part of that time was devoted to writing tools for automated translation of EDI
(Electronic Data Interchange) messages. 


The two preceding candidates have already consented to be special advisors to
the SO

Justin Mason or Daniel Quinlan of SpamAssassin.org
SpamAssassin, representing the most widely used open source end-user email
policy enforcement software, is also participating in the SO.  Based on
SpamAssassin’s wide use and acceptance they are both well suited to represent
the even wider constituency of email policy (spam filter) users on the SO board
of advisors.


Eric Allman of Sendmail.org
Sendmail, representing the most widely used mail server software (MTA mail
transport agents) would be a good candidate.  Based on Sendmail’s wide use and
acceptance, Eric Allman is well suited to represent the even wider constituency
of email mail server users on the SO board of advisors.


Ted Galvin of SpamCon.org
SpamCon.org is one of the primary anti-spam advocacy groups.  Ted's presence
would be to insure that anti-spam advocacy group’s voices are heard.


Suresh Ramasubramanian of OutBlaze.com 
Manager, Outblaze Security & Antispam Operations and Coordinator, CAUCE Asia
Pacific (APCAUCE)
Suresh's presence would be to insure that both large email service providers
and the international anti-spam advocacy group’s voices are heard.


SpamAssassin and Sendmail can help the world-wide implementation of the gTLD
system by modifying their systems to allow mail using domains in this sTLD to
pass in an unencumbered manner to the recipients.

CAUCE.org and SpamCon.org, in their normal advocacy endeavors, will help
popularize the ideas behind this proposed system (and sTLD) to ensure the
delivery of responsible email.  


SO Staff
The SO staff will be supplied by the Spamhaus organization.  Currently there
are twenty members on staff at Spamhaus.  These staff members, who are located
in a number of countries spanning several continents, are highly qualified in
the field of spammer identification and crafting responsible email policies due
to their many years of experience in the field.  Many have advanced degrees and
detailed technical knowledge of DNS, mail and other protocols.  The members of
the staff have existing contacts with law enforcement including The US Secret
Service, The Federal Trade Commission, The FBI, The SEC, The IRS, Scotland
Yard, Interpol, and many US State Attorneys General and local law enforcement. 
Spamhaus staff members also have been at the forefront of legislative
activities regarding spam with various governments.  In their current everyday
duties they also interface with network administrators from all tier-1 and many
other tier Internet service providers.

Selection of Directors, Officers, Members, Staff
Each director must have a long history of service in the sub-community that
they represent and must have overwhelming respect of their peers.  The five
sub-communities are:

1) The community comprised of anti-spam advocacy groups and individuals
2) The community comprised of individuals and companies involved in the
creation of email-policy programs (anti-spam email filter software) and
systems.
3) The community comprised of individuals and companies involved in the
creation of email server software and systems
4) The community of university based network and email systems researchers
5) The community of internet service providers (or large email recipients) 

The initial board has been selected, except for a representative from the ISP
sub-community.  Any vacant seats, whether by removal or resignation, will be
filled by nomination and election by the current board. There is no
geographical diversity requirement as to the board member’s home country
location.  The SO believes diversity of geographical locations is beneficial
but also seeks the best qualified candidates that represent the various
sub-communities. Candidates must be nominated and seconded by two different
board members. Vacancies will be filled within three months of the vacancy. The
nominees must carry 2/3 of the vote of the members in order to be elected.  All
voting may be conducted electronically. Spamhaus, as the founding member, and
representing the anti-spam advocacy group with over 40% of all email boxes
deferring to their judgment, has a permanent seat and cannot be removed, and
receives an additional vote during votes that result in a tie.  A board member
can be removed by a 2/3 vote of the other members.  As discussed, below,
changes in the number of board members may only be made by a change to the
Articles of Incorporation, which would require a 2/3 vote of the members.  The
initial term of service is the same as the initial term of the contract.  Any
board member who wishes to resign must submit a letter of resignation to the
board.

Directors, board members, officers, and staff have a duty to recluse themselves
from any votes or decisions where there is a conflict of interest.   Each board
member, officers, and staff, must disclose any material fact that may be
interpreted as a conflict of interest.  The board or committees of the board
may take action from time to time to appoint officers and staff, following the
procedures outlined below in the section titled "Policy-Making Process."

Compensation will be commensurate with directors at similar non-profit
organizations.

Meetings and Communication
The board will meet at least once per quarter.  Meetings can take place by
teleconference or in person.  The date, time and location of these quarterly
meeting will be communicated to all board members at least 30 days before the
meeting.  The board can call other teleconferencing meetings with a 2/3 vote,
if desired.  Minutes will be taken by an SO staff member and made available at
the SO website within 10 working days from the end of the meeting.

Fiscal Information
The Sponsoring Organization is newly formed.  We estimate an initial SO staff
of 2 (before delegation is made) will be required.  We project this to increase
to 7 in the first year and 16 in the second.  These staff members will be
mostly coming from Spamhaus’ existing staff and augmented by new hires.  Please
see the business plan and the financial model for estimation on the annual
revenue and costs.

The RO is a public company and has an existing staff of over 3,200 employees,
and the XO has an existing staff of over 50 with revenues of over $25 million.

Indemnification from Liability
It is anticipated that, with respect to indemnification from liability, the SO
will follow the contractual example set by other registries.  The SO will enter
into a registry agreement with ICANN.  ICANN accredited registrars will (or
have already) entered into Registrar Accreditation Agreements (“RAA’s”) with
ICANN.  Those Registrars that wish to sell domain names in the sTLD will enter
into an RAA appendix (“RAA Appendix”) with ICANN as well as a
Registry-Registrar Agreement (“RRA”) with the SO. These documents will follow
accepted industry language with respect to the following:

• Registrars shall be required to defend and hold harmless ICANN, the SO, the
RO, and the XO, (including employees, directors, officers, representatives,
agents, shareholders, and affiliates of all such entities) against any cost
(including court costs and attorney fees) claim, suit, action, or other
proceeding brought against such parties relating to any product or service of
the registrar, relating to any agreement between a registrant and a registrar,
or relating to the registrar’s domain name registration business (including
fees, advertising, customer service, and other business practices).  There will
also be a limitation of liability provision precluding special, indirect,
incidental, punitive, or consequential damages, and limiting the SO’s, the
RO’s, and the XO’s damages with respect to the registrars to be no greater than
specified performance credits to be granted should certain defined
circumstances occur.  The registrars will be required to bind the registrants
to substantially identical indemnification and limitation of liability
provisions, except that the limitation of liability (in addition to precluding
consequential damages, etc.) shall limit liability to registrants to no more
than the amount paid by the registrant for the Compliance Review and Monitoring
Service Fee.

• Registrars shall be required to carry insurance in the amount of
$1,000,000.00 to ensure the registrars ability to meet the requirements of the
indemnification provisions and to protect the named parties in the event that
the registrar fails to bind registrants to some or all of the required terms.

• Registrars shall be required to implement the policies of the registry and
the policies established by ICANN with respect to WHOIS, UDRP, transfers, and
such other policies as may be established through ICANN’s consent procedures
from time to time; however, there will be the special requirement that the
WHOIS, UDRP, and other decisions with respect to the Key Domain(s) shall apply
to domains in this sTLD.

• The precise language of the RRA and RAA Appendix will follow the form of
language found in agreements such as the .us Registry-Registrar Agreement.

• Contracts relating to this sTLD will include additional language requiring
that registrars require registrants to agree to the following terms:
  a) Registrants shall acknowledge that they have no property rights in domain
names in this sTLD and to acknowledge that the listing of domain names in this
sTLD is strictly a service;
  b) The registrants will be required to acknowledge that the SO has the sole
and complete discretion to evaluate the registrant’s application and continued
compliance with the sTLDs policies according to criteria established by the SO,
criteria which, similarly, are the sole and complete province of the SO to
establish and modify from time to time;
  c) The registrants will be required to agree to the following arbitration
related terms: to binding arbitration in the jurisdiction of the SO regarding
any dispute relating to interpretation of the service agreement; that the
decision of the SO regarding the listing or de-listing of a domain name in the
zone would remain undisturbed during the pendency of the arbitration
proceeding; that each party would have to bear its own costs in the arbitration
up to the point of the decision; that the looser in the arbitration would have
to pay the costs of the winner, up to a specified cap; and that both parties
would have to post a bond sufficient to ensure payment to the winner.

Because of the unique nature of this proposed sTLD, in which registration of
the Key Domain in another TLD is a pre-requisite, many of the legal and
liability concerns which relate to other TLDs do not apply to this sTLD.  For
example, UDRP arbitration proceedings would never take place with respect to
domain names in this sTLD because the WHOIS listings as well as the management
control of domain names in this sTLD would follow the designations established
by UDRP, judicial, or other proceedings which apply to the Key Domain in the
other TLD.  

Because of the unique functional nature of this proposed sTLD, there will be
complaints surrounding the de-listing of domains from the zone of this sTLD. 
For the reasons discussed below, this leads to the requirement for the
arbitration process, referenced in paragraph c), above, which is unique to this
sTLD.

In terms of complaints regarding de-listing actions (or refusals to list a
domain in the zone), the complaining party would have contractually agreed that
the SO was the sole and complete authority, both with respect to evaluating the
registrant’s application and with respect to establishing and modifying the
application criteria.  However, when a first party pays money to a second party
in exchange for which the second party evaluates the first party according to
some criteria and then makes the results of the evaluation available to third
parties, then a claim can arise that the payment of money in exchange for the
evaluation creates an illusory contract unless the evaluation criteria can be
determined.  If the evaluation criteria cannot be determined, then a court
would not be able to inquire as to whether or not the promised evaluation took
place.  If a court agrees that the evaluation criteria are too indefinite to
form the basis of a contract, then one remedy might be to allow the registrant
to void the contract and obtain a refund of the Compliance Review and
Monitoring Service Fee.  However, it is likely that a court would look to
statements made by the SO to third parties who are meant to convince the third
parties to use the sTLD as a basis for accepting or rejecting email and that
the court would use such statements as a basis for performing its own review of
the evaluation criteria.  Under such a scenario, a court might review the
determined evaluation criteria, notwithstanding contractual claims that the
evaluation criteria are the sole province of the SO, and order that the Court’s
interpretation of the evaluation criteria be adopted by the SO.  Thus, under
“worst case” scenarios, potential outcomes would be either a rescission of the
contract and a refund of the Compliance Review and Monitoring Service Fee or
the imposition of the court’s judgment regarding the court’s own determination
of the evaluation criteria (as the court finds these in statements made to
third parties). 

To avoid this potential, remote as it may be, the language providing for
binding arbitration is to be included in the terms and conditions imposed on
registrants, as well as language limiting damages to the amount of the
Compliance Review and Monitoring Service Fee.  It is tempting to adopt
processes such as those defined in the usTLD Nexus Dispute Policy and Rules,
which, in many respects, are similar to the UDRP arbitration rules.   However,
spam is different from a trademark context, or even a .us nexus context,
requiring departures from the approaches of the UDRP or the usTLD NDPR. The
primary difference in the context of spam is that victims of spam individually
suffer a small harm from any one spammer; as a consequence, victims of spam are
insufficiently motivated to assume the cost of mounting an arbitration
proceeding against the spammer(s).  Under both the UDRP and the usTLD NDPR, the
complaining party must pay the cost of initiating the arbitration proceeding –
typically between $1000 and $1500 (US).  Also in the context of spam, action
would have to be taken immediately by the SO to de-list spammers.  If a third
party victim, such as an individual email user or an ISP, were required to
initiate an arbitration proceeding as a condition precedent to shutting down
spammers, then spammers could rapidly move to new domains with the sTLDs,
effectively circumventing the function of the sTLD and thereby destroying the
value of the sTLD for its community.  

As a consequence, the decision to de-list a registrant from the sTLD must be
made rapidly and the ultimate responsibility for the decision must rest with
the SO.  The principal of “looser pays” in the arbitration proceeding protects
registrants who may be de-listed without a substantial basis and it protects
the SO from disingenuous challenges.  The requirement of a bond ensures
recovery under the “looser pays” principal.  The commercial bonding industry
creates an economically efficient third-party private evaluation of credit
worthiness and risk, which moderates the burden of the bonding requirement
based on private, competitive, evaluation of such risk factors as the bonding
company believes are relevant.  As an example, if a legitimate company with low
risk factors feels that it has been de-listed by the SO without justification,
then a private bonding company would be willing to put up the bonded amount
with payment of a relatively low price, such as 10% of the bonded amount.  A
company presenting high risk factors and/or a weak claim would have to pay a
higher amount to convince a private bonding company to put up the bonded amount.

Proposed Extent of Policy-Making Authority
The need of the community that the SO represents is to send and receive
spam-free email.  The scope of the policy-making authority requested by the SO
is tailored to fit this need of this community.   

The policy decides who may register in the sTLD and under what circumstances
the registration may be revoked.  The SO seeks complete authority in
disallowing and removing names from the zone at anytime for violations of
policy.   The limits of the policy formation authority are in the area of
preventing spam and insuring that the sTLD is trusted.  “Trusted” means, for
example that the whois information is trusted to be valid and verified and that
messages sent using the sTLD are spam-free.  

To illustrate, the following are three examples: 
1) Because there is no need for the registrant to point the domain name to a
particular website, we are seeking the authority to point them all to a site
controlled by the SO 
2) Because there is a need for a third party to receive the abuse mailbox
messages, we ask that the SO have authority over each domain’s name server
pointers and the MX records therein so that all abuse messages are sent to the
SO.
3) Because an especially large need of the community is for each domain in the
zone to have accurate and trusted whois, we will be validating each whois
record before granting use of the sTLD domain.

The SO will have complete authority in determining the namespace in which
domains may be registered for this sTLD.  Initially, names will only be allowed
to be registered in the format, KEY.sTLD, where KEY is an already registered
domain of the form SLD.TLD where TLD is an existing ICANN approved TLD which
TLD has a contract with ICANN (for example “.com”, “.org” or “.biz”).  Any
names not in the form KEY.sTLD, except certain reserved second level names for
registry operations, will not be delegated without an approved change to this
policy.  The SO asks for complete authority over all DNS records placed in the
sTLD zone including but not limited to A, PTR, MX, wildcard, and TXT and other
records that are suitable for anti-spam or anti-forgery technology.  A wildcard
record may, for example, be inserted into the zone so that the SO can determine
which unregistered domains are receiving lookup attempts (are being forged).  A
wildcard record will not be used to generate revenue or point to a public
website.

Therefore, example policies/rules include:
1) Names registered in the TLD must be of the form key.sTLD, where key is of
the form SLD.TLD where TLD is an ICANN TLD from the following list: com, net,
org, info, biz, int, mil, gov, edu, and SLD is a domain name already registered
in TLD.
2) The whois information at SLD.TLD is validated by various methods (details in
other parts of this proposal)
3) The key domain must have been already registered for at least 6 months
4) All abuse messages for key.sTLD must be received by the SO
5) The website at key.sTLD will resolve to an SO-controlled web server and will
display information regarding the registrant and the domain (details in other
parts of this proposal)
6) When the registrant's email server (or an email server sending on behalf of
the registrant) connects to the receiving email server, it must greet the
receiving server with a HELO command of the format "HELO key.sTLD".  The
registrant must inform the SO of the IP's and hostnames of the sending mail
server using the website at key.sTLD.  The SO will enter A records in the DNS
for the domain, for example "hostname.key.sTLD in A 123.123.123.123"
7) spam must not be sent from servers whose IP match the IPs for the A records
in the key.sTLD name servers
8) registrants are encouraged to use sender authentication technologies such as
SPF, Domain Keys, and Caller ID.

Authority is not sought in the following registry services areas:
1) In the aftermarket or with products such as WLS
2) Wildcard record that implements Sitefinder or something similar
3) Email products such as that offered by the .name registry
4) Auctions, Landrush or Sunrise.  These are not necessary because only the
registrant of the name in another ICANN TLD can get the name in this sTLD. 
This fact also eliminates trademark disputes in this sTLD.

Though a higher registration fee is designed to further the mission of the SO
in reserving the namespace for non-spamming emailers, the SO requests authority
to lower the per name registration fees, either the initial registration year
fee, or follow-on registration years fee, if volume increase to the point were
the RO, XO, SO, ICANN and other costs are covered while maintaining the stated
mission.

The non-profit operation of the SO is, by its very nature, a structure which is
likely a better guarantor of following stated policy than for-profit
operations, because the profit motive is greatly diminished.  The high per-name
registration fee needed to register each domain is a guarantee that the SO will
be both able to do its registrant verification procedures and remain a viable
guarantor of the sTLD’s continued administration of the zone and perform the
stated mission of this sTLD.  Temptations to alter policy towards revenue
generation at the expense of the Internet at large are minimal because of both
the non-profit operation of the SO and a high per name fee factors.   Also,
after the normal initial registration 5-day grace period, the fee is
non-refundable (because the fee is for validation and monitoring services, not
for registration, which is free), therefore, there is no financial incentive or
pressure on the SO to violate its own polices by putting unqualified domains in
the zone.

The procedure that will allow the sponsored community to participate in policy
formation is as follows:  People who identify themselves as members of the
community can participate in the SO-maintained forum on policy development. 
This forum facilitates a back-and-forth exchange of comments and ideas between
the SO and the members of the community and between the members themselves. 
This forum will be monitored by the SO and the SO will post messages and
encourage dialog there if necessary.  Additionally, policy drafts will be
posted to the SO website and to the forum where after a similar back-and-forth
comment period on the SO policy forum, the SO board will take the information
into consideration before taking a vote and enacting the policy.

The SO does not intend to vary from any existing ICANN policy.  We observe that
the SO’s rules regarding valid whois may in fact enhance the enforcement of the
current ICANN policies around whois information for certain names because each
sTLD domain is tied to another domain in another ICANN TLD, so that when the
domain’s whois is validated, the whois for the name in the other TLD is
validated as well.

Policy-Making Process
The policy making process will consist of the decisions made by the board
members, including the decisions by the members regarding what processes the
members wish to follow with respect to all or specific policy decisions.  All
decisions by the board shall be made based on a majority vote of a quorum of
the board, except that a 2/3rd vote shall be required in the following
instances: the election of new board members, the removal of existing board
members, the addition or subtraction of board seats, or any change to the
Articles of Incorporation or By-Laws which would result in a change in the
voting control of any board member, or any determination by the board with
respect to whether an individual board member has a conflict of interest with
respect to a particular vote, such that such board member may not be allowed to
vote on the matter in question.  A quorum of the board is greater than half of
the board members.  There shall only be allowed to be an odd number of board
members.    

The board may delegate its authority to committees of the board, provided that
no committee of the board may elect or remove board or committee members nor
revise the Articles of Incorporation, the By-Laws, or the voting rules for a
committee (though committees may make recommendations to the full board in
regard to such matters).  No committee may be constituted other than by act of
the board.  Committees are governed by the same voting rules which apply to the
full board, except that committees may consist of an odd or an even number of
members and that any tie vote on a committee will not constitute an affirmative
vote by the committee.  The term "meeting" used in this "Policy-Making Process"
section refers to meetings of either the board or of a board committee and the
term "members" refers to members of either the board or of a board committee,
unless specifically stated otherwise.    

The policy making process will take place at the regularly scheduled meetings
and at such meetings as the members agree to hold from time to time.  The
members shall direct the maintenance of email fora or other similar
communication system(s) which shall apprise the public of the schedule of
meetings, the anticipated substance of the meetings, and the minutes of past
meetings.  The public shall be invited to use the communication system to
provide input on the schedule and substance of meetings or on other matters
that they believe of importance to the board.  Special Advisors can also be
called upon from time to time by the board to comment on policies and make
recommendations in their areas of expertise. Any action may be proposed by any
member and shall be considered by the other members if the proposed action is
seconded by another member.  Other than the regularly scheduled meetings which
must be scheduled at a previous meeting (regularly scheduled or otherwise),
meetings may only be called by a majority of members and shall be held after at
least 10 days notice, unless 2/3rds or more of the members waive the notice
requirement. As a result, action by the board or a committee may be considered
at any time when at least one-half the members agree to call a meeting and when
at least 2/3rds of the members agree to waive the notice requirement.  Meetings
may take place in person or through any media which allows an exchange of
information among all the members in substantially real-time. Email shall not
be considered "real-time," though chat shall be. The minutes of all meetings
shall be recorded and made available through the public fora no later than 10
days after the meeting.


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 operation of the registry function will use Verisign’s world class
infrastructure to provision and manage the sTLD domain names. The system is
completely automated and the current systems and architecture is sufficient to
take on the additional loads proposed by this sTLD as evidenced by the
technical description of services in section E.2. Management and operation of
the sTLD will be done from the RO’s three major Internet data centers located
in the continental United States. Even at the highest demand levels, the
current systems and staff that are in place are more than adequate to provide a
reliable, responsive and scalable solution.

Verisign prides itself on providing superior customer service. The support
facilities are currently sufficient to handle the additional requirements
proposed. The RO currently established support staff in the call centers and
email help desks will be provided any necessary training. The RO operations
team is also adequate in size and posture for taking on the additional
responsibilities of support and monitoring of all hardware and software
performance.

Extra Services Operator (XO) – eNom Inc.

The selected Extra Services Operator, eNom Inc., will be providing services for
fulfilling the duties of providing DNS services, Whois validation services and
domain name web site administration and hosting.
 
The DNS service is currently being performed by eNom as part of their regular
operations. The scale of the existing DNS infrastructure is currently of
sufficient size to easily accommodate the additional load, even at the highest
anticipated participation level. If demand were even higher than expected, each
of the systems is designed such that scaling out is an inexpensive operation
and only requires the acquisition of inexpensive hardware whose cost will be
taken by the XO in full.
 
The development and testing of the web site administration and hosting services
will be done by the XO with existing staff and will not require hiring of
additional personnel. Once established, the XO may hire two to four additional
web site developers to perform any ongoing development and maintenance of the
web sites for the sTLD.

The hardware requirements for the web site, hosting services and Whois
validation service are projected to be a typical set of servers for the
anticipated demand.  Ten web servers, four utility boxes for various
processing, two firewalls, network hardware for routing and a load balancing
appliance are the initial projected requirements. The costs for the hardware
will be burdened by the XO in full. This configuration is based on the
operational experience of eNom, who currently maintains six data centers and is
familiar with such provisioning of new services.

The acquired hardware will be housed in one or more of the XO’s six data
centers and will be determined before the sTLD is granted based on space and
bandwidth requirements. The costs for the provisioning of space, setup and
ongoing maintenance and bandwidth will be absorbed by the XO.

The small hardware and software required by the SO to perform its duties is
easily and quickly acquired just before it is required.

IV. Staff size/expansion capability. Describe plans for obtaining the necessary staff resources, capacity for start-up and expansion. Include description of hiring policy, employee training, space for additional staff, staffing levels needed for provision of expanded technical, support, escrow, and registry services.
SO
Initially the SO will be manned by Spamhaus Project staff. At the high demand
level, ten Spamhaus staff members will be required by the SO.  These staff
members are already in place at Spamhaus. If demand warrants, additional staff
members can be easily recruited judging from the high number of quality people
who regularly enquire about participating in Spamhaus' anti-spam mission and
are turned away.  All new staff members will be screened according to their
capabilities, be fully trained, and will be required to have proficiency in
their field at the time of hiring.

Standard staff contracts will be “at-will,” meaning no notice is required for
termination of service by the employee or by the SO.  Management level
contracts will generally be for two years, unless otherwise negotiated and
stated in writing in the contract.  Compensation will be competitive for the
market and field of the position.  Salaries and other compensation will be set
in the Human Resources manual with a base pay rate for each job title and
standard policies for level of proficiency pay raises.   

Bonuses may be awarded for performance and service and will be voted on and
determined by the Board.  Annual raises will be a percentage above base salary
at a rate determined by the management.   Management level employees will be
given 2 weeks severance or notice based on security policies.   

Dismissal may be for poor performance, failure to work with team members, theft
or other criminal activity, inability to perform the required job functions, or
other reason as determined by supervisor and approved on a case-by-case basis
by Human Resources and/or the Board.  All dismissals may be appealed in writing
within 2 weeks of initial written notification of dismissal.  No employee will
be fired on the basis of religion, political beliefs, gender, sexual
orientation, injury, race or disability (provided the disability does not
prevent the employee from performing the requisite tasks and was disclosed at
time of hire).   The SO will support and practice fair hiring procedures and
our policies can be updated or amended at any time by proposal to the Board.   

No employee shall be liable jointly or individually for any loss, judgment,
injury, etc. unless proven to be criminally involved as stated in the by-laws
of the company.


RO
Initial staffing and expansion need not be considered for the RO as it is an
existing entity, fully staffed, and the demand levels contemplated in this
proposal will not put additional staff burden on the organization.

XO
The XO is likewise fully staffed to meet the anticipated needs of this project,
and
the XO is also poised both to be staffed during the start-up phase as well as
expand if necessary. During the start-up phase, key technical personnel (some
of whom are introduced in section E.1) from the XO provider, eNom, Inc. are
prepared to supervise other personnel, also from eNom in immediately staffing
the XO. 

If expansion is required, these key personnel will be instrumental in the
evaluation and hiring of an expanded workforce and developing the policy for
hiring, training and continuing evaluation. The hiring policies put in place
will be based, for the most part, on the hiring policies of eNom, the XO
contractor, which has built a strong technical operations team. Consistent with
current practices, training of those employees requiring new knowledge will be
done on a peer-training basis.

Staffing levels for the XO are not anticipated to be high enough to cause
problems in hiring and physical facilities. Additional space is immediately
available in the existing Bellevue, Washington, facilities of the XO contractor
sufficient to support anticipated staffing levels. The acquisition of
additional technical personnel is eased by the physical location of the XO
contractor: the Puget Sound area is well-known for its strong technology market
(including major employers such as Microsoft, Amazon.com, Real Networks, and
Nintendo), and has a sizable pool of qualified technical workers available to
fill any positions, from technical support through high-end design and
development.

V. Identify (including experience and position) key management personnel. Review the expected initial management team and the skills of each member, and plans for obtaining additional management personnel as necessary.
SO Management

The SO's does not require a large initial staff and therefore does not require
the quick ramp-up of a large management team.  Most of the operational
management will be performed by the RO and XO subcontractors supervised by the
SO.  Most of the SO staff will not be managers but Policy Enforcement
Technologists (explained in the Financial Model section). During the formation
of the SO the leadership of the Spamhaus Project will establish a small
management team to run the day-to-day operations of the Sponsor Organization,
including, but not limited to, policy enforcement, technology rollout and
ongoing operational supervision, finances and accounting, promotion, and human
resources.  This management team formation will be spearheaded by Steve Linford
of the Spamhaus project during the time before the contract negotiations are
concluded with ICANN.


See "Business Plan Current Operations III" for detailed bios on the following
management team members of the RO and XO

RO Management at Verisign

Aristotle Balogh — Senior Vice President, Operations and Infrastructure 
Mark R Gathje — Vice President of Technical Operations 
Mark Kosters — Vice President of Research 
Scott Hollenbeck — Technical Director of COM NET Registry 


XO Management at eNom

Paul Stahura - CEO
James L. Beaver - VP Operations
Matthew Stearn - Vice President of Business Development 

See "Business Plan Registry Requirements V" for planned SO management formation.

VIII. Provision for Registry Failure. Provide details on how you would assure continuity of operations in the event of business or operational failure of the Registry Operator or Sponsoring Organization and make provision for contingencies and a failsafe back-up plan.
Sponsoring Organization Business or operational failure
The Registry Operator (RO) will agree in the event of business failure of the
Sponsoring Organization (SO), to 
1) Assign the rights of the Sponsoring Organization under the agreement(s)
between the Registry Operator and the Sponsoring Organization to ICANN (or a
designee of ICANN) for at least one year.
2) Maintain the DNS resolution for the existing names in the registry for one
year
Before the failure, the SO will work with ICANN to find another replacement
non-profit organization that represents the community to takeover for the SO.

Registry Operator Business or operational failure
The RO will agree to allow the SO to switch to a different Registry Operator in
the event the RO experiences a business or operational failure.  Since there is
a time lag between the failure event and the switchover, and since the XO
requires the daily use of the zone file and performs, through the normal course
of business for the SO, DNS for the names (not the same DNS that they RO does),
and since the XO also has all the whois information (the zone file and both the
OAI and the whois for the key domain) for each domain (a functional copy of the
escrowed data), the XO will maintain "hot-spare" DNS and whois systems to take
over from the RO in case of emergency.  The "hot-spare" will not have the
capacity that the DNS system the RO has built, but will be sufficient to
maintain the resolution and whois output for the names until the switchover to
the other RO utlizing the escrowed data is complete.  During this period, no
additional records will be able to be added or removed from the zone (the XO
will not prepare a "hot-spare" EPP registration system), though during the
period, policy violators will still be able to be removed from the XO's name
servers.

Extra Registry Services Operator Business or operational failure
Its contract with the SO will stipulate that in event of failure, the SO is
able to switch to another provider.  During the switchover no additional names
will be able to be added to the sTLD zone file, and if policy violations are
discovered by the SO during this period, the SO can remove the names from the
zone file that the RO maintains.  Arrangements will be made with the RO so that
if a XO failure happens, the RO will immediately but temporarily perform the
DNS services that the XO was performing until a replacement XO is running.


 

Technical Requirements

The Technical Capabilities and Plan section must address the following. Links to other materials must not be included:

1. Outline the Registry Operator's technical capabilities. Provide a description of the Registry Operator's technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce and access to systems development tools. Outline any significant prior technical achievements.
Registry Operator (RO) - Verisign
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 sTLD. VeriSign 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 its
most recent fiscal year which ended December 31, 2003.

VeriSign's operational infrastructure 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. 

Verisign also has a global footprint of high-speed servers to support capacity
and availability demands, global and local load balancing, and threshold
monitoring.

Network Security includes protected domains, restricted nodes, and distributed
access control in our system. Verisign has developed communications protocols
that prevent most known forms of electronic attacks, employs firewalls and
intrusion detection software, and security consultants who perform periodic
attacks and security risk assessments. 

The company provides 24x7 customer support services through its phone-based
call centers, e-mail help desks, and Web-based self-help systems, including
multilingual customer service in 152 languages. 

It has an extensive monitoring capability, staffed 24x7, to track the status
and performance of our critical systems. 

Its disaster recovery and business continuity capabilities address the loss of
entire data centers and other facilities. The critical data services use
advanced storage systems to provide data protection through mirroring and
replication. 
 
VeriSign operates both the Shared Registration System (SRS) and Domain Name
System (DNS) resolution systems for .com, the world's largest TLD with over 31
million domain names in active use. In addition, VeriSign operates Registry and
Resolution services for a number a gTLDs and ccTLDs.
 
VeriSign's operating experience, system scalability, and reliability are
unmatched by any other registry operator, currently supporting 52% of the
worldwide domain name market and over 10 billion resolution requests per day.

VeriSign operates a global network of DNS servers. Each site has multiple
load-balanced DNS servers managed remotely over secure virtual private networks
(VPNs) which are monitored around-the-clock. The Constellation also includes
three hot standby 'swing sites' used for backup and fail-over. These swing
sites are at undisclosed locations for security purposes. See Section 2.a for
more information.

VeriSign has a well-established engineering department with experienced
analysts, developers, software testers, and project managers who use
best-of-breed tools to manage requirements, test cases, design, development,
configuration management, and deployment. 

Sponsoring Organisation (SO) - Founding member: The Spamhaus Project
Spamhaus does not have any quantifiable "business operations", being a
not-for-profit anti-spam advocacy group.  It shops-out its technical
operations, primarily to UltraDNS. Spamhaus researches 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. It is estimated that over 200 million active email boxes
are protected using Spamhaus' SBL. 

Extra Services Operator (XO) - eNom Inc.
eNom Inc. brings a sweeping range of technical expertise and Internet
development capabilities. Its offering of domain names, websites, email, DNS
services and more demonstrates its diverse abilities to not only excel in the
fast paced Internet domain name space but quickly and effectively develop and
bring to market new and innovative products and services.

A for-profit company with over $30M in revenues (cash-based), eNom was formed
in Washington State in 1997 as literally a garage start-up. eNom began its
participation as a registrar when the company applied for inclusion in the
initial registrar test bed. Accredited by ICANN in 1999, eNom is now one of the
largest registrars with over 2.8 million names sponsored across a number of
TLDs. It also "hosts" over 500,000 names for a number of other ICANN accredited
registrars. eNom has consistently performed between eight to eighteen percent
of all net new registrations in the most popular TLDs each month worldwide.

eNom's infrastructure consists 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.


eNom's DNS system is a highly integrated yet geographically dispersed system of
real-time name servers that meet very stringent demands. Average zone change
latency is 3 seconds and serves over 400 million requests per day,
significantly less than the maximum capacity of the system. 

The primary datacenter in San Jose, CA houses our main OLTP database, eNom.com
web site, our reseller API and other key systems. All systems are highly
redundant.

eNom maintains a staff of trained full-time employees to provide telephone and
email support during business hours. We have operations staff and core
employees on call 24x7 available to handle emergency situations and respond to
special emergency contact means provided to key partners.

eNom maintains a disaster recovery procedure that can repair or completely
restore all data in the case of complete disaster. All critical data is backed
up on a regular basis with off-site storage. All OLTP data is replicated and
mirrored strategically for redundancy and performance.

System development tools include Microsoft Visual Studio, NuMega Programmer's
Suite, MS SQL Query Analyzer, etc. Languages include C++, C#, VB, VB Script
(ASP), Java Script, Transaction SQL, etc. Debugging tools include WINDBG, CDB,
Bounds Checker, True Time. MS Visual Source Safe is used for source code
control. 

The size of the technical workforce is 23 permanent full-time employees. eNom
is located in an area of the United States with abundant, available, local
technical personnel who are experienced in the technologies employed to build
the system. Therefore, eNom can scale its technical workforce easily.

Chris Cowherd, Chief Architect
Since writing his first program over 22 years ago, Chris has gained
considerable experience in systems architecture, software development, database
design, and Internet technologies. He brings this experience, drive, and a deep
commitment to "make it work" to eNom.

He contributes world-class experience gained from participating in the
development and evaluation of the source code for such well-known products as
Internet Explorer and Windows2000, as well as earlier operating systems for
Microsoft. Prior to Microsoft, he was also the lead developer for Advanced
Semiconductor, Inc providing engineering software.

After retiring from Microsoft, Chris joined eNom as the leader of the
"deep-technology division" that has been responsible for development of key
eNom services such as DNS, registry communications, POP, kernel level
debugging. Chris also provides key technical leadership across all technical
aspects of eNom.

He currently manages a staff of 6 senior-level developers that focus primarily
on "lower level" development tasks such as system level debugging, C++
development, service and protocol level projects. He and his team provide
architectural and technical analysis for the development staff. They also
manage the selection and direction of the technological decisions of the
company.

Christopher Ambler, Chief Software Strategist
Christopher has been involved with the Internet and software development since
the early 1980's. The author of the popular shareware program FSUUCP, he wrote
one of the first personal computer utilities for Internet communications in
1987. A veteran of Microsoft, Christopher worked on Exchange Server and was
awarded a patent for his design of key communication components. He has been
involved in Internet governance issues since 1995, and the ICANN process since
its formation, participating in the creation process. 

After leaving Microsoft in 2000, Christopher participated in the new TLD
selection process and consulted for a number of registrars and registries
before coming to eNom. He brings his considerable experience in software design
and development to bear in creating cutting-edge Internet applications. He is
considered an expert on Microsoft's technologies and is the author of the Wrox
Press book, 'IIS 6 Programmers Handbook.' In addition to design and
development, Christopher examines the short and long-term strategic
implications of new and existing products, services and helps to identify new
markets, trends and opportunities.

2. Technical plan for the proposed registry operations. Present a technical plan for the proposed registry operations. In addition to providing basic information concerning the Registry Operator's proposed technical solution, this section offers the Registry Operator an opportunity to demonstrate that it has carefully analyzed the technical requirements of registry operation. Factors that must be addressed in the technical plan include:

a. General description of proposed facilities and systems. Address all system locations. Address the specific types of systems being used, their capacity and interoperability, general availability and level of security. Describe in appropriate detail buildings, hardware, software systems, environmental equipment and Internet connectivity. (Note that more detail may be provided in later sections.)
VeriSign’s data centers provide unparalleled Registry services for critical
elements of the Internet infrastructure. Our solution for the proposed sTLD
incorporates management and operation of the registration services from our
three major Internet Data Centers in the continental United States, from which
VeriSign currently provides critical Internet services including:
* Management of the Internet root zone and operation of two of the 13 Internet
root servers (a.root-servers.net and j.root-servers.net)
* Management of the .com and .net registries
* PKI certificate authentication
* Trusted payment services
* Billing and customer relationship management (CRM) systems for wireless
carriers

System Locations
VeriSign has partnerships with major collocation facilities throughout the
United States, Europe, and Asia that provide increased reliability and
redundancy for critical Internet services (e.g., nameserver resolution). As
mentioned in Section E.1 we operate 13 Global Constellation sites.  In many
cases we have tried to locate these sites at major internet peering points. 
The current locations of these servers are:
* Dulles, Virginia
* Ashburn, Virginia
* Atlanta, Georgia
* Miami, Florida
* Seattle, Washington
* Mountain View, California
* Sunnyvale, California
* Stockholm, Sweden
* London, England
* Amsterdam, Netherlands
* Tokyo, Japan
* Singapore
* Korea (scheduled for Q2 2004)

Our data centers are organized into Primary and Secondary facilities, with the
Primary Data Center being located near Dulles, Virginia. All VeriSign
facilities and partner facilities conform to rigorous standards for security,
reliability and quality. 

Specific Types of Systems Being Used
Global resolution sites are critical for a TLD that has a global focus. The
reliability and stability of any global TLD dictates that DNS responses are
given as quickly as possible and close to the point where the query is issued.
Each VeriSign data center has the following specific types of systems to
provide a high degree of reliability for all system operations:
* 24x7 on-site network operations center (NOC)
* Redundant uninterruptible power supplies (UPS)
* Redundant generators
* Redundant power distribution units (PDUs) with redundant circuits to each
equipment rack
* Redundant fire suppression (FM200 gas as primary with dry-pipe individually
activated sprinkler heads as back-up)
* N+1 cooling and humidification

General Availability
Registration Systems. Production EPP traffic will be load-balanced as a normal
mode of operation. Load balancing provides extra capacity as well has a high
degree of confidence (in addition to formal testing) that the system will
remain available in the event of a server failure. Network and databases will
also be configured to provide high availability and failover protection.

Resolution Systems. Internet DNS is, by its very nature, quite robust, but this
is no excuse not to invest in and implement additional DNS functions to improve
DNS reliability and security. The number of DNS sites must be scaled to meet
several demands for a TLD – availability, responsiveness, and capacity.
VeriSign has made a substantial investment in the selection, design, and
operation of its 13 DNS sites to ensure optimal performance of the DNS
Constellation. To meet the DNS needs for the proposed sTLD, VeriSign will
evaluate the global demands to select the locations and scale of each site to
exceed availability, responsiveness, and capacity needs. VeriSign regularly
reevaluates its DNS infrastructure to reposition and scale the DNS
Constellation as necessary to meet the most aggressive demand forecasts.

Each nameserver resolution site around the globe must adhere to strict facility
standards. Beyond this, however, VeriSign has developed operational processes
and procedures that allow us to quickly move DNS services from one site to
another. We also maintain three DNS hot standby “swing sites”, where DNS
traffic from any of the 13 resolution sites can be quickly redirected. The
swing site concept is a major element of our business continuity plan and
supports transparent (from a customer perspective) site maintenance.

Level of Security
The U.S. Government Department of Homeland Security has designated VeriSign’s
U.S. data centers as Critical Infrastructure elements. If natural disasters
were not enough of a risk, physical facilities present the most obvious target
for terrorist activities. The VeriSign data center facilities incorporate the
most obvious characteristics of security, including:
* Low profile (e.g., no external markings or signage on the building)
* Hardened against regional weather events (e.g., high winds or hurricanes)
* Located outside of flood areas
* Multi-level physical security, including 24x7 on-site security force, badge
readers, and biometric access control devices
* 24x7 video surveillance

Hardware and Software Systems
We recommend a three-tiered architecture to operate the proposed sTLD registry.
Technologies applicable to each tier provide redundancy. For example, at the
database tier, the EMC Symmetrix Remote Data Facility (SRDF) product can
replicate data in real-time, both inside the data center (e.g., between
multiple data centers in the same facility) and to the Disaster Recovery Data
Center. Additionally, hot stand-by servers with automated failover using IBM’s
HA/CMP function, provide redundancy of the database server. Load-balancing the
transactions across multiple gateway servers and application servers provide
reliability and redundancy in the other tiers. The hardware systems that
VeriSign proposes to use to support the sTLD registry have been extensively
tested and validated in our state-of-the-practice engineering lab. IBM
Enterprise Servers running the AIX operating system will perform as database
servers using Oracle as the DBMS database. Application and gateway servers are
predominately Intel-based solutions. Web and FTP servers are also predominately
Intel-based. VeriSign uses equipment from leading network vendors to provide a
robust solution for network and load-balancing equipment.

Verisign will use a three-tiered architecture for the sTLD registry as
described in Section E.2.c. This structure separates gateway functions (e.g.,
login, session management, and service auditing), application functions (e.g.,
business rules), and database functions. This separation also improves
security, allows easier problem diagnosis, and makes it easier and more
reliable to test and deploy modifications. Standard industry software products
(e.g., Java, C, and C++) facilitate performance and compatibility as
appropriate at each tier. We use BEA’s WebLogic software for web application
server development. We apply a rigorous QA and testing methodology that
includes a separate, fully functional, production “look alike” environment
where we can test new software before deployment. Additionally, a “staging”
environment enables us to practice repeatedly to ensure that deployments can be
executed seamlessly within maintenance windows. The staging environment also
enables an accurate prediction of the length of a deployment and back-out plan,
if necessary. 

Hot standby servers using IBM HA/CMP for automated failover monitoring and
execution protect the database server functions. The data is stored on EMC SRDF
and is synchronized in real-time to a secondary device located in a physically
separate Data Center. This architecture has a demonstrated capacity of
processing more than 300,000 transactions per minute and a proven availability
rate higher than 99.99 percent. 
It is contrary to security policy to publish the architecture or capacity of
the global DNS Constellation because of its criticality to the stable operation
of the Internet and because it is often a target of Internet “hackers”.
However, that architecture utilizes redundant hardware systems with no single
points of failure. 

Environmental Equipment
Each VeriSign data center HVAC and humidity control system incorporates a
minimum of N+2 redundancy.  Data center temperature is maintained at 70 degrees
Fahrenheit with a variance of plus or minus two degrees. Humidity is maintained
at 50 percent with a variance of plus or minus 5 percent. Primary fire
suppression is provided by FM200 gas with individually activated sprinkler
heads as secondary. The sprinkler system is “dry pipe”, which means that
compressed air keeps water out of the overhead pipes in the data center to
avoid the risk of water leaks damaging equipment. In the event of an FM200
discharge, all power to the data center is turned off. However, the FM200 will
not damage equipment, and a data center equipped with FM200 can be up and
running following a discharge as soon as the reason for the discharge is
identified and fixed. No equipment cleanup is required.

Internet Connectivity 
Internet connectivity is a critical support element to successfully operate the
sTLD registry. Sufficient bandwidth is the primary defense against DoS and
Distributed Denial of Service (DDoS) attacks. VeriSign uses multiple providers
who provision Internet connectivity through multiple physical routes. The data
centers include redundant Internet connections, which enter the facility
through multiple cable conduits, travel to the border routers via separate
conduits within the facility, and terminate at border routers positioned in
separate cabinets located in different sections of the Data Center. Nameservers
positioned with collocation partners have a minimum of two diverse gigEther100
MB connections.

Extra Registry Services
These will be performed by eNom at its datacenters and include DNS for each
name (the names in Verisign's name servers will point to eNom's), a website for
each, whois information aggregation and transmittal to Verisign, and abuse
email reception.

b. Describe the registry-registrar model and protocol.
One difference from this sTLD and other TLDs is that the whois information for
each name in the sTLD is already contained at some other registrar/registry,
therefore it does not need to be tranmitted from the registrar to the registry.
 The registered name (we call it the "key" domain because domains are of the
for key.sTLD at this sTLD) is itself a pointer to the whois information.  It
will be used by the XO (because the XO has access to the zonefile for the sTLD)
to access the whois information, this whois information will then be combined
with the OAI (the Optional Additional Information, which is the information
that the registrar can optionally transmit to the registry via EPP) and used to
validate the whois information.  The XO will then transmit the whois
information to the registry (using EPP) so that it is available via the
registry's normal whois services (to the public or whoever is eligable to see
it according to ICANN policy).

VeriSign plans to provide a “thick” registry for the proposed sTLD.  A “thick”
registry model maintains copies of all information associated with registered
domains, including registrant and contact information. Registrars typically
maintain their own copies of registration information. Thus, registry-registrar
synchronization is required to ensure that both Registry and Registrar have
consistent views of the technical and social information associated with
registered domains. EPP, first developed and published by VeriSign, and later
adopted by the IETF provreg working group, provides features to support both
thick and thin registry models. VeriSign’s basic registrant-registrar-registry
model for shared registration systems has become familiar and stable over the
course of four years of ongoing operations. Verisign has developed multiple
early implementations of EPP for domain name registration, including
implementations for the .name gTLD and the VeriSign NameStore service. EPP
includes many features and improvements as compared to RRP:
-->Extensibility (adding new features, such as support for ENUM and DNS
security) gained through the use of XML and a well-defined protocol extension
mechanism
-->Multiple transport protocol options
-->Improved features to authenticate and streamline transfer operations
-->Real-time client notification and message queuing
-->Support for IPv6 name server addresses
-->Improved pre-sales query mechanisms
-->Specification refinement and standardization through the open processes of
the IETF

VeriSign has developed implementations of EPP based on draft specifications for
several years. The .mail EPP implementation will comply with the current EPP
standard as developed by the technical community.

We subjected our early implementations of EPP to several rounds of development
and formal quality assurance testing. Free client Software Development Kits
(SDKs) that interoperate with other EPP servers are available from VeriSign in
multiple programming languages to minimize the amount of software development
required of Registrars. An isolated Operational Test and Evaluation (OT&E)
environment is available for Registrar testing prior to “live” operations,
allowing Registrars to develop and test their software systems with no risk to
“live” data or systems. Issues, defects, and errors noted during OT&E testing
can be corrected rapidly and deployed in both the OT&E and “live” environments,
ensuring that both environments use the same software code bases and that
transition will require little more than minor changes to client configuration
parameters.

VeriSign will build on its existing EPP server code base to provide a
conforming server implementation of EPP based on the final Internet-Draft
documents or RFC documents to provision the proposed sTLD. The implementation
will include support for domain objects and host objects, with contact objects
supported for the “thick” registry. EPP will be transported over the Internet
using the Transmission Control Protocol (TCP) with data integrity and privacy
provided by the Transport Layer Security (TLS) Protocol. Extensions needed to
provision the sTLD will be designed, documented, and implemented as needed.

c. Database capabilities including database software, size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation and reporting capabilities.
In addition to the DNS zone database, described in sections E.2.d and E.2.e,
the main XO database consists of a multi-server (node) cluster system with a
shared fiber channel RAID system. The RAID system consists of multiple hot
swappable hard drives, configured in a RAID 10 or RAID 5 configuration
depending on the data stored on the drive.

The cluster system provides a robust and completely fault tolerant and
redundant system at each level of the system. The system could continue to
operate without interruption upon drive failure, operating system failure, and
server failure. The hard drive RAID configuration allows any drive to
completely fail without interruption. The server cluster configuration allows
any one server to take over the job of any other node upon server or operating
system failure.

The XO’s Whois database is a replicated, read-only copy of all data required to
perform Whois. All Whois requests received by the registry's Whois servers will
be routed to this database (see also E.2.i for more information on Whois
Services). 

The distributed database model for the XO’s database is designed for
scalability and load balancing. The XO database will be designed for
transactional processing (OLTP) and as such will use relational database design
and concepts that are geared towards increased performance and scalability.
Such concepts include data normalization, vertical and horizontal data
partitioning, narrow indexing and referential and domain integrity. Although it
is estimated that the sTLD Registry OLTP database will only need to handle
30-40 transactions per second on average, the proposed OLTP database will be
able to handle 400 transactions per second with peak time and spike
capabilities of 700 transactions per second.

All data modifications done against the OLTP database will be logged in audit
tables. The information logged will include the modification made, the time,
and the name of the application and server that made the modification. This
data will be retained for one year to support legal inquiry. Direct, ad-hoc
access into the production databases will not be allowed. Data security will be
provided at multiple layers in the system. The firewall at each data center
location will not allow direct connections to the database that will reside on
a port unknown to the outside world. Only application servers will be allowed
access to the appropriate database. For example, the Whois application servers
will only be allowed access to the Whois database. Data replication that occurs
outside of the Operational Data Center will be delivered over a VPN. Data
updates will be delivered via a secure OLEDB connection and in an encrypted
format.

The primary On-Line Transaction Processing (OLTP) database is the most critical
element of the registry provisioning function.

Database Software
VeriSign will use Oracle Enterprise Edition as the Relational Database
Management software for the sTLD registration system. Oracle provides proven
performance, reliability, and security needed for the sTLD registration system.
Features such as JDK, PL/SQL and Unicode support will be employed for the
EPP-based registration applications, business rule batch processes, reporting,
zone and WHOIS generation. Oracle’s ability to integrate with high availability
software provides capabilities to fail over to a hot-standby server to maintain
high system availability in case of unexpected server or network interface
failure.

The OLTP database provides service levels of less than 400 milliseconds for
queries, 800 milliseconds for create transactions and 1600 milliseconds for
transfer transactions. The OLTP database design (which is currently supporting
the .com, .net, .name, and other registries operated by VeriSign) provides a
well-designed archiving process that moves historical/audit information to a
separate database instance. This design maximizes performance and minimizes the
time for data restoration in the unlikely event this is necessary.

Database Size and Throughput
The database has a proven history of handling more than 200 million
transactions per day, with peaks of more than 200,000 transactions per minute,
and more than four billion transactions per month. In addition, identical
systems have been stress-tested to handle more than 100 million registrations.
Transaction volume, however, is only one element required of a registry
database. Reliability is also critical, and a registry cannot permit the loss
of even a single transaction. Therefore, multiple copies of the database must
be replicated and stored in different locations. To accomplish this, the
VeriSign registry uses EMC SRDF data storage technology. We also generate tape
backups and transaction logs and keep them in the unlikely event that they are
needed. In the event of the default, acquisition, or closure of a Registrar,
the sTLD database will have the ability to transfer domain registrations to
another Registrar. A new Network Operations Center (NOC), located in our
Primary Data Center Facility, will monitor the performance and connectivity to
the sTLD registry database in 60-second intervals. 

Scalability
The entire VeriSign system supports “horizontal scaling” (i.e., the addition of
capacity by adding more machines). Scaling includes the following features:

Reliability. The success of any TLD registry depends on the quality of its
service. The OLTP database leverages VeriSign’s expertise and well-established
history of providing service reliability and data. Since the beginning of the
VeriSign SRS, not a single database modification has been lost or corrupted.

Security. If the primary OLTP database is susceptible to unauthorized
intrusions, the stability of the entire TLD is at risk. However, security is
more than just providing protection against hackers. Section E.2.j discusses
other critical elements of security in detail and describes how we have
implemented security requirements.

Recoverability. With all hardware and software systems, failures are not a
matter of “if”, but a matter of “when”. Therefore, all risks and contingencies
must be considered. Recoverability starts with the design of the database and
continues into the hardware architecture, the software architecture, and even
the underlying supporting facilities infrastructure. All VeriSign systems and
software support recoverability as an integral part of their design.

Equivalent Access. This feature is not an “after market” add-on and must be
built in from the ground up. VeriSign has made significant investments in its
current registry services and will ensure that the registry supports equivalent
access for all Registrars. VeriSign is audited annually by an independent third
party to ensure equivalent access.

Access to the registry database will be through a secure EPP connection;
database objects are created through business rules in the application servers
generated from specific EPP commands received from the Registrars. 

Change Notifications
VeriSign will give each registrar notice prior to deploying updates and
upgrades into the production environment. The notice shall be at least sixty
(60) days or as obligated by applicable contractual required. Such notice will
include an initial thirty (30) days notice before deploying the Update that
requires changes to client applications or the Upgrade into the Operational
Test and Evaluation ("OT&E") environment to which all registrars have access.
VeriSign will maintain the Update or Upgrade in the OT&E environment for at
least thirty (30) days, to allow each registrar the opportunity to modify its
client applications and complete testing, before implementation in the
production environment.

Registrar Transfer Procedures
VeriSign is committed to the stability of the proposed sTLD domain and will
implement a transfer policy in accordance with accepted ICANN guidelines. 

The transfer process is started when a registrar requests the transfer,
providing the  data as required by EPP. EPP requires the use of an
 element, in order to authenticate the requester of certain transform
operations on a domain name. The domain is put into PendingTransfer status. The
losing registrar uses the EPP  command to discover pending events, and
finds the pending transfer. The losing registrar either approves or rejects the
request, or does nothing. If the losing registrar does nothing, the transfer
will proceed after the period determined by ICANN's prevailing policy has
expired. 

Grace Period Implementation
Grace periods are configurable in the proposed sTLD database. VeriSign has
demonstrated the ability to modify these grace period rules with the
implementation of a Redemption Grace Period, which extends the DELETE grace
period and allows the Registrars to restore a domain name that was accidentally
deleted. VeriSign has extensive experience with the implementation of complex
business rule decisions and strictly follows detailed and mature analysis,
design, and testing processes to avoid inadvertent conflicts. 

Reporting Capabilities 
VeriSign provides reporting capabilities to meet the requirements for
registrars and ICANN reporting. Most of the reports are generated on a monthly
basis. The contents of the reports will be in compliance with ICANN
requirements and similar to the reports currently available from VeriSign for
.com and .net. 

REGISTRAR REPORTS
VeriSign will generate reports for each registrar on a daily and weekly basis.
These reports will contain domains, name servers and contacts for which the
registrar is the sponsoring registrar. The reports are available for download
from an ftp server requiring the registrar to provide its username and password
for authorization. A complete list of reports can be found in Section 2.o.

d. Zone file generation including procedures for changes, editing by registrars and updates. Address frequency, security, process, interface, user authentication, logging and data back-up.
While the zone file for the sTLD will be maintained by the RO (detailed below),
all delegation records in the sTLD zone will point to zones maintained by the
XO. 

These zones (the XO's) will contain "A" records for the registrant's mail
servers such that SAT-compliant mail transfer agents (MTAs) may verify the
authenticity of connection attempts. Further, the zone for each registration
will also contain records sufficient to implement sender authentication, and
these records will be maintained by the XO in order to maintain the integrity
of the zone. These zones (the XO's) will also contain the "MX" records required
to deliver all "abuse" & "postmaster" emails to the SO for evaluation.

As per the policy set forth by the SO, all registrants must undergo a rigorous
validation procedure to ensure the accuracy of both their technical and contact
registration information. These steps (and the policies on which they are
based) shall be maintained, frequently reviewed and administered by the SO. The
actual work of the validation process shall be performed by the XO. This
validation procedure shall include the following steps, summarized here.

1. Instructional email will be sent to both the contact specified in the OAI
(if any) and the listed administrative contact of the key domain. This email
will contain a numeric email-code.
2. To verify the receipt of the registration email, the recipient must input
the email-code into a web site specified in the verification email. Upon
successful entry, the web site will verify the postal mailing address from the
gathered Whois data and inform the recipient that a postal mail is being sent.
3. Postal mail deliverable by either a governmental postal service or a courier
service (such as Federal Express) will be sent to the registrant address on
record in the key domain Whois, made attention to the individual requesting the
registration (if specified). This postal mail will contain a unique numeric
code.
4. To verify the receipt of the postal registration mail, the unique code must
be entered into a web site specified in the postal mail and validated.
5. The XO may, if it is deemed necessary by the SO, make voice contact via the
telephone number provided in the Whois or OAI. To verify that the XO is
speaking with an authorized representative of the registrant, the contacted
individual must know and communicate the unique code sent to them via postal
mail.
6. Approval or disapproval of the registration shall be granted from the SO
based on its published policies, including information gathered during the
validation process.
			
While changes to sender authentication records will only be made by the XO, the
registrant has complete control over the balance of the records. If the
registrant desires to add, delete or modify an "A" record within their sTLD
zone, they may do so by using a privately-accessible web site. Changes are made
in real time to the XO-maintained zone.

With respect to the RO, VeriSign’s zone file generation process is reliable,
robust, secure, and has an extremely high degree of integrity. Real-time
updates (currently configured to be within 60 seconds) of the sTLD zone file
are possible without sacrificing the current integrity rates. 

Currently, we modify the zone files for the registries periodically based on
information provided by the Registrars through a secure connection to the
registry database. As discussed previously, we maintain full audit trails of
those transactions. These procedures will not change with the implementation of
the proposed sTLD database. The security characteristics of these procedures
are discussed in detail in Section E.2.j.

The system generates periodic snapshots in the form of a “zone file”. It also
monitors and extracts individual modifications to the data in a real-time
fashion. As a modification occurs, the affected data is extracted from the
authoritative database and submitted to the validation process to prepare it
for distribution.

The validation process provides a two-fold verification approach that ensures
the accuracy of the information distributed to the nameserver Constellation.
Before a change is actually sent to the Constellation, it is applied to a local
“Constellation Site” and the resulting changes are compared with the
authoritative database. If the results are identical, the changes are
distributed and applied to the resolution sites within the global VeriSign
Constellation.
The second part of the verification is a continuous comparison of the data on
the Constellation with the data in the authoritative database. This audit
provides an additional layer of protection against any invalid data or
misinformation being returned to the end users.

Procedures for Changes 
Changes to DNS resolution information will be specific to sTLD second and third
level domain names, nameservers, and IP addresses for nameservers within the
sTLD.  The changes will result from create, delete, or modification actions
taken by ICANN-accredited registrars, VeriSign customer service
representatives, the XO or automated batch processes.  Within one minute, each
change will be reflected in the zone generation process for near real-time
publishing of the sTLD domains.

Editing by Registrars
Edits to Zone information will be performed in the SRS by ICANN accredited
Registrars using the Extensible Provisioning Protocol API and Registrar Web
Tools.  In addition, authorized VeriSign Customer Service Representatives will
perform edits to zone information on behalf and consent of the registrars using
web-based customer service tools.  Other edits to zone information will be
performed by automated batch processes on a scheduled basis.  The batch
processes will be based on published business rules such as autorenewal of
expired domains and the Registry Grace Period. 

Updates 
The RO's system will monitor and extract individual modifications to the data
in a near real-time fashion. As a modification occurs, the affected data will
be extracted from the authoritative database and submitted to the validation
process to prepare it for distribution. Although it is possible to take a
snapshot in time to facilitate continued support of bulk zone access, the
frequency of updates means that the zone is extremely dynamic. 

Frequency
Generation of zone file information will occur as domains, nameserver, and
nameserver IP addresses are updated in the sTLD registration system.  The
frequency is dynamic and will vary based on the registration activity of the
sTLD.  However, even if the registry is quiescent, the zone file information
will be updated a minimum of two times per day.

Security 
Generation and validation of zone files will be automated using engineered
software on secure servers in a protected network.  Distribution and publishing
of zone files will be performed through Virtual Private Networks (VPNs) to each
of the VeriSign resolution Constellation sites.  Administrative access to each
component in the system will be limited to authorized VeriSign administrators. 
Each server will be built using a “locked-down” operating system image and
scanned for security vulnerabilities prior to being implemented.  Each server
will further be monitored and scanned for security vulnerabilities while live
in the production environment.

Process 
Zone files are distributed by a completely separate infrastructure than the
zone generation process so the two processes do not impact one another.  Once
the extraction process generates zone files, they are transferred to dedicated
systems for validation and distribution to VeriSign resolution Constellation.

Interface
VeriSign’s system will be implemented with a Heads-Up Display (HUD) providing
real-time monitoring of the generation, validation, distribution, and
publishing processes.  Important features of the HUD will include the SOA
record to provide clearer indication of the sTLD domain serial number and the
progress of zone file updates throughout the system.

User Authentication
Each generation, validation, distribution, and publishing process will use
server and application authentication to ensure only authorized accounts will
be used to update sTLD zone file information.  Each generation and validation
process is authenticated at the application level using server account
information and at the database level using account information specific to the
zone generation/validation process.  Each distribution and publishing process
is authenticated at the application level using server account information. 
Each process is designed to provide notification if it is performed by
non-authorized accounts.

Logging
Each zone generation and validation process will be logged by the application
and will be error-checked using VeriSign’s distributed monitoring system.  Each
zone file update and any errors in the generation or validation process will be
included in the logs.  The logs will be periodically reviewed by developers to
ensure appropriate validation criteria will be met.

Data Backup
Authoritative zone file information will be kept in the sTLD SRS using an
enterprise data storage system with mirrored RAID protection and offsite
real-time replication.  Generation of zone files will be performed using a
server connected to the enterprise storage system.  Each distribution and
resolution server, in turn, will use mirrored data storage to provide data
protection in case of hard drive failure.  A compilation of zone file updates
will be kept on each distribution server.  The compilation will provide for
quicker publishing times after server maintenance.

e. Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them.
XO Maintained Zones for the 3rd level names

The XO's real-time dynamic DNS servers are database driven and therefore rely
on standard and extremely well tested commercial data replication to deliver
zone updates. Each DNS server will house a local database that contains
replicated, read-only data required for DNS queries. Initial data
synchronization is delivered to each DNS server via ftp. Data modifications are
delivered to each subscriber (DNS server) in binary format and via a secure
OLEDB connection. Data update latency will be between 1 and 5 seconds. If a
particular DNS server is unavailable, transactions will be queued and will be
delivered sequentially when DNS server becomes available. Data replication is
coordinated by the replication distributor that will reside on one of the
database cluster nodes.

The XO's proprietary DNS software will power each DNS server and BCP0040 and
RFC 2870 (Root Name Server Operational Requirements) will be fully implemented
on name servers in all locations. The XO's DNS software is a modular service
utilizing an extensible plug-in architecture for name resolution and
administration, and is in production, currently being used by the XO's
registrar operations. This software currently provides DNS service for over
2,750,000 domain names with over 8 million host records (sub-domains) and has
been in continuous production for over three years. The DNS software is
database-driven and relies on standard well-tested data replication to deliver
zone file updates.

RO Maintained Zones for the 2nd level names

Location of Nameservers
VeriSign has at its disposal a Constellation of 13 globally deployed DNS
nameservers (see Section E.1). Each site has multiple load-balanced DNS servers
managed remotely over secure VPNs and are monitored around the clock in
four-second intervals. Each site also contains multiple servers and a complete
set of redundant hardware components to eliminate single points of failure.
Each site has a minimum of two Gigabit Ethernet connections and is served by at
least two separate Tier-1 network bandwidth providers. VeriSign selected these
sites because of their location at major Internet peering points. 

Zone file publication and distribution requires extremely high levels of
quality control. Even six sigma quality (99.9999 percent, or 3.4 defects per
million units) means that a TLD with two million registrations will have seven
that were not working properly at any given time. 

Seven may not seem significant, but that will depend on the individual
criticality of those seven. Many entities would be seriously impacted if their
Internet presence were disabled. Each time a zone file is moved from one
physical location to another, VeriSign systems audit it to ensure that data is
not lost or changed. Many registry providers today do not measure their quality
with regard to zone file publication and distribution. 

Procedures for and Means of Distributing Zone Files
The RO's systems will facilitate near real-time zone updates while maintaining
the current levels of reliability and integrity. We will update the
constellation site with new information and immediately make the information
available for Internet resolution. The distribution of the data across the DNS
Constellation utilizes the “zone file” philosophy as well as incremental
changes. Upon validation of a given zone file or change, the information is
queued for distribution to the remote sites of the DNS Constellation. Upon
receiving the information at the remote site, the Constellation site is updated
with the new information and immediately makes this information available for
Internet resolution.

f. Billing and collection systems. Technical characteristics, system security, accessibility.
The RO, Verisign, will be performing billing and collection services.

VeriSign’s billing capability supports either a wholesale or end-user-billing
model. Our proposed solution assumes the sTLD distributors will perform
end-user billing and the VeriSign system will provide wholesale billing to
distributors.

Technical Characteristics
The billing and collection system maintains the Registrar’s account data, from
which we create invoices, audit tracking, and financial reports. After VeriSign
receives an official notification stating that the Registrar has been
accredited, we will begin the ramp up process for the Registrar, including
setting up the Registrar’s financial account within the SRS. The Registrar is
able to view its account balance through the Web-based Registrar Tool. Only
staff members authorized by the finance group are given password-protected
access to the Customer Service Representative (CSR) Tool to increase or
decrease a Registrar’s account balance.

Registrar financial account balance data are included in the SRS database. As a
result, this account data is maintained through the same backup and escrow
procedures defined in Section E.2.g and the high system security standards
described in Section E.2.j.

VeriSign’s billing and collection systems handle the following functions:
-->Debit and credit Registrar’s accounts
-->Initiate low-balance notifications
-->Enable customers to view their accounts
-->Track and report historical information

VeriSign’s proven Payment Model includes the following features:
-->Security. The VeriSign system debits a Registrar’s available credit balance
by the wholesale fee. The system debits and/or credits the account in
near-real-time batch updates.

-->Monthly invoices. VeriSign invoices the Registrars monthly for the wholesale
fee due for each billable transaction conducted during that calendar month net
grace period transactions. The system automatically calculates the monthly
charges for each Registrar based on system-generated billing reports.

-->Fees. VeriSign debits fees from the account for each Registrar as
transactions are conducted. Payments received replenish a Registrar’s available
account balance.

-->Financial requirements. The following documents comprise a Registrar’s
financial obligations:
- Registrar credit application. The application establishes a Registrar account
with the registry. 
- Acceptable vehicles to satisfy the payment security are: cash deposit,
irrevocable stand-by letter of credit from a bank, payment security bond from
an approved surety or bank

-->Grace periods. Credits are applied to Registrar accounts for grace periods,
pending periods and rules for overlapping grace periods, based on system
settings. Grace periods are configurable within the system to allow ease of
customization and reduced time to market if policies change.
System Security

Accessibility
Registrar’s transaction reports are accessible via secure FTP connection. Daily
reports are posted the following day and remain on the site for 30 days.
Monthly reports are posted on the first day of the following month and remain
on the site for 90 days.

g. Backup. Describe frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of suggested escrow agent(s) and procedures for retrieval of data/rebuild of database.
Backup of critical data is an essential part of VeriSign’s and eNom's (for the
Extra Registry Services data) normal data center operations. Our backup
procedures incorporate hardware, software, and escrow agents to ensure 100
percent availability of data in the case of failure at any point in the
processing stream.

Frequency and Procedures for Data Back-up
For more information on our back-up solution and procedures please refer to
following Sections: E.2.c, E.2.h, E.2.m, and E.2.n. VeriSign plans to provide
real-time back-up as it relates to storage and daily back-up to tapes of the
database. VeriSign will use a five-tiered structure for protecting critical
data. This structure provides:
-->Maximum protection against the corruption of critical data
-->Maximum confidence in the ability never to drop or lose a single real-time
transaction (Especially important in an environment that is processing a
hundred thousand real-time transactions every minute)
-->Ability to quickly restore data in the event of a major disaster

Hardware and Systems Used
The VeriSign five-tiered hardware and software structure starts with maximum
protection of the primary OLTP database. This is the most important element of
any registry provisioning function. At Tier-1, enterprise SRDF storage
technology ensures the performance and integrity of the proposed registry
database. Each disk drive in the enterprise storage frame will be fully
mirrored, with significant automated checking for physical corruption and
failover. Additionally, we will create periodic Business Continuance Volumes
(BCVs) or snapshots from the primary database to provide the ability to quickly
restore the primary database in the event of an emergency, as well as the
ability to perform various administrative batch activities (e.g., reports and
back-ups) without affecting the performance of the primary OLTP database. This
architecture is critically important to maintaining SLAs in an environment with
high transaction volumes and significant transaction peaks. 

At Tier-2, From the BCVs created in Tier-1, we will generate tape back-ups from
the OLTP database, and store them in a tape library located at the Primary Data
Center Facility. VeriSign uses enterprise tape storage software to store data
onto tape libraries. Each day, copies of these tapes are created and stored at
a short-term offsite tape storage facility. These tapes are accessible within
10 minutes to operations personnel. The data on these tapes includes database
transaction logs.

At Tier-3, each real-time operation against the primary OLTP database is
synchronized to another enterprise storage frame located at the secondary data
center facility. This occurs in real time and facilitates the rapid recovery of
the latest database transaction in the event of a major disaster at the primary
data center facility. 

At Tier-4, daily full backup tapes are transported weekly from the short-term
offsite tape storage facility to a secure long-term offsite tape storage
facility operated by a third party storage vendor. These tapes are retrievable
in a few hours at the request of specifically named and authorized individuals.


Data Format 
Data kept in tape storage will be kept in a native binary format that will be
compressed to improve the volume of storage on each data tape. The reports
provided for a third party Data Escrow agency will be provided in an
ASCII-delimited format.  The report files will be further split, archived in a
tar format and compressed for ease of transfer by the Escrow agent.

Identity of Suggested Escrow Agents 
In addition to these extensive data storage and protection procedures, at
Tier-5, the fifth and final tier, we will contract with a third-party data
escrow company for data escrow services. Under this arrangement, the sTLD
database transaction logs will be electronically delivered in a secure mode on
a weekly basis to the escrow agent, as well as incremental updates on a daily
basis. The data escrow agent will receive the data, conduct verification
testing for completeness and integrity, and store the data onto DVD. This
process ensures that current registration data is always available. The terms
of the Escrow Agreement will specify the conditions under which the data will
be released.
Procedures for Retrieval of Data/Rebuild of Database
Should a situation occur that requires data recovery, the severity of the event
determines the specific procedures to be employed. In the event of a failure of
the primary enterprise data storage device, the database will be recovered on a
secondary enterprise data storage device. Since this second device is regularly
updated from the primary OLTP database, the recovery time is minimal and the
confidence in data integrity high. Should the primary data center be rendered
completely offline, registration functions will be recovered at the disaster
recovery data center.


It should also be noted that in the case of this particular sTLD that all the
whois information is also stored at the other registries and/or registrars.  If
a complete disaster happend, including the business failure of the SO and RO,
the only information required to re-aggregate and restore the entire dataset
(whois) is the sTLD zone file, which is a small amount of data that will be
made public with daily updates and stored in a number of locations.

h. Escrow. Describe escrow arrangements, data formats, insurance arrangements and backup plans for data recovery.
Insurance Arrangements
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.      

Backup Plans for Data Recovery.
With all of our previously described data protection plans, redundancy, and
reliability in place, it is difficult to envision a scenario in which data
recovery from tape might be necessary. However, we have planned for this
contingency as well. There are multiple enterprise storage frames located in
various data center facilities that could be used to restore data in the event
of an emergency. In a worst-case scenario where all online copies of the
proposed sTLD registration database are completely destroyed, and the Primary
Data Center Facility is offline, full recovery of registration functions could
be accomplished in a timely manner. In any case, the most critical functions
involving DNS resolution will not be impacted.

The enterprise tape storage software provides the following functions:
* Backup, Archive, and Restore:
* Unattended full and incremental backups
* Administrator initiated manual backups
* User directed backups/restores

i. Publicly accessible WHOIS service. Address software and hardware, connection speed, search capabilities and coordination with other WHOIS systems.
The RO, Verisign, will be performing the Whois service.  The XO will be
validating the whois information and transmitting it to the RO. The XO will
maintain a "hot-spare" whois service in the event of a business or other
failure of the RO's service.  

This (XO) hot-spare port-43 Whois service is already built and resides on
multiple servers load balanced across a single IP address. The service
currently provides real-time results by using XML Web Services to retrieve and
cache contact information prior to displaying it to the end-user. Output is
available both as traditional text-based reports as well as modern XML Web
Services via the Simple Object Access Protocol (SOAP).  Facilities to combat
abuse are incorporated into the system, providing throttling of repeated
high-speed lookups, malformed denial-of-service attacks and data mining.
Additionally, variant output formats are supported to thwart robotic data
mining attempts.

The data-to-day port-43 whois service (whois output of information in response
to port-43 queries) will be performed by the RO. VeriSign, the RO, has the
capability to provide a robust and reliable WHOIS service that initially meets
the current industry standard requirements.

Software and Hardware
Initially, the WHOIS service serving the .mail sTLD domain will be based on the
existing VeriSign WHOIS software and servers used for .com and .net, with
additions provided to include “thick” registry contact data (or as modified to
support specific .mail sTLD requirements). This service is fully compliant with
RFC 954 and is currently being provided via servers located in two separate
facilities. The uptime rate currently exceeds that of the .com and .net
registry database because not all database outages require a WHOIS outage. The
current five servers process 30,000 transactions per minute. 

Connection Speed
The current WHOIS software can be migrated to any Unix platform. The current
architecture is load-balanced between multiple servers at each site, and
balanced between multiple sites. This provides maximum reliability, and is
highly extensible by adding more servers behind the load balancers. The
presence of multiple servers, multiple facilities, and multiple network
providers means that the current service is well protected in the event of an
issue within the control of the registry provider, as well as for many events
outside the control of the registry provider such as an outage of a major
Internet bandwidth provider. The current servers are connected to the Internet
by multiple network connections at each facility.  

Search Capabilities
The current WHOIS service has rate-limiting characteristics within the software
(e.g., the ability to throttle a specific requestor if the query rate exceeds a
configurable threshold). In addition, QoS technology enables rate limiting of
queries before they reach the actual servers, which provides protection against
DoS and DDoS attacks. The current software also permits restrictions on search
capabilities. For example, wild card searches can be disabled. VeriSign is
generally not in favor of restricting searches unless it is clear that the
results of the search are being used in ways not beneficial to registrants. It
is possible to restrict or block individual requestors (i.e., requests coming
from specific IP addresses).

Coordination with Other WHOIS Systems. 
According to the Nicname/WHOIS protocol defined in RFC 954, there is no defined
mechanism or method to instruct RFC 954 client software to follow referrals.
The current state of referrals using RFC 954 is non-standardized, with many
different forms of WHOIS referrals in use today. This WHOIS service provides
all required technical (DNS delegation) information and social (contact)
information associated with a domain without a referral to a Registrar’s WHOIS
service.

j. System security and physical security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering and other disruptions to operations.
VeriSign, the RO, employs numerous safeguards to protect the physical and
logical security of its systems and the data stored on them. While a high-level
discussion of those safeguards is appropriate for this proposal, specific
details are not. The two guiding principles behind our security posture are:
* The more widely a precaution is disclosed, the less useful it is.
* A sufficiently committed and resourced individual can circumvent any
precaution.

Verisign has developed its security policies within the following general
parameters:
* Do everything possible, including staying abreast of the latest exploits and
the latest technology, as well as implementing all known state-of-the-practice
safeguards.
* Develop contingency plans for events that are out of your control.
* Monitor frequently. Just as in the medical field, the key to the cure is
early detection.

The following table identifies general areas of concern with regard to system
risks as well as the precautions that we will take to protect the proposed
registry systems. Interestingly, non-malicious or accidental incidents present
a high risk and are, in reality, more prevalent than malicious incidents.

PRECAUTIONS
1. Physical Security
2. Background Investigations
3. Dedicated IT Security Staff
4. “Hardened” System/Network Architectures and Configurations
5. Detailed Physical and Logical Monitoring
6. Frequent Audits and Tests 
7. System Survivability and Disaster Recovery Plans
8. Cautious Selection of Strategic Vendors and Suppliers
9. Strict Policies on Information Release

RISKS________________PRECAUTIONS
Viruses……………………………………3,4,5,7,8
Logical Intrusion…………2-9
Denial of Service…………3,4,5,7,8,9
Physical Intrusion………1,2,5,7,8,9
Equipment Failures………5,7,8
Software Bugs……………………3,5,6,7,8
Infrastructure Failures……5,7,8
Site Failures……………………5,7,8
Data Loss/Corruption…3,5,7,8
Human Error…………………………1,5,6,7,8

Technical and Physical Capabilities and Procedures
VeriSign’s technical and physical capabilities are designed to prevent system
hacks, break-ins, data tampering, and other disruptions to operations as
described in the following sections.

Physical Security.  The RO's physical security measures include a 24x7 on-site
security force and card readers that protect access to all owned and operated
data center facilities. These measures are also required for all collocation
partner facilities. Additionally, we employ biometric access controls at our
data centers to positively identify all personnel. As important as physical
security is, however, it pales in comparison to logical or I/T security risks.
In reality, there is no way to provide 100 percent protection to any specific
facility. For this reason, the proposed registry systems will balance
transaction loads between multiple facilities and functions that can be
transferred from one facility to another.   The XO also has similar security
measures in place.

Hardened System/Network Architectures and Configurations. VeriSign proposes
three levels of security procedures for accessing the registry. First, all IP
traffic will be filtered, with only traffic from predetermined authorized
Registrar subnets permitted through the routers. Second, a successful SSL
handshake with valid PKI certificates will be required to establish a
connection to the registry. Finally, after passing both of those levels, each
Registrar will be required to enter a valid userid and password to gain access
to the registry. Security internal to the proposed .mail sTLD database prevents
one Registrar from accessing another’s data. As an added layer of protection,
QoS devices will be used to prevent a few Registrars from consuming all
registry resources.

Verisign manages it globally deployed nameservers via secure VPN connections.
These connections are encrypted via IPSec and allow only connections from
authorized machines and users. The VPNs are configured in a high availability
mode.

Detailed Physical and Logical Monitoring. We monitor our data center facilities
24x7 via surveillance cameras. These cameras are located both outside and
inside the facility. At the Primary Data Center Facility, each row of equipment
cabinets has a security camera. Additionally, all card access and biometric
access are monitored and logged. The NOC will monitor all aspects of the
registry database and global DNS, including system health, system performance,
system load, and attempted system intrusions. Attributes of the database will
be monitored in 60-second intervals. Attributes of the global Constellation of
nameservers will be monitored in four-second intervals.

Frequent Audits and Tests. Verisign performs periodic audits of its systems and
networks, including third-party intrusion testing. They use an outside company
to perform penetration tests, which include numerous tests for exploits,
versions, and patch levels. Independent auditors such as KPMG regularly perform
SAS 70 and BS 7799 audits.

Background Checks. Verisign perform two levels of background checks on
contractors, consultants, and prospective employee candidates. The first level
is a Basic Background Investigation Status (BBIS). Employees are required to
re-qualify for the BBIS every three years as a condition of employment.
Non-employees (e.g., contractors and consultants) are required to re-qualify
every three years to be granted badge access to data center facilities. The
BBIS checks for items such as:
* Convictions for violent crimes
* Convictions for crimes involving financial malfeasance
* Convictions for crimes involving controlled substances or illegal drugs
* Behavioral patterns indicating personal irresponsibility (e.g., multiple
Driving Under the Influence convictions)
* Embellishing or falsifying a job application

In addition to the BBIS, personnel requiring access to the data centers are
required to qualify for an Extended Background Investigation Status (EBIS). The
EBIS includes all elements of the BBIS, with the addition of a credit check.

Dedicated I/T Security Staff. Our dedicated I/T security staff performs a
number of functions in support of our I/T security posture, including:
* Development of I/T security standards
* Implementation and management of network security devices (e.g., firewalls,
ACLs, etc.)
* Working with upstream provider’s security staff to deal with DoS and DDoS
issues
* Working with government and industry entities responsible for critical
infrastructure assurance, such as the National Communications Center (NCC) and
the FBI’s National Infrastructure Protection Center (NIPC)
System Survivability and Disaster Recovery Plans. VeriSign has developed a
complete business continuity and disaster recovery strategy. Key elements of
this strategy include:
* Multiple load-balanced servers and/or hot spare servers to protect against
system hardware failures
* A secondary site (with EPP transactions load-balanced between sites) to
protect against a site failure
* The ability to transfer operations (especially DNS operations) between global
sites

Business continuity and disaster recovery plans are not just for system
failures and natural disasters. Verisign implements them in the event that a
system or site suffers a security compromise.

Selection of Strategic Vendors and Suppliers. One of the most important
elements of any critical infrastructure operation is the selection of, and
ongoing relationship with, vendors and suppliers. Critical vendors and
suppliers provide dedicated on-site support. These technical representatives
are located at corporate facilities, work solely with corporate I/T staff, and
do not split their time with other companies. They are on-site during business
hours, on-site with corporate I/T staff during major deployments, and on-call
24x7, ensuring a direct line to vendor engineering and operational resources.
Additionally, these critical vendors advise us of potential bugs or exploits
before making public announcements.

Strict Policies on Information Release. Verisign maintain strict policies
regarding the release and disclosure of information that could generate a
security risk. Direct relationships with the NCC, NSC, and NIPC ensure that
VeriSign is now, and will always be, “in the know” regarding the latest
security threats.


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.  All servers
and systems utilize hardware level security devices such as firewalls,
intrusion detection systems, secure switches and traffic flow monitoring.  eNom
has personnel that monitor OS and application patch status and security
bulletins. The company has a "strong password" policy throughout the
organization.


Supporting Organization (SO)

Electronic communications between the SO, the RO and XO and storage of
sensitive data will be maintained over industry standard secure systems
including secure VPN, mutually authenticated SSL, encrypted file systems, 3DES,
AES and will be re-evaluated for ongoing security issues on a regular basis,
including regular security audits.  Spamhaus currently utilizes secure channels
to communicate sensitive blocklist information with its staffers, these same
types of security precautions will utilized in communications with the RO and
XO.

k. Peak capacities. Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance and personnel.
VeriSign’s existing Constellation of DNS nameservers is capable of handling
more than 200,000 DNS transactions per second, per site. This existing
capability far exceeds the most optimistic growth requirements for the .mail
sTLD. In addition, the overall design is such that it can be massively scaled
with minimal effort and at reasonable cost.

Technical Capability for Handling Larger than Projected Demand for Registration
or Load
Recent experience has demonstrated that many registries have had problems with
unexpectedly larger-than-projected demand for registrations. For example, in
the new gTLD registries, these problems appeared as system failures associated
with the start-up period of land-rush registrations. This phenomenon became
apparent with the high demand associated with desirable domain name
registrations in .com and .net being deleted and reentering the registration
market. Handling high volumes is a difficult enough challenge by itself, but
doing so while satisfying equivalent access requirements is a daunting task.
VeriSign has gained significant experience in developing and implementing an
architecture that will protect the registry database from high transaction
volumes, while maintaining equivalent access for all Registrars. 

Effects of Load on Servers and Systems
Our QoS architecture provides the ability to “tune” the transaction volume
permitted into the proposed registry. VeriSign registries have handled in
excess of 200,000 transactions per minute without sacrificing SLAs or causing
undue system load on application and database servers. Additionally, the
registry database architecture permits us to balance the transaction load
across multiple servers. If additional capacity is required, we can add servers
behind the load-balancers. 

VeriSign’s back-end support systems (backups, escrow, maintenance, etc.) are
capable of handling the maximum transaction volume permitted into the proposed
.mail registry database. As an example, the current .com TLD registry database
has historically demonstrated the ability to quickly scale to meet unforeseen
increases in transaction volume. In April 2000, VeriSign’s daily transaction
rate increased from five million transactions per day to 25 million
transactions per day. This increase occurred over a period of only 48 hours. We
have handled this increase without the need to increase staff or redesign the
system. The proposed database solution will be highly robust, reliable, and
quickly extensible. The CPU load on the database server is typically less than
15 percent. Even during peak periods, the system design for the .mail sTLD will
ensure that CPU utilization remains below 50 percent.

The single most critical element of performance and capacity that can affect
Internet stability is the number and throughput of DNS nameservers. If a
registration system is offline, new registrations and changes to existing
registrations cannot be accommodated. This is undesirable, but the Internet
will continue to work. If DNS nameservers are offline, Internet resolution
ceases as DNS cache decays. The impact of such an event goes far beyond the
stability of a specific TLD and the top-level DNS servers for that TLD. As
lower-level DNS cache decays, the stability of the entire Internet can be at
risk. Internet stability is an ICANN objective for all TLDs, and therefore the
architecture, capacity, and proven performance of a candidate registry’s DNS
Constellation must be of paramount concern.

VeriSign monitors the transactions and performance of the DNS servers with what
we believe to be the highest rigor in the Internet community. Some providers
may not recognize the existence of a problem until their servers crash;
however, VeriSign takes a snapshot of each of VeriSign’s globally deployed DNS
servers every four seconds. This tool depicts the DNS transaction volume and
server performance at each individual site, and rolls the data up into a global
view. It detects unusual increases and notifies the entities that were the
source of the problem before those entities were even aware of their own
problems.

This capability allows our staff to see the top-20 DNS transaction generators
at each of its DNS sites. This tool allows our staff to pinpoint the exact
cause of sudden increases in DNS transactions. Therefore, it is critical to the
stability of the Internet that any TLD registry is able to demonstrate beyond
any doubt that they have a DNS Constellation capable of absorbing massive and
sudden increases in transaction volumes. VeriSign has proven that we can handle
this situation.

Effects of Load on Databases 
Increased transaction activity may result in stress on the authoritative
database which can increase response time for registrar EPP transactions. 
VeriSign’s databases are engineered with a design point not to exceed 50% CPU
utilization.  The database and storage systems will have capacity to add CPU,
memory, and hard drives.  The vertical scalability will allow quick response to
address sustained increases in transaction load.

Effects of Load on Support Systems 
Increased transaction load will not significantly impact backup systems. 
VeriSign will employ a separate backup infrastructure that is not dependent on
transaction load.  VeriSign generally schedules backups during periods of slow
registration activity.

Effects of Load on Escrow Systems 
Larger than projected demand for registrations will ultimately increase the
volume of data backed up for data escrow.  The result will be increased
generation times for data escrow reports, increased data storage for the larger
reports, and increased transfer times to the 3rd party escrow agent. 
VeriSign’s systems will be sufficiently sized to handle at least twice the
current volume of escrow reports for the .mail sTLD.

Effects of Load on Maintenance and Personnel 
VeriSign will design and implement a .mail sTLD registration and resolution
systems with a redundant architecture that allows maintenance to be conducted
even during increased work loads.  With load balancing technology, servers can
be removed from live service for maintenance with minimal impact to registrar
transaction activity.  After maintenance, the servers can be restored for live
service. Increased transactional loads may trigger monitor alerts to VeriSign’s
Network Operations Center.  The alerts will set forth procedures for
troubleshooting and escalation to second level systems, database, and network
administration support.  The second level support will further troubleshoot and
watch the affected system at the network, applications, and databases layers. 
Unusual transactional activity may be the result of automated batch
transactions or broken registrar software.  VeriSign’s customer service
representatives may be engaged to discuss transaction activity with the
registrar.  If the increased transaction load will be sustained, VeriSign’s
engineering resources may be engaged to review capacity planning models to
determine if additional servers, memory, CPUs or storage will be required.

l. System reliability. Define, analyze and quantify quality of service.
Registry system reliability and QoS include three basic categories:
* Reliability and quality of the database and surrounding components that
comprise the provisioning function
* Reliability and quality of the nameservers and surrounding components that
comprise the resolution function
* Quality and integrity of the zone files

Quality of Service
VeriSign has a history of reliable registry database operations. The current
.com and .net database has successfully operated within contractual SLAs. For
the .mail sTLD registry database, we will measure QoS in terms of the following
three elements:
* Availability of the database (system up-time)
* Response time for database transactions
* Equivalent access

Response times for VeriSign’s registries (.com, .net, .name, etc) continually
exceed the SLA criteria for queries - 400 milliseconds, creates - 800
milliseconds and transfers – 1600 milliseconds.

A QoS device that acts as a front-end to the SRS will manage access for the
proposed registry. This QoS device will manage two critical aspects of
Registrar access to the database. The first is the number of SSL connections.
The QoS device ensures that each Registrar is permitted the same number of SSL
connections to the database. However, this by itself is not sufficient. The QoS
device must also ensure that each Registrar has an equivalent amount of network
bandwidth. In this way, no Registrar can utilize their SSL connections to usurp
more than their fair share of transaction bandwidth. 

For the nameserver Constellation, we will measure QoS in terms of the following
two elements:
* Availability of each site (system up-time)
* Capacity (queries per second), including queries answered and not answered

Although DNS is extremely tolerant of the loss of a single site, this is true
only if there are sufficient remaining sites with sufficient extra capacity to
assume the load. 

Since the XO will perform certain DNS services it should be said that they will
be using their existing contelation of five geographically dispursed name
server clusters (more than 3 physical servers at each location behind a
load-balance IP) with 99.99% uptime.  The current capacity is 1.8 Billion
queries per day, of which 500M-1B (peak) is used, leaving plenty of capacity
for the sTLD names' "A" and "MX" records.

Finally, the primary QoS metric (which encompasses both the database and the
nameservers) is the integrity of the zone files. In other words, how many
errors are in the zone files and how long do those errors exist at the
nameservers, and thereby to what extent is resolution affected. There are many
opportunities for failure in the process of zone file generation and
distribution. Considering 2.5 million domains, there are more than 1.8 billion
opportunities for failure in a given year and VeriSign has never had an error
in the .com or .net zones.

m. System outage prevention. Procedures for problem detection, redundancy of all systems, backup power supply, facility security and technical security. Outline the availability of backup software, operating system and hardware. Outline system monitoring, technical maintenance staff and server locations.
Preventing unplanned system outages and keeping planned outages to a minimum
result from robust planning and execution of proven system reliability
practices. Robust system architecture and continuous system monitoring help
prevent or minimize unplanned outages. A modular system design with
well-defined interfaces minimizes planned outages through normal system
maintenance. VeriSign’s system outage prevention process will include the
following elements as described above in Section E.2.a.:
-->Redundant secure facilities
-->Redundant facility infrastructure, including power, cooling, and fire
suppression
-->Redundant Internet providers and massive bandwidth
-->Redundant servers (either hot spares or load balanced)
-->Multiple data center infrastructures within a single facility
-->Redundant servers located in different data centers and different facilities
-->System and network health and intrusion monitoring

Problem Detection
VeriSign’s NOC will monitor the proposed registry database in 60-second
intervals. The monitoring process includes server behavior (e.g., up/down, CPU,
and memory utilization), system characteristics such as the number of EPP
sessions per Registrar, and the number of EPP transactions currently being
processed. The NOC is staffed 24x7 by trained and qualified engineers. If
problems occur, the NOC is typically aware of them in 60 seconds or less. Each
site in the global DNS Constellation is monitored in four-second intervals.
Issues that cannot be resolved by NOC engineers are escalated to an operations
team that is either on-site or on-call 24x7. 

Redundancy of All Systems 
One of the most critical aspects of system outage prevention is the ability to
shift operations between facilities. The locations of facilities that will
support the registry are described in Sections E.1 and E.2.a. The proposed
database operations will be divided between two existing facilities and could
be run from either one in the event of a facility failure. 

DNS is, by its very nature, extremely robust. The outage of one of the 13
global DNS sites will not be noticed on the Internet because other sites will
automatically assume the load. In fact, the current Constellation has
sufficient capacity such that one third of the sites (four sites) could handle
normal DNS volumes. VeriSign also maintains three hot standby “swing sites” to
which the DNS transactions from any global site can be routed in the event of a
site failure, or planned site maintenance. 

Another critical element of preventing outages in the DNS is to over-provision
bandwidth. A DoS or DDoS attack against the Internet DNS is extremely difficult
to repel. The best option is to absorb it. The greater the ability to absorb
such an attack, the less impact it will have. As discussed previously,
VeriSign’s global DNS Constellation can process huge numbers of DNS
transactions per second to withstand even the most aggressive DoS attacks with
no interruption to the end user.

Backup Power Supply
All data center facilities contain backup power supplies as discussed in
Section E.2.a and E.2.n.

Facility Security and Technical Security
VeriSign provides a robust and comprehensive facility and technical security
process as described in Section E.2.j.

Availability of Backup Software, Operating System and Hardware
VeriSign provides backup software, operating systems, and hardware in each of
our data centers as described in Sections E.2.a, E.2.b, and E.2.g. All software
and hardware at each data center is identical to allow rapid takeover of
operations in case of failure.

System Monitoring
VeriSign performs system monitoring on a 24x7 basis (see Section E.2.c). Our
NOC staff, located in our Primary Data Center Facility, monitors the
performance of, and Registrar connectivity to, the registry database in
60-second intervals.

Technical Maintenance Staff
VeriSign’s experienced technical maintenance staff is located at the Primary
Facility, where it supports Data Centers A and B. It also provides support to
the Disaster Recovery Facility, which is located a short distance away.

Server Locations
VeriSign provides a Constellation of 13 servers located worldwide as described
in Section E.1 and E.2.a.

n. System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures. Describe the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation and the availability of the hardware needed to restore and run the system. Describe backup electrical power systems and the projected time for system restoration. Describe procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.
VeriSign recognizes the criticality of continuous system operations. As shown
in Section E.2.l, VeriSign successfully operated the .com and .net registries
at reliability of 99.994 percent for the entire year of 2003. In addition, our
DNS constellation has operated at 100 percent availability since 1997, and the
.com and .net files achieved a reliability rate of 100 percent for all of 2003.
These high levels of reliability and availability attest to our redundant
system architecture, system network health and intrusion monitoring, and the
quality and integrity of the zone files. The following subsections describe the
specific procedures that we will use to continually ensure our high levels of
system operation for the .mail sTLD.

Procedures for Restoring the System to Operation in the Event of System Outage
VeriSign has documented business continuity plans and system recovery
procedures that outline the types of events that might interrupt operations and
how they are addressed. The procedures to recover from failures depend on the
nature, scope, and severity of the failure. The following table shows general
types of failures and the procedures used to recover from them. Sophisticated
hardware and software automatically handle the majority of these failures.

FAILURE TYPE………………………RECOVERY ACTION
Electrical power……………UPS maintains load until generators start
UPS………………………………………………Redundant UPS takes over
Generator………………………………Redundant generator takes over
PDU………………………………………………Redundant PDU takes over
Disk drive……………………………RAID-1 mirroring in EMC
Gateway server…………………Other load-balanced servers take over
Application server………Other load-balanced servers take over
Database server………………Hot stand-by server takes over
Database…………………………………Services recovered on alternate EMC device
Network provider……………Load shifts to other network providers
Secondary site…………………Service continues at primary site
Primary site………………………Service shifts to secondary site

Redundant/Diverse Systems for Providing Service in the Event of Outage
VeriSign maintains redundant equipment to support the proposed registry at both
the primary and disaster recovery data centers. Although the primary facility
hosts the primary database, each facility is able to assume full operations due
to built-in redundancy. Also see the above table for redundant hardware
approaches to handle outages.

Process for Recovery from Various Types of Failures
Each facility contains a robust and redundant infrastructure, including
security, power, cooling, humidity, and fire suppression. Even if this
infrastructure were to completely fail at the Disaster Recovery Facility, it
will not result in any outage of the database. The most common types of
failures are automatically handled by built-in hardware and software features.

Our redundant site architecture also supports failure recovery. For example, a
failure at one Data Center will mean that all services could run from a backup
Data Center. Our QoS function ensures that the registry database will not be
subjected to any unnecessary or unexpected transaction volumes and thereby
ensure that we will continue to satisfy all SLAs. 

Training of Technical Staff
All VeriSign technical staff undergoes continuing training in system
restoration procedures. This training takes the form of system outage scenarios
(see Section E.2.n), responses (automatic and manual, where necessary),
documentation on hardware outages and restorations, and documentation of
indications of potential problems requiring maintenance actions.  

Availability of Backup Hardware Needed to Restore and Run the System
All hardware (and software) necessary to restore and run the system in the
event of failure is replicated either as a backup system at secondary
facilities. This well-proven architecture ensures that the system can be
restored to full operation in the event of a system outage of any type within a
short time frame without the loss of any critical data.

Backup Electrical Power Systems
Each data center incorporates a backup electrical power system that ensures
continuing service in the event of an electrical failure or planned shutdown of
any component.

Projected Time for System Restoration
Restoring critical services at the Disaster Recovery Facility, in the event of
a complete failure of the Primary Facility, can be accomplished in less than
eight hours. It may take up to 48 hours to restore the complete functionality
of all ancillary services. VeriSign performs periodic tests at this facility to
ensure the ability to recover functions such as zone file generation and WHOIS
generation. WHOIS servers are currently divided between both sites so that a
site failure will not interrupt WHOIS service. 

Procedures for Testing the Process of Restoring the System to Operation
Planned outages are subject to detailed planning and testing in a separate
“staging” environment. In addition to validating all steps to be performed
during the outage, back-out plans are developed and tested.

Documentation Kept on System Outages and Potential System Problems that Could
Result in Outages
In addition to backing up registry data to multiple sites using multiple media,
we maintain backup copies of hardware configurations and source code libraries.
Because of the locations of the two facilities, no additional staff is required
in the event of a site failure. We maintain detailed documentation and
statistics on system outages, their causes, and their remedies.

o. Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support services to be offered, time availability of support and language-availability of support.
Online user-provided support and maintenance for registered sTLD domains is
provided by a web site for each sTLD domain. Online support for the public is
provided by the public portions of the web site, which will list validated sTLD
Whois information for the registrant, abuse information, and any additional
information the registrant wishes to provide. Private portions of the web site
will be available to registrants to update their additional information as well
as their zone records. For example, registrants may add, modify or delete "A"
and "MX" records relating their sTLD domain to their key domain mail servers. 
The XO will not have any customer support interaction either with registrars or
registrants.

Support for Registrars, Internet Users, and Registrants. VeriSign, being the
RO, will provide a complete customer service solution for registrars, Internet
users, and registrants. Registrants and end users will be directed to their
Registrar for support, although we are available for escalation of very
high-level complaints related to policy and compliance. VeriSign maintains a
24x7 customer service desk (CSD) located within the NOC, which can instantly
escalate technical issues. The CSD addresses issues that require escalation
during normal business hours.
The VeriSign customer service function contains the following elements:
* Technical Help Systems 
* Personnel Accessibility 
* Web-based and Telephone Support Services 
* Other Support Services
* Time Availability of Support
* Language support

Technical Help Systems
For issues requiring technical expertise beyond what the CSD can provide, the
Network Operations Command Center (NOCC) and a skilled technical staff are
available 24x7 for any Severity 1 problem (i.e., problems materially affecting
a Registrar’s ability to do business). Technical issues that are not high
severity are handled during normal business hours.

Personnel Accessibility
VeriSign’s CSD personnel use advanced the Clarify customer relationship
management (CRM) software to track all customer contacts. The CRM software
provides the CSD staff with the ability to:
* Organize customer contact information
* Categorize requests by e-mail/telephone/web
* Organize company information
* Create Case Types (e.g., billing problem, technical problem, etc.)
* Create internal departments (e.g., Ops, Finance, Engineering)
* Dispatch customer requests to other departments
* Assign a level of priority to each customer request
* Create a database of solutions to various issues
* Generate summary reports

When communicating with Registrars, the CSD staff uses a Clarify case number
for future reference. A daily report is generated showing the status of all
open issues and distributed to the NOC, Operations, and Engineering
departments, as well as select members of the business organizations. These
departments use Clarify to document and research their assigned cases. This
results in a permanent audit trail of actions and status that can be accessed
in real-time by registry business, technical, and customer service staff.

Web-based and Telephone Services 
We will establish a web site to house important information and tools for the
Registrars, which will be accessible by using a userid and password assigned by
the CSD. All Registrars will be assigned a userid and password as part of the
certification process. The following list covers the types of material to be
made available to the Registrars:
* Software Development Kits in C and Java: Contains the source code required to
perform EPP commands
* OT&E Acceptance Criteria: Contains the tests cases required to be certified
as a .mail Registrar and allows Registrars to test their system before taking
the formal exam
* OT&E FAQs: Lists the most popular questions and answers we receive on ramping
up as a Registrar
* Calendar of Scheduled Maintenances: Lists the upcoming maintenance services
to be performed over the next 60 days
* News Bulletins: These announcements focus on customer feedback, bugs, changes
in policy, etc.
* Billing FAQs: Questions and answers related to the invoices generated for
Registrars.
* Links to Registrar Tool: Direct link to the web-based Registrar Tool
(described below).
* Registrar Tool User Guide: User guide on how to operate the Registrar Tool.
* Registrar Reference Manual: A non-technical guide to using EPP and
understanding the business rules applicable to domain and nameserver
registrations.

Other Support Services 
Web-based CSR tools will provide direct access to the registry database,
allowing them to perform domain name and nameserver maintenance on behalf of
Registrars. The CSR tool will allow finance staff to add or transfer monies
within Registrar accounts.

We will provide Registrars with a scaled-down version of the CSR tool. This
tool allows Registrars to be self-sufficient and less reliant on the CSD for
each domain name or nameserver issue. The features of this tool include:
* Domain Name maintenance: Modify, Delete, Renew, Transfer
* Nameserver maintenance: Create, Modify, Delete
* Registrar Account maintenance: add/delete contacts, check account balance

Registrar Reports (for additional reporting information please refer to Section
E.2.c):
* Daily Transaction Reports (previous-day creates/mods/del/renew activity)
* Daily Transfer Report (previous-day transfer activity)
* Daily AutoRenew Report (previous-day AutoRenew activity)
* Weekly Domain Name Report (list of all domain names owned by a Registrar)
* Weekly Nameserver Report (list of all nameservers owned by a Registrar)
* Weekly Domain Names Hosted Nameserver Report

Verisign will conduct a survey among the Registrar community twice a year. The
survey will measure the level of satisfaction among Registrars with our
registry service and their overall satisfaction with the business, technical,
and support aspects of the TLD registry. The survey will also allow Registrars
to provide feedback and suggestions regarding escalation, ramp-up, or finance
issues. Customer surveys will utilize a web site where Registrars can complete
the survey on-line in a matter of minutes, thereby increasing participation and
reducing cycle time. VeriSign will use survey results to improve system
operation and overall registrar satisfaction in specific areas of concern.

Time Availability of Support
VeriSign will staff the CSD 24x7 to handle the variety of Registrar issues that
may surface in support of the .mail sTLD. These issues normally focus on
connectivity problems, registration problems, reporting problems, domain name
or nameserver maintenance, and billing issues. On-site coverage allows the
support team to escalate issues immediately to either business or technical
teams on behalf of the Registrars. 

On-site support also assists with internal company escalations. If any issues
require communication with the Registrars, the CSD is able to communicate the
problem to the Registrars and handle questions or concerns from the customer
base.

The RO's CSD staff also facilitates communication with registrars in other time
zones thereby providing what is essentially a 24x7 virtual business office.
 
Language-Availability of Support
VeriSign will use Language Line for all telephone and document translation
needs. Language Line is a 24x7 operation that offers instant access to
interpreters versed in 152 languages, which represent 98 percent of all
language needs. This service has been instrumental in allowing the CSD to
communicate more easily with Registrars during escalations. If a Registrar is
having a problem, the CSD can instantly conference in an interpreter and
collect information regarding the Registrar’s problem. Minimal time is lost due
to language barriers.  Occasionally, foreign language e-mails are received at
the CSD. In these situations, an online translation tool on AltaVista
interprets the e-mail. Telephone calls remain the primary use for Language
Line. The use of a language service enables the CSD to support a large base of
languages at a reasonable cost.