ICANN New gTLD Application

ADAC intends to organize the registry operation for the .ADAC in such a manner that it will minimize the likelihood of having multiple applications or registration requests for a particular domain name. 
According to ADAC, this can be achieved in any of the following ways, which likely needs to be further refined following ICANN’s award and delegation of the .ADAC gTLD to the Applicant:

1) From the Applicant’s perspective, .ADAC may bring a high degree of recognition and specialization to the currently existing name space. Where in most cases the specific connotation that has been initially given to the gTLDs (or even ccTLDs) has disappeared, the .ADAC top-level domain is currently intended to be unambiguous as regards: 
a) the identity of ADAC as the Registry Operator;
b) the source of the content, products and services offered under the .ADAC gTLD;
c) the affiliation between the Registry Operator and the TLD; and
d) in term, and at the discretion of ADAC, the affiliation between the Registry Operator and any third party that is authorized by ADAC to register and⁄or use one or more domain name registrations in the .ADAC TLD.

2) As mentioned in the vision and mission statement above, the key reasons why Applicant is applying for .ADAC include but are not limited to:
a) Securing and protecting the ADAC brand as a generic top-level domain:  The Applicant holds various registered trademarks for ADAC and its derivations. An important reason for which ADAC submits this application for the .ADAC gTLD is that it wants to prevent third parties from securing the TLD that is identical to ADAC’s highly distinctive and reputable brand;
b) Reflecting the Applicant’s key brand ADAC at the top-level of the DNS’ hierarchy;
c) Safety and security for ADAC members and internet users:  ADAC has always been championing consumer protection and its members expect that it acts in a secure and transparent way, both off-line and online;
d) Ensuring a clear-cut communications channel within the ADAC community; 
e) Providing a platform for the community of the Applicant’s member organizations and about 18 million individual members.

3) The Applicant intends to implement the following policies and procedures with respect to the registration of domain names in the .ADAC top-level domain:
a) reservation and registration of domain names in the name of ADAC. It is likely that this will be the scenario that ADAC will put in place during the first months or even years of operation of the .ADAC gTLD.
These names may include, but are not limited to:
I) descriptive names, referring to the services and products offered by the Applicant to its members;
II) descriptive names, referring to the regional and local clubs of the Applicant and to organizations associated with the Applicant;
III) potentially also names relating to other Stakeholders, to be determined by ADAC  following ICANN’s award and delegation of the .ADAC gTLD to the Applicant;
b) launch of the TLD: if and when implemented by the Registry Operator, this is likely going to be a gradual process, whereby selected third parties that meet certain criteria, which ADAC will be entitled to set at its own discretion, may register domain names in the .ADAC gTLD. These processes will include a sunrise clause allowing physical persons, organizations and entities that meet the eligibility requirements determined by ADAC at that point in time to choose and, where allowed by ADAC, to register the domain names that are identical to their trademarks. After that sunrise period, the general registration procedures and policies will apply (including, as determined by ADAC at its sole discretion, eligibility restrictions).
Depending on the terms and conditions in force at the time of launch of the TLD, these domain names may or may not be registered in the name of the entity wishing to register a domain name or in the name of the Registry Operator of the TLD (i.e., ADAC). In any case, ADAC reserves the right to impose additional and other restrictions from time to time at its sole discretion;

4) Given the fact that the Applicant is a company that is established in Germany, it is subject to national privacy and data protection rules and practices. In particular, given the fact that the German and European data protection authorities have issued strict guidelines, ADAC will at all times be obliged to carefully consider and, where applicable, implement these policies, and this prior to and during the operation of the . ADAC gTLD.

5) The ADAC has been established on 24 May 1903 in Stuttgart in the form of a registered association (“eingetragener Verein”). In the beginning, its main focus lie on motorcyclists but – due to the rapid growth in members and the evolving technical environment – quite quickly evolved to encompass all motorists. After 10 years of operation, ADAC already had some 20.000 members and became the largest automobile club in Germany. Dissolved for political reasons by order of the authorities before the Second World War, the ADAC had to be – from a legal point of view – re-established in 1946, but it always carried on its tradition and has now a successful history of more than 100 years of operation. The success and acceptance of ADAC is particularly highlighted by the steadily growing number of its members. Nowadays, ADAC is broadly regarded in Germany as an organization one can trustfully rely on in case of a breakdown, accident or emergency while traveling. In addition, ADAC has earned a reputation as an advocate of consumer protection issues. More than 18 million members rely on and trust ADAC, making it by far the largest automobile club in Europe.

6) At this stage, ADAC has not developed concrete and tangible plans in order to move its online activities from its many active domain names. However, ADAC has different ways in order to make existing and future Stakeholders as well as visitors aware of the (gradual) development of a new online environment under the .ADAC TLD, including but not limited to:
a) Its own membership magazine which is distributed in over 13 million copies a month;
b) By way of advertisements in newspapers, magazines, tv ,radio, online;
c) Official press releases of ADAC and other activities of its PR department;
d) Direct and indirect marketing and branding initiatives;
e) Internet advertising campaigns, including paid search, pay-per-click advertising, etc.;
f) Having Internet traffic to the its various active domain names resolving into domain names registered in the .ADAC TLD, which builds awareness with Internet users that the .ADAC gTLD exists;
g) Email marketing campaigns;
h) etc.

In line with ADAC’s mission and purpose for the .ADAC gTLD, it is important for ADAC to safeguard and protect its ADAC trademark at the top level of the DNS’ hierarchy. ADAC has built up a reputation as a leading and independent provider servicing the needs of its members and wants to avoid the unduly exploitation of that reputation in the domain name space by third parties. The protection mechanisms ADAC intends to put in place do therefore not only extend to the actual registration, delegation and use of the TLD, but also to the domain names that are registered therein, and how these domain names are used.
Considering the fact that the actual award and delegation of the .ADAC gTLD to ADAC is subject to the successful evaluation of our application, we have defined at a high level: 
1)	the types of domain names that will be registered;
2)	who will be entitled to select which domain names will be registered
3)	who will be entitled to register such domain names;
4)	who will be entitled to use such domain names, and;
5)	which types of use will be allowed or recommended.
More information in this respect can be found in our answer to question 20.
As we believe that the development and implementation of one or more business cases could likely take a couple of months or even years, we have only focused on a number of high-level characteristics of our plans in relation to the operation of the .ADAC gTLD.
By all means, it is in ADAC’s vested interest to, on the one hand, make the most of this initiative, promote the interests of its members (be it legal entities or individuals), and mitigate risks for its brand, the reputation of ADAC and for its members, whilst also reducing the (social) costs for others.
In this context, we will devise policies that encompass and comprise the following features:
At least during the initial months or even years following the delegation of the .ADAC gTLD to the Applicant, this extension is likely going to be a so-called “single registrant TLD” as contemplated by ICANN in Article 4.5 of the template Registry Operator Agreement (“Transition of Registry upon Termination of Agreement”). For the avoidance of doubt, a “single registrant TLD” is a TLD where “(i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for its own exclusive use, and (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator.”
Therefore, parties who are not ADAC or – insofar and to the extent ADAC deems appropriate – a Stakeholder will not be entitled to register domain names in the .ADAC gTLD. 
ADAC believes this to be in line with two of the main elements in its vision and mission statement, namely:
1)	Protecting and safeguarding the ADAC brand and its reputation, by keeping full control over the entire operation of the .ADAC registry and every domain name registered therein; and
2)	Guaranteeing to ADAC’s Stakeholders who are interacting with ADAC and between each other by using domain name registrations in .ADAC that they are in fact interacting with the members of the 
ADAC community or, as the case may be, with a third party authorized by that community.

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

However, even if only ADAC (and, as the case may be, ADAC Stakeholders) will be entitled to register domain names, this does not exclude the hypothesis that disputes may arise with one or more third parties as regards domain names that are registered in the .ADAC gTLD.
In order to avoid these risks, ADAC intends to implement the following policies and processes: 

First, the domain names to be registered by ADAC and, as the case may be, its Stakeholders, will likely be limited to the following:
1)	registered trademarks of ADAC;
2)	names of the regional and local clubs of ADAC;
3)	names of the individual members of ADAC;
4)	names of departments within ADAC;
5)	names of foundations and social initiatives supported by ADAC;
6)	names of events (e.g. motorsports events) organized by ADAC;
7)	names of directors and officers of the Applicant and its subsidiaries, including its employees;
8)	names of subsidiaries;
9)	names of foundations and sponsorships established or supported by the Applicant; 
10)	names of third parties who provide services on behalf of the Applicant to its members and third parties who offer products and services on favorable terms to the Applicant’s members;
11)	names of co-operation and business partners;
12)	etc.

Furthermore, ADAC envisages registering a fair number of generic words that are directly or indirectly related to the services and products offered to and the activities organized by the various members of ADAC.
Prior to effectively registering such domain names in the .ADAC gTLD, ADAC will require its legal and intellectual property department to review the list of these domain names on a regular basis in order to satisfy itself that they will not infringe the rights of third parties.

In any case, ADAC will claim to have a legitimate interest in these domain names, as they are merely descriptive of the activities, products or services of ADAC offered to its members. So even if one or more of these domain names would be protected by a registered trademark, held by a third party, it is likely that a claim under the Uniform Dispute Resolution Policy or Uniform Rapid Suspension policy will fail.
As regards the names referred to in Specification 5 to the template Registry Operator Agreement, ADAC will follow the processes and procedures established by ICANN and the Governmental Advisory Committee.
If ADAC would determine, at its sole discretion, that it will gradually allow certain categories of Stakeholders to register domain names in the .ADAC gTLD in their own name, ADAC will devise policies to that effect.
However, ADAC will at all times be entitled to restrict, limit or expand:
1)	the category or categories of Stakeholders who will be entitled to register one or more domain names in the .ADAC gTLD, including their criteria for qualification, however in any case excluding 
Stakeholders who are not a member of ADAC or do not have a sufficient link to the ADAC community;
2)	the choice of domain name(s) registered in the .ADAC gTLD by and per such eligible Stakeholder (category);
3)	the use made by an and per eligible Stakeholder of a domain name registered in the .ADAC gTLD;
4)	the transfer of domain names registered in .ADAC;
5)	etc.

ADAC shall reserve the right to subject the registration or use of a domain name to internal approval processes and procedures, at each and every step of the domain name life cycle.
Given the fact that ADAC may release such available domain names post launch in a highly controlled manner, this also reduces the likelihood that two or more applicants qualify for the registration of the same domain name in the .ADAC top-level domain.

As a method of last resort, and subject to the actual domain name registration policy adopted by the Applicant and in force at the time of registration, domain names will be allocated on a first-come, first-served basis.

In any event, ADAC reserves the right to change or restrict any policies, procedures and practices at any point in time if it is of the opinion that there would be a risk that the reputation of the ADAC brand would be damaged.

The Applicant intends to make the .ADAC top-level domain available to qualifying domain name registrants at no cost to them; if the Applicant ⁄ Registry Operator would be required to charge a fee for the registration of domain names under the .ADAC TLD, the fee will be set at a cost-recovery or arm’s length basis, to be determined at that time by the Registry. For Stakeholders who offer products or services on favorable terms to the ADAC members, licensing models might also be introduced. 

If ADAC will be required to or would decide to increase the fees for the registration of domain names, such increases will keep pace with the cost-recovery or arm’s length character referred to above.

