Application number: 1-1311-76497 for Pontificium Consilium de Comunicationibus Socialibus (PCCS) (Pontifical Council for Social Communication)

Pontificium Consilium de Comunicationibus Socialibus (PCCS) (Pontifical Council for Social Communication)

Via della Conciliazione 5
Città del Vaticano (Vatican City State) 00120
VA

0039 0669891800

0039 0669891840

http:⁄⁄www.pccsva.org⁄

Ms. Eloisa Romani

Executive Assistant to Project Manager

0039 0669891819

0039 0669891840

e.romani@pccs.va

Mr. Mauro Milita

Project Manager

0039 0669883888

0039 0669885173

m.milita@pccs.va

PCCS is a Dicastery of the Holy See.

Dicasteries are departments of the administrative apparatus of the Holy See sovereign entity. The Holy See is the moral person which governs the Vatican City State and represents the Catholic Church in the International forum.

Not Available

Archbishop Claudio Maria Celli
President of PCCS
Monsignor Paul Tighe
Secretary of PCCS

Eloisa Romani
Executive Assistant to Project Manager
Mauro Milita
Project Manager

catholic

Not Available

A number of operational and rendering issues may arise with the delegation, and subsequent operation and use of a new TLD. Some of these issues may be experienced just by the users of one or two particular TLDs, due to the nature or composition of the string itself; whereas other issues (such as software support) may be experienced across all new TLDs.
Evaluation of the potential operational and rendering issues for this TLD was delegated to ARI. ARI is experienced with:
– The operational issues of operating TLDs.
– TLDs that offer registrations at the third level (eg .com.au, .net.au) and below.
– The rendering and operational issues surrounding the introduction of IDNs.
ARI has executed a suite of tests to evaluate any issues arising from the use of the TLD string. ARI configured a test environment that consisted of DNS software, web server software, and an email server configured for sample domains in this TLD. Where possible, ARI attempted to test many equivalent applications, however the number of and different versions of applications means that testing was limited to the most common environments.
The tests executed by ARI indicate that this TLD is subject to the same issues already experienced by TLDs in the root, which are neither new nor unique. A summary of the common issues is provided below:
– Some applications make assumptions about known valid TLDs and fail to recognize new TLDs.
– Some Non-IDN aware applications require the user to provide input in A-labels.
– Some IDN aware applications present the user with the domain name using A-labels instead of U-labels.
– Some IDN aware applications fail to render IRIs in a manner consistent with user expectations.
To mitigate these issues, ARI will work with us to ensure that maintainers of applications are made aware of the delegation and operation of this TLD. When relevant, we will refer the maintainers to the verification code produced by ICANN in the area for Universal Acceptance of All Top Level Domains such that operational issues can be mitigated for other TLDs.
ARI and us will work with maintainers of applications to provide subject matter knowledge where required, and provide directions to the tools provided by third parties such as the International Components for Unicode project and other groups, that can assist the application maintainer in adding the required support. User education may be required enabling users to configure their applications for correct functioning of this TLD. An informational section on the TLD website will be considered to address questions raised by the Internet community.
The steps ARI will take to mitigate these issues are more than adequate. Thus, we do not believe this TLD raises stability concerns and there is no reason that it should be denied on an operational and rendering issues bases.

MISSION⁄PURPOSE OF THE .CATHOLIC TLD

The mission⁄purpose of the .catholic TLD is to share the teachings, message and values of the Catholic Church with its own members and with the wider global community, by creating a dedicated, authoritative online space for the exclusive use of the Catholic Church and its constituent institutions, including dioceses, religious orders, institutes of consecrated life and organizations affiliated to the Catholic Church, and for the benefit of its adherents globally. The .catholic TLD will serve as an important method of communication for the Church, by establishing a formal and official channel for online communications via the appropriate channels of the Catholic Church. This function of the TLD is consistent with the Church’s core activities, as communication is important in the life of the Church insofar as it facilitates the sharing of information and helps build a sense of community and belonging amongst its adherents. The .catholic TLD will complement the Church’s long established global network of communications activities including print and digital media, television and radio.

The gTLD applicant (PCCS) was established in 1948 as a Dicastery (Department) of the Roman Curia, the central governing body of the Catholic Church and the administrative apparatus of the Holy See, to promote communication activities within the life of the Church. This organisational aim is detailed in the foundational basis of the PCCS, where it is stated (in Article 170 of the Apostolic Constitution on the Roman Curia) that “the chief task of this Council is to encourage and support in a timely and suitable way the action of the Church and her members in the many forms of social communication.” The .catholic TLD will serve to give coherence and unity to the digital presence of the Catholic Church. In particular, the TLD will provide a direct form of identification and authentication for official Catholic institutions in the digital environment.

All domain name registrations in the .catholic TLD will be registered to, and maintained by, the PCCS for the exclusive use of the PCCS and the constituent institutions of the Church. The PCCS will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not identified within the TLD Catholic Community. As such, individual adherents will not be eligible to register or be granted use of .catholic domain names. Dioceses, religious orders and institutions as found in the “Annuario Pontificio” (the official annual directory of all the institutions related to the Holy See) are recognised as members of the TLD Catholic Community, by virtue of their being formally recognised by the Catholic Church. This recognition is primarily, though not exclusively, evidenced by inclusion in the Annuario Pontificio. The PCCS will maintain a list of institutions formally recognised by the Holy See as falling within the Catholic Church.

Each diocese, official religious order of the Catholic Church and Church-affiliated institution, may be granted use of an associated .catholic domain name to facilitate the establishment of formal and official channels of online communication for the Catholic Church, and promote the overall mission⁄purpose of the .catholic TLD. The use of the domain names by these institutions is subject to internal acceptable use policies.

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


BENEFITS OF THE .CATHOLIC TLD

There are four main beneficiaries of the .catholic TLD:

1. PCCS: The .catholic TLD will bring benefits to the PCCS by supporting its efforts to promote social communications supportive of the teachings of the Catholic Church — by establishing a communication channel and a contemporary method of sharing social media content. Existing communication channels include print and radio, television and digital media. A dedicated TLD will enable communications via the Internet to be conducted in a forum of trust and legitimacy amongst users, as existing TLDs do not offer users certainty. The .catholic TLD provides certainty as existence of the domain name indicates legitimate affiliation with the Catholic Church, and that content has been approved by said entities. The .catholic TLD would therefore immediately provide trust in the sole registrant (PCCS).

2. Dioceses, religious orders, educational institutions, and other appropriate Church-sanctioned entities: These entities will be granted use of a .catholic domain name in order to carry out activities supportive of the Church. These entities will be granted the use of domain names that highlight the legitimacy of their position. Ease of communication between these organisations would be increased through the addition of a cohesive and authoritative channel for digital communication. For example, different dioceses could get in contact with one another to share their experiences and passing on best-practices to each other. Also, they could collaborate on common issues if they border the same geographical areas. Access to the new TLD platform would enable less advantaged dioceses to achieve higher visibility. This would enable them to maintain a profile equal with dioceses in more developed economies.

3. Members of congregations, members of religious orders, and those involved in any other organisation affiliated with the Church: these individuals will benefit through being able to easily access information pertinent to the Church and its activities with confidence.

4. Internet users: The .catholic TLD will benefit Internet users seeking philosophical direction by granting them access to appropriate content providers. Benefits are expected for the broader Internet community. By providing a space in which Internet users can feel confident about the authenticity of the Church-related institutions they access, the .catholic TLD will help promote the philosophical ideals and aims of the Church.

i. What is the goal of your proposed gTLD in terms of areas of specialty, service levels, or reputation?

GOALS OF THE .CATHOLIC TLD

The primary service offered by the .catholic TLD is the immediate distinction of legitimacy, authoritativeness and relevance that the string provides to Internet users given the authenticated nature of the institutions to which the string will be consigned. 
A high level of trust in the TLD is paramount to its success and high levels of service will be provided to ensure that the TLD space is maintained as intended and not diluted by unqualified registrations.

A high level of service will help maintain the integrity of the TLD. Granting of use of a domain name will only occur following an established method of verification. For example, use of a .catholic domain name will be granted if the Diocese is recognised by the Holy See and there is no formal request from the applicable Bishop to withhold release of the domain for that Diocese.

This focus of service will maintain the attractiveness of the TLD to all of the above-identified beneficiaries.

The goals of the .catholic TLD are described below along with a discussion of the benefits associated with each goal:


RECOGNITION OF THE .CATHOLIC TLD AS THE AUTHORITATIVE SPACE FOR LEGITIMATE CHURCH INSTUTUTIONS:

The PCCS intends that the .catholic TLD will achieve the reputation of being an authoritative space for legitimate Church-related information provided by dioceses, religious orders, and other Church-affiliated institutions — as a result of eligibility for use of a domain name being limited to entities recognised by the Church.

The PCCS intends that among those to whom the use of a domain name may be granted the .catholic TLD will have the reputation of being the official, authoritative online space for religious entities within the Catholic Church. Among Internet users the PCCS intends that the .catholic TLD will have the reputation of being an authoritative and verified space for accessing online Church-related material.

.catholic domain names will be registered in the name of the PCCS and granted for use to an authorised entity — a diocese, religious order or Church affiliated institution. The reputation amongst these authorised entities will be measured by actual use of the domain name by the entities. Periodic audits will be conducted to assess whether the domain name is being used and complies with the acceptable use policy. These audits of domains will ensure that content posted on .catholic domains is congruent with the TLD mission and purposes and adheres to the standards expected of official Church communications. The PCCS’ goal is to see more than 75% of domain names appropriately used within three years of launching the TLD.

The attainment of this reputation amongst Internet users will be measured by reference to visit metrics for .catholic domain names. This will be cross-referenced with demographic data, such as diocese size, to enable a more sound measure of the level of use for a particular .catholic domain.

FUNCTION AS A COMMUNICATION CHANNEL:

The goal is that the .catholic TLD will serve as a privileged method of communication for the Church, by establishing an authoritative and official channel for online communications with the Church’s constituent institutions and its adherents globally.

The .catholic TLD intends to promote the usage of information and communications technologies among the global network of dioceses, religious institutions and entities belonging to the Catholic Church. The purpose is to support the wider Catholic Community and to serve its global outreach. The TLD would also provide a digital platform that connects different cultural and geographically distant communities and enables them to interact and cooperate. This would add new possibilities of access to a diversity of assets and resources, thus expanding the dioceses’ scope of action and hence improving the social conditions of the respective local areas. Also, the TLD would provide for better communication not only among dioceses or religious institutions, but between these and civil entities— attracting the attention of the general public onto the needs of the local communities that are served by the dioceses and religious⁄charitable⁄educational institutions.

The establishment of this communication channel would benefit Internet end-users from the dioceses’ communities by creating a virtual space that promotes the sharing of information, both within the same diocese and between dioceses, religious institutions and entities belonging to the Catholic Church. By building dedicated websites, it would be possible to create a virtual community where members could upload videos, publish communications, write blogs, etc.

PROMOTE THE DEVELOPMENT OF LEGITIMATE CHURCH-RELATED CONTENT ONLINE: 

The goal is that the creation of an authorised space for Church-related information online, will encourage constituent institutions of the Church to publish material online by allaying their concerns regarding illegitimate communication channels, thereby facilitating the sharing of the Church’s teachings. The creation of an authorised space will be supported by restricting domain name registrations to the PCCS; which provides an increased level of security to end-users by providing assurance that those granted use of a domain name are officially recognised, and thus sanctioned to publish the content on the domain name.

The achievement of this goal will be measured by audits to assess whether domain names are used to publish Church-related content, and are compliant with the acceptable use policy.

In summary, the short-term vision of the .catholic TLD is to offer a trusted, verified online space for Church-related communications; this is something that does not exist in the current offering of TLDs. The medium-term vision is to achieve acceptance of the .catholic TLD through significant usage of websites. The PCCS considers that these aspects would be useful measures of the success of the .catholic TLD, and its achievement of the mission⁄purpose described above. The long-term vision for the .catholic TLD is to achieve high acceptance of the TLD through usage by the majority of suitable Church-recognised entities, and by the wide-spread dissemination of information consistent with the Church’s teachings via hosted pages containing appropriate content.

By achieving the above-identified goals, the .catholic TLD will establish itself as a unique, authoritative, dedicated space for organisations within the Church. Internet users would thus be able to safely and confidently access Church-related information provided by official sources, which is consistent with the overall goals and values of the Catholic Church.

ii. What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

ANTICIPATED CONTRIBUTION TO THE CURRENT SPACE

The .catholic TLD will make a significant contribution to the current space in the following ways:


DIFFERENTIATION AND INNOVATION

The .catholic TLD will provide a high level of differentiation from existing TLDs. From a technical viewpoint, whereas existing TLDs often apply to diverse and broad markets, the .catholic TLD will be differentiated by offering only a relatively restricted number of available registrations. Users searching for information pertaining to the Catholic Church will be easily directed to that material via specific applicable sites. Any registration will be sanctioned by the PCCS and hence by the governing structure of the Catholic Church itself, so validity of registrants will be incontrovertible.

By providing a new alternative TLD, present crowding and forecast crowding in existing TLDs will be negated. Non-sanctioned domain name users will not be able to secure similar strings to confuse end-users or to supply controversial content. Non-sanctioned domain names will be identifiable by the absence of a .catholic registration, and the subsequent clear recognition that said content has not been specifically approved for hosting on a .catholic domain.

Although the .catholic TLD is an ASCII string and therefore primarily targeted at English-language audiences, it is imagined that the ultimate audience will be global in scope. The string is widely recognisable in alternative European languages and is suitable to broader audiences.

The restrictions placed on registrations ensure that the information provided by the qualified institutions is reliable and accurate. 

The .catholic TLD will specifically address the need for an authoritative and dedicated online space for Church-affiliated entities to identify themselves as such and to express their beliefs and general information pertaining to the Church and its activities.
The .catholic TLD will directly address internet users’ concerns about the legitimacy of the sources of information available online by restricting registration of domain names to the PCCS. This will enable Internet users in general to make informed choices relating to those issues that are presented on such sites.


COMPETITION

These clear points of differentiation of the .catholic TLD will promote competition amongst existing TLDs by offering domain name users products and services which are currently unavailable in existing TLDs. Because the registration of domain names is restricted to the PCCS, the .catholic TLD will not compete with other TLDs in terms of acquiring registrations, but has a significant competitive advantage in terms of the value received by Internet users. The .catholic TLD promotes competition by making available a unique TLD with uniquely identified registrations and consequent content for Internet users, hence promoting consumer choice. The restriction on the ability to register domain names, is the key to favourably positioning the .catholic TLD in the market.

iii. What goals does your proposed gTLD have in terms of user experience?
iv. Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

REGISTRATION POLICIES IN SUPPORT OF THE GOALS OF THE .CATHOLIC TLD

All domain name registrations in the .catholic TLD will be registered to, and maintained by, the PCCS for the exclusive use of the PCCS and the constituent institutions of the Church. The PCCS will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not identified within the TLD Catholic Community. As such, individual adherents will not be eligible to register or be granted use of .catholic domain names. 

Each recognised diocese (as evidenced by inclusion in the list of affiliates), official religious order of the Catholic Church and Church-affiliated institutions may be granted use of an associated .catholic domain name to establish formal and official channels of online communication for the Catholic Church, and to promote the overall mission⁄purpose of the .catholic TLD. The domain names granted for use by each entity will be the linguistic term most closely related to the official name of each entity, as determined by the PCCS and within the boundaries of protected name limitations. Additionally, the PCCS may in its sole discretion register generic terms for its own use or the use of recognised institutions. The use of the domain names by the PCCS and the recognised institutions is subject to internal acceptable use policies.

This restriction on eligibility ensures the identification of the .catholic TLD with the Catholic Church. It ensures that the information provided is consistent with the official views and teachings of the Catholic Church and thereby enjoys an appropriate authoritativeness. This restriction consequently strengthens the function of the .catholic TLD as a communication channel for the Church, whose authenticity is a result of the verified nature of the recognised institutions. Furthermore, this ensures the consistency and coherence of the information supplied by the different institutions. 

In addition the following restrictions apply to all .catholic domain names:

- the Registry Operator will reserve names in accordance with Specification 5 of the Registry Agreement. The protection of geographic names in the .catholic TLD will be described further in the response to Question 22 — Protection of Geographic Names.

- Domain names will be registered to the PCCS for a one year term.

- .catholic domain names must be used to promote the mission⁄purpose of the TLD and must therefore only host material relating to the Catholic Church in accordance with the acceptable use policy.

Restrictions on who may be granted use of domain names and the acceptable use policy ensure the reliability, the authenticity and trustworthiness of information published. Self-regulation is the initial mechanism in place for this, with existing Church protocols regarding internal disputes to be utilised for any issues relating to registrations or information.

Periodic audits will ensure that these restrictions are adhered to. These restrictions ensure that all domain names will be used to promote the mission⁄purpose of the TLD.

The combination of restrictions on eligibility and use of domain names, and the established methods of internal dispute settlement to govern content matters, will ensure that the advancement of the TLD’s goals relating to establishing an authoritative and legitimate TLD for Church-related communications may be achieved.

v. Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures.

PROTECTION OF PRIVACY AND CONFIDENTIAL INFORMATION

All domain name registrations in the .catholic TLD will be registered to, and maintained by, the PCCS for the exclusive use of the PCCS and the verified institutions. No information in addition to that which is published on WhoIs will be collected from the sole registrant — the PCCS. Therefore, specific measures to protect publically available information are unnecessary.

No obligations will be imposed by the registry operator on registrars in relation to the handling of confidential information. Note the obligations imposed on registrars through the RAA in relation to handling registrant and confidential information.

In order to be granted use of a .catholic domain name, the name of the authorised entities must be verified by the PCCS against a list of formally recognised Church-affiliated institutions. Because only formally recognised entities will be granted use of domain names, and the information that supports this claim (the name of the entity) is not sensitive information, the PCCS does not consider necessary to keep this information confidential. In all cases the PCCS’ Security Policy protects against the misuse of this information.

The PCCS’ Privacy Policy will require that measures are in place to prevent disclosure of confidential information including registrant contact information — other than available through WhoIs, or intentional disclosures to ICANN or law enforcement agencies.


OUTREACH AND COMMINICATION ACTIVITIES

Outreach and communications activities to promote the .catholic TLD will be undertaken through the Church’s channels of communication. Conferences of Bishops will be informed of the benefits of using a .catholic domain. The highly authoritative position that the PCCS holds within the Church will likely result in a high level of uptake following outreach efforts.

The PCCS enjoys a high degree of support in its work to promote the Catholic faith globally, as all dioceses benefit from this work. Diocese-level support for the TLD is therefore assumed to be in place and easily leveraged into use of domain names in the TLD.

The PCCS has existing staff that are employed to promote social media outreach, and the TLD is a natural extension of existing initiatives. Staffing requirements and promotional networks which are in place will be utilised to promote the TLD. The PCCS will directly manage these high-level efforts.

Subsequent to this, local promotion will become the responsibility of the dioceses. The promotion of the TLD by dioceses will serve to increase the value in their own domain names and, by extension, in the TLD itself. Appropriate use of registrations will help strengthen the dioceses’ positions in the local communities, a goal that is embraced both by the global Church structure and by local establishments.

The awareness generated through outreach and communications activities described above are critical to the achievement of the goals of the .catholic TLD. With a broad uptake, the Church would enjoy a new communication channel which would enable it to reach of its own members and the general public.

This is in accordance with the overall aims of the PCCS, having over 40 years’ experience in utilising media to promote the Catholic faith, and this places PCCS in a strong position to successfully add communications via the .catholic TLD to its existing range of communication methods.

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?

INTRODUCTION
All domain name registrations in the .catholic TLD will be registered to, and maintained by, the PCCS for the exclusive use of the PCCS and the constituent institutions of the Church. The PCCS will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not identified within the TLD Catholic Community. As such, individual adherents will not be eligible to register or be granted use of .catholic domain names.
The PCCS will maintain a high degree of control over the TLD as facilitated by the eligibility restrictions criteria and internal policies and processes. The PCCS has interpreted this question broadly and prepared this response to consider social costs and other negative consequences facing the consumers and internet users who will access content through the .catholic TLD; the PCCS considers these likewise eliminated or minimised by the manner in which it will operate the TLD.


i. How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

METHOD OF RESOLVING MULTIPLE APPLICATIONS

Multiple applications for the same domain names are not anticipated in the .catholic TLD because domain name registrations will be registered for the exclusive use of the Catholic Church and its constituent institutions. Use of domain names will be granted to all dioceses, religious orders and institutions affiliated with the PCCS. Each of these entities possesses a unique denomination which is different from the others. Therefore every authorised entity will only seek to use a .catholic domain name that identifies their own name, so problems of competitive applications for the same name are not foreseen.

Registrations will not be generally available as eligibility to register domain names is limited to members of the TLD Catholic Community, resulting in no competing interests and no risk of multiple applications. The decision-making authority as to which domain names will be registered and for which purposes, will vest in a single office; this will be addressed through internal processes regarding domain name registration, which will require approvals within established reporting lines and the use of a username and password to register domain names. Compliance with these processes will ensure that multiple applications do not arise. Registration in the .catholic TLD will effectively be first-come, first-served at all stages of registration (sunrise and general registration).


ii. Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

COST BENEFITS TO REGISTRANTS

The gTLD will be developed by the PCCS as a service to the constituent institutions. The community nature of this application ensures the maximum sensitivity to the needs and requirements of the registrants. 


iii. Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.


CONTRACTUAL COMMITMENTS TO REGISTRANTS

All registrations will be subject to negotiations between the PCCS and the community institutions. This will ensure a consensual resolution of all issues relating to the ongoing development of the project. 


OTHER OPERATING RULES WHICH ELIMINATE OR MINIMISE SOCIAL COSTS

By imposing strict eligibility restrictions and internal processes regarding domain name registration and restricting the .catholic TLD to uses that clearly support its mission⁄purpose, the PCCS anticipates that vulnerabilities to itself as the sole registrant, and to the Internet public who accesses content through the TLD, would be eliminated through internal policies and procedures which ensure that registrations are made by authorised representatives using established reporting lines. Abusive registrations and misuse of registrations will be prevented by having in place and enforcing a robust anti-abuse policy. This policy is described in detail in the response to Question 28 on Abuse Prevention and Mitigation mechanisms.

Yes

The .catholic TLD belongs to the category of community-based Top-Level Domains. The applicant is the Pontifical Council for Social Communications, henceforth referred to as “PCCS” (in Latin, Pontificium Consilium de Comunicationibus Socialibus). The PCCS is a Dicastery of the Holy See, the governing body of the Catholic Church.
The .catholic TLD belongs to the category of community-based Top-Level Domains. The applicant is the Pontifical Council for Social Communications, henceforth referred to as “PCCS” (in Latin, Pontificium Consilium de Comunicationibus Socialibus). The PCCS is a Dicastery of the Holy See, the governing body of the Catholic Church.
By applying for the .catholic TLD, the PCCS is committed to carrying out its mission of serving the community of the Catholic Church, and in particular its member institutions, including Dioceses, Religious Orders, Institutes of Consecrated Life and organizations affiliated to the Catholic Church.
The “Holy See” is internationally acknowledged to be the highest juridical authority of the Catholic Church, being governed by the Pope, also referred to as “the Supreme Pontiff of the Universal Catholic Church”. For instance, the U.S. Department of State states that “the “Holy See” is the universal government of the Catholic Church and operates from Vatican City State, a sovereign, independent territory […]. The Pope is the ruler of both Vatican City State and the Holy See. The Holy See, as the supreme body of government of the Catholic Church, is a sovereign juridical entity under international law.” (ref. http:⁄⁄www.state.gov⁄r⁄pa⁄ei⁄bgn⁄3819.htm).
As far as the Catholic Church is concerned, it has a long history and traces its origins to the teachings of Jesus Christ (c.33 A.D.).
The Catholic Church has a highly elaborated understanding of its own nature. This understanding is informed primarily by its theological conviction that the Church is both a visible and a spiritual reality. For the purpose of clearly defining the community for whose benefit the .catholic TLD will be operated, the PCCS understands that it must focus on the institutional and visible dimensions of the Church.
From the beginning, the Catholic Church has availed of structures of communities in order to realize its mission and its identity. These communities include both the “territorial communities”, also called “particular Churches” (i.e. dioceses and other territorial equivalents, such as territorial prelatures, territorial abbacies, vicariates apostolic, prefectures apostolic and permanently established apostolic administrations, etc.), the “membership-based communities” (i.e. Religious Orders and Institutes of Consecrated Life) and “institutionalized activities” of the Catholic Church (including institutions affiliated to the Catholic Church which provide educational, healthcare, communications and charitable services).
The above-mentioned structures are intended to be the beneficiaries of the subject TLD, namely the targets of the second level domains. For the purpose of this application, said territorial communities (e.g. New York, Westminster, Manila), membership-based communities (e.g. Jesuits, Franciscans, Mercy Sisters) and institutionalized activities (e.g. Catholic Universities and Hospitals) will be henceforth referred to as the “TLD Catholic Community”.
HOW THE COMMUNITY IS DELINEATED FROM INTERNET USERS GENERALLY:
The TLD Catholic Community is delineated from the broader Catholic Church and Internet users generally by its direct connection to the Holy See. The .catholic TLD thus serves to represent the community of Catholic institutions that acknowledge the authority of the Holy See.
The majority of the members of the TLD Catholic Community are identified in the Annuario Pontificio (most updated version as of year 2012), which is the annual directory of institutions related to the Holy See. It lists in a comprehensive and authoritative manner all the governmental offices of the Holy See, as well as the territorial and membership-based communities that are related to the Catholic Church. The remaining members of the TLD Catholic Community, the Catholic institutionalized activities, although not named in the Annuario Pontificio, are nevertheless affiliated to the Holy See. Such a delineation of the TLD Catholic Community is based on the understanding that its members serve the many believers, adherents, parishes, schools, hospitals and charitable activities that fall within the Church’s own broader view of the Catholic community.
STRUCTURE AND ORGANISATION OF THE COMMUNITY:
As specified in Articles 368 and 573 of the Code of Canon Law, the Catholic Community is basically structured into “territorial” and “membership-based” communities as well as institutionalized activities.
“Territorial communities”, which are represented by dioceses and other territorial equivalents, are overseen by a Bishop or equivalent who is responsible for the ordinary governance of that unit. At the same time, each diocese includes different parishes overseen by the Bishop himself. If a diocese is composed of a notable number of parishes, or if it has acquired particular historical relevance, it is called “archdiocese”, and its Bishop is called “Archbishop”.
National Bishops’ Conferences support the work of diocesan Bishops by co-coordinating certain activities and by providing shared services and logistical assistance as is deemed appropriate. There exist also Regional and Continental Conferences involving representatives of the National Conferences. Again, the purpose of these structures is to co-ordinate at the regional and continental level common activities of Bishops. These Conferences assist the individual Bishops but ultimately each Bishop remains personally responsible for the management of his diocese.
Membership-based communities are constituted by established “religious communities” whose members have committed themselves to live a more radical form of service in accordance with the traditions of the communities. These communities have emerged from groups who have dedicated themselves to particular forms of service within the broader Catholic community. These particular communities have their own governance structure and their own specific responsibilities within the life of the Church. The principal global institutes are guided in their activities and internal structures by the Congregation for the Institutes of Consecrated Life and Societies of Apostolic Life (Arts. 105-111 of the Apostolic Constitution Pastor Bonus). The Congregation maintains an official listing of such Institutes, which is published in the Annuario Pontificio.
The community is also constituted by institutions which are responsible for the provision of specific services to the broader Church community, both at the global and local levels. These institutions have their own autonomy insofar as their existence is provided for by their establishment as public juridical bodies (the equivalent within Canon Law to corporations). These institutions include the departments of the Holy See, healthcare, educational, charitable services and communications providers.
ESTABLISHMENT:
In a broad sense, it is possible to say that the Catholic community roots originate in the times of Jesus Christ. However, from an historical point of view, the establishment of the Catholic Church can be traced back to its social affirmation in the Roman Empire. Sporadic and then systematic persecutions of the Christian communities within the I-III Century A.D. in the Roman Empire provide ample evidence of the presence and structure of the Christian communities which gained their official and political recognition as an institution through the Edict of Milan in 313 A.D., by the Roman Emperor Constantine I. With the collapse of the Western Roman Empire, the Christian community rapidly gained political recognition as established by the political treaties si

