Description of TLD Policies


 

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.

 

Diebold proposes a sliding price scale per registration, based on the aggregate number of registrations received.  Diebold believes this will encourage a higher level of appropriate registrations, while discouraging raw speculative registrations.

 

-  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:

 

N/A

 

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