1) The Applicant is a not for-profit organization whose main purpose – as laid down in its statutes – is to represent and promote the interests of motorists, motorsports and tourism. Beyond the core services that ADAC traditionally provides to its members and in some cases also to non-members (road side assistance, air rescue, travel and traffic information and services) ADAC has extended the scope of its activities to a broad variety of products and services which mainly focus on one particular need of its members: mobility, be it in or outside Germany, be it for private or for professional purposes. It is the ADAC members – whose number currently amounts to about 18 million – and their needs that the Applicant is committed to serve since more than 100 years.
More information with respect to the Applicant can be found at its website: http:⁄⁄www.adac.de.
2) The Applicant is incorporated as a registered association (eingetragener Verein) under German law and as such has to comply with certain statutory requirements under German law, inter alia:
a) it must be of lasting, non-transient nature;
b) membership must be voluntary;
c) it has to establish a management board;
d) it has to pursue a not-for-profit purpose.
Within the boundaries of these statutory requirements, ADAC has established certain membership categories and an organizational and governance structure which can be briefly described as follows;
a) Membership categories:
I) Ordinary membership: eligible for ordinary membership is someone who possesses a motor vehicle or is interested in motor traffic. Ordinary members are obliged to pay an annual membership fee and entitled to benefit from certain services and products offered by ADAC. The membership relation itself is established with the regional club of the Applicant competent for the main residence of the (prospective) member.
II) Corporate membership: eligible for corporate membership are legal entities and certain associations.
III) Extraordinary and honorary membership.
Considering this, the membership of ADAC is clearly delineated.
b) Organizational structure: the ADAC consists of the following three entities
I) Regional clubs: ADAC consists of 18 regional clubs, which are independent legal entities covering a certain geographic area in Germany. In order to be affiliated with ADAC, each regional club is under the duty to accept and incorporate in its statutes certain minimum provisions which have previously been laid down by ADAC. The regional clubs appoint in their general assembly meetings those of their members who participate with voting right in the general assembly of the Applicant.
II) Local clubs: Within a regional club, a minimum of 30 ordinary ADAC members can decide to establish a local club. The local clubs are independent legal entities and have to be approved by the competent regional club and by ADAC itself. In order to be affiliated with the competent regional club and with ADAC, each local club is under the duty to accept and incorporate in its statutes certain minimum provisions that have previously been laid down by ADAC.
III) The umbrella entity “ADAC e.V.”, comprising the not-for-profit ADAC e.V. and the subsidiaries which pursue some form of economic activities to the benefit of the ADAC community;
c) Governance structure:
I) General assembly: consists of the representatives delegated by the regional clubs and of the members of the administrative board and the management board. The general assembly appoints inter alia the management board and is the highest organ of ADAC.
II) Administrative board: consists of the members of the management board and of the chairmen of the regional clubs. The administrative board lays down the minimum provisions that regional and local clubs affiliated with ADAC have to incorporate into their statutes and performs additional tasks as provided for in the ADAC statutes.
III) Management board: appointed by the general assembly, represents and is in charge of the general management of ADAC.
Both the organizational and the governance structure of the Applicant demonstrate that it is a clearly organized organization.
3) The ADAC has been established on 24 May 1903 in Stuttgart in the form of a registered association (eingetragener Verein). In the beginning, its main focus lie on motorcyclists but quite quickly evolved to encompass all motorists. After 10 years of operation, ADAC already had some 20.000 members and became the largest automobile club in Germany. Dissolved for political reasons by order of the authorities before the Second World War, the ADAC had to be legally re-established in 1946, but it always carried on its tradition and has now a successful history of more than 100 years of operation. The success and acceptance of ADAC is particularly highlighted by the steadily growing number of its members. Nowadays, ADAC is broadly regarded in Germany as an organization one can trustfully rely on in case of a breakdown, accident or emergency while traveling. In addition, ADAC has earned a reputation as an advocate of consumer protection issues. More than 18 million members rely on and trust ADAC, making it by far the largest automobile club in Europe.
Considering the above, the Applicant clearly is, or at least represents, the interests of a pre-existing community that has originated in 1903.
The focus of the Applicant has always been on its members and their needs in connection with mobility. The Applicant’s most prominent services and products encompass the following:
a) roadside assistance
b) air rescue
c) traffic information
d) travel information and services
e) advocacy of the interests of motorists etc.
f) legal advice with regard to various topics related to motor vehicles, tourism and travel
g) general advice to members with regard to any kind of mobility related issues (testing, maintenance and purchase of motor vehicles, tourism⁄travel, consumer protection etc.)
h) advocacy of the interests of motorists
i) rebate programs for ADAC members (“Show your Card”)
j) various products and services offered by ADAC subsidiaries (books, insurances, financial products, car rental, road safety training etc.).
In addition, the Applicant organizes motorsports events (for automobiles, go-karts, motorbikes, vintage cars etc.), publishes a monthly magazine for its members and founded various trusts which support the victims of road traffic accidents, engage in road safety education and sponsor talented racing driver. Finally, various corporations associated with the Applicant and its local clubs offer a broad variety of activities for vintage car aficionados and owners of a certain make of car, e.g. rallies, region tours and visits of museums in- and outside Germany. It would be very difficult to provide an exhausting list of activities that the Applicant and its members and member organizations have offered in the decades since the establishment of the Applicant and that they still offer.
All these activities as well as the membership card issued by the Applicant, the members’ magazine published every month and the stickers with the ADAC logo which are usually affixed to the motor vehicles of the members create a sense of community between the ADAC members.
4) Currently, ADAC has some 18 million members, making it the largest automobile club in Europe, ranking worldwide second only to the American Automobile Association. ADAC has its roots in Germany, and its main focus of activities is still on Germany but it is open to members from all over the world and it also offers – by way of co-operation agreements with local automobile clubs – certain services outside Germany.
The size of this community is therefore considerable, and there are no current or future plans to wind down or terminate its activities. Quite to the contrary, the number of members is growing every year, and new products and services are being made available to ADAC members.

1) At least during the initial months or even years following the delegation of the .ADAC gTLD to the Applicant, this extension is likely going to be a so-called “single registrant TLD” as contemplated by ICANN in Article 4.5 of the template Registry Operator Agreement (“Transition of Registry upon Termination of Agreement”). For the avoidance of doubt, a “single registrant TLD” is a TLD where “(i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for its own exclusive use, and (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator.” 
At a later stage, in addition to ADAC, its Stakeholders (as defined in the reply to Question 18 above) will possibly be entitled to register domain names in .ADAC. On the other hand, ADAC intends to exclude those individuals and legal entities from the registration of domain names in the .ADAC TLD who are not a member of ADAC or do not have a sufficient link to the ADAC community.
In any event, ADAC reserves the right to change or restrict any policies, procedures and practices at any point in time if it is of the opinion that there would be a risk that the reputation of the ADAC brand would be damaged.
2) In line with the Applicant’s general objective to focus on activities which benefit its members, the Applicant expects that it will be the members of the ADAC community who will be the end-users of the .ADAC TLD. At this stage, the Applicant cannot predict with certainty all the types of uses which the .ADAC TLD will have, but ADAC will possibly use .ADAC
a) as a platform for the Applicant’s regional and local clubs, who could be given the chance to present themselves under a unique identifier on the Internet which clearly and unambiguously shows their affiliation with ADAC;
b) as a platform for secure and trusted communication with the ADAC members, clearly identifying the Applicant as the sender or, as the case may be, recipient of the communication;
c) as a platform for third parties, who, after being authorized by the Applicant, could be given the chance to offer services and products on favorable terms to ADAC members; 
d) as a platform for the social initiatives and trusts supported and established by the Applicant and its members;
e) as a means for the individual members to clearly demonstrate that they belong to the ADAC community, e.g. by way of providing them with a unique email address;
f) in general as a platform to present ADAC and its activities to the public in general as well as to individuals⁄legal entities who consider joining the ADAC community in particular;
g) etc.
3) The Applicant and some of its Stakeholders already provide a wide range of products, services and information which serve the benefit of its members, such as
a) roadside assistance
b) air rescue
c) traffic information
d) travel information and services
e) legal advice with regard to various topics related to motor vehicles, tourism and travel
f) general advice to members with regard to any kind of mobility related issue  (testing, maintenance and purchase of motor vehicles, tourism⁄travel , consumer protection, advocacy of the interests of motorists etc.).
g) rebate programs for ADAC members (“Show your Card”);
h) products and services offered by subsidiaries of the Applicant (books, insurances, financial products, car rental, road safety training etc.).
The Applicant will of course continue providing these and additional services and products to its members after the launch of the .ADAC TLD. 
4) The obligation to further the interests of its members is clearly laid down in the statutes of the Applicant.  The ADAC has been established on 24 May 1903 in Stuttgart in the form of a registered association (eingetragener Verein). In the beginning, its main focus lie on motorcyclists but – due to the rapid growth in members and the evolving technical environment – quite quickly evolved to encompass all motorists. After 10 years of operation, ADAC already had some 20.000 members and became the largest automobile club in Germany. Dissolved for political reasons by order of the authorities before the Second World War, the ADAC had to be – from a legal point of view – re-established in 1946, but it always carried on its tradition and has now a successful history of more than 100 years of operation. The success and acceptance of ADAC is particularly highlighted by the steadily growing number of its members. Nowadays, ADAC is broadly regarded in Germany as an organization one can trustfully rely on in case of a breakdown, accident or emergency while traveling. In addition, ADAC has earned a reputation as an advocate of consumer protection issues. More than 18 million members rely on and trust ADAC, making it by far the largest automobile club in Europe.
ADAC has therefore already shown for decades its willingness and ability to serve the ADAC community and will continue to do so.

1) At least during the initial months or even years following the delegation of the .ADAC gTLD to the Applicant, this extension is likely going to be a so-called “single registrant TLD” as contemplated by ICANN in Article 4.5 of the template Registry Operator Agreement (“Transition of Registry upon Termination of Agreement”). For the avoidance of doubt, a “single registrant TLD” is a TLD where “(i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for its own exclusive use, and (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator.” 
This will allow the Applicant to build awareness amongst its membership and the Internet community at large that the .ADAC gTLD exists, that the domain names registered under .ADAC and the content provided on the websites to which those domain names point are managed by ADAC.
At a later stage, in addition to ADAC, its Stakeholders will possibly be entitled to register domain names in .ADAC. That is to say, one of the main eligibility criteria will be that the interested party wishing to register a domain name in the .ADAC TLD is either a member of the Applicant or has a sufficiently close link to the ADAC community.
In any event, ADAC reserves the right to change or restrict any policies, procedures and practices at any point in time if it is of the opinion that there would be a risk that the reputation of the ADAC brand would be damaged.
2) The domain names to be registered by ADAC and, as the case may be at a later stage, its Stakeholders, will likely be limited to the following:
a) registered trademarks of ADAC;
b) names of the regional and local clubs of ADAC;
c) names of the individual members of ADAC;
d) names of departments within ADAC;
e) names of foundations and social initiatives supported by ADAC;
f) names of events (e.g. motorsports events) organized by ADAC;
g) names of directors and officers of the Applicant and its subsidiaries, including its employees;
h) names of subsidiaries;
i) names of foundations and sponsorships established or supported by the Applicant; 
j) names of third parties who provide services on behalf of the Applicant to its members and third parties who offer products and services on favorable terms to the Applicant’s members.;
k) names of co-operation and business partners;
l) etc.
Furthermore, ADAC envisages registering a fair number of generic words that are directly or indirectly related to the services and products offered to and the activities organized by the various members of ADAC.
In addition to that, the Applicant will likely require that second-level names meet certain technical and syntax requirements such as that 
a) the A-label will have to consist exclusively of the letters A-Z (case insensitive, however including special characters that are part of the German alphabet, such as e.g. “ä” and “ö”), the numbers 0-9 and the hyphen (“-“), subject to the restrictions set out below;
b) the domain name cannot begin or end with a hyphen (“-“);
c) underlined characters will not be allowed;
d) the domain name cannot exceed 63 characters (excluding the TLD);
e) the domain name will have to have a minimum length of 1 character.
The Applicant will reserve the right to itself to grant exemptions from some or even all of these requirements. 
Moreover, the Applicant will possibly draw up a list of reserved names which will not be available for registration and also put possibly special provisions in place for geographic names (see reply to Question 22 below), The Applicant will however reserve the right to allocate to and register a domain name mentioned on the list of reserved names in the name of a party indicated by the Applicant.
3) The Applicant will likely require that the content and use made by a registrant of a second-level domain name in the .ADAC TLD clearly relates to the ADAC community, e.g. by way of
a) providing information on the activities of the Applicant, its regional or local clubs or a third party affiliated with the Applicant (e.g. vintage car clubs);
b) offering products and services to the members of the Applicant, some of which may be on favorable terms for its members;
c) etc.
The Applicant will in any case require that all content and use offered under the .ADAC TLD complies with all applicable laws, including, but not limited to, trademark laws, criminal laws, data protection laws etc. To that end, ADAC will likely require applicants for a second-level domain name registration to warrant that
a) to their knowledge, the registration of the domain name will not infringe upon or otherwise violate the rights of any third party; 
b) the applicant is not submitting the domain name registration request and, upon registration, will not use the domain name for an unlawful purpose, contrary to public policy or morality, for offensive purposes, to mislead the public and⁄or contrary to good and fair business practices; and 
c) it will not knowingly use the domain name in violation of any applicable laws or regulations, including third party interests; and
d) it will keep the WHOIS information related to the domain name accurate and up-to-date at all times, both with its accredited registrar and ADAC.
ADAC reserves the right to change or restrict any policies, procedures and practices at any point in time if it is of the opinion that there would be a risk that the reputation of the ADAC brand would be damaged by the content or use made by a registrant of a second-level domain name in the .ADAC TLD.
4) Prior to the registration of a domain name in .ADAC, ADAC will require its legal and intellectual property department to review the list of these domain names on a regular basis in order to satisfy itself that they will not infringe the rights of third parties. In addition, ADAC might install a complaints point of contact who can be addressed if a third party deems its rights being violated by a second-level domain name in .ADAC. This complaints point of contact will be installed within the organization of the Applicant and will conduct an investigation of the complaint, if need be in cooperation with external legal advisers. Since the Applicant already offers diverse content under different domain names it has considerable experience in monitoring and ensuring compliance with the applicable laws. The Applicant will be able to leverage on this considerable experience but is committed to invest additional resources should the operation of .ADAC require so.
Furthermore, any party will likely be entitled to request the complaints point of contact for further clarification or information with respect to a second-level domain name registration prior to or following the procedures which will be published on .ADAC. The complaints point of contact may mediate between the complainant and the (prospective) registrant and will likely have the right and the powers to suspend, cancel or delete an application for or a registered second-level domain name. No fees will likely be charged by ADAC or the complaints point of contact in connection with any such mediation or remedy, which will likely be the only remedy offered by ADAC to the complainant.
The Applicant’s domain name registration policies will contain clear rules and procedures with respect to:
a) verifying, on a regular ⁄ spot-check basis, that the registrant of a particular domain name still meets the eligibility requirements for being a .ADAC domain name registrant;
b) verifying on a regular ⁄ spot-check basis, that the content provided under .ADAC domain names is in line with the acceptable use policies and marketing guidelines issued by ADAC from time to time in relation websites operating under the .ADAC gTLD.
In case of complaints from third parties arising after the registration of a domain name that likely infringes the trademark rights of a third party, the registrant will be contractually obliged to 
a) conduct any such proceedings before an ICANN approved dispute resolution service provider in accordance with the UDRP, the URS, the Rules for UDRP and URS and any relevant supplemental rules, as made available on the relevant websites and⁄or the Rules for URS and any relevant supplemental rules, as made available on the relevant websites); and
b) to participate in good faith in any domain name dispute initiated by a third party complainant under the UDRP or URS against the registrant in compliance therewith and with the Rules for UDRP and⁄or URS.