RELATION BETWEEN PCCS AND THE TLD CATHOLIC COMMUNITY:
The Applicant, PCCS, is a Dicastery of the Holy See and thus is itself a member of the TLD Catholic Community. The PCCS is also an officially acknowledged representative of the Catholic Church in matters of social communications, as it is documented by the Apostolic Constitution “Pastor Bonus”, promulgated by Pope John Paul II on 28 June 1988. In this mission it supports the actions of the Church and its institutions by coordinating and handling all the forms of social communication such as newspapers and periodicals, as well as films and radio or television broadcasts and web based communications.
In performing its duties, the PCCS has strong relations with the various dioceses, religious orders and institutions. There are a number of already existing and well-established procedures that could be drawn upon as a basis for the coordination of the TLD Catholic Community on the digital platform.
The PCCS avails of the periodic “ad limina” visits of National Bishops’ Conferences to maintain contact with representatives of local churches. Each Bishops’ Conference visits Rome every five years – prior to the visit each Bishop sends a report on the state of his diocese in which he sets out, inter alia, the situation pertaining to communications. During the visit, the Bishops meet with the PCCS in order to allow for discussion of the reports and of other matters of interest.
At the same time, in line with its mission to serve the community, the PCCS has organized five International Congresses focusing on the impact of new technologies and the digital culture on Catholic TV stations, Catholic faculties of communications, Catholic Radio stations, Catholic print media and those Bishops who are responsible for the promotion of communications at the level of National Bishops’ Conferences. These Congresses are well attended and involve representatives of over 120 countries.
The PCCS seeks to be present at the more significant meetings of Church communicators at continental and national levels.
At continental level, there are regular gatherings of National Conferences’ representatives. The purpose of these meetings is to co-ordinate at the regional and continental level common activities of Bishops. The PCCS has strong relations with these groups as communications has emerged as a theme of particular interest. The continental groups in Africa (SECAM), North America, Asia (FABC), Latin America (CELAM), Europe (CCEE) and Oceania (FCBCO) all have specific offices and committees focusing on the co-ordination of communications activities. The PCCS is represented at the annual meetings of such groups and maintains close contact with the national representatives.
The PCCS also attends many National Conferences to deliver seminars which promote the importance of communications whilst addressing specific opportunities and challenges of new information technologies and social media. In the last two years, the PCCS has delivered seminars in Brazil, Cuba, Chile, Kenya, Tanzania, Bangladesh and Belorussia.
The positive response from representatives of the “particular churches” to the initiatives of the Pontifical Council and the invitations issuing from them to the PCCS to be present at their gatherings and assemblies testify to the standing of the PCCS within the global community of Catholic communicators.
ACCOUNTABILITY OF THE PCCS TO THE TLD CATHOLIC COMMUNITY:
Art. 41 of Apostolic Constitution “Pastor Bonus” states that it is the task of the Secretariat of State, which is the highest governmental structure in the organizational chart of the Holy See, “to expedite the business concerning the daily service of the Supreme Pontiff” and, in accordance with Art. 169 of the same Constitution, the PCCS, as dicastery of the Holy See, is accountable to the Secretariat of State. Thus, PCCS is institutionally charged to co-ordinate the activities of the whole TLD Catholic Community with reference to communications.
The ultimate accountability of the PCCS to the TLD Catholic Community will be established by the willingness of that community to partake in the gTLD project. The PCCS is confident on the basis of its ongoing relations with the broader community that there will be a significant interest in the project. The Pontifical Council will establish an Advisory Group with representatives of the dioceses and of the religious communities in order to develop the gTLD project and to ensure that its development is responsive to the needs and concerns of the constituent members of the community.
Four Community Endorsement Letters are provided in attachment to Question 20(f):
- Q20f_Community Endorsement Letter from the Vaticanʹs Secretariat of State;
- Q20f_Community Endorsement Letter from the Bishopsʹ Conference of Australia;
- Q20f_Community Endorsement Letter from the Bishopsʹ Conference of the USA;
- Q20f_Community Endorsement Letter from the Bishopsʹ Conference of Italy.

COMMUNITY-BASED PURPOSE OF THE APPLIED-FOR GTLD:
The community-based purpose of the .catholic TLD is to enable the TLD Catholic Community to achieve the mission⁄purpose of the TLD, which is to: disseminate the teachings, message and values of the Catholic Church to its own members and to the wider global community by creating a dedicated, authoritative online space for the exclusive use of the Catholic Church and its constituent institutions and for the benefit of its adherents globally.
The .catholic TLD offers members of the TLD Catholic Community the opportunity to register domain names in an authenticated space and use these to promote and achieve the mission⁄purpose of the TLD.
INTENDED REGISTRANTS IN THE .CATHOLIC TLD:
The .catholic TLD is a dedicated and authoritative communications structure for the exclusive use of the TLD Catholic Community. The PCCS, a member of this Community, is ideally situated to facilitate the fulfillment of this purpose as the sole registrant given that it is specifically tasked by the Apostolic Constitution Pastor Bonus with the dissemination of teachings, messages and values of the Catholic Church through communications media. Registrations in the .catholic TLD will therefore be made exclusively by the PCCS.
INTENDED END-USERS OF THE .CATHOLIC TLD:
Through its role as sole registrant, the PCCS serves as representative of the many members of the TLD Catholic Community, who collectively are the intended end-users of the .catholic TLD. Such end-users are the members of territorial communities, membership-based communities and institutionalized activity structures of the Catholic Church.
All domain name registrations in the .catholic TLD will be registered to, and maintained by, the PCCS for the exclusive use of the PCCS and of the other members of the TLD Catholic Community as defined above.
LASTING NATURE OF COMMUNITY BASED PURPOSE:
The purpose of the .catholic TLD is to enable the PCCS and the other members of the TLD Catholic Community to disseminate the teachings, message and values of the Catholic Church. As established by the centuries long history of the Catholic Church, the TLD Catholic Community itself and its purpose are of a lasting nature.
ACTIVITIES BY PCCS IN SERVICE OF THE COMMUNITY BASED PURPOSE:
As explained above in the context of accountability, the PCCS has a long-established relationship with other members of the .catholic TLD Community. This relationship involves the ongoing presence of the PCCS at various assemblies and meetings of members of the .catholic TLD Community, particularly those responsible for communications. The rollout and development of the .catholic TLD will become a particular focus for these established activities. These meetings and assemblies will provide the PCCS with the opportunity to explain and promote to other members of the TLD Catholic Community the .catholic TLD and its use as a tool in social communication. On the basis of its success in carrying out its existing mission, the PCCS is confident that the .catholic TLD will be viewed as a natural extension of this existing mission. The PCCS is also confident that the .catholic TLD will be warmly welcomed by the TLD Catholic Community because it addresses a perceived need to assure the authentication of the Catholic presence in the online environment.

RELATIONSHIP BETWEEN THE APPLIED FOR GTLD STRING AND THE COMMUNITY IDENTIFIED IN 20(A):
The term “Catholic” is universally and consistently used to designate the Universal Church, which is led by the Pope as the Supreme Pontiff, and the affiliated institutions and adherents of this Church. In its own teachings, the Catholic Church uses the term “Catholic” as a clear identifier; for example, the definitive presentation and explanation of the Church’s beliefs is called “The Catechism of the Catholic Church”.
The term “Catholic” has been used in this manner for centuries, the first example of this being found in the Letter of Ignatius of Antioch in c.110 A.D. - and recurs frequently from that time on.
Some examples of this usage from antiquity are as follows:
“Wherever the Bishop shall appear, there let the multitude [of the people] also be; even as, wherever Jesus Christ is, there is the Catholic Church.”
c.110 A.D.- St. Ignatius, Epistle to the Smyrnaeans
“We say that both in substance and in seeming, both in origin and in development, the primitive and Catholic Church is the only one, agreeing as it does in the unity of one faith.”
c.202 A.D. - Clement of Alexandria
“Now it [the Church] is called Catholic because it is throughout the world, from one end of the earth to the other”.
c.347 A.D. - St. Cyril of Jerusalem
RELATIONSHIP TO THE IDENTIFICATION OF COMMUNITY MEMBERS:
The word “Catholic” is frequently used to specify the identity of territorial communities, membership-based communities and institutionalized activities. Very often, a diocese is identified as the “Catholic diocese of…” or the Bishop is identified as the “Catholic Bishop”. Similarly, in secular reporting, it is common to identify religious orders and communities such as the Jesuits as “Catholic”.

DESCRIPTION OF THE APPLICANT’S INTENDED REGISTRATION POLICIES
Eligibility:
The eligibility to register a domain name within the .catholic TLD will be restricted to the PCCS and the PCCS alone. Use of a .catholic domain name may be granted at the sole discretion of the PCCS to an affiliate such as recognised dioceses, religious orders and Catholic Church-affiliated institutions. The PCCS maintains a list of affiliates formally recognised by the Holy See as being part of the Catholic Church and thus being eligible to be granted use of a .catholic domain name. This list is primarily based on, however not exclusively, on the Annuario Pontificio (the official annual directory of all institutions related to the Holy See).
In support of the mission and purpose of the .catholic TLD, the use of .catholic domains will be subject to an acceptable use policy which governs the use and outlines acceptable content for hosting within .catholic domain. Prior to use of a .catholic TLD being granted, the ultimate user of each domain must have read and agreed to the acceptable use policy.
Name Selection:
Selection of names for domains within the .catholic TLD will be administered by the PCCS in collaboration with the applicants for said domains. The type of second-level domain names that may be registered in the TLD will include the most closely related linguistic term to the official name of the affiliate as per the Annuario Pontificio within the boundaries of protected name limitations. The PCCS, at its sole discretion, may also register generic terms for its own use or the use of affiliates to further support the Mission and Purpose of the .catholic TLD. All names will be assigned in accordance with Specification 5 of the Registry Agreement.
Content and Use:
The use of a .catholic domain by the PCCS or an affiliate will be governed by an acceptable use policy. This policy stipulates that content and use of domains in the .catholic TLD are supportive of the Mission and Purpose of the TLD and are used in an acceptable fashion to assist with sharing the message and teachings of the Catholic Church.
Registrations within the .catholic TLD will be initially for a one (1) year term only. Prior to expiry of each registration, use of each domain will be reviewed and renewal will occur should the domain be in use and comply with the guidelines of the acceptable use policy.
Enforcement:
On a regular basis, the Project Manager in charge of the .catholic TLD will be required to undertake an audit of all registrations within the .catholic TLD. This will be undertaken in liaison with personnel from the National Bishops’ Conferences. The audit will ensure that all domain names created have been authorised and comply with name selection policies. This is to ensure that all domain names are the closest related linguistic term to the name of an affiliate according to the Annuario Pontificio and no breach of Specification 5 of the registry agreement has occurred.
As the single registrant, the PCCS exercises a significant amount of control over registrations within the .catholic TLD. An acceptable use policy has also been developed so affiliates understand their responsibilities and what constitutes acceptable use and content of a .catholic domain name. In conjunction with this, the PCCS being part of the Holy See, is held in high regard within the Catholic Community and therefore any directive to an affiliate will be taken seriously and recommended actions will be acted upon as a matter of priority. Through this, we anticipate that the likelihood of a breach of policy will be minimal.

Not Available

No

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. This response describes protection of geographic names as implemented by ARI.

1 PROTECTION OF GEOGRAPHIC NAMES

