ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Wilmar International Limited

String: wilmar

Originally Posted: 13 June 2012

Application ID: 1-972-95481


Applicant Information


1. Full legal name

Wilmar International Limited

2. Address of the principal place of business

56 Neil Road
Singapore 088830
SG

3. Phone number

+65 6216 0244

4. Fax number

+65 6836 1709

5. If applicable, website or URL

http:⁄⁄www.wilmar-international.com

Primary Contact


6(a). Name

Mr. PengKoon Lim

6(b). Title

Director, IT Infrastructure

6(c). Address


6(d). Phone Number

+65 6631 0104

6(e). Fax Number

+65 6631 0130

6(f). Email Address

gtld@wilmar.com.sg

Secondary Contact


7(a). Name

Mr. Tiang Soon Colin Tan

7(b). Title

Company Secretary

7(c). Address


7(d). Phone Number

+65 6216 0244

7(e). Fax Number

+65 6536 2192

7(f). Email Address

pengkoon.lim@wcs-global.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).

Singapore

8(c). Attach evidence of the applicant's establishment.

Attachments are not displayed on this form.

9(a). If applying company is publicly traded, provide the exchange and symbol.

Singapore_Exchange;F34

9(b). If the applying entity is a subsidiary, provide the parent company.


9(c). If the applying entity is a joint venture, list all joint venture partners.


Applicant Background


11(a). Name(s) and position(s) of all directors

John Daniel RiceNon-Executive Director
Kuok Khoon ChenNon-Executive Director
Kuok Khoon EanNon-Executive Director
Kuok Khoon HongChairman & Chief Executive Officer
Kwah Thiam HockIndependent Director
Leong Horn KeeIndependent Director
Martua SitorusExecutive Director & Chief Operating Officer
Tay Kah ChyeIndependent Director
Teo Kim YongExecutive Director (Commercial)
Yeo Teng YangLead Independent Director

11(b). Name(s) and position(s) of all officers and partners

Ho Kiam HongChief Financial Officer
Kuok Khoon HongChairman & Chief Executive Officer
Martua SitorusExecutive Director & Chief Operating Officer
Teo Kim YongExecutive Director (Commercial)
Teo La-MeiGroup Legal Counsel & Company Secretary

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares

Archer Daniels Midland CompanyShareholder
Kuok Brothers Sdn BerhadShareholder
PPB Group BerhadShareholder

11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility


Applied-for gTLD string


13. Provide the applied-for gTLD string. If an IDN, provide the U-label.

wilmar

14(a). If an IDN, provide the A-label (beginning with "xn--").


14(b). If an IDN, provide the meaning or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.


14(c). If an IDN, provide the language of the label (in English).


14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).


14(d). If an IDN, provide the script of the label (in English).


14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).


14(e). If an IDN, list all code points contained in the U-label according to Unicode form.


15(a). If an IDN, Attach IDN Tables for the proposed registry.

Attachments are not displayed on this form.

15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.


15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.


16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.

N.A.

17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).


Mission/Purpose


18(a). Describe the mission/purpose of your proposed gTLD.

The Applicant, Wilmar International Limited, is Asia’s leading agribusiness group. Its business activities include oil palm cultivation, oilseeds crushing, edible oils refining, sugar milling and refining, specialty fats, oleochemiclas, biodiesel and fertilizers manufacturing and grains processing.   For more detailed overview of the Applicant, please visit: www.wilmar-international.com. 

The Applicant’s manifold mission and purposes of applying for the .WILMAR gTLD are as follows:

i. To secure and protect the Applicant’s key brand, .WILMAR as a gTLD on the Internet;

ii. To reflect .WILMAR gTLD at the top-level of the DNS’ hierarchy on the Internet;

iii. To control all domains, online brands and content within .WILMAR;

iv. To provide the Applicant’s authorized and⁄or registered users (“Legitimate Parties”) a recognized and trusted identifier in the Internet. Such Legitimate Parties include, but are not limited to:

• the Applicant’s subsidiary companies and associated companies established around the world and its over 300 manufacturing plants and extensive distribution networks covering China, India, Indonesia and some 50 other more countries
• affiliate partners and⁄or associates
• distributors, official dealers and retailers
• customers

v. The benefits to have the ability to own and control .WILMAR gTLD are substantial, as it will enable the Applicant to provide to its Legitimate Parties, within .WILMAR:

• a secure, convenient community that can reinforce relationships and build market share
• direct navigation to reach websites (applicants may be able to reduce its online advertising expenditures)
• enhance security on the Internet i.e. opportunity to control a distinct gTLD
• prevent third parties from registering desired gTLDs belonging to the Applicant and⁄or its Legitimate Parties obtaining genuine and secure information
• exchanging information
• communications
• new branding, marketing and promotions opportunities
• web space of affiliates and licensees
• Consolidation of internet resources under a house brand gTLD, i.e. all websites & email address can be consolidated under the same gTLD

18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?

(b)(i)
With the benefits being able to organize and control the Registry Operation of the .WILMAR gTLD, following ICANN’s award and delegation of the .WILMAR gTLD to the Applicant, the followings would be achievable by the Applicant:

• eliminate contentious applications of any domain names
• prevent unwanted activity by domainers (for profit traders of domain names) and cybersquatters (who use domain names to unfairly capitalize on brands they do not own)
• to build, establish and own an exclusive and recognizable .WILMAR identity on the Internet
• eliminate confusions of the Applicant’s identity
• eliminate unauthorized sales and channel non-compliance
• reduce phishing threats as phishers will be unable to acquire domains for the purpose of hosting spoofed company websites
• protection against DNS cache poisoning, or pharming attacks which re-direct Internet traffic to unintended locations
• to e-connect all the Applicant’s associates, customers etc.
• to build, establish and own an exclusive name space for all the Applicant’s brands, products and services worldwide
• to build and establish and own an exclusive webspace for the Applicant’s marketing and brands promotions purposes on the internet.

(b) (ii)
.WILMAR will bring a definite recognition and specialisation in the Internet, and the substantial benefits it could bring to the Applicant to achieve the followings:

• the identity of the Applicant as the Registry Operator;
• the source of the content and services offered under the .WILMAR gTLD;
• the affiliation between the Registry Operator and the gTLD; and
• in term, and at the discretion of the Applicant, the affiliation between the Registry Operator and any third party and⁄or third parties that is⁄are authorized by the Applicant to register and⁄or licensed to use one or more domain name registrations in the .WILMAR gTLD.

(b) (iii)
As mentioned under the vision and mission statement, the key reasons the Applicant is applying for .WILMAR include, but are not limited to:

1. To:
• secure and protect the WILMAR brand as a generic top-level domain (the Applicant has applied and registered WILMAR as a trademark in many jurisdictions).
• protect and prevent third party from securing the Applicant’s renowned and reputable global brand WILMAR as a generic top-level domain

2. To reflect the Applicant’s key brand WILMAR at the top-level of the DNS’ hierarchy;

3. Safety and security; and

4. To mitigate counterfeiting and piracy.

(b) (iv)
The Applicant intends to implement the following policies and procedures in respect of the registration of such domain names under .WILMAR top-level domain:

(A) reservation(s) and registration(s) of domain name(s) in the name of the Applicant. It is likely that this could be the scenario the Applicant will put in place during the initial months and⁄or during its tenure of the operation of the .WILMAR gTLD. These names may include, but are not limited to:

a. descriptive names, referring to the actual day-to-day business activities of the Applicant or its affiliates;
b. descriptive names, referring to the internal departments of the Applicant;
c. descriptive names, referring to the subsidiary companies and associated companies of the Applicant;
d. IDN names for second-level domain;
e. geographical names, in the second-level domain; or
f. potentially such names which may be related to such Legitimate users⁄ authorized users (to be determined by the Applicant) of the Applicant, following ICANN’s award and delegation of the .WILMAR gTLD to the Applicant.

(B) launch of a gTLD: if and when implemented by the Registry Operator, which will be in phases whereby Legitimate Parties who meet the Applicant’s certain criteria, may register .WILMAR gTLD domain names. These processes may include the followings:

a. Sunrise: allow physical persons, organizations and entities that meet the eligibility requirements determined by the Applicant at that point in time to choose and, where allowed by the Applicant, to register the domain names that are identical to their trademarks;

b. Land rush and general availability: other available domain names may be registered by physical persons, organizations and entities that meet the eligibility requirements in force at that point in time to choose the domain names in accordance with the applicable terms and conditions.

Depending on the terms and conditions in force at the time of launch of the gTLD, domain names may or may not be registered in the name of the authorized registrant or in the name of the Registry Operator of the gTLD i.e. the Applicant. The Applicant shall reserve the right to impose such additional and other restrictions or vary any provisions of the terms and conditions from time to time at its sole discretion;

(b) (v)
As the Applicant has extensive business operations across the globe, it will therefore be subject to various national privacy and data protection rules and practices. In particular, given the fact that many data protection authorities have issued strict guidelines, the Applicant will at all times be obliged to carefully consider and, where applicable, implement these policies prior to and during the operation of the .WILMAR gTLD.

Currently, the Applicant has not yet developed tangible plans to migrate its online activities from its wilmar-international.com and such other active domain names used by the Applicant’s subsidiary companies and associated companies. However, the Applicant has tentative plans to communicate to its customers, visitors and subsidiary companies and associated companies, its plan to develop, in gradual processes, the new online environment under .WILMAR gTLD, including but not limited to:


a. marketing and informational campaigns to assist users during the transition and to allow brand constituents to quickly learn how to navigate to their desired location
b. brochures and advertisements in newspapers, magazines, etc.;
c. Internet advertising campaigns, etc.;
d. re-direct internet traffic and⁄or link to the wilmar-international.com or such other domain names to the .WILMAR gTLD, to gradually build awareness amongst the Internet users

18(c). What operating rules will you adopt to eliminate or minimize social costs?

(c)
In line with the Applicant’s mission and purposes for the .WILMAR gTLD, it is the utmost importance for the Applicant to safeguard and protect its WILMAR brand at the top-level of the DNS’ hierarchy. Such protection does not only extend to the actual registration, delegation and use of the .WILMAR gTLD, but also to such domain names to be registered under .WILMAR gTLD, and how such domain names to be and⁄or can be used.

In view of the actual award and delegation of the .WILMAR gTLD to the Applicant is subject to the successful evaluation of its application, the Applicant has not yet defined in details:

• the types of domain names that could be registered;
• who could be entitled to select and name domain names that could be registered;
• who could be entitled to register such approved and⁄or authorized domain names that could be registered;
• who could be entitled to use such approved and⁄or registered domain names; and
• such approved and⁄or authorized types of usages that could be allowed

As we believe that the development and implementation of one or more business cases could likely take a couple of months or even years, we have only focused on a number of high-level characteristics of our plans in relation to the operation of the .WILMAR gTLD.

By all means, it is in the Applicant’s vested interest to, make the most of this initiative, that is to promote its own business interests, and mitigate risks for its brand and brand reputation, whilst also reducing the (social) costs for others such as name theft, phishing etc

In this context, the Applicant will devise policies that encompass and comprise the following features, including but not limited to :