1. Overview
The internet today, with 22 generic top-level domain names and approximately 270 country code TLDs, is about to change. As the domain name space will be opened to organizations applying for gTLDs associated with particular interests and businesses sectors, this will help organizations and communities enhance branding, community building, security, and user interaction. Hundreds of new extensions may be introduced and each applicant will have to look for a stable and secure Registry system and technical provider. The Registry Operator has therefore chosen to outsource the technical back-end operations for the domain name Registry to OpenRegistry (the Registry Service Provider). OpenRegistry combines a steady track record with modular software to help applicants take advantage of this opportunity.
When it is stated that the Registry service Provider will perform certain services or comply with certain standards and processes, the Registry Service Provider will do this in the name and on behalf of the Applicant, who itself is committed to comply with these standards and processes towards ICANN under the Registry Agreement and the terms and conditions of the new gTLD program. Unless it is expressly stated otherwise, all services described in this question will be provided by the Registry Service Provider in the name and on behalf of the Applicant, who will monitor the Registry Service Provider’s compliance with its contractual terms and the requirements laid down by ICANN on a regular basis.

1.1. Registry Service Provider
This document sets out the range of services that OpenRegistry offers to its customers in compliance with ICANN’s new top level domain application process. The services are fully compliant with ICANN’s requirements regarding the deployment and management of a gTLD Registry System.
OpenRegistry’s multilingual staff have over 20 years of combined experience in developing and managing sophisticated solutions for domain name Registrars, domain name Registrants (in particular brand owners) and Registry Operators, as well as being involved in the design of policies for and managing registrar relationships with several ccTLDs.
All members of the team (including outsourced personnel) have been specifically trained on the Registry Platform and have an extensive knowledge and hands-on know-how about the DNS. OpenRegistry has offices in Luxembourg and Belgium.
OpenRegistry was founded by the three key leaders involved in the successful creation and operation of the .be and .eu Registries, which combined currently represent over four million domain names. The OpenRegistry team has 20 years of experience in developing and managing sophisticated solutions for Registrars and Registry Operators. The OpenRegistry system draws on the best features of the .be and .eu systems, combined with new technology that has been introduced, which results in best practice system protocols and software design.
OpenRegistry offers from a simple, totally outsourced product to a licensed version of the Registry software for clients who wish to manage their own infrastructure. In each and every case, the system meets and even exceeds ICANN’s Registry contract requirements. The software provides the flexibility to offer options to Registry Operators that are in line with its own specific operational and technical circumstances.
(View attachment for Figure 1: Registry Software Capabilities)
There are three key feature groups which address the ICANN evaluation process and which meet and even exceed ICANN’s mission and core values to protect the stability of the global Internet. These are the technical features, financial features and third party modules that are detailed in the next sections.
(View attachment for Figure 2: Registry Software Features Overview)

1.2. Stability & Security
The Registry Platform that will be deployed for the applied-for gTLD, which meets and even exceeds the technical requirements set by ICANN, combined with the team’s experience in running ccTLD domain extensions, provide a solid basis to assist the Applicant to meet its commitments to ICANN. As a Registry Service Provider, OpenRegistry is an operationally secure company with highly skilled staff and appropriate premises for running Registry Services conform to the ISO27001 standard.
DNS services are monitored at all times and external high quality any-cast providers are added in the mix to deliver excellent and premium class nameserver infrastructure all over the world.
The main features of the Registry Platform include a complete and extendible set of functionalities that can be controlled by the administrator. Some of the more profound features include support for IPv4, IPv6 and DNSSEC. The Registry Platform relies on standards-based software, carrier-grade hardware and protocol compliant interfaces. These include enabling dynamic zone file updates for immediate use after registration, escrow services and advanced reporting. Extensible Provisioning Protocol (EPP) transactions are only accepted from pre-registered IP addresses and all transactions, whether web or EPP are protected by Secure Socket Layer (SSL). All transactions are monitored, traced and logged.
The Registry Service Provider’s staff are industry-trained (in Java, SQL, Linux) university-certified professionals each with over a decade of experience in building and managing network infrastructure (CISCO, Juniper,… ) using quality hardware appropriate for the array of customers.
Diverse audit trails of all activities across software, hardware, staff movement, building access to ensure the security of our systems, are provided. A penalty system ensures Registrars cannot flood the Registry Platform with invalid requests, which would potentially degrade the system’s performance. New connections (SYN packets) are limited on the domain name Registry’s edge routers to minimize the impact of Denial of Service (DOS) and Distributed Denial of Service (DDOS) attacks. The system is further protected with a redundant intrusion detection⁄intrusion prevention system to exercise deep packet inspection and block risks on SQL-injection and cross site scripting.
OpenRegistry offers a range of services to increase the security of communications between the Registry Operator and Registrars. By default, the communication channel is encrypted using Secure Socket Layer (SSL)⁄Transport Security Layer (TLS). On top of encryption, the following options are available:
1) User login with passwords and granular authorization;
2) Trade and transfer control to prevent unintentional transfers;
3) Limited access per second to avoid data harvesting;
4) Monitored update allows ownership data to be changed only after manual checks;
5) Temporary take-over by the Registry Operator in case of Registrar bankruptcy;
6) Domain lock avoids malicious transfer or trades;
7) On-hold status can be set pending an Alternative Dispute Resolution (ADR) case;
8) Domain Name Monitoring module exposes typo-squatters by listing similar domain names;
9) The Registrant extranet puts Registrants in charge of their domain names.
The Registry Platform provides a minimum of two anycast addresses, nodes in 52 locations around the world and a capacity of over 500 billion queries a day with a resolution rate of under one millisecond. Each node is set up in a redundant configuration so that a hardware failure on one machine does not prevent the node from responding to queries.
The Registry’s primary server location is located in Belgium, in a secure, state-of-the-art facility. Special care has been taken to provide several physical layers of security. The Registry database and application servers will be hosted there, with a mirror site in Luxembourg. The Registry Platform is connected using multiple Internet Service Providers (ISPs), all of them Tier 1 providers.
The applications run on a blade infrastructure, allowing for immediate recovery in the case of failure of any one element and providing easy scalability. The setup provides micro-cloud functionality that allows for easy scalability and multiple layers of redundancy. The local backup (warm standby) server is kept current by a stream of write-ahead log records, so it can take over as the master server with minimal delay. Name servers are distributed over the world for load balancing and robustness. External parties provide anycast functionality. The unicast nodes provided are set up in a redundant configuration so that a hardware failure on one machine does not prevent the node from responding to queries.
All the Registry data are stored on a cluster of database servers, both on the primary and on the mirror site. These databases are synchronized permanently. If the load on the production database is deemed too high to deliver excellent quality service, read-only copies are put in place for read-only service, such as WHOIS and Data Escrow, to off-load traffic from the main database. A special delayed recovery database is available on the primary site to be able to recover quickly from data corruption should it have spread to all on-line database servers.
(View attachment for Figure 3: Registry Services interfacing the Registry Database)
The Registry Platform is feature rich with a multitude of parameters that can be set to suit the applicant’s requirements. At system level software modules and functionalities can be switched on and off by the system administrator.
The Registry Platform contains all functionality required by ICANN for a TLD to operate efficiently through two main interfaces or more if necessary. The XML based EPP interface provides excellent means for Registrars who want to offer their customers a fully automated interface. A web interface provides extra functions that are difficult to automate next to a set of commands that are fully compatible with EPP.
The audit trail ensures that from day one every single activity in the system is logged and copied, including all associated data. This allows for going back in time and examining the situation both before and after a transaction took place. Journaling is built straight in the database, so it is hassle free for programmers and works with all programming languages.
The full and flexible audit log eliminates huge log files or endless searching. The audit log can be searched using filters and detailed search criteria, so the requested is found fast and efficiently.
The system was created for the current domain name Registry-Registrar-Registrant model but could easily accommodate a direct Registry-Registrant relationship, for which a web interface is particularly useful.

2. Technical Features

2.1. WHOIS and Domain Availability Service (DAS)
End users (Registrants) are expected to have access to the contact details of a domain name holder. The WHOIS module complies with the ICANN standards, but offers optional flexibility with two different accesses : the WHOIS giving the full details (if allowed) of the domain name holder, and DAS (Domain Availability Service) which only shows whether the domain name is available or not. WHOIS data is fully configurable to meet existing or future data protection requirements, with each field able to be switched on or off. It can be accessed via both a web interface (CAPTCHA protected, where the user needs to enter a verification code to avoid machine-generated queries) or via port 43.
Open Registries may find other uses for their WHOIS data to benefit both the Registry Operator and Registrants, such as a search capable WHOIS on the domain name database to find domain names or registrants in a particular industry or area. Profiles can be set up to determine which information is displayed.
WHOIS and DAS functionalities are described in detail in response to question 26.

2.2. DNSSEC Enabled
In compliance with ICANN requirements, the applied-for TLD will be DNSSEC enabled from day one. Additionally, a DNSSEC solution is offered for the Registrars that they can implement with minimum disruption to their own systems. The implementation of DNSSec is described in detail in response to question 43.

2.3. DNS Service
The DNS infrastructure consists of an own set of redundant unicast nameservers running various flavors of operating systems and DNS software, and a set of high quality anycast nameserver providers. These services are provided by machines distributed all over the world over the IPv4 and IPv6 network and using DNSSEC.
1) Real-time DNS updates compliant with RFC 2136
2) DNS Services implemented using ISC BIND, compliant with RFC 1034, RFC 1035, RFC 1101, RFC 2181, RFC 2182, and RFC 3007
A detailed description of the DNS service is provided in the response to question 35.

2.4. Tailored Contact Types
When a domain name is registered, the Registrant must provide the Registrar of the domain name with valid and up-to-date contact information. In theory, by looking up the domain name in any public WHOIS database, anyone is supposed to be able to view this registration information, and thus contact the person or company that owns it (Registrant or Licensee). The Registry Platform allows specifying tailored contact types to suit the Registry Operator’s need. Each contact type can contain the default set of contact data or fields specified.

2.5. Dynamic Zone Files
The Registry Platform provides a dynamic zone file update, ensuring that, when a domain name is registered, it is available for use immediately.

2.6. Internationalized Domain Name (IDN) Compatible
The Registry Platform is IDN compatible and does not rely on the domain name registrar to convert natural script into punycode. The Registrar simply needs to enter the required information in natural language and the Registry Platform will do the rest. This applies for both EPP and web interfaces.
A detailed description of the implementation of IDN is provided in the response to question 44.

2.7. Nameserver Groups
The Registry Platform can create nameserver groups. A nameserver group contains a list of nameservers that can be linked to a domain name. This can be used instead of individual nameservers on a domain name. When one nameserver is replaced by another, nameserver groups deal with this change in one update that is then propagated to all domain names linked to that group. When using individual name-servers, all domain names using the old name servers need to be updated.

2.8. Extranet
The extranet option allows the Registrant to access and, when permitted, modify his data at the Registry Operator level. It can also be used by the Registrant to approve trade or transfer of a domain name. If needed, the Registrant can be given access to the extranet to switch on some levels of control. For instance, the Registrant can ask to be informed of any change of data made by the Registrar. Similarly, the Registrant can choose to be informed by e-mail when his domain name is scheduled for deletion. In this case, the modification or deletion can only be executed after confirmation from the Registrant.

2.9. Sunrise
The Registry Platform accommodates multiple types of Sunrise arrangements, including first-come-first-served validations or a defined Sunrise window that sends all applications for validation. Rules for the sunrise period can be set such as the type and location of applicant and type, or the dates and geographical coverage of prior IP rights.

2.10. Validation Management
The Registry Platform can provide a direct link to any Trademark Clearinghouse that ICANN may choose, thus encouraging more brand owners to participate in the Sunrise. Validation options include selection of names which are excluded from registration, which are Premium names, and include an auction process for competing applications.

2.11. SRS Registration and Flexible Permissions
SRS is short for Shared Registry System. The Registry Platform offers, besides the access through EPP required by ICANN, the capability to register domain names via the web. The Registry Platform includes a module that allows for flexible permissions for all users. This is very useful to give different permissions to different types of users for different sets of actions, for example to define what certain Registrars or Resellers can or cannot do. These permissions can be applied to different transactions in the system, allowing staying in total control of the TLD.