In accordance with Specification 5 of the New gTLD Registry Agreement, the registry operator must initially reserve all geographic names at the second level, and at all other levels within the TLD at which the registry operator provides for registrations.
ARI supports this requirement by using the following internationally recognised lists to develop a comprehensive master list of all geographic names that are initially reserved:
– The 2-letter alpha-2 code of all country and territory names contained on the ISO 3166-1 list, including all reserved and unassigned codes [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm].
– The short form (in English) of all country and territory names contained on the ISO 3166-1 list, including the European Union, which is exceptionally reserved on the ISO 3166-1 List, and its scope extended in August 1999 to any application needing to represent the name European Union [http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166-1_decoding_table.htm#EU].
– The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardisation of Geographical Names, Part III Names of Countries of the World. This lists the names of 193 independent States generally recognised by the international community in the language or languages used in an official capacity within each country and is current as of August 2006 [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄ungegn%20tech%20ref%20manual_M87_combined.pdf].
– The list of UN member states in six official UN languages prepared by the Working Group on Country Names of the United Nations Conference on the standardisation of Geographical Names [http:⁄⁄unstats.un.org⁄unsd⁄geoinfo⁄UNGEGN⁄docs⁄9th-uncsgn-docs⁄econf⁄9th_UNCSGN_e-conf-98-89-add1.pdf].
Names on this reserved list in ARI’s registry system are prevented from registration.
A corresponding list of geographic names will also be available to the public via the registry operators website, to inform Registrars and potential registrants of reserved names. The lists noted above, are regularly monitored for revisions, therefore the reserved list (both within the registry and publicly facing) will be continually updated to reflect any changes.
The following applies to all Domain Names contained within the registry’s reserved list:
– Attempts to register listed Domain Names will be rejected.
– WhoIs queries for listed Domain Names will receive responses indicating their reserved status.
– Reserved geographic names will not appear in the TLD zone file.
– DNS queries for reserved domain names will result in an NXDOMAIN response.

2 PROCEDURES FOR RELEASE

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

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. This response describes the registry services for our TLD, as provided by ARI.

1 INTRODUCTION

ARI’s Managed TLD Registry Service is a complete offering, providing all of the required registry services. What follows is a description of each of those services.

2 REGISTRY SERVICES
The following sections describe the registry services provided. Each of these services has, where required, been designed to take into account the requirements of consensus policies as documented here:
[http:⁄⁄www.icann.org⁄en⁄resources⁄Registrars⁄consensus-policies]
At the time of delegation into the root this TLD will not be offering any unique Registry services.

2.1 Receipt of Data from Registrars

The day-to-day functions of the registry, as perceived by Internet users, involves the receipt of data from Registrars and making the necessary changes to the SRS database. Functionality such as the creation, renewal and deletion of domains by Registrars, on behalf of registrants, is provided by two separate systems:
– An open protocol-based provisioning system commonly used by Registrars with automated domain management functionality within their own systems.
– A dedicated website providing the same functionality for user interaction.
Registrants (or prospective registrants) who wish to manage their existing domains or credentials, register new domains or delete their domains will have their requests carried out by Registrars using one of the two systems described below.
ARI operates Extensible Provisioning Protocol (EPP) server software and distributes applicable toolkits to facilitate the receipt of data from Registrars in a common format. EPP offers a common protocol for Registrars to interact with SRS data and is favoured for automating such interaction in the Registrar’s systems. In addition to the EPP server, Registrars have the ability to use a web-based management interface (SRS Web Interface), which provides functions equivalent to the EPP server functionality.

2.1.1 EPP

The EPP software allows Registrars to communicate with the SRS using a standard protocol. The EPP server software is compliant with all appropriate RFCs and will be updated to comply with any relevant new RFCs or other new standards, as and when they are finalised. All standard EPP operations on SRS objects are supported.
Specifically, the EPP service complies with the following standards:
– RFC 5730 Extensible Provisioning Protocol (EPP)
– RFC 5731 Extensible Provisioning Protocol (EPP) Domain Name Mapping
– RFC 5732 Extensible Provisioning Protocol (EPP) Host Mapping
– RFC 5733 Extensible Provisioning Protocol (EPP) Contact Mapping
– RFC 5734 Extensible Provisioning Protocol (EPP) Transport over TCP
– RFC 5910 Domain Name System (DNS) Security Extensions for the Extensible Provisioning Protocol (EPP)
– RFC 3915 Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
– Extensions to ARI’s EPP service comply with RFC 3735 Guidelines for Extending the Extensible Provisioning Protocol (EPP)

2.1.1.1 Security for EPP Service

To avoid abuse and to mitigate potential fraudulent operations, the EPP server software uses a number of security mechanisms that restrict the source of incoming connections and prescribe the authentication and authorisation of the client. Connections are further managed by command rate limiting and are restricted to only a certain number for each Registrar, to help reduce unwanted fraudulent and other activities. Additionally, secure communication to the EPP interface is required, lowering the likelihood of the authentication mechanisms being compromised.
The EPP server has restrictions on the operations it is permitted to make to the data within the registry database. Except as allowed by the EPP protocol, the EPP server cannot update the credentials used by Registrars for access to the SRS. These credentials include those used by Registrars to login to ARI’s SRS Web Interface and the EPP service.
Secure communication to the EPP server is achieved via the encryption of EPP sessions. The registry system and associated toolkits support AES 128 and 256 via TLS.
The Production and Operational Testing and Evaluation (OTE) EPP service is protected behind a secure firewall that only accepts connections from registered IP addresses. Registrars are required to supply host IP addresses that they intend to use to access the EPP service.
Certificates are used for encrypted communications with the registry. Registrars require a valid public⁄private key pair signed by the ARI CA to verify authenticity. These certificates are used to establish a TLS secure session between client and server.
EPP contains credential elements in its specification which are used as an additional layer of authentication. In accordance with the EPP specification, the server does not allow client sessions to carry out any operations until credentials are verified.
The EPP server software combines the authentication and authorisation elements described above to ensure the various credentials supplied are associated with the same identity. This verification requires that:
– The username must match the common name in the digital certificate.
– The certificate must be presented from a source IP listed against the Registrar whose common name appears in the certificate.
– The username and password must match the user name and password listed against the Registrar’s account with that source IP address.
To manage normal operations and prevent an accidental or intentional Denial of Service, the EPP server can be configured to rate limit activities by individual Registrars.

2.1.1.2 Stability Considerations

The measures that restrict Registrars to a limit of connections and operations for security purposes also serve to keep the SRS and the EPP server within an acceptable performance and resource utilisation band. Therefore, scaling the service is an almost linear calculation based on well-defined parameters.
The EPP server offers consistent information between Registrars and the SRS Web Interface. The relevant pieces of this information are replicated to the DNS within seconds of alteration, thus ensuring that a strong consistency between the SRS and DNS is maintained at all times.

2.1.2 SRS Web Interface

The registry SRS Web Interface offers Registrars an alternative SRS interaction mechanism to the EPP server. Available over HTTPS, this interface can be used to carry out all operations which would otherwise occur via EPP, as well as many others. Registrars can use the SRS Web Interface, the EPP server interface or both – with no loss of consistency within the SRS.

2.1.2.1 Security and Consistency Considerations for SRS Web Interface

The SRS Web Interface contains measures to prevent abuse and to mitigate fraudulent operations. By restricting access, providing user level authentication and authorisation, and protecting the communications channel, the application limits both the opportunity and scope of security compromise.
Registrars are able to create individual users that are associated with their Registrar account. By allocating the specific operations each user can access, Registrars have full control over how their individual staff members interact with the SRS. Users can be audited to identify which operations were conducted and to which objects those operations were applied.
A secure connection is required before credentials are exchanged and once authenticated. On login, any existing user sessions are invalidated and a new session is generated, thereby mitigating session-fixation attacks and reducing possibilities that sessions could be compromised.

2.1.3 Securing and Maintaining Consistency of Registry-Registrar Interaction Systems

ARI ensures all systems through which Registrars interact with the SRS remain consistent with each other and apply the same security rules. Additionally, ARI also ensures that operations on SRS objects are restricted to the appropriate entity. For example:
– In order to initiate a transfer a Registrar must provide the associated domain password (authinfo) which will only be known by the registrant and the current sponsoring Registrar.
– Only sponsoring Registrars are permitted to update registry objects.
All operations conducted by Registrars on SRS objects are auditable and are identifiable to the specific Registrar’s user account, IP address and the time of the operation.

2.2 Disseminate Status Information of TLD Zone Servers to Registrars

The status of TLD zone servers and their ability to reflect changes in the SRS is of great importance to Registrars and Internet users alike. ARI will ensure that any change from normal operations is communicated to the relevant stakeholders as soon as is appropriate. Such communication might be prior to the status change, during the status change and⁄or after the status change (and subsequent reversion to normal) – as appropriate to the party being informed and the circumstance of the status change.
Normal operations are those when:
– DNS servers respond within SLAs for DNS resolution.
– Changes in the SRS are reflected in the zone file according to the DNS update time SLA.
The SLAs are those from Specification 10 of the Registry Agreement.
A deviation from normal operations, whether it is registry wide or restricted to a single DNS node, will result in the appropriate status communication being sent.

2.2.1 Communication Policy

ARI maintains close communication with Registrars regarding the performance and consistency of the TLD zone servers.
A contact database containing relevant contact information for each Registrar is maintained. In many cases, this includes multiple forms of contact, including email, phone and physical mailing address. Additionally, up-to-date status information of the TLD zone servers is provided within the SRS Web Interface.
Communication using the Registrar contact information discussed above will occur prior to any maintenance that has the potential to effect the access to, consistency of, or reliability of the TLD zone servers. If such maintenance is required within a short time frame, immediate communication occurs using the above contact information. In either case, the nature of the maintenance and how it affects the consistency or accessibility of the TLD zone servers, and the estimated time for full restoration, are included within the communication.
That being said, the TLD zone server infrastructure has been designed in such a way that we expect no down time. Only individual sites will potentially require downtime for maintenance; however the DNS service itself will continue to operate with 100% availability.

2.2.2 Security and Stability Considerations

ARI restricts zone server status communication to Registrars, thereby limiting the scope for malicious abuse of any maintenance window. Additionally, ARI ensures Registrars have effective operational procedures to deal with any status change of the TLD nameservers and will seek to align its communication policy to those procedures.

2.3 Zone File Access Provider Integration

Individuals or organisations that wish to have a copy of the full zone file can do so using the Zone Data Access service. This process is still evolving; however the basic requirements are unlikely to change. All registries will publish the zone file in a common format accessible via secure FTP at an agreed URL.

ARI will fully comply with the processes and procedures dictated by the Centralised Zone Data Access Provider (CZDA Provider or what it evolves into) for adding and removing Zone File access consumers from its authentication systems. This includes:

– Zone file format and location
– Availability of the zone file access host via FTP
– Logging of requests to the service (including the IP address, time, user and activity log)
– Access frequency

2.4 Zone File Update

To ensure changes within the SRS are reflected in the zone file rapidly and securely, ARI updates the zone file on the TLD zone servers using software compliant with RFC 2136 (Dynamic Updates in the Domain Name System (DNS UPDATE)) and RFC 2845 (Secret Key Transaction Authentication for DNS (TSIG)).
This updating process follows a staged but rapid propagation of zone update information from the SRS, outwards to the TLD zone servers – which are visible to the Internet. As changes to the SRS data occur, those changes are updated to isolated systems which act as the authoritative primary server for the zone, but remain inaccessible to systems outside ARI’s network. The primary servers notify the designated secondary servers, which service queries for the TLD zone from the public. Upon notification, the secondary servers transfer the incremental changes to the zone and publicly present those changes.
The protocols for dynamic update are robust and mature, as is their implementation in DNS software. The protocols’ mechanisms for ensuring consistency within and between updates are fully implemented in ARI’s TLD zone update procedures. These mechanisms ensure updates are quickly propagated while the data remains consistent within each incremental update, regardless of the speed or order of individual update transactions. ARI has used this method for updating zone files in all its TLDs including the .au ccTLD, pioneering this method during its inception in 2002. Mechanisms separate to RFC 2136-compliant transfer processes exist; to check and ensure domain information is consistent with the SRS on each TLD zone server within 10 minutes of a change.

2.5 Operation of Zone Servers

ARI maintains TLD zone servers which act as the authoritative servers to which the TLD is delegated.

2.5.1 Security and Operational Considerations of Zone Server Operations

The potential risks associated with operating TLD zone servers are recognised by ARI such that we will perform the steps required to protect the integrity and consistency of the information they provide, as well as to protect the availability and accessibility of those servers to hosts on the Internet. The TLD zone servers comply with all relevant RFCs for DNS and DNSSEC, as well as BCPs for the operation and hosting of DNS servers. The TLD zone servers will be updated to support any relevant new enhancements or improvements adopted by the IETF.
The DNS servers are geographically dispersed across multiple secure data centres in strategic locations around the world. By combining multi-homed servers and geographic diversity, ARI’s zone servers remain impervious to site level, supplier level or geographic level operational disruption.
The TLD zone servers are protected from accessibility loss by malicious intent or misadventure, via the provision of significant over-capacity of resources and access paths. Multiple independent network paths are provided to each TLD zone server and the query servicing capacity of the network exceeds the extremely conservatively anticipated peak load requirements by at least 10 times, to prevent loss of service should query loads significantly increase.
As well as the authentication, authorisation and consistency checks carried out by the Registrar access systems and DNS update mechanisms, ARI reduces the scope for alteration of DNS data by following strict DNS operational practices:
– TLD zone servers are not shared with other services.
– The primary authoritative TLD zone server is inaccessible outside ARI’s network.
– TLD zone servers only serve authoritative information.
– The TLD zone is signed with DNSSEC and a DNSSEC Practice⁄Policy Statement published.

2.6 Dissemination of Contact or Other Information

Registries are required to provide a mechanism to identify the relevant contact information for a domain. The traditional method of delivering this is via the WhoIs service, a plain text protocol commonly accessible on TCP port 43. ARI also provides the same functionality to users via a web-based WhoIs service. Functionality remains the same with the web-based service, which only requires a user to have an Internet browser.
Using the WhoIs service, in either of its forms, allows a user to query for domain-related information. Users can query for domain details, contact details, nameserver details or Registrar details.
A WhoIs service, which complies with RFC 3912, is provided to disseminate contact and other information related to a domain within the TLD zone.

2.6.1 Security and Stability Considerations

ARI ensures the service is available and accurate for Internet users, while limiting the opportunity for its malicious use. Many reputation and anti-abuse services rely on the availability and accuracy of the WhoIs service, however the potential for abuse of the WhoIs service exists.
Therefore, certain restrictions are made to the access of WhoIs services, the nature of which depend on the delivery method – either web-based or the traditional text-based port 43 service. In all cases, there has been careful consideration given to the benefits of WhoIs to the Internet community, as well as the potential harm to registrants – as individuals and a group – with regard to WhoIs access restrictions.
The WhoIs service presents data from the registry database in real time. However this access is restricted to reading the appropriate data only. The WhoIs service does not have the ability to alter data or to access data not related to the WhoIs service. The access limitations placed on the WhoIs services prevent any deliberate or incidental denial of service that might impact other registry services.
Restrictions placed on accessing WhoIs services do not affect legitimate use. All restrictions are designed to target abusive volume users and to provide legitimate users with a fast and available service. ARI has the ability to ‘whitelist’ legitimate bulk users of WhoIs, to ensure they are not impacted by standard volume restrictions.
The data presentation format is consistent with the canonical representation of equivalent fields, as defined in the EPP specifications and ICANN agreement.

2.6.1.1 Port 43 WhoIs

A port 43-based WhoIs service complying with RFC 3912 is provided and will be updated to meet any other relevant standards or best practice guidelines related to the operation of a WhoIs service.
While the text-based service can support thousands of simultaneous queries, it has dynamic limits on queries per IP address to restrict data mining efforts. In the event of identified malicious use of the service, access from a single IP address or address ranges can be limited or blocked.

2.6.1.2 Web-based WhoIs

ARI’s web-based WhoIs service provides information consistent with that contained within the SRS.
The web-based WhoIs service contains an Image Verification Check (IVC) and query limits per IP address. These restrictions strike a balance between acceptable public usage and abusive use or data mining. The web-based WhoIs service can blacklist IP addresses or ranges to prevent abusive use of the service.

2.7 IDNs – Internationalised Domain Names

An Internationalised Domain Name (IDN) allows registrants to register domains in their native language and have it display correctly in IDN aware software. This includes allowing a language to be read in the manner that would be common for its readers. For example, an Arabic domain would be presented right to left for an Arabic IDN aware browser.
The inclusion of IDNs into the TLD zones is supported by ARI. All the registry services, such as the EPP service, SRS Web Interface and RDPS (web and port 43), support IDNs. However there are some stability and security considerations related to IDNs which fall outside the general considerations applicable individually to those services.

2.7.1 Stability Considerations Specific to IDN

To avoid the intentional or accidental registration of visually similar chars, and to avoid identity confusion between domains, there are several restrictions on the registration of IDNs.

2.7.1.1 Prevent Cross Language Registrations

Domains registered within a particular language are restricted to only the chars of that language. This avoids the use of visually similar chars within one language which mimic the appearance of a label within another language, regardless of whether that label is already within the DNS or not.

2.7.1.2 Inter-language and Intra-language Variants to Prevent Similar Registrations

ARI restricts child domains to a specific language and prevents registrations in one language being confused with a registration in another language, for example Cyrillic а (U+0430) and Latin a (U+0061).

2.8 DNSSEC

DNSSEC provides a set of extensions to the DNS that allow an Internet user (normally the resolver acting on a user’s behalf) to validate that the DNS responses they receive were not manipulated en-route.
This type of fraud, commonly called ‘man in the middle’, allows a malicious party to misdirect Internet users. DNSSEC allows a domain owner to sign their domain and to publish the signature, so that all DNS consumers who visit that domain can validate that the responses they receive are as the domain owner intended.
Registries, as the operators of the parent domain for registrants, must publish the DNSSEC material received from registrants, so that Internet users can trust the material they receive from the domain owner. This is commonly referred to as a ‘chain of trust’. Internet users trust the root (operated by IANA), which publishes the registries’ DNSSEC material, therefore registries inherit this trust. Domain owners within the TLD subsequently inherit trust from the parent domain when the registry publishes their DNSSEC material.
In accordance with new gTLD requirements, the TLD zone will be DNSSEC signed and the receipt of DNSSEC material from Registrars for child domains is supported in all provisioning systems.

2.8.1 Stability and Operational Considerations for DNSSEC

2.8.1.1 DNSSEC Practice Statement

ARI’s DNSSEC Practice Statement is included in our response to Question 43. The DPS following the guidelines set out in the draft IETF DNSOP DNSSEC DPS Framework document.

2.8.1.2 Receipt of Public Keys from Registrars

The public key for a child domain is received by ARI from the Registrar via either the EPP or SRS Web Interface. ARI uses an SHA-256 digest to generate the DS Resource Record (RR) for inclusion into the zone file.

2.8.1.3 Resolution Stability

DNSSEC is considered to have made the DNS more trustworthy; however some transitional considerations need to be taken into account. DNSSEC increases the size and complexity of DNS responses. ARI ensures the TLD zone servers are accessible and offer consistent responses over UDP and TCP.
The increased UDP and TCP traffic which results from DNSSEC is accounted for in both network path access and TLD zone server capacity. ARI will ensure that capacity planning appropriately accommodates the expected increase in traffic over time.
ARI complies with all relevant RFCs and best practice guides in operating a DNSSEC-signed TLD. This includes conforming to algorithm updates as appropriate. To ensure Key Signing Key Rollover procedures for child domains are predictable, DS records will be published as soon as they are received via either the EPP server or SRS Web Interface. This allows child domain operators to rollover their keys with the assurance that their timeframes for both old and new keys are reliable.

3 APPROACH TO SECURITY AND STABILITY

Stability and security of the Internet is an important consideration for the registry system. To ensure that the registry services are reliably secured and remain stable under all conditions, ARI takes a conservative approach with the operation and architecture of the registry system.
By architecting all registry services to use the least privileged access to systems and data, risk is significantly reduced for other systems and the registry services as a whole should any one service become compromised. By continuing that principal through to our procedures and processes, we ensure that only access that is necessary to perform tasks is given. ARI has a comprehensive approach to security modeled of the ISO27001 series of standards and explored further in the relevant questions of this response.

By ensuring all our services adhering to all relevant standards, ARI ensures that entities which interact with the registry services do so in a predictable and consistent manner. When variations or enhancements to services are made, they are also aligned with the appropriate interoperability standards.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q24 – ARI Background & Roles.pdf’. This response describes the SRS as implemented by ARI.

1 INTRODUCTION
ARI has demonstrated delivery of an SRS with exceptional availability, performance and reliability. ARI are experienced running mission critical SRSs and have significant knowledge of the industry and building and supporting SRSs.
ARI’s SRS has successfully supported a large group of Registrars for ASCII and IDN based TLDs. The system is proven to sustain high levels of concurrency, transaction load, and system uptime. ARI’s SRS meets the following requirements:
– Resilient to wide range of security and availability threats
– Consistently exceeds performance and availability SLAs
– Allows capacity increase with minimal impact to service
– Provides fair and equitable provisioning for all Registrars

2 CAPACITY

ARI’s SRS was built to sustain 20M domain names. Based on ARI’s experience running a ccTLD registries and industry analysis, ARI were able to calculate the conservative characteristics of a registry this size.
Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com and .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 70 SRS TPS per domain, per month
– A ratio of 3 query to 2 transform txs
This indicates an expected monthly transaction volume of 1,400M txs (840M query and 560M transforms).
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily TPS is 6% of monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak EPP tx rate of 14,000 TPS (5,600 transform TPS and 8,400 query TPS)
Through conservative statistical analysis of the .au registry we know:
– The avg no. contacts⁄domain is 3.76
– The avg no. hosts⁄domain is 2.28
This translates into a requirement to store 75.2M contacts and 45.6M hosts.
Finally through real world observations of the .au registry, which has a comprehensive web interface when compared to those offered by current gTLD registries, we know there is an avg of 0.5 HTTP requests⁄sec to the SRS web interface per Registrar. We also know that this behaviour is reasonably flat. To support an estimated 1000 Registrars, would require 500 requests⁄second.
For perspective on the conservativeness of this, the following was taken from data in the May 2011 ICANN reports referenced above:
–.info: ~7.8M names peaks at ~1,400 TPS (projected peak TPS of ~3,600 with 20M)
–.com: ~98M names peaks at ~41,000 TPS (projected peak TPS of ~8,300 TPS with 20M)
–.org: ~9.3M names, peaks at ~1,400 TPS (projected peak TPS of ~3,100 with 20M)
After performing this analysis the projected TPS for .com was still the largest value.
ARI understand the limitations of this method but it serves as a best estimate of probable tx load. ARI has built overcapacity of resources to account for limitations of this method, however as numbers are more conservative than real world observations, we are confident this capacity is sufficient.
This TLD is projected to reach 3824 domains at its peak volume and will generate 2.6768 EPP TPS. This will consume 0.01912% of the resources of the SRS infrastructure. As is evident ARI’s SRS can easily accommodate this TLD’s growth plans. See attachment ‘Q24 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s SRS infrastructure will be 60% utilised. The SRS infrastructure capacity can be easily scaled as described in Question 32
ARI benchmarked their SRS infrastructure and used the results to calculate the required computing resources for each of the tiers within the architecture; allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server, and the network bandwidth and packet throughput requirements for the anticipated traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions, and headroom for growth. Despite doubling numbers, effective estimated capacity is still reported as 20M. The technical resource allocations are explored in Question 32.

3 SRS ARCHITECTURE

ARI’s SRS has the following major components:
– Network Infrastructure
– EPP Application Servers
– SRS Web Interface Application Servers
– SRS Database
Attachment ‘Q24 – SRS.pdf’ shows the SRS systems architecture and data flows. Detail on this architecture is in our response to Question 32. ARI provides two distinct interfaces to the SRS: EPP and SRS Web. Registrar SRS traffic enters the ARI network via the redundant Internet link and passes (via the firewall) to the relevant application server for the requested service (EPP or SRS Web). ARI’s EPP interface sustains high volume and throughput domain provisioning transactions for a large number of concurrent Registrar connections. ARI’s SRS Web interface provides an alternative to EPP with a presentation centric interface and provides reporting and verification features additional to those provided by the EPP interface.

3.1 EPP
ARI’s EPP application server is based on EPP as defined in RFCs 5730 – 5734. Registrars send XML based transactions to a load balanced EPP interface which forwards to one of the EPP application servers. The EPP application server then processes the XML and converts the request into database calls that retrieve or modify registry objects in the SRS database. The EPP application server tier comprises of three independent servers with dedicated connections to the registry database. Failure of any one of these servers will cause Registrar connections to automatically re-establish with one of the remaining servers. Additional EPP application servers can be added easily without any downtime. All EPP servers accept EPP both IPv4 and IPv6.

3.2 SRS Web
The SRS Web application server is a Java web application. Registrars connect via the load balancer to a secure HTTP listener running on the web servers. The SRS web application converts HTTPs requests into database calls which query or update objects in the SRS database. The SRS Web application server tier consists of two independent servers that connect to the database via JDBC. If one of these servers is unavailable the load balancer re-routes requests to the surviving server. Additional servers can be added easily without any downtime. These servers accept both IPv4 and IPv6.

3.3 SRS Database
The SRS database provides persistent storage for domains and supporting objects. It offers a secure way of storing and retrieving objects provisioned within the SRS and is built on the Oracle 11g Enterprise Edition RDBMS. The SRS Database tier consists of four servers clustered using Oracle Real Application Clusters (RAC). In the event of failure of a database server, RAC will transparently transition its client connections to a surviving database host. Additional servers can be added easily without any downtime.

3.4 Number of Servers
EPP Servers – The EPP cluster consists of 3 servers that can more than handle the anticipated 20M domains. This TLD will utilise 0.01912% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.
SRS Web Servers – The SRS Web cluster consists of 2 servers that can more than handle the anticipated 20M domains. This TLD will utilise 0.01912% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.
SRS DB Servers – The SRS DB cluster consists of 4 servers that can more than handle the anticipated 20M domains. This TLD will utilise 0.01912% of this capacity at its peak volume. As the utilisation increases ARI will add additional servers ensuring the total utilisation doesn’t exceed 50% of total capacity. Adding a new server to the cluster can be done live without downtime.

3.5 SRS Security
ARI adopts a multi-layered security solution to protect the SRS. An industry leading firewall is deployed behind the edge router and is configured to only allow traffic on the minimum required ports and protocols. Access to the ARI EPP service is restricted to a list of known Registrar IPs.
An Intrusion Detection device is in-line with the firewall to monitor and detect suspicious activity.
All servers are configured with restrictive host based firewalls, intrusion detection, and SELinux. Direct root access to these servers is disabled and all access is audited⁄logged centrally.
The SRS database is secured by removal of non-essential features and accounts, and ensuring all remaining accounts have strong passwords. All database accounts are assigned the minimum privileges required to execute their business function.
All operating system, database, and network device accounts are subject to strict password management controls such as validity and complexity requirements.
Registrar access to the SRS via EPP or the Web interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows:
– Registrar’s source IP must be allowed by the front-end firewalls. This source IP is received from the Registrar via a secure communication channel from within the SRS Web interface.
– Registrar must use a digital certificate provided by ARI.
– Registrar must use authentication credentials that are provided by encrypted email.
All communication between the Registrar and the SRS is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ until ‘2031 and beyond’ by NIST Special Publication 800-57.

3.6 SRS High Availability
SRS availability is of paramount. Downtime is eliminated or minimised where possible. The infrastructure contains no single points of failure. N+1 redundancy is used as a minimum, which not only protects against unplanned downtime but also allows ARI to execute maintenance without impacting service.
Redundancy is provided in the network with hot standby devices and multiple links between devices. Failure of any networking component is transparent to Registrar connections.
N+N redundancy is provided in the EPP and SRS Web application server tiers by the deployment of multiple independent servers grouped together as part of a load-balancing scheme. If a server fails the load balancer routes requests to the remaining servers.
N+N redundancy is provided in the database tier by the use of Oracle Real Application Cluster technology. This delivers active⁄active clustering via shared storage. This insulates Registrars from database server failure.
Complete SRS site failure is mitigated by the maintenance of a remote standby site, a duplicate of the primary site ready to be the primary if required.
The standby site database is replicated using real time transaction replication from the main database using Oracle Data Guard physical standby. If required the Data Guard database can be activated quickly and service resumes at the standby site.

3.7 SRS Scalability
ARI’s SRS scales efficiently. At the application server level, additional computing resource can be brought on-line rapidly by deploying a new server online. During benchmarking this has shown near linear.
The database can be scaled horizontally by adding a new cluster node into the RAC cluster online. This can be achieved without disruption to connections. The SRS has demonstrated over 80% scaling at the database level, but due to the distributed locking nature of Oracle RAC, returns are expected to diminish as the number of servers approaches double digits. To combat this ARI ensures that when the cluster is ‘scaled’ more powerful server equipment is added rather than that equal to the current members. Capacity can be added to the SAN at any time without downtime increasing storage and IOPs.

3.8 SRS Inter-operability and Data Synchronisation
The SRS interfaces with a number of related registry systems as part of normal operations.

3.8.1 DNS Update
Changes made in the SRS are propagated to the DNS via an ARI proprietary DNS Update process. This process runs on the ‘hidden’ primary master nameserver and waits on a queue. It is notified when the business logic inserts changes into the queue for processing. The DNS Update process reads these queue entries and converts them into DNS update (RFC2136) commands that are sent to the nameserver. The process of synchronising changes to SRS data to the DNS occurs in real-time.

3.8.2 WhoIs
The provisioned data supporting the SRS satisfies WhoIs queries. Thus the WhoIs and SRS share data sets and the WhoIs is instantaneously updated. Under normal operating conditions the WhoIs service is provided by the infrastructure at the secondary site in order to segregate the load and protect SRS from WhoIs demand (and vice versa). WhoIs queries that hit the standby site will query data stored in the standby database – maintained in near real-time using Oracle Active Data Guard. If complete site failure occurs WhoIs and SRS can temporarily share the same operations centre at the same site (capacity numbers are calculated for this).

3.8.3 Escrow
A daily Escrow extract process executes on the database server via a dedicated database account with restricted read-only access. The results are then transferred to the local Escrow Communications server by SSH.

4 OPERATIONAL PLAN

ARI follow defined policies⁄procedures that have developed over time by running critical registry systems. Some principals captured by these are:
– Conduct all changes and upgrades under strict and well-practised change control procedures
– Test, test and test again
– Maintain Staging environments as close as possible to production infrastructure⁄configuration
– Eliminate all single points of failure
– Conduct regular security reviews and audits
– Maintain team knowledge and experience via skills transfer⁄training
– Replace hardware when no longer supported by vendor
– Maintain spare hardware for all critical components
– Execute regular restore tests of all backups
– Conduct regular capacity planning exercises
– Monitor everything from multiple places but ensure monitoring is not ‘chatty’
– Employ best of breed hardware and software products and frameworks (such as ITIL, ISO27001 and Prince2)
– Maintain two distinct OT&E environments to support pre-production testing for Registrars

5 SLA, RELIABILITY AND COMPLIANCE

ARI’s SRS adheres to and goes beyond the scope of Specification 6 and Specification 10 of the Registry Agreement. ARI’s EPP service is XML compliant and XML Namespace aware. It complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC 5731, 5732 and 5733 respectively. The transport over TCP is compliant with RFC5734. The service also complies with official extensions to support DNSSEC, RFC5910, and Redemption Grace Period, RFC 3915.
ARI’s SRS is sized to sustain a peak transaction rate of 14,000 TPS while meeting strict internal Operational Level Agreements (OLAs). The monthly-based OLAs below are more stringent than those in Specification 10 (Section 2).
EPP Service Availability:100%
EPP Session Command Round Trip Time (RTT):〈=1000ms for 95% of commands
EPP Query Command Round Trip Time (RTT):〈=500ms for 95% of commands
EPP Transform Command Round Trip Time (RTT):〈=1000ms for 95% of commands
SRS Web Interface Service Availability:99.9%
ARI measure the elapsed time of every query, transform and session EPP transaction, and calculate the percentage of commands that fall within OLA on a periodic basis. If percentage value falls below configured thresholds on-call personnel are alerted.
SRS availability is measured by ARI’s monitoring system which polls both the EPP and SRS Web services status. These checks are implemented as full end to end monitoring scripts that mimic user interaction, providing a true representation of availability. These ‘scripts’ are executed from external locations on the Internet.

6 RESOURCES

This function will be performed by ARI. ARI staff are industry leading experts in domain name registries with the experience and knowledge to deliver outstanding SRS performance.
The SRS is designed, built, operated and supported by the following ARI departments:
– Products and Consulting Team (7 staff);
– Production Support Group (27 staff);
– Development Team (11 staff).

A detailed list of the departments, roles and responsibilities in ARI is provided in attachment ‘Q24 – ARI Background & Roles.pdf’. This attachment describes the functions of the teams and the number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a vast experience in estimating the number of resources required to support a SRS.
Based on past experience ARI estimates that the existing staff is adequate to support an SRS that supporting at least 50M domains. Since this TLD projects 3824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q24 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the teams with a 2 month lead time.
The Products and Consulting team is responsible for product management of the SRS solution including working with clients and the industry to identify new features or changes required. The team consists of:
– 1 Products and Consulting Manager;
– 1 Product Manager;
– 1 Technical Product Manager;
– 4 Domain Name Industry Consultants.
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the SRS infrastructure including capacity planning and monitoring as well as security aspects – ensuring the SRS services are available and performing at the appropriate level and operating correctly. The team consists of:
– Production Support Manager;
– Service Desk:
 – 1 Level 1 Support Team Lead;
 – 8 Customer Support Representatives (Level 1 support);
 – 1 Level 2 Support Team Lead;
 – 4 Registry Specialists (Level 2 support);
– Operations (Level 3 support):
 – 1 Operations Team Lead;
 – 2 Systems Administrators;
 – 2 Database Administrators;
 – 2 Network Engineers;
– Implementation:
 – 1 Project Manager;
 – 2 Systems Administrators;
 – 1 Database Administrator;
 – 1 Network Engineer.
The development team is responsible for implementing changes and new features into the SRS as well as bug fixing and complex issue diagnosis. The team consists of:
– 1 Development Manager;
– 2 Business Analysts;
– 6 Developers;
– 2 Quality Analysts.
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q25 – ARI Background & Roles.pdf’. This response describes the Extensible Provisioning Protocol (EPP) interface as implemented by ARI.

1 INTRODUCTION

ARI’s EPP service is XML compliant and XML Namespace aware. The service complies with the EPP protocol defined in RFC5730, and the object mappings for domain, hosts and contacts are compliant with RFC5731-3 respectively. The transport over TCP is implemented in compliance with RFC5734. The service also complies with the official extensions to support DNSSEC, RFC5910 and Redemption Grace Period, RFC3915. ARI implemented EPP draft version 0.6 in 2002, then migrated to EPP RFC 1.0 on its publishing in 2004. The system has operated live since 2002 in the .au ccTLD.
Descriptions in this response follow the terminology used in the EPP RFCs. When referring to the software involved in the process, ARI’s EPP interface is called the server, and the software used by Registrars is called the client.

2 TRANSPORT LAYER

The ARI EPP service implements the RFC5734 – EPP Transport over TCP. Connections are allowed using TLSv1 encryption, optionally supporting SSLv2 Hello for compatibility with legacy clients. AES cipher suites for TLS as described in RFC3268 are the only ones allowed.

2.1 Authentication
Registrar access to the EPP interface is authenticated and secured with multi-factor authentication (NIST Level 3) and digital assertion as follows. Registrars must:
– present a certificate, during TLS negotiation, signed by the ARI Certificate Authority (CA). The server returns a certificate also signed by the ARI CA. Not presenting a valid certificate results in session termination. ARI requires that the Common Name in the subject field of the certificate identifies the Registrar.
– originate connections from an IP address that is known to be assigned to the Registrar with that Common Name.
– Registrar must use authentication credentials provided to the Registrar via encrypted email.
– Registrars aren’t able to exceed a fixed number of concurrent connections. The connection limit is prearranged and designed to prevent abuse of Registrars’ systems from affecting the Registry. The limit is set to reasonable levels for each Registrar, but can be increased to ensure legitimate traffic is unaffected. If any of the above conditions aren’t met the connection is terminated.
All communication between the Registrars and the EPP service is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57.

2.3 Connection Close
The server may close the connection as a result of a logout, an error where the state of the connection is indeterminate, or after a timeout. Timeout occurs where no complete EPP message is received on the connection for 10 minutes.

3 EPP PROTOCOL

This section describes the interface relating to the EPP protocol described in RFC5730. This includes session management, poll message functionality and object mappings for domains, hosts and contacts.

3.1 Session Management
Session management refers to login and logout commands, used to authenticate and end a session with the SRS. The Login command is used to establish a session between the client and the server. This command succeeds when:
– The username supplied matches the Common Name in the digital certificate used in establishing the TLS session.
– The provided password is valid for the user.
– The user’s access to the system isn’t suspended.
The Logout command is used to end an active session. On processing a logout the server closes the underlying connection. The Hello command can be used as a session keep-alive mechanism.

3.2 Service Messages
Offline notifications pertaining to certain events are stored in a queue. The client is responsible for polling this queue for new messages and to acknowledge read messages. Messages include notification about server modification of sponsored objects, transfer operations, and balance thresholds.

4 EPP OBJECT MAPPINGS

This section covers the interface for the 3 core EPP objects; domain, host and contact objects, as per RFC5731, 5732, and 5733 respectively.

The EPP domain, contact and host object mapping describes an interface for the check, info, create, delete, renew (domain only), transfer (domain and contact only) and update commands. For domain objects the server doesn’t support the use of host attributes as described by RFC5731, but rather uses host objects as described by RFC5731 and RFC5732. Details of each command are:
– check command: checks availability of 1 or more domain, contact or host objects in the SRS. Domain names will be shown as unavailable if in use, invalid or reserved, other objects will be unavailable if in use or invalid.
– info command: retrieves the information of an object provisioned in the SRS. Full information is returned to the sponsoring client or any client that provides authorisation information for the object. Non-sponsoring clients are returned partial information (no more than is available in the WhoIs).
– create command: provisions objects in the SRS. To ascertain whether an object is available for provisioning, the same rules for the check command apply.
– delete command: begins the process of removing an object from the SRS. Domain names transition into the redemption period and any applicable grace periods are applied. Domain names within the Add Grace Period are purged immediately. All other objects are purged immediately if they are not linked.
– renew command (domain only): extends the registration period of a domain name. The renewal period must be between 1 to 10 years inclusive and the current remaining registration period, plus the amount requested in the renewal mustn’t exceed 10 years.
– transfer command (domain and contact only): provides several operations for the management of the transfer of object sponsorship between clients. Clients that provide correct authorisation information for the object can request transfers. Domain names may be rejected from transfer within 60 days of creation or last transfer. The requesting client may cancel the transfer, or the sponsoring client may reject or approve the transfer. Both the gaining and losing clients may query the status of the current pending or last completed transfer.
– update command: updates authorisation information, delegation information (domains), and registration data pertaining to an object.

5 NON-PROPRIETARY EPP MAPPINGS

ARI’s EPP service implements 2 non-proprietary EPP mappings, to support the required domain name lifecycle and to provide and manage DNSSEC information. The relevant schema documents aren’t provided as they are published as RFCs in the RFC repository.

5.1 Grace Period Mapping
The Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (as per RFC 3915) is used to support the domain name lifecycle as per existing TLDs. The update command is extended by the restore command to facilitate the restoration of previously deleted domains in the redemption period. This command defines 2 operations, request and report, described here:
– Request operation: requests the restoration of a domain.
– Report operation: completes the restoration by specifying the information supporting the restoration of the domain. The restore report must include a copy of the WhoIs information at both the time the domain was deleted and restored, including the restore reason.

5.2 DNSSEC Mapping
The Domain Name System (DNS) Security Extensions Mapping for EPP, as per RFC5910, is used to support the provisioning of DNS Security Extensions. ARI requires clients use the Key Data interface. Clients may associate a maximum of 4 keys per domain. The registry system generates the corresponding DS data using the SHA-256 digest algorithm for the domain and any active variant domains.
ARI is aware of issues DNSSEC causes when transferring DNS providers – a transfer of Registrar usually means a change in DNS provider. DNSSEC key data won’t be removed from the SRS or the DNS if a transfer occurs. It is the responsibility of and requires the cooperation of the registrant, Registrars, and DNS providers, to provide a seamless transition. ARI observes progress with this issue and implements industry agreed solutions as available. DNSSEC information is included in info responses when the secDNS namespace in login.

6 PROPRIETARY MAPPING

The registry system supports 3 additional EPP extensions where no published standard for the required functionality exists. Developed to conform to the requirements specified in RFC3735, these extensions include the provisioning of Internationalised Domain Names and domain name variants, and the association of arbitrary data with a domain name. These 3 extensions are introduced below, and further described in the attached schema documentation.

6.1 Internationalised Domain Names
ARI has developed an extension to facilitate the registration and management of Internationalised Domain Names as per RFCs 5890-5893 (collectively known as the IDNA 2008 protocol). This extension extends the domain create command and the info response.
The create command is extended to capture the language table identifier that identifies the corresponding IDN language table for the domain name. Additionally the extension requires the Unicode form to avoid an inconsistency with DNS-form, as per RFC 5891.
The domain info command is extended to identify the language tag and Unicode form provided in the initial create command. This information is disclosed to all querying clients that provided the extension namespace at login. This extension is documented in the attachment ‘Q25 - Domain Name Variant Extension Mapping for the EPP.pdfʹ.

6.2 Variant
ARI has developed an extension to facilitate the management of Domain Name variants. This extension extends the domain update command and the domain create and info responses. The domain update command is extended to allow the addition (activation) and removal (de-activation) of domain name variants subject to registry operator policy.
The domain create and info responses are extended to return the list of activated domain name variants. This information is disclosed to all querying clients that provided the extension namespace at login. The extension is documented in the attachment ‘Q25 - IDN Extension Mapping for the EPP.pdfʹ.

6.3 Key-Value
ARI has developed an extension to facilitate the transport of arbitrary data between clients and the SRS without the need for developing EPP Extensions for each specific use-case. This extension extends the domain create and domain update transform commands and the domain info query command. This extension is documented in the attachment ‘Q25 - Key-value mapping for the EPP.pdf’.

7 ADDITIONAL SECURITY

The registry system provides additional mechanisms to support a robust interface. The use of command rate limiting enables the registry to respond to and withstand erroneous volumes of commands, while a user permission model provides fine-grained access to the EPP interface. These 2 mechanisms are described below.

7.1 Rate Limiting
The registry system supports command and global rate limits using a token-bucket algorithm. Limits apply to each connection to ensure fair and equitable use by all. Clients that exceed limits receive a command failed response message indicating breach of the limit.

7.2 User Permission Model
The registry system supports a fine-grained permission model controlling access to each specific command. By default, clients receive access to all functionality; however it is possible to remove access to a specific command in response to abuse or threat to stability of the system. Clients that attempt a command they have lost permission to execute, receive an EPP command failed response indicating loss of authorisation.

8 COMPLIANCE

Compliance with EPP RFCs is achieved through design and quality assurance (QA). The EPP interface was designed to validate all incoming messages against the respective XML Schema syntax. The XML Schema is copied directly from the relevant RFCs to avoid any ambiguity on version used. Inbound messages that are either malformed XML or invalid are rejected with a 2400 response. Outbound messages are validated against the XML Schema, and if an invalid response is generated, it is replaced with a known valid pre-composed 2400 response, and logged for later debugging.
A QA process provides confidence that changes don’t result in regressions in the interface. Automated build processes execute test suites that ensure every facet of the EPP service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs and the EPP service specification. These tests are executed prior to committing code and automatically nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging process.
New versions of the EPP Service follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars are encouraged during this stage to test their systems operate correctly. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior reaching production.
ARI surveys Registrars for information about the EPP client toolkit. These surveys indicated that while many Registrars use ARI toolkits, several Registrars use either their own or that from another registry. The ability for Registrars to integrate with the ARI EPP service without using the supplied toolkit indicates the service is compliant with RFCs.
ARI is committed to providing an EPP service that integrates with third party toolkits and as such tests are conducted using said toolkits. Any issues identified during testing fall into the following categories:
– Third-party toolkit not compliant with EPP
– EPP service not compliant with EPP
– Both third-party toolkit and EPP service are compliant, however another operational issue causes an issue
Defects are raised and change management processes are followed. Change requests may also be raised to promote integration of third-party toolkits and to meet common practice.

9 CAPACITY

This TLD is projected to reach 3824 domains at its peak volume and will generate 2.6768 EPP TPS. This will consume 0.01912% of the EPP resources. ARI’s SRS can easily accommodate this TLD. This was described in considerable detail in the capacity section of Question 24.

10 RESOURCES

This function will be performed by ARI. ARI provides a technical support team to support Registrars and also provides Registrars with a tool kit (in Java and C++) implementing the EPP protocol. Normal operations for all registry services are managed by ARI’s Production Support Group (PSG), who ensure the EPP server is available and performing appropriately.
Faults relating to connections with or functionality of the EPP server are managed by PSG. ARI monitors EPP availability and functionality as part of its monitoring practices, and ensures PSG staff are available to receive fault reports from Registrars any time. PSG has the appropriate network, Unix and application (EPP and load balancing) knowledge to ensure the EPP service remains accessible and performs as required. These ARI departments support EPP:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q25 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that existing staff are adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q25 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required, trained resources can be added to any of the above teams with a 2-month lead time.

10.1 Team Details
The products and consulting team is responsible for product management of the EPP solution, and works with clients and industry to identify required system features or changes. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
The Production Support Group (PSG) is responsible for the design, deployment and maintenance of the EPP infrastructure including capacity planning, monitoring, and security. This team ensures the EPP services are available and performing appropriately. The team consists of:
– Production Support Manager
– Service Desk:
 – 1 Level 1 Support Team Lead
 – 8 Customer Support Representatives (Level 1 support)
 – 1 Level 2 Support Team Lead
 – 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
 – 1 Operations Team Lead
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network Engineers
– Implementation:
 – 1 Project Manager
 – 2 Systems Administrators
 – 1 Database Administrator
 – 1 Network Engineer
The development team is responsible for EPP changes and features, bug fixes and issue diagnosis. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our financial responses.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q26 – ARI Background & Roles.pdf’. This response describes the WhoIs interface as implemented by ARI.

1 INTRODUCTION

ARI’s WhoIs service is for all domain names, contacts, nameservers and Registrars provisioned in the registry database. This response describes the port 43 and web interfaces of WhoIs, security controls to mitigate abuse, compliance with bulk access requirements for registration data, and the architecture delivering the service.

2 PORT 43 WHOIS SERVICE

WhoIs is on TCP port 43 in accordance with RFC3912. Requests are made in semi-free text format and ended by CR and LF. The server responds with a semi-free text format, terminating the response by connection close.
To support IDNs and Localised data we assume the query is encoded in UTF-8 and sends responses encoded in UTF-8. UTF-8 is backwards compatible with the ASCII charset and its use is consistent with the IETF policy on charsets as defined in BCP 18 [http:⁄⁄tools.ietf.org⁄html⁄bcp18].

2.1 Query Format
By default WhoIs searches domains. To facilitate the queries of other objects keywords must be used. Supported keywords are:
– Domain
– Host⁄Nameserver
– Contact
– Registrar
Keywords are case-insensitive. The rest of the input is the search string. Wildcard chars may be used in search strings to match zero or more chars (%), or match exactly one char(_). Wildcard chars must not be in the first 5 chars.

2.2 Response Format
The response follows a semi-structured format of object-specific data, followed by query-related meta-information, then a disclaimer.
The object-specific data is represented by key⁄value pairs, beginning with the key, followed by a colon and a space then the value terminated by an ASCII CR and LF. Where no object is found ‘No Data Found’ is returned.
The meta-information is used to identify data freshness and indicate when limits have been exceeded. It appears on one line within ‘〉〉〉’ and ‘〈〈〈’ chars.
The legal disclaimer is presented without leading comment marks wrapped at 72 chars. This format is consistent with that in the registry agreement.

2.3 Domain Data
Domain data is returned in response to a query with the keyword omitted, or with the ‘domain’ keyword. Domain queries return information on domains that are provisioned in the registry database.
The IDN domains may be specified in either the ASCII-compatible encoded form or the Unicode form. Clients are expected to perform any mappings, in conformance with relevant guidelines such as those specified in RFC5894 and UTS46.
Variant domains may be specified in the search string and WhoIs will match (using case-insensitive comparison) and return information for the primary registered domain.
For queries containing wildcard chars, if only one domain name is matched its details are returned, if more than one domain name is matched then the first 50 matched domain names are listed.

2.3.1 Internationalised Domain Names
The WhoIs response format, prescribed in Specification 4, does not provide a mechanism to identify active variant domain names. ARI will include active variant domain names in WhoIs responses until a common approach for handling and display of variant names is determined.

2.3.2 Reserved Domain Names
Domain names reserved from allocation will have a specific response that indicates the domain is not registered but also not available.

2.4 Nameserver Data
Nameserver data is returned in response to a query where the ‘nameserver’ or ‘host’ keywords have been used. Nameserver queries return information on hosts that are provisioned in the registry.
The search string for a nameserver query can be either a hostname or IP. Queries using the hostname produce one result unless wildcards are used. Queries using the IP produce one or more results depending on the number of hostnames that match that address. Queries for the hostname are matched case-insensitively.
The quad-dotted notation is expected for IPv4 and the RFC3513 – IPv6 Addressing Architecture format for IPv6. Wildcards cannot be used for IP queries.

2.5 Contact Data
Contact data is returned in response to a query where the ‘contact’ keyword was used. Contact queries return information on contacts that are provisioned in the registry.
The search string for a contact query is the contact identifier. Contact identifiers are matched using a case-insensitive comparison. Wildcards cannot be used.

2.6 Registrar Data
Registrar data is returned in response to a query where the ‘Registrar’ keyword was used. Registrar queries return information on Registrar objects that are provisioned in the registry.
The search string for a Registrar query can be name or IANA ID. Queries using the name or the IANA ID produce only one result. Queries for the name are matched using a case-insensitive comparison. Wildcards cannot be used.

2.7 Non-standard Data
The SRS supports domain-related data beyond that above. It may include information used to claim eligibility to participate in the sunrise process, or other arbitrary data collected using the Key-Value Mapping to the EPP. This information will be included in the WhoIs response after the last object-specific data field and before the meta-information.

3 WEB-BASED WHOIS SERVICE

WhoIs is also available via port 80 using HTTP, known as Web-based WhoIs. This interface provides identical query capabilities to the port 43 interface via an HTML form.

4 SECURITY CONTROLS

WhoIs has an in-built mechanism to blacklist malicious users for a specified duration. Blacklisted users are blocked by source IP address and receive a specific blacklisted notification instead of the normal WhoIs response.
Users may be blacklisted if ARI’s monitoring system determines excessive use. A whitelist is used to facilitate legitimate use by law enforcement agencies and other reputable entities.

5 BULK ACCESS

The registry system complies with the requirements for the Periodic Access to Thin Registration Data and Exceptional Access to Thick Registration Data as described in Specification 4.

5.1 Periodic Access to Thin Registration Data
ARI shall provide ICANN with Periodic Access to Thin Registration Data. The data will contain the following elements as specified by ICANN. The format of the data will be consistent with the format specified for Data Escrow. The Escrow Format prescribes an XML document encoded in UTF-8. The generated data will be verified to ensure that it is well formed and valid.
The data will be generated every Monday for transactions committed up to and on Sunday unless otherwise directed by ICANN. The generated file will be made available to ICANN using SFTP. Credentials, encryption material, and other parameters will be negotiated between ARI and ICANN using an out-of-band mechanism.

5.2 Exceptional Access to Thick Registration Data
If requested by ICANN, ARI shall provide exceptional access to thick registration data for a specified Registrar. The date will contain full information for the following objects:
– Domain names sponsored by the Registrar
– Hosts sponsored by the Registrar
– Contacts sponsored by the Registrar
– Contacts linked from domain names sponsored by the Registrar
As above the format of the data will be consistent with the format specified for Data Escrow. And will be made available to ICANN using SFTP.

6 CAPACITY

ARI’s WhoIs infrastructure is built to sustain 20M domain names. Based on ARI’s experience running a high volume ccTLD registry (.au) and industry analysis, ARI were able to calculate the conservative characteristics of a registry of this size.
Through conservative statistical analysis of the .au registry and data presented in the May 2011 ICANN reports for the .com and .net, .org, .mobi, .info, .biz and .asia [http:⁄⁄www.icann.org⁄en⁄resources⁄registries⁄reports] we know there is:
– An average of 30 SRS txs per domain, per month.
Which indicates an expected monthly transaction volume of 600M txs?
Through statistical analysis of the .au registry and backed up by the data published in the .net RFP responses [http:⁄⁄archive.icann.org⁄en⁄tlds⁄net-rfp⁄net-rfp-public-comments.htm] we also know:
– The peak daily transactions is 6% of the monthly total
– The peak 5 min is 5% of the peak day
Thus we expect a peak WhoIs tx rate of WhoIs 6,000 TPS.
For perspective on the conservativeness of this, the following numbers were taken from data in the May 2011 ICANN reports referenced above:
– .info ~7.8M domain names, peaks at ~1,300 TPS (projected peak TPS of ~3,400 with 20M names)
– .mobi ~1M domain names, peaks at ~150 TPS (projected peak TPS of ~3,000 TPS with 20M names)
– .org ~9.3M domain names, peaks at ~1,300 TPS (projected peak TPS of ~2,800 with 20M names)
ARI understand the limitations of these calculations but they serve as a best estimate of probable transaction load. ARI has built overcapacity of resources to account for limitations of this method, however as conservative numbers were used and these are greater than real world observations, we are confident these capacity numbers are sufficient.
ARI benchmarked their WhoIs infrastructure and used the results to calculate the required computing resources for each of the tiers within the WhoIs architecture – allowing ARI to accurately estimate the required CPU, IOPS, storage and memory requirements for each server within the architecture, as well as the network bandwidth and packet throughput requirements for the anticipated WhoIs traffic. These capacity numbers were then doubled to account for unanticipated traffic spikes, errors in predictions and head room for growth. The technical resource allocations are explored in Question 32.
This TLD is projected to reach 3824 domains at its peak volume and will generate 1.1472 WhoIs transactions per second. This will consume 0.01912% of the resources of the WhoIs infrastructure. As is evident ARI’s WhoIs can easily accommodate this TLD’s growth plans. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI expects to provide Registry services to 100 TLDs and a total of 12M domains by end of 2014. With all the TLDs and domains combined, ARI’s WhoIs infrastructure will be only 60% utilised. The WhoIs infrastructure capacity can also be easily scaled as described in Question 32.

7 ARCHITECTURE

WhoIs uses a database separate from the SRS database as it operates from the secondary site such that network and database resources are decoupled from the operation of the SRS. Oracle Data Guard ensures the two databases are synchronised in real-time. The WhoIs service is operated live from the SRS ‘failover’ site, with the SRS ‘primary’ site serving as the ‘failover’ site for the WhoIs service. Both sites have enough capacity to run both services simultaneously, however by separating them, in normal operating modes headroom above the already over provisioned capacity is available. The architecture and data flow diagrams are described below and shown in the attachment ‘Q26 – WhoIs.pdf’.
Traffic enters the network from the Internet through border routers and then firewalls. All traffic destined for this service except for TCP ports 43, 80 and 443 is blocked. Load balancers forward the request to one of the application servers running ARI built WhoIs software. Each server is connected to the database cluster through another firewall further restricting access to the. Each server uses a restricted Oracle user that has read only access to the registry data and can only access the data that is relevant to the WhoIs queries. This ensures that in the unlikely event of an application server compromise the effects are limited.
All components are configured and provisioned to provide N+1 redundancy. Multiple Internet providers with separate upstream bandwidth suppliers are used. At least one additional component of all hardware exists, enabling maintenance without downtime. This configuration provides a service exceeding the availability requirements in Specification 10.
The use of load balancing allows addition of application servers with no downtime. From a database perspective, the ability to scale is enabled by utilising Oracle RAC database clustering. The entire service, including routers, firewalls and application is IPv6 compatible and WhoIs is offered on both IPv4 and IPv6. Detail about this architecture is available in our response to Question 32.

7.1 Synchronisation
The WhoIs database is synchronised with the SRS database using Oracle Data Guard. Committed transactions in the SRS database are reflected in the WhoIs database in real-time. Should synchronisation break, WhoIs continues to operate with the latest available data until the issue is reconciled. The channel between the two sites consists of two independent dedicated point to point links as well as the Internet. Replication traffic flows via the dedicated links or if both links fail replication traffic flows over Internet tunnels.

7.2. Interconnectivity with Other Services
The WhoIs service is not directly interconnected with other registry services or systems. The software has been developed to provide the WhoIs service exclusively and retrieve response information from a database physically separate to the SRS transactional database. This database is updated as described in ‘Synchronisation’ above. Although for smaller system the WhoIs and SRS can be configured to use the same data store. The WhoIs servers log every request to a central repository that is logically separate from the WhoIs database. This repository is used for query counts, detection of data mining and statistical analysis on query trends.

7.3 IT and Infrastructure Resources
The WhoIs service is provided utilizing Cisco networking equipment, IBM servers and SAN. They are described in the attachment ‘Q26 – WhoIs.pdf’. For more information on the architecture including server specifications and database capabilities please see Questions 32 and 33.

8 COMPLIANCE

Compliance with WhoIs RFCs is achieved through design and QA. The WhoIs interface was designed to conform to the RFCs as documented and independent test cases have been developed.
QA processes provide confidence that any changes to the service don’t result in regression of the WhoIs. Automated build processes execute test suites that ensure every facet of the WhoIs service (including malformed input, commands sequencing and synchronisation, and boundary values) is covered and compliant with RFCs. These tests are executed prior to the committing of code and nightly. The final deliverable is packaged and tested again to ensure no defects were introduced in the packaging of the software.
New versions of the WhoIs follow a deployment schedule. The new version is deployed into an OT&E environment for Registrar integration testing. Registrars who rely on WhoIs functionality are encouraged during this stage to test their systems operate without change. After a fixed time in OT&E without issue, new versions are scheduled for production deployment. This ensures incompatibilities with RFCs that made it through QA processes are detected in test environments prior to reaching production.
ARI is committed to providing a WhoIs service that integrates with third party tools and as such tests are conducted using these tools such as jWhoIs, a popular UNIX command line WhoIs client. Any issues identified during integration fall into 1 of the following categories:
– Third-party tool not compliant with the WhoIs specification
– WhoIs service not compliant
– Both third-party tool and WhoIs service are compliant, however another operational issue causes a problem
Defects are raised and follow the change management. Change requests may also be raised to promote integration of third-party tools and to meet common practice.

9 RESOURCES

This function will be performed by ARI. The WhoIs system is supported by a number of ARI departments:
– Products and Consulting Team (7 staff)
– Production Support Group (27 staff)
– Development Team (11 staff)
– Legal, Abuse and Compliance Team (6 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q26 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q26 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The products and consulting team is responsible for product management of the WhoIs solution including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
ARI employ a development team responsible for the maintenance and continual improvement of the WhoIs software. The team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
ARI’s Production Support Team ensures the successful operation of the WhoIs system. The team comprises Database Administrators, Systems Administrators and Network Administrators. This team routinely checks and monitors bandwidth, disk and CPU usages to plan and respond to expected increases in the volume of queries, and perform maintenance of the system including security patches and failover and recovery testing. The team consists of:
– Production Support Manager
– Service Desk:
 – 1 Level 1 Support Team Lead
 – 8 Customer Support Representatives (Level 1 support)
 – 1 Level 2 Support Team Lead
 – 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support)
 – 1 Operations Team Lead
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network Engineers
– Implementation
 – 1 Project Manager
 – 2 Systems Administrators
 – 1 Database Administrators
 – 1 Network Engineers
ARI’s registry provides abuse monitoring detection mechanisms to block data mining. ARI support staff may be contacted to remove blacklisted users during which they may be referred to the Legal, Abuse and Compliance Team for evaluation of their activities. Additionally the support team in conjunction with the Legal, Abuse and Compliance team administer requests for listing on the whitelist. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers
These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q27 – ARI Background & Roles.pdf’. This response describes the Registration Lifecycle as implemented by ARI.

1 INTRODUCTION

The lifecycle described matches current gTLD registries. All states, grace periods and transitions are supported by the EPP protocol as described in RFC5730 – 5734 and the Grace Period Mapping published in RFC3915. An overview is in attachment ‘Q27 – Registration Lifecycle.pdf’.

2 REGISTRATION PERIODS

The registry supports registration up to 10 years and renewals for 1 to 10 years. The total current validity period can’t exceed 10 years.
Transfers under part A of the ICANN Policy on Transfer of Registrations between Registrars (Adopted 7 November 2008) extend registration by 1 year. The period truncates to 10 years if required.

3 STATES

The states that a domain can exist in are: Registered, Pending Transfer, Redemption, Pending Restore and Pending Delete.
All domain name statuses (RFC3915, 5730-5734 and 5910) are covered below

3.1 Registered
EPP Status: ok
In DNS: Yes
Allowed Operations: Update, Renew, Transfer (request) and Delete
The default state of a domain – no pending operations. The sponsoring Registrar may update the domain.

3.2 Pending Transfer
EPP Status: pendingTransfer
In DNS: Yes
Allowed Operations: Transfer (cancel, reject, approve)
Another Registrar has requested transfer of the domain and it is not yet completed All transform operations, other than those to cancel, reject, or approve the transfer are rejected.

3.3 Redemption
EPP Status: pendingDelete
RGP Status: redemptionPeriod
In DNS: No
Allowed Operations: Restore (request)
Domain has been deleted. The sponsor may request restoration of the domain. The domain continues to be withheld from the DNS unless it is restored. No transform operations other than restore are allowed.

3.4 Pending Restore
EPP Status: pendingDelete
RGP Status: pendingRestore
In DNS: Yes
Allowed Operations: Restore (report)
A restore request is pending. The sponsor must submit a restore report. The domain is provisioned the DNS. No transform operations other than the restore report are allowed.

3.5 Pending Delete
EPP Status: pendingDelete
RGP Status: pendingDelete
In DNS: No
Allowed Operations: None
The Redemption Grace Period has lapsed and the domain is pending purge from the registry. This state prohibits the sponsor from updating, restoring or modifying the domain. This status applies for 5 days. At the end of this period the domain is purged from the database and made available for registration.

4 GRACE PERIODS

The registry system supports 4 grace periods: add, renew, auto-renew, and transfer, described below with consideration for overlap of grace periods. States described here are additional to those above.

4.1 Add Grace Period
Length: 5 days
RGP Status: addPeriod
Allows for the no-cost cancellation of a domain registrations resulting from typing mistakes and other errors by Registrars and registrants – beginning on the creation of a domain and lasting for 5 days. When the following operations are performed during this period these rules apply:
– Delete: the sponsoring Registrar, who must have created the domain, may delete the domain and receive a refund. The domain is deleted with immediate effect. The refund is subject to the Add Grace Period Limits consensus policy. Excess deletions over 50 or 10% of creates (whichever is greater), are not subject to a refund, except in extraordinary circumstances.
– Renew: the sponsor may renew the domain but does not receive any refund for the initial registration fee. The Registrar is charged for the renewal operation. The total period for the domain is the sum of the initial period in the create and any renewal term, limited to a 10 year maximum.
– Transfer: Under ICANN policy a transfer can’t occur during the Add Grace Period or at any other time in the first 60 days after the initial registration. The registry system enforces this, rejecting such requests.
– Bulk Transfers: Under Part B of the ICANN Policy on Transfer of Registrations between Registrars, a bulk transfer can occur during the Add Grace Period. Any bulk transfer causes the Add Grace Period to not apply.
The Add Grace Period does not have any impact on other commands.

4.2 Renew Grace Period
Length: 5 days
RGP Status: renewPeriod
Allows the sponsoring Registrar to undo a renewal via the deletion of a domain – beginning on the receipt of a renewal command and lasting for 5 days. If any of the following operations are performed during this period these rules apply:
– Delete: the sponsoring Registrar, who must have initiated the renewal, may delete the domain and receive a renewal fee refund. The extension to the registration period caused by the preceding renew is reversed and unless the domain is also in the Add Grace Period, the domain enters the Redemption state. If also in the Add Grace Period it is deleted with immediate effect and availability for registration.
– Renew: the sponsoring Registrar, who must have performed the initial renew, can subsequently renew the domain again, causing a second independent Renewal Grace Period to start. The Registrar is charged for the operation and the total registration period for the domain is extended by the renewal term, limited to the 10 year maximum.
– Transfer: an approved transfer command ends the current Renew Grace Period without a refund and begins a Transfer Grace Period.
– Bulk Transfers: bulk transfers cause the Renew Grace Period to end without a refund, consequently registration periods are not changed.
The Renew Grace Period has no impact on other commands.

4.3 Auto-Renew Grace Period
Length: 45 days
RGP Status: autoRenewPeriod
Auto-Renew Grace Period allows for domains to remain in the DNS past registration expiration while giving adequate time for the sponsoring Registrar to obtain intention of renewal from the registrant.
This period begins on the expiration of the domain and lasts for 45 days. If any of the following are performed during this period these rules apply:
– Delete: the sponsoring Registrar, who must be the sponsor when the Auto-Renew Grace Period commenced, may delete the domain and receive an auto-renew fee refund. The registration period auto-renew extension is reversed and the domain enters the Redemption state.
– Renew: the sponsoring Registrar, who must be the sponsor when the auto-renew occurred, can renew the domain again causing an independent Renewal Grace Period to begin. The Registrar is charged and the registration period is extended by the renewal term, limited to the 10 year maximum.
– Transfer: an approved transfer command ends the current Auto-Renew Grace Period with a refund to the losing Registrar and begins a Transfer Grace Period. The registration period auto-renew extension is reversed and the registration is extended by the period specified in the transfer.
– Bulk Transfers: bulk transfers cause the Auto-Renew Grace Period to end without a refund consequently registration periods are not changed.
The Auto-Renew Grace Period does not have any impact on other commands.

4.4 Transfer Grace Period
Length: 5 days
RGP Status: transferPeriod
Transfer Grace Period allows the sponsoring Registrar to undo the registration period extension (due to a transfer command), via the deletion of a domain. This period begins on a transfer completion and lasts for 5 calendar days. If the following are performed during the period these rules apply:
– Delete: the sponsoring Registrar, who must have initiated the transfer, may delete the domain and receive a transfer fee refund. The extension to the registration period of the preceding transfer is reversed and the Redemption state is entered.
– Renew: the sponsoring Registrar can renew the domain thus causing an independent Renewal Grace Period to begin. The Registrar is charged and the registration period for the domain is extended by the renewal term, limited to the 10 year maximum.
– Transfer: under Part A of the ICANN Policy on Transfer of Registrations between Registrars a transfer may not occur during the 60 day period after transfer (except in special circumstances). The registry system enforces this – effects of transfer do not require consideration. Should a special situation require transfer back to the losing Registrar, this is dealt with by taking into account the specific situation. The registry system does not allow this without intervention by registry staff.
– Bulk Transfers: bulk transfers cause the Transfer Grace Period to end without a refund; consequently registration periods are not changed.
The Transfer Grace Period does not have any impact on other commands.

4.5 Redemption Grace Period
Length: 30 days
RGP Status: as described in Redemption state
Redemption Grace Period refers to the period of time the domain spends in the Redemption state, starting after a domain is deleted. The Redemption state description provides information on operations during this period.

4.6 Overlap of Grace Periods
The 4 possible overlapping grace periods are:
– Add Grace Period with 1 or more Renew Grace Periods
– Renew Grace Period with 1 or more other Renew Grace Periods
– Transfer Grace Period with 1 or more Renew Grace Periods
– Auto-Renew Grace Period with 1 or more Renew Grace Periods
These are treated independently with respect to timelines however action that is taken has the combined effects of all grace periods still current.

4.6.1 Transfer Clarification
If several billable operations, including a transfer, are performed on a domain and it is deleted in the operations’ grace periods, only those operations performed after⁄including the latest transfer are eligible for refund.

5 TRANSITIONS

5.1 Available 〉 Registered
Triggered by the receipt of a create command to register the domain. The sponsoring Registrar is charged for the creation amount. This transition begins the Add Grace Period.

5.2 Registered 〉 Pending Transfer
Triggered by the receipt of a request transfer command. The transfer must result in domain registration extension – the gaining Registrar is charged for the transfer. Requests to transfer the domain within 60 days of creation or a previous transfer are rejected. As per ‘4.4 Transfer Grace Period’, exceptions specified in ICANN’s Transfer Policy apply – dealt with individually.

5.3 Pending Transfer 〉 Registered
Triggered by 1 of 4 operations:
– Operation 1 (Cancel): during the Pending Transfer period the gaining Registrar may cancel the transfer by issuing a cancel transfer command. The gaining Registrar is refunded the transfer fee, the registration period remains unchanged and all existing grace periods at the time of transfer request remain in effect.
– Operation 2 (Reject): during the Pending Transfer period the losing Registrar may reject the transfer by issuing a reject transfer command. The gaining Registrar is refunded the transfer. The registration period remains unchanged and all grace periods existing at the time of transfer request remain in effect if not elapsed.
– Operation 3 (Approve): During the Pending Transfer period the losing Registrar may approve the transfer by issuing an approve transfer command. If the transfer was requested during the Auto-Renew Grace Period, the extension to the registration period is reversed and the losing Registrar is refunded the auto-renew. The registration period is extended by the amount specified in the transfer request. This begins the Transfer Grace Period.
– Operation 4 (Auto-Approve): If after 5 days, no action has been taken, the system approves the transfer. If the transfer was requested during the Auto-Renew Grace Period the extension to the registration period is reversed and the losing Registrar is refunded the auto-renew. The registration period is extended by the amount specified in the transfer request. This begins the Transfer Grace Period.

5.4 Registered 〉 Deleted
On receipt of a delete command if the domain is in the Add Grace Period, it is purged from the Database and immediately available for registration. Renew Grace Period may also be in effect.

5.5 Registered 〉 Redemption
On receipt of a delete command if the domain is not in the Add Grace Period, it transitions to the Redemption Period state and all grace periods in effect are considered.

5.6 Redemption 〉 Pending Restore
On receipt of a restore command if the Redemption Period has not lapsed, the domain transitions to the Pending Restore state. The domain is provisioned in the DNS. The sponsoring Registrar is charged a fee for the restore request.

5.7 Pending Restore 〉 Registered
During the Pending Restore period the sponsoring Registrar may complete the restore via a restore report containing the WhoIs information – submitted prior to the deletion, the WhoIs information at the time of the report, and the reason for the restoration.

5.8 Pending Restore 〉 Redemption
Seven calendar days after the transition to the Pending Restore state, if no restore report is received the domain transitions to the Redemption state, which begins a new redemption period. The domain is removed from the DNS. The restore has no refund.

5.9 Redemption 〉 Pending Delete
Thirty calendar days after the transition to the Redemption state, if no restore request is received the domain transitions to the Pending Delete state.

5.10 Pending Delete 〉 Deleted
Five calendar days after the transition to the Pending Delete state, the domain is removed from the Database and is immediately available for registration.

6 LOCKS

Locks may be applied to the domain to prevent specific operations occurring. The sponsoring Registrar may set the locks prefixed with ‘client’ while locks prefixed with ‘server’ are added and removed by the registry operator. Locks are added and removed independently but they can be combined to facilitate the enforcement of higher processes, such as ‘Registrar Lock’, and outcomes required as part of UDRP. All locks are compatible with EPP RFCs. The available locks are:
– clientDeleteProhibited, serverDeleteProhibited – Requests to delete the object are rejected
– clientHold, serverHold – DNS information is not published
– clientRenewProhibited, serverRenewProhibited – Requests to renew the object are rejected. Auto-renew is allowed
– clientTransferProhibited, serverTransferProhibited – Requests to transfer the object are rejected
– clientUpdateProhibited, serverUpdateProhibited – Requests to update the object are rejected, unless the update removes this status

7 SPECIAL CONSIDERATIONS

7.1 ICANN-Approved Bulk Transfers
ICANN-Approved Bulk Transfers do not follow the typical transfer lifecycle. Existing grace periods are invalidated and no refunds are credited to the losing Registrar. The prohibition of transfer period on domains created or transferred within 60 days does not apply.

7.2 Uniform Rapid Suspension
In the Uniform Rapid Suspension (URS) process, as described in the ‘gTLD Applicant Guidebook’ 11 January 2012, the following modification to the above processes is required.
Remedy allows for the addition of a year to the registration period, limited to the 10 year maximum. During this time no transform operations may be performed other than to restore the domain as allowed by Appeal. At the expiration of the registration period the domain is not automatically renewed, but proceeds to the Redemption state as per the lifecycle described above, and it is not eligible for restoration.

8 UPDATE⁄DNS

The update command does not impact the state of the domain through the Registration Lifecycle, however the command can be used to add and remove delegation information, which changes the DNS state of the domain.
A domain is required to have 2 or more nameservers published in the DNS. An update that results in a domain having less than 2 nameservers removes the domain from the DNS. An exception is when 1 nameserver remains assigned to a domain due to deletion of its other nameservers due to purge of their parent domain. The next update that modifies delegation information ends the exception and from then on the domain requires 2 nameservers be in the DNS.

9 RESOURCES

This function will be performed by ARI. ARI’s registry performs all time-based transitions automatically and enforces all other business rules – without requiring human resources for normal operation. If changes to the automatic behaviours or restrictions enforced by the policy system are required, ARI has a development team for this.
Domain Name Lifecycle aspects requiring human resources to manage are included in the ARI outsourcing include:
– Processing Add Grace Period exemptions as requested by Registrars.
– Processing restore reports provided by Registrars.
– Meeting the registry operator’s obligations under ICANN’s Transfer Dispute Policy.
– Performing exception processing in the case of approved transfers during the 60 day transfer prohibition window.
The Registration Lifecycle is designed, built, operated and supported by these ARI departments:
– Products and Consulting Team (7 staff)
– Legal, Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q27 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q27 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Products and Consulting team is responsible for product management of the Registration Lifecycle, including working with clients and the industry to identify new features or changes required to the system. The team consists of:
– 1 Products and Consulting Manager
– 1 Product Manager
– 1 Technical Product Manager
– 4 Domain Name Industry Consultants
Most manual tasks fall to the Legal, Abuse and Compliance team, with staff experienced in development of policy for policy rich TLD environments. They have the required legal and industry background to perform this function. The team consists of:
– 1 Legal Manager
– 1 Legal Counsel
– 4 Policy Compliance Officers
The automated aspects of the Registration lifecycle are supported by ARI’s Domain Name Registry software. ARI has a development team for maintenance and improvement of the software. The team consist of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts
Information on these roles is in Resources in our response to Question 31. These resources sufficiently accommodate the needs of this TLD, and are included in ARI’s fees as described in our Financial responses.

In this response, the PCCS describes the efforts that will be undertaken in this TLD to minimise abusive registrations and other activities that have a negative impact on Internet users.

1 INTRODUCTION

The PCCS is committed to operating a secure and reliable TLD, facilitated by the planned operating model of the .catholic TLD and its comprehensive Acceptable Registration and Use Policy. The Acceptable Registration and Use Policy clearly defines “abuse”, identifies particular types of abusive behaviour falling within this definition, and identifies the mitigation response to be initiated when abusive behaviour is determined. This robust policy, in addition to the internal processes and procedures that the PCCS will implement to control domain name registration – all of which will be continually improved, updated and rigidly enforced – will serve to preclude abusive registrations from being made.
The PCCS’s commitment to minimising abuse in the .catholic TLD is further demonstrated by the adoption of relevant requirements proposed in the “2011 Proposed Security, Stability and Resiliency Requirements for Financial TLDs” [http:⁄⁄www.icann.org⁄en⁄news⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf] (the “BITS Requirements”). The PCCS acknowledges that these requirements were developed by the financial services sector in relation to financial TLDs, but nevertheless believes that their adoption in this TLD (which is not financial-related) results in a more robust approach to combating abuse. Particular BITS Requirements are noted where relevant throughout this answer.
The PCCS’s approach to combating abusive behaviour that affects rights in trademarks is described in the response to Question 29. Some overlap between the responses to Questions 28 and 29 is inherent because the prevention of abusive behaviours such as phishing and pharming can also serve to minimise cybersquatting and other infringements of trademark rights. By implementing the anti-abuse measures described in this response, the PCCS thus aims to also minimise the abuses specifically targeted in the response to Question 29.
For clarification, for the purposes of this response:
– References to the Registry Operator are references to the applicant entity, the PCCS. The PCCS intends to request (pursuant to clause 6) an exemption from clause 1b of the Registry Operator Code of Conduct to enable the PCCS to register domain names in its own right in the .catholic TLD. Registrations will not be made commercially available. All domain name registrations in the TLD will be registered to, and maintained by, the PCCS. The PCCS will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not an Affiliate (as that term is defined in Clause 2.9(c) of the Registry Agreement). The control inherent in this operating model will assist the PCCS in minimising abusive registrations and other activities that have a negative impact on Internet users.
– References to the Registry Services Provider are references to ARI Registry Services (ARI). The PCCS has engaged ARI to provide registry services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. Background information on ARI is provided in the attachment ‘Q28 – ARI Background & Roles.pdf’.
– References to a Registrar are references to an ICANN-accredited Registrar
The resources of each of the Registry Operator and Registry Services Provider relevant to the implementation of the anti-abuse measures described in this answer are described in detail in section 5 ‘RESOURCES’, at the end of this answer.

2 ACCEPTABLE REGISTRATION AND USE POLICY

The Acceptable Registration and Use Policy is the main instrument that captures the PCCS’s strategy in relation to identifying and handling abuse in the .catholic TLD. Having in place a robust anti-abuse policy is consistent with Requirements 3 and 4 of the BITS Requirements. Due to the planned operating model of this TLD, the Acceptable Registration and Use Policy will be the foundation of the PCCS’s efforts to minimise abusive behaviour in the TLD.

2.1 Definition of Abuse
Defining abusive behaviour by reference to the stage in the domain name lifecycle in which the behaviour occurs presents difficulty because a particular type of abuse may occur at various stages of the life cycle.
With this in mind, the PCCS has adopted the definition of abuse developed by the Registration Abuse Policies Working Group (Registration Abuse Policies Working Group (RAPWG) Final Report 2010, at http:⁄⁄gnso.icann.org⁄issues⁄rap⁄rap-wg-final-report-29may10-en.pdf), which does not focus on any particular stage in the domain name life cycle. In this report, the RAPWG came to a consensus definition of abuse. This definition (at page 19 of the RAPWG Final Report) reads:
Abuse is an action that:
a. Causes actual and substantial harm, or is a material predicate of such harm; and
b. Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.
The RAPWG’s Final Report further explains that the following factors should be considered when applying this definition:
– The party or parties harmed, and the severity and immediacy of the abuse, should be identified in relation to the specific alleged abuse.
– The term “harm” is not intended to shield a party from fair market competition.
– A predicate is a related action or enabler. There must be a clear link between the predicate and the abuse, and justification enough to address the abuse by addressing the predicate (enabling action).
The following example illustrates the application of the RAPWG’s consensus definition of abuse to a specific behaviour: WhoIs data can be used in ways that cause harm to many parties, including domain name registrants, intellectual property (IP) rights holders and Internet users. Harmful actions may include the generation of spam, the abuse of personal data, IP infringement, loss of reputation or identity theft, loss of data, phishing and other cybercrime-related exploits, harassment, stalking, or other activity with negative personal or economic consequences. Examples of predicates to these harmful actions are automated email harvesting, domain name registration by proxy⁄privacy services to aid wrongful activity, support of false or misleading registrant data, and the use of WhoIs data to develop large email lists for commercial purposes. The misuse of WhoIs data is therefore considered to be abusive because it is contrary to the intention and design of the stated legitimate purpose of WhoIs data.
Having adopted this definition of abuse and its interpretation in line with the RAPWG’s Final Report, the PCCS will measure all domain name registrations in the TLD and their use against this definition. It should be noted, however, that this is not the only standard against which the PCCS measures abuse within its organisation. Other internal policies and procedures are already in place relating to the use of IT resources. The Acceptable Registration and Use Policy will fit within the PCCS’s existing framework of policies and procedures relating to acceptable behaviour. Behaviour that is contrary to this framework will be addressed technically between the PCCS and the Registry Services Provider and procedurally between the PCCS and the breaching party.

2.2 Aims and Overview of the Acceptable Registration and Use Policy
The .catholic TLD Acceptable Registration and Use Policy will provide clear notice of the ways in which abuse will be identified and responded to, and thereby serve as a deterrent against abusive behaviour.
Consistent with Requirements 15 and 16 of the BITS Requirements, the Acceptable Registration and Use Policy:
– Defines abusive behaviour in the TLD.
– Identifies types of actions that constitute abusive behaviour consistent with the PCCS’s adoption of the RAPWG definition of “abuse”.
– Classifies abusive behaviours based on the severity and immediacy of the harm caused.
– Identifies how and to whom abusive behaviour can be notified and the steps that will be taken to determine whether the notified behaviour is abusive.
– Identifies the actions that may be taken in response to behaviour determined to be abusive.
While the PCCS recognises that each incidence of reported abuse represents a unique security threat and should be mitigated accordingly, it also recognises that prompt action justified by objective criteria are key to ensuring that mitigation efforts are effective. With this in mind, the Acceptable Registration and Use Policy categorises the actions that may be taken in response to various types of abusive behaviour by reference to the severity and immediacy of harm of such behaviour.

2.3 Acceptable Registration and Use Policy
The .catholic TLD Acceptable Registration and Use Policy is provided in full at the end of this answer. The PCCS’s specific plans regarding the implementation of this policy are described in the remaining sections of this answer.

3 ABUSE PREVENTION AND MITIGATION BY THE REGISTRY OPERATOR

This section describes the abuse-related policies and processes that will be implemented by the Registry Operator regarding:
– Building awareness of the Acceptable Registration and Use Policy
– Mitigating the potential for abusive behaviour
– Identifying abusive behaviour
– Handling abusive behaviour
Due to the complete control over registrations made in the TLD that is provided by an exemption to clause 1b of the Registry Operator Code of Conduct, the PCCS anticipates that these processes will contribute significantly to the minimisation of abusive registrations in the TLD because they function to control the behaviour of those specifically in a position to engage in such behaviour.

3.1 Awareness of the Acceptable Registration and Use Policy

The .catholic TLD Acceptable Registration and Use Policy is intended to provide clear notice of the ways in which abuse will be identified and responded to, and thereby serve as a deterrent against abusive behaviour in the TLD. Its efficacy therefore depends upon ensuring that the Registry Operator’s personnel and Affiliates are made aware of the Acceptable Registration and Use Policy. Awareness will be generated by requiring relevant employees and Affiliates of the Registry Operator to attend compulsory information sessions that will explain the Acceptable Registration and Use Policy and the ramifications of breaching this policy. Following the attendance of the information session, all attendees will be required to execute documentation which states that the attendee has read, acknowledged and understood the Acceptable Registration and Use Policy. The Acceptable Registration and Use Policy will be published internally as well as on the abuse page of the .catholic TLD registry website.
These efforts will place the PCCS’s personnel and Affiliates on notice of the applicability of the Acceptable Registration and Use Policy to all domain names in the .catholic TLD. These efforts will furthermore provide an opportunity to emphasise and evidence the PCCS’s commitment to combating abusive registrations. The PCCS anticipates that this clear message will serve to minimise abusive registrations in the TLD.

3.2 Pre-emptive – Mitigating the Potential for Abuse
The following practices and procedures will be adopted by the PCCS to mitigate the potential for abusive behaviour in the .catholic TLD.

3.2.1 Mitigating the Potential for Abusive Registrations that Affect the Legal Rights of Others
Many of the examples of abusive behaviour identified in the Acceptable Registration and Use Policy may affect the legal rights of trademark holders. While the Acceptable Registration and Use Policy addresses abusive behaviour in a broad sense, the PCCS will implement specific mechanisms to combat behaviours that affect the rights of trademark holders at start-up and on an ongoing basis. These include the implementation of a Trademark Claims service and a sunrise registration service at start-up of the TLD and implementation of the URS, UDRP and PDDRP on an ongoing basis. The implementation of these rights protection mechanisms, policies and procedures serves to mitigate the potential for abuse in this TLD by ensuring that domain names comprised of a trademark are allocated to those with a legal entitlement to the trademark. These mechanisms, policies and procedures are described in detail in the response to Question 29.

3.2.2 Increasing Security Awareness
In support of the PCCS’s commitment to operating a secure and reliable TLD, the PCCS will attempt to improve awareness within its organisation of the threats of domain name hijacking, registrant impersonation and fraud. The PCCS will also emphasise the need to keep registration information accurate. Awareness will be raised by, for example:
– Conducting bi-annual information sessions to make personnel aware of new and emerging threats relating to domain names and manners in which they may be mitigated.
– Publishing and making easily accessible relevant information in the form of videos, presentations and FAQ’s.
– Developing and implementing Best Common Practices that describe appropriate use of the communication channel between Registry Operator and Registrar and ensuring that the security of the channel is preserved.
The increase in awareness facilitated by the above practices will make the PCCS less susceptible to attacks on its domain names.

3.2.3 Registry Operator’s TLD Plan, Policies and Processes that Mitigate the Potential for Abuse

3.2.3.1 Planned TLD operating model inherently mitigates the potential for abuse
Underpinning the PCCS’s efforts to mitigate the potential for abuse in the .catholic TLD is the planned model of this TLD, whereby PCCS will register domain names in its own right and not sell, distribute or transfer domain names to any third party that is not its Affiliate. The adoption of this model grants the PCCS a high degree of control and facilitates the implementation of measures to minimise abuse by restricting to a small number of trusted individuals the capability of registering domain names and thus the potential to engage in abusive behaviour. This is in contrast to the model of existing TLDs, in which an inherent decrease in control results from enabling any number of individuals outside of the registry operator’s control to register domain names in the TLD. The planned operating model of this TLD precludes the abusive registration and use of domain names by unauthorised individuals not within the PCCS’s control. At the same time, this operating model eliminates the incentive for those within the PCCS to engage in abusive behaviour in the TLD, given that the PCCS’s mission, which is “to encourage and support in a timely and suitable way the action of the Church and her members in the many forms of social communication” (Article 170 of the Apostolic Constitution on the Roman Curia), is inherently intertwined with all domain names and uses of those domain names in the .catholic TLD.

3.2.3.2 Registration policies that mitigate the potential for abuse
The clear benefits of eligibility, naming and use restrictions as means of preventing and mitigating abusive behaviour have been recognised by the financial services sector, thus leading to proposed Requirements 1, 3 and 4 of the BITS Requirements. Consistent with those requirements, eligibility, naming and use restrictions will be imposed in this TLD. These are described in the response to Question 20.

3.2.3.3 Internal processes that mitigate the potential for abuse
The registration policies of this TLD will be implemented and enforced through internal processes which will be put into place by the PCCS prior to the launch of the .catholic TLD. These processes, which will include safeguards against allowing for unqualified registration and use of domains in this TLD, will be aimed at maintaining the integrity of the planned model of this TLD.
The primary safeguard against allowing for registrations in violation of the TLD’s eligibility criteria is the restriction of access to the registration channel to only those delegated the authority by the Registry Operator to register, update and transfer domain names in the TLD. Consistent with the proposed model of the TLD, domain names will be registered by the PCCS in its own right; because it is impossible for a legal entity to carry out such an action without the involvement of a human individual, the authority to register domain names in the name of the PCCS will be delegated to specifically designated individuals within the PCCS’s control.
The Registry Operator will only grant the following individuals within its organisation access to a secure and authenticated communication channel with the Registrar that enables the registration, update and transfer of domains in this TLD:
– The Project Manager, who is the only individual authorised to be designated as the Administrative Contact for all .catholic domain names.
– The Community Liaison Officers, who are the only two individuals authorised to be designated as the Technical Contact for .catholic domain names.
All domain name registrations, updates and transfers requested by the Community Liaison Officers will require the approval of the Project Manager, who will be responsible for ensuring that domain names fall within the Acceptable Registration and Use Policy. The Project Manager will also perform monthly audits of all domain name transactions to ensure their compliance with the Acceptable Registration and Use Policy.
The Registry Operator will supply the Registrar with the contact details of these individuals to enable the Registrar to provide each individual (via alternative sources) with their own credentials for accessing a secure and authenticated communication channel with the Registrar. The Registry Operator will continuously review the level of access that personnel have to the secure and authenticated communication channel.
This arrangement effectively mitigates the potential for abuse by tightly restricting the capability to register domain names to designated individuals, while also enabling the practicalities of domain name registration within the spirit of the planned model of the TLD.

3.2.4 Promoting WhoIs Accuracy
Inaccurate WhoIs information significantly hampers the ability to enforce policies in relation to abuse in the TLD by allowing a registrant to remain anonymous. In addition, law enforcement agencies rely on the integrity and accuracy of WhoIs information in their investigative processes to identify and locate wrongdoers. Restricting the ability to register domain names in this TLD to the Project Manager and the Community Liaison Officers means that a domain name’s contacts are well known and accessible by clear and reliable contact details. Published WhoIs information will thus accurately reflect the identity and contact information of the individual who created the domain name in the name of the PCCS. Individuals to whom the authority to register domain names is delegated will be continually made aware of their responsibility to provide and maintain accurate WhoIs information. The monthly audits of transactions performed by the Project Manager will ensure that WhoIs information in the .catholic TLD is complete and accurate.

3.2.5 Prompt Action Taken in Response to Notification by the Registry Services Provider
The Registry Services Provider will, pursuant to the managed registry services agreement in place between the Registry Operator and the Registry Services Provider, maintain correspondence with multiple points of contact within the Registry Operator’s organisation (including, but not limited to, the Project Manager, Community Liaison officer and Legal⁄Compliance Officer) in order to ensure that all relevant stakeholders are keep fully informed of all matters relating to abuse in the TLD as and when they arise.
As discussed in detail in sections 4.2.1 and 4.2.2 below, the PCCS expects that the Registry Services Provider will be able to detect abusive behaviour through its on-going technical registry monitoring activities and industry participation. If abusive behaviour is detected by the Registry Services Provider, this will be immediately notified to the Registry Operator. This notification mitigates the potential for abuse by enabling the PCCS to be responsive in a timely manner to breaches of the Acceptable Registration and Use Policy and to adapt internal processes to prevent the future reoccurrence of a breach.

3.3 Identification of Abusive Behaviour
While the PCCS is confident that the robust policy and internal process framework that will be put into place will minimise abusive behaviour in the TLD, the implementation of clear means of notification of abuse is vital to the robustness of the PCCS’s efforts to combat abuse in the TLD.
To this end, the PCCS will incorporate notifications from the following parties in its efforts to identify abusive behaviour:
– The Project Manager, through regular audits of all transactions in the TLD.
– Third parties, through a single abuse point of contact (the Abuse page on the registry website).
– Law enforcement, governmental and quasi-governmental agencies, through the expedited process available through the single abuse point of contact.
These three means of identification are discussed below.
The PCCS’s efforts in identifying abusive behaviour will be supported by the Registry Services Provider, in particular through its analysis of registry data and participation in industry forums that facilitate the sharing of information about abuse in TLDs. The Registry Services Provider’s role in identification of Abusive Behaviour is described in section 4.2, below.

3.3.1 Identification of Abusive Behaviour within the Registry Operator’s Organisation
As discussed in section 3.2.3.3 above, the Project Manager will perform a monthly audit of all domain name transactions to verify that transactions and the use of domain names are in compliance with the Registration Policy and Acceptable Registration and Use Policy. Any abusive behaviour identified through such an audit will be notified immediately by the PCCS to the Registrar, in accordance with Requirement 13 of the BITS Requirements.

3.3.2 Single Abuse Point of Contact
In accordance with section 4.1 of Specification 6 of the Registry Agreement, the PCCS will establish a single abuse point of contact to enable a timely response to abuse complaints made by the third parties concerning domain names registered in the .catholic TLD. Complaints may be received through the single abuse point of contact from members of the general public, including (but not limited to) registries, members of the anti-abuse community and security researchers.
The single abuse point of contact will provide accurate, up-to-date contact details (the Registry Operator’s email and mailing address, as well as a primary contact for handling inquiries related to abuse in the TLD). These details will be provided to ICANN and also clearly published on the Abuse page of the registry website. The registry website will also include:
– All policies in relation to the TLD, including the Acceptable Registration and Use Policy
– Best Practice standards adopted by the Registry Operator
As such, the single abuse point of contact may receive complaints regarding a range of matters, including (but not limited to) suspected breaches of the Acceptable Registration and Use Policy.
The single abuse point of contact will be the initial point of contact, following which other processes will be triggered depending on the identity of the reporting party. Separate processes exist for reporting abuse identified by law enforcement, governmental and quasi-governmental agencies and for members of the general public. These processes will each be described in turn, below.

3.3.3 Notification by Agencies of Abuse
The PCCS acknowledges the importance of its role as a registry operator in addressing Internet user vulnerabilities. The PCCS is likewise cognisant of the role of law enforcement, governmental and quasi– governmental agencies in efforts to minimise abuse in the TLD. The PCCS will make reasonable efforts to ensure the integration of these agencies into its processes for the identification and handling of abuse by, amongst other things:
1. Providing an expedited channel of communication (discussed below).
2. Sharing all available information upon request from law enforcement agencies utilising the expedited process, including results of any investigation undertaken by the PCCS or the Registry Services Provider.
3. Providing, through the expedited process, bulk WhoIs information upon request from law enforcement agencies.
4. Acting on instructions by a notifying agency provided that these do not entail the Registry Operator’s contravention of applicable law.
It is anticipated that these actions will assist agencies in the prevention, detection, investigation, prosecution or punishment of criminal offences or breaches of laws imposing penalties. The relevant agencies are not limited to those enforcing criminal matters, but may also include those enforcing civil matters in order to eliminate Internet user vulnerabilities.
The PCCS recognises in particular that law enforcement, governmental and quasi-governmental agencies may be privy to information beyond the reach of others that may prove critical in the identification of abusive behaviour in the TLD. As such, the PCCS will implement an expedited process to serve as a direct channel of communication for such agencies to, amongst other things, report illegal conduct in connection with the use of the TLD.
The expedited process will involve prioritisation and prompt investigation of reports identifying abuse from law enforcement, governmental and quasi-governmental agencies. The expedited process will be implemented through the following steps:
1. The PCCS will publish contact details on the Abuse page of the registry website for the single abuse point of contact to be utilised by only those taking part in the expedited process.
2. All calls to this number will be responded to by the Registry Operator’s Legal ⁄Compliance Officer within 24 hours.
3. Should the Registry Services Provider be notified by law enforcement, governmental or quasi-governmental agencies regarding abuse in the TLD, the Registry Services Provider will request that the notifying agency contact the Registry Operator’s Legal⁄Compliance Officer directly. The Registry Services Provider will thereafter promptly notify the Registry Operator’s Legal⁄Compliance Officer of its having been contacted by an agency regarding abuse in the TLD.

3.4 Abusive Behaviour – Handling

3.4.1 Handling Abuse Notified by the Project Manager
In the event that an audit conducted by the Project Manager reveals an unauthorised domain name transaction or other behaviour indicative of abuse, the Project Manager will notify the Registry Services Provider’s Abuse and Compliance Team, which will (as described in section 4.3 below) undertake a preliminary assessment and investigation to enable categorisation of the reported activity as one of the types of abusive behaviour falling within the scope of the Acceptable Registration and Use Policy. Based upon a report of the Registry Services Provider’s preliminary assessment and categorisation, the Registry Operator will take action in accordance with the subsequent section, 3.4.2.

3.4.2 Handling Abuse Notified Through the Single Abuse Point of Contact
In accordance with the managed registry services agreement in place between the Registry Operator and the Registry Services Provider, all reports of abuse made through the single abuse point of contact will be received by the Registry Services Provider on a 24⁄7 basis. Each report of purported abuse received through the single abuse point of contact will undergo an initial preliminary assessment to determine the legitimacy of the report, followed by (if appropriate) investigation to enable categorisation of the reported activity as one of the types of abusive behaviour falling within the scope of the Acceptable Registration and Use Policy by the application of the definitions provided in that policy. The Registry Services Provider will prepare a report to document the details of the reported abuse and the results of the Registry Services Provider’s preliminary assessment and classification. The implementation of this service, which is summarised here for context, is described in detail in section 4.2.5, below.
A report received from the Registry Services Provider will be used by the Registry Operator to determine the actions to be taken to mitigate an identified abusive behaviour in accordance with the table below. It must be emphasised that the actions to mitigate the identified type of abuse in the table are merely intended to provide a rough guideline, and may vary upon further investigation.
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware, Incomplete WhoIs Information
Mitigation steps:
1. Investigate
2. Take corrective action to eliminate the abusive behaviour
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name
2. Investigate
3. Restore or cancel domain name
The mitigation steps for each category will now be described.

3.4.2.1 Investigation – Category 1
Types of abusive behaviour that fall into this category include those that represent a low severity or immediacy of harm to the PCCS or Internet users. These generally include behaviours that result in the dissemination of unsolicited information or the publication of illegitimate information. While undesirable, these activities do not generally present such an immediate threat as to justify suspension of the domain name in question. Based upon the investigation undertaken, the Registry Operator will take corrective action to eliminate the abusive behaviour. The specific type of action taken will depend upon the abusive behaviour (for example, if incomplete WhoIs information is identified, the Project Manager will promptly provide missing information).

3.4.2.2 Suspension – Category 2
Types of abusive behaviour that fall into this category include those that represent a medium to high severity or immediacy of harm to the PCCS or Internet users. These generally include behaviours that result in intrusion into other computers’ networks and systems or financial gain by fraudulent means. On receipt of a report from the Registry Services Provider notifying the existence of such behaviours, the Registry Operator will immediately suspend the domain name pending further investigation to determine whether the domain name should be restored or cancelled. Cancellation will result if, upon further investigation, the behaviour is determined to be one of the types of abuse defined in the Acceptable Registration and Use Policy. Restoration of the domain name will result where the Registry Operator’s further investigation determines that abusive behaviour, as defined by the Acceptable Registration and Use Policy, does not exist.
Phishing is considered to be a serious violation of the Acceptable Registration and Use Policy owing to its fraudulent exploitation of Internet user vulnerabilities for the purposes of financial gain. Given the direct relationship between phishing uptime and extent of harm caused, the PCCS recognises the urgency required to execute processes that handle phish domain termination in a timely and cost effective manner. Accordingly, the PCCS will require that the Registry Services Provider prioritises all reports of phishing and communicates such reports to the Registry Operator within 12 hours of receipt of notification, in accordance with the Registry Services Provider’s contractual commitments to the Registry Operator in the form of SLA’s.

3.4.3. Executing agency instructions 
Upon notification of abusive behaviour by law enforcement, governmental or quasi-governmental agencies through the expedited process described in section 3.3.3 above, one of the following may occur:
1. Where specific instructions are received from the notifying agency in a format acceptable to the Registry Operator’s Legal ⁄Compliance Officer, the PCCS will act in accordance with those instructions provided that they do not result in the contravention of applicable law. The Registry Operator will execute the instructions of the notifying agency within 12 hours. Following prompt execution of the request, a report will be provided by the PCCS to the agency in a timely manner.
OR
2. The Registry Operator will forward a notification of abusive behaviour to the Registry Services Provider to enable preliminary assessment and investigation⁄categorisation by the Registry Services Provider as described in section 4.3, below. The Registry Operator will require that the Registry Services Provider provide within 24 hours a report of the assessment and investigation⁄categorisation of the notified behaviour, for provision by the Registry Operator to the notifying agency.
Finally, while the PCCS does not anticipate the occurrence of a security situation owing to the Registry Services Provider’s robust systems and processes deployed to combat abuse, the PCCS is aware of the availability of the Expedited Registry Security Request Process. This process enables a registry operator to inform ICANN of a present or imminent security situation and to request a contractual waiver for actions it might take or have taken to mitigate or eliminate the security concern.

4 ABUSE PREVENTION AND MITIGATION BY THE REGISTRY SERVICES PROVIDER

The PCCS will require through the managed registry services agreement in place with the Registry Services Provider that the Registry Services Provider facilitate the implementation of abuse-related processes in relation to:
– Mitigating the potential for abusive behaviour
– Identifying abusive behaviour
– Handling abusive behaviour
These procedures and processes are described below.

4.1 Pre-emptive – Mitigating the Potential for Abuse
Practices and procedures to be implemented by the Registry Services Provider in support of the PCCS’s efforts to mitigate the potential for abusive behaviour in the TLD are described below. Due to the internal controls inherent in the planned TLD model, the PCCS does not anticipate relying strongly on the anti-abuse services of the Registry Services Provider.

4.1.1 Registry Lock
Certain mission-critical domain names such as transactional sites, email systems and site-supporting applications may warrant a higher level of security. While the PCCS will take efforts to promote the awareness of security amongst those to whom the authority to register domain names is delegated, it is recognised that an added level of security may be provided by “registry locking” a domain name and prohibiting updates, thereby preventing unintentional transfer, modification or deletion of the domain name. This service mitigates the potential for abuse by prohibiting any unauthorised updates that may be associated with fraudulent behaviour. For example, an attacker may update nameservers of a mission critical domain name, thereby redirecting customers to an illegitimate website without actually transferring control of the domain name.
To achieve its stated purpose, being the prevention of the unintentional transfer, modification or deletion of a domain name, this mechanism will be implemented by the Registry Services Provider. Upon receipt of a list of domain names to be placed on Registry Lock by an authorised representative of the Registry Operator, the Registry Services Provider will:
1. Verify the identity of the authorised representative.
2. Set or modify the status codes for the names submitted to serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited depending on the request.
3. Record the status of the domain name in the Shared Registration System (SRS).
4. Provide a monthly report to the Registry Operator indicating the names for which the Registry Lock service was provided in the previous month.

4.1.2 ICANN-Prescribed Measures
The PCCS will comply with all obligations of a Registry Operator as prescribed in the Applicant Guidebook and ICANN’s Registry Agreement. Compliance with the following obligations which serve to mitigate the potential for abuse in the TLD will be executed by the Registry Services Provider through corresponding clauses in the managed services agreement in place between the Registry Operator and Registry Services Provider:
– DNSSEC deployment, which reduces the opportunity for pharming and other man-in-the-middle attacks. DNSSEC deployment is further discussed in the context of the response to Question 43.
– Prohibition on Wild Carding, as required by section 2.2 of Specification 6 of ICANN’s Registry Agreement.
– Removal of Orphan Glue records (discussed immediately below in section 4.1.3).

4.1.3 Orphan Glue Record Management
The Registry Services Provider engaged by the PCCS does not allow orphan records. Glue records are removed when the delegation point NS record is removed. Other domains that need the glue record for correct DNS operation may become unreachable or less reachable depending on their overall DNS service architecture. It is the registrant’s responsibility to ensure that their domain name does not rely on a glue record that has been removed and that it is delegated to a valid nameserver. The removal of glue records upon removal of the delegation point NS record mitigates the potential for use of orphan glue records in an abusive manner.

4.2 Identification of Abusive Behaviour
The support provided to the PCCS by the Registry Services Provider in relation to identifying abusive behaviour in the TLD is described below, including detection by the Registry Services Provider and notification by third parties. Instances of potentially abusive behaviour will be handled in accordance with the implementation plan described in section 4.3, below.

4.2.1 Detection – Analysis of Registry Data
The PCCS acknowledges that the Registry Services Provider’s access to registry data puts the Registry Services Provider in an effective position to identify abusive behaviour in the TLD. The Registry Services Provider is required through the managed registry services agreement in place with the Registry Operator to routinely analyse registry data by searching for behaviours typically indicative of abuse. The following are examples of the data variables that may serve as indicators of a suspicious domain name:
– Unusual Domain Name Registration Practices: practices such as registering hundreds of domains at a time, registering domains which are unusually long or complex or include an obvious series of numbers tied to a random word (abuse40, abuse50, abuse60) may, when considered as a whole, be indicative of abuse.
– Domains or IP addresses identified as members of a Fast Flux Service Network (FFSN): The Registry Services Provider engaged by the PCCS uses the formula developed by the University of Mannheim and tested by participants of the Fast Flux PDP WG to determine members of this list. IP addresses appearing within identified FFSN domains, as either NS or A records shall be added to this list.
– An Unusual Number of Changes to the NS record: the use of fast-flux techniques to disguise the location of web sites or other Internet services, to avoid detection and mitigation efforts, or to host illegal activities is considered abusive in the TLD. Fast flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or nameserver resolves. As such, an unusual number of changes to the NS record may be indicative of the use of fast-flux techniques given that there is little, if any, legitimate need to change the NS record for a domain name more than a few times a month.

4.2.2 Industry Participation and Information Sharing
The PCCS has engaged a Registry Services Provider that is a member of the Registry Internet Safety Group (RISG), whose mission is to facilitate data exchange and promulgate best practices to address Internet identity theft, especially phishing and malware distribution. In addition, the Registry Services Provider coordinates with the Anti-Phishing Working Group (APWG) and other DNS anti-abuse organisations and is subscribed to the NXdomain mailing list. The Registry Services Provider’s strong participation in the industry facilitates collaboration with relevant organisations on abuse-related issues and ensures that the Registry Services Provider’s services to the PCCS are responsive to new and emerging domain name abuses.
The information shared as a result of this industry participation will be used to identify domain names registered or used for abusive purposes. Information shared may include a list of registrants known to partake in abusive behaviour in other TLDs. In addition, information shared regarding practices indicative of abuse will facilitate detection of abuse by the PCCS’s own monitoring activities.



4.2.3 Notification by the Project Manager
It is anticipated that notification by the Registry Operator’s Project Manager of abusive behaviour will serve as the primary method by which the Registry Services Provider is notified of abuse in the TLD, given the Project Manager’s oversight over all registrations in the TLD. In the event that the monthly audit of domain name transactions reveals an unauthorised domain name transaction or other behaviour indicative of abuse, the Project Manager may notify such behaviour to the Registry Services Provider. All such notifications will result in the generation of a ticket in the Registry Services Provider’s case management system (CMS), which will be handled in accordance with section 4.3, below.

4.2.4. Notification by Agencies 
Should the Registry Services Provider be notified by law enforcement, governmental or quasi-governmental agencies regarding abuse in the TLD, the Registry Services Provider will request that the notifying agency contact directly the Registry Operator’s Legal ⁄Compliance Officer. The Registry Services Provider will promptly notify the Registry Operator’s Legal ⁄Compliance Officer of its having been contacted by an agency regarding abuse in the TLD.

4.2.5 Notification by the General Public
The single abuse point of contact established by the Registry Operator will be implemented by the Registry Services Provider according to the following steps:
1. The Registry Operator will publish contact details on the Abuse page of the registry website for the single abuse point of contact (note that these contact details are not the same as those that will be provided for the expedited process available to law enforcement, governmental and quasi-governmental agencies).
2. All reports made through the single abuse point of contact will be received by the Registry Services Provider’s Service Desk on a 24⁄7 basis. All calls will result in the generation of a CMS ticket. The details of the report identifying abuse will be documented in the CMS ticket using a standard information gathering template.
4. Tickets will be forwarded to the Registry Services Provider’s Abuse and Compliance Team, to be handled in accordance with section 4.3, below.

4.3 Abusive Behaviour – Handling
Although the PCCS does not anticipate the occurrence of abusive behaviour in the .catholic TLD owing to the high degree of control inherent the planned model of the TLD, the PCCS nevertheless acknowledges the importance of having in place processes to handle identified abuse.
The Registry Services Provider will be required (through the managed registry services agreement in place between the PCCS and Registry Services Provider) to assist the Registry Operator in the implementation of the Acceptable Registration and Use Policy. In particular, the Registry Services Provider will assist with the following actions:
– Preliminary assessment of notified abuse.
– Further investigation and categorisation of notified abuse, if warranted by the preliminary assessment.
– Reporting to the Registry Operator.
– Executing instructions received from the Registry Operator relating to handling of identified abuse in the TLD.

4.3.1 Preliminary Assessment 
Each report of purported abuse received through the single abuse point of contact will undergo an initial preliminary assessment by the Registry Services Provider’s Abuse and Compliance Team to determine the legitimacy of the report. This step may involve simply visiting the offending website and is intended to weed out spurious reports. This will not at this stage involve the in-depth investigation needed to make a determination as to whether the reported behaviour is abusive.

4.3.2 Categorisation
Where the report is assessed as being legitimate, the type of activity reported will be further investigated to enable categorisation of the reported activity as one of the types of abusive behaviour falling within the scope of the Acceptable Registration and Use Policy by the application of the definitions provided in that policy. In order to make this categorisation, the Registry Services Provider’s Abuse and Compliance Team must establish a clear link between the activity reported and the alleged type of abusive behaviour such that addressing the reported activity will address the abusive behaviour.
This categorisation will be applied to each validated report of abuse in accordance with the Acceptable Registration and Use Policy, the relevant part of which is reproduced in the table below:
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
The assessment made and actions taken will be recorded against the relevant CMS ticket.

4.3.3 Registry Services Provider Report to Registry Operator
Upon conclusion of the preliminary assessment and categorisation described above, the Registry Services Provider will prepare a report to the Registry Operator. This report will:
– Clearly set out the details of the notified abuse.
– Explain the steps taken to conduct a preliminary assessment of the notified abuse and identify the results of the preliminary assessment.
– Explain the further investigation undertaken and the classification made by the Registry Services Provider’s Abuse and Compliance Team as a result of that investigation.
Due to the higher severity or immediacy of harm attributed to types of abusive behaviour in Category 2 as identified above, the SLA’s in place between the Registry Operator and Registry Services Provider require that the Registry Services Provider communicate its report in regards to a Category 2 behaviour within 24 hours.
Phishing is considered to be a particularly serious violation of the Acceptable Registration and Use Policy owing to its fraudulent exploitation of Internet user vulnerabilities for the purposes of financial gain. Given the direct relationship between phishing uptime and extent of harm caused, the Registry Operator recognises the urgency required to execute processes that handle phish domain termination in a timely and cost effective manner. Accordingly, the Registry Services Provider is required to prioritise all reports of phishing from brand owners, anti-phishing providers or others, and communicate reports of such activity to the Registry Operator within 12 hours, in accordance with the SLA’s in place between the Registry Operator and Registry Services Provider.

4.3.4 Executing Registry Operator Instructions Regarding Handling of Abuse 
The Registry Services Provider will promptly execute instructions received from the Registry Operator in relation to the handling of abusive behaviour, in accordance with the managed registry services agreement and SLAs in place between the Registry Operator and Registry Services Provider.

5 RESOURCES

The efforts to minimise abusive registrations and other activities that have a negative impact on Internet users in this TLD will be resourced jointly by the Registry Operator and the Registry Services Provider.

5.1 Registry Operator Resources
The following is a description of the resources that are allocated to performing the tasks required by the Registry Operator. These tasks will be absorbed by the individuals currently performing the following roles within the Registry Operator’s organisation.


5.1.1 Project Manager
In the context of operating this TLD, the Registry Operator’s Project Manager will be responsible for managing the creation of all domains in this TLD. The Project Manager will pre-approve all requests to create and⁄or update domain names by the Community Liaison Officers. In addition, the Project Manager will perform a monthly audit of all domain name transactions to verify that these were authorised and that the use of domain names complies with the Acceptable Registration and Use Policy. Finally, the Project Manager will conduct bi-annual information sessions to improve awareness within the PCCS of the threat of domain name hijacking and fraud as well as raising awareness of the Acceptable Registration and Use Policy.

5.1.2 Community Liaison Officers
The Registry Operator’s Community Liaison Officers will be responsible for managing the Registry Operator’s domain name portfolio, which will involve creating, updating and maintaining all domains in this TLD on behalf of the Registry Operator.

5.1.3 Legal⁄Compliance Officer 
The Registry Operator’s Legal⁄Compliance Officer will be responsible for responding to all reports and requests by law enforcement agencies, managing the expedited process for those agencies and handling all escalated complaints and potential disputes arising in connection with the implementation the Acceptable Registration and Use Policy. This will involve assessing escalated complaints and issues, resolving disputes and liaising with all relevant stakeholders (Registrar, Registry Services Provider, law enforcement agencies, the general public, etc.) as needed in fulfilling these responsibilities.

5.2 Registry Services Provider Resources
ARI’s abuse services are supported by the following departments:
– Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
– Service Desk (14 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q28 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system. Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3,824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q28 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally, ARI can scale resources as required.
Certain specifically identified measures described in the responses to Questions 28 and 29 – which serve to prevent and mitigate abusive behaviour in the TLD as well as activities that may infringe trademarks – will be implemented and managed by ARI on the PCCS’s behalf. These responsibilities will be undertaken by three teams. ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the procedures and measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse. ARI’s Abuse and Compliance Team will be responsible for handling abuse reported through the single abuse point of contact, as well as ongoing support of measures to minimise abusive registrations and other activities that have a negative impact on Internet users. ARI’s Service Desk will be responsible for responding to reports of abuse received through the single abuse point of contact on the registry’s website and logging these in a ticket in ARI’s case management system.
The responsibilities of these teams relevant to the initial implementation and ongoing maintenance of measures to minimise abusive registrations and other activities that affect the rights of trademark holders are described in the response to Question 29 – Rights Protection Mechanisms.
All of the responsibilities undertaken by these teams are inclusive in ARI’s managed registry services fee, which is accounted for as an outsourcing cost in the response to Question 47. The resourcing needs of these teams have been determined by applying the conservative growth projections for this TLD (as identified in the response to Question 48) to the teams’ responsibilities at start-up and on an ongoing basis.

5.2.1 ARI Development Team
All tools and systems needed to support the initial and ongoing implementation of measures adopted to mitigate the potential for abuse, identify abuse and handle identified abuse will be developed and maintained by ARI. ARI has a software development department dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change.
ARI’s Development Team participate actively in the industry; this facilitates collaboration with relevant organisations on abuse related issues and ensures that the ARI Development Team is responsive to new and emerging domain name abuses and the tools and systems required to be built to address these abuses. This team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts

5.2.2 ARI Abuse and Compliance Team
ARI’s Abuse and Compliance Team will be staffed by four full-time equivalent Policy Compliance Officers. These roles will entail the following:
A principal responsibility of the Policy Compliance Officers will be managing notifications of abuse through the single abuse point of contact. This will involve identifying and categorising suspected abuse according to the Acceptable Registration and Use Policy and carrying out the appropriate mitigation response for all categorised abuses. Policy Compliance Officers will also be responsible for analysing registry data in search of behaviours indicative of abuse and reviewing industry lists in search of data that may identify abuse in the TLD. Furthermore, Policy Compliance Officers will provide training to the Project Manager of the Registry Operator’s organisation regarding abuse prevention and mitigation in order to enable the Project Manager to competently manage the registration and use of domain names and conduct information sessions which highlight the application of the Acceptable Registration and Use Policy.
Policy Compliance Officers will act on the instructions of the Registry Operator, verified law enforcement agencies or dispute resolution providers and participate in ICANN and industry groups involved in the promulgation of policies and best practices to address abusive behaviour. They will escalate complaints and issues to the Registry Operator’s Legal ⁄Compliance Officer when necessary and communicate with all relevant stakeholders (Registrar, law enforcement agencies, general public, etc.) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis, supported outside of ordinary business hours by ARI’s Service Desk.
Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, comprehensive knowledge of abusive behaviour in a TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.

5.2.3 ARI Service Desk
ARI’s Service Desk will be staffed by 14 full-time equivalent positions. Responsibilities of Service Desk relevant to ARI’s anti-abuse service include the following: responding to notifications of abuse through the single abuse point of contact, directing law enforcement agencies to contact the Registry Operator directly using the expedited process for such agencies, notifying the Registry Operator of a report of abuse received from law enforcement, government and quasi-governmental agencies, logging notifications received through the single abuse point of contact as a ticket in ARI’s case management system, and forwarding tickets to ARI’s Abuse and Compliance team for resolution in accordance with the Acceptable Registration and Use Policy.
Based on the projections and the experience of ARI, the resources described here are more than sufficient to accommodate the needs of this TLD.
For more information on the skills and responsibilities of these roles, please see the in-depth resources section in answer to Question 31.

6. CATHOLIC TLD ACCEPTABLE REGISTRATION AND USE POLICY

6.1 Introduction
The abusive registration and use of domain names in the TLD is not tolerated given that the inherent nature of such abuses creates security and stability issues for all participants in the Internet environment.

6.2 Definitions
a. “Registry Operator” means the registry operator of the .catholic TLD as per the .catholic TLD Registry Agreement with ICANN;
b. “Abusive behaviour” is an action that:
 i. Causes actual and substantial harm, or is a material predicate of such harm; or
 ii. Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of the mission⁄purpose of the TLD.
c. A “predicate” is an action or enabler of a harm; and
d. “Material” means that something is consequential or significant.

6.3 Examples of Abusive Behaviour
Examples of abusive behaviour falling within the definition provided in b. above include, but are not limited to, the following:
– Spam: the use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks.
– Phishing: the use of a fraudulently presented web site to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Pharming: the redirecting of unknowing users to fraudulent websites or services, typically through DNS hijacking or poisoning, in order to deceive Internet users into divulging sensitive information such as usernames, passwords or financial data.
– Wilful distribution of malware: the dissemination of software designed to infiltrate or cause damage to devices or to collect confidential data from users without the owner’s informed consent.
– Fast Flux hosting: the use of DNS to frequently change the location on the Internet to which the domain name of an Internet host or nameserver resolves in order to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast flux hosting may only be used with prior permission of the registry operator.
– Botnet command and control: the development and use of a command, agent, motor, service or software which is implemented: (1) to remotely control the computer or computer system of an Internet user without their knowledge or consent, (2) to generate direct denial of service (DDOS) attacks.
– Distribution of pornography: the storage, publication, display and⁄or dissemination of pornographic materials.
– Illegal access to other computers or networks: the illegal accessing of computers, accounts, or networks belonging to another party, or attempt to penetrate security measures of another individual’s system (hacking). Also, any activity that might be used as a precursor to an attempted system penetration.

6.4 Detection of Abusive Behaviour
Abusive behaviour may be detected in the TLD in the following ways:
– Through ongoing monitoring of all domain name transactions and use of domain names.
– Through on-going technical registry monitoring activities and industry participation.
– By third parties (general public, law enforcement, governmental and quasi-governmental agencies, industry partners, etc.) through:
 i. Notification submitted to the single abuse point of contact on the registry’s website; and
 ii. Industry alerts.

6.5 Notification of Abusive Behaviour
A single abuse point of contact is provided by the Registry Operator to facilitate notification of detected abusive behaviours in relation to the TLD. The single abuse point of contact’s accurate contact details (email and mailing address as well as a primary contact for handling inquiries related to abuse in the TLD) are published on the Abuse page of the registry website. Complaints may be lodged using the single abuse point of contact by any party that has detected abuse in relation to the TLD.
The Registry Operator recognises that law enforcement, governmental and quasi-governmental agencies may be privy to information beyond the reach of others which may prove critical in the identification of abusive behaviour in the TLD. As such, the Registry Operator will additionally provide through the single abuse point of contact an expedited process which serves as a direct channel of communication by such agencies with the Registry Operator to, amongst other things, report illegal conduct in connection with the use of the TLD. This process will involve prioritisation and prompt investigation of reports identifying abuse from those agencies.
All reports of abusive behaviour made through the single abuse point of contact will be notified immediately to the Registrar.

6.6 Handling of Abusive Behaviour
1. Preliminary Assessment
When notification of abusive behaviour is received through the single abuse point of contact, a preliminary assessment will be performed to determine whether the notification is legitimately made.
2. Classification and Mitigation
Where a notification is assessed as being legitimate, the type of activity reported will be further investigated to enable categorisation of the notified activity as one of the types of abusive behaviour falling within the scope of this Acceptable Registration and Use Policy. This categorisation will be applied to each validated report of abuse, and actions will be taken in accordance with the table below. That these expected actions are intended to provide a guide to the response to abusive behaviour rather than any guarantee that a particular action will be taken.
Category 1:
Probable Severity or Immediacy of Harm: Low
Examples of types of abusive behaviour: Spam, Malware, Incomplete WhoIs Information
Mitigation steps:
1. Investigate
2. Take corrective action to eliminate the abusive behaviour
Category 2:
Probable Severity or Immediacy of Harm: Medium to High
Examples of types of abusive behaviour: Fast Flux Hosting, Phishing, Illegal Access to other Computers or Networks, Pharming, Botnet command and control
Mitigation steps:
1. Suspend domain name
2. Investigate
3. Restore or cancel domain name
In the event that the Registry Operator receives specific instructions regarding a domain name from a law enforcement agency, governmental or quasi-governmental agency utilising the expedited process for such agencies, mitigation steps will be taken in accordance with those instructions provided that they do not result in the contravention of applicable law.
The identification of abusive behaviour in the TLD, as defined above, shall give the Registry Operator the right to take actions necessary to do any of the following:
1. Protect the integrity and stability of the registry.
2. Comply with applicable laws, government rules or requirements, requests of law enforcement, or dispute resolution process.
3. Avoid any liability, civil or criminal, on the part of the Registry Operator, as well as its affiliates, subsidiaries, officers, directors, and employees.
4. Correct mistakes made in connection with a domain name registration.
The Registry Operator may amend or otherwise modify this policy to keep abreast of changes in consensus policy or new and emerging types of abusive behaviour relating to the Internet.

1 INTRODUCTION
Rights protection is a core objective of this TLD, facilitated by its planned operating model and well-developed rights protection mechanism (RPM) implementation plans. The PCCS’s commitment to minimising abuse in the TLD is further demonstrated by the adoption of relevant requirements proposed in the “2011 Proposed Security, Stability and Resiliency Requirements for Financial TLDs” [http:⁄⁄www.icann.org⁄en⁄news⁄correspondence⁄aba-bits-to-beckstrom-crocker-20dec11-en.pdf] (the “BITS Requirements”). The PCCS acknowledges that these requirements were developed by the financial services sector in relation to financial TLDs, but nevertheless believes that their adoption in this TLD (which is not financial-related) results in a more robust approach to combating abuse. Particular BITS Requirements are noted where relevant throughout this response.
The clear benefits of eligibility, naming and use restrictions as means of preventing and mitigating abusive behaviour have been recognised by the financial services sector, captured in Requirements 1, 3 and 4 of the BITS Requirements. The eligibility, naming and use restrictions in this TLD are described in the response to Question 20. These will be enforced at the time of registration through the internal processes described in the response to Question 28. These processes will ensure that multiple applications for the same name are not made, thus addressing Requirement 2 of the BITS Requirements. This robust policy and procedure framework, which will be continually improved, updated and rigidly enforced, will preclude abusive registrations from being made.
The abuse primarily targeted by RPMs is cybersquatting, which is the registration of domain names constituting trademarks by registrants lacking rights in such marks. Different RPMs define the scope of protectable trademarks slightly differently; the scope of protectable marks as respects each RPM is therefore clearly identified in the implementation plans below. Cybersquatting is one of the many forms of abuse the PCCS seeks to minimise in this TLD. The PCCS’s approach to combating other forms of abusive behaviour is described in the response to Question 28. Some overlap between the responses to Questions 28 and 29 is inherent because the prevention of abuse affecting trademark rights can also serve to minimise other abusive behaviours such as phishing and pharming. By implementing RPMs, the PCCS thus aims also to minimise abuse as identified in the response to Question 28.
For clarification, for the purposes of this response:
– References to the Registry Operator are references to the applicant entity, the PCCS. The PCCS intends to request (pursuant to clause 6) an exemption from clause 1b of the Registry Operator Code of Conduct to enable the PCCS to register domain names in its own right in the .catholic TLD. Registrations will not be made commercially available. All domain names in the TLD will be registered to, and maintained by, the PCCS. The PCCS will not sell, distribute or transfer control or use of any registration in the TLD to any third party that is not an Affiliate (as that term is defined in Clause 2.9(c) of the Registry Agreement). The control inherent in this operating model will assist the PCCS in minimising abusive registrations and other activities that have a negative impact on Internet users.
– References to the Registry Services Provider are references to ARI Registry Services (ARI). The PCCS has engaged ARI to provide registry services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. Background information on ARI is provided in the attachment ‘Q29 – ARI Background & Roles.pdf’.
– References to a Registrar are references to an ICANN-accredited Registrar.

2 START-UP RPMs

This section identifies the start-up RPM timeline and describes implementation of:
– A sunrise registration service
– The TM Claims service

2.1 Start-up RPMs Timeline
The timeline for start-up RPMs in the .catholic TLD is as follows:
Day 1: Sunrise round opens
Day 30: Sunrise round closes
Day 31: Sunrise allocation period
Day 32: General registration begins, TM Claims service begins
Day 92: TM Claims service ends

2.2 Sunrise Registration Service
Sunrise provides trademark holders satisfying the eligibility restrictions of this TLD (as identified in the response to Question 20) with a 30-day priority period in which to register their marks as domain names. Due to these eligibility restrictions, applicants other than the PCCS will be precluded from registering, but holders of trademarks entered in the TMCH (TMCH) will have the benefit of notice of sunrise registrations constituting an “Identical Match” to their marks.
The following stakeholders are involved in implementation of the sunrise registration service:
– TMCH Service Provider⁄s
– Registrar⁄s
– PCCS
– Registry Services Provider 
The role played by these stakeholders is described below with reference to:
– A summary of the Sunrise Policy and Sunrise Dispute Resolution Policy (SDRP)
– The Sunrise Implementation Plan
– The SDRP Implementation Plan
– Implementation of sunrise and SDRP through contractual relationships

2.2.1 Sunrise Policy Summary and SDRP Summary
The Sunrise Policy will offer a single, 30-day sunrise round in which trademark holders satisfying (i), (iii) and (iv) of the Sunrise Eligibility Requirements (SERs) in the Applicant Guidebook at TMCH s6.2.3 and the eligibility restrictions of the TLD (identified in the response to Question 20) will be entitled to apply for a domain name. This is the first opportunity for domain name registration in the TLD.
The Sunrise Policy will describe the sunrise framework, including the following:
– Applications received by a Registrar within the 30-day Sunrise Period and satisfying the SERs and general eligibility restrictions of the TLD will be accepted for sunrise participation; 
– The trademarks upon which sunrise applications are based must fall within the Applicant Guidebook at TMCH s7.2 and be supported by an entry in the TMCH.
– Domains registered during sunrise will have a term of one year from the date of registration.
– Multiple applications for the same name will be resolved by the PCCS prior to application.
The PCCS will also adopt and submit to an SDRP which will incorporate the following:
– Claims may be raised against a domain applied for during sunrise on the four grounds identified in the Applicant Guidebook at TMCH s6.2.4.
– Complaints must clearly identify the challenger, challenged domain name, and ground⁄s upon which the complaint is based, and explain why the challenger believes that the ground⁄s are satisfied.
– The remedies available are cancellation or deletion of a successfully challenged domain.
If a TMCH service provider is unable to receive challenges directly as part of its undertaking to “maintain the SERs, validate and authenticate marks, as applicable, and hear challenges” (Applicant Guidebook at TMCH s6.2.5), the PCCS (or the Registry Services Provider on the PCCS’s behalf) will receive challenges and communicate these to the SDRP provider.

2.2.2 Sunrise Implementation Plan
1. Prior to or during the 30-day sunrise period, trademark holders can apply for validation of trademarks by the TMCH and inclusion of validated marks in the TMCH database.
2. The Registry Services Provider will develop a website to enable the Registry Operator to publish the Sunrise Policy and SDRP.
3. The PCCS’s Community Liaison Officers will submit applications to a Registrar for domain names corresponding to a TMCH entry with evidence of the corresponding TMCH entry. If additional information or evidence of identity is required for validation by the Registrar, this will also be provided with the application.
4. Pursuant to the PCCS’s Registry-Registrar Agreement (RRA), the Registrar will be required to validate the registrant’s identity and communicate sunrise application information to the Registry Services Provider.
5. The Registry Services Provider will perform standard checks (including IDN validity checks where relevant, reserved and restricted words in accordance with the Registry Agreement, composition requirements, etc) to ensure that the domain applied for is technically valid; an error message will be returned to the Registrar if the domain fails any of these checks.
6. Through an interface with the TMCH, the Registry Services Provider will identify all sunrise applications constituting an “Identical Match” (as defined in the Applicant Guidebook at TMCH s6.1.5) with a TMCH entry and provide notice to the holders of those trademarks of the filing of a corresponding sunrise registration.
7. A one-day allocation period will occur after the sunrise period closes. Compliance with internal processes will ensure that multiple applications are not made for the same name. The Registry Services Provider will enable the Registrar to CREATE (using EPP or the SRS web interface) technically valid domain names.

2.2.3 SDRP Implementation Plan
1. The SDRP will specify an email address to which SDRP filings must be sent if a TMCH service provider is not able to directly receive SDRP complaints. This address will be monitored by the Registry Operator.
2. The Registry Services Provider will develop a process of manual or automatic interface with the TMCH to communicate the SERs and any SDRP challenges received by the Registry Operator. This interface will also enable the TMCH service provider to notify the Registry Operator of successful SDRP challenges.
3. On notification from a TMCH service provider of a successful SDRP challenge, the Registry Services Provider will cancel or delete the domain name the subject of the successful challenge.

2.2.4 Implementation of Sunrise and SDRP through Contractual Relationships
The responsibilities of the Registry Services Provider described above regarding implementation of the Sunrise Policy and SDRP are in accordance with the managed registry services agreement between the PCCS and the Registry Services Provider.

2.3 TM Claims Service
Immediately following the one-day sunrise allocation period, a 60-day period will commence during which the TM Claims service will be offered. This is a service whereby domain name applicants receive notice of existing trademarks matching their applied-for domain and trademark owners receive notice of registrations matching their mark. In accordance with the Applicant Guidebook, the TM Claims service in this TLD will be supported exclusively by the TMCH and will recognise and honour all word marks falling within the Applicant Guidebook at TMCH s7.1.
The following stakeholders are involved in implementation of the TM Claims service:
– TMCH Service Provider⁄s
– Trademark owners
– Registrar⁄s
– PCCS
– Registry Services Provider
The role played by these stakeholders is described below by reference to:
– The TM Claims Service Implementation Plan
– Implementation of the TM Claims service through contractual relationships

2.3.1 Implementation

2.3.1.1 TM Claims Service Implementation Plan
1. Prior to or during the 60-day TM Claims period, trademark holders can apply for validation of their marks by the TMCH and entry in the TMCH database. This enables the provision of notice to applicants during this period of entries in the TMCH and notice to trademark holders of registrations matching TMCH entries (how and by whom this will be achieved is detailed in subsequent steps of this implementation plan).
2. The PCCS’s Community Liaison Officers will submit applications to a Registrar to register domain names corresponding to a TMCH entry with evidence of the corresponding TMCH entry. If additional information or evidence of identity is required for validation by the Registrar, this will also be provided with the application.
3. Pursuant to the PCCS’s RRA, the Registrar will validate the registrant’s identity.
4. For all applications received during this 60-day period, a Registrar will be required pursuant to the PCCS’s RRA to interface with the TMCH to determine whether an applied-for domain constitutes an “Identical Match” with a trademark in the TMCH. If an “Identical Match” is identified, the Registrar will provide to the applicant a TM Claims Notice in the form prescribed by the Applicant Guidebook. Following receipt of this notice, the applicant must communicate to the Registrar a decision either to proceed with or abandon the application. If the applied-for name does not constitute an “Identical Match” with a mark in the TMCH, no TM Claims Notice will be generated.
5. The Registry Services Provider will utilise the manual or automatic interface established for implementation of the SDRP (described above in “SDRP IMPLEMENTATION PLAN”) to facilitate reporting to registries by the TMCH of attempts to register domain names that are an “Identical Match” with a trademark (as defined in the Applicant Guidebook at TMCH s7.1) in the TMCH database.
6. If a TM Claims Notice is generated, the PCCS will conduct a review to determine whether to proceed with the application. If a decision is made to proceed, the Registrar will be required pursuant to the PCCS’s RRA to communicate the application information to the Registry Services Provider.
7. The Registry Services Provider will perform standard checks to ensure that the applied-for domain is technically valid; an error message will be returned to the Registrar if the domain fails any of these checks. If the domain passes these checks, the Registry Services Provider will enable the sponsoring Registrar to CREATE (using EPP or the SRS web interface) the domain. Compliance with internal processes will ensure that multiple applications are not made for the same name.
8. A registrar will be required pursuant to the PCCS’s RRA to interface with the TMCH to promptly notify relevant mark holders of the registration of a domain constituting an “Identical Match” to their TMCH entry.

2.3.1.2 Implementation through Contractual Relationships
The responsibilities of the Registry Services Provider in relation to implementation of the TM Claims service are set out in the managed registry services agreement in place between the PCCS and the Registry Services Provider.
The TM Claims Service Implementation Plan provided above will additionally be executed through the inclusion of the following clauses in the PCCS’s RRA:
– A registrar must make use of the TMCH as required by ICANN and the TMCH service provider⁄s.
– A registrar must not in its provision of the TM Claims service make use of any trademark information aggregation, notification or validation service other than the TMCH.
– In order to prevent a chilling effect on registration, a registrar must ensure that an applicant is not prevented from registering domain names considered an “Identical Match” with a mark in the TMCH.
– A registrar must provide clear notice to the applicant of relevant entries in the TMCH in the specific form provided by the Applicant Guidebook.

3 ONGOING RPMs

Abusive behaviour in this TLD will be prevented by the TLD’s operating model as well as the internal processes that the PCCS will implement to control domain name registration. In its capacity as registrant, the PCCS acknowledges that it is subject to the URS and UDRP. Further, the PCCS takes seriously its responsibilities as Registry Operator and acknowledges that it is subject to the Trademark PDDRP (to which all registry operators, regardless of the operating model of the new gTLD, are bound). The PCCS will abide by decisions rendered through those RPMs.
The PCCS highlights that the operating model it proposes to adopt in this TLD is a new TLD model; RPMs designed prior to the new gTLD program were not designed with this model in mind. Even the newly designed URS and Trademark PDDRP are from conceptual and implementation perspectives not entirely practicable for TLDs in which the Registry Operator registers domain names in its own right. Where gaps exist in current policy, these are noted and addressed in the implementation plans set out below.

3.1 URS
The URS is a new RPM the implementation of which is mandated in all new gTLDs. It is targeted at providing a rapid takedown solution to clear-cut cases of cybersquatting. It is intended to have a deterrent effect and reduce the number of disputes under the UDRP.
Due to the control over registrations provided by the proposed operating model of this TLD, the PCCS does not anticipate any situation in which it could be argued in good faith both that the PCCS has “no legitimate right or interest to the domain name” in question and “that the domain name was registered and is being used in bad faith”. The risk of URS complaints will be minimised through internal processes controlling domain name registration, but these processes would not stop a claimant from making a URS claim (even one in bad faith) against the PCCS. The PCCS does not anticipate that URS claims will arise in this TLD, but nevertheless has developed an implementation plan to ensure that this mechanism is in place and is compliant with registry operators’ obligations.
The URS is intended to supplement and not replace the UDRP, and the Applicant Guidebook foreshadows (at URS ss8.6 and 13) the likelihood of URS claimants also commencing UDRP claims. For this reason, the URS Implementation Plan below considers the potential interaction between URS stakeholders and UDRP stakeholders.
The following stakeholders are involved in implementation of the URS:
– URS claimants (holders of valid and enforceable trade or service marks)
– Registrar⁄s
– PCCS
– Registry Services Provider
– URS provider⁄s
– URS Examiner
The role played by these stakeholders is described below by reference to:
– The URS Implementation Plan
– Implementation of the URS through contractual relationships

3.1.1 Implementation
The PCCS acknowledges that it is prohibited from making changes to the WhoIs information of a registration if it has failed to respond to a URS complaint (default). This is in accordance with the Applicant Guidebook at URS s6.1. The PCCS also acknowledges that it is prohibited from making changes to a domain name in locked status. Understanding that a fundamental aim of the URS is expediency, all of the steps in the URS Implementation Plan set out below will be undertaken as soon as practical but without compromising security or accuracy. The implementation plan identifies certain aspects of implementation that are required under the Applicant Guidebook but nevertheless are not possible or practical to implement in the context of this TLD given its planned operating model.

3.1.1.1 URS Implementation Plan
1. The PCCS will notify to each URS provider an email address to which URS-related correspondence should be sent in respect of this TLD. The Registry Operator will monitor this address on an ongoing basis for communications from URS providers.
2. The Registry Services Provider will assist the Registry Operator in validating correspondence received to ensure that it originates from the URS Provider.
3. The Registry Services Provider will within 24 hours of receipt of a URS Notice of Complaint lock the domain name⁄s the subject of that complaint by restricting all changes to the registration data, including transfer and deletion of the domain. The domain will continue to resolve while in this locked status.
4. The Registry Services Provider will immediately notify the URS provider in the manner requested by the provider once the domain⁄s have been locked.
5. On receipt of a favourable URS Determination, the Registry Services Provider will lock domain⁄s the subject of Determination for the balance of the registration period and redirect the nameservers to an informational web page provided by the URS provider. While a domain is locked, the Registry Services Provider will continue to display all of the WhoIs information of the original registrant except for the redirection of the nameservers and the additional statement that the domain will not be able to be transferred, deleted or modified for the life of the registration.
6. On receipt of notification from the URS provider of termination of a URS proceeding, the Registry Services Provider will promptly unlock the domain and return full control to the registrant.
7. If a default has occurred (because a response has not been submitted to a URS complaint in accordance with the Applicant Guidebook at URS s6.1) and a Determination has been made in favour of the complainant, in the event that the Registry Operator receives notice from a URS provider that a Response has been filed in accordance with the Applicant Guidebook at URS s6.4, the Registry Services Provider will as soon as practical restore a domain to resolve to the original IP address while preserving its locked status until a Determination from de novo review is notified to the Registry Operator.
8. The Registry Operator will ensure that no changes are made to the resolution of a registration the subject of a successful URS Determination until expiry of the registration or the additional registration year unless otherwise instructed by a UDRP provider.
It is noted that the Applicant Guidebook requires that registry operators make available to successful URS complainants an optional extension of the registration period for one additional year at commercial rates. This is rendered impractical in the context of this TLD by its planned operating model.

3.1.1.2 Implementation of the URS through Contractual Relationships
The responsibilities of the Registry Services Provider above relating to implementation of the URS are in accordance with the managed registry services agreement in place between the PCCS and the Registry Services Provider.
The PCCS’s RRA will require that a Registrar not take any action relating to a URS proceeding except as in accordance with a validated communication from the Registry Operator or a URS provider.

3.2 UDRP
The UDRP is applicable to domain name registrations in all new gTLDs. It is available to parties with rights in valid and enforceable trade or service marks and is actionable on proof of three grounds identified in the policy as on ICANN’s website: http:⁄⁄archive.icann.org⁄en⁄udrp⁄udrp-policy-24oct99.htm
Because the PCCS will have control of all registrations in the .catholic TLD, it does not anticipate many, if any, situations in which it could be argued in good faith both that the PCCS has “no rights or legitimate interest in respect of the domain name” in question and that the name “has been registered and is being used in bad faith”. The risk of UDRP complaints will be minimised through internal processes controlling domain name registration, but these processes would not stop a claimant from making a claim (even one in bad faith) against the PCCS. The PCCS does not anticipate that UDRP claims will arise in this TLD, but nevertheless has developed an implementation plan to ensure that this mechanism is in place and is compliant with registry operators’ obligations.
The remedies offered by the UDRP are cancellation or transfer of a domain name to a successful UDRP claimant. The PCCS notes, however, that transfer is rendered impossible in the context of this TLD; where an exemption to clause 1b of the Registry Operator Code of Conduct has been granted enabling the registry operator to register domain names in its own right, transfer of domains is prohibited. For this reason, it appears that the only applicable remedy to a UDRP claim raised against the PCCS is cancellation of the disputed domain. The PCCS will place cancelled names on a list to prevent their subsequent registration.
The following stakeholders are involved in implementation of the UDRP:
– UDRP claimants
– Registrar⁄s
– PCCS
– Registry Services Provider
– UDRP providers
The role played by these stakeholders is described below by reference to:
– The UDRP Implementation Plan
– Implementation of the UDRP through contractual relationships
The UDRP Implementation Plan considers the potential overlap between URS and UDRP implementation because of the potential that URS complainants will commence UDRP claims as a second recourse or simultaneously. The PCCS notes that neither policy prohibits complainants from commencing proceedings simultaneously.

3.2.1 Implementation

3.2.1.1 UDRP Implementation Plan
This UDRP Implementation Plan focuses on interaction with Registrars because there is currently no interaction between existing gTLD registry operators and UDRP providers. The PCCSs considers that it and the Registry Services Provider have two principal responsibilities in facilitating a Registrar’s implementation of the UDRP: i) maintaining awareness of UDRP requirements; and ii) being capable of taking action when required and sufficiently skilled and flexible to respond to any changes to UDRP policy.
UDRP implementation would also ordinarily require that the Registry Services Provider provide EPP and the SRS web interface to enable a Registrar to perform required UDRP functions in accordance with the Policy on Transfer of Registrations between Registrars. However, the PCCS considers transfers between Registrars not likely to arise in this TLD and transfer is not a viable remedy for UDRP violation due to the planned operating model of the TLD.

