ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Oracle Corporation

String: java

Originally Posted: 13 June 2012

Application ID: 1-1785-88138


Applicant Information


1. Full legal name

Oracle Corporation

2. Address of the principal place of business

500 Oracle Parkway
Redwood City CA 94065
US

3. Phone number

+1 650 506 7000

4. Fax number

+1 650 506 7200

5. If applicable, website or URL

http:⁄⁄www.oracle.com

Primary Contact


6(a). Name

Marilyn Tiki Dare

6(b). Title

Managing Counsel

6(c). Address


6(d). Phone Number

+1 650 506 1071

6(e). Fax Number

+1 650 506 7114

6(f). Email Address

tiki.dare@oracle.com

Secondary Contact


7(a). Name

Charles Hoynowski

7(b). Title

Senior Security Operations Engineer

7(c). Address


7(d). Phone Number

+1650 222 6993

7(e). Fax Number

+1650 716 4719

7(f). Email Address

charles.hoynowski@oracle.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Corporation

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

Delaware, United States

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.

NASDAQ;ORCL

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

Bruce Richard ChizenMember, Board of Directors
Donald Leo LucasMember, Board of Directors
Dr. Michael Jay BoskinMember, Board of Directors
George Henry ConradesMember, Board of Directors
Heber Raymond BinghamMember, Board of Directors
Hector Garcia-MolinaMember, Board of Directors
Jeffrey BergMember, Board of Directors
Jeffrey Owen HenleyChairman, Board of Directors
Mark Vincent HurdPresident; Member, Board of Directors
Naomi Ostriker SeligmanMember, Board of Directors
Safra Ada CatzPresident; CFO; Member, Board of Directors

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

Dorian Estelle DaleySenior Vice President, General Counsel, Secretary
John FowlerExecutive Vice President, Systems
Thomas KurianExecutive Vice President, Product Development
William Corey WestSenior Vice President, Corporate Controller, Chief Accounting Officer

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

Lawrence Joseph EllisonCEO; Member, Board of Directors

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.

java

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


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


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


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


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


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


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


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

Attachments are not displayed on this form.

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


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


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

The .java string and A-Label were developed in line with and checked against the eligibility, stability and policy criteria as stated in the ICANN Applicant Guidebook - version 2012-01-11. The results of those checks are as follows:

	- The string has less than 63 characters;

	- The string in ASCII is composed of three or more visually distinct characters;

	- The ASCII label consists entirely of letters;

	- The string is not a reserved name as shown in section 2.2.1.2.1 - Reserved Names of the ICANN Applicant Guidebook - version 2012-01-11; and

	- .java is not identical or similar to any of the top 10 invalid TLD’s responsible for the majority of DNS pollution, as referenced in the Security and Stability Advisory Committee (SSAC)’s report on this topic at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac045.pdf. It is likely that the .java has not already been queried with meaningful frequency at the root. Therefore, it is unlikely that .java will inherit significant invalid query traffic.


Due to the positive results of these checks, Oracle Corporation does not believe that the .java gTLD will be subject to any operational or rendering problems.



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


Mission/Purpose


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

1. QUESTION 18(A): DESCRIBE THE MISSION⁄PURPOSE OF YOUR PROPOSED GTLD.

1.1 INTRODUCTION

The mission and purpose of the proposed .JAVA Top Level Domain (TLD) is the creation and operation of a TLD dedicated to the Applicantʹs JAVA business, brands, trade marks, goods and service. As such the objective is that the .JAVA TLD will serve as an official, trusted, secure and dedicated name space for the globally renowned JAVA brand and services. To this end the Applicant seeks to launch the .JAVA TLD and to create and operate an innovative and secure platform in a manner which is consistent with its subject matter whilst committing to the promotion of competition, consumer trust, consumer protection and integrity of the .JAVA TLD and the associated Internet space.

The Applicant is committed to ensure that it fully complies and meets or exceeds the requirements of ICANN in terms of competition, consumer protection, security, stability and resiliency, malicious abuse issues, sovereignty concerns, and rights protection in relation to the expansion of the generic Top Level
Domain name space by devising and implementing mechanisms in line with ICANN’s Consensus Policies and Temporary Policies.

The Applicant proposes to launch and operate the .JAVA TLD to create a new Internet ecosystem dedicated to the Applicant and to enable and facilitate innovations, creation and promotion of new initiatives, platforms, applications and ventures from the Applicant and its Affiliates. The domain name space associated with the .JAVA TLD will create a new environment which will enhance diversity, choice and utility of the Domain Name System, based on a segmented approach, hence encouraging specialisation, differentiation, consumer recognition, and consumer choice in line with ICANN policy development.

In order to ensure the integrity, success and to build confidence in the .JAVA TLD and the associated domain name space, the Applicant is dedicated to ensuring that appropriate safeguards are put in place with a view to protecting, among other things, public interest, consumers, trade mark owners and other third party rights owners.

Operating and overseeing this new Internet space in a transparent, fair and efficient manner will be essential to create goodwill in the .JAVA TLD and to develop confidence and trust in the .JAVA TLD.

The fact that the Applicant intends to operate the .JAVA TLD as a single registrant⁄single user registry model will allow the Applicant and its Affiliates to control the operations of the .JAVA TLD and prevent violation of public interest, trade mark infringement and other types of malicious conducts. The .JAVA TLD will thus create an environment where opportunities for abuse and malevolent conduct will be virtually eliminated.

Furthermore, the Applicant is dedicated to ensuring that the creation and operation of the .JAVA TLD will not have an adverse or negative effect on the operational security and stability of the Internet and the Domain Name System with regard to the proposed registry services under the .JAVA TLD.

The .JAVA TLD will be a continuously evolving platform and serve as a base for continuously evolving uses, contents and services with a view to optimising specialisation, high level of service, content quality and reliability, consumer trust and innovation.

The Applicant has considered potential uses of the .JAVA TLD which would include allocating second-level domain names that correspond with:


1. The specialisation areas of the Applicant and its Affiliates:

- DEVELOPERS.JAVA

2. Internal management and information:

- LEGAL.JAVA

3. Investor relations and corporate portal:

- INVESTOR.JAVA

These are some of the potential uses which have been identified as being in line with the operation of the proposed .JAVA TLD following the single registrant⁄single user registry model. In addition, the Applicant and its Affiliates will actively use and continue to explore new ways of ensuring that the .JAVA TLD is an environment prone to innovation, consumer choice and recognition, business visibility and specialisation and may in this respect implement additional types of use of the .JAVA TLD within the scope of the Registry Agreement to be executed before delegation of the .JAVA TLD.


1.2 BACKGROUND TO THE ORACLE BUSINESS AND JAVA

The Applicant is the Oracle Corporation, a publicly traded corporation in good standing and listed on NASDAQ Stock Market LLC, ticker ORCL, created in 1977 with its headquarters at 500 Oracle Parkway Redwood Shores, CA 94065, United States of America.

Oracle is the gold standard for database technology and applications in enterprises throughout the world. The Applicant is the worldʹs leading supplier of information management software and the worldʹs second largest independent software company. Oracleʹs complete portfolio of servers, storage, software, and networking products are engineered to work together to deliver performance, simplified management, and cost-saving efficiencies.

One of the key offerings of the Applicant is Java, the software programming language and computing platform.

Java is the foundation for virtually every type of networked application and is the global standard for developing and delivering mobile applications, games, Web-based content, and enterprise software. To date, the Java platform has attracted more than 9 million software developers. Itʹs used in every major industry segment and has a presence in a wide range of devices, computers, and networks.

Java enables users to efficiently develop and deploy exciting applications and services. With comprehensive tooling, a mature ecosystem, and robust performance, Java delivers applications portability across even the most disparate computing environments.

As a result Java is currently one of the most popular programming languages in use, particularly for client-server web applications. It is the underlying technology that powers state-of-the-art programs including utilities, games, and business applications. Java runs on more than 850 million personal computers worldwide, and on more than 3 billion devices worldwide, including mobile and TV devices.


1.3 THE JAVA BRAND, TRADE MARKS, DOMAIN NAMES AND GLOBAL GOODWILL AND REPUTATION

The term JAVA is registered as a trade mark worldwide in many classes of goods and services including computers, computer hardware, computer software (all in International class 9), electronics including mobile phones, personal digital assistants, digital cameras, smart cards and readers, kiosks, set top boxes, digital television products, (in class 9), boats and automobiles in class 12, and a wide array of computer- and software-related goods and services, as well as for user manuals and related printed materials in class 16 and merchandise.

Oracle’s JAVA trade mark registrations include the entire class heading in class 9, and computer related services in classes 35 (business and advertising, trade shows), 36 (financing), 37 (repair and installation), 38 (transmission of data over the internet), 41 (training), 42 (programming, consulting, information resources on the internet) and 45 (computer related security).

The Applicant has secured numerous trade mark registrations in the term JAVA in 148 countries and territories.

The explosive popularity and consumer recognition of the JAVA brand due to its proliferation across multiple technologies and uses makes it instantly recognisable as one of the Applicantʹs premium brands. Reflecting its global reach, the Applicant owns numerous domain names consisting of or comprising the term JAVA in most available gTLDs and ccTLDs.
The JAVA brand, trade marks and domain names are invaluable assets and serve to identify the JAVA business as a trusted source of the highest quality goods and services globally.

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

2. QUESTION 18(B): HOW DO YOU EXPECT THAT YOUR PROPOSED GTLD WILL BENEFIT REGISTRANTS, INTERNET USERS AND OTHERS?

The main goals of the .JAVA TLD are specialisation, visibility, differentiation, innovation and enhancement of consumer recognition and trust.

Given the intended mission and purpose for the .JAVA TLD, the volume of second level domain name registrations will not be a pertinent indicator to assess or measure its success. The Applicant will rather focus and strive to achieve a high level of consumer recognition and trust in the .JAVA TLD.

Operating and overseeing this new dedicated Internet space in a transparent, fair and efficient manner will be a key factor in creating goodwill in the .JAVA TLD that will match the reputation the Applicant has via its globally recognised brand. As a result Internet users and customers of Oracle will come to have the same levels of confidence and trust in the .JAVA TLD.

The creation of a dedicated Internet name space which is indelibly associated with the Oracle brand assurance of quality, will create a clear benefit to Internet users and to the Applicant and its Affiliates as it will establish certainty and trust as to the source of the content.

2.1 18(b)(1): WHAT IS THE GOAL OF YOUR PROPOSED GTLD IN TERMS OF AREAS OF SPECIALTY, SERVICE LEVELS, OR REPUTATION?

(a) GOALS IN TERMS OF SPECIALITY

The creation and operation of the .JAVA TLD will create specialisation by creating a segment of the Domain Name System solely dedicated to the Applicantʹs technology under the JAVA brand.

Currently there is no Top Level Domain that specifically corresponds to the Applicant and to its businesses, brands, trade marks, technologies, goods and services. Thus no existing Top Level Domain could conceivably deliver the level of specialisation which could potentially be achieved by the .JAVA TLD.

Based on the significant goodwill and consumer recognition that the Applicant has acquired and developed in the term JAVA, it is anticipated that the .JAVA TLD will, by association, clearly and visibly demonstrate the specialised nature of the .JAVA TLD resulting in consumer recognition and trust. Internet users will know that they are getting genuine information and be able to access content, information and services relating to the Applicant by virtue of the .JAVA TLD.

Specialisation is a key element for the Applicant and for the proposed creation and operation of the .JAVA TLD. It is anticipated that this drive for specialisation will in the future become the standard for Internet users, customers and other third parties. As such the .JAVA TLD will provide a defined, unique and clear indication to Internet users that the .JAVA domain name space is one that is dedicated to the Applicant.

Therefore, the .JAVA TLD will be designed as a single source dedicated segment of the Internet and the Domain Name System where it will be possible to locate and access data in an efficient manner relating to the products and services of the Applicant and its Affiliates with the same level of trust which the Applicantʹs customers place in the Applicantʹs brand, all within a secure environment.


(b) GOALS IN TERMS OF SERVICE LEVELS

The Applicant is fully committed to providing the highest levels of service in the course of the operation of the .JAVA TLD. Security is one of the cornerstones of the Applicantʹs business and as a result of this the Applicant and its Affiliates have extensive experience in data related and online security issues and would seek to deploy this experience in the .JAVA TLD.

Given the Applicantʹs commitments in terms of service levels associated with the .JAVA TLD, the Applicant has entered into contractual agreements for the provision of services by third party service providers who are all leaders in their respective fields of activity. Thus the Applicant is seeking to ensure that both its internal resources and third party service providers have the capacity to achieve the highest levels of service performance in the course of the operation of the .JAVA TLD.

A key goal of the Applicant in the operation of the .JAVA TLD will be to provide services in a highly secure environment so as to significantly reduce opportunities for malicious conduct. As the Applicant intends to operate the .JAVA TLD following the single registrant⁄single user registry model, the Applicant will be able to fully control operation of the .JAVA TLD and to ensure that services will be provided through the .JAVA TLD in a secured, reliable and trusted manner.


(c) GOALS IN TERMS OF REPUTATION

The Applicant will use best endeavours to ensure that it operates the .JAVA TLD in a manner that furthers its excellent global reputation in terms of quality of content and service, security and compliance.

The Applicant has acquired and constantly developed reputation and goodwill in its JAVA brand and services worldwide through continuous and significant investment, use and effort.

Thus, the creation, delegation and operation of the .JAVA TLD will be consistent with the Applicantʹs continuously increasing use of its JAVA brand and will allow the Applicant to further promote the Applicant and its Affiliates’ reputation for excellence, technological advancement, innovation and specialisation.

Given the increasing importance of the Internet and related applications as part of the Applicantʹs business and services, for instance as a result of the development of cloud computing, creating and operating a dedicated segment of the Internet is of utmost importance to the Applicant, its Affiliates and their credibility and reputation.

As the Applicant intends to operate the .JAVA TLD following the single registrant⁄single user registry model, the Applicant will be able to fully control and oversee operation of the .JAVA TLD. As a result, the .JAVA TLD will by its very nature be associated with trusted and genuine content which will help the Applicant furthering the development of its reputation and consumer recognition in its JAVA brand. Whilst the very nature of the .JAVA TLD will help avoiding abuse and infringements, the Applicant is fully committed to address potential abuses and infringements in a timely and efficient manner if and when they occur.


2.2 18(b)(2): WHAT DO YOU ANTICIPATE YOUR PROPOSED GTLD WILL ADD TO THE CURRENT SPACE, IN TERMS OF COMPETITION, DIFFERENTIATION, OR INNOVATION?

(a) GOALS IN TERMS OF COMPETITION

The .JAVA TLD will contribute to the creation of a more competitive Domain Name System by operating a Top Level Domain dedicated to a particular commercial entity and thus incentivising competitors to position themselves on this new market in order not to lose ground to the Applicant and its Affiliates and to potentially provide new services or content or existing services or content in new ways.

Thus the Applicant will contribute by its .JAVA TLD initiative to the development of dedicated and specialised segments of the Domain Name Space and the diversification of content and services available on the Internet.

The .JAVA TLD initiative, the specialisation, innovation and high level of consumer recognition and trust that the Applicant and its Affiliates anticipate to achieve through the .JAVA TLD will likely trigger a reaction from other economic agents and thus indirectly lead to the creation and availability of new and improved resources, products, services, and contents on the Internet.

Thus, the creation and operation of the .JAVA TLD will benefit consumers by fostering innovation, competition, diversity of content and availability of specialised choices for consumers.


(b) GOALS IN TERMS OF DIFFERENTIATION

The .JAVA TLD will be operated on a single registrant⁄single user registry model and second level domain names will be reserved for exclusive registration by the Applicant for the exclusive use of the Applicant and its Affiliates.

The .JAVA TLD will, by its very nature, be highly distinctive and differentiated from all other Top Level Domains currently available and likely to be available in the future because it will be comprised of the Applicantʹs globally renowned and distinctive JAVA brand.

Thus the .JAVA TLD will clearly and officially indicate to users the source of the TLD.

The .JAVA TLD and all second level domain name registrations under it will act as a clear corporate identifier of the source of the dedicated services or contents.

Therefore, differentiation will be achieved in three ways:

- At the Top Level

- At the second level

- Through dedicated content


(c) GOALS IN TERMS OF INNOVATION

The Applicant and its Affiliates have established a reputation as one of the leading global companies in the field of technological innovation and the Applicantʹs purpose in applying for the .JAVA TLD is to pursue further innovation and technological advancement through a new dedicated platform based on the creation of the .JAVA TLD.

The .JAVA TLD will serve as a base for allowing the Applicant and its Affiliates to provide their products and services to each other, their consumers and Internet users in innovative and diverse ways.

The .JAVA TLD will be a new technological ecosystem for the Applicant and its Affiliates to take their mission of innovation further.


2.3 18(b)(3): WHAT GOALS DOES YOUR PROPOSED GTLD HAVE IN TERMS OF USER EXPERIENCE?

Given that the Applicant will operate and oversee the .JAVA TLD on a single registrant⁄single user registry model, user experience will in this context refer to two types of use:

(a) Exclusive use by the Applicant and its Affiliates

The Applicant will design a platform within the .JAVA TLD which will allow the Applicant and its Affiliates to use this dedicated segment of the Internet in rationalised and unprecedented ways and allow access, experience, exchange, provision and updating of content and information.

Only the Applicant and its Affiliates will have the possibility to alter content with respect to domain names, to manage domain names and to take other actions necessary for the maintenance of domain names under the .JAVA TLD.