2.12. Registrar Interface
1) Fully documented client Application Programming Interface (API)
2) Web interface to allow Registrars full control of names under their management
3) Easy to use and fully compatible with Extensible Provisioning Protocol (EPP)
4) Extra modules provide feature rich experience

2.13. Extensible Provisioning Protocol (EPP)
1) Full EPP compliance with RFC 3730 and RFC 4930
2) Supports standard EPP object mappings for an Internet Domain Name Registry RFC 4931, RFC 4932, and RFC 4933
3) Multi-layer authentication
4) Includes support for implementing EPP extensions
5) Highly configured EPP Service to ensure that Regulator and Registry Operator Policy is adhered to with minimal intervention
6) Works with any RFC compliant EPP server
A detailed description of the implementation of EPP is provided in response to question 25.

2.14. Hidden Master Nameservers
The master nameserver, which interfaces directly with the Registry Database, provides all slave nameservers with the current registration and database information, but cannot be accessed by third party users. This provides optimal security and integrity for the Registry Database.

2.15. Variable Renewal Period
The Registry Platform allows for configuration of the renewal period, with a maximum of 10 years. By default, domain names are renewed every year, but this could be set to any other period, within the limits imposed by ICANN.

2.16. Length Limitations
The Registry Platform allows for the definition of criteria in terms of the length of the registered domain name. This feature can be used for example, to avoid the creation of two and three letter domain names within the TLD.

2.17. String Blocking
This feature allows for blocking of simple or complex ‘strings’ from being used in domain names. Examples include the name of competitors of the Registry Operator for a brand TLD, parts of that name, or foul language.

2.18. Automatic Transfer and Trade Handling

The Registry Platform is capable of automatically handling all transfers and trades using a proven automated process of approval by the registrants. When a transfer is initiated, the current owner receives an e-mail requesting approval. In case of a trade, the new owner also receives an e-mail. Only when all parties involved have electronically given their approval is the transfer or trade scheduled for automatic execution.

2.19. Registrar Dashboard
The Registrar has a dashboard to verify the current status of the registrar account. This includes a number of statistics on domain names in portfolio, domain names recently registered, transferred in and out, etc. These statistics are also provided over a longer period of time, allowing the registrar to conduct statistical analysis of the portfolio. The interface also provides an overview of transaction failures and the reason why, if applicable. It also shows a detailed financial status.

2.20. Registrar Export
The Registrar web provides a separate page where the Registrar has bulk access to the entire portfolio of domain names, contacts and all other useful information stored in the database linked to the Registrar’s account. The data is available in various formats including XLS, CVS and XML. This provides the Registrar with ample facility to verify portfolio and import data into and verify data against any external system used by the Registrar.

3. Financial Features

3.1. Pricing Model
The Registry Platform’s management module allows the Registry Operator to create pricing models as needed. Prices can be set for each type of operation and can have an associated validity period. Price changes can easily be implemented and put in the system with a specific starting date.

3.2. Pre-payment System
For each domain name Registrar, an account is provisioned in the Registry Platform. Every paying transaction reduces the account balance by the corresponding fee. When the account does not contain enough funds, the transaction will not finish successfully. This method eliminates the risk of bad debtors. Invoices are generated at the end of each month for the transactions executed and paid for in the previous period. This flexible system also allows for a post-payment application.

3.3. Credit Lines
While the pre-payment system does not allow a Registrar to execute paying transactions, such as registering a new domain name, a credit mechanism is available that allows the Registry Operator to give a Registrar a credit line for a specific period and a specific amount. During that period, the Registrar’s account may temporarily run negative for the specified amount.

3.4. Invoicing
The Registry Platform allows for both an automated as well as an explicit renewal. Both options occur at the end of the month in which the renewal is due. Payments must be made with the Registrar’s pre-payment accounts, although the Registry Operator can give a particular Registrar a credit line for a specific period. Monthly invoices, detailing all transactions that have occurred in the previous month, are generated by the Registry Platform.

3.5. Payments
The Registry Platform’s management module keeps track of all payments that have been entered into the system. Registrars can access their complete invoice and payment history via the web interface.

3.6. Early Warning System
The Registry Platform contains a system of threshold to prevent the Registrar’s account from going negative. When the prepay account drops below a certain threshold level, an email will be sent to the Registrar to inform him, thus allowing the Registrar to transfer sufficient funds into the account in time.

4. Third Party Modules

4.1. Alternative Dispute Resolution (ADR) Extranet
In the event that a dispute arises over a domain name, the status of the domain name in question needs to be blocked. This is required to prevent the current holder from changing crucial data. As timing is very important, the Registry Platform includes a simple interface for the Alternative Dispute Resolution (ADR) provider that allows placing the disputed name on hold or in use again according to the outcome of the deliberation. Furthermore, if a complaint is launched against a domain name, the Registry Operator can permit the ADR dispute resolution service provider to log in and suspend any transactions on the name until the process is complete. When the dispute is resolved, the ADR provider can either remove the suspension or force a transfer according to the applicable rules and procedures of the UDRP (Uniform Domain-Name Dispute Resolution Policy).

4.2. Extranet
If applicable, the extranet option allows the Registrant to access and, when permitted, modify his data at the Registry Operator level. It can also be used by the Registrant to approve his trade or transfer. If needed, the Registrant can be given access to the extranet to switch on some levels of control. As a first level, the Registrant can ask to be informed of any change of data made by the Registrar. Similarly, the Registrant can choose to be informed by email when his domain name is scheduled for deletion. If the Registrant chooses the second level of security, the modification or deletion can only be executed after confirmation from the Registrant.

4.3. Sunrise Process Management
The Registry Platform accommodates multiple types of Sunrise arrangements, including first-come-first-served validations or a defined Sunrise window that sends all applications for validation. Rules for the Sunrise period can be set, for example, the type and location of applicant and type, or the dates and geographical coverage of prior IP rights.

4.4. Validation Management
The Registry Platform can provide a direct link to any Trademark ClearingHouse that ICANN may choose to operate, thus encouraging more brand owners to participate in the Sunrise. Validation options include selection of names which are excluded from registration, which are Premium names, and include an auction process for competing applications. The Registry Platform is by default compliant with the Trademark Clearinghouse.

4.5. Escrow Module
The escrow module allows for an easy transfer of full and incremental backups to one of ICANNʹs accredited escrow providers. Reports of all exchanges are kept and combined in a monthly report. Emergency backup procedures and verification scripts can be added.
A detailed description of the data escrow is provided in the response to question 38.

1. Overview
The Shared Registration System (SRS) is a computer system for managing a domain name Registry, and allows for the registration, by authorized Registrars, of domain names and modification of information associated with that domain name on the Registry level.
The SRS has two matching subsystems: an Extensible Provisioning Protocol (EPP) server and a Registrar web interface.

2. High-Level SRS System Description

2.1. Infrastructure
The SRS platform consists of several services. These services provide the Registrar with access to the database. Registrarʹs access is limited to objects created and maintained by the Registrar. No other means than the SRS are provided to the Registrar to modify objects. The SRS system runs on a virtualized and strictly separated infrastructure to maintain consistency and security and provide for scalability and availability. For more information, reference is made to the relevant sections in question 31 (Technical Overview of the Proposed Registry), question 32 (System & Network Architecture) and Q33 (Database Capabilities).

2.2. Extensible Provisioning Protocol
As required by Specification 6 (section 1.2) and as detailed in the answer on Question 25 on the Extensible Provisioning Protocol (EPP), the Registry Operator will comply with the relevant existing RFCs. The Registry Operator will also, if applicable, implement the relevant RFCs published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in compliance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734.
Extensive testing will verify that the software performs according to the performance specifications as required by Specification 10 for EPP.
The response to question 25 provides full details on the EPP implementation.

2.2.1. Security
Access to the EPP server system is restricted in three ways:
1) Access control to the production EPP server is restricted by IP address filters;
2) SSL encryption is required for the communication channels between the Registrarʹs client system and the OT&E (Operation Test & Evaluation) and Production EPP servers;
3) Authentication by means of a user name and a strong password is required for session establishment.
The EPP server requires that all three mechanisms must be correctly adhered to before access is granted.
The IP addresses from which the Registrar wants to connect to the EPP server must be registered through the Registrar web interface (maximum 5 IP addresses per Registrar, subject to evaluation).

2.3. Registrar Web Interface
The Registry Operator will, in addition to the EPP server system, also run a Registrar web interface. This web interface can be used besides or instead of the EPP server interface to manage the registration and modifications of domain names and the information associated with those names.
The web interface has two parts: managing the objects in the domain name Registry database, and managing the Registrarʹs business account information.

2.3.1. Managing Objects in the domain name Registry Database
The management of the objects in the database via the web interface is based on the same software code as for the EPP server implementation. The different subparts of managing the objects in the database are: maintaining domain names, maintaining contacts and maintaining hosts.
1) Maintain Domain: The interface allows to easily find, check, query, add, update, renew, transfer or delete domain names from the Registrar account. As an extra feature, the history of the domain name can be explored (if the domain name resides in the Registrarʹs account).
2) Maintain Contact: The interface allows to easily find, check, query, add, update or delete contact information. Also the history of the contact can be listed (if the contact stays in the Registrarʹs account).
3) Maintain Host: The interface allows to simply find, check, query, add, update or delete host information from the Registrar account. Also the history of the host object can be viewed (if the host object is in the Registrarʹs account).

2.3.2. Managing the Registrar Account
The Registrar Profile page allows the Registrar to
1) View, add and update own contact information for administrative, technical, commercial and financial purposes;
2) Add and update the IP addresses required for access to the EPP server (see above);
3) Add and update the different email addresses of the Registrar where he can be reached by the Registry Operator for administrative, technical and financial purposes;
4) View hitpoints (attributed when the EPP client software behaves erratically), and resume the Registrar account (when hitpoints reach a defined threshold, the Registrar account is suspended temporarily).
The financial information pages reveals
1) Account balance overview;
2) Overview of invoices and payments, with details;
3) Overview of possible renewals in coming months.
The reports page provides customized reports on gained and lost domain names (via transfers), on nearly expired domain names and on the latest transactions (per object type and transaction type).
The export page offers downloads of full exports of contacts, domain names and hosts in different formats (CSV, XLS, XML), to allow the Registrar to consolidate and cross-check his own data.

2.3.3. Security
Access to the Registrar web interface is restricted in three ways:
1) HTTPS encryption is required for the communication between the Registrar and the OT&E and production Registrar web interfaces;
2) Authentication by means of a user name and password is required;
3) Extra passphrase authorization to confirm transactional commands (create⁄modify⁄delete).
All communication is encrypted and secured using the SSL⁄TLS protocol. The main idea of HTTPS is to create a secure channel over an insecure network. Adding a trusted and verified server certificate ensures reasonable protection from eavesdroppers and man-in-the-middle attacks.
Security is augmented by requiring an extra passphrase authorization to complete all transactional commands on the SRS system.

2.3.4. Redundancy & Scalability
The SRS system runs on a mini-cloud virtualizing all machine infrastructures needed (for further information on, for instance the number of servers, see question 32). Not only does this improve high-availability and scalability, it also allows for very fine grained access control improving security and mitigating network cross connections. The cloud can be distributed over the two sites allowing for a full hot-standby mirror site. Using network based traffic mirroring, resources are scaled and load balancing and fail-over are implemented.
The synchronization scheme for the Registry database, which contains all information used by the Shared Registration System, is described in full detail in the response to question 33 (Database Capabilities). The database is continuously synchronized.
Dynamic updates are implemented on the nameserver infrastructure. All changes to the database are immediately synchronized to the worldwide nameserver infrastructure, with an average delay of 10 seconds.

3. Resourcing Plan

3.1. Technical Resources

3.1.1. Network
The Registry Platform is based on a full redundant network setup, based on different technologies that together form a reliable setup. The network setup is greatly detailed in the answer on Question 32 on Network & System Architecture, and consists of:
1) Multi-homed network with own IP-range and Autonomous System number (AS) announce via Border Gate Protocol (BGP);
2) Redundant routers and firewalls;
3) Fully redundant internal network for interconnection between the Registry Services.
Network security measures include:
1) Traffic shaping (on SYN packets) on the routers to minimize impact of (Distributed) Denial Of Service attacks;
2) Stateful firewall to limit access to service ports only;
3) Limiting source IP addresses per Registrar to connect to EPP server system;
4) Network separation using VLAN (IEEE802.1q) technology to separate service and data plane;
5) Private firewall on every server.

3.1.2. Servers
The EPP server and the Registrar web interface are running on their own respective machines. Virtualization is used to make the service machines independent of the underlying hardware.