3.2.1.2 Implementation of the UDRP through Contractual Relationships
The UDRP is applicable to domain name registrations in all new gTLDs by force of a contractual obligation (Registry Agreement Art. 2.9) on registry operators to use only ICANN-accredited Registrars, who in turn are contractually required (Registrar Accreditation Agreement, 21 May 2009, at 3.8) to incorporate the UDRP in their Registration Agreements. The responsibilities of the Registry Services Provider in relation to implementation of the UDRP as described above are in accordance with the managed registry services agreement in place between the PCCS and the Registry Services Provider.

3.3 Preventing Trademark Infringement in Operating the Registry
The new Trademark PDDRP, which targets trademark infringement arising from a registry operator’s manner of operation or use of its TLD, is primarily directed at the situation in which trademark holders have no clear RPM-based recourse against a registry operator. In the proposed operating model of this TLD, however, trademark owners do have recourse against the Registry Operator under the URS and UDRP. The grounds of those RPMs differ, however, from the grounds of the Trademark PDDRP. Grounds for raising a Trademark PDDRP claim are as follows:
a. There is a substantial pattern or practice of specific bad faith intent by the registry operator to profit from the sale of trademark infringing domain names; and
b. The registry operator’s bad faith intent to profit from the systematic registration of domain names within the gTLD that are identical or confusingly similar to the complainant’s mark, which:
 i. Takes unfair advantage of the distinctive character or reputation of the complainant’s mark; or
 ii. Impairs the distinctive character or reputation of the complainant’s mark; or
 iii. Creates a likelihood of confusion with the complainant’s mark.