(b) Passive use by third parties

While the exclusive use of the .JAVA TLD will be reserved for the Applicant and its Affiliate, other users will be able to access content, information and services within the .JAVA TLD.

The .JAVA TLD will provide a single, genuine, secure and trusted ecosystem where users worldwide will be able to experience and access content, information and services relating to the Applicant and its Affiliates. The specialisation and visibility of the .JAVA TLD as the dedicated Top Level Domain of the Oracle Corporationʹs JAVA brand and will provide considerable legitimacy and recognition to the .JAVA TLD and thus be an online landmark for users worldwide.

By virtue of operating its own dedicated TLD registry this will enable the Applicant to ensure a high degree of content quality and integrity which should result in an optimal user experience within the new .JAVA dedicated segment of the Internet name space.


2.4 18(b)(4): PROVIDE A COMPLETE DESCRIPTIN OF THE APPLICANTʹS INTENDED REGISTRATION POLICIES IN SUPPORT OF THE GOALS LISTED ABOVE

The Applicant intends to create and operate the .JAVA TLD as a single registrant⁄single user registry and will reserve domain names under the .JAVA TLD for exclusive registration by the Applicant to the exclusion of other parties. Thus it will not be possible for individuals or entities who are not the Applicant to register domain names under the .JAVA TLD.

In addition, the Applicant does not intend to sell, distribute or transfer control or use of any second level domain name registrations in the .JAVA TLD to any party that is not an Affiliate of the Applicant as defined in the Draft New gTLD Registry Agreement in section 2.9 (c) version 2012-01-11.

As a result, rules and regulations aiming at protecting the public interest in the event of the opening of a TLD to general registration will not be relevant.

Accordingly the intended registration policies in support of the goals set out in the Applicantʹs .JAVA TLD application will not contain provisions relating to registration by parties that are not the Applicant who will solely and wholly control and maintain registrations under the .JAVA TLD.

Such policies will be consistent with all applicable ICANN’s Consensus Policies and Temporary Policies and the Applicant is committed to ensure that said policies are strictly complied with.


2.5 18(b)(5): WILL YOUR PROPOSED GTLD IMPOSE ANY MEASURES FOR PROTECTION THE PRIVACY OR CONFIDENTIAL INFORMATION OF REGISTRANTS OR USERS?

Given that the Applicant will operate the .JAVA TLD on a single registrant⁄single user registry model, confidential information relating to the sole registrant (the Applicant) and exclusive users (the Applicant and its Affiliates) will be the responsibility of the Applicant and its Affiliates and will be addressed by existing internal policies implemented within the Applicantʹs organisation.

In relation to the information on users who will access content, information and services within the .JAVA TLD, the Applicant will ensure that the operation of the .JAVA TLD is at all times consistent with the Applicantʹs various privacy policies which are tailored for the different ways personal information is collected by different lines of business and offerings within the Applicant organisation.

The details of said policies are available at the following URL http:⁄⁄www.oracle.com⁄us⁄legal⁄privacy⁄index.html and a summary of the principles contained in said policies are copied below:

ʺOracle Corporation and our subsidiaries and affiliates (ʺOracleʺ or ʺweʺ) respect your preferences concerning the treatment of personal information that we may collect from your use of the Oracle.com Web sites and your interactions with Oracle off-line. This policy lets you know how we collect and use your personal information, and how you can control its use. This policy describes the broadest potential use of personal information throughout the Oracle.com Web sites and in off-line transactions; however, we may make far less use of your personal information.

Because Oracle lines of business and offerings collect and use personal information in different ways, Oracle has established separate privacy policies that govern those different activities. The following privacy policies are specifically tailored to the relevant line of business or offering, and are separate and distinct from the activities governed by this privacy policy:

The services privacy policy addresses customer data to which we may be provided access in order to perform consulting, product support, outsourcing and other services.

The recruiting privacy policy addresses information we may collect in connection with Oracleʹs employment recruiting efforts.

The Exchange.Oracle.com privacy policy addresses information shared in an online commercial trading community.

The Profit Magazine and Oracle Magazine privacy policy addresses information we collect from subscribers to these publications.

The Oracle.com Web sites provide links to non-Oracle sites we believe may be of interest to you. Those sites are beyond our control. You are advised to check the privacy policies and terms of use of any non-Oracle sites before providing your personal information to them.ʺ


2.6 18(b)(6): DESCRIBE WHETHER AND IN WHAT WAYS OUTREACH AND COMMUNICATIONS WILL HELP TO ACHIEVE YOUR PROJECTED BENEFITS

It is anticipated that the use made of the .JAVA TLD will continuously evolve so as to ensure adaptation and innovation mirroring market trends, consumer demand and fostering technological advancement.

As the Applicant identifies new demands, needs, innovative and beneficial types of uses, the Applicant will implement new types of use of the .JAVA TLD.
Communication on the .JAVA TLD and the services that it will offer will be crucial and the Applicant and its Affiliates will make extensive use of its substantial in-house capabilities and experience. In addition, the Applicant and its Affiliates will use preferred third party service providers if necessary to ensure efficient and visible communication, promotion and public information on the .JAVA TLD and on the content, information and services available within this dedicated segment of the Internet.

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

3. QUESTION 18(C) 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?

Given that the Applicant intends to operate the .JAVA TLD as a single registrant⁄single user registry, the Applicant will be the only registrant of second level domain names under the .JAVA TLD to the exclusion of any other entity or individual.

In light of the intended structure and operating model of the .JAVA TLD, the Applicant does not anticipate that its Top Level Domain will have any known negative consequences or cost implications to consumers.

The .JAVA TLD operating model which will be based on the Applicant and its Affiliatesʹ sole control should actually create an environment with an unprecedented level of security, consumer trust, consumer protection, content quality and reliable indication of source.

3.1 18(c)(1): HOW WILL MULTIPLE APPLICATIONS FOR A PARTICULAR DOMAIN NAME BE RESOLVED, FOR EXAMPLE, BY AUCTION OR ON A FIRST-COME ⁄ FIRST-SERVE BASIS?

The Applicant will be the only registrant of second level domain names under the .JAVA TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .JAVA TLD, the Applicant does not anticipate that the scenario of multiple applications for a particular domain name could ever occur.

In view of the above, it is neither necessary nor pertinent within the context of the .JAVA TLD to implement mechanisms to resolve multiple applications for a particular domain name.

For the sake of completeness, should the Applicant, after the delegation of the .JAVA TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms to ensure resolution of multiple applications for a particular domain name in the most transparent and fair manner and in accordance with all applicable ICANN’s Consensus Policies and Temporary Policies.


3.2 18(c)(2): EXPLAIN ANY COST BENEFITS FOR REGISTRANTS YOU INTEND TO IMPLEMENT

The Applicant will be the only registrant of second level domain names under the .JAVA TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .JAVA TLD, there are no cost benefits to implement for registrants given that the only registrant under the .JAVA TLD will be the Applicant.

In view of the above, it is neither necessary nor pertinent within the context of the .JAVA TLD to implement any cost benefits for registrants.

For the sake of completeness, should the Applicant, after the delegation of the .JAVA TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms to achieve cost benefits for registrants in the most transparent and fair manner and in accordance with all applicable ICANN’s Consensus Policies and Temporary Policies.


3.3 18(c)(3): CONTRACTUAL COMMITMENTS TO REGISTRANTS REGARDING MAGNITUDE OF PRICE ESCALATION

The Applicant will be the only registrant of second level domain names under the .JAVA TLD to the exclusion of any other entity or individual.

Given the closed nature of the proposed single registrant⁄single user registry model for the .JAVA TLD, contractual commitments to registrants regarding price escalation will not be relevant to the Applicant’s mission or goals for the .JAVA TLD.
In view of the above, it is neither necessary nor pertinent within the context of the .JAVA TLD to implement the types of mechanisms contemplated by question 18(c)(3).

For the sake of completeness, should the Applicant, after the delegation of the .JAVA TLD, wish to apply to ICANN for a modification of its single registrant⁄single user registry model, then the Applicant undertakes that it will implement appropriate mechanisms in order to comply with the Registry Agreement and all applicable ICANN’s Consensus Policies and Temporary Policies.

Community-based Designation


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

No

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


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


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


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


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


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

Attachments are not displayed on this form.

Geographic Names


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

No

Protection of Geographic Names


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

Oracle Corporation is not currently planning to utilise geographic names at the second and other levels in the applied-for gTLD. However, and notwithstanding the absence of geographic names in Oracle Corporation’s forward planning and use intentions, Oracle Corporation has considered the requirements necessary should it, at a later date, seek to obtain ICANN approval for the use of geographic names as follows:


REGISTRY AGREEMENT - SPECIFICATION 5 CRITERIA

§2 The reservation of two-character label string may be released to the extent that Registry Operator reaches agreement with the government and the country-code manager. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country names.

§5 the reservation of specific country and territory names may be released to the extent that the Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN.


Oracle Corporation generally respects and abides by the GAC’s Principles regarding New gTLDs, dated March 28, 2007. In particular, Oracle Corporation adheres to and⁄or intends to adhere to the recommendations directed towards new registry operators in Sections 2.1, 2.4, 2.7(b). On the other hand, Oracle Corporation assumes that several of the recommendations directed towards new registry operators, in general, are less applicable in the case of Single-Registrant operational models such as .java than in an completely open Registry model. These include without limitation Sections 2.2, 2.3, 2.7(a) and 2.9.

In order to comply with the requirements of the Registry Agreement, Specification 5, and as with all other domains in the .java TLD, all Two-character labels (§2) and Country and Territory Names (§5) will be initially reserved. However, Oracle Corporation believes that the use of geographic terms can provide great benefit and simplicity to internet users because these terms are intuitive ways to resolve to Oracle Corporation’s content that is specifically relevant and targeted to users in the particular geographic region and in line with local customs, laws and regulations. The use of the geographic terms will be valuable to internet users because they can be reassured that the content that they are viewing is relevant to their local situation thus mitigating the risk of unnecessary user confusion.

Oracle Corporation intends to use any Two-character label and⁄or Country or Territory Name domains in Oracle Corporation’s discretion, and to participate in or implement a process by which any Government may reasonably object to that use. Oracle Corporation envisions a number of possible scenarios for ensuring Government agreement to the use of Country and Territory names. These will be explored in detail with ICANN and the Governmental Advisory Committee to ensure a mutually agreeable solution. Scenarios range from at a minimum; Oracle Corporation informing the Chair of the Governmental Advisory Committee (GAC) to ICANN in writing of its proposed use of geographic terms and provide Governments who wish to do so with an opportunity to block the use of their relevant name in the .java TLD. Other plausible scenarios would include;


SCENARIO 1 (LETTER TO GAC)

In advance of any use of geographical names Oracle Corporation will send a letter to the chair of the Governmental Advisory Committee (GAC) informing the GAC of its intention to use geographical names in the .java TLD. The letter will outline the reasons for using geographical names and provide Governments with the opportunity to contact Oracle Corporation within 90 days to reserve their respective geographical name from use in the TLD. Should a Government inform Oracle Corporation that it wishes to reserve the use of their respective geographical name, the name will remain reserved for the duration of Oracle Corporation’s registry agreement with ICANN. The opportunity to reserve a name will be offered to Governments free of charge.


SCENARIO 2 (LETTER INFORMING INDIVIDUAL GOVERNMENTS)

In advance of any use of geographical names Oracle Corporation will send a letter to the Government concerned and inform it of Oracle Corporation’s intention to use geographical names in the .java TLD. The letter will outline the reasons for using geographical names and provide the Government with the opportunity to contact Oracle Corporation within 90 days to reserve its respective geographical name from use in the TLD. Should the Government inform Oracle Corporation that it wishes to reserve the use of its respective geographical name, the name will remain reserved for the duration of Oracle Corporation’s registry agreement with ICANN. The opportunity to reserve a name will be offered to the Government free of charge.


SCENARIO 3 (LETTER REQUESTING PERMISSION FROM INDIVIDUAL GOVERNMENT)

In advance of any use of geographical names Oracle Corporation will send a letter to the Government concerned and inform it of Oracle Corporation’s intention to use geographical names in the .java TLD. The letter will outline the reasons for using geographical names and request the Government’s approval or non-objection to the proposed use of the geographical name. Should the Government not respond to the Oracle Corporation within 90 days, Oracle Corporation will understand this to mean that the Government does not object to Oracle Corporation’s proposed use of the geographical name. However should the Government at a later stage contact Oracle Corporation and request that the geographical name no longer be used, Oracle Corporation will work in good faith with the Government to try to find a mutually agreeable solution.

Alternatively: However should the Government at a later stage contact Oracle Corporation and request that the geographical name no longer be used, Oracle Corporation will work in good faith with the Government to try to find a mutually agreeable solution. If such a solution cannot be found Oracle Corporation will respect the Government’s wishes and reserve the name from use without cost to the Government concerned.

Generally, it is extremely unlikely that Oracle Corporation’s tightly controlled use of any cc.java or countryname.java domain name could be confusing or detrimental to users, or otherwise offensive to any country. Nor is it likely to be detrimental to the operator of a country code top level domain. To the extent that use of any .java domain was ever deemed confusing or offensive, Oracle Corporation has a strong desire to resolve the situation quickly and respectfully to any affected Government’s sovereign interests. Oracle Corporation will ensure that its designated abuse contact is aware of the additional sensitivities that may potentially arise with respect to use of cc.java or countryname.java domains, such that any complaints of this nature are prioritized accordingly. Oracle Corporation will not use geographic names until ICANN has approved such use.








Registry Services


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

23 REGISTRY SERVICES


1 CUSTOMARY REGISTRY SERVICES

Oracle Corporation (Oracle) has engaged Melbourne IT Limited and its affiliate entities (Melbourne IT) as a service provider to assist Oracle with this application and on-going management of its .java gTLD, should this application be successful.  Melbourne IT’s managed services incorporate the management and oversight of Oracle’s selected backend registry services provider, Verisign Inc (Verisign), as well as other third party service providers.

As Oracle’s selected provider of backend registry services, Verisign provides a comprehensive system and physical security solution that is designed to ensure a TLD is protected from unauthorized disclosure, alteration, insertion, or destruction of registry data. Verisign’s system addresses all areas of security including information and policies, security procedures, the systems development lifecycle, physical security, system hacks, break-ins, data tampering, and other disruptions to operations. Verisign’s operational environments not only meet the security criteria specified in its customer contractual agreements, thereby preventing unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with applicable standards, but also are subject to multiple independent assessments as detailed in the response to Question 30, Security Policy. Verisign’s physical and system security methodology follows a mature, ongoing lifecycle that was developed and implemented many years before the development of the industry standards with which Verisign currently complies. Please see the response to Question 30, Security Policy, for details of the security features of Verisign’s registry services.

Verisign’s registry services fully comply with relevant standards and best current practice RFCs published by the Internet Engineering Task Force (IETF), including all successor standards, modifications, or additions relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472. Moreover, Verisign’s Shared Registration System (SRS) supports the following IETF Extensible Provisioning Protocol (EPP) specifications, where the Extensible Markup Language (XML) templates and XML schemas are defined in RFC 3915, 5730, 5731, 5732, 5733, and 5734. By strictly adhering to these RFCs, Verisign helps to ensure its registry services do not create a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems. Besides its leadership in authoring RFCs for EPP, Domain Name System Security Extensions (DNSSEC), and other DNS services, Verisign has created and contributed to several now well-established IETF standards and is a regular and long-standing participant in key Internet standards forums.

Figure 23-1 summarizes the technical and business components of those registry services, customarily offered by a registry operator (i.e., Verisign), that support this application. These services are currently operational and support both large and small Verisign-managed registries. Customary registry services are provided in the same manner as Verisign provides these services for its existing gTLDs.

Through these established registry services, Verisign has proven its ability to operate a reliable and low-risk registry that supports millions of transactions per day. Verisign is unaware of any potential security or stability concern related to any of these services.

Registry services defined by this application are not intended to be offered in a manner unique to the new generic top-level domain (gTLD) nor are any proposed services unique to this application’s registry.

As further evidence of Verisign’s compliance with ICANN mandated security and stability requirements, Verisign allocates the applicable RFCs to each of the five customary registry services (items A – E above). For each registry service, Verisign also provides evidence in Figure 23-2of Verisign’s RFC compliance and includes relevant ICANN prior-service approval actions.



1.1 CRITICAL OPERATIONS OF THE REGISTRY


i. RECEIPT OF DATA FROM REGISTRARS CONCERNING REGISTRATION OF DOMAIN NAMES AND NAME SERVERS

See Item A in Figure 23-1 and Figure 23-2.



ii. PROVISION TO REGISTRARS STATUS INFORMATION RELATING TO THE ZONE SERVERS

Verisign is Oracle’s selected provider of backend registry services. Verisign registry services provisions to registrars status information relating to zone servers for the TLD. The services also allow a domain name to be updated with clientHold, serverHold status, which removes the domain name server details from zone files. This ensures that DNS queries of the domain name are not resolved temporarily. When these hold statuses are removed, the name server details are written back to zone files and DNS queries are again resolved. Figure 23-3 describes the domain name status information and zone insertion indicator provided to registrars. The zone insertion indicator determines whether the name server details of the domain name exist in the zone file for a given domain name status. Verisign also has the capability to withdraw domain names from the zone file in near-real time by changing the domain name statuses upon request by customers, courts, or legal authorities as required.



iii. DISSEMINATION OF TLD ZONE FILES

See Item B in Figure 23-1 and Figure 23-2.