3.1.3. Interconnectivity with other Registry Services
The Shared Registration System (SRS) maintains the objects in the core database from a Registrarʹs perspective. All other Registry systems such as the WHOIS service, the data escrow system, the (dynamic) zone file generator,... all use the core database.
The Registry Operator implements a thick Registry model, and as such the full data are present in the core database. There is no need to synchronize the data from different source databases into the master database.
As detailed in the answer on Question 33 on Database Capabilities, the Registry Operator is using hot-standby database replication for redundancy and fail-over, and if the load on the system should require so, the WHOIS system can be off-loaded to another hot-standby read-only copy of the core database, which is near-synchronous with the main database.
Note that the network and system setup on the primary site is duplicated on a mirror site.
(View attachment for Figure 1: Interplay of Registry Services)
Other services such as the dynamic updates of the zone file, zone file generation and escrow use the database or a trigger mechanism to update the relevant resources when the Registrar updates objects in the database.
All changes to the database are tagged and linked to a transaction description also specifying the relevant time stamp, user and IP address. The information can be used to provide a full audit trail or to pinpoint invalid or illegal behavior.

3.2. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Shared Registration System is under the authority of the Software Developer, under control of the Operations Manager. The technical infrastructure is implemented and maintained by the Network & System Administrator.

1. Overview
The Registry Operator will comply with the latest version of the Extensible Provisioning Protocol (EPP). The domain name Registry is designed to strict EPP standards from the ground up. No proprietary EPP extensions have been developed. Upon selection of the Trademark Clearinghouse (TMCH) provider by ICANN, the EPP implementation will be complemented with an interface towards the TMCH, in line with community defined interface specifications.

2. EPP Registry – Registrar Model
The domain name Registry implementation features a ʺthickʺ model as represented by the rich object store managed by the centralized domain name Registry.
This object store can be managed by accredited Registrars via the EPP interface that will be using the interface protocol specified by the current EPP standard.
The EPP specification is broken up into an extensible object design with each of the primary objects given an individual but consistent interface that meet the base EPP framework as described below.

2.1. EPP Protocol Highlights

2.1.1.RFC 5730 - Extensible Provisioning Protocol (EPP)
This document describes the foundation upon which all the specific objects (Domain names, Hosts, Contacts) must adhere to in order to maintain a consistent interface. A standard domain name Registry specific extensible object management framework is also described in this document to handle any extra information need to satisfy policy or other agreements the domain name Registry may be required to sustain.

2.1.2.RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
This document describes an EPP mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.

2.1.3.RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping
This document describes an EPP mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.

2.1.4.RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
This document describes an EPP mapping for the provisioning and management of identifiers representing individuals or organizations (known as ʺcontactsʺ) stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts.

2.1.5.RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over Transmission Control Protocol (TCP)
This document dictates the TCP connection strategies to use. The implemented transport layer is conform to RFC 5734 and RFC 2246. RFC 5734 specifies the low level transport and allows for a typical TCP connection to be used to serve as a client-server communication channel. To secure the communication between client and server, an obligatory Transport Layer Security (TLS) layer is run on top of the TCP connection, as specified in RFC 2246.
A number of security settings no longer comply with current security needs and are prohibited in RFC 6176. The security algorithms that are allowed to communicate were chosen to be secure and compliant with a wide variety of implementations currently in use on most operating systems. These security algorithms include Advanced Encryption Standard (AES) and Triple Data Encryption Standard (TripleDES) for encryption and RSA for negotiation.

2.1.6.RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
This document describes the DNSSEC Extensions Mapping for EPP for the provisioning and management of DNS security extensions stored in a shared central repository. Specified in XML, the mapping defines EPP DNSSEC extensions to the command syntax and semantics as applied to domain names.

2.1.7.RFC 3915 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
This document describes the Registry Grace Period (RGP) Extensions Mapping for EPP for the management of domain names subject to “grace period” policies defined by ICANN. Specified in XML, the mapping defines EPP RGP extensions to the command syntax and semantics as applied to domains.

2.2. Supported Command Set
A full set of EPP commands is implemented, as specified in the above mentioned RFCs. The EPP service provides all commands specified in the RFCs 5730, 5731, 5732, 5733, 3915 and 5910 in a fully functional fashion. The commands are implemented conform the specifications set forth in the RFCs. The fully compliant XSD schema describing the XML layout which can be used to validate the XML command can be found in RFC 5730-5733, 3915 and 5910.
Please note that two extensions are implemented:
1) RFC 3915 is a specific extension to implement the “grace period” policies, both in providing extra information to the Registrar, as well as the possibility to restore a domain name from redemption.
2) RFC 5910 is a specific description to comply with the DNSSEC extension, as is required by the Applicant Guidebook, to manage the DNSSEC keys of the domain name.
The domain name Registry will provide the following command sets to support the Registry Service:
1) Greeting
2) Session management
3) Object Query
4) Object Transform
All commands from the EPP client to the EPP server run over an encrypted connection. The EPP client has to identify itself by using the predefined session management command 〈login〉 using unique and out-of-band communicated credentials.
The command sets are described in detail below.

2.2.1. Greeting
The EPP server will respond to a successful connection by returning a greeting to the client. The greeting response includes information such as:
1) The name of the server
2) The serverʹs current date and time in Coordinated Standard Time (UTC)
3) The features supported by this server, which may include:
a) One or more protocol versions supported by the server
b) One or more languages for the text response supported by the server
c) One or more 〈objURI〉 elements which identify the objects which the server is capable of managing
d) An optional 〈svcExtension〉 element that contains one or more 〈extURI〉 elements that contain namespace URIs representing object extensions supported by the server. Here the EPP server will announce support for rgp-1.0 (as defined in RFC 3915) and for secDNS-1.1 (as defined in RFC 5910).
At any time a 〈hello〉 command can be used to receive a 〈greeting〉 response.

2.2.2. Session Management
EPP provides two commands for session management: 〈login〉 to establish a session with a server, and 〈logout〉 to end a session with a server.
1) Login: The EPP 〈login〉 command is used to establish a session with an EPP server in response to a greeting issued by the server. A 〈login〉 command MUST be sent to a server before any other EPP command.
2) Logout: The EPP 〈logout〉 command is used to end a session with an EPP server.

2.2.3. Object Query Commands
EPP provides three commands to retrieve object information:
〈info〉 to retrieve detailed information associated with a known object,
〈check〉 to determine if an object is known to the server, and
〈transfer〉 to retrieve known object transfer status information. These are described into further detail below.
1) Info: The EPP 〈info〉 command is used to retrieve information associated with a known object. The elements needed to identify an object and the type of information associated with an object are both object-specific, so the child elements of the 〈info〉 command are specified using the EPP extension framework.
2) Check: The EPP 〈check〉 command is used to determine if an object is known to the server. The elements needed to identify an object are object-specific, so the child elements of the 〈check〉 command are specified using the EPP extension framework.
3) Poll: The EPP 〈poll〉 command is used to discover and retrieve notification messages queued by the server for individual Registrars. Some elements are object-specific, so the child elements of the 〈poll〉 response are specified using the EPP extension framework.
4) Transfer (Query): The EPP 〈transfer〉 command provides a query operation that allows a client to determine real-time status of pending and completed transfer requests. The elements needed to identify an object that is the subject of a transfer request are object-specific, so the child elements of the 〈transfer〉 query command are specified using the EPP extension framework.

2.2.4. Object Transform Commands
EPP provides five commands to transform objects:
〈create〉 to create an instance of an object with a server,
〈delete〉 to remove an instance of an object from a server,
〈renew〉 to extend the validity period of an object,
〈update〉 to change information associated with an object, and
〈transfer〉 to manage changes in client sponsorship of a known object. These are described into further detail below.
1) Create: The EPP 〈create〉 command is used to create an instance of an object. An object may be created for an indefinite period of time, or an object may be created for a specific validity period. The EPP mapping for an object MUST describe the status of an object with respect to time, to include expected client and server behavior if a validity period is used.
2) Delete: The EPP 〈delete〉 command is used to remove an instance of a known object. The elements needed to identify an object are object-specific, therefore the child elements of the 〈delete〉 command are specified using the EPP extension framework.
3) Renew: The EPP 〈renew〉 command is used to extend the validity period of an object. The elements needed to identify and extend the validity period of an object are object-specific, therefor the child elements of the 〈renew〉 command are specified using the EPP extension framework.
4) Transfer: The EPP 〈transfer〉 command is used to manage changes in client sponsorship of a known object. Clients may initiate a transfer request, cancel a transfer request, approve a transfer request, and reject a transfer request.
5) Update: The EPP 〈update〉 command is used to change information associated with a known object. The elements needed to identify and modify an object are object-specific, therefore the child elements of the 〈update〉 command are specified using the EPP extension framework.
All above transform commands can be processed by the Registry Operator in two ways:
1) immediately process the requested action;
2) initiate processing the requested action, but allow for off-line review or further interaction before completing the requested action. The response of the EPP server will clearly note that the requested action is “pending”.
In the latter case the state of the corresponding object will clearly reflect processing of the pending action. For more information on the domain name states, reference is made to the response to Question 27 (Domain Name Lifecycle).

2.3. Functionality to provision Registry services
To comply with the current EPP standard, a fully functional set of commands is at the Registrar’s disposal. These functions are based on the CRUD (Create – Read – Update – Delete) principle. The state of the data is maintained by creating (C), reading (R), updating (U) and eventually deleting (D) the data from the database.
The following basic objects exist in the database:
1) Domain: The domain object contains all relevant information to the domain name. This includes registration date, renewal date, status and DNSSEC key material.
2) Host: A host object defines a hostname which might be linked to a domain name. It is intrinsically needed to get the domain name working. It contains at least a domain name, possibly IP addresses and other references.
3) Contact: The contact object specifies a person or an organization. It contains various fields to identify such party. When linked to a domain name, a specific role is attributed to the relation.
The following commands, per object, allow for the full CRUD cycle to be implemented conform the above specified relevant RFCʹs. Please note that the read commands as referred to in the CRUD terminology are defined as query commands in the EPP-centric documentation. All objects are attributed to a specific Registrar and remain under its supervision. No other Registrar is granted access to these objects.
Registrars should first verify if the object is manageable (and owned) by using the 〈check〉 command. To get the content of an object, use the 〈info〉 command.
(View attachment for Table 1: Commands per object type)
By assigning a Registrar to all objects, a unique identifiable party is assigned to any object as the owner that is allowed to change and delete the object. To maintain a history of all changes, both a full trace log identifying Registrar, IP address, time and command as well as a history of the objects are stored in the database. This allows for a swift reconstruction of any interaction with the system. For more information we refer to the response to Question 33 of the evaluation criteria (Database Capabilities).

3. EPP Extensions
In order to be compliant with ICANNʹs Applicant Guidebook, an additional extension to maintain the domain object is needed to integrate with the Trademark ClearingHouse (Module V of ICANN’s Applicant Guidebook).
At the moment, no party has been appointed to perform the TradeMark Clearinghouse function, hence no specifications for interfacing have been established.
The function of the TradeMark Clearinghouse is to enable trademark holders to register their right in a central database, from where the trademark holder receives a validation code that can be used to apply for a domain name in a new TLD.
To that extent, ongoing community effort led already to a Launch Phase Mapping for EPP. This Internet-Draft describes an extension mapping for EPP that specifies a flexible scheme that can be used to implement several common use cases related to the provisioning and management of launch phase extension in a domain name Registry.
This mapping enables the Registrar to apply for⁄claim a domain name in the sunrise phase using the Pre-Validation Result Code 〈pvrc〉 from the TM Clearinghouse.

4. Security
It is imperative to make sure the service is not blocked by Denial Of Service attacks (DOS). To prevent this from happening, a number of security barriers are in place:
1) rate limiting the number of connections on the border router;
2) allowing only specific IP addresses specified by the Registrar;
3) limiting the number of concurrent connections per Registrar.
The EPP service will run on its own virtual machine. Resources available to the machine are constantly monitored. Early warnings are sent out in case any of the resources are deemed to be inadequately provisioned.
Security is enhanced by limiting the access to the EPP server to a Transport Layer Security (TLS) connection using high-grade encryption.
The Registrar is authenticated using the predefined session commands as defined in the above RFCs. The initial credentials are exchanged between the Registry Operator and the Registrar over an out-of-band channel.
A strict object-to-Registrar link exists such that a Registrar can only view, access and modify its own managed objects.

5) Resourcing Plan

5.1. Technical Resources
This service is delivered by a JAVA application running on a TOMCAT server. To ensure the database is consistent at all times, a lock is set per Registrar to ensure multiple connections set up by a Registrar are serialized at the application level. To maintain high speed at all time, a locking mechanism is also active at the domain name level, ensuring no two domain name registrations for the same domain name are modified, while still allowing the necessary concurrency.
Experience has learned that, under high load conditions, the bottleneck will rather be located at the database level, and not at the application level. If extra CPU power is required to deal with high volumes, an extra EPP service will be provided using an alternate IP address or using a load balancer.
To improve database security, the EPP serverʹs access to the database is limited to a specific separate network. For a more complete and detailed picture, reference is made to the response to Question 32 of the evaluation criteria (System & Network Architecture).

5.2. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Extensible Provisioning Protocol is under the authority of the Software Developer, under control of the Operations Manager. The technical infrastructure is implemented and maintained by the Network & System Administrator.