At least during the initial months or the tenure following the delegation of the .WILMAR gTLD to Applicant, this extension is likely going to be a so-called “single registrant gTLD” as contemplated by ICANN in Article 4.5 of the template Registry Operator Agreement (“Transition of Registry upon Termination of Agreement”). For the avoidance of doubt, a “single registrant gTLD” is a gTLD where “(i) all domain name registrations in the g TLD are registered to, and maintained by, Registry Operator for its own exclusive use, and (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the gTLD to any third party that is not an Affiliate of Registry Operator.”

Therefore, parties who are not Wilmar or – insofar and to the extent Wilmar deems appropriate an affiliate will not be entitled to register domain names in the .WILMAR gTLD.

The Applicant believes this to be in line with two of the main elements in its vision and mission statement, namely:

• Protecting and safeguarding the WILMAR brand and its reputation, by keeping full control over the entire operation of the .WILMAR registry and every domain name registered therein; and

• Guaranteeing to the Applicant’s associates who are interacting with the Applicant and, as the case may be, its Affiliates, by using domain names registered in .WILMAR that they are in fact interacting with the brand owner or its authorized Affiliates.

Consequently, there will be no (social) costs for non-eligible (third) parties, given the fact that they will be unable to register.WILMAR domain names in the first place.

However, even if only the Applicant and⁄or as the case may be, the Applicant’s Legitimate parties, will be entitled to register .WILMAR domain names, this does not exclude the hypothesis that disputes may possibly arise for such same domain name(s) registered under .WILMAR. In order to avoid these situations from happening, the Applicant intends to implement the following processes and policies:

the followings are examples of the domain names could be registered by the Applicant and⁄or its Legitimate Parties:

• trademarks;
• company’s names
• etc.

Furthermore, the Applicant envisages registering a fair numbers of generic words that could be directly or indirectly related to the day-to-day business activities and⁄or operations of the Applicant and⁄or its legitimate Parties. Prior to approving and effectively registering such generic words in the .WILMAR gTLD, the Applicant will, as may be required review the list of such domain names on a regular basis to avoid infringing the rights of third parties (if any).

In any case, the Applicant will claim its legitimate interest in these domain names, as they could be merely descriptive of the business activities, products and⁄or services of the Applicant and⁄or its legitimate parties. So even if one or more of these domain names would be protected by a registered trademark, held by a third party, it is likely that a claim under the Uniform Dispute Resolution Policy or Uniform Rapid Suspension policy should fail.


As regards the names referred to in Specification 5 to the template Registry Operator Agreement, the Applicant will follow the processes and procedures established by ICANN and the Governmental Advisory Committee. The Applicant will at all times, be entitled at its absolute discretion, to restrict, limit or expand:

• such names which may be eligible and to be approved to be registered as domain name under the .WILMAR gTLD
• usage of such registered domain names under the .WILMAR gTLD;
• the transfer of such registered domain names registered under .WILMAR gTLD;
• etc.

The Applicant shall reserve the right to subject the registration, renewal and⁄or use of a domain name to such internal approval processes and procedures in place from time to time, at each and every step of the domain name life cycle.

Given the fact that the Applicant may release such available domain names lists post launch in a highly controlled manner, this should reduce the likelihood that two or more applicants will apply for the registration of the same domain name under the .WILMAR gTLD.

Subject to the actual domain name registration policy to be adopted by the Applicant, which the Applicant may from time to time, annul, amend, add or vary any policies and⁄or provisions, domain names will be allocated on a first-come, first-served basis.

The Applicant also reserves the right to amend, add or vary any policies and⁄or provisions, procedures and practices at any point of time if it is of the opinion that the reputation of the brands of the Applicant and its Legitimate Parties could be subjected to risks.

The Applicant may intend to allow the registration of domain names under the .WILMAR gTLD available to qualified Legitimate Parties ⁄registrants at no cost to them. The Applicant may charge a fee for the registration of such approved and qualified domain names under the .WILMAR gTLD and such fees shall be set at cost-recovery or arm’s length basis which shall be determined by the Registry Operator. If required, the Applicant may increase the fees for the registration of the domain names, such fees shall also be set at cost-recovery or arm’s length basis.

Community-based Designation


19. Is the application for a community-based TLD?

No

20(a). Provide the name and full description of the community that the applicant is committing to serve.


20(b). Explain the applicant's relationship to the community identified in 20(a).


20(c). Provide a description of the community-based purpose of the applied-for gTLD.


20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).


20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.


20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).

Attachments are not displayed on this form.

Geographic Names


21(a). Is the application for a geographic name?

No

Protection of Geographic Names


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD.

The Applicant has an extensive geographic coverage and diversified business⁄operations across the globe with subsidiary companies and associated companies established around the world, and its over 300 manufacturing plants and extensive distribution networks covering China, India, Indonesia and some 50 other more countries. Therefore clearly it has a vested interest giving its stakeholders, subsidiary companies and associated companies, affiliate partners and⁄or associates, distributors, official dealers, retailers and customers a clear and predictable naming scheme in the. WILMAR gTLD. 

The Applicant’s stakeholders, subsidiary companies and associated companies, affiliate partners and⁄or associates, distributors, official dealers, retailers and customers etc. may have already increasingly identifying the Applicant’s business activities⁄operations by its geographical locations. The Applicant may develop⁄implement a mechanism in order for domain names that exclusively contain geographic names (country names, city names, names of regions, etc.) to be approved to be registered. However, the Applicant will put in place and consider the following confines before such domain names are to be approved to be registered:
• that these domain names will be exclusively registered in the name of the Applicant ⁄ Registry Operator or its Affiliates, and not in the name of a third party that is not controlled by the Applicant ⁄ Registry Operator, unless otherwise agreed with the authority competent for giving its consent in accordance with Specification 5 of the Registry Agreement;

• that where consents are required prior to the registration and use of a domain name referred to and in accordance with Specification 5 of the Registry Agreement, the Applicant will obtain such consents before actually registering, delegating and using these domain names.

In any case, the Applicant will retain its rights to the full control of the registration, delegation and use of domain names corresponding to the geographic names at all times.

Registry Services


23. Provide name and full description of all the Registry Services to be provided.

As mentioned in response to Question 18 (a) above, Wilmar is Asia’s leading agribusiness group and the holding company of 400+ subsidiaries. Therefore, Wilmar has a substantial experience and expertise in managing complex information technology infrastructures, hereby relying on in-house and external resources.
Given the specific technical requirements imposed upon new gTLD registries, as well as the lack of in-depth experience within Wilmar’s own organization in managing a domain name registry system, Wilmar has decided to rely on The Service Provider Ltd. (“The Service Provider” or “Service Provider” – see www.the Service Provider.info) together with IP Mirror to provide back-end services for the .WILMAR registry. In this application, the The Service Provider-IP Mirror alliance is refer as the “Service Provider”. The Service Provider The Service Provider has experience in managing several top-level domains, including, but not limited to, .ORG, .INFO, .AERO, .ASIA and .XXX,

The following section describes the registry services to be provided by the Applicant, which services will almost be entirely outsourced toThe Service Provider. This section has been prepared in cooperation with The Service Provider
The Service ProviderThe Service Provider is dedicated to managing the technical operations and support of the applied-for TLD in a secure, stable and reliable manner. With over a decade of registry experience, The Service has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in The Service Provider’ participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows the Service Provider to be at the forefront of security initiatives such as: DNSSEC, wherein The Service Provider worked with Public Interest Registry (PIR) to make the .ORG registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.
With the .WILMAR registry, the Applicant will provide the highest level of service, while delivering a secure, reliable and comprehensive platform. The Applicant will utilize an existing, proven team and platform for registry services with:


- A stable and secure, state-of-the-art, EPP-based SRS with ample storage capacity, data security provisions and scalability that is proven with registrars who account for over 95% of all gTLD domain name registration activity (over 375 registrars);
- A reliable, 100% available DNS service (zone file generation, publication and dissemination) tested to withstand severe DDoS attacks and dramatic growth in Internet use;
- A WHOIS service that is flexible and standards compliant, with search capabilities to address both registrar and end-user needs; includes consideration for evolving standards, such as RESTful, or draft-kucherawy-wierds;
- Experience introducing IDNs in the following languages: German (DE), Spanish (ES), Polish (PL), Swedish (SV), Danish (DA), Hungarian (HU), Icelandic (IS), Latvian (LV), Lithuanian (LT), Korean (KO), Simplified and Traditional Chinese (CN), Devanagari (HI-DEVA), Russian (RU), Belarusian (BE), Ukrainian (UK), Bosnian (BS), Serbian (SR), Macedonian (MK) and Bulgarian (BG) across the TLDs it serves;
- A registry platform that is both IPv6 and DNSSEC enabled;
- An experienced, respected team of professionals active in standards development of innovative services such as DNSSEC and IDN support;
- Methods to limit domain abuse, remove outdated and inaccurate data, and ensure the integrity of the SRS, and;
- Customer support and reporting capabilities to meet financial and administrative needs, e.g., 24x7 call center support, integration support, billing, and daily, weekly, and monthly reporting.



The .WILMAR TLD will be supported from a technical level in accordance with the specific policies and procedures of the registry operator, leveraging a proven registry infrastructure that is fully operational, staffed with professionals, massively provisioned, and immediately ready to use, launch and maintain the .WILMAR TLD.

The below response includes a description of the registry services to be provided for this TLD, additional services provided to support registry operations, and an overview of the Applicant’s approach to registry management that will be used by its back-end registry operator, Aflilias.



Registry services to be provided
The following registry services will be offered in support of the .WILMAR TLD, all in accordance with relevant technical standards and policies:
− Receipt of data from registrars concerning registration for domain names and nameservers, and provision to registrars of status information relating to the EPP-based domain services for registration, queries, updates, transfers, renewals, and other domain management functions. Please see the Applicant’s responses to questions #24, #25, and #27 for full details, which the Applicant requests be incorporated here by reference.
− Operation of the registry DNS servers: The The Service Provider DNS system, run and managed by The Service Provider, that will be used for the .WILMAR TLD is a massively provisioned DNS infrastructure that utilizes among the most sophisticated DNS architecture, hardware, software and redundant design created. The Service Provider’ industry-leading system works in a seamless way to incorporate nameservers from any number of other secondary DNS service vendors. Please see the Applicant’s response to question #35 for full details, which the Applicant requests be incorporated here by reference.
− Dissemination of TLD zone files: The Service Provider’ distinctive architecture allows for real-time updates and maximum stability for zone file generation, publication and dissemination. Please see the Applicant’s response to question #34 for full details, which the Applicant requests be incorporated here by reference.
− Dissemination of contact or other information concerning domain registrations: A port 43 WHOIS service with basic and expanded search capabilities with requisite measures to prevent abuse. Please see the Applicant’s response to question #26 for full details, which the Applicant requests be incorporated here by reference.
− Internationalized Domain Names (IDNs): Ability to support all Unicode characters at every level of the TLD, including alphabetic, ideographic and right-to-left scripts. Please see the Applicant’s response to question #44 for full details, which the Applicant requests be incorporated here by reference.
− DNS Security Extensions (DNSSEC): A fully DNSSEC-enabled registry, with a stable and efficient means of signing and managing zones. This includes the ability to safeguard keys and manage keys completely. Please see the Applicant’s response to question #43 for full details, which the Applicant requests be incorporated here by reference.

Each service will meet or exceed the contract service level agreement. All Registry Services for the .WILMAR TLD will be provided in a standards-compliant manner.
and The Service Provider are committed to ensuring the confidentiality, integrity, and availability of all information.




Security
The Applicant addresses security in every significant aspect – physical, data and network as well as process. The shared approach to security between the Applicant and The Service Provider permeates every aspect of the registry services that will be provided for the .WILMAR TLD. A dedicated security function exists within the company to continually identify existing and potential threats, and to put in place comprehensive mitigation plans for each identified threat. In addition, a rapid security response plan exists to respond comprehensively to unknown or unidentified threats. The specific threats and the Applicant’s mitigation plans are defined in response #30(b); please see the Applicant’s response to #30b for full details, which the Applicant requests be incorporated here by reference. In short, both the Applicant and The Service Provider are committed to ensuring the confidentiality, integrity, and availability of all information.


New registry services

No new registry services are planned for the launch of this TLD.


Additional services to support registry operation
The Applicant will use various support services and functions to facilitate the effective management of the TLD. These support services and functions include, without limitation,:
− Customer support offered by The Service Provider: 24x7 live phone and e-mail support for customers to address any access, update or other issues they may encounter. This includes assisting the customer identification of the problem as well as solving it. Customers include registrars and the registry operator, but not registrants except in unusual circumstances. Customers have access to a web-based portal for a rapid and transparent view of the status of pending issues.
− Financial services: billing and account reconciliation for all registry services according to pricing established in respective agreements.



Reporting is an also an important component of supporting registry operations. The Applicant will be able to rely on The Service Provider reporting (inclusive of financial reporting) to ICANN, the registry operator and registrars.



Reporting provided to Registry Operator


The Registry Operator of the applied for TLD will be able to rely on The Service Provider providing an extensive suite of reports to the registry operator, including daily, weekly and monthly reports with data at the transaction level that enable the registry operator to track and reconcile at whatever level of detail preferred. The exact data required by ICANN in the required format shall be provided for the Registry Operator to meet its technical reporting requirements to ICANN.

In addition, the Registry Operator’s Back-End Service Provider will offer access to a data warehouse capability that will enable near real-time data to be available 24x7. The access to the data warehouse capability will be controlled through the The Service Provider Account Manager. The data warehouse capability will enable drill-down analytics all the way to the transaction level.


Reporting available to registrars


The Registry Operator of the applied-for gTLD will be providing an extensive suite of reporting to registrars through The Service Provider, who has been doing so in an exemplary manner for more than ten years. Specifically, the Registry Operator of the applied-for gTLD will provide daily, weekly and monthly reports through The Service Provider with detail at the transaction level to enable registrars to track and reconcile at a level of detail that may be adapted to a large extent to the registrars’ preferences.

Reports shall be provided in standard formats, facilitating import for use by virtually any (existing) registrar analytical tool. Registrar reports will be made available for download via a secure administrative interface. A given registrar will only have access to its own reports. These include the following:
− Daily Reports: Transaction Report, Billable Transactions Report, and Transfer Reports;
− Weekly: Domain Status and Nameserver Report, Weekly Nameserver Report, Domains Hosted by Nameserver Weekly Report, and;
− Monthly: Billing Report and Monthly Expiring Domains Report.

Weekly registrar reports will be maintained for each registrar for four weeks. Weekly reports older than four weeks will be archived for a period of six months, after which they will be deleted.


Financial reporting

Registrar account balances will be updated in real-time when payments and withdrawals are posted to the registrarsʹ accounts. In addition, the registrar account balances will be updated as and when the concerned registrar performs billable transactions at the registry level.

The Applicant, through The Service Provider, will provide Deposit⁄Withdrawal Reports that are updated periodically to reflect payments received or credits and withdrawals posted to the registrar accounts.

The following reports will also be available to registry operators: a) Daily Billable Transaction Report, containing details of all the billable transactions performed by all the registrars in the SRS, b) daily e-mail reports containing the number of domains in the registry and a summary of the number and types of billable transactions performed by the registrars, and c) registry operator versions of most registrar reports (for example, a daily Transfer Report that details all transfer activity between all of the registrars in the SRS).