iv. OPERATION OF THE REGISTRY ZONE SERVERS

Verisign is Oracle’s selected provider of backend registry services. Verisign, as a company, operates zone servers and serves DNS resolution from 76 geographically distributed resolution sites located in North America, South America, Africa, Europe, Asia, and Australia. Currently, 17 DNS locations are designated primary sites, offering greater capacity than smaller sites comprising the remainder of the Verisign constellation. Verisign also uses Anycast techniques and regional Internet resolution sites to expand coverage, accommodate emergency or surge capacity, and support system availability during maintenance procedures. Verisign operates Oracle’s gTLD from a minimum of eight of its primary sites (two on the East Coast of the United States, two on the West Coast of the United States, two in Europe, and two in Asia) and expands resolution sites based on traffic volume and patterns. Further details of the geographic diversity of Verisign’s zone servers are provided in the response to Question 34, Geographic Diversity. Moreover, additional details of Verisign’s zone servers are provided in the response to Question 32, Architecture and the response to Question 35, DNS Service.



v. DISSEMINATION OF CONTACT AND OTHER INFORMATION CONCERNING DOMAIN NAME SERVER REGISTRATIONS

See Item C in Figure 23-1andFigure 23-2.



2 OTHER PRODUCTS OR SERVICES THE REGISTRY OPERATOR IS REQUIRED TO PROVIDE BECAUSE OF THE ESTABLISHMENT OF A CONSENSUS POLICY

Verisign, Oracle’s selected provider of backend registry services, is a proven supporter of ICANN’s consensus-driven, bottom-up policy development process whereby community members identify a problem, initiate policy discussions, and generate a solution that produces effective and sustained results. Verisign currently provides all of the products or services (collectively referred to as services) that the registry operator is required to provide because of the establishment of a Consensus Policy. For the .java gTLD, Verisign implements these services using the same proven processes and procedures currently in-place for all registries under Verisign’s management. Furthermore, Verisign executes these services on computing platforms comparable to those of other registries under Verisign’s management. Verisign’s extensive experience with consensus policy required services and its proven processes to implement these services greatly minimize any potential risk to Internet security or stability. Details of these services are provided in the following subsections. It shall be noted that consensus policy services required of registrars (e.g., Whois Reminder, Expired Domain) are not included in this response. This exclusion is in accordance with the direction provided in the question’s Notes column to address registry operator services.



2.1 INTER-REGISTRAR TRANSFER POLICY (IRTP)


TECHNICAL COMPONENT:

In compliance with the IRTP consensus policy, Verisign, Oracle’s selected provider of backend registry services, has designed its registration systems to systematically restrict the transfer of domain names within 60 days of the initial create date. In addition, Verisign has implemented EPP and “AuthInfo” code functionality, which is used to further authenticate transfer requests. The registration system has been designed to enable compliance with the five-day Transfer grace period and includes the following functionality:

- Allows the losing registrar to proactively ‘ACK’ or acknowledge a transfer prior to the expiration of the five-day Transfer grace period

- Allows the losing registrar to proactively ‘NACK’ or not acknowledge a transfer prior to the expiration of the five-day Transfer grace period

- Allows the system to automatically ACK the transfer request once the five-day Transfer grace period has passed if the losing registrar has not proactively ACK’d or NACK’d the transfer request.



BUSINESS COMPONENT:

All requests to transfer a domain name to a new registrar are handled according to the procedures detailed in the IRTP. Dispute proceedings arising from a registrarʹs alleged failure to abide by this policy may be initiated by any ICANN-accredited registrar under the Transfer Dispute Resolution Policy. Oracle’s compliance office serves as the first-level dispute resolution provider pursuant to the associated Transfer Dispute Resolution Policy. As needed Verisign is available to offer policy guidance as issues arise.


SECURITY AND STABILITY CONCERNS:

Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. By implementing the IRTP in accordance with ICANN policy, security is enhanced as all transfer commands are authenticated using the AuthInfo code prior to processing.


ICANN PRIOR APPROVAL:

Verisign has been in compliance with the IRTP since November 2004 and is available to support Oracle in a consulting capacity as needed.



UNIQUE TO THE TLD:

This service is not provided in a manner unique to the .java TLD.



2.2 ADD GRACE PERIOD (AGP) LIMITS POLICY


TECHNICAL COMPONENT:

Verisign’s registry system monitors registrars’ Add grace period deletion activity and provides reporting that permits Oracle to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, Oracle accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. Oracle maintains all AGP Limits Policy exemption request activity so that this material may be included within Oracle’s Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to Oracle for consideration. Oracle’s compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, Oracle submits associated reporting on exemption request activity to support reporting in accordance with established ICANN requirements.



BUSINESS COMPONENT:

The Add grace period (AGP) is restricted for any gTLD operator that has implemented an AGP. Specifically, for each operator:

- During any given month, an operator may not offer any refund to an ICANN-accredited registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations (calculated as the total number of net adds of one-year through ten-year registrations as defined in the monthly reporting requirement of Operator Agreements) in that month, or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted by an operator.

- Upon the documented demonstration of extraordinary circumstances, a registrar may seek from an operator an exemption from such restrictions in a specific month. The registrar must confirm in writing to the operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside the registrarʹs control. Acceptance of any exemption will be at the sole and reasonable discretion of the operator; however ʺextraordinary circumstancesʺ that reoccur regularly for the same registrar will not be deemed extraordinary.

In addition to all other reporting requirements to ICANN, Oracle identifies each registrar that has sought an exemption, along with a brief description of the type of extraordinary circumstance and the action, approval, or denial that the operator took.



SECURITY AND STABILITY CONCERNS: 

Verisign is unaware of any impact, caused by the policy, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems.



ICANN PRIOR APPROVAL:

Verisign, Oracle’s backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support Oracle in a consulting capacity as needed.



UNIQUE TO THE TLD:

This service is not provided in a manner unique to the .java TLD.



2.3 REGISTRY SERVICES EVALUATION POLICY (RSEP)


TECHNICAL COMPONENT:

Verisign, Oracle’s selected provider of backend registry services, adheres to all RSEP submission requirements. Verisign has followed the process many times and is fully aware of the submission procedures, the type of documentation required, and the evaluation process that ICANN adheres to.



BUSINESS COMPONENT:

In accordance with ICANN procedures detailed on the ICANN RSEP website (http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄), all gTLD registry operators are required to follow this policy when submitting a request for new registry services.



SECURITY AND STABILITY CONCERNS: 

As part of the RSEP submission process, Verisign, Oracle’s backend registry services provider, identifies any potential security and stability concerns in accordance with RSEP stability and security requirements. Verisign never launches services without satisfactory completion of the RSEP process and resulting approval.



ICANN PRIOR APPROVAL:

Not applicable.



UNIQUE TO THE TLD:

gTLD RSEP procedures are not implemented in a manner unique to the .java TLD.



3 PRODUCTS OR SERVICES ONLY A REGISTRY OPERATOR IS CAPABLE OF PROVIDING BY REASON OF ITS DESIGNATION AS THE REGISTRY OPERATOR

Verisign, Oracle’s selected backend registry services provider, has developed a Registry-Registrar Two-Factor Authentication Service that complements traditional registration and resolution registry services. In accordance with direction provided in Question 23, Verisign details below the technical and business components of the service, identifies any potential threat to registry security or stability, and lists previous interactions with ICANN to approve the operation of the service. The Two-Factor Authentication Service is currently operational, supporting multiple registries under ICANN’s purview.

Oracle is unaware of any competition issue that may require the registry service(s) listed in this response to be referred to the appropriate governmental competition authority or authorities with applicable jurisdiction. ICANN previously approved the service(s), at which time it was determined that either the service(s) raised no competitive concerns or any applicable concerns related to competition were satisfactorily addressed.



3.1 TWO-FACTOR AUTHENTICATION SERVICE


TECHNICAL COMPONENT:

The Registry-Registrar Two-Factor Authentication Service is designed to improve domain name security and assist registrars in protecting the accounts they manage. As part of the service, dynamic one-time passwords augment the user names and passwords currently used to process update, transfer, and⁄or deletion requests. These one-time passwords enable transaction processing to be based on requests that are validated both by “what users know” (i.e., their user name and password) and “what users have” (i.e., a two-factor authentication credential with a one-time-password).

Registrars can use the one-time-password when communicating directly with Verisign’s Customer Service department as well as when using the registrar portal to make manual updates, transfers, and⁄or deletion transactions. The Two-Factor Authentication Service is an optional service offered to registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement.



BUSINESS COMPONENT:

There is no charge for the Registry-Registrar Two-Factor Authentication Service. It is enabled only for registrars that wish to take advantage of the added security provided by the service.



SECURITY AND STABILITY CONCERNS:

Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. The service is intended to enhance domain name security, resulting in increased confidence and trust by registrants.



ICANN PRIOR APPROVAL:

ICANN approved the same Two-Factor Authentication Service for Verisign’s use on .com and .net on 10 July 2009 (RSEP Proposal 2009004) and for .name on 16 February 2011 (RSEP Proposal 2011001).



UNIQUE TO THE TLD: 

This service is not provided in a manner unique to the .java TLD.



Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

24 SHARED REGISTRATION SYSTEM (SRS) PERFORMANCE

1 ROBUST PLAN FOR OPERATING A RELIABLE SRS

1.1 HIGH-LEVEL SHARED REGISTRATION SYSTEM (SRS) SYSTEM DESCRIPTION

Verisign, Oracle’s selected provider of backend registry services, provides and operates a robust and reliable SRS that enables multiple registrars to provide domain name registration services in the top-level domain (TLD). Verisign’s proven reliable SRS serves approximately 915 registrars, and Verisign, as a company, has averaged more than 140 million registration transactions per day. The SRS provides a scalable, fault-tolerant platform for the delivery of gTLDs through the use of a central customer database, a web interface, a standard provisioning protocol (i.e., Extensible Provisioning Protocol, EPP), and a transport protocol (i.e., Secure Sockets Layer, SSL).

The SRS components include:

- Web Interface: Allows customers to access the authoritative database for accounts, contacts, users, authorization groups, product catalog, product subscriptions, and customer notification messages.

- EPP Interface: Provides an interface to the SRS that enables registrars to use EPP to register and manage domains, hosts, and contacts.

- Authentication Provider: A Verisign developed application, specific to the SRS, that authenticates a user based on a login name, password, and the SSL certificate common name and client IP address.

The SRS is designed to be scalable and fault tolerant by incorporating clustering in multiple tiers of the platform. New nodes can be added to a cluster within a single tier to scale a specific tier, and if one node fails within a single tier, the services will still be available. The SRS allows registrars to manage the .java gTLD domain names in a single architecture.

To flexibly accommodate the scale of its transaction volumes, as well as new technologies, Verisign employs the following design practices:

- Scale for Growth: Scale to handle current volumes and projected growth.

- Scale for Peaks: Scale to twice base capacity to withstand “registration add attacks” from a compromised registrar system.

- Limit Database CPU Utilization: Limit utilization to no more than 50 percent during peak loads.

- Limit Database Memory Utilization: Each user’s login process that connects to the database allocates a small segment of memory to perform connection overhead, sorting, and data caching. Verisign’s standards mandate that no more than 40 percent of the total available physical memory on the database server will be allocated for these functions.

Verisign’s SRS is built upon a three-tier architecture as illustrated in Figure 24-1 and detailed here:

- Gateway Layer: The first tier, the gateway servers, uses EPP to communicate with registrars. These gateway servers then interact with application servers, which comprise the second tier.

- Application Layer: The application servers contain business logic for managing and maintaining the registry business. The business logic is particular to each TLD’s business rules and requirements. The flexible internal design of the application servers allows Verisign to easily leverage existing business rules to apply to the .java gTLD. The application servers store Oracle’s data in the registry database, which comprises the third and final tier. This simple, industry-standard design has been highly effective with other customers for whom Verisign provides backend registry services.

- Database Layer: The database is the heart of this architecture. It stores all the essential information provisioned from registrars through the gateway servers. Separate servers query the database, extract updated zone and Whois information, validate that information, and distribute it around the clock to Verisign’s worldwide domain name resolution sites.

SCALABILITY AND PERFORMANCE. Verisign, Oracle’s selected backend registry services provider, implements its scalable SRS on a supportable infrastructure that achieves the availability requirements in Specification 10. Verisign employs the design patterns of simplicity and parallelism in both its software and systems, based on its experience that these factors contribute most significantly to scalability and reliable performance. Going counter to feature-rich development patterns, Verisign intentionally minimizes the number of lines of code between the end user and the data delivered. The result is a network of restorable components that provide rapid, accurate updates. Figure 24-2 depicts EPP traffic flows and local redundancy in Verisign’s SRS provisioning architecture. As detailed in the figure, local redundancy is maintained for each layer as well as each piece of equipment. This built-in redundancy enhances operational performance while enabling the future system scaling necessary to meet additional demand created by this or future registry applications.

Besides improving scalability and reliability, local SRS redundancy enables Verisign to take down individual system components for maintenance and upgrades, with little to no performance impact. With Verisign’s redundant design, Verisign can perform routine maintenance while the remainder of the system remains online and unaffected. For the .java gTLD registry, this flexibility minimizes unplanned downtime and provides a more consistent end-user experience.


1.2 REPRESENTATIVE NETWORK DIAGRAMS

Figure 24-3 provides a summary network diagram of Oracle’s selected backend registry services provider’s (Verisign’s) SRS. This configuration at both the primary and alternate-primary Verisign data centers provides a highly reliable backup capability. Data is continuously replicated between both sites to ensure failover to the alternate-primary site can be implemented expeditiously to support both planned and unplanned outages.


1.3 NUMBER OF SERVERS

As Oracle’s selected provider of backend registry services, Verisign continually reviews its server deployments for all aspects of its registry service. Verisign evaluates usage based on peak performance objectives as well as current transaction volumes, which drive the quantity of servers in its implementations. Verisign’s scaling is based on the following factors:

- Server configuration is based on CPU, memory, disk IO, total disk, and network throughput projections.

- Server quantity is determined through statistical modeling to fulfill overall performance objectives as defined by both the service availability and the server configuration.

- To ensure continuity of operations for the .java gTLD, Verisign uses a minimum of 100 dedicated servers per SRS site. These servers are virtualized to meet demand.


1.4 DESCRIPTION OF INTERCONNECTIVITY WITH OTHER REGISTRY SYSTEMS

Figure 24-4 provides a technical overview of the Oracle’s selected backend registry services provider’s (Verisign’s) SRS, showing how the SRS component fits into this larger system and interconnects with other system components.


1.5 FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS

As Oracle’s selected provider of backend registry services, Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. This synchronization is performed in near-real time, thereby supporting rapid failover should a failure occur or a planned maintenance outage be required.


1.6 SYNCHRONIZATION SCHEME

Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. Because the alternate-primary site is continuously up, and built using an identical design to the primary data center, it is classified as a “hot standby.”


2 SCALABILITY AND PERFORMANCE ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .java gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.


3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Verisign, the Oracle’s selected provider of backend registry services, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services provided to Oracle fully accounts for this personnel-related cost, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support SRS performance:

- Application Engineers: 19

- Database Administrators: 8

- Database Engineers: 3

- Network Administrators: 11

- Network Architects: 4

- Project Managers: 25

- Quality Assurance Engineers: 11

- SRS System Administrators: 13

- Storage Administrators: 4

- Systems Architects: 9

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.


4 EVIDENCE OF COMPLIANCE WITH SPECIFICATION 6 AND 10 TO THE REGISTRY AGREEMENT

SECTION 1.2 (EPP) OF SPECIFICATION 6, REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS.

Verisign, Oracle’s selected backend registry services provider, provides these services using its SRS, which complies fully with Specification 6, Section 1.2 of the Registry Agreement. In using its SRS to provide backend registry services, Verisign implements and complies with relevant existing RFCs (i.e., 5730, 5731, 5732, 5733, 5734, and 5910) and intends to comply with RFCs that may be published in the future by the Internet Engineering Task Force (IETF), including successor standards, modifications, or additions thereto relating to the provisioning and management of domain names that use EPP. In addition, Verisign’s SRS includes a Registry Grace Period (RGP) and thus complies with RFC 3915 and its successors. Details of the Verisign SRS’ compliance with RFC SRS⁄EPP are provided in the response to Question 25, Extensible Provisioning Protocol. Verisign does not use functionality outside the base EPP RFCs, although proprietary EPP extensions are documented in Internet-Draft format following the guidelines described in RFC 3735 within the response to Question 25. Moreover, prior to deployment, Oracle will provide to ICANN updated documentation of all the EPP objects and extensions supported in accordance with Specification 6, Section 1.2.

SPECIFICATION 10, EPP REGISTRY PERFORMANCE SPECIFICATIONS.

Verisign’s SRS meets all EPP Registry Performance Specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .com and .net Registry Operator’s Monthly Reports, which Verisign files with ICANN. These reports detail Verisign’s operational status of the .com and .net registries, which use an SRS design and approach comparable to the one proposed for the .java gTLD. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with EPP Registry Performance Specifications detailed in Specification 10, Verisignʹs SRS meets the following performance attributes:

- EPP service availability: ≤ 864 minutes of downtime (≈98%)

- EPP session-command round trip time (RTT): ≤4000 milliseconds (ms), for at least 90 percent of the commands

- EPP query-command RTT: ≤2000 ms, for at least 90 percent of the commands

- EPP transform-command RTT: ≤4000 ms, for at least 90 percent of the commands