1. Overview
The Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC3912. This standard service is intended as a lookup service for Registry Operators, Registrars, Registrants, as well as for other individuals and businesses that wish to query details of domain names or nameservers stored in the domain name Registry and that are public. The standard WHOIS service provides a central location for all authoritative data the Registry has on the domain name. The Registry Operator also provides a front-end web interface to allow for convenient user access to the WHOIS service.
The Registry Operator will also operate a Domain Availability Service (DAS) via port 4343. Reference is made to section 5 of this response for further detail.
All WHOIS⁄DAS services are connected to the main domain name Registry database. If and when it is necessary for operational stability reasons, the WHOIS server can be duplicated, and connected to one or more read-only hot standby database mirrors. These mirrors are updated a-synchronously via streaming replication, which results in a near real-time data duplication.

2. WHOIS Service

2.1. RFC-3912 Compliant WHOIS
The RFC3912-conformant WHOIS service is engineered to handle moderate transaction load and is part of the standard suite of Registry Services. The WHOIS service will return a single response per domain name or nameserver query. The RFC3912-conform WHOIS service will comply with the requirements of Specification 4 of the Registry Agreement.
The RFC3912-compliant service provided by the Registry Operator will have the following features:
1) Standard protocol accessible over the common WHOIS port 43;
2) Near real-time updates;
3) The format of responses follows a semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of the Registry Operator, and of the user querying the database;
4) Each data object is represented as a set of key⁄value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value;
5) For fields where more than one value exists, multiple key⁄value pairs with the same key are allowed (for example to list multiple name servers). The first key⁄value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and Registrant information, together;
6) The format of the following data fields is: domain status, individual and organizational names, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date and times conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.

2.2. WHOIS Service data elements
The RFC3912-conform service will include the following data fields:
1) The name of the domain name registered;
2) The IP addresses of the primary nameserver and secondary nameserver(s) of the name registered, if applicable, and the corresponding names of those nameservers;
3) The identity of the Sponsoring Registrar;
4) The original creation date and term of the registration;
5) The name, postal address, e-mail address, voice telephone number, and (if available) fax number of the domain name Registrant;
6) The name, postal address, e-mail address, voice telephone number, and (if available) fax number of the technical contact for the domain name registered;
7) The name, postal address, e-mail address, voice telephone number, and (if available) fax number of the administrative contact for the domain name registered.

2.3. WHOIS Data update frequency
The Registry Operator will be running a thick Registry model, so the data will be readily available and doesnʹt need to be collected from the Registrars. The WHOIS service will query the main database, or, if database load or operational reasons demand, will query a hot standby read-only database mirror. In case of querying the main database, the data is always up-to-date, in case of querying a mirror database, the data is updated continuously via streaming replication and is near real time up-to-date (in a matter of seconds or minutes).

2.4. Privacy Capability
The Registry Operator will protect the privacy of an individual where required. If the Registrant of a domain name is an individual, the WHOIS service could disclose only limited information on the Registrant. If the Registrant wishes to disclose more information, he can instruct the Registrar to update the corresponding contact object in the Registry database (e.g. using the 〈contact:disclose〉 statement in EPP according to RFC5733).
If legislation mandates to avoid automatic harvesting of the Registrantʹs details (because port 43 WHOIS is plain text), the WHOIS service could omit the Registrant details and refer the initiator of the query to the web-based WHOIS where the WHOIS data will be disclosed in a multiple-step process.

2.5. Query Control – Object Type Control
The following keywords restrict a search to specific object type:
1) Domain: Search only by domain objects. The input string is searched in the Domain Name field.
2) Contact: Search only contact objects. The input string is searched in the Contact ID field.
3) Nameserver: Search only by nameserver objects. The input string is searched in the nameserver field and the IP address field.
4) Registrar: Search only Registrar objects. The input string is searched in the Registrar ID and Registrar Name fields.
By default, if no object type control is specified, then the Name field of the Domain object is searched.

3. WHOIS Output fields

3.1. Domain Records

3.1.1. Introduction
The WHOIS server can answer a domain name query in three different ways:
1) The domain name is registered in the domain name Registry database, a typical response is detailed in section 3.1.2;
2) The domain name is not registered, nor available for registration, because of various reasons, such as appearing on the blocked or reserved list, as specified in the Applicant Guidebook (see article 2.6 of the Registry Agreement), or for policy reasons. A typical response is detailed in section 3.1.3.
3) The domain name Registry has no information on the domain name in the request. A typical response is detailed in section 3.1.4.

3.1.2. Domain Name is registered
A WHOIS query that results in domain name information will return the following fields from the domain object and the associated data from host and contact objects. This set of data is also referred to as the Domain Record.
1) Domain Name (both A-label and U-label for IDN domain names, see response to Question 44 on Internationalized Domain Names);
2) Domain ID;
3) Domain Status (several domain status codes can be shown here, such as OK or INACTIVE, a pending action status and⁄or restriction flags. An overview can be found in the response to Question 27 on Domain Name Lifecycle);
4) Sponsoring Registrar (IANA-assigned identifier) and name of Registrar
5) Registrant, Administrative, Technical Contact Information including:
a) Contact ID
b) Contact Name
c) Contact Organization
d) Contact Address, City, State⁄Province, Country
e) Contact Postal Code
f) Contact Phone, Fax, E-mail
6) Names of Nameservers and IP addresses (IPv4 and⁄or IPv6) associated with this domain
7) Creation Date
8) Domain Expiration Date
9) Domain Last Updated Date
10) DNSSEC status of delegation (signedDelegation, unsigned)
For domain names that are registered in the sunrise phase, the WHOIS can show additional labels containing sunrise information (depending on the information provided by Trademark ClearingHouse, in accordance with Specification 7 in the Applicant Guidebook).

3.1.3. Domain Name is not registered, but not available
A WHOIS query for a domain name that is not registered in the domain name Registry database, but is also not available for registration, will result in a single line with the reason of non-availability (f.i. “Reserved by Registry” or “Blocked by Registry”).

3.1.4. No information on Domain Name
A WHOIS query for a domain name for which the domain name Registry has no information, will result in a single line stating “NOT FOUND”.

3.2. Nameserver Record
A WHOIS query that results in nameserver information will return the following (this set of information is referred to as the Nameserver Record)
1) Nameserver name
2) IP address (if applicable, IPv4 and⁄or IPv6)
3) Sponsoring Registrar (IANA-assigned identifier)

3.3. Contact Record
A WHOIS query that results in contact information will return the following. This set of information is referred to as the Contact Record.
1) Contact ID
2) Contact Name
3) Contact Organization
4) Contact Address, City, State⁄Province, Country + 3 street fields
5) Contact Postal Code
6) Contact Phone, Fax (if available), E-mail
7) Create Date
8) Contact Last Updated Date
9) Contact Status (several contact status codes can be shown here, such as OK or LINKED, a pending action status and⁄or restriction flags)
10) Sponsoring Registrar (IANA-assigned identifier)

3.4. Registrar Record
A WHOIS query that results in Registrar information will return the following (this set of information is referred to as the Registrar Record)
1) Registrar ID (conforming to the IANA Registrar-ids Registry)
2) Registrar Name
3) Registrar Address, City, State⁄Province, Country
4) Registrar Postal Code
5) Registrar Phone, Fax, E-mail
6) Registrar Administrative Contacts
7) Registrar Technical Contacts
8) Registrar Billing Contacts

4. Measures for Abuse Mitigation
Measures are taken to protect the WHOIS port 43 service against bulk access:
1) The number of queries is limited per querying IP address in two different ways: a maximum number of queries per second, and a capped number of queries per hour. Excessive querying will result in a denial of the result of the query.
2) The web-based WHOIS implements a multiple-step process to obtain the queried data, and is protected by a CAPTCHA image. Here the number of queries per day per IP address is also capped.
3) Data-mining techniques are implemented to monitor the distribution of the querying client’s IP addresses. Anomalies will be brought under the attention of the Registry Operator for further evaluation.
Often the reason for bulk access to the WHOIS service is querying the availability of the domain name (e.g. from Registrarʹs web front-ends). Therefore the domain name Registry Operator will also introduce a Domain Availability Service (DAS).

5. Domain Availability Service (DAS)
The DAS service will run on port 4343 and implements a very simple protocol, similar to the WHOIS protocol. The DAS service only indicates whether the given domain name is still available for registration or not, thereby not giving more information regarding the Registrant.
The query format: whois -p 4343 EXAMPLE.TLD
The response format:
1) Domain Name: EXAMPLE.TLD
2) Available: yes
3) Available: no
Bulk access to the DAS service is not discouraged, but, if required by stability concerns, the number of queries per second can be capped.

6. Searchable WHOIS Capabilities
The web-based WHOIS service will also offer the possibility to partially match the domain name field. The search string must be at least 4 characters, and the wildcard operator ʹ*ʹ must be added at the beginning and⁄or at the end of the search string. The WHOIS service will then return a HTML page with a maximum of 10 matching domain names, which can be clicked to view full details.
The search capabilities can only be explored by legitimate authorized users. Candidate users of this service need to apply for access to these features, giving a legitimate reason why they would need the service.
If the applicable privacy laws and policies allow to do so, more search capabilities can be enabled on the web-based WHOIS service, conform to Specification 4 of the Applicant Guidebook.
To prevent abuse of the service, all queries are stored per user. The number of queries per month is capped.
The searchable WHOIS capabilities offers the same privacy rules as described above.

7. Security and Stability
The WHOIS setup has multiple overload protection systems in place:
1) At the border of the network, rate limiting is implemented;
2) The stateful firewall prevents abuse from a single IP address;
3) The IDS⁄IPS prevents malformed WHOIS requests from passing;
4) To be able to maintain a high load of WHOIS queries, a cluster of virtual machines is set up. By using port replication or broadcast MAC, no load-balancing single points of failure are introduced;
5) If the WHOIS service load on the database experiences decreasing performance, as many extra read-only copies of the Registry database as needed can be set up and used by the WHOIS server(s) to provide extra WHOIS capacity. The capacity of the WHOIS service is therefore only capped by the rate limiting that is implemented at the network edge;
6) All WHOIS (port 43) cluster nodes run as separate virtual machines.
(View attachment for Figure 1: WHOIS Network & Infrastructure Overview)

8. Resourcing Plan
With regards to resourcing, reference is made to the global resourcing scheme as part of response to question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the WHOIS and DAS is under the authority of the Software Developer, under control of the Operations Manager. The technical infrastructure is implemented and maintained by the Network & System Administrator.

1. Overview
The registration life cycle for a private brand Domain Name Registry is a reduced version of the life cycle for an open brand TLD. Many of the requirements for open TLDs are less relevant for TLDs which have a limited number of names under management and which will use a very limited number of registrars (most likely just one).
It is also likely that the registered domain names will not be sold on the secondary market and transferred from one registrar to another. In addition, it is likely that the names will be “registered” for very long periods (max. 10 years), and that the domain name registry itself will automatically renew the domain names on expiry.
To summarize the operations:
1) All transactions via one registrar;
2) Create registrant, administrative, technical and billing contact;
3) Register domain name;
4) Add, remove or change name servers;
5) Add, remove or change DNSSEC keys;
6) Transfer not used (one registrar)?;
7) Deletion and restoration from redemption provided.
The following sections give an overview of the different actions that the Registrar can perform to influence the state of a domain name. Some might just change the state of the domain name. Others might alter the domain nameʹs information such as name servers, contacts, DNSSEC keys and client flags.
Some actions also involve interaction from the Domain Name Registry.
There are two distinct phases in the TLDʹs lifespan which lead to different behavior. The first phase does not allow free registrations. It typically consists of a number of sunrise periods where different parties under different circumstances are allowed to register certain domain names. The second phase is what is referred to as general availability. It could start with a so called ʹland rushʹ period that allows the Domain Name Registry to identify popular names.

2. Registration Lifecycle
The time line of a domain name is schematically provided in Figure 1.
(View attachment for Figure 1: Domain Timeline)
In the following paragraphs, more details are provided on the different steps in the time line.

2.1. Registration (or Sunrise)
1) The Domain Name Registry Operator receives the domain create command
2) The domain name goes into state pendingCreate during sunrise
a) The clearing house does validation of the domain name for the registrant
b) The domain name is registered if properly validated, or canceled otherwise.
3) Domain is registered

2.2. Update
1) Add, remove or change of tech, admin, billing contacts possible
2) Add, remove or change of name servers possible
3) Add, remove or change of DNSSEC keys possible

2.3. Transfer
1) Transfer: changing Registrar, same Registrant
2) Transfer command secured by authentication code
3) Losing Registrar notified to accept or reject the transfer (after consulting registrant and⁄or admin contact)
4) A successful transfer extends the registration period with one year (up to a maximum of ten years)

2.4. Renew
Registrars use the Renew Domain command to extend the registration period of a domain object. A Registrar can only renew domain names for which it is the sponsoring registrar. The Renew Domain command must be specified with a registration period, from one to ten years. The resulting expiry date must not lay more than 10 years in the future.
1) Domain name is renewed automatically on expiry date
2) Explicit renewal of period possible (period can be extended up to 10 years)

2.5. Delete
1) Deletion puts domain name in redemption status
2) Deleted from zone file instantly (serverHold)

2.6. Redemption
1) Domain name is no longer available in zone file (serverHold)
2) Domain name can be restored before the end of the redemption grace period (RGP)
3) The domain name will be purged after the pendingDelete interval

2.7. Available
1) Domain comes back in the pool of available domain names