Approach to registry support

By relying on the Service Provider for this gTLD, the Applicant is dedicated to managing the technical operations and support of this gTLD in a secure, stable and reliable manner. It has worked closely with the Applicant to review specific needs and objectives of this gTLD. The resulting comprehensive plans are illustrated in technical responses #24-44 in accordance to the Applicant’s requirements. Both parties also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of this TLD.

Over the past 11 years of providing services for gTLD and ccTLDs, our Service Provider has accumulated experience about resourcing levels necessary to provide high quality services with conformance to strict service requirements. It currently supports over 20 million domain names, spread across 16 TLDs, with over 400 accredited registrars.

Since its founding, it has focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the registry system in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the project management methodology allows efficient and effective use of our staff in a focused way.

With over a decade of registry experience, it has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in its participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows our Service Provider to be at the forefront of security initiatives such as: DNSSEC, wherein it worked with Public Interest Registry (PIR) to make the .ORG registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.

The ability to observe tightening resources for critical functions and the capacity to add extra resources ahead of a threshold event are factors that the Service Provider is well versed in. Its human resources team, along with well-established relationships with external organizations, enables it to fill both long-term and short-term resource needs expediently.

The growth from a few domains to serving 20 million domain names across 16 TLDs and 400 accredited registrars indicates that the relationship between the number of people required and the volume of domains supported is not linear. In other words, servicing 100 TLDs does not automatically require 6 times more staff than servicing 16 TLDs. Similarly, an increase in the number of domains under management does not require in a linear increase in resources. The Service Provider carefully tracks the relationship between resources deployed and domains to be serviced, and pro-actively reviews this metric in order to retain a safe margin of error. This enables the Service Provider to add, train and prepare new staff well in advance of the need, allowing consistent delivery of high quality services.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS, or < and >), WHICH ICANN INFORMS US (CASE ID 11027)
CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE,
THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE
AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO
ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN
UNDER CASE ID 11027.


Answers for this question (#24) are provided directly from the Service Provider, the back-end provider of registry services for this TLD.

As referred to above, in the Applicant’s response to Question 23, As agreed between the Applicant and The Service Provider, all technical back-end operations with respect to the .WILMAR gTLD will be outsourced to The Service Provider, an experienced and proven registry operator with over ten years of experience managing a world-class registry platform. The Applicant will, however, remain responsible for the provision of these services vis-à-vis ICANN, as referred to in the Registry Operator Agreement.
The Applicant has partnered with The Service Provider, an experienced TLD registry operator, who will provide for the necessary support in deploying a fully ICANN-compliant Shared Registration System (SRS). The Applicant is confident that the plan in place for the operation of a robust and reliable SRS as currently provided by The Service Provider will satisfy the criterion established by ICANN.

The Service Provider built its SRS as an EPP based platform and has been operating it reliably and at scale since 2001. The software currently provides registry services to inter alia .INFO and .ORG TLDs. The Service Provider’ state of the art registry has a proven track record of being secure, stable, and robust. It manages more than 20 million domain names, and has over 375 registrars connected today.

The following describes a detailed plan for a robust and reliable SRS that meets all ICANN requirements, including compliance with Specifications 6 and 10 to the Registry Operator Agreement published by ICANN.
The answers for this question (#24) are provided in cooperation with The Service Provider


The .WILMAR TLD will operate in a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS that will be used for the .WILMAR TLD meets or exceeds all ICANN requirements given that The Service Provider:
− operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
− is committed to continuously enhancing the SRS that will be used for the operation of the applied-for TLD to meet existing and future needs;
− currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
− provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of this TLD, and;
− manages the SRS with a team of experienced technical professionals who can seamlessly integrate the applied-for TLD into the The Service Provider registry platform and support the applied-for TLD in a secure, stable and reliable manner.



Description of operation of the SRS, including diagrams
The SRS that will be used for the .WILMAR TLD will provide the same advanced functionality as that used in the .INFO and .ORG registries, as well as the fourteen other TLDs currently supported by The Service Provider. The registry system that will be used for the .WILMAR TLD, is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by massively provisioned infrastructure that mitigates the risk of disaster. Specifically, The Service Provider has engineered its registry applications as stateless systems, managed with load balancers. This permits dynamic scaling at the application layer for all registry functions. The Service Provider’ applications exercise 5-6% sustained load on the current application servers, with bursted loads of up to 12-13%. The servers are operated with a minimum bursted capacity of 50% over sustained loads. In the event of unexpected load increase, this available overhead permits The Service Provider to promote additional resources into production without expected degradation of service.

EPP functionality is described in detail in the Applicant’s response to Question #25; please consider those answers incorporated here by reference. An abbreviated list of the SRS functionality that will be supported by the Applicant, through The Service Provider, includes:
− Domain registration: the Applicant will provide registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
− Domain renewal: the Applicant will provide services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry shall be able to perform the automated renewal of all domain names at the expiration of their term, and will allow registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund.
− Transfer: the Applicant will provide efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry shall enable bulk transfers of domains under the provisions of the Registry-Registrar Agreement.
− RGP and restoring deleted domain registrations: the Applicant, through its Back-End Operator, shall provide support for the Redemption Grace Period (RGP) to the extent needed, enabling the restoration of deleted registrations.
− Other grace periods and conformance with ICANN guidelines: the Applicant, through its Back-End Operator shall be able to provide support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the registry system that the Applicant will use, shall support the evolving ICANN guidelines on IDNs.

The Applicant, through its Back-End Operator shall also support the basic check, delete, and modify commands.


As required for all new gTLDs, the system provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.
The SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this gTLD’s respective domain policies. With over a decade of experience, the Service Provider has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.


SRS servers and software
All applications and databases for the applied-for TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (Although it is possible that by the time this application has passed the evaluation and systems deployed, Westmere processors may no longer be the “latest”, the Applicant’s Back-End Operator’s policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment will allow the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It will also facilitate effective utilization of system resources, thus reducing energy consumption and carbon footprint.

The latest network firewalls, routers and switches will support all applications and servers. Hardware traffic shapers will be used to enforce an equitable access policy for connections coming from registrars. The registry system that will be used for the applied-for gTLD accommodates both IPv4 and IPv6 addresses. Hardware load balancers will accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.

Each of the servers and network devices that will be used for the gTLD are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all the Back-End Operator’s data centers guarantee the replacement of failed parts in the shortest time possible.

Examples of current system and network devices used by the Applicant’s Back-End Operator are:
− Servers: Cisco UCS B230 blade servers
− SAN storage arrays: IBM Storwize V7000 with Solid State Drives
− SAN switches: Brocade 5100
− Firewalls: Cisco ASA 5585-X
− Load balancers: F5 Big-IP 6900
− Traffic shapers: Procera PacketLogic PL8720
− Routers: Juniper MX40 3D
− Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232


These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center of the Applicant’s Back-End Operator, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.

Technical components of the SRS that will be used for the applied-for gTLD already include the following items, continually checked and upgraded as needed: WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).

All hardware that will be used for the applied-for gTLD is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device to be used for the applied-for gTLD will be continuously monitored by the The Service Provider Network Operations Center for performance and availability. The data gathered will be used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review shall be instituted to address the need for additions well in advance of their actual need.



SRS diagram and interconnectivity description
As with all core registry services, the SRS that will be used for the applied-for gTLD, shall be run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see the Applicant’s responses to questions #32 and #35.

Registrars will be able to access the SRS that will be used for the applied-for gTLD in real-time using EPP.

A schematic overview of the Applicant’s Back-End Operator’s registry infrastructure that will be used for the applied for gTLD is provided in Annex A – Figure 24-a.

A sample of the technical and operational capabilities (displayed in Annex A – Figure 24-a) of the SRS that will be used include:
− Geographically diverse redundant registry systems;
− Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
− Disaster Recovery Point objective for the registry (This is within one minute of the loss of the primary system);
− Detailed and tested contingency plan, in case of primary site failure, and;
− Daily reports, with secure access for confidentiality protection.

As evidenced in Annex A – Figure 24-a, the SRS that will be used for the applied-for gTLD contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.

The WHOIS servers that will be used for the applied-for gTLD shall be directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.

Committed DNS-related EPP objects in the database will be made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor will extract committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.

The system as proposed by the Applicant, through its Back-End Operator is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.

This interconnectivity will be monitored, as will be the entire registry system, according to the plans detailed in the Applicant’s response to Question #42.



Synchronization scheme
Registry databases are synchronized both within the same data center, and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37; please consider those answers incorporated here by reference. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) will work continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction, the Slony replication system will ensure that each replica also processes the transaction. When there are no transactions to process, Slony will “sleep” until a transaction arrives or for one minute, whichever comes first. If there is no transaction within one minute, Slony will “wake up” each minute to confirm with the publisher that there has not been a transaction and thus will ensure that subscribers are synchronized and that the replication time lag is minimized. The typical replication time lag between the publisher and subscribers will depend on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.



SRS SLA performance compliance
The Applicant’s Back-End Operator has a ten-year record of delivering on all ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Annex A – Figure 24-b.

The The Service Provider SRS currently handles over 200 million EPP transactions per month for just .INFO and .ORG. Overall, the The Service Provider SRS manages over 700 million EPP transactions per month for all TLDs under management.

Given this robust functionality and the Applicant’s Back-End Registry Operator having more than a decade of experience supporting a thick TLD registry with a strong performance history, the Applicant will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The The Service Provider services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The The Service Provider architecture is also massively provisioned to meet seasonal demands and marketing campaigns. The Service Provider’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.



SRS resourcing plans
Since its founding, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the The Service Provider project management methodology allows efficient and effective use of our staff in a focused way.

Over 100 The Service Provider team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate The Service Provider facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, The Service Provider also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy the .WILMAR TLD on the The Service Provider infrastructure, and maintain it. Together, the The Service Provider team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for the .WILMAR TLD.

25. Extensible Provisioning Protocol (EPP)

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS, or < and >), WHICH ICANN INFORMS US (CASE ID 11027)
CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE,
THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE
AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO
ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN
UNDER CASE ID 11027.


