New gTLD Application Submitted to ICANN by: Webera Inc.

Application Downloaded On: 01 Jul 2014

String: app

Application ID: 1-1289-59445

Applicant Information

1. Full legal name
Webera Inc.

2. Address of the principal place of business
F/19, BC1, Ras Al Khaimah FTZ, P.O Box # 16113 Ras Al Khaimah - 16113 AE

3. Phone number
+14153580831

4. Fax number
+15126847732

5. If applicable, website or URL
http://www.radixregistry.com

Primary Contact

6(a). Name
Brijesh Joshi

6(b). Title
Director & GM

6(c). Address

6(d). Phone Number
+14153580831

6(e). Fax Number

6(f). Email Address
webera@radixregistry.com

Secondary Contact

7(a). Name
Namit Merchant

7(b). Title
General Manager

7(c). Address

7(d). Phone Number
+14152232608

7(e). Fax Number

7(f). Email Address
namit@radixregistry.com

Proof of Legal Establishment

8(a). Legal form of the Applicant
International Business Company

8(b). State the specific national or other jurisdiction that defines the type of entity identified in 8(a).
Jurisdiction: Republic of Seychelles, International Business Companies Act, 1994 (Act 24 of 1994)

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.

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
Name
Position
Brijesh JoshiDirector & General Manager
Vishal ManjalaniDirector & VP

11(b). Name(s) and position(s) of all officers and partners
Name
Position
Bhavin TurakhiaFounder
Brijesh JoshiDirector & General Manager
Namit MerchantGeneral Manager
Vishal ManjalaniDirector & VP

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

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.
app


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



14B. 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.



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



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



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



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



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



15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
  1. the applied-for gTLD string relevant to the tables,
  2. the script or language designator (as defined in BCP 47),
  3. table version number,
  4. effective date (DD Month YYYY), and
  5. contact name, email address, and phone number.
    Submission of IDN tables in a standards-based format is encouraged.



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



15C. List any variants 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.

The string ʺ.appʺ consists of three ASCII characters, each one of which currently occurs as part of existing and operational gTLD strings. We are not aware of any possible rendering problems concerning the string ʺ.appʺ.

 

We are aware of the issue of universal acceptability and accept that some incorrectly configured third-party software may consider ʺ.appʺ to be an invalid string, in the same way that other TLDs such as ʺ.INFOʺ and “.MUSEUMʺ are also at times considered ʺinvalid.ʺ The Registry will work to raise awareness of the issue of universal acceptance of .app and other new gTLDs. CentralNic has previously contributed to these efforts, such as by publication of TLD Verification code for the PHP programming language.

 

We are aware that a significant fraction of queries sent to the DNS root servers are for invalid TLDs such as ʺ.LOCALʺ or ʺ.LANʺ, and that the delegation of these TLDs could cause previously undiscovered configuration errors to result in operational problems for other operators. We have reviewed the research in this area, including the SAC 045 report from ICANNʹs Security and Stability Advisory Committee, data from the Day In The Life of the Internet project, and other sources, and are not aware of any significant volume of invalid root server queries related to .app. Therefore we feel confident that the delegation of this string will not result in any operation problems for Internet users.

 

 

 This completes our response to Q16



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



18A. Describe the mission/purpose of your proposed gTLD.

MISSION AND PURPOSE:

Apple says, ‘ There is an App for Everything’; that definitely seems to be the case.As the usage of smartphones and tablets increases, people depend on Apps for everything; right from instant messaging, shopping, entertainment, to even monitoring their diet plan.

The .App mission is to serve as a dedicated and globally identifiable namespace for all Web & Mobile applications’ websites.

With each passing day, there is an incremental growth in the number of applications being published. The App market is growing at a phenomenal pace. Two of the most popular App Stores – Apple & Android have 500,000+ Apps and they definitely don’t seem to be stopping at that. The number of Apps in the Apple App Store have grown 1000X in 4 years, from a mere 500 in 2008 to 500,000 in 2012 (^1). Android has seen a growth rate of 250% (2010-2011) (^2).

Currently, most App Developers are heavily dependent on app stores to distribute, promote and brand their applications. The scope of these activities is very restricted in the App Store as Developers have to work within the limitations⁄restrictions enforced by the App Stores.Applications need a dedicated and flexible platform – a location to build their brand, have detailed information about it (as compared to the restricted 1-2 paragraphs in the app store), roll out upgrades, network with their customers and do a lot more.

While some apps have websites to do this, most of them choose domain names within the gTLD space. Based on our experience, when a potential registrant goes to a registrar’s site to register a new gTLD domain name, the domain name is unavailable over 70% of the time (Source: Internal research on com⁄net availability checks) and the registrant is presented with long list of permutation options that are not their first choice – either for the name or the TLD. Thus, they end up choosing sub-standard domains instead of the ones they actually prefer.

A .App domain name will give application developers a greater choice and a larger pool of names to choose from and will give them the creative flexibility to do a lot more with their applications.A .App domain will not only add credibility but will also be very relevant to the category itself. (eg: Angrybirds.app would be more appropriate than AngryBirds.com as Angry Birds is not a company but an app). The .App registry will aim to create value and global presence such that an Application with a .app extension, will automatically be recognized as a serious and credible player, as opposed one with a generic extension.

It’s a TLD that clearly sets aside a URL for applications’ primary websites. It will also help end users locate the website with ease and will definitely add value to the existing App Market.

Apart from this, we also believe that a .App domain will be of great value to e-commerce businesses that are looking at building a mobile presence

The internet traffic coming from internet and tablets is increasing, this trend is seen in varying degrees across countries (^3 – page 9).The fastest-growing activities for mobile users in the US showed that consumers increasingly use their devices for retail and commerce. In December 2011, 28.5million mobile users accessed online retail content on theirmobile devices, up 87% compared to the previous year andshows no signs of slowing down(^3 – page 29). As a result, a lot of ecommerce brands are also looking at catching their customers on the move.

In the upcoming years, (^3 – page 30) smartphones are going to becoming the favourite companion for shoppers and brands need to have a mobile presence in order to keep up with their customers. An app is a perfect way for brands to engage their customers, inform them of their latest product ranges and enable easy and frequent shopping. That said, there isn’t a dedicated⁄singlelocation for these apps on the internet where the customer can find them. Our goal is also to make .app the defacto, quick and easy way in which customers can reach the app of any e-commerce company. If theyʹre looking for an app of a company our goal is to inculcate behavior wherein their first response is to reach ʹcompanyname.appʹ. .App will be the primary domain name for these apps and can be used for several other purposes like branding, marketing,support etc too.

Almost all businesses today have their online presence in the .com and .net namespaces. This has made the Internet a very crowded and uncategorized space. App aims to be the defacto TLD for applications online.

Furthermore, with almost the entire industry already having an online presence, this growing niche very well deserves its own namespace on the Internet.

In addition to the above, the mission⁄purpose of .App is:

* ENHANCE SEARCHABILITY AND RECOGNITION

To create a namespace that enables Applications⁄Application Developers to easily distinguish themselves from countless others in unrestricted gTLDs. This benefits the Registrants as well as the end users. End users will be able to find the website of an app they are looking for easily.

* CREATE A CLEANER INTERNET SPACE

To create a cleaner internet experience for end users by implementing pioneering registration policies, content and usage policies, and abuse mitigation processes.

* CREATE A STABLE AND RESILIENT INTERNET SPACE

To deliver a stable and resilient internet experience to registrants and end-users by meeting the ICANN mandated SLAs and delivering 100% resolution uptime

External References:

(^1) - http:⁄⁄gigaom.com⁄apple⁄infographic-apple-app-stores-march-to-500000-apps
(^2) - Refer Attachment ‘Q48a_Android_Market_Insights’ – page 7, figure 3
(^3) - Mobile-Future-in-Focus2012 - A Report by Comscore: http:⁄⁄resources.logicboxes.com⁄files⁄comScore_2012_Mobile_Future_in_Focus.pdf

This completes our reponse to Q18(a)



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

1. GOAL OF .APP

1.1 SPECIALTY

The goal of .App is to serve as a dedicated and globally identifiable namespace for all for Web & Mobile applications’ websites. .App will add credibility to an App and will automatically recognize it as a serious player as compared to it being on any other generic TLD.

1.2 SERVICE LEVELS

Our goal for .App in terms of service levels is to go above and beyond the ICANN SLAs. ICANN provides for its expected SLA in Specification 10 in the Registry Agreement in the Applicant guidebook.

We have engaged CENTRALNIC to deliver services for this TLD. CENTRALNIC provides registry services for a number of TLDs including the .LA and .PW ccTLDs.

Our contract with CENTRALNIC is attached to our response to Q46. This contract details the SLA we intend on achieving with this TLD. As can be seen in the contract we meet or exceed the ICANN required SLA on every parameter.

Our response to Q34 and Q35 provides details on CentralNic's DNS system. This system has operated at 100% service availability since 1996 and has been developed into a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNic’s DNS system includes nameservers in more than forty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.

It is our objective to provide 100% uptime, a resilient global DNS infrastructure, and very low latency in terms of DNS resolution for this TLD

1.3 REPUTATION

Reputation of our TLD is of paramount importance to us. The reputation of our TLD directly relates to how end-users on the internet perceive our Registrants. We will ensure the highest reputation of .Appby ensuring the following –
* Maintaining a high quality bar with respect to Registrants in the TLD
* Well defined Acceptable usage and content policies
* Well defined dispute resolution mechanisms
* Ensuring Whois accuracy to support abuse mitigation
* Well defined and implemented abuse mitigation processes
* Well definedand implemented rights protection mechanisms
* Exceptional service levels

To this effect we have created unprecedented Abuse mitigation policies and Rights protection mechanisms that go significantly above and beyond mandatory requirements and common practicedescribed in considerable detail in our response to Q28 and Q29. We also commit to extremely high service levels that go beyond the stipulated service levels in the applicant guidebook.

2. CONTRIBUTION OF.APPTO THE NAMESPACE

2.1 CONTRIBUTION IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION

Per ICANN’s Bylaws as amended June 24, 2011, ICANN’s core value number six is “Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest.”

* A key purpose of the .App Registry is differentiation, categorization and recognition for any entity that has developed an app. The string itself differentiates the niche that this TLD will cater to. Any entity with a .App extension will automatically be identified as a serious player and become easily accessible. By offering more and better choice of names, we aim to be the preferred choice gTLD for the primary website of Applications built across the world.

.App will also allow Applications’ websites to differentiate themselves from the 200+ million domain names out there. As of now a domain for an application appears identical to any other domain name in a .gTLD (com) or .ccTLD extension (eg .in). .App provides the ability for Registrants to create a differentiated identity wherein just by looking at the URL end-users will be able to recognize and identify the category of the domain name.

.Appwill provide registrants the option to register more desirable and shorter names as opposed to names they would have otherwise registered in existing gTLDs due to the high saturation of the existing namespaces.

* Our intent is to operate .Appwith a focus on integrity and quality for the .Appbrand. This entails running robust abuse mitigation programs and pioneering Rights Protection Mechanisms from initiation, which in our case not only meets ICANN’s requirements, but extends significantly beyond it as described in our response to Q28 and Q29.

3. USER EXPERIENCE GOALS

.Appconsiders both its Registrants and the end-users that access .App websites as its users. Our goal is to create a highly reliable namespace and provide an outstanding user experience to both Registrants and end-users of .App.

Registrants of .App have an assurance of a scalable, resilient registry with 100% uptime, low latency, and exemplary security standards. Registrants will have the option to register the domain name of their choice, without much saturation of the namespace. Our registration policiesand abuse mitigation policies ensure that Registrants will get advantages like higher recognition, better branding and more desirable, shorter names.

Our content and acceptable use policies and abuse mitigation processes ensure that end-users are benefited from a clean namespace. These are described in further detail in our response to Q28 and Q29.

4.REGISTRATION POLICIES IN SUPPORT OF GOALS

4.1 GENERAL NAMES

The goals of .App are outlined in the sections above. These goals are supported by the following artifacts –
* Registration policies and processes
* Acceptable usage policies and content guidelines
* Abuse mitigation processes
* Rights protection mechanisms
* Dispute resolution polices

To this effect we have created unprecedented Abuse mitigation policies and Rights protection mechanisms that go significantly above and beyond mandatory requirements and common practice. The salient aspects of all of the above are described below -
* Webera Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (ResellerClub.com and BigRock.com) and Web Hosting companies. With over four million active domain names registered through its registrars, Directi has significant experience (over 10 years) of managing domain name abuse mitigation and rights protection. Directi has been heralded as a white hat registrar and the undisputed leader with respect to abuse mitigation.
* Our Abuse and compliance processes will be run by the Directi Group
* We have an elaborate and detailed Accepted usage and content policy that covers over 11 macro forms of violations
* .App will create a zero-tolerance reputation when it comes to abuse
* We have a defined SLA for responding to abuse complaints ensuring guaranteed turn-around time on any abuse complaint depending on its severity
* We will work closely with LEA and other security groups to mitigate abuse within TLD by providing them with special interfaces and interacting with them regularly in terms of knowledge sharing.
* Other abuse mitigation steps we undertake include profiling, blacklisting, proactive quality reviews, industry collaboration and information sharing, regular sampling, contractual enforcements and sanctions
* The protection of trademark rights is a core goal of .App. .App will have a professional plan for rights protection. It will incorporate best practices of existing TLDs, going above and beyond the ICANN mandated RPMs to prevent abusive registrations and rapidly take-down abuse when it does occur.
* Standard RPMs such as Sunrise, Trademarks claims service, URS, UDRP, SDRP, PDDRP, SPOC etc are all provided for. Additional RPMs such as profiling and blacklisting, proactive quality reviews, APWG Review and others will also be provided.

The above salient points barely scratch the surface in detailing the steps that .App will take in order to build a reputation of operating a clean, secure and trusted namespace. Significant details of all of the above and more are provided in our responses to Q26, Q27, Q28 and Q29

4.2. OTHER NAMES

* We will reserve the following classes of domain names,which will not be available to registrants via the Sunrise or subsequent periods:
** The reserved names required in Specification 5 of the new gTLD Registry Agreement.
** The geographic names required in Specification 5 of the new gTLD Registry Agreement, and as per our response to Question 21.See our response to Question 22 (“Protection of Geographic Names”) for details.
** The registry operator will reserve its own name and variations thereof, and registry operations names (such as nic.App, registry.App, and www.App), so that we can point them to our Web site.Reservation of the registry operator’s names was standard in ICANN’s past gTLD contracts.
** We will also reserve names related to ICANN and Internet standards bodies (iana.App, ietf.App, w3c.App, etc.), for delegation of those names to the relevant organizations upon their request.Reservation of this type of names was standard in ICANN’s past gTLD contracts.The list of reserved names will be published publicly before the Sunrise period begins, so that registrars and potential registrants will know which names have been set aside.
* We will reserve generic names which will be set aside for distribution via special mechanisms.

5. PROTECTING PRIVACY OF REGISTRANTS’ OR USERS’ INFORMATION

.App is committed to providing a secure and trusted namespace to its Registrants and end-users. To that extent we will have several measures for protecting the privacy or confidential information of registrants or users -

* Our Whois service (web-based whois, port 43 whois) all have built in abuse prevention mechanisms to prevent unauthorized access, data mining, data scraping and any other abusive behavior. Details of this are provided in our response to Q26

* .App will allow Registrants to use privacy protection services provided by their Registrars in the form of a Proxy whois service as long as they follow the guidelines stipulated within our response to Q28 to prevent any abuse of the same

* As per the requirements of the new gTLD Registry Agreement (Article 2.17), we shall notify each of our registrars regarding the purposes for which data about any identified or identifiable natural person (“Personal Data”) submitted to the Registry Operator by such registrar is collected and used, and the intended recipients (or categories of recipients) of such Personal Data.(This data is basically the registrant and contact data required to be published in the WHOIS.)

* We will also require each registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data.As the registry operator, we shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars.

* As the registry operator we shall take significant steps to protect Personal Data collected from registrars from loss, misuse, unauthorized disclosure, alteration, or destruction.In our responses to Q24, Q30 and Q38 we detail the security policies and procedures we will use to protect the registry system and the data contained there from unauthorized access and loss.

* As registry operator we impose certain operational standards for our registrars.In order gain and maintain accreditation for our TLD, we require them to adhere to certain information technology policies designed to help protect registrant data.These include standards for access to the registry system.Please see our response to Q24, Q25 and Q30 for details.

* We offer a “registry lock” service, designed to help protect participating registrants’ contact data from unauthorized modification, and against unauthorized domain transfers and deletions.Please see our response to Q27 for details.

* .App implements DNSSEC at the zone which guarantees origin authentication of DNS data, authenticated denial of existence, and data integrity. This protects end-users from a man-in-the-middle attack protecting the privacy of data of end-users.

6. OUTREACH AND COMMUNICATIONS

* Our goal for .App is for it to be the first-choice TLD for the primary website of Applications.

* To achieve this, we will emphasize distribution channels internationally.

* We will also look to spread awareness virally through PR and Social Media. We will evangelize it as a defacto TLD for Applications built across the world.

* Our outreach efforts will thus be directed towards our target market in coordination with Registrar partners, to ensure greater adoption of the .App TLD. One important method of outreach will involve co-marketing programs with registrars. We will also leverage Directi’s existing channel of 65,000 Resellers, and its strategic relationships with other ICANN Accredited Registrars.

The communication and outreach will focus on -
* Education amongst the Application Developers
* Generating awareness of our Registration policies, Acceptable usage and content policies, Abuse mitigation processes and Rights protection mechanisms

This completes our response to Q18(b)




18C. What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences/costs imposed upon consumers?

.App considers both its Registrants and the end-users that access .App websites as its users. Our goal is to create a highly reliable namespace and provide an outstanding user experience to both Registrants and end-users of .App. To that extent it is our goal to –

* Reduce ⁄ minimize any incremental costs ⁄ negative consequences imposed upon our users
* Increase ⁄ maximize the value added to our Registrants and end-users
* Ensure that the net effect of .App on its users is that of positive value creation

In this response we explore how .App achieves a net benefit for Registrants and End-users.

1 MINIMIZING COSTS

1.1 REGISTRANTS