25. Extensible Provisioning Protocol (EPP)

25 EXTENSIBLE PROVISIONING PROTOCOL (EPP)

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign, Oracle’s selected backend registry services provider, has used Extensible Provisioning Protocol (EPP) since its inception and possesses complete knowledge and understanding of EPP registry systems. Its first EPP implementation— for a thick registry for the .name generic top-level domain (gTLD)—was in 2002. Since then Verisign has continued its RFC-compliant use of EPP in multiple TLDs, as detailed in Figure 25-1.

Verisign’s understanding of EPP and its ability to implement code that complies with the applicable RFCs is unparalleled. Mr. Scott Hollenbeck, Verisign’s director of software development, authored the Extensible Provisioning Protocol and continues to be fully engaged in its refinement and enhancement (U.S. Patent Number 7299299 – Shared registration system for registering domain names). Verisign has also developed numerous new object mappings and object extensions following the guidelines in RFC 3735 (Guidelines for Extending the Extensible Provisioning Protocol). Mr. James Gould, a principal engineer at Verisign, led and co-authored the most recent EPP Domain Name System Security Extensions (DNSSEC) RFC effort (RFC 5910).

All registry systems for which Verisign is the registry operator or provides backend registry services use EPP. Upon approval of this application, Verisign will use EPP to provide the backend registry services for this gTLD. The .com, .net, and .name registries for which Verisign is the registry operator use an SRS design and approach comparable to the one proposed for this gTLD. Approximately 915 registrars use the Verisign EPP service, and the registry system performs more than 140 million EPP transactions daily without performance issues or restrictive maintenance windows. The processing time service level agreement (SLA) requirements for the Verisign-operated .net gTLD are the strictest of the current Verisign managed gTLDs. All processing times for Verisign-operated gTLDs can be found in ICANN’s Registry Operator’s Monthly Reports at http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

Verisign has also been active on the Internet Engineering Task Force (IETF) Provisioning Registry Protocol (provreg) working group and mailing list since work started on the EPP protocol in 2000. This working group provided a forum for members of the Internet community to comment on Mr. Scott Hollenbeck’s initial EPP drafts, which Mr. Hollenbeck refined based on input and discussions with representatives from registries, registrars, and other interested parties. The working group has since concluded, but the mailing list is still active to enable discussion of different aspects of EPP.


1.1 EPP INTERFACE WITH REGISTRARS

Verisign, Oracle’s selected backend registry services provider, fully supports the features defined in the EPP specifications and provides a set of software development kits (SDK) and tools to help registrars build secure and stable interfaces. Verisign’s SDKs give registrars the option of either fully writing their own EPP client software to integrate with the Shared Registration System (SRS), or using the Verisign-provided SDKs to aid them in the integration effort. Registrars can download the Verisign EPP SDKs and tools from the registrar website (http:⁄⁄www.Verisign.com⁄domain-name-services⁄current-registrars⁄epp-sdk⁄index.html).

The EPP SDKs provide a host of features including connection pooling, Secure Sockets Layer (SSL), and a test server (stub server) to run EPP tests against. One tool—the EPP tool—provides a web interface for creating EPP Extensible Markup Language (XML) commands and sending them to a configurable set of target servers. This helps registrars in creating the template XML and testing a variety of test cases against the EPP servers. An Operational Test and Evaluation (OT&E) environment, which runs the same software as the production system so approved registrars can integrate and test their software before moving into a live production environment, is also available.


2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .java gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.


3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the provisioning of EPP services:

- Application Engineers: 19

- Database Engineers: 3

- Quality Assurance Engineers: 11

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed TLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.


4 ABILITY TO COMPLY WITH RELEVANT RFCS

Verisign, Oracle’s selected backend registry services provider, incorporates design reviews, code reviews, and peer reviews into its software development lifecycle (SDLC) to ensure compliance with the relevant RFCs. Verisign’s dedicated QA team creates extensive test plans and issues internal certifications when it has confirmed the accuracy of the code in relation to the RFC requirements. Verisign’s QA organization is independent from the development team within engineering. This separation helps Verisign ensure adopted processes and procedures are followed, further ensuring that all software releases fully consider the security and stability of the TLD.

For the .java gTLD, the Shared Registration System (SRS) complies with the following IETF EPP specifications, where the XML templates and XML schemas are defined in the following specifications:

- EPP RGP 3915 (http:⁄⁄www.apps.ietf.org⁄rfc⁄rfc3915.html): EPP Redemption Grace Period (RGP) Mapping specification for support of RGP statuses and support of Restore Request and Restore Report (authored by Verisign’s Scott Hollenbeck)

- EPP 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730): Base EPP specification (authored by Verisign’s Scott Hollenbeck)

- EPP Domain 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731): EPP Domain Name Mapping specification (authored by Verisign’s Scott Hollenbeck)

- EPP Host 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732): EPP Host Mapping specification (authored by Verisign’s Scott Hollenbeck)

- EPP Contact 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733): EPP Contact Mapping specification (authored by Verisign’s Scott Hollenbeck)

- EPP TCP 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734): EPP Transport over Transmission Control Protocol (TCP) specification (authored by Verisign’s Scott Hollenbeck)

- EPP DNSSEC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910): EPP Domain Name System Security Extensions (DNSSEC) Mapping specification (authored by Verisign’s James Gould and Scott Hollenbeck)


5 PROPRIETARY EPP EXTENSIONS

Verisign, Oracle’s selected backend registry services provider, uses its SRS to provide registry services. The SRS supports the following EPP specifications, which Verisign developed following the guidelines in RFC 3735, where the XML templates and XML schemas are defined in the specifications:

- IDN Language Tag (http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf): EPP internationalized domain names (IDN) language tag extension used for IDN domain name registrations

- RGP Poll Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP mapping for an EPP poll message in support of Restore Request and Restore Report

- Whois Info Extension (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP extension for returning additional information needed for transfers

- EPP ConsoliDate Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt): EPP mapping to support a Domain Sync operation for synchronizing domain name expiration dates

- NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf): EPP extension for routing with an EPP intelligent gateway to a pluggable set of backend products and services

- Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf): EPP mapping to support low balance poll messages that proactively notify registrars of a low balance (available credit) condition

As part of the 2006 implementation report to bring the EPP RFC documents from Proposed Standard status to Draft Standard status, an implementation test matrix was completed. Two independently developed EPP client implementations based on the RFCs were tested against the Verisign EPP server for the domain, host, and contact transactions. No compliance-related issues were identified during this test, providing evidence that these extensions comply with RFC 3735 guidelines and further demonstrating Verisign’s ability to design, test, and deploy an RFC-compliant EPP implementation.


5.1 EPP TEMPLATES AND SCHEMAS

The EPP XML schemas are formal descriptions of the EPP XML templates. They are used to express the set of rules to which the EPP templates must conform in order to be considered valid by the schema. The EPP schemas define the building blocks of the EPP templates, describing the format of the data and the different EPP commands’ request and response formats. The current EPP implementations managed by Verisign, Oracle’s selected backend registry services provider, use these EPP templates and schemas, as will the proposed TLD. For each proprietary XML template⁄schema Verisign provides a reference to the applicable template and includes the schema.


XML TEMPLATES⁄SCHEMA FOR IDNLANG-1.0

- Template: The templates for idnLang-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf.


- Schema is set out in Figure 25-2
This schema describes the extension mapping for the IDN language tag. The mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN domain name registrations.


XML TEMPLATES⁄SCHEMA FOR RGP-POLL-1.0

- Template: The templates for rgp-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄rgp-poll-mapping.pdf.


- Schema is set out in Figure 25-3:
This schema describes the extension mapping for poll notifications. The mapping extends the EPP base mapping to provide additional features for registry grace period (RGP) poll notifications.


XML TEMPLATES⁄SCHEMA FOR WHOISINF-1.0

- Template: The templates for whoisInf-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf.


- Schema is set out in Figure 25-4:
This schema describes the extension mapping for the Whois Info extension. The mapping extends the EPP domain name mapping to provide additional features for returning additional information needed for transfers.


XML TEMPLATES⁄SCHEMA FOR SYNC-1.0 (CONSOLIDATE)

- Template: The templates for sync-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt.

- Schema is set out in Figure 25-5:
This schema describes the extension mapping for the synchronization of domain name registration period expiration dates. This service is known as ʺConsoliDate.ʺ The mapping extends the EPP domain name mapping to provide features that allow a protocol client to end a domain name registration period on a specific month and day.


XML TEMPLATES⁄SCHEMA FOR NAMESTOREEXT-1.1

- Template: The templates for namestoreExt-1.1 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf.


- Schema is set out in Figure 25-6:
This schema describes the extension mapping for the routing with an EPP intelligent gateway to a pluggable set of backend products and services. The mapping extends the EPP domain name and host mapping to provide a sub-product identifier to identify the target sub-product that the EPP operation is intended for.


XML TEMPLATES⁄SCHEMA FOR LOWBALANCE-POLL-1.0

- Template: The templates for lowbalance-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf.


- Schema is set out in Figure 25-7:
This schema describes the extension mapping for the account low balance notification. The mapping extends the EPP base mapping so an account holder can be notified via EPP poll messages whenever the available credit for an account reaches or goes below the credit threshold.


6 PROPRIETARY EPP EXTENSION CONSISTENCY WITH REGISTRATION LIFECYCLE

Oracle’s selected backend registry services provider’s (Verisign’s) proprietary EPP extensions, defined in Section 5 above, are consistent with the registration lifecycle documented in the response to Question 27, Registration Lifecycle. Details of the registration lifecycle are presented in that response. As new registry features are required, Verisign develops proprietary EPP extensions to address new operational requirements. Consistent with ICANN procedures Verisign adheres to all applicable Registry Services Evaluation Process (RSEP) procedures.

26. Whois

26 WHOIS


1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign, Oracle’s selected backend registry services provider, has operated the Whois lookup service for the gTLDs and ccTLDs it manages since 1991, and will provide these proven services for the .java gTLD registry. In addition, it continues to work with the Internet community to improve the utility of Whois data, while thwarting its application for abusive uses.



1.1 HIGH-LEVEL WHOIS SYSTEM DESCRIPTION

Like all other components of Oracle’s selected backend registry services provider’s (Verisign’s) registry service, Verisign’s Whois system is designed and built for both reliability and performance in full compliance with applicable RFCs. Verisign’s current Whois implementation has answered more than five billion Whois queries per month for the TLDs it manages, and has experienced more than 250,000 queries per minute in peak conditions. The proposed gTLD uses a Whois system design and approach that is comparable to the current implementation. Independent quality control testing ensures Verisign’s Whois service is RFC-compliant through all phases of its lifecycle.

Verisignʹs redundant Whois databases further contribute to overall system availability and reliability. The hardware and software for its Whois service is architected to scale both horizontally (by adding more servers) and vertically (by adding more CPUs and memory to existing servers) to meet future need.

Verisign can fine-tune access to its Whois database on an individual Internet Protocol (IP) address basis, and it works with registrars to help ensure their services are not limited by any restriction placed on Whois. Verisign provides near real-time updates for Whois services for the TLDs under its management. As information is updated in the registration database, it is propagated to the Whois servers for quick publication. These updates align with the near real-time publication of Domain Name System (DNS) information as it is updated in the registration database. This capability is important for the .java gTLD registry as it is Verisign’s experience that when DNS data is updated in near real time, so should Whois data be updated to reflect the registration specifics of those domain names.

Verisign’s Whois response time has been less than 500 milliseconds for 95 percent of all Whois queries in .com, .net, .tv, and .cc. The response time in these TLDs, combined with Verisign’s capacity, enables the Whois system to respond to up to 30,000 searches (or queries) per second for a total capacity of 2.6 billion queries per day.

The Whois software written by Verisign complies with RFC 3912. Verisign uses an advanced in-memory database technology to provide exceptional overall system performance and security. In accordance with RFC 3912, Verisign provides a website at whois.nic.〈TLD〉 that provides free public query-based access to the registration data.

Verisign currently operates both thin and thick Whois systems.

Verisign commits to implementing a RESTful Whois service upon finalization of agreements with the IETF (Internet Engineering Task Force).



PROVIDED FUNCTIONALITIES FOR USER INTERFACE

To use the Whois service via port 43, the user enters the applicable parameter on the command line as illustrated here:

- For domain name: whois EXAMPLE.TLD

- For registrar: whois ʺregistrar Example Registrar, Inc.ʺ

- For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the Whois service via the web-based directory service search interface:

- Go to http:⁄⁄whois.nic.〈TLD〉

- Click on the appropriate button (Domain, Registrar, or Name Server)

- Enter the applicable parameter:

- Domain name, including the TLD (e.g., EXAMPLE.TLD)

- Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)

- Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)

- Click on the Submit button.



PROVISIONS TO ENSURE THAT ACCESS IS LIMITED TO LEGITIMATE AUTHORIZED USERS AND IS IN COMPLIANCE WITH APPLICABLE PRIVACY LAWS OR POLICIES

To further promote reliable and secure Whois operations, Verisign, Oracle’s selected backend registry services provider, has implemented rate-limiting characteristics within the Whois service software. For example, to prevent data mining or other abusive behavior, the service can throttle a specific requestor if the query rate exceeds a configurable threshold. In addition, QoS technology enables rate limiting of queries before they reach the servers, which helps protect against denial of service (DoS) and distributed denial of service (DDoS) attacks.

Verisign’s software also permits restrictions on search capabilities. For example, wild card searches can be disabled. If needed, it is possible to temporarily restrict and⁄or block requests coming from specific IP addresses for a configurable amount of time. Additional features that are configurable in the Whois software include help files, headers and footers for Whois query responses, statistics, and methods to memory map the database. Furthermore, Verisign is European Union (EU) Safe Harbor certified and has worked with European data protection authorities to address applicable privacy laws by developing a tiered Whois access structure that requires users who require access to more extensive data to (i) identify themselves, (ii) confirm that their use is for a specified purpose and (iii) enter into an agreement governing their use of the more extensive Whois data.



1.2 RELEVANT NETWORK DIAGRAMS

Figure 26-1 provides a summary network diagram of the Whois service provided by Verisign, Oracle’s selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For the .java gTLD Verisign provides Whois service from 6 of its 17 primary sites based on the proposed gTLD’s traffic volume and patterns. A functionally equivalent resolution architecture configuration exists at each Whois site.



1.3 IT AND INFRASTRUCTURE RESOURCES

Figure 26-2 summarizes the IT and infrastructure resources that Verisign, Oracle’s selected backend registry services provider, uses to provision Whois services from Verisign primary resolution sites. As needed, virtual machines are created based on actual and projected demand.



1.4 DESCRIPTION OF INTERCONNECTIVITY WITH OTHER REGISTRY SYSTEMS

Figure 26-3 provides a technical overview of the registry system provided by Verisign, Oracle’s selected backend registry services provider, and shows how the Whois service component fits into this larger system and interconnects with other system components.


1.5 FREQUENCY OF SYNCHRONIZATION BETWEEN SERVERS

Synchronization between the SRS and the geographically distributed Whois resolution sites occurs approximately every three minutes. Verisign, Oracle’s selected backend registry services provider, uses a two-part Whois update process to ensure Whois data is accurate and available. Every 12 hours an initial file is distributed to each resolution site. This file is a complete copy of all Whois data fields associated with each domain name under management. As interactions with the SRS cause the Whois data to be changed, these incremental changes are distributed to the resolution sites as an incremental file update. This incremental update occurs approximately every three minutes. When the new 12-hour full update is distributed, this file includes all past incremental updates. Verisign’s approach to frequency of synchronization between servers meets the Performance Specifications defined in Specification 10 of the Registry Agreement for new gTLDs.



2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .java gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.



3 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support Whois services:

- Application Engineers: 19

- Database Engineers: 3

- Quality Assurance Engineers: 11

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.



4 COMPLIANCE WITH RELEVANT RFC

Oracle’s selected backend registry services provider’s (Verisign’s) Whois service complies with the data formats defined in Specification 4 of the Registry Agreement. Verisign will provision Whois services for registered domain names and associated data in the top-level domain (TLD). Verisign’s Whois services are accessible over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in accordance with RFC 3912, provides free public query-based access to domain name, registrar, and name server lookups. Verisign’s proposed Whois system meets all requirements as defined by ICANN for each registry under Verisign management. Evidence of this successful implementation, and thus compliance with the applicable RFCs, can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files with ICANN. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.



5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT

In accordance with Specification 4, Verisign, Oracle’s selected backend registry services provider, provides a Whois service that is available via both port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉 also in accordance with RFC 3912, thereby providing free public query-based access. Verisign acknowledges that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, Verisign will implement such alternative specification as soon as reasonably practicable.

The format of the following data fields conforms to the mappings specified in Extensible Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values returned in Whois responses) can be uniformly processed and understood: domain name status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date, and times.

Specifications for data objects, bulk access, and lookups comply with Specification 4 and are detailed in the following subsections, provided in both bulk access and lookup modes.



BULK ACCESS MODE.

This data is provided on a daily schedule to a party designated from time to time in writing by ICANN. The specification of the content and format of this data, and the procedures for providing access, shall be as stated below, until revised in the ICANN Registry Agreement.

The data is provided in three files:

- Domain Name File: For each domain name, the file provides the domain name, server name for each name server, registrar ID, and updated date.
- Name Server File: For each registered name server, the file provides the server name, each IP address, registrar ID, and updated date.

