Description of TLD Policies
[For
sponsored TLDs, this part of the application is to be completed by the
sponsoring organization. For unsponsored TLDs, the registry operator should
complete this part of the application. Please refer to the Detailed Application
Instructions for more information on the requirements for new TLD applications.
The
operation of a TLD involves the implementation of policies on a very large
number of topics. Applicants are urged to use their response to this part of
the application to demonstrate their detailed knowledge of what topics are
involved and their careful analysis and clear articulation of the policies they
propose on these topics.
Please
place the legend "CONFIDENTIAL" on any part of your description that
you have listed in item F3.1 of your Statement of Requested Confidential
Treatment of Materials Submitted.
Section
III of this application applies only to applicants for restricted TLDs.
Ordinarily, restricted TLDs should be sponsored.]
I.
GENERAL TLD POLICIES (Required for all TLDs. Note that two special policy areas‑‑policies
during the start‑up period and restrictions on who may register within
the TLD and for what purpose‑‑are covered in sections II and III
below.)
E1.
In General. Please provide a full and detailed description of all policies to
be followed in the TLD (other than those covered in response to items E11‑E21).
If the TLD's policy on a particular topic is proposed to be identical to that
reflected by a particular version of any of the following documents, it is
sufficient for your response to identify the topic, to give a brief summary of
the policy, and for the details to reference the document and section:
•
ICANN Registrar
Accreditation Agreement
•
NSI Registrar License
and Agreement
•
ICANN‑NSI
Registry Agreement
•
Uniform Dispute
Resolution Policy
Your
response should comprehensively describe policies on all topics to be followed
in connection with the proposed TLD. The following items (E2‑E10) are examples
only and should not limit your description.
E2.
TLD String. Please identify the TLD string(s) you are proposing. For format
requirements for TLD strings, see the answer to FAQ #5.
Diebold
is proposing a registry for the following generic Top Level Domains:
.GLOBAL
.SECURE
.CASH
Diebold
also stands ready to discuss the potential for hosting TLD registry for
Sponsored TLD needing a host provider.
E3.
Naming conventions. Describe the naming conventions and structure within the
TLD. E.g., will registrants have names registered at the second level (directly
under the TLD, as in registered‑name.com), or will the TLD be organized
with sub‑domains so that registered domain names are created at a lower
level (as in registered‑name.travel.com)?
All registrations within the Diebold proposed TLDs will be at the “second level”.
E4.
Registrars. Describe in detail the policies for selection of, and competition
among, registrars. Will domain‑name holders deal through registrars,
directly with the registry operator, or some combination of the two? What are
the respective roles, functions, and responsibilities for the registry operator
and registrars? If registrars are to be employed, how and by whom will they be
selected or accredited? If the number of registrars will be restricted, what
number of registrars will be selected? Have the qualifying registrars already
been selected? On what basis will selections among those seeking to be
registrars be made, and who will make them? If registrars are to be used, what
mechanisms will be used to ensure that TLD policies are implemented?
Diebold
proposes operating as both registry and registrar for the proposed TLDs. Diebold
is of the opinion that the highest potential for stability and success, and
lowest potential for risk, exists in a new TLD registry system based on this
model.
Diebold believes it is in
the best interest of Diebold, ICANN and the Internet community to establish a
stable TLD registry model before considering working with potential registrars.
E5.
Intellectual Property Provisions. Describe the policies for protection of
intellectual property. Your response should address at least the following
questions, as appropriate to the TLD:
E5.1. What measures will be taken to discourage registration
of domain names that infringe intellectual property rights?
Diebold will discourage such infringements by stating to potential registrants, in very clear language, the policies as set forth in E5.2 (below). During the “sunrise” period (see below), registrants will be required to “Click To Accept” the terms of the “sunrise” period trademark protections.
E5.2. If you are proposing pre‑screening for
potentially infringing registrations, how will the pre‑screening be
performed?
Diebold will not perform “pre-screening” per se. Diebold is not positioned to review each
application for potential trademark infringement.
Diebold does propose a ninety (90) day “sunrise” period during which holders of existing trademarks may register their trademarks into the new TLDs. Diebold will, as an integral part of the registration process, allow registrants the opportunity to provide written documentation, such as registration certificate or international equivalent, providing proof of the trademark holders’ rights for at least the prior twelve months. Diebold will hold this documentation during the sunrise period and for an additional 2 years.
During this “sunrise” period, “normal” registrants would be advised in clear, understandable language, that all registrations during the “sunrise” period would be subject to revocation based on documented proof of trademark rights by another party. Registrants found to be out of compliance would be required to select another domain name in the same TLD at no additional charge.
Disputes regarding domain name infringement upon a
trademark holder’s rights will be referred by Diebold to the ICANN UDRP
process.
E5.3. What registration practices will be employed to
minimize abusive registrations?
Diebold is not an arbiter of taste nor morality, and wishes to avoid such a role.
Diebold will work with ICANN and the Internet community toward mutually agreeable policy on abusive registrations.
E5.4. What measures do you propose to comply with applicable
trademark and anti‑cybersquatting legislation?
Diebold will comply with all US and International (where appropriate) laws regarding trademarks and anti-cybersquatting. Diebold will employ objective and predictable measures, as stated above, to provide for the most straight-forward approach to avoiding trademark and cybersquatting situations.
Diebold will provide a registration certificate to a court under the in rem provisions of the Lanham Act. Diebold will comply with any court order issued in litigation related to a domain name. If Diebold is named a party to such litigation, Diebold will act upon the recommendation of competent counsel.
E5.5. Are you proposing any special protections (other than
during the start‑up period) for famous trademarks?
Diebold is not in a position to determine what trademarks are “famous”. Diebold endorses the concept of the UDRP and would encourage further development and refinement of its precepts and processes.
E5.6. How will complete, up‑to‑date, reliable,
and conveniently provided Whois data be maintained, updated, and accessed
concerning registrations in the TLD?
Information regarding domain name registrations and
registrants will be maintained on a separate whois server maintained as part of
the overall Registry System. Please
refer to the Registry Operator’s Proposal portion of our application for
functional details.
Diebold will provide open access to all whois
information.
Diebold anticipates making every reasonable effort to
adjust incorrect registration information.
Diebold anticipates suspending registrations where
intentionally misleading, malicious or false information has been provided to
the Registry System.
E6.
Dispute Resolution. Describe the policies for domain name and other dispute
resolution. If you are proposing variations to the policies followed in .com,
.net, and .org, consider the following questions:
E6.1. To what extent are you proposing to implement the
Uniform Dispute Resolution Policy?
Diebold endorses the concept of the UDRP and would encourage further development and refinement of its precepts and processes.
E6.2. Please describe any additional, alternative, or
supplemental dispute resolution procedures you are proposing.
Diebold is concerned about the potential for intentionally
misleading, malicious or false information has been provided to the Registry
System. Diebold will work with ICANN
and the Internet community to determine appropriate policy for the resolution
of such occurrences.
E7.
Data Privacy, Escrow, and Whois. Describe the proposed policies on data privacy,
escrow and Whois service.
Diebold will provide open access to all whois information. Registrants will be required to accept a prominently displayed notification of this policy before completing the registration.
Diebold makes no claim to the whois information. Diebold will consider the whois information to be in the public domain.
E8.
Billing and Collection. Describe variations in or additions to the policies for
billing and collection.
The Diebold Registry Proposal incorporates immediate billing via debit or credit card. Invoicing is not planned as a normal method by which registration fees would be collected.
Diebold is capable of generating invoices as the business need would arise.
Diebold
has vast experience dealing with financial transaction systems. All customer billing information, except
that which would be in common with typical “whois” information, will be kept in
the strictest of confidence.
E9.
Services and Pricing. What registration services do you propose to establish charges
for and, for each such service, how much do you propose to charge?
Diebold
proposes the following services, with pricing:
-
Domain Name Registration $10.00US/year*
-
DNS Hosting for Registrants (at time of registration) N/C
-
Website “Placeholder” Hosting $5.00/month
-
TLD Registry Hosting To
be negotiated with TLD Sponsoring Organization
*Please see section E14 for the special pricing structure for the startup period.
E10.
Other. Please describe any policies concerning topics not covered by the above
questions.
II.
REGISTRATION POLICIES DURING THE START‑UP PERIOD (Required for all TLDs)
E11.
In this section, you should thoroughly describe all policies (including
implementation details) that you propose to follow during the start‑up
phase of registrations in the TLD, to the extent they differ from the General
TLD Policies covered in items E1‑E9. The following questions highlight
some of the areas that should be considered for start‑up policies:
E12.
How do you propose to address the potential rush for registration at the
initial opening of the TLD? How many requested registrations do you project
will be received by the registry operator within the first day, week, month,
and quarter? What period do you believe should be considered the TLD's
"start‑up period," during which special procedures should
apply?
Please see section E14 for pricing mechanisms during the startup period.
Diebold
anticipates, and has designed its systems to handle, the following registration
levels for each new TLD:
-
Day 1 10,000
-
Week 1 50,000
-
Month 1 175,000
-
Quarter 1 350,000
Aggregate
numbers for 3 TLDs:
-
Day 1 30,000
-
Week 1 150,000
-
Month 1 525,000
-
Quarter 1 1,050,000
Diebold
reserves the right to limit simultaneous connections to the
registry/registration system during the startup period to allow for system
performance observation and adjustment.
Diebold
believes a 120 day startup period is appropriate.
E13.
Do you propose to place limits on the number of registrations per registrant?
Per registrar? If so, how will these limits be implemented?
Diebold will place no limits on the number of registrations per registrant.
E14.
Will pricing mechanisms be used to dampen a rush for registration at the
initial opening of the TLD? If so, please describe these mechanisms in detail.
- First 50,000 registrations per TLD $30.00
per domain name
- Registrations 50,001 – 100,000 $20.00
per domain name
- All registrations 100,000 and beyond $10.00 per
domain name
E15.
Will you offer any "sunrise period" in which certain potential
registrants are offered the opportunity to register before registration is open
to the general public? If so, to whom will this opportunity be offered (those
with famous marks, registered trademarks, second‑level domains in other
TLDs, pre‑registrations of some sort, etc.)? How will you implement this?
Diebold does not endorse the practice of pre-registration, where pre-registration is defined as being prior to the acceptance of our proposal.
Diebold
does see the value of offering pre-registration to all parties, subject to the
“sunrise” policy stated above, AFTER acceptance of our proposal and subsequent
agreement with ICANN, and BEFORE final systems modifications for operation are
made. While Diebold has been operating
systems in each of the proposed TLDs for more than a year, it is anticipated
that changes will be necessary before the systems are fully operational.
III.
REGISTRATION RESTRICTIONS (Required for restricted TLDs only)
E16.
As noted in the New TLD Application Process Overview, a restricted TLD is one
with enforced restrictions on (1) who may apply for a registration within the
domain, (2) what uses may be made of those registrations, or (3) both. In this
section, please describe in detail the restrictions you propose to apply to the
TLD. Your description should should define the criteria to be employed, the
manner in which you propose they be enforced, and the consequences of violation
of the restrictions. Examples of matters that should be addressed are:
E17.
Describe in detail the criteria for registration in the TLD. Provide a full
explanation of the reasoning behind the specific policies chosen.
N/A
E18.
Describe the application process for potential registrants in the TLD.
N/A
E19.
Describe the enforcement procedures and mechanisms for ensuring registrants
meet the registration requirements.
N/A
E20.
Describe any appeal process from denial of registration.
N/A
E21.
Describe any procedure that permits third parties to seek cancellation of a TLD
registration for failure to comply with restrictions.
N/A
IV.
CONTEXT OF THE TLD WITHIN THE DNS (Required for all TLDs)
E22.
This section is intended to allow you to describe the benefits of the TLD and
the reasons why it would benefit the global Internet community or some segment
of that community. Issues you might consider addressing include:
Please see sections E23 through E27 for information regarding TLD benefits.
E23.
What will distinguish the TLD from existing or other proposed TLDs? How will
this distinction be beneficial?
Diebold
proposed three new TLDs to:
-
Expand the available gTLD name space, which has been somewhat depleted
-
Foster affinity groups for types of organizations providing information
and services across the Internet
-
Create a competitive TLD environment
The
specific TLDs have the following potential benefits, among others:
-
.GLOBAL
o
For organizations with information, products and services of a
multinational and/or global nature
o
Open to all potential registrants, to foster global growth for
organization not currently of an multinational or global nature
o
Competitive with existing and any additional gTLDs providing both name
space growth and a competitive domain name price model
-
.SECURE
o
For organizations with information, products and services of a secure
and/or sensitive nature. While the TLD
itself will not provide any additional security, Diebold proposes a TLD where
organizations may focus secure aspects of their services, creating an affinity
group
o
For organizations wishing to establish secure Internet connectivity, the
TLD offers an affinity group
o
For organizations wishing to promote an image of security
o
Competitive with existing and any additional gTLDs providing both name
space growth and a competitive domain name price model
-
.CASH
o
For organizations with information, products and services of a financial
and/or monetary nature
o
Competitive with existing and any additional gTLDs providing both name
space growth and a competitive domain name price model
E24.
What community and/or market will be served or targeted by this TLD? To what
extent is that community or market already served by the DNS?
Diebold
proposes no limits on the available market for these new TLDs. However, there would likely be specific affinity
groups/communities that would have specific use of these TLDs. Some potential examples are below:
-
.GLOBAL
o
International corporations
o
International trade organizations
o
Other organizations wishing to promote a global presence
-
.SECURE
o
ISPs wishing to provide secure/VPN services
o
Financial institutions wishing to provide secure financial transaction
services across the Internet
o
Organizations wishing to provide security services over the Internet
(alarms, security monitoring, etc.)
o
Other organizations seeking to promote an image of security
-
.CASH
o
Financial institutions and other organizations as a method of
identification for Internet connected self-service devices
o
Organizations dealing with financial transactions, access to funds, etc.
E25.
Please describe in detail how your proposal would enable the DNS to meet
presently unmet needs.
Diebold’s
proposal addresses several poignant issues.
First,
the additional gTLDs would help alleviate the current shortage of meaningful
domain names in the current gTLDs.
Second, the TLDs .SECURE and .CASH allow for an organic process of self organization toward affinity groups on the Internet. This was an initial intent of the current TLDs .COM, .NET, .ORG, .EDU, .MIL, .GOV, etc.
Additionally,
Diebold believes that, as part of a group of additional TLDs, the proposed TLDs will significantly strengthen
the Internet domain name space.
E26.
How would the introduction of the TLD enhance the utility of the DNS for
Internet users? For the community served by the TLD?
Diebold
proposed three new TLDs to:
-
Expand the available gTLD name space, which has been somewhat depleted
-
Foster affinity groups for types of organizations providing information
and services across the Internet
-
Create a competitive TLD environment
Diebold believes that the introduction of general use TLDs, affinity group TLDs, and restricted use TLDs would allow for the organic self organization and growth of the Internet DNS space.
E27.
How would the proposed TLD enhance competition in domain‑name
registration services, including competition with existing TLD registries?
Diebold
proposes an aggressive pricing structure while eliminating the “middle man” –
the third party registrar. We believe
this structure allows for the most efficient level of operation and highest
probability for competitive pricing.
V.
VALUE OF PROPOSAL AS A PROOF OF CONCEPT (Required for all TLDs)
E28.
Recent experience in the introduction of new TLDs is limited in some respects.
The current program of establishing new TLDs is intended to allow evaluation of
possible additions and enhancements to the DNS and possible methods of
implementing them. Stated differently, the current program is intended to serve
as a "proof of concept" for ways in which the DNS might evolve in the
longer term. This section of the application is designed to gather information
regarding what specific concept(s) could be evaluated if the proposed TLD is
introduced, how you propose the evaluation should be done, and what information
would be learned that might be instructive in the long‑term management of
the DNS. Well‑considered and articulated responses to this section will
be positively viewed in the selection process. Matters you should discuss in
this section include:
E29.
What concepts are likely to be proved/disproved by evaluation of the
introduction of this TLD in the manner you propose?
-
The value of the single registry/registrar model
-
The value of additional generally available TLDs to augment the DNS name
space
-
The value of operating new TLDs within the structure of an established,
proven company with a track record for success
-
The value of allowing an organic self-organization process for affinity
groups on the Internet
E30.
How do you propose that the results of the introduction should be evaluated? By
what criteria should the success or lack of success of the TLD be evaluated?
Diebold proposes a simple approach toward the assessment of the new TLDs:
- Number of registrations / acceptance by the Internet community
- Number of problems during the startup period
- Nature of problems during the startup period
- Problem handling characteristics of the registry organization
- Affect / lack thereof on the existing DNS
- Assessment of the new TLDs in comparison with other new TLDs in the startup period
- Assessment of new TLD registry hosting organizations in comparison with other new TLD registry organizations in the startup period
E31.
In what way would the results of the evaluation assist in the long‑range
management of the DNS?
Diebold believes this can only be assessed as a part of the process of introducing new TLDs and registries. Diebold anticipates working with ICANN and the Internet community to learn from the process, and apply this new knowledge to future DNS enhancements.
E32.
Are there any reasons other than evaluation of the introduction process that
this particular TLD should be included in the initial introduction?
ICANN
needs to form a core group of solid, reliable organizations for the
appropriate, stable expansion of the DNS.
The Diebold proposal offers a very high probability for success due to
our proven track record and considerable resources, both in funding and
personnel.
Diebold
believes that the selection of solid, proven organizations as new registries is
as, or more, important than the TLDs approved.
Selection of Diebold by ICANN represents a choice of just such a solid
organization.
We
look forward to working with ICANN to enhance the DNS in a stable and well
supported manner.
By signing
this application through its representative, the Applicant attests that the
information contained in this Description of TLD Policies, and all referenced
supporting documents, are true and accurate to the best of Applicant's
knowledge.
_______________________________
Signature
_______________________________
Name
(please print)
_______________________________
Title
_______________________________
Name
of Applicant Entity
_______________________________
Date
(c) 2000 The Internet Corporation for Assigned Names
and Numbers
All rights reserved.
Updated August 15, 2000