As required by the Registry Agreement, the PCCS agrees to participate in all Trademark PDDRP procedures and be bound by resulting determinations. The PCCS nevertheless considers the risk of Trademark PDDRP claims being raised against the PCCS negated by the fact that it will not be possible for claimants to satisfy the two grounds cited above. Specifically, it cannot be shown that there exists a “substantial pattern or practice... to profit from the sale of trademark infringing domain names” because domain names will not be sold in this TLD.
The PCCS will implement the Trademark PDDRP in accordance with the implementation plan below, but does not foresee that any Trademark PDDRP claims raised against the PCCS could succeed.
The following stakeholders are involved in the implementation of measures to prevent trademark infringement in the PCCS’s manner of operation of the .catholic TLD:
– Trademark holders
– PCCS
– Registry Services Provider
– Trademark PDDRP provider⁄s
The role played by these stakeholders is described below by reference to:
– The Trademark PDDRP Implementation Plan
– Implementation of the Trademark PDDRP through Contractual Relationships

3.3.1 Implementation

3.3.1.1 Trademark PDDRP Implementation Plan
1. The PCCS will notify to the Trademark PDDRP provider⁄s contact details for communications regarding the Trademark PDDRP, including the threshold determination, Trademark PDDRP complaint, complainant’s reply, notice of default, expert panel determinations, notice of appeal and determinations of an appeal panel.
2. As described in the response to Question 28, the Registry Services Provider will develop a website and to enable the Registry Operator to publish on that website policies relating to the TLD. Consistent with Requirement 8 of the BITS Requirements, this website will also provide the Registry Operator’s contact details. This will enable trademark holders to contact the PCCS to raise a complaint regarding trademark infringement and resultant harm caused by the PCCS’s operation or use of the .catholic TLD.
3. The details of a complaint will be documented by the PCCS using a standard information gathering template, which will include the following:
– Complainant name
– Contact details
– Trademark name
– Jurisdiction
– Registration date
– Registration number
– Nature of entitlement to trademark
– Explanation of why complainant believes that its mark has been infringed and harm caused by the PCCS’s operation or use of the TLD
4. The PCCS will conduct a preliminary assessment to ensure that a complaint is not spurious. If it is determined that a complaint is not spurious, PCCS will commence investigation and good faith negotiation with the complainant in accordance with the Applicant Guidebook at Trademark PDDRP s7.2.3(d).
5. In the event that a complaint cannot be resolved and a Trademark PDDRP claim is made, the PCCS will do the following:
– File a response in accordance with the Applicant Guidebook at Trademark PDDRP s10 (thus avoiding, whenever possible, default).
– Where appropriate, make and communicate to the Trademark PDDRP provider decisions regarding the Trademark PDDRP proceeding, including whether to request a three-person Trademark PDDRP Expert Panel (Trademark PDDRP s13.2), request discovery (s15.1), request a hearing (s16), request a de novo appeal (s20.1), challenge an ICANN-imposed Trademark PDDRP remedy (s21.3), initiate dispute resolution under the Registry Agreement (s21.4), or commence litigation in the event of a dispute arising under the Trademark PDDRP (s22).
– Where appropriate, undertake discovery in compliance with the Applicant Guidebook at Trademark PDDRP s15, attend hearings raised under s16, and gather evidence in compliance with ss20.5 and 20.6.
7. The PCCS will reimburse a Claimant on notification of an Expert Panel finding in favour of that Claimant (Trademark PDDRP s14.3).
8. The PCCS will implement any remedial measures recommended by the expert panel pursuant to Trademark PDDRP s18.3.1 and take all steps necessary to cure violations found by the expert panel (Trademark PDDRP s18.3.2) and notified by ICANN (Trademark PDDRP s21.3).