Answers for this question (#25) are provided in cooperation with The Service Provider, who will serve as the back-end provider of registry services (hereinafter referred to as the ‘Back-End Operator’) for the applied-for TLD.

The Applicant’s selected Back-End Operator for the .WILMAR TLD has been a pioneer and innovator in the use of EPP. The .INFO TLD operated by the Applicant’s Back-End Operator was the first EPP-based gTLD registry and launched on EPP version 02⁄00. The Applicant’s Back-End Operator The Service Provider has a track record of supporting TLDs on standards-compliant versions of EPP. Through The Service Provider, the Applicant will operate the EPP registrar interface as well as a web-based interface for the .WILMAR TLD in accordance with RFCs and global best practices. In addition, the Applicant, through The Service Provider, will maintain a proper Operational Testing and Evaluation (OT&E) environment to facilitate registrar system development and testing.


The Service Provider’ EPP technical performance that will be used for the .WILMAR TLD meets or exceeds all ICANN requirements as demonstrated by:
- A completely functional, state-of-the-art, EPP-based SRS that currently meets the needs of various gTLDs and will meet the new TLD’s needs for the applied-for TLD;
- A track record of success from The Service Provider in developing extensions to meet client and registrar business requirements such as multi-script support for IDNs;
- The Service Provider supporting six ICANN gTLDs on EPP: .INFO, .ORG, .MOBI, .AERO, .ASIA and .XXX
- EPP software that is operating today and has been fully tested to be standards-compliant;
- Proven interoperability of existing EPP software with ICANN-accredited registrars, and;
- An SRS that currently processes over 200 million EPP transactions per month for both .INFO and .ORG. Overall, The Service Provider processes over 700 million EPP transactions per month for all 16 TLDs under management.

The EPP service shall be offered in accordance with the performance specifications defined in the new gTLD Registry Agreement, Specification 10.


EPP Standards
The The Service Provider registry system that will be used for the .WILMAR TLD, complies with the following revised versions of the RFCs and operates multiple ICANN TLDs on these standards, including .INFO, .ORG, .MOBI, .ASIA and .XXX. The systems have been tested by the Quality Assurance (“QA”) team of Applicant’s Back-End Operator for RFC compliance, and have been used by registrars for an extended period of time:
- RFC 3735 - Guidelines for Extending EPP
- RFC 3915 - Domain Registry Grace Period Mapping
- RFC 5730 - Extensible Provisioning Protocol (EPP)
- RFC 5731 - Domain Name Mapping
- RFC 5732 - Host Mapping
- RFC 5733 - Contact Mapping
- RFC 5734 - Transport Over TCP
- RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

Sample EPP commands are available in Annex B and copies of the XSD schema files from the Applicant’s Back-End Operator, which define all the rules of valid EPP commands and responses that Afilias supports, are also included. These samples demonstrate compliance with these RFCs.

The staff members from the Applicant’s Back-End Operator actively participated in the Internet Engineering Task Force (IETF) process that finalized the new standards for EPP. The Applicant’s Back-End Operator, The Service Provider will continue to actively participate in the IETF process and will stay abreast of any updates to the EPP standards.


EPP software interface and functionality
Through its Back-End Operator, the Applicant will provide all registrars with a free open-source EPP toolkit. This software will be provided for use with both Microsoft Windows and Unix⁄Linux operating systems. This software, which includes all relevant templates and schema defined in the RFCs 3735, 3915, 5730, 5731, 5732, 5733, 5734 and 5910, is available on sourceforge.net and will be available through the registry operator’s website.

The Service Provider’ SRS EPP software that will be used by the Applicant complies with all relevant RFCs and includes the following functionality:
- EPP Greeting: A response to a successful connection returns a greeting to the client. Information exchanged can include: name of server, server date and time in UTC, server features, e.g., protocol versions supported, languages for the text response supported, and one or more elements which identify the objects that the server is capable of managing;
- Session management controls: 〈login〉 to establish a connection with a server, and 〈logout〉 to end a session;
- EPP Objects: Domain, Host and Contact for respective mapping functions;
- EPP Object Query Commands: Info, Check, and Transfer (query) commands to retrieve object information, and;
- EPP Object Transform Commands: five commands to transform objects: 〈create〉 to create an instance of an object, 〈delete〉 to remove an instance of an object, 〈renew〉 to extend the validity period of an object, 〈update〉 to change information associated with an object, and 〈transfer〉 to manage changes in client sponsorship of a known object.

Currently, 100% of the top domain name registrars in the world have software that has already been tested and certified to be compatible with the The Service Provider SRS registry. In total, over 375 registrars, representing over 95% of all registration volume worldwide, operate software that has been certified compatible with the The Service Provider SRS registry. The EPP Registrar Acceptance Criteria that shall be used by the Applicant, through its Back-End Operator, are available in attachment (Annex C – figure 25(b)EPP OT&E Criteria).

Free EPP software support
The technical back-end registry operator shall analyze and diagnose registrar EPP activity log files as needed and will be available to assist registrars who may require technical guidance regarding how to fix repetitive errors or exceptions caused by misconfigured client software.

Registrars will be responsible for acquiring a TLS⁄SSL certificate from an approved certificate authority, as the registry-registrar communication channel shall require mutual authentication; The Applicant, through its Back-End Operator, will acquire and maintain the server-side TLS⁄SSL certificate. The registrar will be responsible for developing support for TLS⁄SSL in their client application. The Applicant, through its Back-End Operator, will provide free guidance for registrars unfamiliar with this requirement.

Registrar data synchronization
There will be two methods available for registrars to synchronize their data with the registry:
- Automated synchronization: through automated synchronization, registrars can, at any time, use the EPP 〈info〉 command to obtain definitive data from the registry for a known object, including domains, hosts (nameservers) and contacts.
- Personalized synchronization: through personalized synchronization, a registrar may contact technical support and request a data file containing all domains (and associated host (nameserver) and contact information) registered by that registrar, within a specified time interval. The data will be formatted as a comma separated values (CSV) file and made available for download using a secure server.

EPP modifications
There are no unique EPP modifications planned for this TLD.
At least 30 days prior to the launch of a new gTLD, all new gTLDs must offer a Sunrise period as part of a rights protection program. The EPP extensions that the Applicant will use, shall allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. These extensions are:
- An 〈ipr:name〉 element that indicates the name of Registered Mark.
- An 〈ipr:number〉 element that indicates the registration number of the IPR.
- An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
- An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
- An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for.
- An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered.
- An 〈ipr:class〉 element that indicates the class of the registered mark.
- An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for.
Some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse.


EPP resourcing plans
Since its founding, the Applicant’s selected technical back-end provider for registry services, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of the .WILMAR TLD.
The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the project management methodology that shall be used by The Service Provider for the .WILMAR TLD, will allow for the efficient and effective use of the Back-End Operator’s staff in a focused way.
Currently, 108 The Service Provider team members directly contribute to the management and development of the EPP based registry systems. As previously noted, The Service Provider is an active member of IETF and has a long documented history developing and enhancing EPP. These contributors include 11 developers and 14 Quality Assessment engineers focused on maintaining and enhancing EPP server side software. These engineers work directly with business staff to timely address existing needs and forecast registry⁄registrar needs to ensure the The Service Provider EPP software is effective today and will remain effective in the future. A team of eight data analysts work with the EPP software system to ensure that the data flowing through EPP is securely and reliably stored in replicated database systems. In addition to the EPP developers, Quality Assessment engineers, and data analysts, other EPP contributors at The Service Provider include: Technical Analysts, the Network Operations Center and Data Services team members. The Applicant’s Back-End Operator shall ensure that sufficient personnel will allow for the further development of the EPP software system to ensure the secure and reliable storage in replicated database systems of the data flowing through EPP in the applied-for TLD.

26. Whois

Answers for this question (#26) are provided by the Service Provider, the back-end provider of registry services for this TLD.

The Service Provider operates the WHOIS (registration data directory service) infrastructure in accordance with RFCs and global best practices, as it does for the 16 TLDs it currently supports. Designed to be robust and scalable, the Service Provider’ WHOIS service has exceeded all contractual requirements for over a decade. It has extended search capabilities, and methods of limiting abuse.

The WHOIS service operated by the Service Provider meets and exceeds ICANN’s requirements. Therefore, by relying on the Service Provider, the Applicant will:
• Offer a WHOIS service made available on port 43 that is flexible and standards- compliant;
• Comply with all ICANN policies, and meeting or exceeding WHOIS performance requirements in Specification 10 of the new gTLD Registry Agreement;
• Enable a Searchable WHOIS with extensive search capabilities that offers ease of use while enforcing measures to mitigate access abuse, and;
• Employ a team with significant experience managing a compliant WHOIS service.

Such extensive knowledge and experience managing a WHOIS service enables the Service Provider to offer a comprehensive plan for this TLD that meets the needs of constituents of the domain name industry and Internet users. The service has been tested by our QA team for RFC compliance, and has been used by registrars and many other parties for an extended period of time. The WHOIS service currently serves almost 500 million WHOIS queries per month, with the capacity already built in to handle an order of magnitude increase in WHOIS queries, and the ability to smoothly scale should greater growth be needed.


WHOIS system description and diagram

The WHOIS system, depicted in figure 26-a, is designed with robustness, availability, compliance, and performance in mind. Additionally, the system has provisions for detecting abusive usage (e.g., excessive numbers of queries from one source). The WHOIS system is generally intended as a publicly available single object lookup system. The system uses an advanced, persistent caching system to ensure extremely fast query response times.

The Service Provider will develop restricted WHOIS functions based on specific domain policy and regulatory requirements as needed for operating the business (as long as they are standards compliant). It will also be possible for contact and registrant information to be returned according to regulatory requirements. The WHOIS database supports multiple string and field searching through a reliable, free, secure web-based interface.


Data objects, interfaces, access and lookups

Registrars can provide an input form on their public websites through which a visitor is able to perform WHOIS queries. The registry operator can also provide a Web-based search on its site. The input form must accept the string to query, along with the necessary input elements to select the object type and interpretation controls. This input form sends its data to the system port 43 WHOIS server. The results from the WHOIS query are returned by the server and displayed in the visitor’s Web browser. The sole purpose of the Web interface is to provide a user-friendly interface for WHOIS queries.

The system will provide WHOIS output as per Specification 4 of the new gTLD Registry Agreement. The output for domain records generally consists of the following elements:
• The name of the domain registered and the sponsoring registrar;
• The names of the primary and secondary nameserver(s) for the registered domain name;
• The creation date, registration status and expiration date of the registration;
• The name, postal address, e-mail address, and telephone and fax numbers of the domain name holder;
• The name, postal address, e-mail address, and telephone and fax numbers of the technical contact for the domain name holder;
• The name, postal address, e-mail address, and telephone and fax numbers of the administrative contact for the domain name holder, and;
• The name, postal address, e-mail address, and telephone and fax numbers of the billing contact for the domain name holder.
• The following additional features are also present in the WHOIS service:
o Support for IDNs, including the language tag and the Punycode representation of the IDN in addition to Unicode Hex and Unicode HTML formats;
o Enhanced support for privacy protection relative to the display of confidential information.

The system will also provide sophisticated WHOIS search functionality that includes the ability to conduct multiple string and field searches.


Query controls

For all WHOIS queries, a user is required to enter the character string representing the information for which they want to search. The object type and interpretation control parameters to limit the search may also be specified. If object type or interpretation control parameter is not specified, WHOIS will search for the character string in the Name field of the Domain object.

WHOIS queries are required to be either an ʺexact searchʺ or a ʺpartial search,ʺ both of which are insensitive to the case of the input string.

An exact search specifies the full string to search for in the database field. An exact match between the input string and the field value is required.

A partial search specifies the start of the string to search for in the database field. Every record with a search field that starts with the input string is considered a match. By default, if multiple matches are found for a query, then a summary containing up to 50 matching results is presented. A second query is required to retrieve the specific details of one of the matching records.

If only a single match is found, then full details will be provided. Full detail consists of the data in the matching object as well as the data in any associated objects. For example: a query that results in a domain object includes the data from the associated host and contact objects.

WHOIS query controls fall into two categories: those that specify the type of field, and those that modify the interpretation of the input or determine the level of output to provide. Each is described below.

The following keywords restrict a search to a specific object type:
• Domain: Searches only domain objects. The input string is searched in the Name field.
• Host: Searches only nameserver objects. The input string is searched in the Name field and the IP Address field.
• Contact: Searches only contact objects. The input string is searched in the ID field.
• Registrar: Searches only registrar objects. The input string is searched in the Name field.
• By default, if no object type control is specified, then the Name field of the Domain object is searched.

In addition, the WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names. Deployment of these features is provided as an option to the registry operator, based upon registry policy and business decision making.

Figure 26-b presents the keywords that modify the interpretation of the input or determine the level of output to provide.

By default, if no interpretation control keywords are used, the output will include full details if a single match is found and a summary if multiple matches are found.


Unique TLD requirements

There are no unique WHOIS requirements for this TLD.


Sunrise WHOIS processes

All ICANN TLDs must offer a Sunrise as part of a rights protection program. The system uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. The following corresponding data will be displayed in WHOIS for relevant domains:
• Trademark Name: element that indicates the name of the Registered Mark.
• Trademark Number: element that indicates the registration number of the IPR.
• Trademark Locality: element that indicates the origin for which the IPR is established (a national or international trademark registry).
• Trademark Entitlement: element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
• Trademark Application Date: element that indicates the date the Registered Mark was applied for.
• Trademark Registration Date: element that indicates the date the Registered Mark was issued and registered.
• Trademark Class: element that indicates the class of the Registered Mark.
• IPR Type: element that indicates the Sunrise phase the application applies for.


IT and infrastructure resources

All the applications and databases for this TLD will run in a virtual environment hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors (or a more advanced, stable technology available at the time of deployment). The registry data will be stored on storage arrays of solid-state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources thus reducing energy consumption and carbon footprint.

The applications and servers are supported by network firewalls, routers and switches.
The WHOIS system accommodates both IPv4 and IPv6 addresses.

Each of the servers and network devices are equipped with redundant hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with our hardware vendor with a 4-hour response time at all our data centers guarantees replacement of failed parts in the shortest time possible.

Models of system and network devices used are:
• Servers: Cisco UCS B230 blade servers
• SAN storage arrays: IBM Storwize V7000 with Solid State Drives
• Firewalls: Cisco ASA 5585-X
• Load balancers: F5 Big-IP 6900
• Traffic shapers: Procera PacketLogic PL8720
• Routers: Juniper MX40 3D
• Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

There will be at least four virtual machines (VMs) offering WHOIS service. Each VM will run at least two WHOIS server instances - one for registrars and one for the public. All instances of the WHOIS service is made available to registrars and the public are rate limited to mitigate abusive behavior.


Frequency of synchronization between servers

Registration data records from the EPP publisher database will be replicated to the WHOIS system database on a near-real-time basis whenever an update occurs.


Specifications 4 and 10 compliance

The WHOIS service for this TLD will meet or exceed the performance requirements in the new gTLD Registry Agreement, Specification 10. Figure 26-c provides the exact measurements and commitments. The Service Provider has a 10 year track record of exceeding WHOIS performance and a skilled team to ensure this continues for all TLDs under management.

The WHOIS service for this TLD will meet or exceed the requirements in the new gTLD Registry Agreement, Specification 4.


RFC 3912 compliance

The Service Provider will operate the WHOIS infrastructure in compliance with RFCs and global best practices, as it does with the 16 TLDs The Service Provider currently supports.

The Service Provider maintains a registry-level centralized WHOIS database that contains information for every registered domain and for all host and contact objects. The WHOIS service will be available on the Internet standard WHOIS port (port 43) in compliance with RFC 3912. The WHOIS service contains data submitted by registrars during the registration process. Changes made to the data by a registrant are submitted to the system by the registrar and are reflected in the WHOIS database and service in near-real-time, by the instance running at the primary data center, and in under ten seconds by the instance running at the secondary data center, thus providing all interested parties with up-to-date information for every domain. This service is compliant with the new gTLD Registry Agreement, Specification 4.

The WHOIS service will be authoritative and complete, as this will be a “thick” registry (detailed domain contact WHOIS is all held at the registry); users do not have to query different registrars for WHOIS information, as there is one central WHOIS system. Additionally, visibility of different types of data is configurable to meet the registry operator’s needs.


Searchable WHOIS

The system offers a searchable WHOIS on a web-based Directory Service. Partial match capabilities are offered on the following fields: domain name, registrar ID, and IP address. In addition, the WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names.

Providing the ability to search important and high-value fields such as registrant name, address and contact names increases the probability of abusive behavior. An abusive user could script a set of queries to the WHOIS service and access contact data in order to create or sell a list of names and addresses of registrants in this TLD. Making the WHOIS machine readable, while preventing harvesting and mining of WHOIS data, is a key requirement integrated into the WHOIS systems. For instance, the system limits search returns to 50 records at a time. If bulk queries were ever necessary (e.g., to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process), the system would make such query responses available to carefully screened and limited staff members at the registry operator (and customer support staff) via an internal data warehouse. The WHOIS system accommodates anonymous access as well as pre-identified and profile-defined uses, with full audit and log capabilities.

The WHOIS service has the ability to tag query responses with labels such as “Do not redistribute” or “Special access granted”. This may allow for tiered response and reply scenarios. Further, the WHOIS service is configurable in parameters and fields returned, which allow for flexibility in compliance with various jurisdictions, regulations or laws.

The system offers exact-match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). Search capabilities are fully available, and results include domain names matching the search criteria (including IDN variants). The system manages abuse prevention through rate limiting and CAPTCHA (described below). Queries do not require specialized transformations of internationalized domain names or internationalized data fields

Please see “Query Controls” above for details about search options and capabilities.


Deterring WHOIS abuse

The Service Provider has adopted two best practices to prevent abuse of the WHOIS service: rate limiting and CAPTCHA.

Abuse of WHOIS services on port 43 and via the Web is subject to an automated rate-limiting system. This ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system.

Abuse of web-based public WHOIS services is subject to the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) technology. The use of CAPTCHA ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system. The registry operator will adopt a CAPTCHA on its Web-based WHOIS.