It is our goal to provide Registrants of .App incremental value and minimize any negative consequences and costs associated with .App. We address this in the following manner

1.1.1 SUNRISE, TMCH, RPMs

Rights protection is a core goal of .App. Our Right Protection mechanisms go significantly above and beyond the mandatory RPMs ensuring protection of trademark and IP rights of domain registrants and reducing the costs associated with rights protection for Registrants. Our elaborate RPMs are described in significant detail in our response to Q29. Some salient aspects of these are as follows -

* We offer a sunrise period to provide an opportunity for legitimate Registrants to block domain names in .App before general availability begins, preventing unnecessary post-facto litigation

* We will integrate with the Trademark Clearing House in the manner prescribed to provide the Trademarks claims service, so as to alert potential Registrants of any trademark violations prior to registration, as well as notify mark holders of potential mark violations

* We will provide SDRP, URS, UDRP and PDDRP reducing litigation costs by providing legitimate Registrants the opportunity to resolve disputes through standardized arbitration proceedings.

* Additionally we have pioneering RPMs like Profiling and Blacklisting, Proactive Quality assurance, APWG review etc – all intended to reduce rights violations and hence reduce costs for Registrants

The above salient points barely scratch the surface in detailing the steps that .Appwill take in order to reduce costs of Registrants with respect to rights violations. Significant details of all of the above and more are provided in our responses to Q26, Q27, Q28 and Q29.

1.1.2 MULTIPLE APPLICATIONS FOR A DOMAIN

All of the RPMs described in section 1.1.1 above ensure that applicants for domain names in .App are legitimate right holders for the applied string.

During general availability domain names will be allocated on a first come first serve basis amongst applicants. During the initial registry launch periods of Sunrise and Landrush if multiple applications for the same domain name are received from applicants then the same will be distributed in the following manner –

* Incase of multiple sunrise applications for the same domain name, all applications will be validated against the TMCH for a valid trademark. Applications that do not qualify will be dropped.

* All remaining applications will be distributed through a fair auction.

1.1.3 COST BENEFITS FOR REGISTRANTS

The ICANN new gTLD program marks a historical event in the timeline of the Internet. It is an unprecedented event and one that will yield tremendous benefits for consumers. At this preliminary stage it is impossible to determine the true value consumers will derive from increase in competition and choice. However there is historical data to go by. Upon the launch of Domain Registrars and creation of competition amongst registrars, the Registrants benefited from reduced pricing.

With .App our goal is to provide fair pricing for domains within .App that reflect the value proposition derived by the Registrants of .App. While we do not have any committed pricing plans as yet and the same will be determined during the launch process, we do anticipate providing promotional offers through the life of .App for the purpose of customer acquisition. This is not too dissimilar from other gTLD registries currently in existence who offer ongoing promotional offers to their customer base.

1.1.4 PRICE ESCALATIONS

The ICANN new gTLD program is an unprecedented event and the actual nature of pricing pressures will only be determinable once several TLDs have successfully launched. At this preliminary stage it is impossible to commit to any pricing strategy on our part. We strongly believe that ultimately, the open market will determine the viability of pricing models and dictate pricing strategy for everyone. We intend to maintain the freedom to set pricing to accommodate for the existence of 100s of TLDs and business models and create a sustainable long term business model. Our goal is to provide fair pricing for domains within .App that reflect the value proposition derived by the Registrants of .App.

1.2 END USERS

It is our goal to provide end users of .App incremental value and minimize any negative consequences and costs associated with .App. We address this in the following manner

End-users bear a considerable amount of cost as a result of various forms of Internet abuse such as spam, malware, phishing, pharming, hacking, identity theft etc. Any TLD that implements policies and processes to create a clean namespace will result in a considerable reduction of these forms of abuse and hence a significant saving in terms of cost to consumers

.App intends to set an example when it comes to abuse mitigation and preventing abuse within .App. To this effect we have created unprecedented Abuse mitigation policies and Rights protection mechanisms that go significantly above and beyond mandatory requirements and common practice. These are detailed in our response to Q28. We strongly believe these practices will result in a significant reduction in online abuse and considerable savings for end users of .App. We similarly hope to set an example for other TLDs and cooperate with the industry in creating a clean internet experience for internet users.

2 COST BENEFIT ANALYSIS

There has been considerable debate within the community concerning the cost benefit analysis of launching new gTLDs. We strongly believe that the launch of new gTLDs and our implementation of .App will and add considerable value and result in a net positive effect on Registrants and end-users worldwide.

We recognize that there will be a postlaunchreview of the NewgTLDProgram,from the perspective of assessing therelative costs and benefits achieved in theexpanded gTLD space.

To this extent we would like to offer the following pointers concerning .Appas well as the general expansion of the new gTLD space in determining the net positive value generated for Registrants and end users –

* .App will reduce overall cost for end-users in combating fraud and other forms of online abuse by implementing pioneering processes and anti-abuse policies as described in our response to Q28. Billions of dollars are spent worldwide combating various forms of fraud such as malware, phishing, spamming etc. Our abuse policies will result in overall reduction of these forms of abuses within .App resulting in a considerable reduction in global costs spent towards combating these abuses. We also strongly believe that introduction of new gTLDs will result in increased competition which will drive significant innovation as well as competitive pressures for everyone in the industry to improve their abuse mitigation processes resulting in overall cost reduction for end-users

* The value of a Registrant getting the name they want is immeasurably larger than any costs resulting from expansion of the namespace. Webera Inc. is a subsidiary within the Directi Group which owns and operates several ICANN Accredited Registrars. Our stats show that 70% of the users who check for a .com domain name do not get their desired name. Until this launch of the new gTLD program there were very limited alternatives and none very viable⁄desirable for Registrants to choose from. .App will expand the namespace thus providing a higher probability for new Registrants to obtain names they desire

* In general increased competition always results in pricing benefits for Registrants. .App will provide additional options to new Registrants resulting in overall benefits to Registrants

* By virtue of registering a domain name within .App, the URL categorizes itself as a location where marketing, support and information about a specific applicationcan be found. This adds considerable value in terms of searchability, SEO, creating trust and branding. As of now the only mechanism that exists for users to find a specific website are search engines. Search engines however do not classify the results in any manner to make it easier for users to determine which links are relevant to them with respect to their current search. .Appenables Registrants to standout amongst search results and allows end users to directly co-relate as to whether a search result will likely be what they are looking for. This adds considerable value to Registrants who can be easily found now, and to end-users who will take lesser time to find specific sites.

This completes our response to Q18(c)




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

No


20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.



20B. Explain the applicant’s relationship to the community identified in 20(a).



20C. Provide a description of the community-based purpose of the applied-for gTLD.



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



20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.



20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.



21A. Is the application for a geographic name?

No


22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.

We have engaged CENTRALNIC to deliver services for this TLD. This response describes protection of geographic names as implemented by CENTRALNIC.

1. PROTECTION OF GEOGRAPHIC NAMES

In accordance with Specification 5 of the New gTLD Registry Agreement, we will initially reserve all geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations.

CENTRALNIC supports this requirement by using the following internationally recognised lists to develop a comprehensive master list of all geographic names that are initially reserved:

– The 2-letter alpha-2 code of all country and territory names contained on the ISO 3166-1 list, including all reserved and unassigned codes [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm].

– The short form (in English) of all country and territory names contained on the ISO 3166-1 list, including the European Union, which is exceptionally reserved on the ISO 3166-1 List, and its scope extended in August 1999 to any application needing to represent the name European Union [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU].

– The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardisation of Geographical Names, Part III Names of Countries of the World. This lists the names of 193 independent States generally recognised by the international community in the language or languages used in an official capacity within each country and is current as of August 2006[http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn⁄docs⁄pubs⁄UNGEGN%20tech%20ref%20manual_m87_combined.pdf].

– The list of UN member states in six official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardisation of Geographical Names [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄docs⁄9th-uncsgn-docs⁄econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf].

Names on this reserved list in CENTRALNIC’s registry system are prevented from registration.

A corresponding list of geographic names will also be available to the public via our website, to inform Registrars and potential registrants of reserved names. The lists noted above, are regularly monitored for revisions, therefore the reserved list (both within the registry and publicly facing) will be continually updated to reflect any changes.

In addition to these requirements, CENTRALNIC are able to support the wishes of the Governmental Advisory Council (GAC) or any individual Government in regard to the blocking of individual terms on a case by case basis. CENTRALNIC’s registry system allows such additions to be made by appropriately authorised staff, with no further system development changes required.

The following applies to all Domain Names contained within the registry’s reserved list:

– Attempts to register listed Domain Names will be rejected.
– WhoIs queries for listed Domain Names will receive responses indicating their reserved status.
– Reserved geographic names will not appear in the TLD zone file.
– DNS queries for reserved domain names will result in an NXDOMAIN response.

2. PROCEDURES FOR RELEASE

We understand that if we wish to release the reserved names at a later date, this will require agreement from the relevant government(s) or review by the GAC, and subsequent approval from ICANN.

This completes our response to Q22.



23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
  1. Receipt of data from registrars concerning registration of domain names and name servers.
  2. Dissemination of TLD zone files.
  3. Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
  4. Internationalized Domain Names, where offered.
  5. DNS Security Extensions (DNSSEC). The applicant must describe whether any of
    these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.

Webera Inc. has chosen CentralNic as the registry infrastructure provider for the TLD. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed TLD registry (answers to questions 23 – 44) therefore refers to CentralNic’s registry infrastructure systems.