3.3.1.2 Implementation of Trademark PDDRP through Contractual Relationships
All new gTLD registry operators are bound to comply with the Trademark PDDRP by Specification 7, cl 2 of the Registry Agreement. The responsibilities of the Registry Services Provider in relation to implementation of the Trademark PDDRP are in accordance with the managed registry services agreement in place between the PCCS and the Registry Services Provider.

4 RESOURCES

The efforts to minimise abusive registrations and other activities that have a negative impact on Internet users in this TLD will be resourced jointly by the Registry Operator and the Registry Services Provider.

4.1 Registry Operator Resources
The following responsibilities will be absorbed by the individuals currently performing the following roles within the Registry Operator’s organisation.

4.1.1 Project Manager
The Registry Operator’s Project Manager will be responsible for managing the creation of domains in this TLD. In particular the Project Manager will pre-approve all requests to create and⁄or update domain names by the Community Liaison Officers and perform a monthly audit of all domain name transactions. The Project Manager will additionally be responsible for supporting the implementation of the sunrise, TM Claims service, URS, UDRP and Trademark PDDRP.

4.1.2 Community Liaison Officers
The Registry Operator’s Community Liaison Officers will be responsible for managing the Registry Operator’s domain name portfolio, which will involve creating, updating and maintaining domains in this TLD on behalf of the Registry Operator.