Data mining of any sort on the WHOIS system is strictly prohibited, and this prohibition is published in WHOIS output and in terms of service.

For rate limiting on IPv4, there are configurable limits per IP and subnet. For IPv6, the traditional limitations do not apply. Whenever a unique IPv6 IP address exceeds the limit of WHOIS queries per minute, the same rate-limit for the given 64 bits of network prefix that the offending IPv6 IP address falls into will be applied. At the same time, a timer will start and rate-limit validation logic will identify if there are any other IPv6 address within the original 80-bit(⁄48) prefix. If another offending IPv6 address does fall into the ⁄48 prefix then rate-limit validation logic will penalize any other IPv6 addresses that fall into that given 80-bit (⁄48) network. As a security precaution, the Service Provider will not disclose these limits.

Pre-identified and profile-driven role access allows greater granularity and configurability in both access to the WHOIS service, and in volume⁄frequency of responses returned for queries.

The Service Provider staff are key participants in the ICANN Security & Stability Advisory Committee’s deliberations and outputs on WHOIS, including SAC003, SAC027, SAC033, SAC037, SAC040, and SAC051. Its staffs are active participants in both technical and policy decision making in ICANN, aimed at restricting abusive behavior.


WHOIS staff resourcing plans

The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the project management methodology allows efficient and effective use of our staff in a focused way.

There are 11 staff members who develop and maintain the compliant WHOIS systems. They keep pace with access requirements, thwart abuse, and continually develop software. Of these resources, approximately two staffers are typically required for WHOIS-related code customization. Other resources provide quality assurance, and operations personnel maintain the WHOIS system itself. This team will be responsible for the implementation and on-going maintenance of the new TLD WHOIS service.

27. Registration Life Cycle

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉”
CHARACTERS, or < and >), WHICH ICANN INFORMS US (CASE ID 11027)
CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE,
THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE
AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO
ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN
UNDER CASE ID 11027.


Answers for this question (#27) are provided in cooperation with The Service Provider, the back-end provider of registry services (hereinafter referred to as the ‘Back-End Operator’) for the applied-for TLD.
The .WILMAR registry will follow the lifecycle and business rules found in the majority of gTLDs today. The Applicant’s back-end registry operator, The Service Provider, has over ten years of experience managing numerous TLDs that utilize standard and unique business rules and lifecycles. It operates with comprehensive registration lifecycle services, which include support for all standard grace periods and registration states, and can address any modifications required by new ICANN policies.This section describes the business rules, registration states, and the overall domain lifecycle that will be use for .WILMAR.
The applied-for TLD will largely follow the ICANN standard domain lifecycle, as is currently implemented in TLDs such as .ORG and .INFO. The below response includes: a diagram and description of the lifecycle of a domain name in this TLD, including domain creation, transfer protocols, grace period implementation and the respective time frames for each; and the existing resources to support the complete lifecycle of a domain.

As depicted in Annex E – Figure 27-a, prior to the beginning of the Trademark Claims Service or Sunrise IP protection program[s], the Applicant, through its Back-End Operator, will support the reservation of names in accordance with the new gTLD Registry Agreement, Specification 5. After that, the IP protection program will commence (see the response to Question #29). Upon the program close, names will be available for general registration and take a uniform life cycle described below.


Registration period
A domain can be created at any time after the TLD is placed in the root.

Prior to the launch and prior to the Sunrise period, only registry-reserved names can be registered in accordance with the new gTLD Registry Agreement Specification 5. After the IP protection programs and the general launch, eligible registrants may choose an accredited registrar to register a domain name. The registrar will check availability on the requested domain name and if available, will collect specific objects such as, the required contact and host information from the registrant and. The registrar will then provision the information into the registry via system using standard Extensible Provisioning Protocol (“EPP”) commands through a secure connection to the registry backend service provider.
When the domain name is created, the standard five day Add Grace Period (the duration of this Add Grace Period may change, insofar permissible to ICANN) begins the domain and contact information are available in WHOIS, and normal operating EPP domain name statuses will apply. Other specifics regarding registration rules for an active domain name include:
- The domain name must be unique;
- Restricted or reserved domain names cannot be registered;
- The domain name can be registered from 1-10 years;
- The domain name can be renewed at any time for 1-10 years, but cannot exceed 10 years;
- The domain name can be explicitly deleted at any time;
- The domain name can be transferred from one registrar to another except during the first 60 days following a successful registration or within 60 days following a transfer; and,
- Contacts and hosts can be modified at any time.


The following describe the domain name status values recognized in WHOIS when using the EPP protocol following RFC 5731.
- OK or Active: This is the normal status for a domain name that has no pending operations or restrictions.
- Inactive: The domain name has no delegated name servers.
- Locked: No action can be taken on the domain name. The domain name cannot be renewed, transferred, updated, or deleted. No objects such as contacts or hosts can be associated to, or disassociated from the domain name. This status includes: Delete Prohibited ⁄ Server Delete Prohibited, Update Prohibited ⁄ Server Update Prohibited, Transfer Prohibited, Server Transfer Prohibited, Renew Prohibited, Server Renew Prohibited.
- Hold: The domain name will not be included in the zone. This status includes: Client Hold, Server Hold.
- Transfer Prohibited: The domain name cannot be transferred away from the sponsoring registrar. This status includes: Client Transfer Prohibited, Server Transfer Prohibited.

The following describe the registration operations that apply to the domain name during the registration period.
i. Domain modifications: This operation allows for modifications or updates to the domain attributes to include:
i. Registrant Contact
ii. Admin Contact
iii. Technical Contact
iv. Billing Contact
v. Host or nameservers
vi. Authorization information
vii. Associated status values
A domain name with the EPP status of Client Update Prohibited or Server Update Prohibited may not be modified until the status is removed.

b) Domain name renewals: This operation extends the registration period of a domain by changing the expiration date. The following rules apply:
i. A domain name can be renewed at any time during its registration term,
ii. The registration term cannot exceed a total of 10 years.
A domain with the EPP status of Client Renew Prohibited or Server Renew Prohibited cannot be renewed.

a) Domain name deletions: This operation deletes the domain name from the Shared Registry Services (SRS). The following rules apply:
i. A domain name can be deleted at any time during its registration term,
ii. If the domain name is deleted during the Add Grace Period or the Renew⁄Extend Grace Period, the sponsoring registrar will receive a credit,
iii. A domain name cannot be deleted if it has “child” nameservers that are associated to other domains.
A domain name with the EPP status of Client Delete Prohibited or Server Delete Prohibited cannot be deleted.

b) Domain name transfers: A transfer of the domain from one registrar to another is conducted by following the steps below.
i. The registrant must obtain the applicable 〈authInfo〉 code from the sponsoring (losing) registrar.
• Every domain name has an authInfo code as per EPP RFC 5731. The authInfo code is a six- to 16-character code assigned by the registrar at the time the name was created. Its purpose is to aid identification of the domain name holder so proper authority can be established (it is the ʺpasswordʺ to the domain).
• Under the Registry-Registrar Agreement, registrars will be required to provide a copy of the authInfo code to the domain name registrant upon his or her request.
ii. The registrant must provide the authInfo code to the new (gaining) registrar, who will then initiate a domain name transfer request. A transfer cannot be initiated without the authInfo code.
• Every EPP 〈transfer〉 command must contain the authInfo code or the request will fail. The authInfo code represents apparent authority to the registry to initiate a transfer.
iii. Upon receipt of a valid transfer request, the registry automatically asks the sponsoring (losing) registrar to approve the request within five calendar days.
• When a registry receives a transfer request the domain name cannot be modified, renewed or deleted until the request has been processed. This status must not be combined with either Client Transfer Prohibited or Server Transfer Prohibited status.
• If the sponsoring (losing) registrar rejects the transfer within five days, the transfer request is cancelled. A new domain name transfer request will be required to reinitiate the process.
• If the sponsoring (losing) registrar does not approve or reject the transfer within five days, the registry automatically approves the request.
iv. After a successful transfer, it is strongly recommended that registrars change the authInfo code, so that the prior registrar or registrant cannot use it anymore.
v. Registrars must retain all transaction identifiers and codes associated with successful domain name object transfers and protect them from disclosure.
vi. Once a domain name is successfully transferred the status of TRANSFERPERIOD is added to the domain for a period of five days.
vii. Successful transfers will result in a minimum one year term extension to a maximum of 10 years, which will be charged to the gaining registrar.

c) Bulk transfer: The Service Provider, supports bulk transfer functionality within the SRS for situations where ICANN may request the registry to perform a transfer of some or all registered objects (includes domain name, contact and host objects) from one registrar to another registrar. Once a bulk transfer has been executed, expiry dates for all domain name objects remain the same, and all relevant states of each object type are preserved. In some cases the gaining and the losing registrar as well as the registry must approved bulk transfers. A detailed log is captured for each bulk transfer process and is archived for audit purposes.


Applicant will support ICANN’s Transfer Dispute Resolution Process. Applicant also understands that it may occasionally be called upon to receive Requests for Enforcement (law enforcement or court orders) and will follow that process.


1. Auto-renew grace period
The Auto-Renew Grace Period displays as AUTORENEWPERIOD in WHOIS. An auto-renew occurs if a domain name registration is not explicitly renewed or deleted by the expiration date and is set to a maximum of 45 calendar days. In this circumstance the registration will be automatically renewed by the registry system the first day after the expiration date. If a Delete, Extend, or Transfer occurs within the AUTORENEWPERIOD the following rules apply:

i. Delete. If a domain name is deleted the sponsoring registrar at the time of the deletion receives a credit for the auto-renew fee. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.


ii. Renew⁄Extend. A domain name can be renewed as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed.
iii. Transfer (other than ICANN-approved bulk transfer). If a domain name is transferred, the losing registrar is credited for the auto-renew fee, and the year added by the operation is cancelled. As a result of the transfer, the expiration date of the domain name is extended by minimum of one year as long as the total term does not exceed 10 years. The gaining registrar is charged for the additional transfer year(s) even in cases where a full year is not added because of the maximum 10 year registration restriction.
2. Redemption grace period
During this period, a domain name is placed in the PENDING DELETE RESTORABLE status when a registrar requests the deletion of a domain that is not within the Add Grace Period. A domain can remain in this state for up to 30 days and will not be included in the zone file. The only action a registrar can take on a domain is to request that it be restored. Any other registrar requests to modify or otherwise update the domain will be rejected. If the domain is restored it moves into PENDING RESTORE and then OK. After 30 days if the domain name is not restored it moves into PENDING DELETE SCHEDULED FOR RELEASE before the domain is released back into the pool of available domains.


3. Pending delete
During this period, a domain name is placed in PENDING DELETE SCHEDULED FOR RELEASE status for five days, and all Internet services associated with the domain will remain disabled and domain name cannot be restored. After five days the domain name is released back into the pool of available domains.