3. RFC5731-Compliant Domain Name Status Codes
The status information on a domain name object is in line with the flags described in RFC5731, section 2.3. It is a combination of the following Status Value Descriptions:
1) clientDeleteProhibited, serverDeleteProhibited: Requests to delete the domain name will be rejected.
2) clientHold, serverHold: DNS delegation information is not published for the domain name .
3) clientRenewProhibited, serverRenewProhibited: Requests to renew the domain name are rejected.
4) clientTransferProhibited, serverTransferProhibited: Requests to transfer the domain name are rejected.
5) clientUpdateProhibited, serverUpdateProhibited: Requests to update the domain name , other than to remove this status value, are rejected.
6) Inactive: Delegation information has not been associated with the domain name . This is the default status when a domain object is first created and there are no associated host objects or host attributes for the DNS delegation. This status can also be set by the server when all host-object associations are removed.
7) Ok: This is the normal status value for an domain name that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
8) PendingCreate: Request to create a new domain name has been received and is being processed or evaluated.
9) pendingDelete: Request to delete an existing domain name has been received and is being processed or evaluated.
10) pendingRenew: Request to renew an existing domain name has been received and is being processed or evaluated.
11) pendingTransfer: Request to transfer an existing domain name has been received and is being processed or evaluated.
12) pendingUpdate: Request to update an existing domain name has been received and is being processed or evaluated.
Following combinations are excluded :
1) ok cannot be combined with any other status
2) pendingDelete status cannot be combined with ʺclientDeleteProhibitedʺ or ʺserverDeleteProhibitedʺ status
3) ʺpendingRenewʺ cannot be combined with ʺclientRenewProhibitedʺ or ʺserverRenewProhibitedʺ status
4) ʺpendingTransferʺ status cannot be combined with ʺclientTransferProhibitedʺ or ʺserverTransferProhibitedʺ status
5) ʺpendingUpdateʺ status cannot be combined with ʺclientUpdateProhibitedʺ or ʺserverUpdateProhibitedʺ status
6) pendingCreate, pendingDelete, pendingRenew, pendingTransfer and pendingUpdate cannot be combined
The status flags starting with the word ʹclientʹ can be changed and updated by the Registrar. The status flags starting with ʹserverʹ are handled by the Domain Name Registry Operator.
The Domain Name Registry will implement the above statuses in full.

4. RFC3915-Compliant Domain name status code
RFC3915 defines extra flags on the domain name that can be set or referenced by EPP. These flags are referred to as the RGP flags (Registry Grace Period). The following flags are defined and can be found in a separately available EPP extension called the RGP extension (RFC3915).
1) addPeriod: This “add grace period” is provided after the initial registration of a domain name. If the domain name is deleted by the registrar during this period, the domain name registry provides a credit to the registrar for the cost of the registration.
2) autoRenewPeriod: This “auto-renew grace period” is provided after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
3) renewPeriod: This “renew grace period” is provided after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the renewal.
4) transferPeriod: This “transfer grace period” is provided after the successful transfer of domain name registration sponsorship from one registrar to another registrar. If the domain name is deleted by the new sponsoring registrar during this period, the registry provides a credit to the registrar for the cost of the transfer.
5) redemptionPeriod: This status value is used to describe a domain for which a 〈delete〉 command has been received, but the domain has not yet been purged because an opportunity exists to restore the domain and abort the deletion process. This status must be combined with the pendingDelete status in the EPP domain mapping.
6) pendingRestore: This status value is used to describe a domain that is in the process of being restored after being in the redemptionPeriod state. This status must be combined with the pendingDelete status in the EPP domain mapping.
7) pendingDelete: This status value is used to describe a domain that has entered the purge processing state after completing the redemptionPeriod state without succesful restoration. This status must be combined with the pendingDelete status in the EPP domain mapping.
The Domain Name Registry will partially implement the above RGP statuses: the statuses concerning the redemption of the domain name (redemptionPeriod, pendingRestore, pendingDelete) and autoRenewPeriod.
We will not implement the following statuses:
1) addPeriod: because no “domain name tasting” will be allowed
2) renewPeriod: because the registrar has explicitly and successfully issued the renew command, no refund is granted;
3) transferPeriod: because the registrar has explicitly and successfully issued the transfer command, no refund is granted.

5. Status code matrix
There are two types of status values. These may change as a result of the Client initiating a transform command referring to the commands referenced in the ʹClientʹ column or by the domain name Registry referring to the ʹServerʹ column. The last column referred to as ʹGeneralʹ contains flags that transitional status values.
(View attachment for Table 1: Status Code Matrix)
The Prohibited flags have no influence on the status of the domain object. They prevent the denoted command from being executed on the domain name object. As such when set, they prevent the transform command from being executed and hence block the specified domain name life cycle transition.

6. Status transitions

6.1. Global status transitions
The following domain name states can be determined
1) The domain name status is defined as ʹavailable for registrationʹ (in short ʹavailableʹ) if the domain name is conform to the registration policy and the domain name object does not exist.
2) The domain name is registered (no pending actions).
3) The domain name has a pending action. This can be one of the following
a) pendingCreate
b) pendingTransfer
c) pendingDelete
d) pendingUpdate
e) pendingRenew
(View attachment for Table 2: Exhaustive list of transitions)
Some transitions might be influenced by the registration policy. For instance
1) The create has to be verified by the domain name Registry to see if no conflicts or infringements are detected.
2) The name servers added to the domain name object have to comply with certain rules set forth in the policy.
3) Change of ownership has to be verified.
4) Domain name matches predefined rule set needing registry acceptance.
This is a non-exhaustive list which should reflect domain name registration policy regulations.

6.2. Registry grace period status transitions
The following domain name states are added to the domain name object when it has the EPP pendingDelete status:
1) redemptionPeriod
2) pendingRestore
3) pendingDelete
(View attachment for Table 3: Exhaustive list of 3c pendingDelete state transitions)

6.3. Registration State Diagram
The Registration state diagram shows all possible states and transactions between those states.
In a single-Registrar Registry model, this State Diagram can be simplified:
1) The transfer of domain names is not used. Therefore all flags linked to transfer can be ignored.
The domain name life cycle can be found in the attached flow chart.
(View attachment for Figure 2: Registration State Diagram)

7. Transition commands
The following domain object commands, requested by the registrar, can be used to trigger status transitions:
(View attachment for Table 4: Transition commands)

8. Registry transitions
The Domain Name Registry triggers also status transitions in case of expiration, time-outs or resolution of pending actions:
(View attachment for Table 5: Registry status transitions)

9. Resourcing Plan

9.1. Personnel
With regards to resourcing, reference is made to the global resourcing scheme as part of response to Question 31 (Technical Overview of the Proposed Registry). Implementation and maintenance of the Registration Lifecycle in the Registry Platform is under the authority of the Software Developer, under control of the Operations Manager.

1.	Introduction
Next to ensuring that a TLD is operated in a technically stable and secure manner, it is also of utmost importance that the Internet community at large is safeguarded from abusive and malicious behavior. Existing TLDs have often suffered from such behavior and, gradually, best practices have been developed in order to not only counter abusive or malicious conduct, but also prevent such issues from happening.
Abusive use of a domain name generally includes, but is not limited to the following:
1)	illegal or fraudulent actions;
2)	using domain names in the TLD in order to send or forward unsolicited bulk messages, generally referred to as “spam”;
3)	distribution of malware: using domain names in order to disseminate software (e.g. computer viruses, keyloggers, etc.) that is designed to damage or harm the integrity of computers; 
4)	phishing: displaying web pages that are intended to mislead Internet users, with the aim of obtaining in a malicious manner from such users their sensitive data such as logins and passwords of the pirated websites;
5)	pharming: redirecting Internet users to fraudulent website, which is generally done by hijacking or poisoning the DNS or changing host files on the victim’s computer;
6)	fast-flux hosting and botnets;
7)	Illegal access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity);
8)	Using domain names in the TLD in order to disseminate illegal content, such as child pornography
Given the fact that the applied-for TLD will likely be and remain a single registrant TLD, as explained in our response to Question 18 et seq., where only members of the Applicant will be entitled to register domain names in the TLD, the likelihood for any such abusive behavior in this TLD to materialize is lower. Nonetheless, the Applicant commits to implement the preventive and curative measures described in the following paragraphs, in order to ensure that the applied-for TLD is operated in a responsible manner.

2.	Control
Considering the fact that the applied-for gTLD will be a so-called brand-TLD, the Applicant ⁄ Registry Operator will put in place various tools in order to mitigate or even exclude the possibility that the reputation of the key brands and identifiers of the Applicant is not harmed in any way. Especially, these tools and techniques will ensure that the Applicant will have the ability at all times to exercise control over:
1)	the registrant;
2)	the domain name;
3)	the contact information associated with any domain name; and
4)	the products, services and information provided under such domain name.
In order to effectuate this, a limited number of identified individuals within the Applicant’s organization will be able to control the applied-for TLD and any and all domain names registered therein from one portal, which has the following functionalities:
1)	validating the registrant’s eligibility and user rights in order to register domain names in the applied-for TLD;
2)	validating whether an (about to be) registered domain name in the applied-for TLD corresponds to the naming conventions that will be established by the Registry Operator for domain names registered in the applied-for TLD;
3)	validating contact information associated with registered domain names, in particular these contacts that can exercise control over the domain name itself, the name servers associated with such domain name, etc.;
4)	validating specific commands, including create, update and delete commands;
5)	approving for some or all domain names any transfer or trade requests, or intervene in the execution of such requests where the Registry Operator suspects that such transfer or trade requests are initiated in bad faith; and
6)	review whether the use that is made of a particular domain name corresponds with the Registry Operator’s use policy, and suspend domain name registrations or even delete name servers associated with domain names that are being used in a manner that does not comply with the types of uses that are allowed by the Registry Operator.
Bearing in mind that the registry is intended to be single registrant-registry only certain individuals are involved in above mentioned processes, reducing the risk of registering and⁄or using domain names in bad faith by any party that is not a member of the Applicant’s organization.
Access to this portal will be given to the administrators of the Registry Operator; furthermore, the Complaints Point of Contact will also obtain access to a limited number of features explained above.

3.	Reporting
Also, the Registry Operator will obtain access to reports generated by its back-end registry services provider, which reports include:
1)	number of DNS queries for each particular domain name registration;
2)	number of new domain names registered;
3)	number of new contacts created;
4)	etc.
If any suspicious activity is being detected following analysis of these reports, the Registry Operator will thoroughly investigate the matter and take appropriate action where required.

4.	Anti-abuse policy
Prior to the delegation of the TLD, the Registry Operator will publish the terms and conditions for the registration of domain names in the applied-for TLD, which will include an anti-abuse policy. Highlights of such policy will include:
Complaints Point of Contact: the Registry Operator will put in place a Complaints Point of Contact. The Complaints Point of Contact’s contact details will be mentioned on the home page of the Registry Operator, including on the web-based WHOIS interface.

5.	Monitoring
The Registry backend service provider, appointed by the applicant, will put in place certain tools and methodologies in order to proactively screen for malicious conduct. Such tools include scanners that automatically scan for viruses or other forms of malware on all services deployed under applied-for domain names.
These tools will operate in the background, and will not affect the functioning of the applied-for TLD.

6.	Prevention of Orphan glue records
In compliance with SSAC recommendations, the Registry backend service provider, appointed by the applicant, will check for the existence of glue records following the receipt of a deletion request for a particular domain name registration. If it would appear that no other domain names other than the domain name that is up for deletion are using the glue records associated with that domain name registration, the Registry Operator will remove such glue records after the domain name is deleted. 
Furthermore, any interested party will be entitled to file a complaint before the Complaints Point of Contact if it would appear that orphan glue records would still exist. If it would appear, following investigation by the Registry Operator, that orphan glue records would still exist in the zone file, such records will be promptly deleted from the zone file.

6.1.	Glue record
RFC 1034 defines glue as
“A zone contains glue resource records which are not part of the authoritative data, and are address resource records for the servers.”
And specifies further that
“These resource records are only necessary if the name serverʹs name is ʺbelowʺ the cut, and are only used as part of a referral response.”
In this specific case a glue record is the IP address of a name server held at the domain name registry.  They are required when a set of name servers of a domain name point to a hostname under the domain name itself. For example, if the name servers of example.com are ns1.example.com and ns2.example.com: to make the domain name system work, glue records (i.e. the IP addresses) for ns1.example.com and ns2.example.com are required. Without the glue records for these name servers the domain name would not work as anyone requiring DNS information for it would get stuck in a loop.
Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 donʹt know, try looking at name server for example.com
What is the name server for example.com? -〉 ns1.example.com
With the glue record in place the registry will hold the IP address and the loop will not occur.
Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 [IP Address]

6.2.	Orphan glue
The zone generation process could publish A-records ʺaddress-recordsʺ (also called ʺglueʺ records) regardless of whether or not the name server is referenced by any NS (name server) records. If an A-record is published and no zone delegations reference to such a record, it is called an orphan. Its presence in the zone is undesirable for a number of reasons, both administrative and technical.