4.1.3 Legal⁄Compliance Officer
The Registry Operator’s Legal⁄Compliance Officer will be responsible for receiving, assessing and managing trademark infringement complaints and handling issues arising in connection with the implementation of RPMs in the TLD. This will involve assessing escalated complaints and issues, resolving disputes and liaising with all relevant stakeholders (Registrar, Registry Services Provider, trademark holders, RPM providers, etc.) as needed in fulfilling these responsibilities.

4.2 Registry Services Provider Resources
ARI’s abuse services are supported by the following departments:
– Abuse and Compliance Team (6 staff)
– Development Team (11 staff)
– Service Desk (14 staff)
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q29 – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system. Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3,824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q29 – Registry Scale Estimates & Resource Allocation.xlsx’ for more information. ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required.
Certain measures described in the responses to Questions 28 and 29 – which serve to prevent and mitigate abusive behaviour in the TLD including activities that may infringe trademarks – will be implemented and managed by ARI on the PCCS’s behalf. These responsibilities will be undertaken by three teams. ARI’s Development Team will be responsible for developing the technical platforms and meeting technical requirements needed to implement the RPMs discussed above. ARI’s Abuse and Compliance Team will be responsible for the ongoing operations of measures to minimise abusive registrations and other activities that affect trademark rights recognised through RPMs. ARI’s Service Desk will be responsible for supporting the Abuse and Compliance team out of hours. The responsibilities of these teams relevant to the implementation and ongoing maintenance of measures to minimise the potential in this TLD for abuse not specifically affecting trademark rights are described in the response to Question 28.
All of the responsibilities undertaken by these teams are inclusive in ARI’s managed registry services fee, which is accounted for as an outsourcing cost in the response to Question 47. The resourcing needs of these teams have been determined by applying the conservative growth projections for this TLD (as identified in the response to Question 48) to the teams’ responsibilities at start-up and on an ongoing basis.