- Registrar File: For each registrar, the following data elements are provided: registrar ID, registrar address, registrar telephone number, registrar email address, Whois server, referral URL, updated date, and the name, telephone number, and email address of all the registrarʹs administrative, billing, and technical contacts.



LOOKUP MODE.

Figures 26-4 through Figure 26-6 provide the query and response format for domain name, registrar, and name server data objects.



5.1 SPECIFICATION 10, RDDS REGISTRY PERFORMANCE SPECIFICATIONS

The Whois service meets all registration data directory services (RDDS) registry performance specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files monthly with ICANN. These reports are accessible from the ICANN website at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄.

In accordance with RDDS registry performance specifications detailed in Specification 10, Verisignʹs Whois service meets the following proven performance attributes:
- RDDS availability: less than or equal to 864 min of downtime (is approximately equal to 98%)

- RDDS query RTT: less than or equal to 2000 ms, for at least 95% of the queries

- RDDS update time: less than or equal to 60 min, for at least 95% of the probes



6 SEARCHABLE WHOIS

Verisign, Oracle’s selected backend registry services provider, provides a searchable Whois service for the .java gTLD. Verisign has experience in providing tiered access to Whois for the .name registry, and uses these methods and control structures to help reduce potential malicious use of the function. The searchable Whois system currently uses Apache’s Lucene full text search engine to index relevant Whois content with near-real time incremental updates from the provisioning system.


Features of the Verisign searchable Whois function include:

- Provision of a web-based searchable directory service

- Ability to perform partial match, at least, for the following data fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state, or province)

- Ability to perform exact match, at least, on the following fields: registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records)

- Ability to perform Boolean search supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT

- Search results that include domain names that match the selected search criteria

Verisign’s implementation of searchable Whois is EU Safe Harbor certified and includes appropriate access control measures that help ensure that only legitimate authorized users can use the service. Furthermore, Verisign’s compliance office monitors current ICANN policy and applicable privacy laws or policies to help ensure the solution is maintained within compliance of applicable regulations. Features of these access control measures include:

- All unauthenticated searches are returned as thin results.

- Registry system authentication is used to grant access to appropriate users for thick Whois data search results.

- Account access is granted by the Oracle’s defined .java gTLD admin user.



POTENTIAL FORMS OF ABUSE AND RELATED RISK MITIGATION.

Leveraging its experience providing tiered access to Whois for the .name registry and interacting with ICANN, data protection authorities, and applicable industry groups, Verisign, Oracle’s selected backend registry services provider, is knowledgeable of the likely data mining forms of abuse associated with a searchable Whois service. Figure 26-7 summarizes these potential forms of abuse and Verisign’s approach to mitigate the identified risk.



27. Registration Life Cycle

27 REGISTRATION LIFECYCLE


1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF REGISTRATION LIFECYCLES AND STATES

Starting with domain name registration and continuing through domain name delete operations, Oracle’s selected backend registry services provider’s (Verisign’s) registry implements the full registration lifecycle for domain names supporting the operations in the Extensible Provisioning Protocol (EPP) specification. The registration lifecycle of the domain name starts with registration and traverses various states as specified in the following sections. The registry system provides options to update domain names with different server and client status codes that block operations based on the EPP specification. The system also provides different grace periods for different billable operations, where the price of the billable operation is credited back to the registrar if the billable operation is removed within the grace period. Together Figure 27-1 and Figure 27-2 define the registration states comprising the registration lifecycle and explain the trigger points that cause state-to-state transitions. States are represented as green rectangles within Figure 27-1.



1.1 REGISTRATION LIFECYCLE OF CREATE⁄UPDATE⁄DELETE

The following section details the create⁄update⁄delete processes and the related renewal process that Verisign, Oracle’s selected backend registry services provider, follows. For each process, this response defines the process function and its characterization, and as appropriate provides a process flow chart.



CREATE PROCESS.

The domain name lifecycle begins with a registration or what is referred to as a Domain Name Create operation in EPP. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.



PROCESS CHARACTERIZATION.

The Domain Name Create command is received, validated, run through a set of business rules, persisted to the database, and committed in the database if all business rules pass. The domain name is included with the data flow to the DNS and Whois resolution services. If no name servers are supplied, the domain name is not included with the data flow to the DNS. A successfully created domain name has the created date and expiration date set in the database. Creates are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.


The Domain Name Create operation is detailed in Figure 27-3 and requires the following attributes:

- A domain name that meets the string restrictions.

- A domain name that does not already exist.

- The registrar is authorized to create a domain name in .java.

- The registrar has available credit.

- A valid Authorization Information (Auth-Info) value.

- Required contacts (e.g., registrant, administrative contact, technical contact, and billing contact) are specified and exist.

- The specified name servers (hosts) exist, and there is a maximum of 13 name servers.

- A period in units of years with a maximum value of 10 (default period is one year).



RENEWAL PROCESS.

The domain name can be renewed unless it has any form of Pending Delete, Pending Transfer, or Renew Prohibited.

A request for renewal that sets the expiry date to more than ten years in the future is denied. The registrar must pass the current expiration date (without the timestamp) to support the idempotent features of EPP, where sending the same command a second time does not cause unexpected side effects.

Automatic renewal occurs when a domain name expires. On the expiration date, the registry extends the registration period one year and debits the registrar account balance. In the case of an auto-renewal of the domain name, a separate Auto-Renew grace period applies. Renewals are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.



PROCESS CHARACTERIZATION.

The Domain Name Renew command is received, validated, authorized, and run through a set of business rules. The data is updated and committed in the database if it passes all business rules. The updated domain name’s expiration date is included in the flow to the Whois resolution service.


The Domain Name Renew operation is detailed in Figure 27-4 and requires the following attributes:

- A domain name that exists and is sponsored by the requesting registrar.

- The registrar is authorized to renew a domain name in .java.

- The registrar has available credit.

- The passed current expiration date matches the domain name’s expiration date.

- A period in units of years with a maximum value of 10 (default period is one year). A domain name expiry past ten years is not allowed.



REGISTRAR TRANSFER PROCEDURES.

A registrant may transfer his⁄her domain name from his⁄her current registrar to another registrar. The database system allows a transfer as long as the transfer is not within the initial 60 days, per industry standard, of the original registration date.
The registrar transfer process goes through many process states, which are described in detail below, unless it has any form of Pending Delete, Pending Transfer, or Transfer Prohibited.
A transfer can only be initiated when the appropriate Auth-Info is supplied. The Auth-Info for transfer is only available to the current registrar. Any other registrar requesting to initiate a transfer on behalf of a registrant must obtain the Auth-Info from the registrant.

The Auth-Info is made available to the registrant upon request. The registrant is the only party other than the current registrar that has access to the Auth-Info. Registrar transfer entails a specified extension of the expiry date for the object. The registrar transfer is a billable operation and is charged identically to a renewal for the same extension of the period. This period can be from one to ten years, in one-year increments.

Because registrar transfer involves an extension of the registration period, the rules and policies applying to how the resulting expiry date is set after transfer are based on the renewal policies on extension.

Per industry standard, a domain name cannot be transferred to another registrar within the first 60 days after registration. This restriction continues to apply if the domain name is renewed during the first 60 days. Transfer of the domain name changes the sponsoring registrar of the domain name, and also changes the child hosts (ns1.sample.xyz) of the domain name (sample .xyz).


The domain name transfer consists of five separate operations:

- Transfer Request (Figure 27-5): Executed by a non-sponsoring registrar with the valid Auth-Info provided by the registrant. The Transfer Request holds funds of the requesting registrar but does not bill the registrar until the transfer is completed. The sponsoring registrar receives a Transfer Request poll message.

- Transfer Cancel (Figure 27-6): Executed by the requesting registrar to cancel the pending transfer. The held funds of the requesting registrar are reversed. The sponsoring registrar receives a Transfer Cancel poll message.

- Transfer Approve (Figure 27-7): Executed by the sponsoring registrar to approve the Transfer Request. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar receives a Transfer Approve poll message.

- Transfer Reject (Figure 27-8): Executed by the sponsoring registrar to reject the pending transfer. The held funds of the requesting registrar are reversed. The requesting registrar receives a Transfer Reject poll message.

- Transfer Query (Figure 27-9): Executed by either the requesting registrar or the sponsoring registrar of the last transfer.

The registry auto-approves a transfer if the sponsoring registrar takes no action. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar and the sponsoring registrar receive a Transfer Auto-Approve poll message.



DELETE PROCESS.

A registrar may choose to delete the domain name at any time.



PROCESS CHARACTERIZATION.

The domain name can be deleted, unless it has any form of Pending Delete, Pending Transfer, or Delete Prohibited.

A domain name is also prohibited from deletion if it has any in-zone child hosts that are name servers for domain names. For example, the domain name “sample.xyz” cannot be deleted if an in-zone host “ns.sample.xyz” exists and is a name server for “sample2.xyz.”

If the Domain Name Delete occurs within the Add grace period, the domain name is immediately deleted and the sponsoring registrar is credited for the Domain Name Create. If the Domain Name Delete occurs outside the Add grace period, it follows the Redemption grace period (RGP) lifecycle.



UPDATE PROCESS.

The sponsoring registrar can update the following attributes of a domain name:

- Auth-Info

- Name servers

- Contacts (i.e., registrant, administrative contact, technical contact, and billing contact)

- Statuses (e.g., Client Delete Prohibited, Client Hold, Client Renew Prohibited, Client Transfer Prohibited, Client Update Prohibited)



PROCESS CHARACTERIZATION.

Updates are allowed provided that the update includes the removal of any Update Prohibited status. The Domain Name Update operation is detailed in Figure 27-10.

A domain name can be updated unless it has any form of Pending Delete, Pending Transfer, or Update Prohibited.



1.2 PENDING, LOCKED, EXPIRED, AND TRANSFERRED

Verisign, Oracle’s selected backend registry services provider, handles pending, locked, expired, and transferred domain names as described here. When the domain name is deleted after the five-day Add grace period, it enters into the Pending Delete state. The registrant can return its domain name to active any time within the five-day Pending



DELETE GRACE PERIOD.

After the five-day Pending Delete grace period expires, the domain name enters the Redemption Pending state and then is deleted by the system. The registrant can restore the domain name at any time during the Redemption Pending state.

When a non-sponsoring registrar initiates the domain name transfer request, the domain name enters Pending Transfer state and a notification is mailed to the sponsoring registrar for approvals. If the sponsoring registrar doesn’t respond within five days, the Pending Transfer expires and the transfer request is automatically approved.

EPP specifies both client (registrar) and server (registry) status codes that can be used to prevent registry changes that are not intended by the registrant. Currently, many registrars use the client status codes to protect against inadvertent modifications that would affect their customers’ high-profile or valuable domain names.

Verisign’s registry service supports the following client (registrar) and server (registry) status codes:

- clientHold
- clientRenewProhibited
- clientTransferProhibited
- clientUpdateProhibited
- clientDeleteProhibited
- serverHold
- serverRenewProhibited
- serverTransferProhibited
- serverUpdateProhibited
- serverDeleteProhibited



1.3 ADD GRACE PERIOD, REDEMPTION GRACE PERIOD, AND NOTICE PERIODS FOR RENEWALS OR TRANSFERS

Verisign, Oracle’s selected backend registry services provider, handles Add grace periods, Redemption grace periods, and notice periods for renewals or transfers as described here.

- Add Grace Period: The Add grace period is a specified number of days following the initial registration of the domain name. The current value of the Add grace period for all registrars is five days.

- Redemption Grace Period: If the domain name is deleted after the five-day grace period expires, it enters the Redemption grace period and then is deleted by the system. The registrant has an option to use the Restore Request command to restore the domain name within the Redemption grace period. In this scenario, the domain name goes to Pending Restore state if there is a Restore Request command within 30 days of the Redemption grace period. From the Pending Restore state, it goes either to the OK state, if there is a Restore Report Submission command within seven days of the Restore Request grace period, or a Redemption Period state if there is no Restore Report Submission command within seven days of the Restore Request grace period.

- Renew Grace Period: The Renew⁄Extend grace period is a specified number of days following the renewal⁄extension of the domain name’s registration period. The current value of the Renew⁄Extend grace period is five days.

- Auto-Renew Grace Period: All auto-renewed domain names have a grace period of 45 days.

- Transfer Grace Period: Domain names have a five-day Transfer grace period.



1.4 ASPECTS OF THE REGISTRATION LIFECYCLE NOT COVERED BY STANDARD EPP RFCS

Oracle’s selected backend registry services provider’s (Verisign’s) registration lifecycle processes and code implementations adhere to the standard EPP RFCs related to the registration lifecycle. By adhering to the RFCs, Verisign’s registration lifecycle is complete and addresses each registration-related task comprising the lifecycle. No aspect of Verisign’s registration lifecycle is not covered by one of the standard EPP RFCs and thus no additional definitions are provided in this response.



2 CONSISTENCY WITH ANY SPECIFIC COMMITMENTS MADE TO REGISTRANTS AS ADAPTED TO THE OVERALL BUSINESS APPROACH FOR THE PROPOSED GTLD

The registration lifecycle described above applies to the .java gTLD as well as other TLDs managed by Verisign, Oracle’s selected backend registry services provider; thus Verisign remains consistent with commitments made to its registrants. No unique or specific registration lifecycle modifications or adaptations are required to support the overall business approach for the .java gTLD.

To accommodate a range of registries, Verisign’s registry implementation is capable of offering both a thin and thick Whois implementation, which is also built upon Verisign’s award-winning ATLAS infrastructure.



3 COMPLIANCE WITH RELEVANT RFCS

Oracle’s selected backend registry services provider’s (Verisign’s) registration lifecycle complies with applicable RFCs, specifically RFCs 5730 – 5734 and 3915. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.


In addition, in accordance with RFCs 5732 and 5733, the Verisign registration system enforces the following domain name registration constraints:
- Uniqueness⁄Multiplicity: A second-level domain name is unique in the .java database. Two identical second-level domain names cannot simultaneously exist in .java. Further, a second-level domain name cannot be created if it conflicts with a reserved domain name.

- Point of Contact Associations: The domain name is associated with the following points of contact. Contacts are created and managed independently according to RFC 5733.

- Registrant

- Administrative contact

- Technical contact

- Billing contact

- Domain Name Associations: Each domain name is associated with:

- A maximum of 13 hosts, which are created and managed independently according to RFC 5732

- An Auth-Info, which is used to authorize certain operations on the object

- Status(es), which are used to describe the domain name’s status in the registry

- A created date, updated date, and expiry date



4 DEMONSTRATES THAT TECHNICAL RESOURCES REQUIRED TO CARRY THROUGH THE PLANS FOR THIS ELEMENT ARE ALREADY ON HAND OR READILY AVAILABLE

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the registration lifecycle:

- Application Engineers: 19
- Customer Support Personnel: 36
- Database Administrators: 8
- Database Engineers: 3
- Quality Assurance Engineers: 11
- SRS System Administrators: 13

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

28. Abuse Prevention and Mitigation

A. ABUSE PREVENTION AND MITIGATION TO BE IMPLEMENTED BY ORACLE


Oracle’s proposed use for .java should, by its very nature, preclude abusive registrations from occurring, as all domains names may only be registered in the name of Oracle and its affiliates (for the purposes of this response, “affiliates” means in relation to a party any corporation or other business entity controlling, controlled by, or under common control of that party and for the purposes of this definition, a corporation or other business entity shall be deemed to control another corporation or business entity if it owns directly or indirectly (i) fifty percent (50%) or more of the voting securities or voting interest in any such corporation or other entity; or (ii) fifty percent (50%) or more of the interest in the profit or income in the case of a business entity other than a corporation; or (iii) in the case of a partnership, any other compatible interest equal to at least a fifty percent (50%) share in the general partner).

Oracle is intending to operate .java for the benefit of Internet users that would like to interact with Oracle. There is no incentive for Oracle to confuse Internet users, nor otherwise use domain names in bad faith, since Oracle’s branded keyword gTLD is inherently intertwined with all uses of .java domain names.

Notwithstanding the above, Oracle understands and agrees that it must comply with the different rights protection mechanisms such as the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS) as described in the gTLD Applicant Guidebook (as may be later amended via Consensus Policy) and the Registry Agreement. The aforementioned policies provide a strong incentive to ensure that relevant and effective checks are in place to ensure that all .java domain names are only registered and used in an appropriate manner so as to benefit Internet users who would like to interact with Oracle, rather than in any manner that may be deemed inappropriate or in bad faith.

Oracle will implement a clear written policy which requires the relevant corporate authorization and approvals to be procured and evidenced in order for any .java domain name to be registered for Oracle’s use. In the event that Oracle resolves to permit third parties (other than affiliates) that have a relationship with either Oracle or its business, to register (or license) and use domain names within the top level domain (TLD), then additional corporate authorizations and approvals may be required to ensure internal responsibility for permitting and enforcing the terms of use of the .java domain. In addition to these safeguards, all registered domain names in the TLD will be regularly monitored for abusive use.


B. .java ANTI-ABUSE POLICIES


Although domain names will only be registered to Oracle and its affiliates, all domain names will be subject to specific internal registration policy for .java domain. The registration policy will set out in writing a methodology for corporate authorization, approval and evidence in order for any domain name to be registered for Oracle’s use. This will prohibit any abusive use of a domain name. These policies include not only the required URS, but also the supplemental Anti-Phishing Takedown Process, Oracle’s Acceptable Use Policy, and Oracle’s strict controls on registration.


C. DEFINITION OF ABUSE