Webera Inc. and CentralNic hereby explicitly confirm that all registry services stated below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described above, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for the TLD;(iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement.

There are no other products or services, except those described above that the Registry Operator will provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of Webera Inc.being designated as the Registry Operator.

Any changes to the registry services that may be required at a later time in the course of Webera Inc.operating the registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.

Webera Inc.proposes to operate the following registry services, utilizing CentralNic's registry system:


23.1. Receipt of Data From Registrars

CentralNic will operate a Shared Registry System (SRS) for the TLD. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web based Registrar Console. Registrars will uses these interfaces to provide registration data to the registry.

The SRS will be hosted at CentralNic's primary operations centre in London, UK. The primary operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. The primary operations centre is hosted in Level 3's flagship European data centre and boasts significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.

CentralNic's existing SRS system currently supports more than 250,000 domain names managed by over 1,500 registrars. CentralNic has effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of the TLD and provide additional capacity during periods of elevated activity (such as during Sunrise periods).

The SRS and EPP systems are described more fully in Q24 and Q25. The Registrar Console is described in Q31.

EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:

1. Registry Grace Period Mapping - compliant with RFC 3915(http://tools.ietf.org/html/rfc3915)
2. DNSSEC Security Extensions - compliant with RFC 5910 (http://tools.ietf.org/html/rfc5910)
3. Launch Phase Extension - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft
https://github.com/wil/EPP-Launch-Phase-Extension-Specification/blob/master/draft-tan-epp-launchphase.txt

More information on EPP extensions is provided in Q25.

The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:

*Uniform Domain Name Dispute Resolution Policy

*Inter-Registrar Transfer Policy

*Whois Marketing Restriction Policy

*Restored Names Accuracy Policy

*Expired Domain Deletion Policy

*AGP Limits Policy


23.2. Provision to Registrars of Status Information Relating to the Zone Servers

CentralNic will operate a communications channel to notify registrars of all operational issues and activity relating to the DNS servers which are authoritative for the TLD. This includes notifications relating to:

1. Planned and unplanned maintenance;

2. Denial-of-service attacks;

3. unplanned network outages;

4. delays in publication of DNS zone updates;

5. security incidents such as attempted or successful breaches of access controls;

6. significant changes in DNS server behaviour or features;

7. DNSSEC key rollovers.

Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.


23.3. Dissemination of TLD Zone Files

CentralNic will make TLD zone files available via the Centralized Zone Data Access Provider according to specification 4, section 2 of the Registry Agreement.

Webera Inc.will enter into an agreement with any Internet user that will allow such user to access an Internet host server or servers designated by Webera Inc.and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider (the “CZDA Provider”). Webera Inc. will provide access to zone file data using the file format described in Section 2.1.4 of Specification 4 of the New gTLD Registry Agreement.

Webera Inc., through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address, and the Internet host machine name and IP address.

Webera Inc. will provide the Zone File FTP (or other Registry supported) service for an ICANN-specified and managed URL for the user to access the Registry’s zone data archives. Webera Inc. will grant the user a non-exclusive, non-transferable, limited right to access Webera Inc.’s Zone File FTP server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using FTP, or other data transport and access protocols that may be prescribed by ICANN.

Webera Inc. will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035(http://tools.ietf.org/html/rfc1035), Section 5, including all the records present in the actual zone used in the public DNS.

Webera Inc., through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Webera Inc. will allow users to renew their Grant of Access.

Webera Inc. will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.


23.4. Operation of the Registry Zone Servers

The TLD zone will be served from CentralNic's authoritative DNS system. This system has operated at 100% service availability since 1996 and has been developed into a secure and stable platform for domain resolution. Partnering with Community DNS, CentralNic's DNS system includes nameservers in more than forty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.

The DNS system is described further in Q35.


23.5. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations

CentralNic will operate a Whois service for the TLD. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912 (http://tools.ietf.org/html/rfc3912). The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for domain names. The Whois service will return records in a standardised format which complies with ICANN specifications.

CentralNic will provide access to the Whois service at no cost to the general public.

CentralNic's Whois service supports a number of features, including rate limiting to prevent abuse and privacy protections for natural persons. The Whois service is more fully described in Q26.

Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, CentralNic will implement such alternative specifications as soon as reasonably practicable.


23.6. DNSSEC

The TLD zone will be signed by DNSSEC. CentralNic uses the award-winning signer technology from Xelerance Corporation. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in Q43.

CentralNic's DNSSEC implementation complies with RFCs 4033, 4034, 4035, 4509 and follows the best practices described in RFC 4641(http://tools.ietf.org/html/rfc4641). Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155(http://tools.ietf.org/html/rfc5155). The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910(http://tools.ietf.org/html/rfc5910)). CentralNic will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. CentralNic will publish its DPS following the format described in the “DPS-framework” Internet Draft within 180 days after that draft becomes an RFC.


23.7. Rights Protection Mechanisms

Webera Inc. will provide all mandatory Rights Protection Mechanisms that are specified in Webera Inc. Guidebook (version 11 January 2012), namely Trademark Claims Service (section 6.1) and Sunrise service (section 6.2). All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in the TLD. More information is available in Q29.

In addition to such RPMs, Webera Inc. may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Webera Inc. will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in the TLD. Webera Inc. shall implement these mechanisms in accordance with requirements established by ICANN each of the mandatory RPMs set forth in the Trademark Clearinghouse.

The "LaunchPhase" EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for the TLD. Depending on the final specification for the Trademark Claims Service (details of which have not yet been published), an additional EPP extension may be required in order to implement this service. If this is necessary, the extension will be designed to minimise its effect on the operation of the SRS and the requirements on registrars, and will only be in place for a limited period while the Trademark Claims Service is in effect for the TLD.


23.8. Registrar Support and Account Management

CentralNic will leverage its 16 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for the TLD registrars. CentralNic's experienced technical and customer support personnel will assist the TLD registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone and a web based support ticketing system.


23.9. Reporting to ICANN

Webera Inc. and CentralNic will compile and transmit a monthly report to ICANN relating to the TLD. This report will comply with Specification 3 of the New gTLD Registry Agreement.


23.10. Personnel Resources of CentralNic

The technical, operations and support functions of the registry will performed in-house by CentralNic's personnel. These personnel perform these functions on a full-time basis.


23.10.1. Technical Operations

Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. Internal helpdesk and incident reporting is also performed by the Technical Operations team. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are co-ordinated.

CentralNic intends to maintain a Technical Operations team consisting of the following positions. These persons will be responsible for managing, developing and monitoring the registry system for the TLD on a 24x7 basis:

*Senior Operations Engineer(s)

*Operations Engineer(s)

*Security Engineer


23.10.2. Technical Development

The Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, Zone file generation, data escrow, reporting, backoffice and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team.

CentralNic intends to maintain a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software which will support the TLD:

*Senior Technical Developer x 2

*Technical Developer x 3


23.10.3. Technical Support

Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.

1st line support issues are normally dealt with by these personnel. 2bd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.

The Technical Support team will consist of the following positions:

*Operations Manager

*Support Manager

*Support Agent(s)

Our overseas account managers also perform basic support functions, escalating to the support agents in London where necessary.


23.10.4. Key Personnel


23.10.4.1. Gavin Brown - Chief Technology Officer

Gavin has worked at CentralNic since 2001, becoming CTO in 2005. He has overall responsibility for all aspects of the SRS, Whois, DNS and DNSSEC systems. He is a respected figure in the domain industry and has been published in several professional technical journals, and co-authored a book on the Perl programming language. He also participates in a number of technical, public policy and advocacy groups and several open source projects. Gavin has a BSc (hons) in Physics from the University of Kent.


23.10.4.2. Jenny White - Operations Manager

Jenny has been with CentralNic for nine years. Throughout this time she has expertly managed customer relations with external partners, prepared new domain launch processes and documentation, managed daily support and maintenance for over 1,500 Registrars, carried out extensive troubleshooting within the registrar environment to ensure optimum usability for registrars across communication platforms, handled domain disputes (from mediation to WIPO filing), and liaised with WIPO to implement changes to the Dispute Resolution Procedure when necessary.


23.10.4.3. Adam Armstrong - Senior Operations Engineer

Adam has recently joined CentralNic as Senior Operations Engineer. In this role he is responsible for the operation and development of the system and network infrastructure for the registry system. Adam has previously worked at a number of large UK ISPs including Jersey Telecom and Packet Exchange. He is also the lead developer of Observium, a network management system used by ICANN (amongst others). Adam has brought his strong knowledge of network design, management and security to bear at CentralNic and will oversee the operation of the SRS for the TLD.


23.10.4.4. Milos Negovanovic - Senior Technical Developer

Milos has worked at CentralNic since 2009. He has a background in building rich web applications and protocol servers. His main areas of responsibility are the Registrar Console, EPP and backoffice functions.


23.10.4.5. Mary O'Flaherty - Senior Technical Developer

Mary has worked at CentralNic since 2008. She plays an integral role in the ongoing design, development and maintenance of the registry as a whole and has specific experience with the EPP system, Registrar Console and Staff Console. Mary has a 1st class Honors degree in Computer Science from University College Cork and has previously worked for Intel and QAD Ireland.


23.10.5. Job Descriptions

CentralNic will recruit a number of new employees to perform technical duties in relation to the TLD and other gTLDs. The following job descriptions will be used to define these roles and select candidates with suitable skills and experience.


23.10.5.1. Operations Engineer

Operations Engineers assist in the maintenance and development of the network and server infrastructure of the registry system. Operations Engineers have a good knowledge of the TCP/IP protocol stack and related technologies, and are familiar with best practice in the areas of network design and management and system administration. They should be competent system administrators with a good knowledge of Unix system administration, and some knowledge of shell scripting, software development and databases. Operations Engineers have 1-2 year's relevant commercial experience. Operations Engineers report to and work with the Senior Operations Engineer, who provides advice and mentoring. Operations Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.


23.10.5.2. Security Engineer

Security Engineers enhance and assure the security of the registry system. Day-to-day responsibilities are: responding to security incidents, performing analysis and remediating vulnerabilities, conducting tests of access controls, refining system configuration to improve security, training other team members, reviewing source code, maintaining security policies and procedures, and gathering intelligence relating to threats to the registry. Security Engineers have 1-2 year's relevant commercial experience. This role reports to and works with the Senior Operations Engineer and CTO. Security Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.


23.10.5.3. Technical Developer

Technical Developers are maintain the software which supports the registry. Day-to-day responsibilities are developing new systems in response to requests from management and customers, correcting bugs in existing software, and improving its performance. Technical Developers have a good knowledge of general programming practices including use of revision control and code review systems. Developers have a good awareness of security issues, such as those described in advisories published by the oWASP Project. Developers have at least one years' commercial experience in developing applications in programming languages such as PHP, Perl, and Python, although knowledge of domain technologies such as EPP and DNS is not critical. Technical Developers work as part of a team, with advice and mentoring from the Senior Technical Developers, to whom they report.


23.10.6. Resource Matrix

To provide a means to accurately and objectively predict human resource requirements for the operation of the registry system, CentralNic has developed a Resourcing Matrix, which assigns a proportion of each employee's available time to each aspect of registry activities. These activities include technical work such as operations and development, as well as technical support, registrar account management, rights protection, abuse prevention, and financial activity such as payroll, cash collection, etc. This matrix then permits the calculation of the total HR resource assigned to each area.

A copy of the Resourcing Matrix is included as Appendix 23.2. It is important to note that the available resources cover the operation of CentralNic's entire registry operations: this includes CentralNic's own domain registry portfolio (uk.com, us.com, etc), the .LA and .PW ccTLDs, as well as the gTLDs which CentralNic will provides registry service for.

The actual proportion of human technical resources required specifically for the TLD is determined by the relative size of the TLD to the rest of CentralNic's operations. This calculation is based on the projected number of domains after three years of operation: the optimistic scenario is used to ensure that sufficient personnel is on hand to meet periods of enhanced demand. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names.

Since the optimistic projection for the number of domains registered in the TLD after three years is 60,000, the TLD will therefore require 1.33% ofCentralNic's total available HR resources in order operate fully and correctly. In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

 


This completes our response to Q23.


24. Shared Registration System (SRS) Performance:
describe

Except where specified, this answer refers to the operations of Webera Inc.'s outsource Registry Service Provider, CentralNic.

24.1. Registry Type

CentralNic operates a "thick" registry in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See Q25 for further details.


24.2. Architecture

Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in Q32.

The SRS is hosted at CentralNic's primary operations centre in London. It is connected to the public Internet via two upstream connections, one of which is provided by Qube. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via two BGP routers which connect to the firewalls which implement access controls over registry services.

Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit ethernet switches implementing Spanning Tree Protocol.

The registry system implements two interfaces to the SRS: the standard EPP system (described in Q25) and the Registrar Console (described in Q31). These systems interact with the primary registry database (described in Q33). The database is the central repository of all registry data. Other registry services also interact with this database.

An internal "Staff Console" is used by CentralNic personnel to perform management of the registry system.


24.3. EPP System Architecture

A description of the characteristics of the EPP system is provided in Q25. This response describes the infrastructure which supports the EPP system.

A network diagram for the EPP system is provided in Figure 24.2. The EPP system is hosted at the primary operations centre in London. During failover conditions, the EPP system operates from the Isle of Man Disaster Recovery site (see Q34).

CentralNic’s EPP system has a two-layer logical and physical architecture, consisting of load balancers and a cluster of application servers. Each layer can be scaled horizontally in order to meet demand.

Registrars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.

The load balancers pass sessions to the EPP application servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp module. These servers implement the EPP state diagram and handle registrar commands using application code.

Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.

The EPP system will comprise of the following systems:

*3x load balancers (1U rack mount servers with quad-core Intel processors, 16GB RAM, 40GB solid-state disk drives, running the CentOS operating system using the Linux Virtual Server [see http://www.linuxvirtualserver.org/])

*12x EPP protocol servers (1U rack mount servers with dual-core Intel processors, 16GB RAM, solid-state disk drives, running the CentOS operating system using Apache and mod_epp)


24.3.1. mod_epp

mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found at http://sourceforge.net/projects/aepps. CentralNic uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into HTTP requests which can then be handled by backend application code.


24.4. Performance

CentralNic performs continuous remote monitoring of its EPP system, and this monitoring includes measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of the EPP system were as follows:

*connect time: 40ms

*login time: 20ms

*hello time: 7ms

*check time: 15ms

*logout time: 6ms

These figures include an approximate latency of 3.2ms due to the distance between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.


24.5. Scaling

Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.

Vertical scaling leverages Moore's Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.

For further information about Capacity Management and Scaling, please see Q32.


24.6. Registrar Console

The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. It is hosted on a virtual platform at the primary operations centre in London. As with the rest of the registry system, during a failover condition it is operated from the Isle of Man. The virtual platform is described in Figure 24.3.

The features of the Registrar Console are described in Q31.

The virtual platform is a utility platform which supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on "bare metal" would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.

The Registrar Console currently sustains an average of 6 page requests per minute during normal operations, with peak volumes of around 8 requests per minute. Volumes during weekends are significantly lower (fewer than 1 requests per minute). Additional load resulting from this and other new gTLDs is expected to result in a trivial increase in Registrar Console request volumes, and CentralNic does not expect additional hardware resources to be required to support it.


24.7. Quality Assurance

CentralNic employs the following quality assurance (QA) methods:

1. 24x7x365 monitoring provides reports of incidents to NOC

2. Quarterly review of capacity, performance and reliability

3. Monthly reviews of uptime, latency and bandwidth consumption

4. Hardware depreciation schedules

5. Unit testing framework

6. Frequent reviews by QA working group

7. Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis

8. Revision control software with online annotation and change logs

9. Bug Tracking system to which all employees have access

10. Code Review Policy in place to enforce peer review of all changes to core code prior to deployment

11. Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team

12. Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment

13. Evidence-based project scheduling

14. Specification development and revision

15. Weekly milestones for developers

16. Gantt charts and critical path analysis for project planning

Registry system updates are performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.


24.8. Billing

CentralNic operates a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. The foundation of the process is debit accounts established for each registrar. CentralNic will withdraw all domain fees from the registrar’s account on a per-transaction basis. CentralNic will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar’s account shows a positive balance.

Once ICANN notifies Webera Inc. that a registrar has been issued accreditation, CentralNic will begin the registrar on-boarding process, including setting up the registrar's financial account within the SRS.


24.9. Registrar Support

CentralNic provides a multi-tier support system on a 24x7 basis with the following support levels:

*1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.

*2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.

*3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.

CentralNic provides a support ticketing system for tracking routine support issues. This is a web based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from CentralNic support personnel.

When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used: n

1. Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.

2. Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.

3. Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.

4. Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.

Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.


24.10. Enforcement of Eligibility Requirements

The SRS supports enforcement of eligibility requirements, as required by specific TLD policies.

Figure 24.4 describes the process by which registration requests are validated. Prior to registration, the registrant's eligibility is validated by a Validation Agent. The registrant then instructs their registrar to register the domain. The SRS returns an "Object Pending" result code (1001) to the registrar.

The request is sent to the Validation Agent by the registry. The Validation Agent either approves or rejects the request, having reconciled the registration information with that recorded during the eligibility validation. If the request has been approved, the domain is fully registered. If it is rejected, the domain is immediately removed from the database. A message is sent to the registrar via the EPP message queue in either case. The registrar then notifies the registrant of the result.


24.11. Interconnectivity With Other Registry Systems

The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by the database which is the single authoritative source of data for the registry as a whole. Individuals modules perform "CRUD" (create, read, update, delete) actions upon the database. These actions then affect the behaviour of other registry systems: for example, when a registrar adds the "clientHold" status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the "Status: CLIENT HOLD" appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.


24.12. Resilience

The SRS has a stateless architecture designed to be fully resilient in order to provide an uninterrupted service in the face of failure or one or more parts of the system. This is achieved by use of redundant hardware and network connections, and by use of continuous "heartbeat" monitoring allowing dynamic and high-speed failover from active to standby components, or between nodes in an active-active cluster. These technologies also permit rapid scaling of the system to meet short-term increases in demand during "surge" periods, such as during the initial launch of a new TLD.


24.12.1. Synchronisation Between Servers and Sites

CentralNic's system is implemented as multiple stateless systems which interact via a central registry database. As a result, there are only a few situations where synchronisation of data between servers is necessary:

1. replication of data between active and standby servers (see Q33). CentralNic implements redundancy in its database system by means of an active/standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.

2. replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see Q34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a "hot" backup site which can be used to provide registry services in the event of a failure at the primary site.


24.13. Operational Testing and Evaluation (OT&E)

An Operational Testing and Evaluation (OT&E) environment is provided for registrars to develop and test their systems. The OT&E system replicates the SRS in a clean-room environment. Access to the OT&E system is unrestricted and unlimited: registrars can freely create multiple OT&E accounts via the Registrar Console.


24.14. Resourcing

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LAand .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.

CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 60,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 1.33% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

 


This completes our response to Q24.


25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.

Except where specified this answer refers to the operations of Webera Inc.'s outsource Registry Service Provider, CentralNic.

The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.

CentralNic has operated its EPP system since 2005, and it currently operates at significant load in terms of registrars, sessions and transaction volumes. CentralNic's EPP system is fully compliant with the following RFC specifications:

*5730 - Base Protocol

*5731 - Domains

*5732 - Host Objects

*5733 - Contact Objects

*5734 - TCP Transport

*3735 - Extension Guidelines

*3915 - RGP Extension

*5910 - DNSSEC Extension


25.1. Description of Interface

EPP is a stateful XML protocol layered over TCP (see RFC 3734 (http://tools.ietf.org/html/rfc3734)). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).

EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.

EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.

EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.

Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.

EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.


25.1.1. Objects supported

Registrars may create and manage the following object types in the CentralNic EPP system:

*domains (RFC 5731 (http://tools.ietf.org/html/rfc5731))

*host objects (RFC 5732 (http://tools.ietf.org/html/rfc5732))

*contact objects (RFC 5733 (http://tools.ietf.org/html/rfc5733))


25.1.2. Commands supported

CentralNic supports the following EPP commands:

*<hello> - retrieve the <greeting> from the server

*<login> and <logout> - session management

*<poll> - message queue management

*<check> - availability check

*<info> - object information

*<create> - create object

*<update> - update object

*<renew> - renew object

*<delete> - delete object

*<transfer> - manage object transfer


25.2. EPP state diagram

Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.


25.3. EPP Object Policies

The following policies apply to objects provisioned via the EPP system:


25.3.1. domains

1. domains must comply with the syntax described in RFC 1035 (http://tools.ietf.org/html/rfc1035) §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.

2. domains must have a registrant attribute which is associated with a contact object in the database.

3. domains must have an administrative contact attribute which is associated with a contact object in the database.

4. domains must have a technical contact which attribute is associated with a contact object in the database.

5. domains may have an billing contact attribute which is associated with a contact object in the database.

6. domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS

7. the host object model for domains is used rather than the host attribute model.

8. domains may have a number of status codes. The presence of certain status codes indicates the domain's position in the lifecycle, described further in §27.

9. where policy requires, the server may respond to a <domain:create> command with an "Object Pending" (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.

10. when registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.

11. when renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. domains which auto-renew are renewed for one year at a time.

12. domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.

13. domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910 (http://tools.ietf.org/html/rfc5910).

14.only the sponsoring registrar of the domain may submit <update>, <renew> or <delete> commands for the domain.


25.3.2. Host objects

1. host names must comply with RFC 1035 (http://tools.ietf.org/html/rfc1035). The maximum length of the host name may not exceed 255 characters.

2. in-bailiwick hosts must have at least one address of either type (IPv4 or IPv6). Any number of additional addresses of either type may be provided

3. sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.

4. if a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.

5. registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.

6. a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).

7. inter-registrar transfers are not permitted.

8. only the sponsoring registrar of the host may submit <update> or <delete> commands for the object.


25.3.3. Contact objects

1. contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.

2. phone numbers and email addresses must be valid as described in RFC 5733(http://tools.ietf.org/html/rfc5733) §2.5 and §2.6.

3. contact information is accepted and stored in "internationalized" format only: that is, contact objects only have a single <contact:postalInfo> element and the type attribute is always "int".

4. the<contact:org>, <contact:sp>, <contact:pc>, <contact:phone> and <contact:fax> elements are optional.

5. contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.

6. a contact cannot be deleted if one or more domains are associated with it.

7. only the sponsoring registrar of the contact may submit <update> or <delete> commands for the object.


25.4. EPP Extensions

CentralNic supports the following EPP extensions. CentralNic's implementations fully comply with the required specifications.


25.4.1. Registry Grace Period Mapping

Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915 (http://tools.ietf.org/html/rfc3915). This is described further in §27.


25.4.2. DNSSEC Security Extensions Mapping

Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.

CentralNic supports the specification defined in RFC 5910 (http://tools.ietf.org/html/rfc5910). This supports two interfaces: the DS Data Interface and Key Data Interface. CentralNic supports the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the <secDNS:dsData> element. The maxSigLife element is optional in the specification and is not currently supported.


25.4.3. Launch Phase Extension

CentralNic has assisted development of a standard EPP extension for registry "launch phases" (ie Sunrise and Landrush periods), during which the steady-state mode of "first-come, first-served" operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in an Internet-Draft (see http://tools.ietf.org/html/draft-tan-epp-launchphase-00). It is hoped that this draft will eventually be published as an RFC which can be implemented by other registries and registrars.

CentralNic's system implements this extension and will support the most recent version of the draft during the initial launch of the TLD. Once the TLD enters General Availability, this extension will no longer be available for use by registrars. Example frames describing the use of this extension are included in Appendix 25.2.

If and when this extension is published as an RFC, CentralNic will update the implementation so that it is compliant with the final specification

25.4.4. IDN Extension

The IDN extension allows registrars to specify the IDN table associated with an IDN domain at the point of registration. It also extends the <domain:info> response to return the IDN table associated with an IDN domain. This extension is specified at http://tools.ietf.org/html/draft-obispo-epp-idn.

If and when this extension is published as an RFC, CentralNic will update the implementation so that it is compliant with the final specification.

25.4.5. Fee Extension

This extension allows registrars to query for the fees charged by the registry for certain transactions. The server response provides a hint as to the fees charged to the registrar for the requested action. The extension extends the “check” command frame to include a currency, action (ie create, renew, transfer, restore) and period for a given transaction (in addition to the object specified in the main request). The response frame is extended to include the fee associated with the requested transaction.

This extension is specified at the following URL, which includes example request and response frames, and an EPP schema: http://tools.ietf.org/html/draft-brown-epp-fees

CentralNic’s implementation will be updated as the specification develops and will be finalized upon publication of the RFC.


25.5. Registrar Credentials and Access Control

Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the "Management" access level can change their EPP password via the Registrar Console.

RFC 5730 (http://tools.ietf.org/html/rfc5730) requires "mutual, strong client-server authentication". CentralNic requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with CentralNic via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.


25.6. Session Limits and Transaction Volumes

There are no limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However the system is fully capable of imposing connection limits and this measure may be used in future to ensure equal access amongst registrars.


25.7. Transaction Logging and Reporting

All "transform" commands are logged. Transform commands are: <create>, <renew>, <update>, <delete> and <transfer>. The system logs the time and date when the command was received, the registrar which submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.

The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.

Query commands (<check>, <info>, <poll op="req">) and session commands (<login>, <logout> and <hello>) are not logged due to the large volume of such queries (particularly <check> queries). The EPP system uses counters for these commands to facilitate generation of monthly reports.


25.8. EPP Message Queue

The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic currently supports the following EPP message notifications:

*approved inbound transfer

*rejected inbound transfer

*new outbound transfer

*cancelled outbound transfer

*approved or rejected domain registration request (where TLD policy requires out-of-band approval of <domain:create> requests)


25.9. Registrar Support, Software Toolkit

CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:

*Net::EPP, a general purpose EPP library for Perl. See http://code.google.com/p/perl-net-epp/

*Preppi, a graphical EPP client written in Perl. See https://www.centralnic.com/company/labs/preppi

*Net_EPP, a PHP client class for EPP. See https://github.com/centralnic/php-epp

*Simpleepp, a Python client class for EPP. See https://bitbucket.org/milosn/simpleepp

*tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python. See https://bitbucket.org/milosn/tx-epp-proxy

These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.


25.10. Quality Assurance, RFC Compliance

To ensure that its EPP system fully complies with the relevant specifications documents, CentralNic has implemented the following:


25.10.1. Schema Validation

The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected. By default, this feature is disabled in the production environment but it is enabled in all other environments (as described below).


25.10.2. Multi-stage Deployment and Testing

EPP system code is developed, tested and deployed in a multi-stage environment:

1. Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.

2. All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).

3. Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.


25.10.3. Registrar Feedback

Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation on the responses they receive. When issues are detected by registrars, they are encouraged to submit bug reports so that developers can rectify the issues.


25.11. EPP System Resourcing

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time person.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.

CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 60,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 1.33% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

 


This completes our response to Q25.


26. Whois: describeA complete answer should include, but is not limited to:Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:A complete answer is expected to be no more than 5 pages.

Except where specified this answer refers to the operations of Webera Inc.'s outsource Registry Service Provider, CentralNic.

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.

Whois is described by RFC 3912 (http://tools.ietf.org/html/rfc3912), which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.


26.1. Compliance

The Whois service for the TLD will comply with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service will be provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as RDAP) then CentralNic will implement these as soon as reasonably practicable.

CentralNic will monitor its Whois system to confirm compliance. Monitoring stations will check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic will maintain a public Whois contact to which bug reports and other questions about the Whois service can be directed.


26.2. Domain Name

By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:

*Domain ROID

*Domain Name

*Domain U-label (if IDN)

*Creation Date

*Last Updated

*Expiration Date

*EPP status codes

*Registrant Contact Information

*Administrative Contact Information

*Technical Contact Information

*Billing Contact Information (if any)

*Sponsoring Registrar ID

*Sponsoring Registrar Contact Information

*DNS servers (if any)

*DNSSEC records (if any)

An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730(http://tools.ietf.org/html/rfc5730), Q2.8. The ROID field corresponds to the <domain:roid> element of EPP <info> responses.

A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:

*PENDING CREATE - a <domain:create> command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.

*ADD PERIOD - the domain is in the Add Grace Period

*CLIENT HOLD - the registrar has added the clientHold status

*DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)

*INACTIVE - the domain has no DNS servers

*PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion

*PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period

*PENDING RESTORE - a restore request has been received, but the Restore Report has not been received

*PENDING TRANSFER - there is an active inter-registrar transfer for the domain

*RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period

*RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)

*SERVER HOLD - the registry has added the serverHold status

*TRANSFER PERIOD - the domain is in the Transfer Grace Period

*TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)

*UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)

*OK - present if none of the above apply.

The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.

Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the "INACTIVE" status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.


26.3. Contact

Users can query for information about a contact by submitting a query of the form "contact [ID]", where "[ID]" is the contact ID equivalent to the <contact:id> element in EPP <info> responses. This is also the ID used when referring to contacts in domain responses.

The following information is included in Dontact records:

*Contact ID

*Sponsoring Registrar

*Creation Date

*Last Updated Date

*EPP Status Codes

*Contact Name

*Organisation

*Street Address (1-3 fields)

*City

*State/Province

*Postcode

*Country Code (2 character ISO-3166 code)

*Phone number (e164a format)

*Fax number (e164a format)

*Email address

An example of a contact object whois response is included in Appendix 26.2. A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:

*DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)

*TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)

*UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)

*PENDING TRANSFER - there is an active inter-registrar transfer for the contact object

*LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status


26.4. Host Objects

Users can query for information about a host object by submitting a query of the form "nameserver [HOST]". The following information is included in host records:

*Server Name

*IPv4 address (if any)

*IPv6 address (if any)

*EPP status codes

*Sponsoring Registrar

*Creation Date

*Referral URL (if any)

*An example of a host whois response is included in Appendix 26.3. A host object may have an IPv4 or IPv6 address if the host is "in-bailiwick", ie subordinate to a domain name within a TLD operated by the registry. IP address information is not shown for "out-of-bailiwick" hosts.

Host objects may only have two status codes:

*INACTIVE - the host is not associated with any domain names

*LINKED - the host is associated with one or more domain names

The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in the TLD, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original <create> request.


26.5. Character Encoding

Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.


26.6. IDN Support

The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.


26.7. Bulk Access

CentralNic will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). CentralNic will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.

At ICANN's request, CentralNic will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. CentralNic will provide the data within 2 business days.


26.8. Load Projections

As described in Q31, CentralNic's existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.

The number of daily queries per domain for each existing gTLD was calculated using figures for the month of November 2011 published by ICANN. This analysis may be found in Appendix 26.6. It shows little correlation between the number of domains in the TLD and the number of queries that each domain receives. Smaller gTLDs such as .aero and .museum receive more queries per domain than larger gTLDs, but .jobs (which is much larger than either .aero or .museum) received more queries per domain than either. It should be noted that the high volumes observed for .XXX are very likely due to activities surrounding the Landrush and initial launch of that TLD.

CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for the TLD. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.


26.9. Technical Implementation

A diagram describing the infrastructure supporting the Whois service may be found in Figure 26.1. During normal operations, the Whois service is operated at the primary operations centre in London. During failover conditions, it is operated at the Disaster Recovery site in the Isle of Man (see Q34).

Queries pass through the firewalls to one of two front-end load balancers. Round-robin DNS distributes queries between the devices. Load balancers are configured in High Availability mode so that if one a server fails, the other will resume service on its IP address until the server can be restored. Queries are distributed to backend application servers via weighted least connections algorithm.


26.9.1. Application Server Architecture

Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whoisng Apache module (see https://www.centralnic.com/registry/labs/mod-whois) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.


26.9.2. Caching

Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.


26.9.2. Database

The Whois service draws data directly from the primary database. The query volume required to sustain the Whois service is comparable to that of a modest web application such as a small e-commerce site, and as a result a dedicated database for the Whois system is not required. As can be seen in Figure 26.1, a separate logging database is used to aggregate log data for use with the rate limiting system.


26.10. Web based Whois Service

CentralNic provides a web interface to the Whois service on its website. In addition, Webera Inc. will provide a similar service on the TLD registry website. The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to the rate limiting described above, but users will be required to complete a CAPTCHA to prevent high-volume automated access.


 


26.11. Anti-Abuse Mechanisms

CentralNic has implemented measures to mitigate the threat of abuse of the Whois service. The primary threat to the Whois service are so-called "dictionary" attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.

The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing /48 will be blocked.

Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels which are unappealing for attackers.

CentralNic keeps a "white list" of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists are also incorporated into the white list, and IP addresses registered on ICANN's RADAR system will also be included. Queries from IP addresses that appear on the white list are not rate-limited. Interested parties can request addition to the white list by contacting CentralNic's public customer service team.

The web-based Whois does not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.


26.11.1. Denial-of-Service attacks

The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNic's network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system (see Q42) proactively detects these threats. As the Whois service directly queries the primary SRS database, CentralNic rate-limits on the database backend to prevent an attack against the Whois service from disrupting the SRS.


26.12. Monitoring and Logging

Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.


26.13. Resourcing

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to almost one full-time person (83%.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.

CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 60,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 1.33% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

The Abuse and Compliance functions will be outsourced to the Abuse and Compliance team (20 staff) of the Directi Group.

The Directi Group and CentralNic teams provide abuse monitoring detection mechanisms to block data mining. Additionally the support team in conjunction with both the Compliance teams administer requests for listing on the Whitelist.

A detailed list of the Abuse and Compliance desk of Directi is provided in Q28. The Directi Group is protected against loss of staff due to its scale of operations. This is described in further detail in Q39

 


This completes our response to Q26.


27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.

Except where specified this answer refers to the operations of Webera Inc.'s outsource Registry Service Provider, CentralNic.

The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.


27.1. Available

The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a "NOT FOUND" response to queries. An EPP <check> command will return an "avail" status of 1.


27.2. Registered

A registar submits an EPP <create> command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrar's balance. The initial registration period may be any whole number of years between one (1) and ten (10).

For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).

While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain name's DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a <renew> EPP command or using the Registrar Console.

The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.


27.3. Expired

When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrar's account.

For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.


27.4. Redemption Grace Period

Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from the TLD zone.

For the first thirty (30) days after receipt of the delete request, the domain is in the "Pending Delete Restorable" state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the "Pending Restore" state.

The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the "Pending Delete Restorable" state.


27.5. Redemption Period State Diagram

Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915 (http://tools.ietf.org/html/rfc3915).


27.6. Pending Delete

Forty (40) days after the receipt of the delete request, the domain leaves the "Pending Delete Restorable" and enters the "Pending Delete" status. The registrar cannot submit a Restore Request during this period.


27.7. Released

Five (5) days after the domain enters the "Pending Delete" status the domain name is purged from the database and is once again available for registration.


27.8. Other Grace Periods

The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.


27.8.1. Add Grace Period

As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.


27.8.2. Auto-renew Grace Period

As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.


27.8.3. Renew Grace Period

The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP <renew> command, or via the Registrar Console.


27.8.4. Transfer Grace Period

The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.


27.9. Hold Periods

The registry implements the following hold periods:


27.9.1. Registration Hold Period

The Registration Hold Period forbids inter-registrar transfers of domain names within sixty (60) days of initial registration.


27.9.2. Transfer Hold Period

The Transfer Hold Period forbids transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.


27.10. Lock Statuses

The registry system permits the following lock statuses for domain names:


27.10.1. clientHold

This status may be set by registrars using an EPP <update> command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.


27.10.2. clientDeleteProhibited

This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can delete the domain.


27.10.3. clientRenewProhibited

This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can renew the domain.


27.10.4. clientUpdateProhibited

This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the <update> request frame includes a <rem> element to remove this status. Once the status has been removed, subsequent <update> commands will succeed.


27.10.5. clientTransferProhibited

This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP <transfer> command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.


27.10.6. serverHold

This status is set by the registry in accordance with policy. It cannot be removed by registrars. Domains with this status are removed from the DNS and will not resolve.


27.10.7. serverDeleteProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.8. serverUpdateProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.9. serverRenewProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.10.10. serverTransferProhibited

This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP <transfer> command will be refused with EPP response code 2304 (Status Prohibits Operation).


27.11. Lifecycle Processing

Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.

Billing runs take place once per day. The billing run performs the following batch jobs:

*auto-renewal of expired domains

*processing of registration and renewal fees for domains that move outside their grace periods

*processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)

*purging of domains scheduled for deletion

The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.


27.12. Inter-Registrar Transfer Period

When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.


27.13. pendingCreate Status

The Registry system supports the "pendingCreate" status for domain names, as described in RFC 5731 (http://tools.ietf.org/html/rfc5731), Q3.3. Domains in this state are fully registered in the database (subsequent <create> commands would fail with an Object Exists error) but are not present in the DNS.

This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.

If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain which begins to resolve.


27.14. Resourcing

The domain registration lifecycle is managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure which supports the lifecycle processing systems. Backend systems are hosted on a flexible virtual infrastructure hosted at the primary operations centre at the Goswell Road Data Centre in London.

The domain registration lifecycle does have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent has been dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.

As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 30% of a full time person. Because of the maturity and stability of this system (which has been in use for more than 16 years), only 5% of time of a technical developer has been allocated to this area.

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNic's resources.

CentralNic's resourcing model assumes that the "dedicated" resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 60,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 1.33% of the total resources available for this area of the registry system.

In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.

The Abuse and Compliance functions will be outsourced to the Abuse and Compliance team (20 staff) of the Directi Group. The Compliance team outsourced to the Directi Group is responsible for any abuse of the registration policies within .app.

Most manual tasks fall to the Abuse and Compliance teams of the Directi Group, with staff experienced in development of policy for policy rich TLD environments. They have the required legal and industry background to perform this function.

A detailed list of the Abuse and Compliance desk of Directi is provided in Q28. The Directi Group is protected against loss of staff due to its scale of operations. This is described in further detail in Q39.

 


This completes our response to Q27.


28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.A complete answer is expected to be no more than 20 pages.

Webera Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (including ResellerClub.com and BigRock.com) and Web Hosting companies. The Directi Group manages centralized functions for all its businesses. We have outsourced our Abuse and Compliance functions to the Directi Group and our Abuse and Compliance desk will be staffed as a cost center by them.

This response aims to provide a 360 degree perspective on our policies and processes to prevent abusive activities, and ensure swift mitigation when abuse does occur. We have prepared this plan based on over a decade’s experience of fighting abuse as a Registrar, learnings through active industry participation, best-practices from exisiting registry operators and expert inputs from our back-end technical partner CENTRALNIC.

1. ABUSE MITIGATION EXPERIENCE AND CAPABILITIES

With over four million active domain names registered through its registrars, Directi has significant experience (over 10 years) of managing domain names and is fully cognizant of the threat that stems from their abuse.
As one of the world’s top ten registrars, we equally understand our ability to make a sizable contribution towards curbing internet abuse, and believe that mitigating this threat is one of our foremost responsibilities. By instituting policies, processes and services which go significantly above and beyond our obligation as a registrar, Directi has taken various initiatives to make the Internet a safer ground.
To drive this effort, Directi has a committed function working towards identifying abusive domain names and enforcing its policies. Our Abuse Desk functions 24⁄7 and takes prompt and effective action (both reactively and proactively) against domains reported or co-networked to be involved in any sort of online abuse. Complaints ranging from phishing, spam, malware perpetration, 419 scams, child pornography, copyright infringement and varied forms of abuse are subject to investigation at our Abuse Desk on a daily basis. The nature of abuse and the types of complaints received are varied in nature and intensity, and are documented in more detail further.
On average we already address, 15000 reported or detected abuse cases per year. Abuse cases are addressed within pre-determined SLAs, and our team is committed to ensure that each incident is resolved satisfactorily. The Directi abuse team has been heralded on many occasions by various security groups, law enforcement organizations and the general anti-abuse community for the manner in which abuse mitigation has been handled by us. Additionally, we have always become highly involved, and continue to remain committed to industry-wide efforts to address organized abuse such as botnets (see below) and large scale phishing attacks, and any other malfeasances.

1.1 NOTABLE INSTANCES OF DIRECTI’S SUCCESSFUL ABUSE MITIGATION INITIATIVES

Our abuse mitigation team has developed strong relationships with many security groups and individuals in the abuse mitigation community, with the aim of sharing intelligence and facilitating quick action on abusive domain names. These sources provide us actionable intelligence on domains bought through our registrar. We have also participated in coordinated takedowns with such agencies in the past and are committed to doing so in the future. Please refer to Attachment ʹQ28_Recommendationsʹ which showcases letters from several global agencies including the IRS, commending our work and cooperation on several fronts. Following are some examples of cases where our efforts paid great results in abuse mitigation –

1.1.1 MARIPOSA WORKING GROUP

Directi was part of the Mariposa Working Group which was responsible for taking down the largest known botnet network at the time.
(Ref: http:⁄⁄defintel.com⁄docs⁄Mariposa_White_Paper.pdf)

ʺDirecti is BY FAR THE BEST registrar we have ever worked with at taking down criminal domains in a timely, efficient and professional manner. Your team was absolutely key to the Mariposa Working Group taking down one of the largest Botnets in the history of the Internet. You and your team should be VERY proud of that :)ʺ -- Christopher Davis, Former CEO of Defence Intelligence

1.1.2 IM WORM BOTNET TAKEDOWN COORDINATED BY IID

Since 1996, IID (Internet Identity) has been providing technology and services that secure the Internet presence for an organization and its extended enterprise. It recently introduced a number of unique approaches to secure organizations’ use of Internet infrastructure with ActiveTrust® BGP, ActiveTrust DNS, and ActiveTrust Resolver with TrapTrace. Directi worked with IID, acting against problematic domain names and sharing intelligence to take down a notorious botnet that was plaguing the internet for quite some time.

ʺThank you for your exceptional coordination with our team and the other providers … during the simultaneous shutdown. We wanted to follow up with you and let you know that despite the last minute unanticipated scramble, the takedown was a success and the botnet has been shutdown.ʺ -- Lauren Lamp, Manager ⁄ Service Delivery - internetidentity.com

1.1.3 FAKE PHARMACY TAKEDOWNS COORDINATED BY LEGITSCRIPT

LegitScript is the leading source of information for patients, Internet users, physicians, businesses and other third parties who need to know if an Internet pharmacy is acting in accordance with the law and accepted standards of ethics and safety. LegitScript is identified by the National Association of Boards of Pharmacy as the only Internet pharmacy verification service that adheres to its standards. After affiliating with LegitScript, we have witnessed a steep downfall in fake pharma-related registrations. ResellerClub (referred below) is our wholesale registrar brand.
(Ref:http:⁄⁄legitscriptblog.com⁄2009⁄03⁄directi-no-safe-haven-for-rogue-internet-pharmacies⁄)

ʺSome registrars claim that they cannot shut down dangerous ʹno-prescription-requiredʹ and fake online pharmacies. ResellerClub has proven that this is not true. By refusing to profit from dangerous, criminal activity at the expense of Internet users, ResellerClub has established itself as a responsible example for the rest of the
Internet community.ʺ John Horton, President, LegitScript.com

We have enclosed a commendation letter from LegitScript in
Attachment ʹQ28_Recommendationsʹ, which speaks of our leadership in fighting fake and rouge pharmacies.

1.1.4 419 FEEDBACK LOOP WITH ARTISTS AGAINST 419 (AA419.ORG)

An honorary member of the APWG (Anti-Phishing Working Group), Artists Against 419 is a premier organization with expertise in identifying, cataloging, and terminating fraud sites. Our tie-up with them has been greatly successful in eliminating fraudulent registrations within our portfolio. (Ref: http:⁄⁄blog.aa419.org⁄?p=134)

ʺMany registrars do respond to abuse reports and take action against them. However none do it as quickly and efficiently as Directi. If all registrars and hosters take this approach, it might then be possible to reduce internet fraud.ʺ -- aa419.org

We have enclosed a letter from Artists Against 419 in Attachment ʹQ28_Recommendationsʹ commending the speed and impact of our proactive abuse mitigation activites.



2. PROPOSED ABUSE POLICY FOR .App

We have fully adopted the definition of abuse developed by the Registration Abuse Policies Working Group (Registration Abuse Policies Working Group Final Report 2010).

Our abuse policies described in this section apply to initial and ongoing domain registrations, ie any domain name must comply with these policies during registration and throughout its tenure.

Abusive behaviour in a TLD may relate can be categorized into:

2.1 REGISTRATION POLICY VIOLATIONS

.App adopts certain Registration policies and any violations of these policies would be treated as an Abuse.

2.1.1 SUNRISE POLICY VIOLATION

.App will have a sunrise period as described in the response to Question 29. Our sunrise policy will have an overarching goal to protect interests of IP holders globally, and be based on best practices seen in previous TLD launches. We will implement the Trademark Claim Service and partner with experienced service providers to run the TM verification, Sunrise Challenge and Auction processes. All Sunrise domain names will be validated before they are activated. Hence the possibility of a Sunrise policy violation is low. However the Sunrise process provides for a Sunrise Dispute Resolution Policy, and any disputes that fall within its scope will be referred to the Sunrise Dispute Resolution provider. If the abuse desk receives any complaints concerning a sunrise domain which violates the Sunrise eligibility policy the abuse desk will direct the complainant to the Sunrise Dispute Resolution provider

2.1.2 WHOIS INACCURACY

.App requires Whois accuracy as per its contracts. Any domain name with inaccurate whois information will be deemed to be in violation of its contract and hence will be deemed as an abuse and handled in the manner described ahead.

2.1.3 TRADEMARK INFRINGEMENT VIOLATION AND UDRP

.App requires registrants to abide by UDRP. If the abuse desk receives any complaints concerning a domain name which infringes upon the trademark right of a 3rd party, the abuse desk will direct the complainant to the Uniform Dispute Resolution provider.

All names registered under .App will be subject to the UDRP and URS processes. We believe that URS will deter cybersquatting, and some malicious activities that illegitimately use brand names. We will seek to expeditiously process all URS cases, and are already equipped with mature processes and tracking systems to manage and keep track of all cases.

The URS process will be run by our compliance team, who has significant experience in processing UDRP complaints for our Registrar businesses.

While Registrars will be responsible for processing all UDRP cases related to the .App, we will reserve the right to act on their behalf when necessary, and process all court orders that are directed to us.

2.2 ACCEPTABLE USAGE RELATED VIOLATIONS

.App adopts certain Content and Acceptable usage policies and any violations of these would be treated as an Abuse. The following are deemed as violations of our content and acceptable usage policy

2.2.1 INTELLECTUAL PROPERTY, TRADEMARK, COPYRIGHT, AND PATENT VIOLATIONS, INCLUDING PIRACY

Intellectual property (IP) is a term referring to a number of distinct types of creations of the mind for which a set of exclusive rights are recognized—and the corresponding fields of law. Under intellectual property law, owners are granted certain exclusive rights to a variety of intangible assets, such as musical, literary, and artistic works; discoveries and inventions; and words, phrases, symbols, and designs. Common types of intellectual property rights include copyrights, trademarks, patents, industrial design rights and trade secrets in recognized jurisdictions. Any act resulting in theft, misuse, misrepresentation or any other harmful act by any individual or a company is categorized as Intellectual Property violation.

2.2.2 SPAMMING

The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. Unsolicited emails advertising legitimate and illegitimate products, services, and⁄or charitable requests and requests for assistance are also considered as spam.

2.2.3 PHISHING (and various forms of identity theft)

Fraudulent web services and applications meant to represent⁄confuse or mislead internet users into believing they represent services or products for nefarious purposes, such as illegally gaining login credentials to actual legitimate services.

2.2.4 PHARMING AND DNS HIJACKING

Redirection of DNS traffic from legitimate and intended destinations, by compromising the integrity of the relevant DNS systems. This leads unsuspecting Internet users to fraudulent web services and applications for nefarious purposes, such as illegally gaining login credentials to actual legitimate services.

2.2.5 DISTRIBUTION OF VIRUSES OR MALWARE


Most typically the result of a security compromised web service where the perpetrator has installed a virus or “malevolent” piece of software meant to infect computers attempting to use the web service in turn. Infected computers are then security compromised for various nefarious purposes such as gaining stored security credentials or personal identity information such as credit card data. Additionally compromised computers can sometimes be remotely controlled to inflict harm on other internet services (see botnet below).

2.2.6 CHILD PORNOGRAPHY

Child pornography refers to images or films (also known as child abuse images) and, in some cases, writings depicting sexually explicit activities involving a minor.

2.2.7 USING FAST FLUX TECHNIQUES

A methodology for hiding multiple source computers delivering malware, phishing or other harmful services behind a single domain hostname, by rapidly rotating associated IP addresses of the sources computers through related rapid DNS changes. This is typically done at DNS zones delegated below the level of a TLD DNS zone.

2.2.8 RUNNING BOTNET COMMAND AND CONTROL OPERATIONS

A Botnet is a significant coordinated net of compromised (sometimes tens of thousands) computers running software services to enact various forms of harm - ranging from unsanctioned spam to placing undue transaction traffic on valid computer services such as DNS or web services. Command and control refers to a smaller number of computers that issue⁄distribute subsequent commands to the Botnet. Compromised botnet computers will periodically check in with a command and control computer that hides behind a list of date triggered, rotating domain registrations, which are pre-loaded in the compromised computer during its last check-in.
Registries play a key role in breaking this cycle of pre-determined domain registrations by deactivating said registrations prior to the compromised computers being able to use them to contact the command and control computer. Successful intervention results in the botnet losing contact with their command and control computers, leaving them inactive and reducing potential harms.

2.2.9 HACKING

Hacking constitutes illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of other individuals. Also includes any activity that might be used as a precursor to an attempted system penetration.

2.2.10 FINANCIAL AND OTHER CONFIDENCE SCAMS

Financial scams, including but not limited to the cases defined below, are operated by fraudsters to lure investors into fraudulent money making schemes. Prominent examples that will be treated as abusive are –
1. Ponzi Schemes. A Ponzi scheme is essentially an investment fraud wherein the operator promises high financial returns or dividends that are not available through traditional investments. Instead of investing victimsʹ funds, the operator pays ʺdividendsʺ to initial investors using the principle amounts ʺinvestedʺ by subsequent investors. The scheme generally falls apart when the operator flees with all of the proceeds, or when a sufficient number of new investors cannot be found to allow the continued payment of ʺdividends.ʺ
2. Money Laundering. Money laundering, the metaphorical ʺcleaning of moneyʺ with regard to appearances in law, is the practice of engaging in specific financial transactions in order to conceal the identity, source, and⁄or destination of money, and is a main operation of the underground economy.
3. 419 Scams. ʺ419ʺ scam (aka ʺNigeria scamʺ or ʺWest Africanʺ scam) is a type of fraud named after an article of the Nigerian penal code under which it is prosecuted. It is also known as ʺAdvance Fee Fraudʺ. The scam format is to get the victim to send cash (or other items of value) upfront by promising them a large amount of money that they would receive later if they cooperate.

2.2.11 ILLEGAL PHARMACEUTICAL DISTRIBUTION

Distribution and promotion of drugs, locally within a nation or overseas, without prescription and appropriate licenses as required in the country of distribution are termed illegal.

2.2.12 OTHER VIOLATIONS

Other violations that will be expressly prohibited under the .App TLD include
* Network attacks
* Violation of applicable laws, government rules and other usage policies


3. PROCEDURES TO MINIMIZE ABUSIVE REGISTRATIONS

3.1 BUILDING A ZERO-TOLERANCE REPUTATION

Our Anti-Abuse Policy will put Registrants on notice of the ways in which we will identify and respond to abuse and serve as a deterrent to those seeking to register and use domain names for abusive purposes. The policy will be made easily accessible on the Abuse page of our Registry website which will be accessible and have clear links from the home page along with FAQs and contact information for reporting abuse.

Directi has vast experience in minimizing abusive registrations. Our zero tolerance procedures and aggressive proactive takedown measures as a Domain Registrar have resulted in a white-hat reputation discouraging abusive registrations to begin with. We intend on following the same approach with respect to Registry operations for .App. Our proactive abuse procedures are geared towards building a reputation that discourages miscreants and malicious intent. Once it is known that abusive registrations and registrations in violation of our policies are suspended rapidly, both abusive registrations and abusive behavior will be discouraged.

Our Abuse policies described in section 2 above apply to new and ongoing registrations.

3.2 BUILDING AWARENESS OF OUR ANTI-ABUSE POLICY

The Abuse Policy will be published on the abuse page of our Registry website which will be accessible and have clear links from the home page. The abuse page of our Registry website will emphasise and evidence our commitment to combating abusive registrations by clearly identifying what our policy on abuse is and what effect our implementation of the policy may have on registrants. We anticipate that the clear message, which communicates our commitment to combating abusive registrations, will further serve to minimise abusive registrations in our TLD.

3.3 ICANN PRESCRIBED MEASURES

In accordance with our obligations as a Registry Operator we will comply with all requirements in the ‘gTLD Applicant Guidebook’. In particular, we will comply with the following measures prescribed by ICANN which serve to mitigate the potential for abuse in the TLD:

* DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. We will encourage registrars and Internet Service Providers to deploy DNSSEC capable resolvers in addition to encouraging DNS hosting providers to deploy DNSSEC in an easy to use manner in order to facilitate deployment by registrants. DNSSEC deployment is further discussed in the context of our response to Question 43;
* Prohibition on Wild Carding as required by section 2.2 of specification 6 of the Registry Agreement

* Removal of Orphan Glue records: ICANN requires a policy and procedure to take action to remove orphan glue records from the zone when provided with evidence that the glue is indeed present and aiding malicious conduct.

 

CentralNic's registry system includes effective measures to prevent the abuse of orphan glue records.

 

Firstly, the Shared Registry System will reject any request to create host object that is the child of a non-existent domain name. That is, if EXAMPLE.APP does not exist, then NS0.EXAMPLE.APP cannot be created.

If the parent domain name does exist, then only the sponsoring registrar of that domain is permitted to create child host objects.

 

CentralNic's registry system currently follows the third model described in the SAC 048 report: orphan glue records are deleted from the registry and removed from the DNS when the parent domain name is deleted. If other domains in the database are delegated to orphan hosts that are removed, then the delegation is also removed from these domains.

 

The removal of glue records upon removal of the delegation point NS record mitigates the potential for use of orphan glue records in an abusive manner

3.4 REGISTRANT DISQUALIFICATION

Abusive domain registration has historically attracted a small number of individuals and organisations that engage in high volume registrations, driven by the marginal profitability of individual abusive registrations. As specified in our Anti-Abuse Policy, we reserve the right to deny registration of a domain name to a Registrant who has repeatedly engaged in abusive behaviour in our TLD or any other TLD.

Registrants, their agents or affiliates found through the application of our Anti-Abuse Policy to have repeatedly engaged in abusive registration will be disqualified from maintaining any registrations or making future registrations. This will be triggered when our records indicate that a Registrant has had action taken against it an unusual number of times through the application of our Anti-Abuse Policy.

Registrant disqualification provides an additional disincentive for qualified registrants to maintain abusive registrations in that it puts at risk even otherwise non-abusive registrations through the possible loss of all registrations.

In addition, name servers that are found to be associated only with fraudulent registrations will be added to a local blacklist and any existing or new registration that uses such fraudulent NS record will be investigated.

The disqualification of ‘bad actors’ and the creation of blacklists mitigates the potential for abuse by preventing individuals known to partake in such behaviour from registering domain names.

3.5 PROACTIVE DETERMINATION OF POTENTIAL ABUSE

There are several tell-tale signs which are indicative of abusive intent. The following are examples of the data variables will serve as indicators that we will monitor with the help of our registry technical partner.

* Unusual Domain Name Registration Practices: practices such as registering hundreds of domains at a time, registering domains which are unusually long or complex or include an obvious series of numbers tied to a random word (abuse40, abuse50, abuse60) may when considered as a whole be indicative of abuse


* An Unusual Number of Changes to the NS record: the use of fast-flux techniques to disguise the location of web sites or other Internet services, to avoid detection and mitigation efforts, or to host illegal activities is considered abusive in the TLD. Fast flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. As such an unusual number of changes to the NS record may be indicative of the use of fast-flux techniques given that there is little, if any, legitimate need to change the NS record for a domain name more than a few times a month.

* Results of Monthly Checks: The random monthly checks to promote Whois accuracy (described ahead) are not limited to serving that purpose but may also be used to identify abusive behaviour given the strong correlation between inaccurate Whois data and abuse.

* Analysis of Cross Validation of Registrant Whois data against Whois Data Known to be Fraudulent.

* Analysis of Domain Names belonging to Registrant subject to action under the Anti-Abuse policy: in cases where action is taken against a registrant through the application of our Anti-Abuse policy, we will also investigate other domain names by the same registrant (same name, nameserver IP address, email address, postal address etc).

4. PROCEDURES FOR HANDLING COMPLAINTS

4.1 MECHANISMS FOR REPORTING COMPLAINTS

In order to make it easy for security agencies, law enforcement bodies and vigilant users to report incidents of abusive behavior within .App, we shall enable several channels of communication.

4.1.1 SINGLE POINT OF CONTACT

In accordance with section 4.1 of specification 6 of the Registry Agreement we will establish a single abuse point of contact (SAPOC) responsible for addressing and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller. Complaints may be received from members of the general public, other registries, registrars, LEA (Law Enforcement Agencies), government and quasi governmental agencies and recognised members of the anti-abuse community.

The SAPOC’s accurate contact details (email, fax and mailing address) will be provided to ICANN and published on the abuse page of our Registry website. The SAPOC will in turn represent the entire compliance desk operated by the Directi group on behalf of .App as an outsourced function.

The Registry website will additionally also include:

* All public facing policies in relation to the TLD including the Anti-Abuse Policy described in section 2
* A web based submission service for reporting inaccuracies in Whois information
* Registrant Best Practices
* Conditions that apply to proxy registration services and direction to the SAPOC to report domain names that violate the conditions

As such, the SAPOC may receive complaints regarding a range of matters concerning the abuse policy defined in section 2

The SAPOC will be the primary method by which we will receive notification of abusive behaviour from third parties. It must be emphasised that the SAPOC will be the initial point of contact following which other processes will be triggered depending on the identity of the reporting organization and the type of abuse. Accordingly, separate processes for identifying abuse will exist for reports by LEA⁄government and quasi governmental agencies and members of the general public.

When any party makes a report via the Abuse POC e-mail address or the abuse web form, he or she will receive back a ticket number from a ticketing system. Our abuse team will then examine these reports, and use a ticketing system to track each issue. This process will leverage a dedicated software that we have used for handling abuse reports to our registrar businesses. It is our goal to provide a timely response to all abuse complaints concerning domains registered in the TLD, as per the SLAs defined by us.

4.1.2 LAW ENFORCEMENT AGENCIES

We recognise that LEA, governmental and quasi governmental agencies may be privy to information beyond the reach of others which may prove critical in the identification of abusive behaviour in our TLD. As such, we will provide an expedited process which serves as a channel of communication for law enforcement, government and quasi-governmental agencies to, amongst other things, report illegal conduct in connection with the use of the TLD.

The process will involve prioritization and prompt investigation of reports identifying abuse from those organizations. The steps in the expedited process are summarised as follows:

1. We will identify relevant LEA, government and quasi governmental agencies who may take part in the expedited process
2. We will establish back channel communication with each of the identified agencies in order to obtain information that may be used to verify the identity of the agency upon receipt of a report utilising the expedited process;
3. We will publish contact details on the abuse page of the Registry website for the SAPOC to be utilised by only those taking part in the expedited process;
4. All calls to this number will be responded to by a member of our 24⁄7 Compliance Team
5. We will verify the identity of the reporting agency employing methods specific to that agency established during back channel communication;
6. Upon verification of the reporting agency, we will obtain the details necessary to adequately investigate the report of abusive behaviour in the TLD;
7. Reports from verified agencies may be provided in the Incident Object Description Exchange Format (IODEF) as defined in RFC 5070. Provision of information in the IODEF will improve our ability to resolve complaints by simplifying collaboration and data sharing
8. The report identifying abuse will then be dealt with in accordance to our process defined in subsequent sections of this answer

4.2 EVALUATION OF COMPLAINTS

The next step is for our abuse desk staff to review each complaint. The abuse team looks at the facts of each complaint in order to verify the complaint. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants while at the same time, taking timely action to mitigate abusive behaviour and to minimize impact.

Evaluation of complaints thus forms a very important part of the process. The following factors are considered for each case:

* Type, Severity and immediacy of the abuse: Upon initial review, all incoming complaints will face an initial evaluation on the basis of severity and harm cased due to the abuse. While we will adhere to the SLAs laid down for our abuse mitigation processes, regardless of the type of complaint, there will be some complaints that will be considered relatively more severe and of greater malicious impact than others. Complaints with a higher severity⁄malicious impact and immediacy will be processed with greater urgency than others.

* Determining the origin of the complaint: a credible complainant e.g. a law enforcement agency, a security group etc. automatically lends genuineness to a complaint while a complaint from a previously unknown source will require a background check to ensure that the complaint is not from a miscreant looking to create unnecessary trouble for a domain owner. Thus while we may take immediate action complaints from reliable sources, those from other sources, not backed by enough evidence, may require further due-diligence before action is taken.

* Evaluating proof submitted along with a complaint: A complaint is also evaluated based on the supporting evidence provided which further determines the validity of a complaint. At this stage we will also attempt to establish a clear link between the activity reported and the alleged type of abusive behaviour. This is done to ensure that addressing the reported activity will address the abusive behaviour. In some cases the abuse is evident, which will result in immediate processing of the complaint from our side without much further due-diligence. In some cases, where the abuse may not be evident upfront, our desk will rely on supplementary evidence provided by the complainant which may be further ratified. While not limited to this list, supporting evidence could range from links, screen-shots of websites, copy right ⁄ trademark details, emails, email headers, whois information, ID proof etc.

* Evaluating historical data: As mentioned before, we will maintain a log of all complaints received, including the contact details of complainants, the whois details of the abusers, the nameservers of abusive domain registrations, the type of domain names, the IPs of spamming domains etc. This will further help us in establishing trends for further action as required. A registration that re-sounds alarms from previously seen abusive trends will ascertain the necessary pre-emptive mitigation processes.

Assessing abuse reports requires good judgment, and we will rely upon our, specially trained abuse desk staff.

While we recognise that each incident of abuse represents a unique security threat and should be mitigated accordingly, we also recognise that prompt action justified by objective criteria are key to ensuring that mitigation efforts are effective. With this in mind, we have categorised the actions that we may take in response to various types of abuse by reference to the severity and immediacy of harm. This categorisation will be applied to each validated report of abuse and actions will be taken accordingly. It must be emphasised that the actions to mitigate the identified type of abuse in the section⁄s below are merely intended to provide a rough guideline and may vary upon further investigation.

4.3 CATEGORIZATION OF COMPLAINTS

Each confirmed case of abuse is bucketed into one of the following categories

4.3.1 CATEGORY 1

Probable Severity or Immediacy of Harm - Low
Examples of types of abusive behaviour – Small Scale Spam, Whois Inaccuracy

Mitigation steps:

1. Preliminary Investigation
2. Delegate to Registrar
3. Monitor response time-frame vis-à-vis SLA
4. Take direct action in case of Registrar non-conformance.

4.3.2. CATEGORY 2

Probable Severity or Immediacy of Harm - Medium
Examples of types of abusive behaviour – Medium scale spam, inactive botnets and other forms of abuse which have a higher degree of impact than the ones bucketed as category 1, but still relatively limited in terms of potential damage.

Mitigation steps:

1. Preliminary Investigation
2. Delegate to Registrar
3. Monitor response time-frame vis-à-vis SLA
4. Take direct action in case of Registrar non-conformance.

4.3.3 CATEGORY 3

Probable Severity or Immediacy of Harm - High
Examples of types of abusive behaviour – Fast Flux Hosting, Phishing, Large scale hacking, Pharming, Botnet command and control, Child Pornography and all other cases deemed to carry a very high risk of large scale impact

Mitigation steps for Abuse policy violation:

1. Suspend domain name
2. Investigate
3. Restore or terminate domain name


4.4 MITIGATION OF COMPLAINTS

The mitigation steps for each category will now be described:

4.4.1 CATEGORY 1

Types of abusive behaviour that fall into this category include those that represent a low severity or immediacy of harm to registrants and internet users. These generally include behaviours that result in the dissemination of unsolicited information or the publication of illegitimate information. While undesirable, these activities do not generally present such an immediate threat as to justify suspension of the domain name in question. Each of these cases will be delegated down to the Registrar and the registrar’s performance, in terms of response and resolution rate, will be monitored and recorded by us. In case of non-conformance by the Registrar, we will take-over the issue.

We will also continually monitor the issue to track possible increases in the severity of harm. In case the threat level is above what was originally anticipated, we will escalate the issue to category two or three and act in accordance.

4.4.2 CATEGORY 2

Types of abusive behaviour that fall into this category include those that represent a medium severity or immediacy of harm to registrants and internet users. These generally include medium scale spam, network intrusion, inactive botnets etc. Following the notification of the existence of such behaviours, our compliance team will delegate the issue to registrars and envoke the more aggressive SLAs that apply to this category of risk.

As was the case with category 1, we will continue to monitor the registrar’s conformance with the SLAs and take direct action when necessary. We will also check for possible increases in risk levels and escalate the abuse category if required.

4.4.3 CATEGORY 3

Highly serious, sensitive and large scale issues like phishing, child pornography and large-scale botnet are considered to be a serious violation of the Anti-Abuse Policy owing to its fraudulent exploitation of consumer vulnerabilities, high level of risk and far-reaching consequences. Given the direct relationship between the uptime of these activities, and extent of harm caused, we recognise the urgency required to execute processes that handle these cases directly, without any delegation.
As soon as the abuse is substantiated, we will proceed to suspend the domain name pending further investigation to determine whether the domain name should be unsuspended or cancelled. Cancellation will result if upon further investigation, the behaviour is determined to be one of the types of abuse defined in the Anti Abuse Policy.

In some cases we may change the nameservers associated with the domain and⁄or use EPP prohibited statuses in appropriate combinations to restrict activity against the domain such as contact updates, deletes or transfers.

In the past we have modified Nameservers to sinkhole malicious domains, so research partners can measure botnets and monitor malware activity. We believe this to be an extremely effective mechanism which takes down large scale attacks from the source, and assists researchers to build processes and tools which prevent future attacks from the same source. Our team will follow the same process for domains belonging to our registry.

We have built special systems to suspend individual and bulk batches of domains. This will allow us to quickly take care of cases where criminals have obtained bulk batches of domain names. This will be of use if malware designers use generation algorithms to register domains.

Reactivation of the domain name will result where further investigation determines that abusive behaviour, as defined by the Anti Abuse Policy, does not exist and that the domain name is not causing any harm.


4.5 PROPOSED RESOLUTION METRICS AND SERVICE LEVEL AGREEMENTS

SLA RESPONSE CONSIDERATIONS FOR REPORTED ABUSE CASES

As described earlier, each abuse case and goes into one of three response categories depending on the severity and immediacy of the harm caused by the abuse. In the case of any failed SLA responses, the Registry reserves the right to act directly to suspend and⁄or lock the domains associated with a given abuse case. Additionally, highly serious, sensitive and large scale issues are ranked as category 3 and prioritized above all other cases.

Attachment ʹQ28_Abuse Mitigation SLAʹ, shows the flowchart and SLA response for each category of abuse complaint

4.5.1 CATEGORY 1

Some examples of abuses cases that will be categorized as 1 include:

* Low scale Spam
* Whois Inaccuracy
* Low scale Malware
* Any other abuse case deemed as low risk

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 2 business days from the time of receipt of the complaint
* Registry Notification to Registrar: 2 business days from the time of receipt of the complaint
* Initial Response from Registrar: 3 business days from the time that the complaint notification is sent to the Registrar
* Update from Registrar as action taken or intended: 7 business days from the time that the complaint notification is sent to the Registrar
* Final Resolution: 15 business days from the time the issue was reported to us

4.5.2 CATEGORY 2

Some examples of abuses cases that will be categorized as 2 include:

* Medium scale Spam
* Confirmed but inactive botnet domains
* All other abuse cases deemed as medium scale

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 2 business days from the time of receipt of the complaint
* Registry Notification to Registrar: 2 business days from the time of receipt of the complaint
* Initial Response from Registrar: 2 business days from the time that the complaint notification is sent to the Registrar by the Registry
* Update from Registrar as action taken or intended: 3 business days from the time that the complaint notification is sent to the Registrar by the Registry
* Final Resolution: 8 business days from the time of receipt of the complaint

4.5.3 CATEGORY 3

Some examples of abuses cases that will be categorized as 3 include:

* Confirmed Cases of child pornography
* Confirmed cases of Phishing
* Confirmed and active botnets domains
* Any other case deemed as large scale

RESPONSE SLA COMMITMENTS:

* Initial Registry Response to Complainant: 1 business day from the time of receipt of the complaint
* Registry time to direct takedown: 3 business days from the time of receipt of the complaint

4.6 FOLLOW-UP AND CAPTURE OF METRICS

The abuse staff will track each abuse complaint ticket to resolution. Our ticketing system allows us to capture many metrics. We will measure resolution times, and we can see what percentage of abuse reports could be confirmed. We will also capture how many domains were suspended, and we will break down statistics by registrar in the TLD. This will help us identify registrars that have regular problems, and we can work with them to systematically identify and act against bad actors.


4.7 CONTRACTUAL PROVISIONS

As the registry operator, we will use the Registry-Registrar Agreement (RRA) to establish the registry’s right to act against abusive registrations as described in the preceding sections. We will also use the contract to impose certain obligations on the registrars, and make some obligations binding on the registrants by obligating specific terms in the registrar-registrant contract. The contract will be a mandatory part of the Registrar accreditation process with the Registry. Production access to the Registry will not be granted until the contract is duly signed AND the registrar has provided copy of their Registry Registrant Agreement to demonstrate the inclusion of any required pass-through provisions. The registrar is also fully obligated to their accreditation contracts with ICANN (via the RAA) which includes elements such as the UDRP.

In general, the contracts will establish that the registry operator may reject a registration request, or can delete, revoke, update, suspend, cancel, or transfer a registration for violations of our anti-abuse policies. The terms in our proposed agreement will empower us to take necessary action including, but not limited to:

* Discretionary action against domain names that are 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;

* Action as may be required to protect the integrity and stability of the Registry, its operations, and the TLD system;

* Action as may be required 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;

* Action as may be required 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;

* Action as may be required to correct mistakes made by the Registry or any Accredited Registrar in connection with a registration; or

* Enforcement of Registry policies and ICANN requirements; each as amended from time to time;

* Actions as otherwise provided in the Registry-Registrar Agreement and⁄or the Registry-Registrant Agreement.

Below are some additional points that we will look to cover in the RRA. These clauses will enable us to enforce some additional, proactive measures to curb and deter abuse:

* We will reserve the right to deny registration of a domain name to a registrant who has repeatedly engaged in abusive behaviour in our TLD or any other TLD.

* We will reserve the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.

* We may amend or otherwise modify this policy to keep abreast of changes in consensus policy or new and emerging types of abusive behaviour in the Internet.

* Relevant language that enforces Registrars to conform with the SLAs provided for abuse cases delegated to them and provides the Registry with rights to take relevant actions in those cases.

* Relevant language for sanctions against a Registrar leading to termination with respect to repeated offences and violations of their obligations with respect to abuse mitigation.

* Relevant language that requires Registrars to provide for the following in their agreement with the Registrants
** Whois accuracy provisions
** Acceptable content and usage policy
** Sunrise policy and submission to SDRP
** UDRP
** Rights granted to the Registrar and Registry to take necessary action wrt abuse prevention including sharing information with regulatory bodies and LEA and domain takedowns where appropriate
** Indemnification

All of the contracts above will be regularly reviewed (atleast once a year) based on the experience gained by the Registry during actual operation and any relevant changes required to mitigate abuse will be appropriately introduced in consultation with ICANN and the Registrars

4.8 ADDITIONAL MITIGATION MEASURES

Based on our experience of running a leading Registrar, we have also devised some powerful mechanisms which will prevent possible abuse, and quickly diffuse abusive domains. These mechanisms include:

4.8.1 PROFILING & BLACKLISTING

This process, currently in practice for our registrar businesses within the Directi Group, is used for gathering intelligence on known offenders. We maintain abuse ratios for each of the 1,000,000 plus registrants and 65,000 plus resellers who use Directi.

Experience has enabled us to use these ratios accurately to uncover registrants who are known and repeated offenders. Expert offenders rarely reuse the same registrant profile and often maintain a myriad number of profiles to mask their true identity. Through pattern mapping we try and group registrant profiles that we believe belong to the same operator.

The same process is followed at the reseller level too, to identify those resellers who are knowingly harboring offenders, or are themselves involved in abuse.
When a registrant profile is confirmed to be involved in organized abuse, including but not limited to cybersquatting, phishing, pharming etc., our immediate step is to suspend that customer’s control over his abusive domain portfolio. Our compliance team then carefully analyzes each domain name to identify those which are abusive and not already taken-down. The necessary action is undertaken to diffuse any ongoing abuse.

We plan to adopt the ‘Profiling and Blacklisting’ process within our registry operations. Since all of our compliance resources will be trained and experienced in running this process, its implementation into .App will be simple. Specifics of this policy and process, as it applies to our registry business, will be drawn out.

4.8.2 PROACTIVE QUALITY REVIEW

As a preventive safeguard against abusive domain registration, we follow a consistent review process for domain registrations on our registrar, where a sample of newly registered domain names are analyzed for potential abusive activity. Coupled with our profiling process (described above), it enables us to take proactive measures against domain names that are registered solely to perpetrate malicious activities such as phishing, or otherwise infringe on the rights of others. This helps us curb abusive activity before it can affect too many Internet users. We shall seek to implement similar safeguards for .App, and encourage registrars to incorporate this practice as part of their abuse mitigation processes.

4.9 INDUSTRY COLLABORATION AND INFORMATION SHARING

Upon obtaining Registry Accreditation, we will join the Registry Internet Safety Group (RISG), whose mission is to facilitate data exchange and promulgate best practices to address internet identity theft, especially phishing and malware distribution. In addition, Directi coordinates with the Anti-Phishing Working Group (APWG), other DNS abuse prevention organizations and is subscribed to the NXdomain mailing list.
Directi’s strong participation in the industry facilitates collaboration with relevant organizations on abuse related issues and ensures that Directi is responsive to new and emerging domain name abuses.

The information shared as a result of this industry participation will be used to identify domain names registered or used for abusive purposes. Information shared may include a list of registrants known to partake in abusive behavior in other TLDs. While presence on such lists will not directly constitute grounds for registrant disqualification, we will investigate domain names registered to those listed registrants and take appropriate action. In addition, information shared regarding practices indicative of abuse will facilitate detection of abuse by our own monitoring activities.

5. PROMOTING AND ENSURING WHOIS ACCURACY

All registrants shall be required, via required language in every Registrar – Registrant Agreement, to provide accurate Registrar Data Directory Services, RDDS (WHOIS) contact details, and to keep those details current. Additionally, Registrars shall have direct responsibility to ensure Whois accuracy through their accreditation contracts with ICANN. Whois Data Reminder Policy or WDRP is an example of a direct Registrar⁄ICANN contractual obligation to monitor that RDDS (WHOIS) information is accurate and up to date – it includes requiring Registrars to notify their registrants at least once a year to ensure their RDDS (WHOIS) data is correct and up to date.

The threat of inaccurate Whois information significantly hampers the ability to enforce policies in relation to abuse in the TLD by allowing the registrant to remain anonymous. In addition, LEA’s rely on the integrity and accuracy of Whois information in their investigative processes to identify and locate wrongdoers.

In recognition of this, we propose that .App have the following measures to promote RDDS (WHOIS) accuracy.

5.1 WHOIS INACCURACY REPORTING SYSTEM

On the abuse page of our Registry website, we will provide a web based submission service for reporting Whois accuracy issues. Each of these issues will then be resolved as per the process detailed in the previous sections.

5.2 REGULAR MONITORING & SAMPLING

Registrants of randomly selected domain names will be contacted by telephone using the provided Whois information by a member of our team in order to verify the phone number and confirm other Whois information. Where the registrant is not contactable by telephone, alternative contact details (email, postal address) will be used to contact the registrant who must then provide a contact number that is verified by our team. In the event that the registrant is not able to be contacted by any of the methods provided in Whois, the domain name will be cancelled following five contact attempts or one month after the initial contact attempt (based on the premise that a failure to respond is indicative of inaccurate Whois information and is grounds for terminating the registration agreement)

5.3 ANALYSIS OF REGISTRY DATA

We will adopt some processes to identify patterns and correlations indicative of inaccurate Whois (e.g. repetitive use of fraudulent details).

5.4 PROMOTING ACCURATE WHOIS DATA

WDRP (Whois Data Reminder Policy) implemented by ICANN at the Registrar level, mandates regular e-mail communication to registrants reminding them to keep their whois data accurate and updated. In addition, we will also identify effective mediums to remind registrants to update Whois information and inform them of the ramifications of a failure to respond to our random monthly checks. Ramifications include but are not limited to termination of the registration agreement.

5.5 ENFORCEMENT AT REGISTRAR LEVEL

Registrars will also be contractually required to promptly investigate reports of RDDS (WHOIS) accuracy submitted to them, and resolve each case within a predefined time-frame stipulated through our SLA.

For all cases where inaccuracy is confirmed, we will record the registrar from whom the domain was sourced. We will use this data to capture the ratio of inaccuracies as a percentage of total domains managed, and identify the registrars that seem to attract an abnormally high number of inaccuracy issues. We will then work with those registrars to find potential ways in which they can progressively reduce the number of whois inaccuracy incidents.

The measures to promote Whois accuracy described above strike a balance between the need to maintain the integrity of the Whois service, which facilitates the identification of those taking part in illegal or fraudulent behaviour, and the operating practices of the Registry Operator and Registrars which aim to offer domain names to registrants in an efficient and timely manner.

Awareness among registrants that we will actively take steps to maintain the accuracy of Whois information mitigates the potential for abuse in the TLD. It deters abusive behaviour given that registrants may be identified, located and held liable for all actions in relation to their domain name.

5.6 PROXY ⁄ PRIVACY PROTECTION

We have designed a policy that will maximize the legitimate use of proxy and privacy services, and will minimize use by criminals and abusers.

.App will allow the use of proxy and privacy services, where permitted by ICANN policies and requirements. These services have legitimate uses. Millions of registrants use them to protect their privacy and personal data from spammers and other parties that mine zone files and RDDS (WHOIS) data.

It is undeniable that criminals also use whois proxy services, to hide their true identities. To deter that practice, our policy will require that:

* Registrants must use only a privacy⁄proxy service operated, contracted or owned by the domain’s sponsoring registrar, and cannot use third-party proxy services unaffiliated with the domain’s sponsoring registrar. This means that a domain’s sponsoring registrar will always be in possession of the underlying contact data.

*. Registrars and resellers must provide the underlying registrant information to the registry operator upon request, and⁄or upon a legitimate law-enforcement request, within 24 hours. The registry operator will keep this data confidential, unless #3 below applies.

* Registrars and resellers must remove the proxy protection and publish the underlying registrant information in the RDDS (WHOIS) if it is determined by the registry operator and⁄or the registrar that the registrant has breached any terms of service, such as anti-abuse policies.

The registrar obligations outlined above shall apply with equal force to all registrations sponsored by a registrar, whether those registrations were placed directly with the registrar or through a reseller.

These conditions will be implemented contractually by inclusion of corresponding clauses in the RRA as well as being published on the abuse page of our Registry website. Individuals and organisations will be encouraged through our abuse page to report any domain names they believe violate the restriction on the availability of proxy registrations, following which appropriate action may be taken by us. Publication of these conditions on the abuse page of our Registry website ensures that registrants are aware that despite utilisation of a proxy registration service, actual Whois information will be provided to LEA upon request in order to hold registrants liable for all actions in relation to their domain name. The certainty of Whois disclosure of domain names which draw the attention of LEA, deters those seeking to register domain names for abusive purposes.

6. CONTROLS FOR PROPER ACCESS TO DOMAIN FUNCTIONS

We realize that registrants often do not willfully use their domain names for abusive purposes, but domain names end up being compromised because of a lapse in security. Though this cannot always be controlled or mitigated by the registry, we are nevertheless committed to ensure that adequate safeguards are implemented to prevent domain names from being compromised and thereby making them prone to abuse.

6.1 MULTI-FACTOR AUTHENTICATION AND SECURE CONNECTIVITY FOR REGISTRARS

Through the contractual agreement with the registry, registrars will be expected to develop and employ in their domain name registration business, all necessary technology and restrictions to ensure that their connection to the registry is secure. All data exchanged between the registrarʹs system and the registry shall be protected to avoid unintended disclosure of information. Each EPP session shall be authenticated and encrypted using two-way secure socket layer (ʺSSLʺ) protocol. Registrars will also agree to authenticate every EPP client connection with the registry using both an X.509 server certificate issued by a commercial Certification Authority identified by the registry and their registrar password, disclosed only to their respective employees on a need-to-know basis. Registrars will also access the SRS Web interface by utilizing an additional two-factor authentication token. Further details on this is provided in the response to Question 24 and 25

6.2 ENFORCEMENT OF STRONG AUTHCODES

Every domain name will have a strong authorization (authinfo) code, composed of alphabets, numerals, and special characters. An inter-registrar domain name transfer will not be permitted unless the registrant provides this authorization code at the time of executing the transfer process.

6.3 NOTIFICATION FOR EVERY UPDATE

We plan to notify the domain name holder upon any update made to a domain name. The notification will be committed through email to either or both of the registrant and technical contact of the domain name.

6.4 REGISTRY LOCK

Certain mission-critical domain names such as transactional sites, email systems and site supporting applications may warrant a higher level of security. ‘Registry locking’ is a feature which allows registrants to prohibit any updates at the Registry Operator level. This service will be available programmatically via EPP, so all registrars will be able to offer it in real-time to their registrants. The feature will prevent unintentional transfer, modification or deletion of the domain name, and mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update name servers of a mission critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name. This is described in detail in our response to Question 27

6.5 AWARENESS PROGRAMS

In accordance with our commitment to operating a secure and reliable TLD, we will attempt to improve registrant awareness of the threats of domain name hijacking, registrant impersonation and fraud, and emphasize the need for registrants to keep registration information accurate and confidential. Awareness will be raised by:

* Publishing the necessary information on the Abuse page of our Registry website in the form of videos, presentations and FAQs;

* Developing and providing to registrants, resellers and Registrars Best Common Practices that describe appropriate use and assignment of domain auth info codes and risks of misuse when the uniqueness property of this domain name password is not preserved.

7. RESOURCING PLANS

7.1 PERSONNEL

Functions described herein will be performed by -
* Directi Group staff under contract with us -
** Abuse & Compliance Team
* Dispute Resolution Service Providers that are selected wrt UDRP, and SDRP

Directi Group possesses an exemplary track record of diffusing abuse on 4 million plus domains under their Registrar. The abuse mitigation function of our Registry will be handled by the same team that currently manages this process for the registrar businesses.

The existing compliance team comprises of:
* 1 Compliance Manager
* 1 Team Supervisor
* 4 Cyber Security Analysts
* 9 Compliance Officers

The compliance function is staffed on a 24⁄7⁄365 basis and capable of handling up to a peak of 52,800 unique abuse incidents per year. Each incident by itself can relate to a few to hundreds of domain names.

While this team is trained to investigate and verify all types of issues, they can also fall back on support from our technical staff when required. Similarly, abuse cases following new or unexpected parameters may also be escalated to legal support staff for expert counsel.

Our estimates of resource sizing are directly derived from the abuse case incident volumes currently experienced. On a base of 4 million domains across our Registrar businesses within Directi, each year we experience approximately:

* 6000 malware related abuses
* 1600 phishing abuses
* 1200 spam cases
* 600 pharmacy related abuses
* 5600 large botnet related abuse cases annually

This averages an incident rate of approximately 15,000 cases of abuse per year or 3.75 incidents per 1000 names

Since registries delegate a large portion of their abuse responsibilities to registrars, it is fair to assume that our registry’s abuse incident ratio will be lower than what we experience as registrars. In fact, in our case 2⁄3 categories of incidents will be delegated to the registrar and our direct involvement is expected in only 25%-35% of all incidents. However, given our proactive approach, importance on ensuring a clean and secure namespace, and aggressive SLAs, we choose to be conservative by assuming that we will be involved in 75% of the incidents.

Based on our projections, we expect .App to reach 60,623 domain names at the end of the 3rd year. Extrapolating from our current rate of 3.75 incidents per 1000 names, we can expect around 227 abuse incidents yearly and be involved in 171 (75%) of them. Including the estimated 10 RPM incidents (details in our response to Q29), brings our total projected incident count to 181. This conservative estimate also accounts for the aggressive SLAs at multiple levels, law enforcement interfacing and having a single POC available at all times.

The Compliance desk works as a centralized team and all team members are responsible for all abuse complaints across all businesses of Directi. Costs of the Compliance team are then allocated to each business based on the % utilization of the compliance team by each business. We have assumed 15% of 2 compliance officers’ time towards .App. Given that our 15 people team has the capacity to handle 52,800 incidents yearly, 2 officers with 15% of their time, will have a total capacity to handle 1056 incidents annually, which is more than adequate for the Registry. It is important to point out that 15% of the 2 officers is merely a cost allocation method and in actuality all 15 members and more of the Compliance team will be available to resolve abuse issues for TLD.

Our planning provides us redundant capacity of around 11x in Y1, over 7x in Y2 and around 4.8x in Y3, to handle both abuse as well as RPM related cases such as those involving URS. This leaves substantial headroom for rapid growth of domains under management, or a sudden surge in abuse incident rates per domain.

It is also important to note that there exists some economies of scale in our operations since a large number of these cases are dealt with in bulk, or large batches, as they relate to the same instigator(s).

The abuse team has a structured training program in place which enables them to rapidly scale-up resources when required. Typically a team of recruits are given four weeks of training and two weeks on the floor before they are fully activated.

Given the rapid growth rate of Directi businesses, Directi will continue to hire and maintain a sizable buffer over and above anticipated growth.

7.2 FINANCIAL CONSIDERATIONS

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46 (ʹQ46_References: Service and Facilities Commitment Agreementʹ). This cost is shown in the financial answers.

This completes our response to Q28.



29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.

Webera Inc. is a wholly owned subsidiary within the Directi Group. The Directi Group runs various businesses including several ICANN Accredited Domain Registrars (including ResellerClub.com and BigRock.com) and Web Hosting companies. At Directi, through our decade long experience as a domain name registrar, we have consciously strived to ensure that domain registrations through our platform do not violate the intellectual property or other rights of any person or organization.

Our experience as a domain name registrar gives us insight into the necessity and importance of rights protection, and the mechanisms that must be employed to assure it. With .App, we shall leverage our experience to implement a comprehensive set of policies and procedures that will uphold intellectual property rights to the greatest possible extent.

The protection of trademark rights is a core goal of .App. .App will have a professional plan for rights protection. It will incorporate best practices of existing TLDs, going above and beyond the ICANN mandated RPMs to prevent abusive registrations and rapidly take-down abuse when it does occur.

The broad outline of our response is provided below:

1. PREVENT ABUSIVE REGISTRATIONS
2. ONGOING RIGHTS PROTECTION AND ABUSE PREVENTION
3. ADDITIONAL RIGHTS PROTECTION MECHANISMS
4. REDUCING PHISHING AND PHARMING
5. PREVENTING TRADEMARK INFRINGEMENT IN OPERATING THE REGISTRY
6. RESOURCING PLANS


1. PREVENT ABUSIVE REGISTRATIONS

We will put into place the following measures to ensure prevention of registrations that infringe the IP rights of others

1.2 SUNRISE PROCESS

Our sunrise registration service will provide trademark holders with atleast a 30-day priority period in which to register their trademarks as domain names.

Sunrise Timeline -
Day 1:Single sunrise round opens
Day 30:Sunrise round closes
Day 31:Sunrise allocation begins and Sunrise period ends

1.2.1 SUNRISE POLICY SUMMARY AND SDRP SUMMARY

This section provides a summary of our Sunrise Policy and SDRP. We have formulated our policies and processes based on existing guidance concerning Sunrise and TMCH provided by ICANN. Any additional guidance in the future that requires changes to our process and policies will be implemented.

Through our Sunrise Policy we will offer atleast one 30-day sunrise round in which trademark holders satisfying the Sunrise eligibility requirements proposed in the ‘gTLD Applicant Guidebook’ will be eligible to apply for a domain name. This sunrise period will be the first opportunity for registration of domain names in .App. Trademarks upon which sunrise applications are based must meet the criteria defined in the ‘gTLD Applicant Guidebook’ and be supported by an entry in the TMCH.

Sunrise allocation will start at the end of the 30-day sunrise period. If one validated application is received for a domain name, the same will be allocated to the applicant in the 10-day period following the end of the sunrise period. Where multiple validated applications are received for a domain name, the name will be allocated by auction. Domain names registered during the sunrise period will have a minimum term of 1 yr.

We will adopt a Sunrise Dispute Resolution Policy (‘SDRP’) to allow any party to raise a challenge on the four grounds identified in the ‘gTLD Applicant Guidebook’. All registrants will be required to submit to proceedings under the SDRP. SDRP claims may be raised at any time after registration of a domain name.

1.2.2 IMPLEMENTATION

1.2.2.1 SUNRISE PRICING

We plan to charge a non-refundable Sunrise application fee or validation fee of $80 for every Sunrise application. We have arrived at the fee to offset the cost of the trademark validation and other administrative over-heads.

1.2.2.2 SUNRISE IMPLEMENTATION PLAN

1. Prior to sunrise, trademark holders should apply for inclusion of their marks in the TMCH database.
2. Our Sunrise Policy and SDRP will be published on our website.
3. A trademark holder satisfying the sunrise eligibility requirements will pay the non-refundable sunrise application fee and submit its application corresponding to its TMCH entry to a registrar along with evidence of the corresponding TMCH entry.
4. Registrars will send the sunrise applications to CENTRALNIC. They will be charged the application fee at this time.
5. CENTRALNIC will perform standard checks to ensure that the domain name is technically valid and hold the application for subsequent allocation.
6. Upon conclusion of the 30-day sunrise period, CENTRALNIC will

allocate the  applied-for names as follows:

 

* Where a single sunrise application exists for a particular domain name CentralNic will allocate the domain to the sponsoring registrar and will charge the sunrise registration fee to the registrar.

* Where multiple sunrise applications exist for a domain name, CentralNic will compile and communicate to a 3rd-party auction services provider appointed by us a list of competing applicants, who will be invited to participate in an auction for the domain name.

7. The auction services provider will facilitate the auction process and upon completion of the auction will notify all participants of the outcome and collect the auction payment from the winning participant.

 

8. Upon payment of the auction bid, the auction services provider will communicate to CentralNic the details of the winning auction participant and will submit the revenue collected to CentralNic. CentralNic will validate the communication from the auction services provider and allocate the domain name to the sponsoring registrar of the winning application.

 

9. Sometime during this process CentralNic will identify all sunrise applications which constitute an ‘Identical Match’ (as defined in the ‘gTLD Applicant Guidebook’) with a TMCH entry and provide notice to the TMCH via the List of Registered Domain Names (LORDN).


1.2.1.3 SDRP IMPLEMENTATION PLAN

When a domain is awarded and granted to a registrant, that domain will be available for lookup in the public WHOIS.

After a Sunrise name is awarded it will also remain under a “Sunrise Lock” status for at least 60 days. During this period the domain will not resolve and cannot be modified, transferred, or deleted by the sponsoring registrar. A domain name will be unlocked at the end of that lock period only if it is not the subject of a Sunrise Challenge. Challenged domains will remain locked until the dispute resolution provider has issued a decision, which the registry operator will promptly execute.

SDRP filings will be handled by an appropriate service provider as per ICANN guidance and policy.

1.2.1.4 IMPLEMENTATION THROUGH CONTRACTUAL RELATIONSHIPS

The following features of the Sunrise and SDRP implementation plans described above will be executed by the inclusion of corresponding clauses in our RRA, which will require inclusion in registrars’ Domain Name Registration Agreements:
* By making a sunrise application the applicant agrees to purchase the domain name if that name is allocated to the applicant.
* The sunrise application fee is non-refundable.
* All sunrise applicants must submit to proceedings under the SDRP.

1.3 TRADEMARK CLAIMS SERVICE

For atleast 60 days during general availability we will offer the trademark claims service as described in the ‘gTLD Application Guidebook’.

1.3.1 IMPLEMENTATION

1.3.1.1 TRADEMARK CLAIMS SERVICE IMPLEMENTATION PLAN
This process will be executed for atleast the first 60 days of general availability:
1. an applicant will make an application to a registrar for a domain name.
2. Registrars will be required to communicate land rush application information to our registry backend provider - CENTRALNIC.
3. CENTRALNIC or Registrars (as prescribed) will interface with the TMCH to determine whether an applied-for domain name constitutes an ‘Identical Match’ with a trademark in the TMCH. If an ‘Identical Match’ is identified, the registrar will provide to the land rush applicant a Trademark Claims Notice in the form prescribed by the ‘gTLD Applicant Guidebook’. Following receipt of this notice a land rush applicant must communicate to the registrar its decision either to proceed with or abandon the registration.
4. CENTRALNIC or Registrar (as prescribed) will interface with the TMCH to promptly notify relevant mark holders of the registration of a domain name constituting an ‘Identical Match’ to their TMCH entry.

1.3.1.2 IMPLEMENTATION THROUGH CONTRACTUAL RELATIONSHIPS

The following features of our Trademark Claims Service Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:
* Registrars must comply with the TMCH as required by ICANN and the TMCH Service Provider⁄s.
* Registrars must not in their provision of the trademark claims service make use of any other trademark information aggregation, notification or validation service other than the TMCH.
* In order to prevent a chilling effect on registration, registrars must ensure that land rush applicants are not prevented from registering domain names considered an ‘Identical Match’ with a mark in the TMCH.
* Registrars must provide clear notice in the specific form provided by the ‘gTLD Applicant Guidebook’ to the prospective registrant of relevant entries in the TMCH.
* Registrars must interface with the TMCH as prescribed to relevant mark holders of the registration of a domain name constituting an ‘Identical Match’ to their TMCH entry.

2. ONGOING RIGHTS PROTECTION AND ABUSE PREVENTION

Below we describe ongoing RPMs which we will implement to mitigate cybersquatting and other types of abusive behaviour such as phishing and pharming.

2.1 UNIFORM RAPID SUSPENSION (URS)

The URS (Uniform Rapid Suspension) procedure is a new RPM the implementation of which is mandated in all new gTLDs. Understanding that a fundamental aim of the URS is expediency, all of the steps in our Implementation Plan below will be undertaken as soon as practical but without compromising security or accuracy.

2.1.1 IMPLEMENTATION

2.1.1.1 URS IMPLEMENTATION PLAN

1. We will provide to each URS provider an email address to which URS-related correspondence can be sent. On an ongoing basis, our compliance desk will monitor this email address for receipt of communications from URS providers, including the Notice of Complaint, Notice of Default, URS Determination, Notice of Appeal and Appeal Panel Findings.
2. We will validate correspondence from a URS provider to ensure that it originates from the URS Provider.
3. We will within 24 hours of receipt of a URS Notice of Complaint lock the domain name⁄s the subject of that complaint by restricting all changes to the registration data, including transfer and deletion of the domain name. The domain name will continue to resolve while in this locked status.
4. We will immediately notify the URS provider in the manner requested by the URS provider once the domain name⁄s have been locked.
5. Upon receipt of a favourable URS Determination we will unlock the domain name and redirect the nameservers to an informational web page provided by the URS provider. While a domain name is locked, our backend provider - CENTRALNIC - will continue to display all of the WHOIS information of the original registrant except for the redirection of the nameservers and the additional statement that the domain name will not be able to be transferred, deleted or modified for the life of the registration.
6. Upon receipt of notification from the URS provider of termination of a URS proceeding we will promptly unlock the domain name and return full control to the registrant.
7. Where a default has occurred (because a registrant has not submitted an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’) and a Determination has been made in favour of the complainant, in the event that we receive notice from a URS provider that a Response has been filed in accordance with the ‘gTLD Applicant Guidebook’, we will as soon as practical restore a domain name to resolve to the original IP address while preserving the domain’s locked status until a Determination from de novo review is notified to us.
8. We will ensure that no changes are made to the resolution of a registration the subject of a successful URS Determination until expiry of the registration or the additional registration year unless otherwise instructed by a UDRP provider.
9. We will make available to successful URS complainants an optional extension of the registration period for one additional year.

2.1.1.2 IMPLEMENTATION OF THE URS THROUGH CONTRACTUAL RELATIONSHIPS

The following features of our URS Implementation Plan described above will be executed by the inclusion of corresponding clauses in our RRA:

* In the event that a Registrant does not submit an answer to a URS complaint in accordance with the ‘gTLD Applicant Guidebook’, registrars must prevent registrants from making changes to the WHOIS information of a registration while it is in URS default.
* Registrars must prevent changes to a domain name when a domain is in locked status to ensure that both the Registrar’s systems and Registry’s systems contain the same information for the locked domain name.
* Registrars must not take any action relating to a URS proceeding except as in accordance with a validated communication from us or a URS provider.

2.2 UDRP

The UDRP (Uniform Domain Name Dispute Resolution Policy) is applicable to domain name registrations in all new gTLDs. It is available to parties with rights in valid and enforceable trade or service marks and is actionable on proof of all of the following three grounds:
1. The registrant’s domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights.
2. The registrant has no rights or legitimate interests in respect of the domain name.
3. The registrant’s domain name has been registered and is being used in bad faith.

The remedies offered by the UDRP are cancellation of a domain name or transfer of a domain name registration to a successful UDRP claimant.

2.2.1 IMPLEMENTATION

2.2.1.1 UDRP IMPLEMENTATION PLAN

We have two responsibilities in order to facilitate registrars’ implementation of the UDRP -
1. Our backend provider – CENTRALNIC - will maintain awareness of UDRP requirements and be capable of taking action when required and sufficiently skilled and flexible to respond to any changes to UDRP policy arising from future consensus policy reviews.
2. We will provide EPP and the SRS web interfaces to enable registrars to perform required UDRP functions in accordance with the Policy on Transfer of Registrations between Registrars.

2.2.1.2 IMPLEMENTATION OF THE UDRP THROUGH CONTRACTUAL RELATIONSHIPS

The UDRP is applicable to domain name registrations in all new gTLDs by force of a contractual obligation on Registry Operators to use only ICANN-accredited registrars, who in turn are contractually required to incorporate the UDRP in their Domain Name Registration Agreements.


3. ADDITIONAL RIGHTS PROTECTION MECHANISMS

The protection of trademark rights is a core goal of .App. Our Right Protection Mechanisms, policies and procedures go significantly above and beyond the minimum mandated RPMs to prevent abusive registrations, rapidly take-down abuse when it occurs, and foster a clean namespace for .App

This section describes several other RPMs that .App will implement that exceed the minimum requirements for RPMs and align with our goal of creating a namespace that provides maximum protection to trademark holders.


3.1 PROFILING & BLACKLISTING

This process, currently in practice for our registrar businesses within the Directi Group, is used for gathering intelligence on known offenders. We maintain abuse ratios for each of the 1,000,000 plus registrants and 65,000 plus resellers who use Directi.

Experience has enabled us to use these ratios accurately to uncover registrants who are known and repeated offenders. Expert offenders rarely reuse the same registrant profile and often maintain a myriad number of profiles to mask their true identity. Through pattern mapping we try and group registrant profiles that we believe belong to the same operator.

The same process is followed at the reseller level too, to identify those resellers who are knowingly harboring offenders, or are themselves involved in abuse.
When a registrant profile is confirmed to be involved in organized abuse, including but not limited to cybersquatting, phishing, pharming etc., our immediate step is to suspend that customer’s control over his abusive domain portfolio. Our compliance team then carefully analyzes each domain name to identify those which are abusive and not already taken-down. The necessary action is undertaken to diffuse any ongoing abuse.

We plan to adopt the ‘Profiling and Blacklisting’ process within our registry operations. Since all of our compliance resources will be trained and experienced in running this process, its implementation into .App will be simple. Specifics of this policy and process, as it applies to our registry business, will be drawn out.

3.2 PROACTIVE DOMAIN QUALITY ASSURANCE

As a preventive safeguard against abusive domain registration, we follow a consistent review process for domain registrations on our registrar, where a sample of newly registered domain names are analyzed for potential abusive activity. Coupled with our profiling process (described above), it enables us to take proactive measures against domain names that are registered solely to perpetrate malicious activities such as phishing, or otherwise infringe on the rights of others. This helps us curb abusive activity before it can affect too many Internet users. We shall seek to implement similar safeguards for .App, and encourage registrars to incorporate this practice as part of their abuse mitigation processes.

3.3 INDUSTRY COLLABORATION

3.3.1 ACTIVE INVOLVEMENT WITH SECURITY AGENCIES

In order to mitigate abuse of domain names on our registrar business, our abuse team has active involvement in helping security vendors and researchers fight domain abuse. They provide us a constant feed of abuse instances and help us identify domain names involved in activities like phishing or pharming. Some of the prominent organizations we work with include PhishLabs (phishing), LegitScript (illegal pharmaceutical distribution), Artists Against 419 (financial scams), Knujon (spam) etc. We will leverage these relationships to ensure oversight for all domain names registered within .App.

3.3.2 APWG REVIEW

Every six months, the Anti-Phishing Working Group (APWG) publishes its latest Global Phishing Survey [See http:⁄⁄www.apwg.org⁄resources.html#apwg]. This study contains an analysis of phishing per TLD. We will review the performance of our anti-abuse program against the APWG reports, and other metrics created by the security community. We will work closely with APWG to combat phishing within .App

3.3.3. MESSAGE OF ZERO TOLERANCE

Our Anti-Abuse Policy will put Registrants on notice of the ways in which we will identify and respond to abuse and serve as a deterrent to those seeking to register and use domain names for abusive purposes. The policy will be made easily accessible on the Abuse page of our Registry website which will be accessible and have clear links from the home page along with FAQs and contact information for reporting abuse.

The Directi Group has vast experience in minimizing abusive registrations. Our zero tolerance procedures and aggressive proactive takedown measures as a Domain Registrar have resulted in a white-hat reputation discouraging abusive registrations to begin with. We intend on following the same approach with respect to Registry operations for .App. Our proactive abuse procedures are geared towards building a reputation that discourages miscreants and malicious intent. Once it is known that abusive registrations and registrations in violation of our policies are suspended rapidly, this will directly result in discouraging abusive registrations and creating a clean namespace. While following this path will mean a higher compliance and abuse vigilance cost for us, we believe this effort will pay us long term rewards through abusers keeping away and .App becoming recognized as a reputable namespace.

4. REDUCING PHISHING AND PHARMING

All of the measures we have described in the preceding sections significantly reduce phishing and pharming within .App. These include RPMs like URS, and UDRP.

Over and above this our coordination with APWG, Industry Collaboration, Profiling and Blacklisting processes and Proactive measures described in Section 3 above will go a long way in ensuring a clean namespace for .App and considerably reduced phishing and pharming activities.

5. PREVENTING TRADEMARK INFRINGEMENT IN OPERATING THE REGISTRY

We take seriously our responsibilities in running a registry and we understand that while offering a sunrise registration service and the trademark claims service during start-up of our TLD and the URS and UDRP on an ongoing basis serves to minimise abuse by others, this does not necessarily serve to minimise trademark infringement in our operation of the TLD. This responsibility is now clearly expressed and imposed upon registries through the new Trademark PDDRP [Post-Delegation Dispute Resolution Procedure], which targets infringement arising from the Registry Operator’s manner of operation or use of its TLD.

Whilst we will as required under the Registry Agreement agree to participate in all Trademark PDDRP procedures and be bound by the resulting determinations, we will also have in place procedures to identify and address potential conflicts before they escalate to the stage of a Trademark PDDRP claim.

5.1 IMPLEMENTATION

1. We will notify to the Trademark PDDRP provider⁄s contact details to which communications regarding the Trademark PDDRP can be sent.
2. We will publish our Anti-Abuse Policy on a website specifically dedicated to abuse handling in our TLD.
3. Using the single abuse point of contact discussed in detail in our response to Q28, a complainant can notify us of its belief that that one or more of its marks have been infringed and harm caused by our manner of operation or use of our TLD
4. We will receive complaints submitted through the single abuse point of contact.
5. The Compliance Team will acknowledge receipt of the complaint and commence investigation of the subject matter of the complaint and good faith negotiations with the complainant in accordance with the ‘gTLD Applicant Guidebook’.
6. On an ongoing basis, our Compliance Team will monitor the email address notified to the Trademark PDDRP provider⁄s for all communications from the Trademark PDDRP provider, including the threshold determination, Trademark PDDRP complaint, complainant’s reply, notice of default, expert panel determinations, notice of appeal and determinations of an appeal panel.
7. In the event that a complaint cannot be resolved and a Trademark PDDRP claim is made, we will do the following:

* File a response to the complaint in accordance with Trademark PDDRP policy section 10 (thus avoiding, whenever possible, a default situation).
* Where appropriate, make and communicate to the Trademark PDDRP provider decisions regarding the Trademark PDDRP proceeding, including whether to request a three-person Trademark PDDRP Expert Panel, request discovery, request and attend a hearing, request a de novo appeal, challenge an ICANN-imposed Trademark PDDRP remedy, initiate dispute resolution under the Registry Agreement, or commence litigation in the event of a dispute arising under the Trademark PDDRP.
* Where appropriate, undertake discovery in compliance with Trademark PDDRP policy section 15, attend hearings raised under section 16 if required, and gather evidence in compliance with sections 20.5 and 20.6.
8. We will upon notification of an Expert Panel finding in favour of the Claimant (Trademark PDDRP policy section 14.3), reimburse the Trademark PDDRP Claimant.
9. We will implement any remedial measures recommended by the expert panel pursuant to Trademark PDDRP policy and take all steps necessary to cure violations found by the expert panel and notified by ICANN.

6. RESOURCING PLANS

6.1 PERSONNEL

Functions described herein will be performed by:

* Directi Group Abuse and Compliance team under contract with us -
** Overseeing Sunrise process
** URS
** Abuse complaints concerning RPM

* CENTRALNIC’s backend Registry
* Service Providers that are selected wrt TMCH, UDRP, URS, and SDRP

* Director of Technology at .App & Account Management staff at .App
** Overseeing Sunrise process
** Communication of the sunrise process to Registrars

Directi Group possesses an exemplary track record of diffusing abuse on 4 million plus domains under their Registrar business. The Rights protection and abuse mitigation function of our Registry will be handled by the same team that currently manages this process for the registrar businesses.

The existing compliance team comprises of:

* 1 Compliance Manager
* 1 Team Supervisor
* 4 Cyber Security Analysts
* 9 Compliance Officers

The compliance function is staffed on a 24⁄7⁄365 basis and capable of handling up to a peak of 52,800 unique abuse incidents per year. Each incident by itself can relate to a few to hundreds of domain names.

While this team is trained to investigate and verify all types of issues, they can also fall back on support from our technical staff when required. Similarly, abuse cases following new or unexpected parameters may also be escalated to legal support staff for expert counsel.

Our estimates of resource sizing are directly derived from the abuse case incident volumes currently experienced. On a base of 4 million domains as a Registrar, we experience approximately the following incidents per year:
* UDRP Cases - 200
* Other RPM incidents - 20 cases

This averages an incident rate of approximately 220 cases of abuse per year or 0.055 incidents per 1000 names. Given that this is based on a more mature base of names, it would be prudent to assume a higher rate of activity for .App. Based on our experience we have assumed the increase in activity rate to be three fold (300% of the current rate) and increase it to 0.165 per 1000 names.

Based on our projections, we expect .App to reach 60,623 domain names at the end of the third year. Extrapolating from our estimated rate of 0.165 incidents per 1000 names, we can expect around 10 incidents yearly. Including the estimated 171 Abuse incidents that the registry will be involved in (details in our response to Q28), brings our total projected incident count to 181.

The Compliance desk works as a centralized team and all team members are responsible for all abuse complaints across all businesses of Directi. Costs of the Compliance team are then allocated to each business based on the % utilization of the compliance team by each business. We have assumed 15% of 2 compliance officers’ time towards .App. Given that our 15 people team has the capacity to handle 52,800 incidents yearly, 2 officers with 15% of their time, will have a total capacity to handle 1056 incidents annually which is more than adequate for the Registry. It is important to point out that 15% of the 2 officers is merely a cost allocation method and in actuality all 15 members and more of the Compliance team will be available to resolve abuse issues for TLD.

Our planning provides us redundant capacity of over 11X in Y1, around 7X in Y2 and just over 4.8x in Y3, to handle both abuse as well as RPM related cases such as those involving URS. This leaves substantial headroom for rapid growth of domains under management, or a sudden surge in abuse incident rates per domain.

It is also important to note that there exist some economies of scale in our operations since a large number of these cases are dealt with in bulk, or large batches, as they relate to the same instigator(s).

The Abuse and Compliance team has a structured training program in place which enables them to rapidly scale-up resources when required. Typically a team of recruits are given four weeks of training and two weeks on the floor before they are fully activated.

Given our rapid growth rate and business expansion plans, we will continue to hire and maintain a sizable buffer over and above anticipated growth.

6.2 FINANCIAL COSTS

The usage of Directi Group’s staff is included in our contract with Directi attached to Q46. This cost is shown in the financial answers.

This completes our response to Q29.



30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:To be eligible for a score of 2, answers must also include:A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).

Except where specified this answer refers to the operations of Webera Inc.'s outsource Registry Service Provider, CentralNic.

30(a).1. Introduction

CentralNic's Information Security Management System (ISMS) has been certified against ISO 27001. A copy of the certificate issued by Lloyd's Register Quality Assurance (LRQA), a UKAS accredited certifier, is provided as Appendix 30.1.1. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.


30(a).2. Independent Assessment

As part of ISO 27001 compliance, CentralNic's security policies  aresubject to biannual external audit. Further details can be found in Q30(b).


30(a).3. Augmented Security Levels

Webera Inc. believes that the TLD requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, Webera Inc. and CentralNic will operate the TLD to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.

Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast ("Anycast") addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a "hot" Disaster Recovery site in the Isle of Man, as well as a backup provider relationship with GMO Registry in Japan.


30(a).4. Commitments to Registrars

Webera Inc. and CentralNic will make the following commitments to the TLD registrars:

*The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.

*The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.

*The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.

*The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in Q43).

*Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).

*Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.

*Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.


30(a).5. Access Controls

CentralNic operates an access control policy for the registry system. For example, the web-based Staff Console which is used to administer the SRS and manage registrar accounts supports a total of ten different access levels, ranging from "Trainee", who have read-only access to a subset of features, to "System Administrator" who have full access to all systems.

Underlying server and network infrastructure is also subjected to access control. A centralised configuration manager is used to centrally control access to servers. Individual user accounts are created, managed and deleted via the configuration server. Access to servers is authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the "sudo" command which is logged and audited as described below.

Only operations personnel have access to production environments. Development personnel are restricted to development, staging and OT&E environments.


30(a).6. Security Enforcement

Security controls are continually monitored to ensure that they are enforced. Monitoring includes use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).

Since CentralNic operates a centralised logging and monitoring system (see Q42), access logs are analysed in order to generate access reports which are then reviewed by NOC personnel. This includes access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems is investigated with a view to correcting any breaches and/or revoking access where appropriate.


30(a).8. Security Incident Response Policy

CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.

The Policy provides a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It also defines the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).

The Policy established an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.

The Policy makes use of CentralNic's existing support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy also describes the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.


30(a).9. Role of the Network Operations Centre (NOC)

In addition to its role in managing and operating CentralNic's infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.


30(a).10. Information Security Team

CentralNic maintains an Information Security Team (IST) to proactively manage information security. The IST is a cross-functional team from relevant areas of CentralNic. These key members of staff are responsible for cascading rules, regulations and information to their respective departments. They are also the first port of call for their departmental staff to report potential security incidences and breaches, the IST are all members of an internal email group used to co-ordinate and discuss security related issues.

The IST is comprised of the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.

IST responsibilities include:

*Review and monitor information security threats and incidents.

*Approve initiatives and methodologies to enhance information security.

*Agree and review the security policy, objectives and responsibilities.

*Review client requirements concerning information security.

*Promote the visibility of business support for information security company-wide.

*Manage changes to 3rd party services that may impact on Information Security

*Perform internal audits with the assistance of Blackmores.


30(a).11 Auditing and Review

ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. The IST periodically reviews the ISMS and conducts a gap analysis, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work.


30(a).12. Testing of Controls and Procedures

CentralNic will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both "black box" testing of public registry services such as Whois and the Registrar Console, "grey box" testing of authenticated services such as EPP, and tests of physical security at CentralNic's offices and facilities.

CentralNic will retain the services of a reputable security testing company such as SecureData (who, as MIS-CDS, performed the 2009 assessment of CentralNic's security stance). The results of this test will be used in annual reviews and audits of the ISMS.


30(a).13.Webera Inc. Security Policy

In addition to the security of our technical back-end by CentralNic, we will implement the following security measures in our offices:

As explained earlier, some of our functions are outsourced to the Directi Group. The Directi Group operates offices across Mumbai, India and UAE. The office building has a 24⁄7 alarm system and cameras throughout the building, with a full view of entry and exits to the main areas.  All critical physical and digital file storage areas are also closely monitored with controlled access.

The office doors are only accessible with access cards provided to employees. All entries and exits are recorded by the system. Access cards are de-activated as part of the employee discontinuation policy.

Access to sensitive areas are controlled by the electronic access control system managed by the IT team.

The facility is designed to have 100% power backup in case of a power failure. Currently, we have generators which are capable of providing power backup to critical requirements like servers, workstations & lights for atleast 48 hours.

With regards to our company systems and network security, we have adopted the following policies and processes:

Password Policy:We have policies and procedures to manage the creating, changing, and safeguarding of passwords.

*A password cannot contain your User Name and cannot match your first or last name

*A password must contain at least eight characters, and contain at least one alphabetic character and one number

*The last three passwords cannot be re-used when changing to a new password

*Account lockout after 8 failed login attempts, reset only possible after logging a ticket to internal IT help desk team

*Passwords are force-changed every quarter

 

Systems Security Policy:

*We use well-known Anti-Virus/Malware tools that constantly run scans during off peak hours and are updated on a regular basis

*Automatic Screen locking systems for idle users to prevent unauthorized access

*Hard disk encryption with domain login password preventing data duplication if the hard drive is attached to a different system

*Access to information that is deemed sensitive, requires the input of the employee’s password in conjunction with the password of a member from senior management

*Password protected BIOS in each system preventing any hardware level tampering

*Phishing/Malware sites blocked on all browsers by our Internet Security tools

*Unauthorized software is blocked and only while-listed after proper business justification and approvals

*We have an internal process to back-up critical data on a regular basis

*Redundancy for our all Critical Applications and Servers is ensured

 

Network Security Policy:

*The default passwords are always reset on all network devices

*Firewall is configured to block outbound traffic from VLAN workgroups or entire network segments that have no business establishing client connections to internet servers

*Requests to our internal servers are blocked unless authorized explicitly

*Our wireless network is encrypted using a signed certificate

*VPN traffic is encrypted using a CA signed certificate

*DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports

*Inbound Internet traffic is limited to servers in DMZ zone only

*Servers that store data are on an internal network zone are segregated from the DMZ and other untrusted networks

*We occasionally run intruder detection tests to identify insecure services/protocols/ports

*We have processes to ensure that ios/firmware/patches to switches/firewall/routers are updated regularly

*Tests are run regularly to ensure the internet redundancy links are working fine on our edge routers

 

Intranet Security Policy:

*Constant collaboration with leading security vendors and experts on specific threats

*Internal Mails (Webmail, SMTP, POP3, IMAP) are only accessible via VPN

*Internal Mail over mobile device is password protected screen locks with remote wipe supported if the device is lost

*Penetrating tests for each system (including virtual machine/network device) are run to check for weak passwords and security vulnerabilities

*SSO (Single Sign On) login for all our internal sites only work over our VPN

*Security audit logs are archived for a year

*Revoking all privileges and re-setting access details as part of the employee discontinuation process

*Some of the monitoring tools we use internally are:

*Cacti

*Nagios

*Zenoss

*Pingdom

*Whats up gold

*Observium

 

We are and will continue to be working with CentralNic and other security experts to enhance physical and network security measures in addition to policy development and employee training.

Given that the string is a generic TLD that does not propose to offer unique security policies beyond those detailed; we will not be making specific security commitments to our registrants. We trust that we will become known for providing a safe and secure platform for individuals and companies.

 


This completes our response to Q30(a).



© Internet Corporation For Assigned Names and Numbers.