Other grace periods
All ICANN required grace periods will be implemented in the registry backend service provider’s system including the Add Grace Period (AGP), Renew⁄Extend Grace Period (EGP), Transfer Grace Period (TGP), Auto-Renew Grace Period (ARGP), and Redemption Grace Period (RGP). The lengths of grace periods are configurable in the registry system. At this time, the grace periods will be implemented following other gTLDs such as .ORG. More than one of these grace periods may be in effect at any one time. The following are accompanying grace periods to the registration lifecycle.

Add grace period
The Add Grace Period displays as ADDPERIOD in WHOIS and is normally set to five calendar days following the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the registration. If a Delete, Renew⁄Extend, or Transfer operation occurs within the five calendar days, the following rules apply.

i. Delete. If a domain name is deleted within this period the sponsoring registrar at the time of the deletion is credited for the amount of the registration. The domain name is deleted from the registry backend service provider’s database and is released back into the pool of available domains.
ii. Renew⁄Extend. If the domain name is renewed within this period and then deleted, the sponsoring registrar will receive a credit for both the registration and the extended amounts. The account of the sponsoring registrar at the time of the renewal will be charged for the initial registration plus the number of years the registration is extended. The expiration date of the domain registration is extended by that number of years as long as the total term does not exceed 10 years.
iii. Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the ADDPERIOD or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the registrar sponsoring the domain name registration and is enforced by the SRS.
Renew ⁄ extend grace period
The Renew ⁄ Extend Grace Period displays as RENEWPERIOD in WHOIS and is set to five calendar days following an explicit renewal on the domain name by the registrar. If a Delete, Extend, or Transfer occurs within the five calendar days, the following rules apply:

ii. Delete. If a domain name is deleted within this period the sponsoring registrar at the time of the deletion receives a credit for the renewal fee. The domain then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.
iii. Renew⁄Extend. A domain name registration can be renewed within this period as long as the total term does not exceed 10 years. The account of the sponsoring registrar at the time of the extension will be charged for the additional number of years the registration is renewed.
iv. Transfer (other than ICANN-approved bulk transfer). If a domain name is transferred within the Renew⁄Extend Grace Period, there is no credit to the losing registrar for the renewal fee. As a result of the transfer, the expiration date of the domain name registration is extended by a minimum of one year as long as the total term for the domain does not exceed 10 years.
If a domain name is auto-renewed, then extended, and then deleted within the Renew⁄Extend Grace Period, the registrar will be credited for any auto-renew fee charged and the number of years for the extension. The years that were added to the domain’s expiration as a result of the auto-renewal and extension are removed. The deleted domain is moved to the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.



Transfer Grace Period
The Transfer Grace period displays as TRANSFERPERIOD in WHOIS and is set to five calendar days after the successful transfer of domain name registration from one registrar to another registrar. Transfers under Part A of the ICANN Policy on Transfer of Registrations between registrars may not occur during the TRANSFERPERIOD or within the first 60 days after the transfer. If a Delete or Renew⁄Extend occurs within that five calendar days, the following rules apply:

i. Delete. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer. The domain name then moves into the Redemption Grace Period with a status of PENDING DELETE RESTORABLE.
ii. Renew⁄Extend. If a domain name registration is renewed within the Transfer Grace Period, there is no credit for the transfer. The registrarʹs account will be charged for the number of years the registration is renewed. The expiration date of the domain registration is extended by the renewal years as long as the total term does not exceed 10 years.
In the event that the Applicant was to decide to conduct an auction for certain domain names (which is currently not part of the business plan of the Applicant), The Service Provider will manage the domain name auction using existing technology. Upon the completion of such auction, any domain name acquired will then follow the standard lifecycle of a domain.



Registration lifecycle resourcing plans
Since its founding, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the project management methodology that shall be used by the Applicant’s Back-End Operator for the applied-for gTLD, will allow efficient and effective use of the Back-End Operator’s staff in a focused way. Virtually all of the Applicant’s Back-End Operator’s resources are involved in the registration lifecycle of domains.

There are a few areas where The Service Provider’ registry staff devote resources to registration lifecycle issues:
a. a. Supporting Registrar Transfer Disputes. The registry operator will have a compliance staffer handle these disputes as they arise; they are very rare in the existing gTLDs.
b. b. The Service Provider has its development and quality assurance departments on hand to modify the grace period functionality as needed, if ICANN issues new Consensus Policies or the RFCs change.
c. The Service Provider has more than 30 devoted staff resources for this.

28. Abuse Prevention and Mitigation

Strong abuse prevention of a new gTLD is an important benefit to the internet community.  The Applicant is of the opinion that a registry must not only aim for the highest standards of technical and operational competence, but also needs to be protective of the space under .WILMAR on behalf of the Internet community and ICANN in promoting the public interest.  
The Applicant will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the .WILMAR TLD. The specific measures include, but are not limited to:

− Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
− Committing to rapid identification and resolution of abuse, including suspensions;
− Ensuring completeness of WHOIS information at the time of registration;
− Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;
− Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.


Abuse policy
The Applicant will adopt an Anti-Abuse Policy that clearly defines the types of activities that will not be permitted in the .WILMAR TLD and reserves the right of the registry operator to cancel, transfer, or otherwise suspend or take down a domain name that violates the Acceptable Use Policy and allow the registry operator – where and when appropriate – to share information with law enforcement agencies. Each ICANN-Accredited Registrar must agree to pass through the Acceptable Use Policy to its Reseller(s) (if applicable) and ultimately to the domain name registrant(s) in the TLD.


The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. The Anti-Abuse Policy will be posted on the .WILMAR TLD web site along with contact information for registrants or users to report suspected abuse.

The Anti-Abuse Policy will be designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This Anti-Abuse Policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain name users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

The below Anti-Abuse Policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool. This Anti-Abuse Policy will serve as an example for the Anti-Abuse Policy to be used in connection with the applied-for TLD.


.WILMAR Anti-Abuse Policy
An Anti-Abuse Policy identical or similar to the following Anti-Abuse Policy will be effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:

− Illegal or fraudulent actions;
− Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums;
− Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
− Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
− Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses.
− Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.
− Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
− Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, (5) to protect the reputation and⁄or activities of the registry operator, the integrity of its .WILMAR brand and⁄or any of the registry operator’s trademarks, and⁄or (6) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The Anti-Abuse Policy that will be adopted by the Applicant shall be accompanied by notes on how to submit a report to the registry operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).


Abuse point of contact and procedures for handling abuse complaints
The registry operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.WILMAR”. This e-mail address will allow multiple staff members of the Applicant, any of its sub-contractor (which may be an ISP or a registrar) and⁄or its Back-End Operator to monitor abuse reports on a 24x7 basis, and then work toward the efficient handling of cases as each situation calls for. For tracking purposes, the registry operator will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. The Service Provider will integrate its existing ticketing system with the registry operator’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.


The registry operator’s designated abuse point of contact and⁄or abuse handlers will then evaluate complaints received via the abovementioned email address. They will decide whether or not a particular issue is of concern, and decide what action, if any, is appropriate.

The Applicant may receive abuse reports from a wide variety of parties as a registry operator, including from security researchers and Internet security companies, financial institutions such as banks, ordinary Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be sufficient evidence to support the complaint (even after investigation), or because some reports or reporters will not be credible.

Assessing abuse reports requires great care, and the registry operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities may require different methods of investigation and documentation, which will be implemented by the Applicant as the need may arise. During the operation of the applied-for TLD, the Applicant may also face unexpected or complex situations that call for professional advice. The registry operator will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that will be addressed, if occuring:
a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.
b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.

The standard procedure is that the registry operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this. The registrar is the party with a direct relationship with – and a direct contract with – the registrant. The registrar may also have vital information that the registry operator has not, such as:
− Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
− The identity of a proxy-protected registrant;
− The purchaser’s IP address;
− Whether there is a reseller involved, and;
− The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).

In general, Registrars do not share the above information with registry operators (due to privacy, liability and⁄or other concerns). Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine whether or not the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, if the registrant violates ICANN policy, if the registrant is involved in illegal activity through the domain name, or if the registrant violates the registry’s Anti-Abuse Policy.

If a registrar has not taken action within the time period indicated by the registry operator (usually 24 hours), the Applicant, acting as the registry operator of the applied-for TLDmay itself take action. At all times, the registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.
The registry operator will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where the registry operator will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which the registry operator, although the operator in all cases will adhere to applicable laws and regulations.


When valid court orders or seizure warrants are received from courts or law enforcement agencies having the required jurisdiction, the Applicant, acting as the registry operator of the applied-for TLD shall order execution in an expedited fashion. Compliance with such court orders or seizure warrants shall be a top priority and shall be completed within the briefest delays and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:
- Registration information
- History of a domain, including recent updates made
- Other domains associated with a registrant’s account
- Patterns of registrant portfolio

Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. The selected back-end registry operator of the Applicant, The Service Provider sets a goal to respond to such requests within 24 hours. Given the controlled manner in which the Applicant will operate the applied-for TLD, the Applicant does not expect to have to answer many of these requests.

The Applicant, acting as the registry operator of the applied-for TLD may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The Applicant will be able to use the following resources, among others, or any combination thereof:
− Blocklists of domain names and name servers published by organizations such as SURBL and Spamhaus.
− Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.
− Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.]

The Applicant, acting as the registry operator of the applied-for TLD, will keep records and track metrics regarding abuse and abuse reports. These will include:
− Number of abuse reports received by the registry’s abuse point of contact described above;
− Number of cases and domains referred to registrars for resolution;
− Number of cases and domains where the registry took direct action;
− Resolution times;
− Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;
− Phishing site uptimes in the TLD.


Removal of orphan glue records
By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.)

Orphan glue records may be created when a domain name (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain name is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain name (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Through its Back-End Operator, the Applicant shall observe the following procedures, which are being followed by other registries (inclusive of the Applicant’s Back-End Operator) and are generally accepted as DNS best practices. The procedures that will be observed by the Applicant are also in line with the ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the Applicant’s registry (through The Service Provider) shall first checks for the existence of glue records. If glue records exist, the Applicant’s registry will check to see if other domain names in the registry are using the glue records. If other domain names in the registry are using the glue records then the request to delete the domain name will fail until no other domain names are using the glue records. If no other domain names in the registry are using the glue records, then the glue records will be removed before the request to delete the domain name is satisfied. If no glue records exist then the request to delete the domain name will be satisfied.

If a registrar cannot delete a domain name because of the existence of glue records that are being used by other domain names, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domain names are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The Applicant, through its Back-End Operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator of the applied-for TLD, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. The Applicant’s Back-End Operator has the technical ability to execute such requests as needed. Generally, direct manipulation of the zone is not performed. Functionality exists in the registry EPP and DNS distributor software that will be used for the .WILMAR TLD to initiate such removals by changing the status on the domain or host objects. If necessary, scripts can be used for larger batches.


Methods to promote WHOIS accuracy
The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in the Applicant’s response to Question #26 relating to WHOIS services, the Applicant, acting as the registry operator for the applied-for TLD will manage a secure, robust and searchable WHOIS service for the applied-for TLD.

WHOIS data accuracy
The Applicant, acting as the registry operator of the applied-for TLD, will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This will allow better access to domain data, and will provide uniformity in storing the information. The Applicant, acting as the registry operator of the applied-for TLD, will ensure that the required fields for WHOIS data (as per the defined policies for the applied-for TLD) are enforced at the registry level. This will ensure that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory, are documented as such and must be submitted by registrars. The The Service Provider registry system that will be used for the applied-for TLD verifies formats for relevant individual data fields (e.g., e-mail, and phone⁄fax numbers). Only valid country codes will be allowed as defined by the ISO 3166 code list. The The Service Provider WHOIS system that will be used for the .WILMAR TLD is extensible, and is capable of using the VAULT system, described further below.

Similar to the centralized abuse point of contact described above, the registry operator can institute a contact email address which could be utilized by third parties to submit complaints for inaccurate or false WHOIS data detected. This information will be processed by The Service Provider’ support department and forwarded to the registrars. The registrars can work with the registrants of those domains to address these complaints. The Service Provider will audit registrars on a yearly basis to verify whether the complaints being forwarded are being addressed or not. This functionality, available to all registry operators, is activated based on the registry operator’s business policy.

The Service Provider also incorporates a spot-check verification system where a randomly selected set of domain names are checked periodically for accuracy of WHOIS data. The Service Provider’ .PRO registry system incorporates such a verification system whereby 1% of total registrations or 100 domains, whichever number is larger, are spot-checked every month to verify the domain name registrant’s critical information provided with the domain registration data. With both a highly qualified corps of engineers and a 24x7 staffed support function, The Service Provider has the capacity to integrate such spot-check functionality into this TLD, based on the registry operator’s business policy. Note: This functionality will not work for proxy protected WHOIS information, where registrars or their resellers have the actual registrant data. The solution to that problem lies with either registry or registrar policy, or a change in the general marketplace practices with respect to proxy registrations.

Finally, The Service Provider’ registry systems have a sophisticated set of billing and pricing functionality which aids registry operators who decide to provide a set of financial incentives to registrars for maintaining or improving WHOIS accuracy. For instance, it is conceivable that the registry operator may decide to provide a discount for the domain registration or renewal fees for validated registrants, or levy a larger cost for the domain registration or renewal of proxy domain names. The The Service Provider system has the capability to support such incentives on a configurable basis, towards the goal of promoting better WHOIS accuracy.



Role of registrars
As part of the Registry Registrar Agreement (RRA ), the Applicant, acting as the registry operator of the applied-for TLD, will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports at http:⁄⁄wdprs.internic.net⁄, as per ICANN policy.

Controls to ensure proper access to domain functions
Several measures are in place in the The Service Provider registry system that will be used for the applied-for TLD to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication will be used to control access to the registry system. Registrars will only be given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the Applicant’s response to Question #30b.


Validation and abuse mitigation mechanisms
The Applicant’s Back-End Operator has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

Through its Back-End Operator, the Applicant will have the ability to analyze the registration data for known patterns at the time of registration. A database of such known patterns has already been developed from domain namess and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domain names matching the defined criteria can be flagged for investigation by the domain anti-abuse team members. These domain names may be suspended. This provides proactive detection of abusive domain names and allows for the further development of the database of mentioned patterns.

Provisions are available that may enable the registry operator to only allow registrations by pre-authorized and verified contacts. These verified contacts are given a unique code that can be used for registration of new domains.


Registrant pre-verification and authentication
One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).


Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

• Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.
• Based on required WHOIS Data; registrant contact details (name, address, phone)
• If address⁄ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)
• If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions.
• If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant.
• If Whois data is validated a token would be generated and could be given back to the registrar which registered the domain.
• Whois data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.
• A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers
• Validation would be annually renewed, and validation date displayed in the WHOIS.