Oracle defines abuse as an action that causes actual and substantial harm, or is a material predicate of such harm, and is illegal, illegitimate, or otherwise contrary to registration policy. Abuse includes, without limitation, the following:

- Content or actions that attempt to defraud members of the public in any way (for example, ʺphishingʺ sites);

- Content that is hateful, defamatory, derogatory or bigoted based on racial, ethnic, political grounds or which otherwise may cause or incite injury, damage or harm of any kind to any person or entity;

- Content that is threatening or invades another personʹs privacy or property rights or is otherwise in breach of any duty owed to a third party;

- Content or actions that infringe the trademark, copyright, patent rights, trade secret or other intellectual property rights, or any other legal rights of Oracle or any third party;

- Content or actions that violate any applicable local, state, national or international law or regulation;

- Content or actions that promote, are involved in or assist in, the conduct of illegal activity of any kind or promote business opportunities or investments that are not permitted under applicable law;

- Content that advertises or offers for sale any goods or services that are unlawful or in breach of any national or international law or regulation; or

- Content or actions associated with the sale or distribution of prescription medication without a valid prescription;

- Content that depicts minors engaged in any activity of a sexual nature or which may otherwise harm minors;

- Activities that mislead or deceive minors into viewing sexually explicit material;

- Spam: 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. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;

- Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;

- Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through Domain Name System (DNS) hijacking or poisoning;

- Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers and trojan horses;

- Botnet command and control: Services run on a domain name that are used to control a collection of illegally compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks); and

- Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).


As stated in response to Question 18, Oracle’s registration policy will address the minimum requirements mandated by ICANN including rights abuse prevention measures. Oracle will implement the following as means of abuse prevention and mitigation:


1. Oracle’s draft registration policy ** (See end of document)


2. Oracle’s draft procedure for management of trademark infringement claims *** (see end of document)


Any employee found to have violated any of Oracle’s policies may be subject to disciplinary action, up to and including termination of employment.


Every Oracle employee should be aware that the data they create on the corporate systems, including on any domain name hosted in .java, remains the property of Oracle. For security and network maintenance purposes, authorized individuals within Oracle may monitor equipment, systems and network traffic at any time. Oracle reserves the right to audit networks and systems on a periodic basis to ensure compliance with this policy.

Oracle recognizes that, notwithstanding all of Oracle’s internal policies having been meticulously followed by all employees and affiliates, the Internet remains an open and ubiquitous system that provides access and anonymity to participants around the world. This is one of the Internet’s strengths and also a source of difficulty as malicious or criminal perpetrators exploit these characteristics for their own benefit. The frequency of activities such as phishing, pharming, spam and DDoS attacks have increased dramatically on the Internet and there is strong evidence to suggest this will continue.

Oracle has resolved to ensure that abusive use of the .java domain names will not be permitted nor tolerated. The nature of such abuses creates security and stability issues for Oracle, as well as for users of the Internet in general, and particularly those who wish to interact with Oracle in a secure and reliable manner. The nature of such abuses also inherently creates negative publicity and loss of brand integrity and goodwill and, therefore, any such abuse must be swiftly and effectively addressed, and systems must continue to evolve in accordance with evolving threats.


SCANNING TO IDENTIFY MALICIOUS OR ABUSIVE BEHAVIOR

All domain names within the .java domain shall be continually executing approved virus-scanning software with a current virus database, unless overridden by departmental or group policy for legitimate business reason.

Oracle will conduct automated and regular scanning for malware of all domain names in the Registry through its selected back end Registry services provider, Verisign. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names. Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s malware scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus results, detailed malware patterns, and network analysis to discover known exploits for the particular scanned zone. If malware is detected, the service sends the registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.


D. ADDITIONAL PROCESSES TO ADDRESS ABUSIVE USE OF REGISTERED DOMAIN NAMES


SUSPENSION PROCESSES CONDUCTED BY BACKEND REGISTRY SERVICES PROVIDER.

In the case of domain name abuse, Oracle or Oracle’s approved registrar(s) will determine whether to take down the subject domain name. Verisign, Oracle’s selected backend registry services provider, will follow the auditable processes to comply with the suspension request as set out Diagram 1 of the Attachment.


VERISIGN SUSPENSION NOTIFICATION.

Oracle or Oracle’s approved registrar(s) submits the suspension request to Verisign for processing, documented by:

- Threat domain name

- Registry incident number

- Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence

- Threat classification

- Threat urgency description

- Recommended timeframe for suspension⁄takedown

- Technical details (e.g., Whois records, IP addresses, hash values, anti-virus detection results⁄nomenclature, name servers, domain name status that are relevant to the suspension)

- Incident response, including surge capacity


VERISIGN NOTIFICATION VERIFICATION.

When Verisign receives a suspension request from Oracle or Oracle’s approved registrar(s), it performs the following verification procedures:

- Validate that all the required data appears in the notification

- Validate that the request for suspension is for a registered domain name

- Return a case number for tracking purposes


SUSPENSION REJECTION.

If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to Oracle or Oracle’s approved registrar(s) with the following information:

- Threat domain name
- Registry incident number
- Verisign case number
- Error reason

Oracle will notify the registrar of record in relation to a complaint.


E. ABUSE POINT OF CONTACT AND PROCESS FOR ADDRESSING COMPLAINTS


Oracle will act as the primary abuse point of contact for the gTLD. Oracle may use its third party registrar(s) or its selected back end registry services provider, Verisign, to perform some or all of the functions associated with handling inquiries relating to malicious conduct in the gTLD. Contact details (including at least a valid email and mailing address) for the abuse primary contact will be displayed prominently on Oracle’s main website. The primary contact will investigate and respond to all complaints and incidents within a reasonable time and be empowered to take effective action within well-defined written criteria to guide those actions. Action will be taken in line with what is set out in this answer and the registration policy for the .java domain. Changes to contact details will be clearly and effectively communicated to ICANN and prominently displayed on Oracle’s website.

The above mentioned email address will be set up to receive complaints for any potential malicious conduct in the TLD. Furthermore, the email address will be routinely monitored over a 24 hour period, 365 days a year. Complainants will be provided with a written email response communication containing an auditable tracking or case number. Oracle will investigate all reasonable complaints and take any reasonably necessary and appropriate action. Verified law enforcement requests will be addressed in no more than twenty-four hours from verified receipt. All other requests will be addressed in no more than seventy-two hours from receipt.

Abuse complaint metrics will be tracked, and adequate resources will be expended to ensure appropriate trending of those metrics by providing the abuse point of contact with sufficient resources. The complaint metrics will be gathered by the registrar(s) and regularly forwarded to Oracle for the purposes of identifying gaps in the Registry’s current policies and areas of improvement. Given Oracle’s belief that infrastructure protection, rights protection and user security are paramount goals of operating the TLD, Oracle intends to engage a third party registrar(s), who will be required to ensure that sufficient resources are provided to satisfy this critical requirement, and to do whatever is reasonably necessary to ensure a secure and trusted zone.

Oracle will have strict controls over the registration and use of the .java domain names. Oracle will devise and document strict criteria and authority levels which will need to be satisfied before a domain name can be registered for use. To ensure independence of this function, a third party registrar will be responsible for ensuring strict compliance with the criteria and authority levels designated. Only authorized personnel within Oracle organization will be permitted to request and⁄or authorize DNS changes to be made either by the third party registrar or the registry services provider. Oracle’s documented criteria and authority levels for registering a domain name ensure multiple, unique points of contact are needed to request and⁄ or approve, update, transfer and⁄ or deal with deletion requests, and will require notification of multiple unique points of contact when a domain name has been updated, transferred, or deleted.


F. ORPHAN GLUE RECORDS


Oracle will ensure proper attention is paid to orphan glue records. While orphan glue often supports correct and ordinary operation of the DNS, Oracle understands that it will be required, via Specification 6 of the Registry Agreement, to take action to remove orphan glue records when provided with evidence in written form that such records are present in connection with malicious conduct. Oracle’s robust controls on registration and use, and ongoing monitoring of the .java zone, should ensure that this is not an area of concern. Furthermore, Oracle’s selected backend registry services provider’s (Verisign’s), registration system is specifically designed to not allow orphan glue records. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain. To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:


CHECKS DURING DOMAIN DELETE:

- Parent domain delete is not allowed if any other domain in the zone refers to the child name server

- If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone


CHECK DURING EXPLICIT NAME SERVER DELETE:

- Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server


ZONE-FILE IMPACT:

- If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a server Hold status, then the parent domain goes out of the zone but the name server glue record does not

- If no domains reference a name server, then the zone file removes the glue record


CONTROLS ON NEW REGISTRATIONS OF DOMAIN NAMES

Oracle will adopt and impose strict controls over the registration and use of .java domain names. Oracle will devise and document strict criteria and authority levels which will need to be satisfied before a domain name can be registered for Oracle’s use. To ensure appropriate verification of this function, third party registrar(s) will be appointed to perform the administrative aspects of the registration of domain names in strict compliance with the defined criteria and designated authority levels. The registry services provider will be provided with the defined criteria and will be required to ensure that only domains which comply with the criteria are registered. Only authorized personnel within Oracle organization will be able to request and⁄or authorize DNS changes to be made either by the third party registrar(s) or the registry services provider. Oracle’s documented criteria and authority levels for domain name registration will ensure multiple, unique points of contact are needed to request and⁄ or approve, update, transfer and⁄ or deal with deletion requests, and will require notification of multiple unique points of contact when a domain name has been updated, transferred, or deleted.

Oracle confirms that it will meet the standards set out in the Registry Agreement, with respect to the Sunrise and Trademark claims process for any domain names registered.


G. ENSURING WHOIS ACCURACY


A complete and accurate Whois database promotes the prevention of identity theft, fraud and other on-line crime, promotes the public’s ability to police its rights against unlawful copyright and trademark infringement, and minimizes technical errors. Oracle has a compelling interest in accounting to itself and the public for the use of Applicant assets, and in ensuring those assets are only used by persons or entities authorized by Oracle. That interest is especially strong with respect to the .java and all domain names registered or used therein, since it is a core component of Oracle’s online branding and technological platform.

Oracle will enforce the Whois data accuracy provisions in ICANN’s Registry Agreement, Registrar Accreditation Agreement and all relevant Consensus Policies. Those agreements generally require all registrants to provide accurate and reliable contact details and promptly update any changes made during the registration term. Oracle’s registrars must present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of the domain name registration. Oracle and⁄or its affiliates (as defined in this response) will be listed as the sole registrant of all domains within the .java. Oracle’s clear written policy which requires the relevant corporate authorisation and approvals to be procured and evidenced for any .java domain name to be registered for Oracle’s use, and the subsequent verification through a registrar will ensure thorough pre-verification of all Whois data. Therefore, all Whois information will be complete and accurate at the time of registration. In the event of any change in the Whois contact information for a domain name, that change will be promptly updated in the Whois database.

Verisign, Oracle’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s Whois accuracy requirements. Verisign provides the following services to Oracle for incorporation into its full-service registry operations.


REGISTRAR SELF CERTIFICATION.

The self-certification program consists, in part, of evaluations applied equally to all operational ICANN accredited registrars and conducted from time to time throughout the year. Process steps are as follows:

- Verisign sends an email notification to the ICANN primary registrar contact, requesting that the contact go to a designated URL, log in with his⁄her Web ID and password, and complete and submit the online form. The contact must submit the form within 15 business days of receipt of the notification;

- When the form is submitted, Verisign sends the registrar an automated email confirming that the form was successfully submitted;

- Verisign reviews the submitted form to ensure the certifications are compliant;

- Verisign sends the registrar an email notification if the registrar is found to be compliant in all areas;

- If a review of the response indicates that the registrar is out of compliance or if Verisign has follow-up questions, the registrar has 10 days to respond to the inquiry;

- If the registrar does not respond within 15 business days of receiving the original notification, or if it does not respond to the request for additional information, Verisign sends the registrar a Breach Notice and gives the registrar 30 days to cure the breach;

- If the registrar does not cure the breach, Verisign terminates the Registry-Registrar Agreement (RRA).


WHOIS DATA REMINDER PROCESS.

Verisign regularly reminds registrars of their obligation to comply with ICANN’s Whois Data Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003. Verisign sends a notice to all registrars once a year reminding them of their obligation to be diligent in validating the Whois information provided during the registration process, to investigate claims of fraudulent Whois information, and to cancel domain name registrations for which Whois information is determined to be invalid.


H. RESOURCE PLANNING


Oracle has effectively mitigated the risk of abuse in the gTLD and foresees dedicating a member of staff to act as the primary points of contact for handling inquiries relating to malicious or abusive conduct in the TLD. Oracle is committed to ensuring that sufficient resources are made available at all times. Oracle may engage its third party registrar(s) and its selected back end registry services provider, Verisign, to perform some or all of the tasks associated with abuse issues. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible abuse issues both during the startup phase of the TLD and continually during operations of the TLD.

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is included in the registry services provider costs in Section I.K “Outsourcing Operating Costs” within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support abuse prevention and mitigation:

- Application Engineers: 19
- Business Continuity Personnel: 3
- Customer Affairs Organization: 9
- Customer Support Personnel: 36
- Information Security Engineers: 11
- Network Administrators: 11
- Network Architects: 4
- Network Operations Center (NOC) Engineers: 33
- Project Managers: 25
- Quality Assurance Engineers: 11
- Systems Architects: 9

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.


I. CONCLUSION


The approach outlined in this answer clearly shows that the risk of abuse in the .java TLD has been extensively mitigated and as a direct result is very low. Oracle is committed to ensuring that abuse will not be tolerated. The proposed policies and methods for addressing any abuse exceed the standard outline in the gTLD Applicant Guidebook and is more than commensurate with the risks identified, Oracle is, therefore, entitled to a score of two points for its response to Question 28.



** ORACLE’S DRAFT REGISTRATION POLICY



1. DOMAIN NAME LICENCES

Upon registration of a Domain Name, the Registrant holds a licence to use the Domain Name for a specified period of time in accordance with the Registry Rules. Domain Names may be registered and renewed for 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10 years.


2. SELECTION OF REGISTRARS

Registrars eligible to register domain names must meet the following non-discriminatory criteria (in compliance with clause 2.9 (a) of the Registry Agreement):

(i) be an accredited ICANN Registrar;
(ii) demonstrate a level of understanding of the Domain Name registration policies of the Registry;
(iii) have experience of managing the Domain Names of major corporations;
(iv) have proven tools for domain name portfolio management;
(v) have business processes to perform automated validation (and any additional human checks as required by the Registry) of the eligibility of the domain name for registration according to the Domain Name policies of Oracle;
(vi) demonstrate a sufficient level of security to protect against unauthorised access to the Domain Name records;
(vii) demonstrate experience and have appropriate resources in managing abuse prevention, mitigation and responses;
(viii) provide multi-language support for the registration of IDNs;
(ix) comply with any re-validation of its Registry-Registrar agreement at such regular intervals as are determined by the Registry or as required by ICANN from time to time;
(x) meet applicable technical requirements of Oracle; and
(xi) comply with all conditions, dependencies, policies and other requirements reasonably imposed by Oracle, including maintenance of suitable systems and applications that are capable of interacting with the Registry system.


3. ELIGIBLE REGISTRANTS

The Registrant must be:

(i) an Affiliate entity of Oracle; or
(ii) an organisation explicitly authorised by Oracle; or
(iii) a natural person explicitly authorised by Oracle.
If the Registrant does not meet one of the above eligibility criteria, there is no entitlement to register a Domain Name under the .java gTLD. If the Registrant ceases to be eligible at any time in the future, the Registry may cancel or suspend the licence to use the Domain Name immediately.


4. REGISTRY APPROVAL REQUIREMENT

Registration of Domain Names under the .java gTLD must be approved by Oracle in addition to meeting all requirements under the Registry Rules. Oracle’s approval for a complete and validly submitted application will be authorised by:

(i) a head of appropriate department as nominated by Oracle (“Authorisation Provider”); or
(ii) an authorised person as nominated by Oracle (“Authorised Person”) and notified to the Registrar from time to time.

The Authorisation Provider will notify the Registrar of its decision.


5. REQUIRED CRITERIA FOR DOMAIN NAME REGISTRATION

An application for Domain Name registration must meet all the following criteria:

(i) availability;
a. the Domain Name is not already registered;
b. it is not reserved or blocked by the Registry; or
c. it meets all Registry’s technical requirements.

(ii) technical requirements;
a. a maximum of 63 characters (after its conversion into the ASCII for IDNs);
b. use of characters selected from the list of supported characters as nominated by the Registry; and
c. any additional technical requirements as required by the Registry from time to time.

(iii) the Domain Name must be consistent with the mission and purposes of the gTLD and consistent with the Domain Name registration policy of Oracle, and include but not be limited to:
a. product name;
b. service name;
c. marketing term;
d. geographic identifier; or
e. any relevant name or term as approved by Authorisation Provider or Authorised Person.

(iv) compliance with all requirements under the Registry Rules: the Registrant must comply with all provisions contained in the Registry Rules.


6. OBLIGATION OF REGISTRANTS

The Registrant must enter into an agreement with the Registrar for Domain Name registration under which the Registrant will be bound by the Registry Rules specified through the Registry-Registrar agreement as amended by the Registry from time to time.

The Registrant must also agree to be bound by the minimum requirements in clause 3.7.7 of ICANNʹs Registrar accreditation agreement.

The Registrant must represent and warrant that:

(i) it meets, and will continue to meet, the eligibility criteria at all times and must notify the Registrar if it ceases to meet such criteria;
(ii) the registration, renewal and use of the Domain Name does not violate any third party intellectual property rights, applicable laws or regulation;
(iii) it is entitled to register the Domain Name;
(iv) the registration and use of the Domain Name is made in good faith and for a lawful purpose;
(v) if the use of registered Domain Name is licensed to a third party,
a. the Registrant must have a licencing agreement with the licensee for the use of the Domain Name that is not less onerous than the obligation of the Registrant contained in the Registry Rules; and
b. where there is a breach of any provisions contained in the Registry Rules by the licensee of the Domain Name, Registry may revoke the Domain Name at its sole discretion.
(vi) it owns or otherwise has the right to provide all registration data (including personal information) for each Domain Name registered and provision of such registrant data complies with all applicable data protection laws and regulations; and
(vii) It has appropriate consent and licences to allow for publication of registration data in the WHOIS database.


7. REGISTRANT CONTACT INFORMATION

The Registrant must provide complete and accurate contact information of the Registrant (in accordance with clause 3.7.7.1 of the ICANN’s Registrar accreditation agreement), including but not limited to the following;

(i) if the Registrant is a company or organisation:
a. name of a company or organisation;
b. registered office and principal place of business; and
c. contact details of the Registrant including e-mail address and telephone number;

(ii) if the Registrant is a natural person:
a. full name of the Registrant;
b. address of the Registrant; and
c. contact details of the Registrant including e-mail address and telephone number.

All Registrant contact information must be complete and accurate. Any changes to such Registrant information must be promptly notified to the Registrar, and no later than one (1) month of such change.


8. REVOCATION OF DOMAIN NAMES

The Registrant acknowledges that the Registry may revoke a Domain Name immediately at its sole discretion:

(i) in the event the Registrant breaches any Registry Rules;
(ii) to comply with applicable law, court order, government rule or under any dispute resolution processes;
(iii) where such Domain Name is used for any of the following prohibited activities (Prohibited Activities):
a. spamming;
b. intellectual property and privacy violations;
c. obscene speech or materials;
d. defamatory or abusive language;
e. forging headers, return addresses and internet protocol addresses;
f. illegal or unauthorised access to other computers or networks;
g. distribution of internet viruses, worms, Trojan horses or other destructive activities; and
h. any other illegal or prohibited activities as determined by the Registry.
(iv) in order to protect the integrity and stability of the domain name system and the Registry;
(v) where such Domain Name is placed under reserved names list at any time; and
(vi) where Registrant fails to make payment to the Registrar for registration, renewal or any other relevant services.


9. USE OF SECOND OR THIRD LEVEL IDNS

In addition to meeting all required criteria for registration of domain names above, an application for an IDN Domain Name must:

(i) comply with any additional registration policy on IDNs for each language;
(ii) meet all technical requirement for the applicable IDN;
(iii) comply with the IDN tables used by the Registry as amended from time to time; and
(iv) meet any other additional technical requirements as required by the Registry.


10. USE OF GEOGRAPHIC NAMES

All two-character labels and country and territory names will be initially reserved in accordance with specification 5 of the Registry Agreement.
Upon approval from ICANN and any other guidelines by applicable governments and ICANN’s Governmental Advisory Committee, the Registry may release the two-character labels and country and territory names in accordance with Oracle’s response to Question 22 Geographic Names.


11. RESERVED NAMES

The Registry may place certain names in its reserved list from time to time where:

(i) the Registry believes in its sole discretion that use of such names may pose a risk to the operational stability or integrity of the Registry;
(ii) in accordance with ICANN’s specifications contained in the Registry Agreement, guidelines or recommendations;
(iii) there is a risk of trademark infringement or where the name otherwise may cause confusion taking into consideration the mission and purpose of the gTLD; or
(iv) the Registry in its sole discretion decides certain names to be reserved for any reason.


12. ALLOCATION OF DOMAIN NAME

The Registry will register Domain Names on a first-come, first-served basis in accordance with the Registry Rules. The Registry does not provide pre-registration or reservation of Domain Names.


13. LIMITATION ON REGISTRATION ⁄ DOMAIN NAME LICENCES

There is no restriction on the number of Domain Names any Registrant may hold. The Registrant may further licence the use of the Domain Name to any third parties provided that the Registrant enters into an agreement with such third parties on the terms not less onerous than its obligations under the Registry Rules.


14. PROTECTION OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS

The Registry will implement all rights protection measures as required by ICANN in clause 2.8 of the Registry Agreement, including the use of the Uniform Rapid Suspension (URS) procedure, and Uniform Domain Name Dispute Resolution Policy (UDRP).


15. TERM OF REGISTRATION ⁄ RENEWAL


Initial term of registration:

A Domain Name can be registered for a period between one (1) to ten (10) years.

Renewal of registration:

(i) The term may be extended at any time for a period between one (1) to ten (10) years, provided that the total aggregate term of the Domain Name does not exceed ten (10) years at any time.
(ii) Upon change of sponsorship of the Domain Name from one Registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the registered Domain Name will be extended by one year, provided that the maximum term of registration at any time does not exceed ten (10) years.
(iii) The change of sponsorship of the registration of a Domain Name from one Registrar to another, accordingly to Part B of the ICANN Policy on Transfer of Registrations between Registrars will not result in the extension of the term of registration.

Cancellation of registration:

The Registrant may cancel a Domain Name registration at any time by submitting its request in writing with the Registrar.

Auto-renewal:

Upon expiry of the Domain Name, the Registry will auto-renew the Domain Name for a one year term (1) year term unless the Registrant submits its intention not to renew the Domain Name.

The Registry will implement the business rules for the renewal of Domain Names documented in appendix 7 of the .com Registry Agreement.


16. TRANSFER OF DOMAIN NAMES BETWEEN REGISTRANTS

Any transfer of a Domain Name between Registrants must be approved by the Registry through the Registrar. The legal heirs of the Registrant or purchaser of the Registrant may request the transfer provided that they meet the eligibility criteria for registration under the .java gTLD. If the Registrant becomes subject to insolvency or any other proceeding, the administrator may request the transfer. The transferee must provide appropriate documentation as required by the Registry to approve such transfer.


17. CHANGE OF REGISTRAR

If the agreement between the Registry and the Registrar is terminated and if the Registrar has not transferred its Domain Name portfolio to another Registrar, the Registry will notify affected Registrants. The Registrants must select a new Registrar within one (1) month following such notice from the Registry. If the Registrant fails to appoint a new Registrar within the timeframe set out above, the Registry may suspend the Domain Name.

If the Registrant wishes to change the Registrar, the Registrant must obtain the auth-info code from the Registrantʹs current Registrar, and request a transfer through the gaining Registrar in compliance with ICANNʹs Inter-Registrar transfer policy.


18. PRIVACY AND DATA PROTECTION

By registering a Domain Name, the registrant authorises the Registry to process personal information and other data required for the operation of the .java gTLD. The Registry will only use the data for the operation of the Registry including but not limited to its internal use, communication with the Registrant, and provision of WHOIS look-up facility.

The Registry may only transfer the data to third parties:

(i) with the Registrant’s consent;
(ii) in order to comply with laws, regulations or orders by a competent public authority and any Alternative Dispute Resolution (ADR) providers; or
(iii) for a publicly available and searchable WHOIS look-up facility, in accordance with specification 4 of the Registry Agreement.


19. WHOIS

The Registry provides a publicly available and searchable WHOIS look up facility, where information about the Domain Nameʹs status (including creation and expiry dates), and registrant, administrative and the technical contact administering the Domain Name can be found, in accordance with specification 4 of the Registry Agreement.

In order to prevent misuse of the WHOIS look up facility, the Registry requires that any person submitting a WHOIS database query will be required to read and agree to the terms and conditions, which will provide that:

(i) the WHOIS database is provided for information purposes only; and
(ii) the user agrees not to use the WHOIS information to allow or enable the transmission of unsolicited commercial advertising or other communication via email or other methods to the Registrants.


20. PRICING ⁄ PAYMENT

The new gTLD does not charge a separate fee for the Registrar to register domain names, as the gTLD is used only for the specified mission and purpose of Oracle. Oracle shall bear the cost of operating the Registry.

The Registry will provide Registrars with 30 days’ notice of any price change for new registrations, and 180 days advance notice of any price change for renewals in accordance with clause 2.10 of the Registry Agreement.


21. DISPUTE RESOLUTION

The Registrant agrees to be bound by ICANN’s Dispute Resolution Policies in respect of all disputes in connection with the Domain Name.


22. COMPLIANCE WITH CONSENSUS AND TEMPORARY POLICIES

The Registrant agrees to be bound by all applicable consensus and temporary policies as required and mandated by ICANN.


23. DEFINITIONS

Affiliate means in relation to a party any corporation or other business entity controlling, controlled by, or under common control of that party and for the purposes of this definition, a corporation or other business entity shall be deemed to control another corporation or business entity if it owns directly or indirectly:

(i) fifty percent (50%) or more of the voting securities or voting interest in any such corporation or other entity; or
(ii) fifty percent (50%) or more of the interest in the profit or income in the case of a business entity other than a corporation; or
(iii) in the case of a partnership, any other compatible interest equal to at least a fifty percent (50%) share in the general partner.

Domain Name means a domain name registered directly under the .java gTLD or for which a request or application for registration has been filed with the Registry;

ICANN’s Dispute Policy means the dispute policy currently known as the Uniform Domain Name Dispute Resolution Policy (UDRP) issued and as may be updated from time to time by the Internet Corporation of Assigned Names and Number (ICANN) and the Uniform Rapid Suspension (URS) (see Specification 7 of the Registry Agreement).

Registrar means an ICANN accredited registrar which enters into and is in compliance with the registry-registrar agreement for the TLD, and which provides domain name registration services to Registrants;

Registry means Oracle Corporation (Oracle);

Registry Agreement means the agreement between Oracle and ICANN;

Registry Rules mean:

(i) Registration terms and conditions agreed between the Registry and Registrant for registration of a Domain Name; and
(ii) Registration policies provided and amended by the Registry from time to time.

Registrant means a natural person, company or organisation who holds a Domain Name registration or who has requested or applied for the registration of a Domain Name.



***


DRAFT PROCEDURE FOR MANAGEMENT OF TRADEMARK INFRINGEMENT CLAIMS:

It is almost impossible to devise a standard response⁄process for all claims made of trademark infringement, as the seemingly small individual differences between each complaint and between each domain name registration make the course of action potentially different in each case. This draft procedure is a guide to the general approach required, but thought should be given to the appropriateness of any action in each case, with assistance from designated senior manager where appropriate.

(a) DOMAIN NAME ITSELF IS CLAIMED TO BE AN INFRINGEMENT OF A PARTY’S TRADEMARK RIGHTS:

i. ACTIONS
- Determine if the name is being used for any “visible” fraudulent activity such as phishing. If so, follow the phishing process.
- If no fraudulent content , send “invalid whois” notice to the registrant of the domain name

ii. FORMULATING A RESPONSE TO COMPLAINANT
- It is outside of a registrar’s scope to determine if a domain name infringes a party’s rights
- Cannot transfer or delete a domain name based on complaint alone – will need to be issued with copies of relevant court orders or other appropriate documentation
- Outline invalid whois process and inform complainant that a notice has already been sent to the registrant in respect of this
- If applicable, inform the complainant that the complaint has also been forwarded to the reseller who may be able to take action.
- Suggest Uniform Dispute Resolution Policy action

(b) WEBSITE LOCATED AT THE DOMAIN NAME CONTAINS LOGOS OR TEXT WHICH ARE CLAIMED TO INFRINGE ANOTHER PARTIES RIGHTS:

i. ACTIONS (WHERE THE REGISTRAR IS NOT THE HOST)
- Determine if the name is being used for any “visible” fraudulent activity such as phishing. If so, follow the phishing process.
- If no fraudulent content, send “invalid whois” notice to the registrant of the domain name

ii. FORMULATING A RESPONSE TO COMPLAINANT (WHERE REGISTRAR IS NOT THE HOST):
- Inform complainant that the Registrar is not hosting the content, and therefore has no ability to access, modify or delete the content.
- Outline who the host is, and, if able to determine, steps to contact them.
- Outline invalid whois process and inform complainant that a notice has already been sent to the registrant in respect of this (use prepared template)
- If applicable, inform the complainant that the complaint has also been forwarded to the relevant third party Registrar

iii. WHERE REGISTRAR IS THE HOST:
- Review, formulate a proposed course of action based on the circumstances and applicable policies,
- Discuss proposed course of action with designated senior manager and base response to complainant around this.



29. Rights Protection Mechanisms

A. RIGHTS PROTECTION MECHANISMS TO BE IMPLEMENTED 

In operating the .java Top Level Domain, Oracle is fully committed to ensure efficient and timely rights protection not only for Oracle but also for third party rights owners. In particular, Oracle seeks to establish a trusted and reliable, branded platform for those who wish to interact or communicate with Oracle. Therefore, Oracle has extremely strong interest in ensuring that all of its aforementioned policies are implemented and continually enforced. Importantly, Oracle’s proposed use of the .java gTLD should, of itself, preclude any abusive registrations from occurring, since all domain names may only be registered in the name of Oracle . Notwithstanding the above, Oracle understands the importance of ensuring safeguards are implemented which protect against unqualified registrations. Oracle and its backend registry service provider, Verisign, are fully aware of all rights protection mechanisms implemented by ICANN and fully committed to ensure compliance with such mechanisms when applicable. Therefore, Oracle has resolved to implement the following:

Firstly, Oracle will have absolute control over the registration and use of all .java domain names. Only authorized personnel will be able to register a second level domain name on behalf of and in the name of Oracle only for corporate use and only authorized personnel will be permitted to make Domain Name System (DNS) changes. Oracle will require multiple, unique points of contact to request and⁄or approve, update, transfer and⁄ or deal with deletion requests, and will require notification of multiple unique points of contact when a domain name has been updated, transferred, or deleted. In other words, Oracle will have an identifiable and delineated process in place from pre-verification to eventual deletion of a domain name. This process will bind Oracle and its Affiliates in line with the definition of Affiliates in clause 2.9 (c) of the new gTLD Registry Agreement . Compliance with the policy will be ensured by the appointed Registrar(s). This, in conjunction with Oracle’s resolution to ensure that abusive use of .java domain names will not be permitted nor tolerated, means that the scope for abusive use will be very limited.