6.3.	Out-of-bailiwick records
Records pointing to names of other zones besides the relevant registry zone, are called out-of-zone records or even out-of-bailiwick records. Any IP addresses linked to these names should in all circumstances be refused by the registry since they do not form part of the registryʹs zone. Most modern nameserver software will ignore these records by default.

6.4.	Exclusion
Glue records can only be inserted following the registration of a domain name and the creation of a host object. They can also only be included when the name servers have the same extension as the domain name. 
Example:
A glue record can only be inserted if the name server of example.com is located in example.com
These address records only live by the grace of the domain name itself. Since the IP address is always linked to the domain name, the address will also disappear from the zone as soon as the domain name is eliminated from the registration database. This limits the possibility to register name servers within a domain name, because setting up circular referencing name servers is not allowed. In view of the possible risks and dangers, this is a very balanced choice of limitations and it allows for a flexible and consistent handling of glue records.

7.	WHOIS accuracy
The Registry Operator will include in its domain name registration policies the obligation to keep all information contained in the WHOIS accurate and up-to-date.
As mentioned in response to Question 26, the applied-for WHOIS will be a “thick” WHOIS, where all key contact data relating to every domain name registered in the applied-for TLD will be stored at the level of the Registry Operator. 
Working closely with the accredited registrars for the applied-for TLD, Registry Operator will put in place measures whereby registrants are obliged to keep their WHOIS information accurate and up-to-date. Clauses will be inserted in the Registry-Registrar Agreement to that effect, in particular:
1)	under the terms of the Registry-Registrar Agreement, accredited registrars will be required to impose upon their clients the obligation to maintain accurate and up-to-date WHOIS data at all times;
2)	furthermore, accredited registrars will be instructed to send their customers who have registered a domain name in the TLD a request to confirm the accuracy of their WHOIS data and⁄or an email message whereby their obligation to keep WHOIS data accurate and up-to-date will is restated. 
3)	accredited registrars will have to demonstrate, upon the Registry Operator’s request, their compliance with the above, as well as any changes that have been made to WHOIS data following submission of such instructions.
The above processes and requirements will in particular be relevant as of the moment that the applied-for TLD will no longer be a single registrant TLD, which entails that certain parties, other than the Registry Operator, will be entitled to register domain names in this extension.
Furthermore, the Applicant ⁄ Registry Operator will display on the web-based WHOIS interface a link to the Complaints Point of Contact. Any party who is of the opinion that certain WHOIS data is inaccurate, incomplete or not up-to-date can contact the Complaints Point of Contact. The latter has the authority to commence investigations, and – in case of registrant non-compliance – take measures against such registrant. These measures include, but are not limited to, putting the domain name on hold, or revoking the domain name registration.

8.	WHOIS abuse prevention measures
Considering the fact that a WHOIS database contains quite some sensitive information that is available to Internet users at large over a web-based interface, the Registry Operator will put in place various methods in order to avoid abuse of such information by third parties.
First of all, the Registry Operator will only display search results in response to a search query after the user has successfully entered the displayed CAPTCHA code together with such query, this in order to prevent the automatic harvesting of WHOIS data.
Furthermore, private individuals (if at all allowed by the Applicant ⁄ Registry Operator to register and hold domain names within the TLD) will be allowed to indicate – through their registrars or via a web-based portal provided by the Applicant ⁄ Registry Operator – that certain personal data will not be automatically displayed following a successful WHOIS query. This measure is taken in order to comply with particular applicable laws and regulations regarding data privacy.
However, parties demonstrating to the Registry Operator that they have a right or legitimate interest in order to obtain access to this hidden data can request access to a particular, identified record upon request to the Registry Operator. Positive responses to legitimate requests shall not be unreasonably withheld or delayed.
The features described above can be temporarily or permanently disabled for specific eligible parties, such as law enforcement agencies, and this upon simple request by a competent authority. These eligible parties will then obtain access to all WHOIS information via a secure, web-based portal.

9.            Resourcing Plan
Applicant intends to outsource the above to reputable firms that have had experience to handle such complaints. These firms will consist out of highly technical and legal qualified staff.
An estimate of financial projections can be found in question 47.
For implementation of the technical measures, reference is made to the team of the Registry Service Provider, as described in the response to question 31.

1.	Introduction
As has been explained above, the Applicant ⁄ Registry Operator intends the applied-for TLD to be a restricted and closely monitored gTLD. This characteristics are mainly inspired by the Applicant’s ⁄ Registry Operator’s desire to protect the reputation of the key brands and identifiers of the Applicant under any circumstances.

2.	Preventing abusive domain name registrations
In order to prevent abusive domain name registrations in the applied-for TLD, various steps in the domain name lifecycle will be controlled by the Applicant ⁄ Registry Operator. In order to enable the Applicant ⁄ Registry Operator to do this, it will provide access to a control panel (“portal”) to key individuals within the Applicant’s organization. By way of this portal, these users can exercise at any time control over the applied-for TLD and any and all domain names registered in this extension, and in particular:
1)	validate on an ongoing basis the registrant’s eligibility and user rights in order to register domain names in the applied-for TLD;
2)	validate whether a (about to be) registered domain name in the applied-for TLD corresponds to the naming conventions that will be established by the Registry Operator for domain names registered in the applied-for TLD;
3)	validate contact information associated with registered domain names, in particular these contacts that can exercise control over the domain name itself, the name servers associated with such domain name, etc.;
4)	validate specific commands, including create, update and delete commands;
5)	approve for some or all domain names any transfer or trade requests, or intervene in the execution of such requests where the Applicant ⁄ Registry Operator suspects that such transfer or trade requests are initiated in bad faith; and
6)	review whether the use that is made of a particular domain name corresponds with the Applicant’s ⁄ Registry Operator’s use policy, and suspend domain name registrations or even delete name servers associated with domain names that are being used in a manner that does not comply with the types of uses that are allowed by the Applicant ⁄ Registry Operator.
Therefore, it is likely that for the term of the Registry Operator Agreement that will be executed between the Applicant and ICANN following award of the applied-for TLD by the latter to the Applicant, the Registry Operator will carefully monitor and manage all domain name registrations that are being made in the applied-for TLD.
This way, the Applicant ⁄ Registry Operator will put measures in place on a continuous basis whereby, first of all, the rights and legitimate interest of third parties are safeguarded, and, secondly, the reputation and good name of the key brands and identifiers of the Applicant will be underlined at all times.

3.	Internal verification and validation processes
One of the most effective safeguards that will be implemented by the Applicant ⁄ Registry Operator will be the screening of every domain name before this domain name gets registered and⁄or entered into the zone file of the applied-for TLD.
During any of such screenings, the relevant legal and risk management departments of the Applicant will consider the following factors:
1)	the likelihood of trademark infringement, if and when such domain name would become registered;
2)	the legitimate interests the Registry Operator or other members of the Applicant would have when using such domain name. This is in particular relevant if the domain name represents a generic, dictionary word that could be protected as a trademark. Given the fact that various members of the Applicant are engaged in the sale ⁄ retail of tens of thousands consumer goods, there is a likelihood that certain companies hold trademark registrations for the generic word relating to any of these goods. However, the Applicant ⁄ Registry Operator will at all times be entitled to invoke that it is making fair use of such domain name insofar and to the extent any such use is merely descriptive and relates to the offering of any such goods to consumers.
3)	any potential harm being done to trademark owners when registering and using a particular domain name in the applied-for TLD, and the benefit such domain name would have for the registrant.
Furthermore, as explained above and in various other sections of this application, the Applicant ⁄ Registry Operator will be screening on an ongoing basis the use that is being made of any domain name registered in the applied-for TLD and will implement reasonable measures in order to avoid harm being done to third parties.
Although the above processes will make it extremely unlikely that the Applicant ⁄ Registry Operator will engage or encourage potentially malicious or infringing activities to be carried out under the applied-for TLD, these cannot be completely excluded. 
Therefore, in addition to monitor any domain names registered under the applied-for TLD and the use that is made of such domain names, the Registry will – in accordance with its domain name registration policies – at all times be entitled to intervene if any such activities have been detected. Measures that can be taken include the suspension, revocation and blocking of any domain name registration and, in general, take any action necessary in order to limit or outright avoid any harm being done to the interests and reputation of third parties, the Registry Operator and its eligible registrants.

4.	Sunrise
When relevant, the Applicant ⁄ Registry Operator will implement a Sunrise process, whereby holders of certain trademarks will be entitled to safeguard the domain names that are identical (or even confusingly similar) to the name(s) to which they hold rights.
However, as mentioned in response to Question 18 of this application, the applied-for TLD is at least initially intended to be a single registrant-TLD, where only the Applicant ⁄ Registry Operator (or other members of the Applicant) will be entitled to register domain names. Now, Applicant ⁄ Registry Operator has no interest whatsoever to register any domain name on which it has no legitimate interest and⁄or that is useful for the day-to-day business activities of the eligible registrants within the TLD.
Therefore, the Applicant expects that the net effect of the operation of the TLD, and whether or not a Sunrise process is being introduced or not, will be the same.
However, the Applicant – being a member of the Applicant, holding various highly reputable brands – sees a benefit for introducing such Sunrise process at a specific point in time, albeit with the sole purpose of putting other brand owners at ease.
Such process would therefore most probably include providing the opportunity to other brand owners – unrelated to the Applicant or the other members of the Applicant – to block names to which such brand owners have rights, as demonstrated by the Trademark Clearinghouse.
Applicant’s ⁄ Registry Operator’s back-end registry operator has significant experience in managing Sunrise processes. In particular, various key staff members were heavily involved in designing and implementing Sunrise processes that preceded the launch of the .EU ccTLD, which is generally considered the most successful Sunrise process that has ever been implemented. 
At the time of submitting this application, the back-end registry operator is involved in the implementation of the Sunrise process for the .SX TLD.

5.	Trademark Claims
The Applicant ⁄ Registry Operator will support ICANN’s Trademark Claims process. Depending on the actual process that will be put in place by the Trademark Clearinghouse, the Applicant will implement these processes for at least the duration indicated in ICANN’s Applicant Guidebook or may even have this process in place for a longer term.
Similar processes have been put in place by various staff members of the Applicant’s back-end registry operator, so also here the Applicant can bow on significant and hands-on experience in handling these types of processes.

6.	Complaints Point of Contact
As is the case for various other processes and proceedings whereby third parties’ interests can be harmed, the Complaints Point of Contact that will be put in place by the Applicant ⁄ Registry Operator will also here play a pivotal role.
Any party claiming that his trademark(s) are infringed due to the registration and use of a domain name in the applied-for TLD is able to file a complaint before the Complaints Point of Contact of the Applicant ⁄ Registry Operator. Filing these complaints will be free of charge. The Complaints Point of Contact will generally provide a written response or even resolution of the matter within a suitable timeframe (depending on the complaint type) following the receipt of the complaint. 
Within this timeframe, the Complaints Point of Contact will investigate the complaint, and carry out ex officio investigations. As mentioned previously, the Complaints Point of Contact is entitled to suspend domain name registrations, delete name servers associated with infringing domain name registrations, or even outright revoke and block domain names from further registration if the Complaints Point of Contact is of the opinion that such domain name potentially infringes the rights of a third party, that no legitimate use is being made by the registrant of such domain name, and that there is bad faith involved.
It is the true desire of the Applicant ⁄ Registry Operator to have potential issues resolved by the Complaints Point of Contact. Therefore costly litigation can be avoided and issues resolved amicably.

7.	UDRP and URS
The Applicant ⁄ Registry Operator will implement all domain name dispute resolution policies designed by ICANN, including but not limited to those described in Consensus Policies and the Applicant Guidebook.
In this respect, the Applicant ⁄ Registry Operator will put any registered domain name on hold following receipt of a notification from the Uniform Dispute Resolution Policy or the Uniform Rapid Suspension Policy dispute resolution service provider that a complaint under such policies have been received.
Furthermore, it will implement decisions rendered by such dispute resolution service providers, however taking into account at all times that eligibility restrictions may be in force for domain name registrations made in the applied-for TLD. 
This could entail that the only remedy available to a third party that is not entitled by the Applicant ⁄ Registry Operator to register domain names in the applied-for TLD will be the revocation ⁄ deletion of the domain name. In order to ensure maximum compliance with any such decision, the Applicant ⁄ Registry Operator will put such domain name on a blocked list (i.e. make this domain name unavailable for further registration) insofar and to the extent the UDRP ⁄ URS dispute resolution service provider was of the opinion that the domain name registered by any party other than the Registry Operator or other members of the Applicant meets the requirements set out in the UDRP or URS.

Dr. August Markl	First Vice-President
Hermann Tomczyk	Sportspresident
Max Stich	Vice-President for Tourism
Peter Meyer	Vice-President for Finance
Peter Meyer	President
Thomas Burkhardt	Vice-President for Technics
Ulrich Klaus Becker	Vice-President for Traffic

Dr. Karl Obermair	Chief Operating Officer
Raimund Müller	Chief Operating Officer
Stefan Müller	Chief Executive Officer
Stefan Weßling	Chief Financial Officer

New gTLD Application Submitted to ICANN by: Allgemeiner Deutscher Automobil-Club e.V. (ADAC)

String: ADAC

Originally Posted: 13 June 2012

Application ID: 1-1031-24651

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.