[INSTRUCTION: 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.
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)?
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?
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?
E5.2. If you are proposing pre-screening for potentially infringing registrations, how will the pre-screening be performed?
E5.3. What registration practices will be employed to minimize abusive registrations?
E5.4. What measures do you propose to comply with applicable trademark and anti-cybersquatting legislation?
E5.5. Are you proposing any special protections (other than during the start-up period) for famous trademarks?
E5.6. How will complete, up-to-date, reliable, and conveniently provided Whois data be maintained, updated, and accessed concerning registrations in the TLD?
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?
E6.2. Please describe any additional, alternative, or supplemental dispute resolution procedures you are proposing.
E7. Data Privacy, Escrow, and Whois. Describe the proposed policies on data privacy, escrow and Whois service.
E8. Billing and Collection. Describe variations in or additions to the policies for billing and collection.
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?
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?
E13. Do you propose to place limits on the number of registrations per registrant? Per registrar? If so, how will these limits be implemented?
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.
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?
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.
E18. Describe the application process for potential registrants in the TLD.
E19. Describe the enforcement procedures and mechanisms for ensuring registrants meet the registration requirements.
E20. Describe any appeal process from denial of registration.
E21. Describe any procedure that permits third parties to seek cancellation of a TLD registration for failure to comply with restrictions.
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:
E23. What will distinguish the TLD from existing or other proposed TLDs? How will this distinction be beneficial?
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?
E25. Please describe in detail how your proposal would enable the DNS to meet presently unmet needs.
E26. How would the introduction of the TLD enhance the utility of the DNS for Internet users? For the community served by the TLD?
E27. How would the proposed TLD enhance competition in domain-name registration services, including competition with existing TLD registries?
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?
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?
E31. In what way would the results of the evaluation assist in the long-range management of the DNS?
E32. Are there any reasons other than evaluation of the introduction process that this particular TLD should be included in the initial introduction?
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
Henry
A. Lubsen, Jr.
Name (please print)
President
Title
iDomains,
Inc.
Name of Applicant(s)
September
30, 2000
Date
General TLD Policies
This
section provides a full and detailed description of all policies that will be
followed for the TLDs that iDomains is proposing. With the exception of the
proposals noted below, and except as mutually agreed upon with ICANN, iDomains
will implement all existing ICANN policies and operational functions of
Verisign Global Registry Services (VGRS) in the operation of the new TLD.
iDomains, Inc. proposes the following TLD strings in order of preference for a chartered top-level domain focusing on the enhancement of electronic commerce: ".BIZ", ".EBIZ", or ".ECOM".
Proposed Dual Co-Existent Naming System
iDomains proposes a dual co-existent naming system that will incorporate both second and third level domain name registrations. To facilitate this system, certain second level domains will be permanently retained by the registry to provide third-level domain name registrations.
Reserved Second Level Domain Names
All two-letter domains will be retained to replicate the existing country code top-level domain system. Further, a limited number of additional second level domains may be reserved to create a directory listing service within the top-level domain (e.g., sme.biz for small to medium enterprise business, .min.biz for minority-owned businesses, etc). These second level domains will be used to provide a hierarchical structure to the top-level domain that will be incorporated into a proposed directory service.
Multi-Level Registrations
The multi-level domain name registrations (second and third level) will be offered as a single package. A domain name registrant will be able to register a second level domain at the initial registration, and replicate that domain name as a third level domain in any relevant second level domain offered by iDomains. The domain name registrant will be given a choice of one free third level domain to register. The registrant will have the option to register additional third level domains pursuant to a fee schedule. Such registrant would be under no obligation to register such additional third-level domains, and the registrants string will be protected against registrations by other parties in the third levels offered by iDomains (in that no other registrant would be permitted to register third level domains using the same second level string).
The idea of this dual co-existent naming system was conceived to bridge the gap between the United States' general population, living primarily in a second level-world (domain-name.com), and the rest of the world that lives primarily in a third level domain world (e.g., domain-name.co.uk). iDomains recognizes that businesses throughout the world perceive value in publicizing their county of domicile in various manners, including the domain name under which they do business. For instance, businesses in South Korea or England may be more comfortable today doing business online using a third-level domain under .co.kr or .co.uk, respectively, rather than .com. Such registrants may find great value in being able to market their services under company-name.uk.biz or company-name.kr.biz. Further, such registrant could market to different geographical regions using different country-specific domains.
We strongly believe this dual co-existent naming system is both technically viable and culturally sensitive, and represents an excellent proof-of-concept for creative uses of the domain name system. Should ICANN's technical staff in its judgment believe that this dual co-existent should not be used during the proof of concept stage, we remain open to the idea of reserving the above referenced second level domain names for future use and roll-out the new top-level domain with second domain name registrations only. The exact nature and number of second level domains to be reserved will not be determined until iDomains is able to consult with its Business Advisory Committee (BAC) (described in Section E10 below) on the needs of the business community.
Will domain-name holders deal through registrars, directly with the
registry operator, or some
combination of the two?
We propose a process essential identical to the current registrant/registrar/registry relationship, domain name registrants will enter into domain name registration agreement (DNRA)with a qualified registrar who will then register the domain name on behalf of the registrant with iDomains. Prior to being eligible to provide domain name registration services to its customer, the registrar will have to enter into a registrar licensing agreement (RLA) that sets forth the contractual responsibilities that exist between the registrar and registry.
Each registrar, and any of its sales affiliates, will be required as part of their contractual obligations to disclose to domain name registrants the registrar of record along with certain minimum associated contact information to enhance customer confidence and service.
What are
the respective roles, functions, and responsibilities for the registry operator
and registrars?
iDomains will provide the same basic services as currently provided by VGRS except in the context of the following functions:
§ Unlike the current VGRS "thin" registry model that requires all Whois information to be maintained by the registrar, iDomains will employ a "thick" registry model.
§ Maintenance of a "thick" registry model will enable iDomains to provide significant enhancement to this proposed registry; that being a "UNIFIED WHOIS QUERY", a valuable functionality that currently is not available in the .COM, .ORG and .NET top-level domains, (the absence of which has resulted in fragmented Whois data availability).
§ iDomains also contemplates offering value added services to .BIZ domain name registrants. Such services would be provided by iDomains, or via third-party vendors. However, in order to adhere to the contractual relationships set forth above, either the registrar of record or the third party vendor will interact with the domain name registrant with a mutually agreed revenue sharing model. Such services could include Domain Name Monitoring and Service History Reports (as described in Section D13.2.1 of the Registry Operator’s Proposal).
§
In addition, iDomains will provide a "subscription
based" enhanced multi-field Whois search engine service. This service is primarily geared toward the
intellectual property community and associated businesses. We also intend to
provide this service to appropriate law enforcement agencies on a no charge
basis. This service will be available
to the registrars to resell to their customers.
§
Bulk access to the whois database would be available to
any ICANN accredited registrar for resale by such registrar to its
customers. Any resale by such registrar
would be subject to ICANN policies (e.g., the registrar could not charge more
than $10,000 per year for the data). Further,
the registrars would be required to obtain from the end user an agreement (in a
form approved by iDomains) to use the information only for lawful purposes and
in no event for purposes that would constitute abuse of the data, such as
facilitating high volume commercial e-mail.
As further protection against abusive uses of the bulk whois data, all e-mail addresses displayed in the bulk whois will be replaced in the form of CONTACT-HANDLE>@handles.registry.biz within the following guidelines:
E-mail received at <CONTACTHANDLE>@handles.registry.biz will be forwarded to the contact's real e-mail address. If the E-Mail address becomes invalid or bounces, the forwarding mechanism will be disabled and the contacts true e-mail address will be put into the bulk whois data.
This default mechanism
for all registrations is designed to enable spam prevention; however, upon
request of a registrant, such registrant may have their default changed to
disabled. The true and correct contact's e-mail address will be disclosed to
courts and police upon request.
Using the above policies will enable the registry to mitigate spam on the
behalf of registrants. Should a mass mailing be sent to registrants within the
.BIZ registry, the registry will be able to file appropriate legal action as
the e-mail addresses could have only been mined from the registry whois. We
believe that e-mail spam prevention and detection will become an industry
standard as we will be able to show just how much the whois database is used as
a source for spammer lists.
The .BIZ registry will
make available to the Internet Community additional statistics, sample spam,
and know spam origination sites. The .BIZ Registry will work with Industry
anti-spam and UCE prevention leaders such as RBL/Maps Project and other
anti-spam organizations to encourage the responsible use of whois data.
Fees collected by iDomains for provision of bulk whois service will be used to fund marketing projects designed to increase awareness of the .BIZ brand, and thus increase business for registrars, as well as the registry.
ICANN accredited registrars will have the same roles and functions as they currently do with regard to billing and customer support. The only differences will be those responsibilities associated with Whois and escrow requirements.
If registrars are to be employed, how and by whom
will they be selected or accredited?
iDomains will allow registrars that are accredited by ICANN to register in the .BIZ registry. However, iDomains will require such registrars to demonstrate their technical capability to properly interface with the registry prior to being able to register domain names in the ".BIZ" registry. iDomains will charge a small cost recovery based fee ( we are projecting in the area of $500.00) to defer its costs in connection with the technical interface compliance requirements.
If the
number of registrars will be restricted, what number of registrars will be
selected?
There will be no restriction on the number of registrars. All ICANN accredited registrars will be eligible to provide registration services in the .BIZ registry provided that they sign the RLA and meet the necessary minimum technical interface requirements.
Have the
qualifying registrars already been selected?
All ICANN accredited registrars will be eligible to provide registration services in the .BIZ registry provided that they sign the RLA and meet the necessary minimum technical interface requirements.
On what
basis will selections among those seeking to be registrars be made, and who
will make them?
All ICANN accredited registrars will be eligible to provide registration services in the .BIZ registry provided that they sign the RLA and meet the necessary minimum technical interface requirements.
If
registrars are to be used, what mechanisms will be used to ensure that TLD
policies are implemented?
iDomains will employ a registrar compliance liaison to proactively monitor registrar compliance with the RLA as well as aggressively investigating consumer or third party complaints.
What
measures will be taken to discourage registration of domain names that infringe
intellectual property rights?
iDomains will employ the following mix of measures to minimize abusive domain name registrations:
§ The use of a "Sunrise Program" to allow qualifying trademark owners to pre-register their respective trademarks as domain names;
§ Adoption of the Uniform Dispute Resolution Policy (“UDRP”) as promulgated by ICANN;
§ Requiring pre-payment prior to registering a domain name;
§ Stringent enforcement of domain name registrants providing and updating accurate Whois information;
§ Adopting a two-year minimum registration period;
§ Providing an enhanced subscription-based multi-field Whois queried database, as well as bulk whois access; and
§
Providing a Whois data watch service to notify domain
name registrants when any information contained in the Whois fields has
changed.
If you are proposing pre-screening for potentially
infringing registrations, how will the pre-screening be performed?
There will be no pre-screening of domain names with regard to potential intellectual property violations. During the Sunrise Period, however, registrants will be required (i) to represent that they have a valid registered trademark in the character string for which they apply, (ii) to provide the country from which such registration issued and (iii) to enter the registration number of such mark. Such information will assist the Internet community to ascertain the legitimacy of the registration.
Further, all registrants will be obligated to provide a national business tax identification number (or equivalent) prior to a domain name registration being added to the zone files. The exact nature of this requirement is set forth in more detail in Sections E.16 thru E.21.
What
registration practices will be employed to minimize abusive registrations?
iDomains believes the following practices, in addition to protecting intellectual property, will minimize abusive registrations: the institution of a Sunrise Program, the adoption of the UDRP, requiring pre-payment for registrations, requiring a minimum two-year initial registration, a commitment to stringent enforcement of accurate Whois data, and providing enhanced Whois search capabilities.
What
measures do you propose to comply with applicable trademark and
anti-cybersquatting legislation?
iDomains believes that by instituting a Sunrise Period, adopting the UDRP, requiring pre-payment for registrations, requiring a two-year minimum term for initial registrations, stringently enforcing the requirement that registrants maintain accurate whois data, and providing enhanced Whois search capabilities, in addition to minimizing abusive domain name registrations, will facilitate maximum compliance with applicable trademark and anti-cybersquatting legislation.
iDomains is committed to complying with all trademark and anti-cybersquatting legislation.
Are you
proposing any special protections (other than during the start-up period) for
famous trademarks?
Other than the Sunrise Program, detailed in Section E.15, iDomains does not propose any special protections for famous trademarks. As stated above, iDomains believes that by instituting a Sunrise Period, adopting the UDRP, requiring pre-payment for registrations, requiring a two-year minimum term for initial registrations, stringently enforcing the requirement that registrants maintain accurate whois data, and providing enhanced Whois search capabilities, will provide maximum protection for holders of registered trademarks worldwide.
How will
complete, up-to-date, reliable, and conveniently provided Whois data be
maintained, updated, and accessed concerning registrations in the TLD?
iDomains plans to provide a publicly accessible centralized Whois as a result of the "fat" nature of the registry. Because of the centralized location of the data, iDomains will undertake a regular scheduled statistical sampling of Whois data to guarantee its accuracy, as part of it charter enforcement guidelines. This sampling will employ the use of a variety of algorithms, i.e. missing data fields, address verification, check sum values, etc.
Any Whois inaccuracies or irregularities uncovered during this sampling will be forwarded to the appropriate registrar to correct. Failure to remedy inaccurate data in a timely fashion may result in the domain name being deleted.
As mentioned above, iDomains plans to offer a Whois data watch service to notify a domain name registrant of any changes in the Whois data fields. This feature is particularly useful in light of the recent rash of domain name hi-jacking incidents.
iDomains is also awaiting guidance from the ICANN Whois Taskforce with regard to technical considerations involving Whois data, and is closely following the international privacy directives involving Whois data. In light of these dynamic situations, iDomains stands ready to modify its Whois and privacy policies to meet the technical or legal directives established by the appropriate governing bodies.
To what
extent are you proposing to implement the Uniform Dispute Resolution Policy?
iDomains plans to adopt the
current Uniform Dispute Resolution Policy, as amended by ICANN from time to
time, in its entirety.
Please
describe any additional, alternative, or supplemental dispute resolution
procedures you are proposing.
According to the terms of the RLA, iDomains and its contracting registrars will be required to submit to binding arbitration for disputes arising out of the RLA.
Describe the proposed policies on
data privacy, escrow and Whois service.
iDomains is currently waiting guidance from the ICANN Whois and Escrow Taskforces with regard to these important issues. However, until such time that ICANN provides further instructions, iDomains will adhere to the following policies:
Data Privacy
iDomains is keenly aware of the international debate and dynamics involving individual privacy rights in Whois data. At this time, iDomains intends to comply with the terms of the ICANN-NSI Registry Agreement dated November 4, 1999. However, as a result of the chartered nature of the .BIZ top-level domain, registrants will be precluded from registering a domain name for non-commercial use in this domain. Therefore, concerns over individual privacy rights associated with Whois data should be minimized.
As part of any licenses to access the Whois data in bulk, there will be restrictions limiting the use of such data, (e.g., a prohibition against using the data to enable unsolicited commercial e-mail).
As further protection against abusive uses of the bulk whois data, all e-mail addresses displayed in the bulk whois will be replaced in the form of CONTACT-HANDLE>@handles.registry.biz within the following guidelines:
E-mail received at <CONTACTHANDLE>@handles.registry.biz will be forwarded to the contact's real e-mail address. If the E-Mail address becomes invalid or bounces, the forwarding mechanism will be disabled and the contacts true e-mail address will be put into the bulk whois data.
This default mechanism for all registrations is designed to
enable spam prevention; however, upon request of a registrant, such registrant
may have their default changed to disabled. The true and correct contact's
e-mail address will be disclosed to courts and police upon request.
Using the above policies will enable the registry to mitigate spam on the
behalf of registrants. Should a mass mailing be sent to registrants within the
.BIZ registry, the registry will be able to file appropriate legal action as
the e-mail addresses could have only been mined from the registry whois. We
believe that e-mail spam prevention and detection will become an industry
standard as we will be able to show just how much the whois database is used as
a source for spammer lists.
The .BIZ registry will make available to the Internet Community
additional statistics, sample spam, and known spam origination sites. The .BIZ
Registry will work with Industry anti-spam and UCE prevention leaders such as
RBL/Maps Project and other anti-spam organizations to encourage the responsible
use of whois data.
Escrow Service
iDomains will implement a data escrow policy as documented in the current ICANN-NSI Registry Agreement. Because of the "thick" nature of the .BIZ registry (all Whois information residing at the registry level), registrars will not be required to independently escrow Whois information for .BIZ domain name registrations. It is our understanding that ICANN is currently in the process of reviewing the “Escrow Process” with a goal of making it more uniform and efficient across-the-board. It is our intent to strictly adhere to any guidelines which may evolve thru the above mentioned review process.
Whois Service
iDomains will provide an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date registry database. Additionally, iDomains contemplates providing an additional subscription service that will allow subscribers the ability to run complex queries across multiple fields. iDomains will closely monitor subscribers' usage to ensure that this feature is not being used inappropriately.
Finally, bulk whois access will be provided as described in Section E4 above.
Describe variations in or
additions to the policies for billing and collection.
iDomains will comply with current billing and collection practices, i.e. letter of credit, reasonable assurances of payment, refunds, etc. The only significant modification will be in connection with domains that are registered by the registrar but which are not paid for by the domain name registrant. In accordance with our proposed RLA, a registrar will have to delete a domain name after a “commercially reasonable” passage of time in which payment should have been received. In such a case, the registrar shall delete the domain name and it will immediately be released into the available domain name pool.
What registration services do you
propose to establish charges for and, for each such service, how much do you
propose to charge?
Registrars will not be required to pay a software licensing fee. However, iDomains will charge a small cost recover y based fee (Currently estimated to be approximately USD $500.00) to defer the cost of the registry in connection with the initial technical interface compliance requirements for each registrar. This process is similar to the technical certification that ICANN accredited registrars must pass prior to being able to go live with VGRS.
With regard to domain name pricing, iDomains will
require an initial minimum two year
registration period to minimize domain name speculation with a maximum term of
ten years. The registry fee for a single year domain name registration is
anticipated to be $5.45.
iDomains'
primary focus will initially be providing domain name registration services to
the registrars. We envision expanding
its scope of services to provide other services after the initial roll-out.
However, these services would not be designed to compete directly with our
established sales channels (the registrars). Some of these potential services
that iDomains may offer, include:
·
Enhanced
multi-field Whois queries - this would be a subscription service with an annual
single user fee of approximately two hundred dollars.
· Bulk Whois data access - provided as described in Section E4 above and Section D13.2.1 of the Registry Operator’s Proposal. We anticipate charging registrars $5,000 per end-user license for this service, which could be resold by the registrars to their customers. Any proceeds to iDomains from such service will be used to fund marketing projects designed to increase awareness of the .BIZ brand, and thus increase business for registrars, as well as the registry.
· A Whois data watch service to notify domain name registrants when any information contained in the whois fields has changed - iDomains may provide this service itself, or through third party vendors. No pricing has been determined at this time.
· As part of the dual naming system described in Section E3 above, iDomains envisions providing a directory service to the Internet community. It is possible a registrant will be afforded the opportunity to customize the information on its business in such directory on a fee basis, however no fee schedule has been developed at this time.
· IDomains plans to offer Service History Reports as described in Section D13.2.1 of the Registry Operator’s Proposal, however no fee schedule has been developed for such services at this time.
Please describe any policies
concerning topics not covered by the above questions
iDomains recognizes that ICANN has indicated that restricted top level domains normally should be sponsored. We believe that the full sponsorship model is not required for a top level domain developed for the commerce space. The policies inherent to such a model should not be markedly distinct from existing ICANN policies in our view. The .BIZ TLD is distinguished more from the services offered to registrants that the policies associated with the registry.
We also recognize, however, that there are advantages to drawing upon the knowledge and resources of a broad base of base of experts in global business issues. iDomains acknowledges that in order for this registry to fulfill its mission of promoting the development of e-commerce on a global scale, the registry must solicit input from experts from around the world. With this in mind, iDomains proposes to create a Business Advisory Committee (BAC) that with will provide recommendations on how to promote the responsible growth of e-commerce.
The BAC will have an advisory role to the iDomains Board of Directors similar to that of the relationship between ICANN and the Government Advisory Committee. It is estimated that the BAC will be composed of approximately 10 to 15 persons and that there will be proportional representation from each of the five ICANN geographic regions.
In preparing this registry proposal bid, iDomains has been in contact with numerous people involved with promoting e-commerce initiatives. Two people that have been extremely helpful in providing background information in connection with this bid have been Glynis D. Long from the US Small Business Administration, Office of Entrepreneurial Development and Eric Menge of the US Small Business Administration, Office of Advocacy.
iDomains has been in contact with both Mrs. Long and Mr. Menge about identifying people on a global scale that could potentially serve and make a contribution on the BAC. Once the BAC is in place, iDomains will be able to effect serious initiatives toward promoting e-commerce more effectively on a global scale.
iDomains plans on contributing approximately five percent (5%) of its annual pre-tax profits to a fund to be administered by the BAC and allocated for the development and enhancement of global commerce initiatives.
Registration
Policies During The
Start-Up Period
This section describes all policies (including implementation details) that iDomains proposes during the start-up phase of registration in the TLDs.
How do you propose to address the
potential rush for registration at the initial opening of the TLD?
iDomains intends to use a combination of mechanisms to handle the potential rush for registration that might otherwise threaten the stability of the registry. The two primary tools that will be used are the rotational "round robin" system (explained in detail below) and the Sunrise Program.
Rotational "Round Robin" System:
Although iDomains' normal registration system will register domain names on a first come first serve basis in real time, the realities of rolling out a new top-level domain dictate that a modified system be used to handle the contemplated land rush phenomenon.
The basis of the rotational "round robin" system involves a method by which registrars accept pre-registration that are then submitted to the registry in batch files and then processed by the registry using a queue system. The details of this system are outline in more detail below.
Qualified registrars would begin by accepting pre-registrations from domain name registrants. The registrar would then compile these domain names and the associated Whois data into batch files for submission to the registry. When the registry was ready to accept domain name registrations, the registry would query each registrar to get its initial batch file. These batch files would then be securely transferred to the registry for processing off-line, i.e. no open secure connection between the registry and the registrar.
After obtaining these batch files, the registry would then undertake the task of randomizing the batch files, and then processing these domain name requests names one application per registrar in a random order. Independent of the random order of the registrar ranking in each round, no registrar will have the opportunity to request and register more than one domain name per round. iDomains feels that this methodology will dissuade registrars from “selling” places in their respective queues, a practice is unacceptable in the opinion of iDomain’s management.
If a registrar's request for a domain name registration is denied, the registry will request the next available domain name registration in the batch file until a domain name is successfully registered or the registrar has no more requests in the batch. Once a registrars batch file is depleted, the registry will contact the registrars to look for another available batch file.
We remain open to other suggestions from ICANN as well as input from the Internet community at large for methods to enhance the equitable and reliable features of this rotational round-robin feature.
Sunrise Program:
A detailed description of the Sunrise Program that iDomains envisions providing is set forth in Section E.15.
How
many requested registrations do you project will be received by the registry
operator within the first day, week, month, and quarter?
iDomains estimates the following domain name registration volumes upon the initial opening of the registry to the public (i.e., after the conclusion of the Sunrise Period):
i) 75,000 on the first day;
ii) 200,000 within the first week;
iii) 300,000 within the first month; and
iv) 712,500 within the first quarter.
What
period do you believe should be considered the TLD's "start-up period,"
during which special procedures should apply?
iDomains estimates being able to move to a traditional first come first serve registry model within twenty (20) to thirty (30) days of going live. However, this date may have to be adjusted accordingly to account for demand and system resources.
Do you propose to place limits on
the number of registrations per registrant? Per registrar? If so, how will
these limits be implemented?