Abuse prevention resourcing plans
Since its founding, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the The Service Provider project management methodology allows efficient and effective use of our staff in a focused way. Abuse prevention and detection is a function that is staffed across the various groups inside The Service Provider, and requires a team effort when abuse is either well hidden or widespread, or both. While all of The Service Provider’ 200+ employees are charged with responsibility to report any detected abuse, the engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The The Service Provider security and support teams have the authority to initiate mitigation.
The Service Provider has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.
The registry operator will maintain an abuse response team, which may be a combination of internal staff and outside specialty contractors, adjusting to the needs of the size and type of TLD. The team structure planned for this TLD is based on several years of experience responding to, mitigating, and managing abuse for TLDs of various sizes. The team will generally consist of abuse handlers (probably internal), a junior analyst, (either internal or external), and a senior security consultant (likely an external resource providing the registry operator with extra expertise as needed. These responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

The exact resources required to maintain an abuse response team may change in function of the size and registration procedures of the .WILMAR TLD. An initial abuse handler will be appointed as a point of contact for reports, even if a part-time responsibility. Abuse handlers will monitor the abuse email address for complaints and evaluate incoming reports from a variety of sources. A large percentage of abuse reports to the registry operator may be unsolicited commercial email. The designated abuse handlers can identify legitimate reports and then decide what action is appropriate, either to act upon them, escalate to a security analyst for closer investigation, or refer them to registrars as per the above-described procedures. A TLD with rare cases of abuse would conform to this structure.


In the unlikely event – given the controlled way in which the .WILMAR TLD is planned to be operated – that, multiple cases of abuse within the same week occur regularly, the registry operator will consider staffing internally a security analyst to investigate the complaints as they become more frequent. In is expected that training an abuse analyst requires 3-6 months and likely requires the active guidance of an experienced senior security analyst for guidance and verification of assessments and recommendations being made.

If the .WILMAR TLD were to regularly experience multiple cases of abuse within the same day, a full-time senior security analyst would likely be necessary. A senior security analyst capable of fulfilling this role should have several years of experience and able to manage and train the internal abuse response team. Once again, given the controlled way in which the .WILMAR is planned to be operated, it is highly unlikely that this will be required.

The abuse response team will also maintain subscriptions for several security information services, including the blocklists from organizations like SURBL and Spamhaus and anti-phishing and other domain related abuse (malware, fast-flux etc.) feeds. The pricing structure of these services may depend on the size of the domain and some services will include a number of rapid suspension requests for use as needed.


For a large TLD, regular audits of the registry data will be required to maintain control over abusive registrations. When a registrar with a significant number of registrations has been compromised or acted maliciously, the registry operator may need to analyze a set of registration or DNS query data. A scan of all the domains of a registrar is conducted only as needed. Scanning and analysis for a large registrar may require as much as a week of full-time effort for a dedicated machine and team. The Applicant will do this to the extent needed.

To the extent needed, the Applicant will involve internal and external resources for abuse prevention, detection and mitigation.

29. Rights Protection Mechanisms

Rights protection is a core responsibility of the  Registry Operator, and is supported by a well-developed plan for rights protection that includes:
- Establishing mechanisms to prevent unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies);
- Implementing a robust Sunrise program, utilizing the Trademark Clearinghouse, the services of one of ICANN’s approved dispute resolution providers, a trademark validation agent, and drawing upon sunrise policies and rules used successfully in previous gTLD launches;
- Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
- Complying with the URS requirements;
- Complying with the UDRP;
- Complying with the PDDRP, and;
- Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.

The response below details the rights protection mechanisms at the launch of the TLD (Sunrise period and Trademark Claims Service), the compliance with rights protection policies (URS, UDRP, PDDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans.

Safeguards for rights protection at the launch of the TLD
The launch of this TLD will include the operation of a trademark claims service according to the defined ICANN processes for checking a registration request and alerting trademark holders of potential rights infringement.

Sunrise period

The Sunrise Period will be an exclusive period of time, prior to the opening of public registration, when trademark and service mark holders will be able to reserve marks that are an identical match in the TLD domain. Following the Sunrise Period, Applicant will open registration to qualified applicants.

The anticipated Rollout Schedule for the Sunrise Period will be approximately as follows:
- Launch of the TLD – Sunrise Period begins for trademark holders and service mark holders to submit registrations for their exact marks in the TLD domain. To maximize fairness registrations will be processed via four queues of a randomized, round robin system, which will close 15 days, 30 days, 45 days and 60 days following the launch date respectively (date are indicative). Following this, PIR expects the balance of Sunrise registrations to be awarded in real-time.

- Five months after launch –The Sunrise Period will close and will be followed by a Quiet Period for testing and evaluation.

- One month after close of Quiet Period – Registration in the TLD domain will be opened to qualified applicants.
- After the close of Quite Period – TLD domain names, registered by third parties will begin to resolve through standard Web browsers. Domain names registered by the registry operator itself may resolve before that date.

Sunrise Period Requirements & Restrictions
Eligible registrants wishing to reserve their marks in the TLD domain during the Sunrise Period must own a current trademark or service mark listed in the Trademark Clearinghouse.

Notice will be provided to all trademark holders in the Clearinghouse if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an Identical Match (as defined in the Trademark Clearing House) to the name to be registered during Sunrise.

Each Sunrise registration will require a minimum term of five years.

The Applicant will establish the following Sunrise eligibility requirements (SERs) as minimum requirements, verified by Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP). Additianal eligibility requirements may apply. The SERs include: (i) ownership of a mark that satisfies the criteria set forth in section 7.2 of the Trademark Clearing House specifications, (ii) description of international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

The SDRP will allow challenges based on the following four grounds: (i) at time the challenged domain name was registered, the registrants did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.


Ongoing rights protection mechanisms
Several mechanisms will be in place to protect rights in the .WILMAR TLD. As described in the Applicant’s responses to Questions #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and an experienced team is available to respond to legal actions by law enforcement or court orders.

The Applicant will conform to all ICANN RPMs during the operation of the applied-for TLD. These RPMs will include the URS (defined below), UDRP, PDDRP, and all measures defined in Specification 7 of the new TLD agreement.


Uniform Rapid Suspension (URS)
The registry operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site, the registry operator will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the registry operator’s support staff, which may be provided by the Applicant’s Back-End Operator and which will be on duty 24x7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.

As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the registry operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
- ServerUpdateProhibited, with an EPP reason code of “URS”
- ServerDeleteProhibited, with an EPP reason code of “URS”
- ServerTransferProhibited, with an EPP reason code of “URS”
- The registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email.

The registry operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.

The registry operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.

As per the URS guidelines, if the complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”


Rights protection via the RRA
The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant agreements:

- The registry operator may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:
a. to enforce registry policies and ICANN requirements; each as amended from time to time;
b. that is not accompanied by complete and accurate information as required by ICANN requirements and⁄or registry policies or where required information is not updated and⁄or corrected as required by ICANN requirements and⁄or registry policies;
c. to protect the integrity and stability of the registry, its operations, and the TLD system;
d. to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
e. to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
f. to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
g. as otherwise provided in the Registry-Registrar Agreement and⁄or the Registrar-Registrant Agreement.


Reducing opportunities for behaviors such as phishing or pharming
In its response to question #28, the Applicant has described its proposed anti-abuse program. Rather than repeating the policies and procedures here, please see our response to question #28 for full details.

These procedures will sometimes allow the registry operator to identify the domain name portfolios of phishers, and suspend those portfolios before all of the domains in them are used. This will reduce damage to Internet users and the brands that such phishers target.