Secondly, where Oracle intends to permit certain entities who are affiliated with Oracle’s business (Affiliates) to use second level domain names within the .java domain, Oracle will ensure that it is limited to legitimate uses of the domain name (such use being consistent with the mission and purpose of the .java TLD, and subject always to continuing compliance with all applicable policies in place during that time and those mandated thereafter to ensure compliance with on-going applicable ICANN requirements. Oracle and its Affiliates must warrant they will not assign, licence or otherwise permit any other third party to use or link to the subdomain under the .java TLD.

Thirdly, Oracle will regularly monitor the .java zone, for viruses⁄malware, illegitimate use and for inappropriate content. Abuses and complaints will be quickly addressed in the manner set forth in response to Question 28.

Fourthly, Oracle will participate in, and comply with, the applicable Rights Protection Mechanisms set forth in the gTLD Applicant Guidebook and Registry Agreement, including the Uniform Domain Name Dispute Resolution Policy (UDRP), the Uniform Rapid Suspension (URS) and the Trademark Claims and Sunrise processes. In the unlikely event that third parties perceive that their rights have been infringed, they will have a speedy right of recourse open to them. Given that Oracle has resolved to ensure that abusive use of .java domain names will not be permitted nor tolerated and the risk that such abuses inherently create negative publicity, loss of brand integrity and goodwill, Oracle is committed to ensuring that any abuse will be swiftly and effectively addressed, and that systems are in place to mitigate rights protection issues.

Fifthly, Oracle will go beyond the required rights protection mechanisms defined in Specification 7 of the Registry Agreement by also participating in solutions to monitor potentially malicious conduct over the Internet as outlined below and in the answer to Question 28. These measures will be available at time of registration and include:

- Rapid Takedown or Suspension Based on Court Orders: Oracle or Oracle’s approved registrar(s) complies promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. These orders may be issued when abusive content, such as child pornography, counterfeit goods, or illegal pharmaceuticals, is associated with the domain name;
- Anti-Abuse Process: Oracle or Oracle’s approved registrar(s) implements an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, bot nets, and malware;

- Authentication Procedures: Verisign, Oracle’s selected backend registry services provider, uses two-factor authentication to augment security protocols for telephone, email, and chat communications;

- Malware Code Identification: This safeguard reduces opportunities for abusive behaviors that use registered domain names in the gTLD. Registrants are often unknowing victims of malware exploits. As Oracle’s backend registry services provider, Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in the computer systems accessible through domain names;

- DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .java gTLD is DNSSEC-enabled as part of Verisign’s core backend registry services.

Lastly, Oracle will also ensure in all cases that its approved Registrar(s) will adopt appropriate anti-abuse mechanisms, respond to abuse processes and third party rights protection mechanisms and processes, in dealing with any domain name registrations, renewals and use, on behalf of Oracle. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible rights protection issues both during the startup phase of the TLD and continually during operations of the TLD. An example of the type of processes that Registrar(s) will be required to have in place for managing e.g. a UDRP claim is described at the end of the response to Question 29*** (see end of document).java will ensure that Registrar(s) are contractually bound to provide high quality and responsive management of rights protection queries.

B. REGISTRY OPERATOR PROVIDED RIGHTS PROTECTION MECHANISMS

Oracle has engaged Verisign to provide certain registry operation services, amongst which, are the technical functions required to implement the mechanisms outlined below in respect of sunrise periods, trademark claims periods and the interaction with the Trademark Clearinghouse. The manner in which these elements will be addressed by the various parties is set out in this section. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, Oracle cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. Oracle will adhere to all processes and procedures to comply with ICANN guidance once this guidance is finalized.

SUNRISE SERVICES

Oracle acknowledges that, although the .java domain is intended to be limited exclusively to registrations by Oracle as defined in the response to Question 28, the gTLD Applicant Guidebook provides that all new gTLD’s must provide a sunrise period before general registration of domain names.

Oracle confirms that it will implement a sunrise service pre-registration procedure for domain names for 30 days prior to the launch of the general registration of domain names. Prior to the Sunrise Period commencing, Oracle will establish and then notify its registry service provider of the sunrise eligibility requirements for the gTLD. Oracle may register domain names which meet the sunrise eligibility requirements. The registrant of any registrations of domain names during this period must agree to be subject to the Sunrise Dispute Resolution Policy (SDRP) consistent with Section 6 of the Trademark Clearinghouse Rules as set forth by ICANN. During this period, Oracle, and its approved registrars, will verify whether or not a particular domain name is eligible to be registered on an individual case by case basis before adding the necessary command to the Shared Registry Service (SRS) to register the applicable domain name.

TRADEMARK CLAIMS SERVICE

In respect of the .java domain, Oracle will provide a trademark claims service for a minimum of sixty (60) days after it has permitted general registration of domain names in the .java domain. During this period, Oracle (or its approved registrars on its behalf) shall validate each request for registration of a domain name against trademarks registered in the Trademark Clearinghouse and shall (where applicable) provide notice to each prospective Registrant of a domain name that it is an identical match (as defined in the gTLD Applicant Guidebook) to the mark holder validated in the Trademark Clearinghouse, in the form required by ICANN. The Approved Registrar(s) will then require each registrant to provide the warranties set out in the gTLD Applicant Guidebook before registration of the particular domain name. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, Oracle or Oracle’s approved Registrar will not process the domain name registration.

Oracle and⁄or its approved Registrar(s)(as applicable) will be responsible for determining whether a domain name is eligible to be registered and will do so for each domain name before submitting an add command to the gTLD Shared Registry Service to register the applicable domain name.

Following the registration of a domain name, the holders of trademarks that have been previously validated by the Trademark Clearinghouse as an identical match, will receive a notice of the domain name registration by Oracle or Oracle’s approved Registrar (as applicable), in the form required by ICANN.

GENERAL REGISTRATION PERIOD

Following the expiry of the trademark claims service, Oracle (through its appointed registrar(s)may nevertheless continue to require potential domain names in the .java domain to be validated against trademarks registered in the Trademark Clearinghouse as part of its internal approval process prior to the registration being approved. This will be subject to the final rules for the Trademark Clearinghouse, and reasonable commercial terms for the on-going use of the Trademark Clearinghouse for this purpose.

Oracle will implement processes to enable Internet users or third parties to lodge complaints about any domain names in the .java which the complainant claims is infringing a third party’s intellectual property rights in some way. These processes will include mechanisms for rapid suspension of an infringing domain name (including but not limited to via ICANN’s URS system). The abuse point of contact resources described in the response to Question 28 above will also be tasked with responding to complaints in relation to rights protection.

C. DISPUTE RESOLUTION

Oracle will comply with the dispute resolution mechanisms required by ICANN including the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP), the Registration Restriction Dispute Resolution Procedure (RRDRP), the URS, and the UDRP. All registrations of domain names will be subject to compliance with the above procedures and policies, should any relevant disputes occur. Oracle will act as the primary contact for handling inquiries relating to malicious conduct in the gTLD. The primary contact will investigate and respond to all complaints and incidents within a reasonable time and be empowered to take effective action within well-defined written criteria to guide those actions. Action will be taken in line with what is set out in the answers to Question 28 and 29 and the registration policy for the .java.

D. RESOURCE PLANNING

RESOURCE PLANNING SPECIFIC TO BACKEND REGISTRY ACTIVITIES
Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as Line IIb. G, Total Critical Registry Function Cash Outflows, within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support the implementation of RPMs:

-Customer Affairs Organization: 9
- Customer Support Personnel: 36
- Information Security Engineers: 11

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.

RESOURCE PLANNING SPECIFIC TO ENGAGING THIRD PARTY REGISTRARS
Oracle has effectively mitigated the risk of abuse in the gTLD and foresees dedicating a member of staff to act as the primary points of contact for handling inquiries relating to malicious or abusive conduct in the TLD. Oracle is committed to ensuring that sufficient resources are made available at all times. Oracle may engage its third party registrar(s) and its selected back end registry services provider, Verisign to perform some or all of the tasks associated with abuse issues. This will ensure that highly skilled, specialized and scalable resources are on hand to address any possible abuse issues both during the startup phase of the TLD and continually during operations of the TLD.

E. CONCLUSION

The approach outlined in this answer clearly shows that the risk of abuse in the .java TLD has been extensively mitigated and as a direct result is very low. Oracle is committed to ensuring that abuse will not be tolerated. The proposed policies and methods for addressing any abuse exceed the standard outlined in the gTLD Applicant Guidebook and is more than commensurate with the risks identified, Oracle is, therefore, entitled to a score of two points for its response to Question 29.




***
EXAMPLE OF A DRAFT PROCESS FOR A REGISTRAR’S HANDLING OF UDRP CLAIMS

REQUEST FOR REGISTRAR VERIFICATION
‘Request for Registrar Verification’ emails are received from the provider of UDRP, and are the official “beginning” of the UDRP case. These emails normally ask the Registrar to verify the domain name and the corresponding registrant details. The Registrar can ONLY ever lock a domain name following receipt of one of these emails. The receipt of a copy of a complaint does not indicate the beginning of a dispute.

The two most commonly used providers are the National Arbitration Forum (NAF) and the World Intellectual Property Organisation (WIPO).NAF requests will generally have the subject “Domain Name Dispute Verification Request”. WIPO requests will generally have the subject “Request for Registrar Verification”

WHEN SUCH A REQUEST IS RECEIVED, THE FOLLOWING STEPS NEED TO BE TAKEN:
1. Update the UDRP Spreadsheet with the complaint details
2. Create a response to UDRP Provider
3. Send a confirmation to the complainant of receipt of complaint and inform of registrar lock and the circumstances under which the lock will expire
4. Change domain name Registry Key
5. Assign domain name to the ‘ABC Disputes’ account
6. Lock domain name
7. Advise Registrant of UDRP ⁄ create New Case
8. Spreadsheet finalization

WHEN A COPY OF THE UDRP COMPLAINT IS RECEIVED:
-Make a note in the spreadsheet of where to access the complaint.

WHEN A NOTICE OF “COMMENCEMENT OF UDRP” RECEIVED:
-Save the domain name in the case and resolve.
- If a copy of the complaint has been attached, follow process in above.

WHEN A NOTICE OF “SUSPENSION” OR “STAY” OF PROCEEDINGS IS RECEIVED:
Sometimes, the parties to the UDRP may reach an agreement to settle the matter outside of the UDRP. If the parties contact the registrar directly and indicate that they (the respondent) wish to transfer the domain name to the complainant, the registrar must direct them to the UDRP provider where they must have the proceedings “stayed” (sometimes called “suspended”). The registrar may only transfer a domain name once official notice from the provider has been received.

If a notice is receive from the UDRP provider PRIOR to the registrar being contacted by the parties:
-Respond to everyone who has been emailed a copy of the notice, with the template “UDRP – Notice of stay of proceedings. This includes instruction that the registrar require written authorization from the respondent before releasing the domain name from registrar lock.

Once the registrar has received BOTH authorization from the current registrant, and official notice of suspension from the provider, the domain name may be transferred to the complainant.

Note, the registrar is only able to transfer the domain name to the complainant. The Registrar is not able to transfer the domain name to any other party.

WHEN A UDRP DECISION IS RECEIVED:
When WIPO sends a notice of decision, the subject will be “Notification of Decision”. When NAF sends a notice of decision, the subject will be “DECISION – Complainant v Respondent”

TO VIEW THE DECISION:
1. Locate the decision
2. Scroll to the end of the decision document and note whether the decision is for the complainant or the respondent:
-A decision for the complainant will be described as “the domain name is ordered to be transferred from the respondent to the complainant (follow process (a), below)
- A decision for the respondent will be described as “the complaint is denied” (follow process (b), below)

RESPONDING TO THE EMAIL REGARDING THE DECISION:
1. If decision is for the complainant:
Schedule the transfer for 10 working days time:
-Add end date to calendar
- Open the UDRP spreadsheet and make a note that the decision is for the complainant and note the date the name is scheduled to be transferred.

2. If decision is for the respondent:
Open the UDRP spreadsheet and locate the name of the reseller account (if any) which this domain name was on prior to the UDRP, then:
- Move the domain name from the ABCDISPUTES account
- Unlock the domain name
- Send the registrant the new registry key

IMPLEMENTATION OF THE DECISION FOR COMPLAINANT – TRANSFER OF DOMAIN NAME:
1. Copy of Complaint received? - check UDRP Spreadsheet to make sure
2. Assigning domain name to new Channel Partner (CP) & Update domain name
3. Unlock the domain name
4. Change Contact Details for domain name
5. Password Recovery
6. CRM case creation ⁄ Notice of Transfer of Licence
7. Update UDRP Spreadsheet – indicate that the case is closed




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

30A SECURITY POLICY – PART A


1 DETAILED DESCRIPTION OF PROCESSES AND SOLUTIONS DEPLOYED TO MANAGE LOGICAL SECURITY ACROSS INFRASTRUCTURE AND SYSTEMS, MONITORING AND DETECTING THREATS AND SECURITY VULNERABILITIES AND TAKING APPROPRIATE STEPS TO RESOLVE THEM

As advised previously, Oracle has engaged the services of Verisign as its selected backend registry services provider for .java. Accordingly, the responses to both Questions 30a and 30b mostly describe the security policies and regime deployed by Verisign, as Oracle’s backend registry services provider. Further attachments have been provided as evidence of, and testimony to, independent third party validation of Verisign’s compliance with these requirements. Whilst Oracle does have a company-wide security policy in place, it was not provided here as it has much wider scope beyond the current application for the proposed operation of .java gTLD. Oracle will likewise ensure equivalent security policies and controls are adhered for by its other third party services providers, including registrars.

Oracle’s selected backend registry services provider’s (Verisign’s) comprehensive security policy has evolved over the years as part of managing some of the world’s most critical TLDs. Verisign’s Information Security Policy is the primary guideline that sets the baseline for all other policies, procedures, and standards that Verisign follows. This security policy addresses all of the critical components for the management of backend registry services, including architecture, engineering, and operations.


Verisign’s general security policies and standards with respect to these areas are provided as follows:


- ARCHITECTURE

- Information Security Architecture Standard: This standard establishes the Verisign standard for application and network architecture. The document explains the methods for segmenting application tiers, using authentication mechanisms, and implementing application functions.

- Information Security Secure Linux Standard: This standard establishes the information security requirements for all systems that run Linux throughout the Verisign organization.

- Information Security Secure Oracle Standard: This standard establishes the information security requirements for all systems that run Oracle throughout the Verisign organization.

- Information Security Remote Access Standard: This standard establishes the information security requirements for remote access to terminal services throughout the Verisign organization.

- Information Security SSH Standard: This standard establishes the information security requirements for the application of Secure Shell (SSH) on all systems throughout the Verisign organization.


- ENGINEERING

- Secure SSL⁄TLS Configuration Standard: This standard establishes the information security requirements for the configuration of Secure Sockets Layer⁄Transport Layer Security (SSL⁄TLS) for all systems throughout the Verisign organization.

- Information Security C++ Standards: These standards explain how to use and implement the functions and application programming interfaces (APIs) within C++. The document also describes how to perform logging, authentication, and database connectivity.

- Information Security Java Standards: These standards explain how to use and implement the functions and APIs within Java. The document also describes how to perform logging, authentication, and database connectivity.


- OPERATIONS

- Information Security DNS Standard: This standard establishes the information security requirements for all systems that run DNS systems throughout the Verisign organization.

- Information Security Cryptographic Key Management Standard: This standard provides detailed information on both technology and processes for the use of encryption on Verisign information security systems.

- Secure Apache Standard: Verisign has a multitude of Apache web servers, which are used in both production and development environments on the Verisign intranet and on the Internet. They provide a centralized, dynamic, and extensible interface to various other systems that deliver information to the end user. Because of their exposure and the confidential nature of the data that these systems host, adequate security measures must be in place. The Secure Apache Standard establishes the information security requirements for all systems that run Apache web servers throughout the Verisign organization.

- Secure Sendmail Standard: Verisign uses sendmail servers in both the production and development environments on the Verisign intranet and on the Internet. Sendmail allows users to communicate with one another via email. The Secure Sendmail Standard establishes the information security requirements for all systems that run sendmail servers throughout the Verisign organization.

- Secure Logging Standard: This standard establishes the information security logging requirements for all systems and applications throughout the Verisign organization. Where specific standards documents have been created for operating systems or applications, the logging standards have been detailed. This document covers all technologies.

- Patch Management Standard: This standard establishes the information security patch and upgrade management requirements for all systems and applications throughout Verisign.


- GENERAL

- Secure Password Standard: Because passwords are the most popular and, in many cases, the sole mechanism for authenticating a user to a system, great care must be taken to help ensure that passwords are “strong” and secure. The Secure Password Standard details requirements for the use and implementation of passwords.
- Secure Anti-Virus Standard: Verisign must be protected continuously from computer viruses and other forms of malicious code. These threats can cause significant damage to the overall operation and security of the Verisign network. The Secure Anti-Virus Standard describes the requirements for minimizing the occurrence and impact of these incidents.


Security processes and solutions for the .java TLD are based on the standards defined above, each of which is derived from Verisign’s experience and industry best practice. These standards comprise the framework for the overall security solution and applicable processes implemented across all products under Verisign’s management. The security solution and applicable processes include, but are not limited to:

- System and network access control (e.g., monitoring, logging, and backup)

- Independent assessment and periodic independent assessment reports

- Denial of service (DoS) and distributed denial of service (DDoS) attack mitigation

- Computer and network incident response policies, plans, and processes

- Minimization of risk of unauthorized access to systems or tampering with registry data

- Intrusion detection mechanisms, threat analysis, defenses, and updates

- Auditing of network access

- Physical security

Further details of these processes and solutions are provided in Part B of this response.



1.1 SECURITY POLICY AND PROCEDURES FOR THE PROPOSED REGISTRY

Specific security policy related details, requested as the bulleted items of Question 30 – Part A, are provided here.



INDEPENDENT ASSESSMENT AND PERIODIC INDEPENDENT ASSESSMENT REPORTS.

To help ensure effective security controls are in place, Oracle, through its selected backend registry services provider, Verisign, conducts a yearly American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70 audit on all of its data centers, hosted systems, and applications. During these SAS 70 audits, security controls at the operational, technical, and human level are rigorously tested. These audits are conducted by a certified and accredited third party and help ensure that Verisign in-place environments meet the security criteria specified in Verisign’s customer contractual agreements and are in accordance with commercially accepted security controls and practices. Verisign also performs numerous audits throughout the year to verify its security processes and activities. These audits cover many different environments and technologies and validate Verisign’s capability to protect its registry and DNS resolution environments. Figure 30A -1 lists a subset of the audits that Verisign conducts. For each audit program or certification listed in Figure 30A-1, Verisign has included, as attachments to the Part B component of this response, copies of the assessment reports conducted by the listed third-party auditor. From Verisign’s experience operating registries, it has determined that together these audit programs and certifications provide a reliable means to ensure effective security controls are in place and that these controls are sufficient to meet ICANN security requirements and therefore are commensurate with the guidelines defined by ISO 27001.



AUGMENTED SECURITY LEVELS OR CAPABILITIES.

See Section 5 of this response.



COMMITMENTS MADE TO REGISTRANTS CONCERNING SECURITY LEVELS.

See Section 4 of this response.



2 SECURITY CAPABILITIES ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.

Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .java gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.



3 TECHNICAL PLAN ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Verisign, Oracle’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Oracle fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.

Verisign projects it will use the following personnel role, which is described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support its security policy:

- Information Security Engineers: 11

To implement and manage the .java gTLD as described in this application, Verisign, Oracle’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.

When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.



4 SECURITY MEASURES ARE CONSISTENT WITH ANY COMMITMENTS MADE TO REGISTRANTS REGARDING SECURITY LEVELS

Verisign is Oracle’s selected backend registry services provider. For the .java gTLD, no unique security measures or commitments must be made by Verisign or Oracle to any registrant.



5 SECURITY MEASURES ARE APPROPRIATE FOR THE APPLIED-FOR GTLD STRING (FOR EXAMPLE, APPLICATIONS FOR STRINGS WITH UNIQUE TRUST IMPLICATIONS, SUCH AS FINANCIAL SERVICES-ORIENTED STRINGS, WOULD BE EXPECTED TO PROVIDE A COMMENSURATE LEVEL OF SECURITY)

No unique security measures are necessary to implement the .java gTLD. As defined in Section 1 of this response, Verisign, Oracle’s selected backend registry services provider, commits to providing backend registry services in accordance with the following international and relevant security standards:

- American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70

- WebTrust⁄SysTrust for Certification Authorities (CA)



© Internet Corporation For Assigned Names and Numbers.