4.2.1 ARI Development Team
All tools and systems used for the transmission and receipt of information related to RPMs will be developed and maintained by ARI. ARI has a Development Team dedicated to this purpose which will ensure that the tools are fit for purpose and adjusted as requirements change. ARI will ensure that systems and tools will be compliant with the appropriate processes for dealing with Registrars, the TMCH, URS and Trademark PDDRP providers as these processes are defined. ARI has been and will remain active in the formulating of these processes. ARI will use its resources to remain current with the approved measures for exchange of any material relevant to RPMs, whether during sunrise or on an ongoing basis. This team consists of:
– 1 Development Manager
– 2 Business Analysts
– 6 Developers
– 2 Quality Analysts

4.2.2 ARI Abuse and Compliance Team
ARI’s Abuse and Compliance Team is staffed by five full-time equivalent positions:
– 4 Policy Compliance Officers
– 1 Legal Manager
Policy Compliance Officers’ responsibilities relevant to RPMs include managing sunrise applications, managing communications between ARI and the TMCH service providers, SDRP provider⁄s, URS provider⁄s, UDRP providers and Trademark PDDRP provider⁄s, escalating complaints and issues to the Legal Manager when necessary, and communicating with all relevant stakeholders (Registry Operator, Registrar, RPM providers, trademark holders, general public, etc.) as needed in fulfilling these responsibilities. This role will be provided on a 24⁄7 basis supported by the ARI Service Desk. Policy Compliance Officers will be required to have the following skills⁄qualifications: customer service⁄fault handling experience, complete knowledge of all RPMs offered by the TLD and related policies, Internet industry knowledge, relevant post-secondary qualification, excellent communication and professional skills, accurate data entry skills, high-level problem solving skills, and high-level computer skills.
The Legal Manager will be responsible for handling RPM-related disputes involving ARI. This will involve assessing complaints and issues, liaising with legal counsel and management, resolving disputes and communicating with all relevant stakeholders (Registry Operator, Registrar, trademark holders, RPM providers, general public, etc) as needed in fulfilling these responsibilities. The Legal Manager will be required to have the following skills⁄qualifications: legal background (in particular, intellectual property⁄information technology law) or experience with relevant tertiary or post-graduate qualifications, dispute resolution experience, Internet industry experience, excellent communication, negotiation, problem solving and professional skills and good computer skills.

4.2.3 ARI Service Desk
ARI’s Service Desk is staffed by 14 full-time equivalent positions. The Service Desk will support the Abuse and Compliance Team outside of ordinary working hours.
For more information on the skills and responsibilities of these roles, please see the in-depth resources section in response to Question 31.
Based on the projections and the experience of ARI, the resources described here are more than sufficient to accommodate the needs of this TLD.

We have engaged ARI Registry Services (ARI) to deliver services for this TLD. ARI provide registry services for a number of TLDs including the .au ccTLD. For more background information on ARI please see attachment ‘Q30(a) – ARI Background & Roles.pdf’. This response describes Security as implemented by ARI under direction from the registry operator, taking into account any specific needs for this TLD.

1 SECURITY POLICY SUMMARY

ARI operates an ISO27001 compliant Information Security Management System (ISMS) for Domain Name Registry Operations; see attachment ‘Q30(a) – SAI Global Certificate of Compliance.pdf’. The ISMS is an organisation-wide system encompassing all levels of Information Security policy, procedure, standards, and records. Full details of all the policies and procedures included in the ISMS are included in the attachment to Question 30(b).

1.1 The ISMS
ARI’s ISMS’s governing policy:
– Defines the scope of operations to be managed (Domain Name Registry Operations).
– Designates the responsible parties (COO, CTO and Information Security Officer) for governance, Production Support Group for implementation and maintenance, and other departments for supporting services.
– Requires a complete Risk Assessment (a developed Security Threat Profile for the Service – in this case registry services for the TLD – and a Risk Analysis tracing threats and vulnerabilities through to Risks) and Risk Treatment Plan (each major risk in the Risk Assessment references the Statement of Applicability indicating controls to be implemented, responsible parties, and the effectiveness metrics for each).
– Includes a series of major sub policies governing security, which include but are not limited to:
 – ICT acceptable use policy and physical security policies.
 – PSG Security Policy which outlines the registry operations policies, the management of end-user devices, classification of networks and servers according to the classification of information they contain, networking, server and database configuration and maintenance guidelines, vulnerability and patch management, data integrity controls, access management, penetration testing, third party management, logging and monitoring, and cryptography.
– Requires ongoing review:
 – Of risks, threats, the Risk Treatment Plan, client requirements and commitments, process and policy compliance, process and policy effectiveness, user etc.
 – Regular internal and external penetration testing and vulnerability scanning.
 – Ad-hoc review raised during normal operations, common sources being change management processes, scheduled maintenance or project debriefs, and security incidents.
 – Yearly review cycle which includes both internal and external audits, including external surveillance audits for compliance.
 – Additional yearly security controls assessment reviews, which include analysis of the security control implementations themselves (rather than compliance with any particular standard).
 – At 24 month intervals, external penetration testing of selected production services.
 – periodic ISO reaccreditation
ARI’s ISMS encompasses the following ARI standards:
– Configuration standards for operating systems, networking devices and databases based on several key publications, including those released by NIST (e.g. SP800-123, SP800-44v2, SP-800-40, SP800-41) and the NSA, staff testing and experience, and vendor supplied standards.
– Security Incident Classification, which identifies the various classifications of security incidents and events to ensure that events that qualify as security incidents.
– Information Classification and Handling which specifies the information classification scheme and the specific requirements of handling, labeling, management and destruction for each level of classification.

1.2 SECURITY PROCESSES
Processes are used to implement the policies. These include, but are not limited to:

1.2.1 Change Management
This includes change management and its sub-processes for access management, software deployment, release of small changes and scheduled maintenance. This process includes:
– The classification of changes and the flow into sub processes by classification.
– The release and deployment process for change control into production environments, outlining peer review, testing steps, approval points, checklist sets, staging requirements and communication requirements.
– The software release and deployment process with its specific testing and staged rollout requirements.
– The scheduled maintenance process and its various review points.

1.2.2 Incident Management
This includes incident management process and its sub-process for unplanned outages. These outline:
– How incidents are managed through escalation points, recording requirements, communication requirements etc.
– The unplanned outage procedure which applies directly to situations where the registry itself or other critical services are unexpectedly offline.

1.2.3 Problem Management
The goal of problem management is to drive long term resolution of underlying causes of incidents. This process centres on finding and resolving the root causes of incidents. It defines escalation points to third parties or other ARI departments such as Development, as well as verification of the solution prior to problem closure.

1.2.4 Security Incident Management
This process deals with the specific handling of security incidents. It outlines the requirements and decision points for managing security incidents. Decision points, escalation points to senior management and authorities are defined, along with evidence-gathering requirements, classification of incidents and incident logging.

1.2.5 Access Management
This process handles all access changes to systems. HR must authorize new users, and access changes are authorized by departmental managers and approved by the Information Security Officer.
When staff leave or significantly change roles, a separation process is followed which ensures all access that may have been granted during their employment (not just their initially granted access) is checked and where appropriate, revoked.
Finally, quarterly review of all access is undertaken by the ISO, reviewing and approving or rejecting (with an action ticket) as appropriate.

2 ARI’s SECURITY INFRASTRUCTURE SOLUTIONS

ARI has developed a layered approach to IT security infrastructure. At a high level, some of the layers are as follows:
– DDoS countermeasures are employed outside ARI networks. These include routing traps for DDoS attacks, upstream provider intervention, private peering links and third party filtering services.
– Routing controls at the edge of the network at a minimum ensures that only traffic with valid routing passes into ARI networks.
– Overprovisioning and burstable network capabilities help protect against DoS and DDoS attacks.
– Network firewalls filter any traffic not pre-defined by network engineering staff as valid.
– Application layer firewalls then analyse application level traffic and filter any suspicious traffic. Examples of these would be an attempt at SQL injection, script injection, cross-site scripting, or session hijacking.
– Server firewalls on front-end servers again filter out any traffic that is not strictly defined by systems administrators during configuration as valid traffic.
– Only applications strictly necessary for services are running on the servers.
– These applications are kept up-to-date with the latest security patches, as are all of the security infrastructure components that protect them or that they run on.
– ARI infrastructure is penetration-tested by external tools and contracted security professionals for vulnerabilities to known exploits.
– ARI applications are designed, coded and tested to security standards such as OWASP and penetration-tested for vulnerabilities to common classes of exploits by external tools and contracted security professionals.
– ARI configures SELinux on its production servers. Specific details of this configuration is confidential; essentially any compromised application is extremely limited in what it can do.
– Monitoring is used to detect security incidents at all layers of the security model. Specifically:
 – Network Intrusion Detection systems are employed to monitor ARI networks for suspicious traffic.
 – ARI maintains its own host-based Intrusion Detection system based on tripwire, which has now undergone four years of development. Specific details are confidential, but in summary, the system can detect any unusual activity with respect to configuration, program files, program processes, users, or network traffic.
 – More generic monitoring systems are used as indicators of security incidents. Any behaviour outside the norm across over 1,100 individual application, database, systems, network and environmental checks is investigated.
– Capacity management components of the monitoring suite are also used to detect and classify security incidents. Some examples are:
 – Network traffic counts, packet counts and specific application query counts.
 – Long term trend data on network traffic vs. specific incident windows.
 – CPU, Storage, Memory and Process monitors on servers.
– A second layer of hardware firewalling separates application and middle tier servers from database servers.
– Applications only have as much access to database information as is required to perform their function.
– Finally, database servers have their own security standards, including server-based firewalls, vulnerability management for operating system and RDBMS software, and encryption of critical data.

2.1 Physical Security Infrastructure
ARI maintains a series of physical security infrastructure measures including but not limited to biometric and physical key access control to secured areas and security camera recording, alarm systems and monitoring.

3 COMMITMENTS TO REGISTRANTS

We commit to the following:
– Safeguarding the confidentiality, integrity and availability of registrant’s data.
– Compliance with the relevant regulation and legislation with respect to privacy.
– Working with law enforcement where appropriate in response to illegal activity or at the request of law enforcement agencies.
– Maintaining a best practice information security management system that continues to be ISO27001-compliant.
– Validating requests from external parties requesting data or changes to the registry to ensure the identity of these parties and that their request is appropriate. This includes requests from ICANN.
– That access to DNS and contact administrative facilities requires multi-factor authentication by the Registrar on behalf of the registrant.– That Registry data cannot be manipulated in any fashion other than those permitted to authenticated Registrars using the EPP or the SRS web interface. Authenticated Registrars can only access Registry data of domain names sponsored by them.
– A Domain transfer can only be done by utilizing the AUTH CODE provided to the Domain Registrant.
– Those emergency procedures are in place and tested to respond to extraordinary events affecting the integrity, confidentiality or availability of data within the registry.

4 AUGMENTED LEVEL OF SECURITY

This TLD is a single-registrant⁄single-user TLD (.brand style) and as such requires security considerations that are commensurate with its purpose. Our goal with this TLD is to use the TLD internally and adequate protect it against unauthorized registrations or modifications to the namespace, without making the internal process too onerous and thus increasing costs. Whilst, due to the single-registrant⁄single-user nature, it is relatively straightforward to restrict and enforce restrictions on registrations, the impact of an unauthorised registration can be high, potentially damaging.
The following attributes describe the security with respect to the TLD:
– ARI, follows the highest security standards with respect to its Registry Operations. ARI is ISO 27001 certified and has been in the business of providing a Registry backend for 10 years. ARI have confirmed their adherence to all of the security standards as described in this application. As per recommendation 24 this ensures that the technical implementations do not compromise elevated security standards
– A single Registrar will be nominated for this TLD, facilitating the tightest possible control over Registrant validity enforcement and domain registration restrictions.
– Registrant will only be permitted to make changes to their domain name after a authenticating to their Registrar.
– Registrants will only be able to access all interfaces for domain registration and management via HTTPS. A reputed digital certificate vendor will provide the SSL certificate of the secure site.
– Registrar identity will be manually verified before they are accredited within this TLD. This will include verification of corporate identity, identity of individuals involved ⁄ mentioned, and verification of contact information
– Registrars will only be permitted to connect with the SRS via EPP after a multi-factor authentication that validates their digital identity. This is described further ahead.
– Registrars will only be permitted to use a certificate signed by ARI to connect with the Registry systems. Self-signed certificates will not be permitted.
– The Registry is DNSSEC enabled and the TLD zone will be DNSSEC enabled. This is described in detail in our response to Question 43. The following additional requirements will exist for Registrars who want to get accredited to sell this TLD:
 – Registrars must support DNSSEC capabilities within its control panels.
 – If the Registrar provides Managed DNS services to Registrants within this TLD they must provide DNSSEC for the same. This ensures that DNSSEC is deployed at each zone and subsequent sub-zones at Registry, Registrar and Registrant level as per recommendation 26.
– Registrar access to all Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 27. This is described in detail in our responses to Question 24 and Question 25.
– Registrant access to all Registrar and Registry Systems will be via TLS and secured with multi-factor authentication as per recommendation 28. This is described in detail in our response to Question 25, Question 27 and Question 29.
 – All communication between the Registrar or the Registrars systems and the registry system is encrypted using at least 128 bit encryption which been designated as ‘Acceptable’ till ‘2031 and beyond’ by NIST Special Publication 800-57. This includes the following communication:
 – Secure websites and control panels provided by the Registrar to the Registrant.
 – Ticketing systems provided by the Registrar to the Registrant.
 – Web and EPP interfaces provided by ARI to the Registrars.
 – Ticketing systems provided by ARI to the Registrar.
 – Any communication between the Registrant, Registrar and Registry that is deemed as critical or contains credentials or sensitive information.
Where these requirements put controls on Registrars these will be enforced through the RRA.

5 RESOURCES

This function will be performed by ARI. The following resources are allocated to performing the tasks required to deliver the services described:
– Executive Management Team (4 staff)
– Production Support Group (27 staff)
ARI has ten years’ experience designing, developing, deploying, securing and operating critical Registry systems, as well as TLD consulting and technology leadership.
As a technology company, ARI’s senior management are technology and methodology leaders in their respective fields who ensure the organisation maintains a focus on technical excellence and hiring, training and staff management.
Executive Management is heavily involved in ensuring security standards are met and that continued review and improvement is constantly undertaken. This includes the:
– Chief Operations Officer
– Chief Technology Officer
A detailed list of the departments, roles and responsibilities in ARI is provided as attachment ‘Q30(a) – ARI Background & Roles.pdf’. This attachment describes the functions of the above teams and the exact number and nature of staff within.
The number of resources required to design, build, operate and support the SRS does not vary significantly with, and is not linearly proportional to, the number or size of TLDs that ARI provides registry services to.
ARI provides registry backend services to 5 TLDs and has a wealth of experience in estimating the number of resources required to support a registry system.
Based on past experience ARI estimates that the existing staff is adequate to support a registry system that supports in excess of 50M domains. Since this TLD projects 3824 domains, 0.0076% of these resources are allocated to this TLD. See attachment ‘Q30(a) – Registry Scale Estimates & Resource Allocation.xlsx’ for more information.
ARI protects against loss of critical staff by employing multiple people in each role. Staff members have a primary role plus a secondary role for protection against personnel absence. Additionally ARI can scale resources as required. Additional trained resources can be added to any of the above teams with a 2 month lead time.
The Production Support Group is responsible for the deployment and operation of TLD registries.
The group consists of:
– Production Support Manager (also the ISO)
– Service Desk:
 – 1 Level 1 Support Team Lead
 – 8 Customer Support Representatives (Level 1 support)
 – 1 Level 2 Support Team Lead
 – 4 Registry Specialists (Level 2 support)
– Operations (Level 3 support):
 – 1 Operations Team Lead
 – 2 Systems Administrators
 – 2 Database Administrators
 – 2 Network Engineers
– Implementation:
 – 1 Project Manager
 – 2 Systems Administrators
 – 1 Database Administrators
 – 1 Network Engineers
ARI employs a rigorous hiring process and screening (Police background checks for technical staff and Australian Federal Government ‘Protected’ level security clearances for registry operations staff).