Every six months, the Anti-Phishing Working Group (APWG) publishes its latest Global Phishing Survey. (See http:⁄⁄www.apwg.org⁄resources.html#apwg). Each edition of this study contains an analysis of how phishers construct phishing URLs and register domain names. The registry operator, together with its Back-End Operator will continue to track that report and ongoing trends. APWG studies show that in the first half of 2011, just two percent of the domain names used for phishing (or 12% of malicious phishing registrations) contained a targeted brand name or misspelling thereof. According to the APWG, in the year July 2010 through June 2011, there were only about 5,700 known brand-or-misspelling phishing domains registered in all TLDs worldwide.


The demonstrated phishing problem is therefore a tiny percentage of domain registrations overall, and should be balanced against the impact that filtering or denying incoming domain registrations in an open registration period may have upon other parties. The number of potential variations and misspellings of target brand names is very large, and attempts to deny registrations containing them might infringe upon the rights of other trademark holders. For example, misspellings of “Google” include “goggle” and “boggle” – but “goggle” and “boggle” are trademarked terms in use by multiple trademark owners across the globe. Therefore preemptive blocking of variations of for instance “Google” by the registry could infringe upon the rights of other legitimate registrants, and favor one registrant in one country over multiple potential registrants in that or other jurisdictions. This variant or misspelling problem is why ICANN specified that only exact domain name string matches will be addressed by the Trademark Clearinghouse. In addition, most generic words are trademarked, and trademarked terms may be found within larger words that would be legitimate for registrants to register.
For these reasons, the registry operator does not plan on heuristics based filtering or denying registrations as they come to the registry during the Land Rush and Open Registration periods based on misspelling detection algorithms. Instead, the Applicant may prefer an approach that addresses registered domain names (rather than potentially registered domains). This approach will not infringe upon the rights of legitimate and eligible registrants to register domains, and allows the Applicant’s internal controls as well as community-developed UDRP and URS policies and procedures, if needed, to deal with complaints should there be any.

The Service Provider is a member of various security fora which provide access to lists of names in each TLD which may be used for malicious purposes. Such identified names will be subject to the TLD anti-abuse policy, including rapid suspensions after due process.

With specific respect to phishing and pharming, it should be noted by ICANN that the .WILMAR TLD will, at least in first instance, operate as a single-registrant TLD in which Applicant has direct control over each registrant (they are typically on staff or otherwise contractually bound) and how each registration may be used. Since all criminal activity (such as phishing and pharming) is precluded by the mission, values and policies of the registry operator (and its parent organization), criminal activity is not expected to be a problem. If such activity occurs due to hacking or other compromises, the registry operator will take prompt and effective steps to eliminate the activity.

Rights protection resourcing plans
Since its founding, The Service Provider is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the The Service Provider registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of the .WILMAR TLD. The Service Provider operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the The Service Provider project management methodology allows efficient and effective use of our staff in a focused way.
Supporting RPMs requires several departments within the registry operator as well as within its Back-End Operator, ⁄The Service Provider. The implementation of Sunrise and the Trademark Claims service and on-going RPM activities will pull from the 102 The Service Provider staff members of the engineering, product management, development, security and policy teams at The Service Provider and the IP (or other appropriate) department at the registry operator and the support staff of service providers to the registry operator. Support staff will be on duty 24x7 for this. A trademark validator will also be assigned within the registry operator, whose responsibilities may require as much as 50% of full-time employment if the domains under management were to exceed several million. No additional hardware or software resources are required to support this as the Applicant’s Back-End Operator has fully-operational capabilities to manage abuse today.

30(a). Security Policy: Summary of the security policy for the proposed registry

The answer to Question #30a is provided in cooperation with The Service Provider, the back-end provider of registry services (hereinafter referred to as the Back-End Operator) for the applied-for TLD.

The Applicant, through its Back-End Operator shall aggressively and actively protect the registry system from known threats and vulnerabilities, and shall deploy an extensive set of security protocols, policies and procedures to thwart compromise. The Service Provider’ robust and detailed plans that will be used for the applied-for TLD are continually updated and tested to ensure new threats are mitigated prior to becoming issues. The Service Provider will continue these rigorous security measures, which include:
- Multiple layers of security and access controls throughout registry and support systems;
- 24x7 monitoring of all registry and DNS systems, support systems and facilities;
- Unique, proven registry design that ensures data integrity by granting only authorized access to the registry system, all while meeting performance requirements;
- Detailed incident and problem management processes for rapid review, communications, and problem resolution, and;
- Yearly external audits by independent, industry-leading firms, as well as twice-yearly internal audits.

Security policies and protocols
The Applicant’s Back-End Operator that will be used for the applied-for TLD has included security in every element of its service, including facilities, hardware, equipment, connectivity⁄Internet services, systems, computer systems, organizational security, outage prevention, monitoring, disaster mitigation, and escrow⁄insurance, from the original design, through development, and finally as part of production deployment. Examples of threats and the confidential and proprietary mitigation procedures are detailed in our response to Question #30(b).

There are several important aspects of the security policies and procedures to note:
- The Applicant’s Back-End Operator hosts and will host domain names in data centers around the world that meet or exceed global best practices.
- The Applicant’s Back-End Operator’s DNS infrastructure is massively provisioned as part of its DDoS mitigation strategy, thus ensuring sufficient capacity and redundancy to support new gTLDs, inclusive of the applied-for TLD.
- Diversity is an integral part of all of the Applicant’s Back-End Operator’s software and hardware stability and robustness plan, thus avoiding any single points of failure in its infrastructure.
- Access to any element of the Applicant’s Back-End Operator’s service (applications, infrastructure and data) is only provided on an as-needed basis to employees and a limited set of others to fulfill their job functions. The principle of least privilege is applied.
- All registry components – critical and non-critical – are monitored 24x7 by staff at the Network Operations Centers of the Applicant’s Back-End Operator, and the technical staff has detailed plans and procedures that have stood the test of time for addressing even the smallest anomaly. Well-documented incident management procedures are ans will remain in place to quickly involve the on-call technical and management staff members to address any issues.

The Applicant’s Back-End Operator follows the guidelines from the ISO 27001 Information Security Standard (Reference: http:⁄⁄www.iso.org⁄iso⁄iso_catalogue⁄catalogue_tc⁄catalogue_detail.htm?csnumber=42103 ) for the management and implementation of its Information Security Management System that will be used for the applied-for TLD. The Applicant’s Back-End Operator also utilizes the COBIT IT governance framework to facilitate policy development and enable controls for appropriate management of risk (Reference: http:⁄⁄www.isaca.org⁄cobit). Best practices defined in ISO 27002 are followed for defining the security controls within the Applicant’s Back-End Operator’s organization. The Applicant’s Back-End Operator continually looks to improve the efficiency and effectiveness of its processes, and follows industry best practices as defined by the IT Infrastructure Library, or ITIL (Reference: http:⁄⁄www.itil-officialsite.com⁄).

The The Service Provider registry system that will be used for the applied-for TLD is located within secure data centers that implement a multitude of security measures both to minimize any potential points of vulnerability and to limit any damage should there be a breach. The characteristics of these data centers are described fully in the Applicant’s response to Question #30(b).

The The Service Provider registry system that will be used for the applied-for TLD employs a number of multi-layered measures to prevent unauthorized access to its network and internal systems. Before reaching the registry network, all traffic will be required to pass through a firewall system. Packets passing to and from the Internet will be inspected, and unauthorized or unexpected attempts to connect to the registry servers will be both logged and denied. Management processes will be in place to ensure each request is tracked and documented, and regular firewall audits will be performed to ensure proper operation. 24x7 monitoring will be in place and, if potential malicious activity is detected, appropriate personnel will be notified immediately.

The Applicant, through its Back-End Operator employs a set of security procedures to ensure maximum security on each of its servers, including disabling all unnecessary services and processes and regular application of security-related patches to the operating system and critical system applications. Regular external vulnerability scans shall be performed to verify that only services intended to be available are accessible.

Regular detailed audits of the server configuration shall be performed to verify that the configurations comply with current best security practices. Passwords and other access means will be changed on a regular schedule and shall be revoked whenever a staff member’s employment is terminated.


Access to registry system
Access to all production systems and software shall be strictly limited to authorized operations staff members. Access to technical support and network operations teams where necessary shall be read only and limited only to components required to help troubleshoot customer issues and perform routine checks. Strict change control procedures shall be in place and shall be followed each time a change is required to the production hardware⁄application. User rights shall be kept to a minimum at all times. In the event of a staff member’s employment termination, all access will be removed immediately.

The Service Provider applications that will be used for the applied-for TLD use encrypted network communications. Access to the registry server shall be controlled. The Applicant and its Back-End Operator shall allow access to an authorized registrar only if each of the authentication factors matches the specific requirements of the requested authorization. These mechanisms shall also be used to secure any web-based tools that allow authorized registrars to access the registry. Additionally, all write transactions in the registry (whether conducted by authorized registrars or the registryʹs own personnel) shall be logged.

EPP connections shall be encrypted using TLS⁄SSL, and mutually authenticated using both certificate checks and login⁄password combinations. Web connections shall be encrypted using TLS⁄SSL for an encrypted tunnel to the browser, and authenticated to the EPP server using login⁄password combinations.

All systems shall be monitored for security breaches from within the data center and without, using both system-based and network-based testing tools. Operations staff shall also monitor systems for security-related performance anomalies. Triple-redundant continual monitoring must ensure multiple detection paths for any potential incident or problem. Details are provided in the Applicant’s responses to Questions #30(b) and #42. Network Operations and Security Operations teams shall perform regular audits in search of any potential vulnerability.

To ensure that registrar hosts configured erroneously or maliciously cannot deny service to other registrars, the Applicant, through its Back-End Operator, shall use traffic shaping technologies to prevent attacks from any single registrar account, IP address, or subnet. This additional layer of security must reduce the likelihood of performance degradation for all registrars, even in the case of a security compromise at a subset of registrars.

There will be a clear accountability policy that defines what behaviors are acceptable and unacceptable on the part of non-staff users, staff users, and management. Periodic audits of policies and procedures shall be performed to ensure that any weaknesses are discovered and addressed. Aggressive escalation procedures and well-defined Incident Response management procedures must ensure that decision makers are involved at early stages of any event.

In short, security is a consideration in every aspect of business at the Applicant and its Back-End Operator, and this is evidenced in the Back-End Operator’s track record of a decade of secure, stable and reliable service.


Independent assessment
Supporting operational excellence as an example of security practices, the Applicant’s Back-End Operator shall perform a number of internal and external security audits each year of the existing policies, procedures and practices for:
- Access control;
- Security policies;
- Production change control;
- Backups and restores;
- Batch monitoring;
- Intrusion detection, and
- Physical security.

The Applicant’s Back-End Operator has an annual Type 2 SSAE 16 audit performed by PricewaterhouseCoopers (PwC). Further, PwC performs testing of the general information technology controls in support of the financial statement audit. A Type 2 report opinion under SSAE 16 covers whether the controls were properly designed, were in place, and operating effectively during the audit period (calendar year). This SSAE 16 audit includes testing of internal controls relevant to The Service Providerʹ domain registry system and processes. The report includes testing of key controls related to the following control objectives:

- Controls provide reasonable assurance that registrar account balances and changes to the registrar account balances are authorized, complete, accurate and timely.
- Controls provide reasonable assurance that billable transactions are recorded in the Shared Registry System (SRS) in a complete, accurate and timely manner.
- Controls provide reasonable assurance that revenue is systemically calculated by the Deferred Revenue System (DRS) in a complete, accurate and timely manner.
- Controls provide reasonable assurance that the summary and detail reports, invoices, statements, registrar and registry billing data files, and ICANN transactional reports provided to registry operator(s) are complete, accurate and timely.
- Controls provide reasonable assurance that new applications and changes to existing applications are authorized, tested, approved, properly implemented and documented.
- Controls provide reasonable assurance that changes to existing system software and implementation of new system software are authorized, tested, approved, properly implemented and documented.
- Controls provide reasonable assurance that physical access to data centers is restricted to properly authorized individuals.
- Controls provide reasonable assurance that logical access to system resources is restricted to properly authorized individuals.
- Controls provide reasonable assurance that processing and backups are appropriately authorized and scheduled and that deviations from scheduled processing and backups are identified and resolved.

The last Type 2 report issued was for the year 2010, and it was unqualified, i.e., all systems were evaluated with no material problems found. The Applicant’s Back-End Operator shall continue to have similar audits performed in relation to the operation of the applied-for and other TLDs.

During each year, the Applicant’s Back-End Operator monitors the key controls related to the SSAE controls. Changes or additions to the control objectives or activities can result due to deployment of new services, software enhancements, infrastructure changes or process enhancements. These are noted and after internal review and approval, adjustments are made for the next review.

In addition to the PricewaterhouseCoopers engagement, the Applicant’s Back-End Operator performs internal security audits twice a year. These assessments are constantly being expanded based on risk assessments and changes in business or technology.
Additionally, the Applicant’s Back-End Operator engages a well-reputed independent third-party security organization, PivotPoint Security to perform external vulnerability assessments and penetration tests on the sites hosting and managing the Registry infrastructure. These assessments are performed with major infrastructure changes, release of new services or major software enhancements. These independent assessments are performed at least annually. A report from a recent assessment is attached with the response to Question #30(b).
The Applicant’s Back-End Operator has engaged with security companies specializing in application and web security testing to ensure the security of web-based applications, offered by The Service Provider, such as the Web Admin Tool (WAT) for registrars and registry operators.
Finally, the Applicant’s Back-End Operator has engaged IBM’s security services division to perform ISO 27002 gap assessment studies so as to review alignment of The Service Provider’ procedures and policies with the ISO 27002 standard. The Service Provider has since made adjustments based on the recommendations by IBM. The Applicant’s Back-End Operator shall continue to have similar tests proceedings for the operation of the applied-for and other TLDs.


Special TLD considerations
The rigorous security practices form the Applicant’s Back-End Operator are regularly reviewed; if there is a need to alter or augment procedures for the .WILMAR TLD, this will be done so in a planned and deliberate manner.


Commitments to Registrant Protection
With over a decade of experience protecting domain registration data, the Applicant’s Back-End Operator understands registrant security concerns. The Applicant, through its Back-End Operator will support a “thick” registry system in which data for all objects will be stored in the registry database that is the centralized authoritative source of information. As an active member of IETF (Internet Engineering Task Force), ICANN’s SSAC (Security & Stability Advisory Committee), APWG (Anti-Phishing Working Group), MAAWG (Messaging Anti-Abuse Working Group), USENIX, and ISACA (Information Systems Audits and Controls Association), the Applicant’s Back-End Operator’s team is highly attuned to the potential threats and leading tools and procedures for mitigating threats. As such, registrants should be confident that:
- Any confidential information stored within the registry will remain confidential;
- The interaction between their registrar and The Service Provider is secure;
- The The Service Provider DNS system will be reliable and accessible from any location;
- The registry system will abide by all polices, including those that address registrant data;
- The Service Provider will not introduce any features or implement technologies that compromise access to the registry system or that compromise registrant security.

The Applicant’s Back-End Operator has directly contributed to the development of the documents listed below and has implemented them where appropriate. All of these have helped improve registrants’ ability to protect their domains name(s) during the domain name lifecycle.
- [SAC049]: SSAC Report on DNS Zone Risk Assessment and Management (03 June 2011)
- [SAC044]: A Registrantʹs Guide to Protecting Domain Name Registration Accounts (05 November 2010)
- [SAC040]: Measures to Protect Domain Registration Services Against Exploitation or Misuse (19 August 2009)
- [SAC028]: SSAC Advisory on Registrar Impersonation Phishing Attacks (26 May 2008)
- [SAC024]: Report on Domain Name Front Running (February 2008)
- [SAC022]: Domain Name Front Running (SAC022, SAC024) (20 October 2007)
- [SAC011]: Problems caused by the non-renewal of a domain name associated with a DNS Name Server (7 July 2006)
- [SAC010]: Renewal Considerations for Domain Name Registrants (29 June 2006)
- [SAC007]: Domain Name Hijacking Report (SAC007) (12 July 2005)


To protect any unauthorized modification of registrant data, the Applicant’s Back-End Operator shall mandate TLS⁄SSL transport (per RFC 5246) and authentication methodologies for access to the registry applications. Authorized registrars will be required to supply a list of specific individuals (five to ten people) who are authorized to contact the registry. Each such individual will be assigned a pass phrase. Any support requests made by an authorized registrar to registry customer service shall be authenticated by registry customer service. All failed authentications shall be logged and reviewed regularly for potential malicious activity. This must prevent unauthorized changes or access to registrant data by individuals posing to be registrars or their authorized contacts.

These items reflect an understanding of the importance of balancing data privacy and access for registrants, both individually and as a collective, worldwide user base.

The The Service Provider 24⁄7 Customer Service Center that will be used for the applied-for TLD consists of highly trained staff who collectively are proficient in 15 languages, and who are capable of responding to queries from registrants whose domain name security has been compromised – for example, a victim of domain name hijacking. The Applicant’s Back-End Provider will provide specialized registrant assistance guides, including specific hand-holding and follow-through in these kinds of commonly occurring circumstances, which can be highly distressing to registrants

Security resourcing plans
Please refer to the Applicant’s response to Question #30b for security resourcing plans.



© Internet Corporation For Assigned Names and Numbers.