New gTLD Application Submitted to ICANN by: Accent Media Limited

Application Downloaded On: 11 Nov 2014

String: tickets

Application ID: 1-2155-24150

Applicant Information

1. Full legal name
Accent Media Limited

2. Address of the principal place of business
2 Pattison Road, London, N2 2HH , London, GB

3. Phone number
+447970628509

4. Fax number
+44 (0) 20 33 88 0601

5. If applicable, website or URL

Primary Contact

6(a). Name
Steve Machin

6(b). Title
Director

6(c). Address

6(d). Phone Number
+447970628509

6(e). Fax Number
+44 (0) 20 33 88 0601

6(f). Email Address
primary@dottickets.org

Secondary Contact

7(a). Name
Gary Fisher

7(b). Title
CFO

7(c). Address

7(d). Phone Number
+44 7515 399 353

7(e). Fax Number
44 (0) 20 33 88 0601

7(f). Email Address
gary@accent.media

Proof of Legal Establishment

8(a). Legal form of the Applicant
Limited Company

8(b). State the specific national or other jurisdiction that defines the type of entity identified in 8(a).
England and Wales

8(c). Attach evidence of the applicant's establishment.
Attachments are not displayed on this form.

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

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

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

Applicant Background

11(a). Name(s) and position(s) of all directors
Name
Position
Ben CrawfordNon Exec Director
Gary FIsherCOO
Steve MachinCEO
Thomas HigginsNon Exec Chairman

11(b). Name(s) and position(s) of all officers and partners
Name
Position
Gary FisherCOO
Steve MachinCEO

11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
Name
Position
Animeros Enterprises
Pexterino Enterproses IncNot Applicable

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

Applied-for gTLD string

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


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



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



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



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



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



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



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



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



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



15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.



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

Accent Media anticipates the introduction of this TLD without operational or rendering problems. Based on a decade of experience launching and operating new TLDs, Afilias, the back-end provider of registry services for this TLD, is confident the launch and operation of this TLD presents no known challenges. The rationale for this opinion includes:

- The string is not complex and is represented in standard ASCII characters and follows relevant technical, operational and policy standards;
- The string length is within lengths currently supported in the root and by ubiquitous Internet programs such as web browsers and mail applications;
- There are no new standards required for the introduction of this TLD;
- No onerous requirements are being made on registrars, registrants or Internet users, and;
- The existing secure, stable and reliable Afilias SRS, DNS, WHOIS and supporting systems and staff are amply provisioned and prepared to meet the needs of this TLD.


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



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

The mission of .TICKETS is to create a safe, secure & trusted global domain environment for online ticket sales, marketing, & promotions which is free from fraudulent activity.Fraudulent & deceptive activity includes the sale of fake or non-existent tickets, phishing, malware & other malicious attacks & the collection of personal details for sale to third parties.

.TICKETS websites & services will be trusted by consumers, supported by the global industries that use tickets & ticket services & relevant industry bodies, promoted by credit card providers, welcomed by consumer protection organisations & endorsed by law enforcement agencies. The .TICKETS TLD will be the cornerstone of a much-needed structural solution to a global multi-million dollar problem, providing a solution that transcends national legislative frameworks.

We will achieve our mission by:
- Creating a gated space for trusted, authentic ticket selling & other ticketing services by validating all registrants of second level domains in the .TICKETS namespace against a published set of eligibility criteria developed by sector specific industry and other bodies
- Monitoring & controlling the use & transfer of second level domains within & between eligible registrants
- Developing meaningful strategies & partnerships (with industry bodies, credit card companies, consumer protection organisations & law enforcement agencies) to provide the consumer education & awareness programme which will ensure that over time, Internet users requiring tickets or ticketing services will seek out only websites that use the .TICKETS domain. Consumers will trust that a .TICKETS domain will take them to authentic ticket vendors & service providers.

Background and context:
Despite the existence of major ticket service brands operating with strong consumer awareness, online ticket fraud is a multi-million dollar global industry. It occurs when victims purchase tickets for, for e.g, a music, sport, theatre or other activity (e.g air or other travel,gaming & lotteries) which are either counterfeit or do not materialise.These “tickets” are purchased from fake ticketing websites & through online auction & shopping sites.Fake websites arenʹt always easy to spot & criminals invest heavily in making them look legitimate & very professional. Furthermore, contrary to popular belief the presence of HTTPS does not necessarily means that a website is secure & not being used for fraudulent purposes.As users become more fraud-aware, online scammers are making increasing efforts to trick consumers into visiting fake ticketing websites.

Online ticket fraud is a growing global problem & one that is increasingly associated with worldwide organised crime. In the UK alone, ticket fraud in the sporting & entertainment industries costs consumers, credit card providers, and event organisers over US$264M per year in fraudulent transactions (Source: UK Home Office figures)& research carried out in September 2009 by the UK Office of Fair Trading identified that 1 in 5 people know of someone who has bought “tickets” from a fake ticketing website. In the airline industry, 0.9% of global online airline ticket sales were lost to online fraud in 2010 amounting to US$1.4BN.The global challenge of online ticketing fraud extends to major global sporting events such as the Olympics. For e.g a fraudulent ticketing site www.beijingticketing.com sold over USD$50M of non-existent tickets. Interpol president Khoo Boon Hui said in May 2012 that organised international gangs are behind most Internet scams & that the estimated cost of cybercrime is more than that of cocaine, heroin & marijuana trafficking combined. The impact of online ticket fraud transcends unwitting consumers who buy fake or non-existent tickets. The knock-on effects are felt by many others, including brand owners (as domain names for websites often contain strings associated with them), entertainment venue & ticket collection outlets (who are faced with consumers arriving to collect non-existent tickets), credit card companies (who can suffer charge-backs where this consumer protection applies) & event organisers (who may endure charge-back costs assessed against them by their payment providers). In addition to online ticket fraud, fake ticketing sites may also put consumers at risk from phishing, malware & other malicious attacks. Also, personal information, such as credit card details, collected from fake ticketing sites may be sold on to third parties.

Our goals & objectives:
1. Enhance consumer protection by providing a safe & secure global domain space for tickets - by creating a gated space available for authentic ticket sellers, marketers and promoters which has strict entry requirements (eligibility criteria), strictly policed and enforced & with ongoing compliance monitoring.
2. Allow Internet users to easily & unmistakably identify trusted ticketing websites (for example, “For safety guaranteed, look for .TICKETS in the URL”) & raise consumer awareness by educating the public - which will be achieved through implementing a comprehensive & carefully researched marketing plan which will maximise awareness of the .TICKETS domain space.
3. Continue to build coalition partnerships & further develop our reputation as representing the interests, & acting as a trusted partner, of the global ticketing industries, ensuring that our policies & operations are technically excellent & fit for purpose, relevant & not unduly burdensome.
4. Operate the .TICKETS Registry impartially, responsibly & with integrity so as to promote a fair marketplace for the ticketing industry - through developing fair & transparent eligibility criteria & procedures for multiple application & dispute resolution, which will be sub-sector specific & developed in conjunction with relevant industry bodies.
5. Promote the Internet as a trusted global resource & contribute positively to the evolution of the domain name system.
6. Ensure the .TICKETS Registry is operated by an organisation with strong financial viability & longevity, supported by sound business practices & good governance, with strong management that has appropriate breadth & depth of experience.

Accent Media will involve the ticketing industry in developing the policies it will apply to the .TICKETS domain. In so doing, it will create a policy-making procedure that balances the participation of members of the ticketing industry with consultation and advice from consumer groups and others, such as law enforcement agencies. An advisory board will be convened for each industry sub-sector. The Registry shall appoint a policy officer who shall be responsible for assisting, drafting & revising all policies in liaison with the advisory boards. The advisory boards’ recommendations shall be delivered to the Registry’s executive committee for approval.

Summary: Our proposal for the .TICKETS domain space will promote diversification of the TLD namespace by introducing an innovative model that has safety and security at its core; in so doing playing its part in enhancing trust in the Internet. We will contribute to increasing competition in domain registration services through the independent operation of a TLD namespace that shall be accessible to businesses serving the global ticketing industry, rather than reserved for any single entity. At the heart of our business model will be our alliances with a wide range of stakeholders within both the private & public sectors and with whom we shall partner in developing fair & transparent policies that promote competition in the ticketing marketplace alongside consumer protection standards. We shall protect & promote the interests of consumers by creating a safe & secure environment for online ticket sales, marketing, & promotions which is free from fraudulent activity, promoted through global marketing & educational campaigns conducted in conjunction with our alliance partners.


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

i. The .TICKETS domain will be a safe, secure and trusted global domain space for ticket sales and ticket marketing and promotions.

The benefit for Internet users is clear: a .TICKETS domain will take them to trusted ticket vendors and associated service providers. Over time, consumer trust in the online ticket sectors will be improved, fraud and deception will be reduced and consumer protection will be increased.

We have support for our mission from a range of stakeholders that are connected to the ticket sector and ticket services. For example we have support from the Music Managers Forum - the UK trade organisation of over four hundred music managers representing more than one thousand music artists - who are keen to see our application succeed and for our gTLD to protect music fans from fraudulent and deceptive activity. See formal statement of support at http:⁄⁄www.stormcrowd.com⁄ACCENT_MEDIA⁄FAC_MMF_Accent_Media.pdf.

Registrants, being part of the global ticketing industry which is, for most industry sectors, unregulated will benefit from having available to them a “kite mark” of authenticity and legitimacy which will build consumer trust and confidence in online ticketing within the current global environment of increasingly sophisticated and widespread ticketing fraud and deception.

The legitimacy of registrants operating a .TICKETS domain will be secured through carefully developed industry specific eligibility criteria, containing quality standards and specifying service levels and best practices, compliance with which shall be monitored on an ongoing basis, and when appropriate amended in order to deal dynamically with new challenges that arise.

The reputation of the .TICKETS domain shall be paramount; the public’s trust in the safety and security of the .TICKETS domain must be sought through effective education and marketing, and maintained through diligent gatekeeping of the .TICKETS domain space.

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

In terms of the current space, online ticket selling and online ticket service provision, the .TICKETS domain will provide simple, immediate and effective differentiation and innovation by introducing a safe, secure and trusted global domain space.

It will assist in promoting fair competition by minimising fraud and deception. Fraud and deception costs consumers, ticket sellers, credit card companies and others in terms of brand equity losses, money, resource and time. The .TICKETS space with its industry sub-sector specific eligibility criteria will benefit all of these stakeholders. In so doing, it will assist operators in the .TICKETS domain space in building their businesses and brands, and will encourage new innovative players to enter the market and compete.

Furthermore, the .TICKETS domain space will enhance competition within the ticketing industry by allowing ticketing businesses who don’t have a traditional gTLD (such as .COM),(because their business or brand name has already been reserved in that gTLD domain space), to nonetheless obtain a second level domain name. This may make it easier for the public to find them and thus increase competition in the ticketing marketplace.

The .TICKETS namespace will facilitate a much greater level of innovation within the ticketing industry by giving those operating within this space the opportunity to develop specialist services such as trusted aggregators for, for example, festivals, concerts or sporting events.

The .TICKETS domain space will also enhance diversity; principally diversity regarding eligibility mechanisms for gTLDs. We envisage that the majority of new gTLD registrations will be plain Internet identifiers, not protected gateways like .TICKETS.

iii. What goals does your proposed gTLD have in terms of user experience?

As has already been stated, a .TICKETS domain will take users to trusted ticket vendors and service providers.

A .TICKETS domain will remove uncertainty for consumers and save them time, removing the need for consumers to carry out their own due diligence on the website from which they intend to procure ticketing goods or services, which they are often advised to do (see for example the advice from the UK Government joint initiative website, Get Safe Online at www. http:⁄⁄www.getsafeonline.org⁄nqcontent.cfm?a_id=1800)

In short, a .TICKETS second level domain will operate as a badge of authenticity and legitimacy within the ticketing sector in a similar way to that provided to Internet users who seek out .EDU for registered educational establishments or .GOV for official government websites.

iv. Provide a complete description of the applicant’s intended registration policies in support of the goals listed above.

The Registry policies surrounding the .TICKETS namespace will support and enable our mission to create a safe, secure and trusted global domain environment for online ticket sales, marketing and promotions free from fraudulent activity. It will ensure that only non-fraudulent operators can acquire second level domains and will also protect intellectual property rights owners.

The .TICKETS domain is intended to serve the global ticketing industry. Registrants will be those participating in the ticketing and ticket-related industries, and will be limited to a predetermined list of industry-types (which may be extended) to be developed by extended coalitions of cross-sector advisors.

Accent Media will involve the ticketing industry in developing the policies it will apply to the .TICKETS domain. Therefore, it will create a policy-making procedure that balances the participation of members of the ticketing industry with consultation and advice from consumer groups and others, including national and international law enforcement agencies. An advisory board will be convened for each industry sub-sector. The Registry shall appoint a policy officer who shall be responsible for assisting, drafting and revising all policies in liaison with the advisory boards. The advisory boards’ recommendations shall be delivered to the Registry’s executive committee for approval.

Please see our answers to Q#29 Rights Protection Mechanisms.

In addition, policies will be created to address the following:

1. The eligibility of registrants

Maintaining the credibility of the .TICKETS domain as a safe, secure and trusted global domain environment for online ticket sales, marketing, and promotions is crucial and Accent Media’s principle objective.

Therefore strict eligibility criteria shall be adopted in order to ensure that all registrants of .TICKETS domain names meet the above objective.

Fair, practicable, relevant and robust eligibility criteria, which will be sub-sector specific, must and will be developed by the advisory boards.

Consideration will be given to the necessity of adopting or revising certain eligibility criteria for different jurisdictions, although this will be the exception.

A potential registrant will be required to complete and submit an application, attesting to their eligibility and declaring the accuracy of the information they have provided. An authentication process, for example similar to that used for acquiring secure certification, will also need to be completed and may vary depending on the specific use cases as defined from time to time by the policy advisory boards.

Registrants shall be required to agree to a privacy policy which shall detail how information provided by them shall be used, including which information shall be made available to the public and under what circumstances.

In accordance with the eligibility criteria policy, the Registry will verify whether the declaration made by the applicant contains inaccurate or false information about the applicant’s identity and credentials and whether it has met the eligibility criteria. In order to verify the information provided by the applicant, the Registry shall be entitled to request supplementary information from the applicant, including but not limited to references.

In the event that an applicant’s application is denied, the applicant shall have a specified period of time within which to request a denial review. Should denial be confirmed following denial review, the applicant may appeal by initiating an appeals process (see below). Names that are subject to the denial review or appeal will not be available to any other applicant.

Eligible registrants may be limited to the number of second level domain names they may register.

Applicants will be required to demonstrate a knowledge of and support for the aims and objectives of the .TICKETS domain space (see below).

The eligibility criteria and authentication process will be reviewed and, if appropriate, updated from time to time.

To ensure fair access to the .TICKETS domain space, any name that is not registered by reason of the ineligibility of any applicant will become available for registration by any eligible party.

No applicant will be deemed eligible without accepting the terms of a registration agreement (see below). The agreement will be submitted to Accent Media either directly or via an authorised channel.

All registrants will be subject to audit and periodic review to ensure that they continue to meet the eligibility requirements. In addition to fixed period audits, the Registry may be entitled to initiate an audit at any time at its discretion, for example, upon receipt of user complaints. Failure to meet the audit and review requirements will be notified to the registrant and a period for compliance shall be given. Failure to demonstrate compliance within such time period may result in revocation of the registration agreement and forfeiture of the registrant’s right to use the .TICKETS domain space, as further defined in the registration agreement.

An appeals process will be available to any applicant whose application is unsuccessful and for any registrant whose registration agreement is revoked. An ombudsman will be appointed for each industry sub-sector to hear appeals. The ombudsman shall be independent from the Registry and the appellant. The ombudsman may be an individual or an entity.

2. Registration agreements

A registration agreement will be entered into by every registrant.

The registration agreement will contain operating rules. These operating rules will govern compliance with Registry policies, and will include, for example how and to whom the applicant may delegate third level domain names within their sub-domain.

The registrant agreement will require the registrant to make a declaration that it is legally entitled to use the name(s) it is proposing to register under the .TICKETS domain. The registrant will also be required to be bound by various dispute resolution policies (see below), including an eligibility dispute resolution policy (to be followed where a registrant’s eligibility is challenged by a third party).

All registrants will be required declare their support for the aims and objectives of the .TICKETS domain space by endorsing the Registry’s charter and code of conduct, which will set out the Registry’s fundamental guiding principles.

The registration agreement will permit the Registry to revoke the registrant’s right to use the .TICKETS domain in certain circumstances.


3. Registry policies

The Registry will develop, again in conjunction with the advisory boards referred to above, Registry policies that will support the Registry in its mission and which will sit alongside existing norms and conventions.

In terms of name selection, the principle that the Registry shall adopt is that the first eligible applicant for registration of a domain name will be entitled to register that name. The date and time of completion of all registration requirements, including eligibility and the authentication process, will determine the applicant’s order of priority.

The Registry shall adopt policies focused on the resolution of any dispute that may arise from the registration and ownership of a .TICKETS domain name. These policies shall include:

- An eligibility dispute resolution policy - to be followed where a registrant’s eligibility is challenged by the third party (NB we wish to make it clear that the Registry itself shall have primary responsibility for ensuring that eligibility criteria have been met by any applicant)
- A compliance consideration policy – to be followed where the Registry’s audit and periodic review of registrants’ on-going compliance with eligibility requirements has not been met by the registrant.
- Uniform Dispute Resolution Policy (UDRP) – all registrants will abide by the UDRP as approved by ICANN.

4. Appointment of registrars – selection and oversight

Policies surrounding the appointment of registrars will be developed and will operate in conjunction with standard operational policies of ICANN and other relevant authorities.

To ensure our aims and objectives are clearly communicated to potential registrants, it is crucial that registrar selection rests with the Registry. The Registry will accept all registrars meeting the Registry’s registrar eligibility criteria.

The Registry will oversee all registrars that it authorises. Such oversight shall include registrars’ adherence to Registry policies, their delivery of registration agreements, their handling and processing of applications according to the eligibility criteria and authentication processes, their delivery and updating of WHOIS data, and their management of cancellations, transfers and renewals.


5. Reserved names policy

Upon launch of the .TICKETS namespace, the Registry will inform the market in an appropriate manner of a list of reserved names and those available as premium domains at a fixed cost and those available as part of the opening premium domain name auction as is customary upon the launch of a new TLD Registry.

Additionally the Registry will comply fully with ICANN policy regarding reservation of geographical names and will ensure that any registrants of geographical names have the appropriate authorisation to use such a name in accordance with ICANN policy. See Q22 for additional specification of this policy.

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

Information given for the eligibility evaluation:

Registrants shall be required to agree to a privacy policy which shall detail how information provided by them to the Registry will be used, including explaining which information shall be made available to the public and⁄or regulatory bodies and under what circumstances.

For example, the Registry will compile and maintain a publicly accessible registration database that includes basic information about each domain name registered to it, including the names, telephone numbers and email addresses of individuals designated as points of contact for a given domain name.

Information published in the WHOIS service:

Information will be made available for the WHOIS service in accordance with ICANN policy.

General comments:

Registrants shall be required to endorse the Registry’s charter and code of practice which, amongst other matters, will confirm their adherence to privacy and data protection laws and regulations in the territories in which they operate, to ensure the protection of users.

The Registry itself shall operate to the highest standards of privacy and data protection, ensuring comprehensive understanding of its obligations by its senior officers, employees, agents and any third parties with which it works.

Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

Significant marketing and efforts are essential to educating consumers and raising their awareness of the .TICKETS namespace.

Accent Media will develop meaningful strategies and partnerships (with industry bodies, commercial partners (including, for example, credit card companies and banks), consumer protection organisations and law enforcement agencies) to provide the consumer education and awareness programme which will ensure that over time, Internet users requiring tickets or ticketing services will seek out only websites that use the .TICKETS domain. Consumers will trust that the .TICKETS domain will take them to authentic ticket vendors and service providers.

Accent Media will identify and engage with marketing partners to fund consumer education and awareness campaigns. These campaigns will be delivered on a sector by sector, territory by territory basis using locally relevant media campaigns to deliver the greatest impact towards achieving our goals and objectives. The primary goal of these campaigns will be to reach consumers most susceptible to online ticket fraud and deception.

Many industry sectors, such as the entertainment industry, have already engaged in initiatives to promote consumer awareness of fraud in online ticket sales. We will partner with these and new sectors and co-develop innovative ways of promoting our collective objectives that support our mission.

As an analogy, we will explore initiatives similar to that employed, for example, by the alcohol industry in the UK, Drinkaware (see www.drinkaware.co.uk), which aims to promote responsible drinking by equipping people with knowledge so as to enable them to make decisions about how they drink, and which is supported by voluntary donations from across the drinks industry.

Ultimately, through engagement with our key stakeholders, we envisage a future when a .TICKETS message is included prominently on all advertising and marketing for concerts, theatre productions, movies, sporting events and travel promotions as well as included on every ticket that is sold worldwide.


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

The essence of our mission for the .TICKETS domain space is to create a safe, secure and trusted global domain environment for online ticket sales, marketing, and promotions which are free from fraudulent activity.

By helping to reduce fraud – and the associated risks from consumers visiting sham websites, such as phishing and malware attacks, attacks from malicious software and the theft of personal information, such as credit card details – the .TICKETS domain space will save unwitting consumers money and disappointment, and reduce the costs (both financial and reputational) to brand and rights owners (as domain names for websites often contain strings associated with them), entertainment venue and ticket collection outlets (who are faced with consumers arriving to collect non-existent tickets), credit card companies (who can suffer charge-backs where this consumer protection applies) and event organisers who may have charge-back costs assessed against them by their payment providers.

In addition, since ticket fraud websites are widely associated with worldwide organised crime, the social good created by a secure .TICKETS domain space goes far beyond the online ticket-buying public and ticketing industry.

Our operating rules will inherently support all of the above.

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

Multiple applications for a particular domain name will be resolved on a first-come, first-served basis. This will be subject to applicants meeting the eligibility criteria.

Premium names will be auctioned amongst the eligible registrants.

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

It is our intention to offer registrants contracts for 1, 2 and 5 year periods and we may offer a discount on periods longer than 1 year. We may offer bulk-registration discounts if that expedites the use and consumer awareness of the .TICKETS registry.

Additionally, we have ascertained a number of technical redundancies and potential cost savings that might be available to registrants that have achieved specific tiers of registration or registrants that undertake specific activities and have use cases that would enable us to develop services around the cohort of registrants operating with the high levels of security and transparency benchmarks that will be in place to support our goals and objectives.

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

As a high security TLD based on pre-authorisation and registrant eligibility, we will naturally seek consistency within our registrant clients. We therefore welcome and encourage multiple year registrations of 5 years or more, subject to the maximum ICANN registration period that is set at ten years. Registrants of multiple year registrations will be audited in accordance with the sector-specific eligibility criteria throughout the term of their registration, and on an ongoing basis throughout any renewal periods.

As part of the registry agreement that we will agree with ICANN, we will commit to limiting renewal price increases. In practice we anticipate that registration prices will reduce over time as we build economies of scale. However, we are exposed to exchange rate risk, and our financial model is based on a rate of £1 = USD$1.57. Should the exchange rate change materially, we will review prices to take account of currency movements.

Our financial model also includes a substantial proportion of “other” service revenues, which are again priced in US dollars, but in practice might be received in multiple currency denominations depending upon the location of the vending registrar or the registrant. We will commit that the retail price of any annual fees (paid per organisation, not per domain) will increase no faster than the agreed rate of increase of the renewal prices per the Registry agreement. We will reserve the right to adjust these fees further if the exchange rate changes materially.

Registrars will be given sufficient notice of any price changes in accordance with the then current Registry agreement with ICANN and price changes will apply to new registrations and renewals.


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

No


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



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



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



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



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



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



21A. Is the application for a geographic name?

No


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

We will protect names with national or geographic significance by reserving the country and territory names at the second level and at all other levels within the TLD, as per the requirements in the New TLD Registry Agreement (Specification 5, paragraph 5).

We will employ a series of rules to translate the geographical names required to be reserved by Specification 5, paragraph 5 to a form consistent with the ʺhost namesʺ format used in domain names.

Considering the Governmental Advisory Committee (GAC) advice “Principles regarding new gTLDs”, these domains will be blocked, at no cost to governments, public authorities, or IGOs, before the TLD is introduced (Sunrise), so that no parties may apply for them. We will publish a list of these names before Sunrise, so our registrars and their prospective applicants can be aware that these names are reserved.

We will define a procedure so that governments can request the above reserved domain(s) if they would like to take possession of them. This procedure will be based on existing methodology developed for the release of country names in the .INFO TLD. For example, we will require a written request from the country’s GAC representative, or a written request from the country’s relevant Ministry or Department. We will allow the designated beneficiary (the Registrant) to register the name, with an accredited .tickets Registrar, possibly using an authorization number transmitted directly to the designated beneficiary in the country concerned.

As defined by Specification 5, paragraph 5, such geographic domains may be released to the extent that Registry Operator reaches agreement with the applicable government(s). Registry operator will work with respective GAC representatives of the country’s relevant Ministry of Department to obtain their release of the names to the Registry Operator.

If internationalized domains names (IDNs) in other languages and script than the ones referred to in Q44 are introduced in the .tickets in the future, we will also reserve the IDN versions of the country names in the relevant script(s) before IDNs become available to the public. If we find it advisable and practical, we will confer with relevant language authorities so that we can reserve the IDN domains properly along with their variants.

Regarding GAC advice regarding second-level domains not specified via Specification 5, paragraph 5: All domains awarded to registrants are subject to the Uniform Domain Name Dispute

Resolution Policy (UDRP), and to any properly-situated court proceeding. We will ensure appropriate procedures to allow governments, public authorities or IGO’s to challenge abuses of names with national or geographic significance at the second level. In its registry-registrar agreement, and flowing down to registrar-registrant agreements, the registry operator will institute a provision to suspend domains names in the event of a dispute. We may exercise that right in the case of a dispute over a geographic name.


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

Accent Media Limited has chosen CentralNic as the registry infrastructure provider for .TICKETS. Please see Appendix 23.1 for the acceptance letter from CentralNic. Any information regarding technical and operational capability of the proposed registry (answers to questions 23 - 44) therefore refers to CentralNic's registry infrastructure.
 
Accent Media and CentralNic hereby explicitly confirm that all registry services described below are engineered and will be provided in a manner compliant with the new gTLD Registry Agreement, ICANN consensus policies (such as Inter-Registrar Transfer Policy and AGP Limits Policy) and applicable technical standards. Except for the registry services described below, no other services will be provided by the Registry that relate to (i) receipt of data from registrars concerning registrations of domain names and name servers; (ii) provision to registrars of status information relating to the zone servers for .TICKETS; (iii) dissemination of TLD zone files; (iv) operation of the Registry zone servers; or (v) dissemination of contact and other information concerning domain name server registrations in .TICKETS as required by the Registry Agreement.
 
There are no other products or services, except those described below, that the Registry Operator will provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of Accent Media being designated as the Registry Operator.
 
Any changes to the registry services that may be required at a later time in the course of the operation of the registry will be addressed using rules and procedures established by ICANN, such as the Registry Services Evaluation Policy.
 
Accent Media proposes to operate the following registry services, utilising CentralNic's registry system:
 
23.1 Receipt of Data From Registrars
 
CentralNic will provide a Shared Registry System (SRS) for .TICKETS. The SRS consists of a database of registered domain names, host objects and contact objects, accessed via an Extensible Provisioning Protocol (EPP) interface, and a web-based Registrar Console. Registrars will use these interfaces to provide registration data to the registry.
 
The SRS will be hosted on CentralNic's resilient infrastructure operated from multiple operations centres. Each operations centre comprises a resilient, fault-tolerant network infrastructure with multiple high quality redundant links to backbone Internet carriers. Each operations centre is hosted in carrier-grade data centre facilities and boast significant physical security capabilities, including 24x7 patrols, CCTV and card-based access controls.
 
CentralNic's existing SRS system currently supports over 1 million domain names managed by over 1,500 registrars. CentralNic has effective and efficient 24x7 customer support capabilities to support these domain names and registrars, and this capability will be expanded to meet the requirements of .TICKETS and provide additional capacity during periods of elevated activity (such as during Sunrise periods).
 
The SRS and EPP systems are described more fully in S24 and S25. The Registrar Console is described in S31.
 
EPP is an extensible protocol by definition. Certain extensions have been put in place to comply with the new gTLD registry agreement, ICANN Consensus Policies and technical standards:
 
1. Registry Grace Period Mapping - compliant with RFC 3915
 
2. DNSSEC Security Extensions - compliant with RFC 5910
 
3. Launch Phase Extension - compliant with the current Internet Draft draft-ietf-eppext-launchphase-02
 
4. Fee extension - compliant with the current Internet Draft draft-brown-epp-fees-02
 
More information on EPP extensions is provided in S25.
 
The SRS will implement and support all ICANN Consensus Policies and Temporary Policies, including:
 
* Uniform Domain Name Dispute Resolution Policy
 
* Inter-Registrar Transfer Policy
 
* Whois Marketing Restriction Policy
 
* Restored Names Accuracy Policy
 
* Expired Domain Deletion Policy
 
* AGP Limits Policy
 
23.2 Provision to Registrars of Status Information Relating to the Zone Servers
 
CentralNic operates a communications channel to notify registrars of all operational issues and activity relating to the DNS servers that are authoritative for .TICKETS. This includes notifications relating to:
 
1. Planned and unplanned maintenance;
 
2. Denial-of-service attacks;
 
3. Unplanned network outages;
 
4. Delays in publication of DNS zone updates;
 
5. Security incidents such as attempted or successful breaches of access controls;
 
6. Significant changes in DNS server behaviour or features;
 
7. DNSSEC key rollovers.
 
Notifications will be sent via email (to preregistered contact addresses), with additional notifications made via an off-site maintenance site and via social media channels.
 
23.3 Dissemination of TLD Zone Files
 
CentralNic will make TLD zone files available via the Centralized Zone Data Service according to specification 4, section 2 of the Registry Agreement.
 
Accent Media, through the CZDS, will provide each user with access to the zone file for a period of not less than three (3) months. Accent Media will allow users to renew their Grant of Access.
 
23.4 Operation of the Registry Zone Servers
 
The .TICKETS zone will be served from CentralNic's authoritative DNS system. This system has operated at 100% service availability since 1995 and has been developed into a secure and stable platform for domain resolution. Partnering with multiple third-party secondary DNS providers, CentralNic's DNS system includes nameservers in more than fifty cities, on five continents. The DNS system fully complies with all relevant RFCs and all ICANN specifications, and has been engineered to ensure resilience and stability in the face of denial-of-service attacks, with substantial overhead and geographical dispersion.
 
The DNS system is described further in S35.
 
23.5 Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
 
CentralNic will provide a Whois service for .TICKETS. The Whois service will provide information about domain names, contact objects, and name server objects stored in the Shared Registry System via a port-43 service compliant with RFC 3912. The Whois service will permit interested parties to obtain information about the Registered Name Holder, Administrative, Technical and Billing contacts for domain names. The Whois service will return records in a standardised format that complies with ICANN specifications.
 
CentralNic will provide access to the Whois service at no cost to the general public.
 
CentralNic's Whois service supports a number of features, including rate limiting to prevent abuse, privacy protections for natural persons, and a secure Searchable Whois Service. The Whois service is more fully described in S26.
 
Should ICANN specify alternative formats and protocols for the dissemination of Domain Name Registration Data, CentralNic will implement such alternative specifications as soon as reasonably practicable.
 
23.6 DNSSEC
 
.TICKETS zone will be signed by DNSSEC. CentralNic's DNSSEC system is based on OpenDNSSEC. Zone files will be signed using NSEC3 with opt-out, following a DNSSEC Practice Statement detailed in S43.
 
CentralNic's DNSSEC implementation complies with RFCs 4033, 4034, 4035, 4509 and follows the best practices described in RFC 4641. Hashed Authenticated Denial of Existence (NSEC3) will be implemented, which complies with RFC 5155. The SRS will accept public-key material from child domain names in a secure manner according to industry best practices (specifically the secDNS EPP extension, described in RFC 5910). CentralNic also publishes on its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants' public-key material. CentralNic's DPS follows the format described in RFC6841.
 
23.7 Rights Protection Mechanisms
 
Accent Media will provide all mandatory Rights Protection Mechanisms that are specified in the Applicant Guidebook, namely Trademark Claims Service and Sunrise service. All the required RPM-related policies and procedures such as UDRP, URS, PDDRP and RRDRP will be adopted and used in .TICKETS. More information is available in S29.
 
In addition to such RPMs, Accent Media may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party's legal rights. Accent Media will include all ICANN mandated and independently developed RPMs in the registry-registrar agreement entered into by ICANN-accredited registrars authorised to register names in .TICKETS. Accent Media shall implement these mechanisms in accordance with requirements established by ICANN each of the mandatory RPMs set forth in the Trademark Clearinghouse.
 
The "LaunchPhase" EPP extension (described above) will be used to implement an SRS interface during the Sunrise period for .TICKETS.
 
23.8 Registrar Support and Account Management
 
CentralNic will leverage its 20 years of experience of supporting over 1,500 registrars to provide high-quality 24x7 support and account management for .TICKETS registrars. CentralNic's experienced technical and customer support personnel will assist .TICKETS registrars during the on-boarding and OT&E process, and provide responsive personal support via email, phone and a web based support ticketing system.
 
23.9 Reporting to ICANN
 
Accent Media and CentralNic will compile and transmit a monthly report to ICANN relating to .TICKETS. This report will comply with Specification 3 of the New gTLD Registry Agreement.
 
23.10 Registry Lock Service
 
Accent Media and CentralNic will provide a Registry Lock Service for .TICKETS. This service will operate in a similar way to that provided by other gTLD registries such as Verisign and Afilias.
 
The Registry Lock Service provides an additional layer of protection for "high value domains", protecting them from unauthorised modification as a result of a hijacked customer account, or a compromise of a registrar's website or other technical system.
 
Under the service, domain names are placed in a "Registry Lock" which prohibits any updates by the registrar. When a change is required, the registrar must submit a request for the domain to be unlocked: this is request is authenticated out-of-band using pre-established communication channels.
 
A per-domain fee will be charged to all registrars who use this service.
 
23.10.1 Procedure
 
1. The registrar provides an initial list of domain names to be placed under a lock, and one or more Points of Contact (POC) with whom unlock requests will be authenticated. Additional domains may be added to the list by submitting a support ticket.
 
2. The registry will then place these domains under Registry Lock. This will result in the following EPP status codes being applied to the domain:
 
* serverUpdateProhibited
* serverTransferProhibited
* serverRenewProhibited (this will not prevent auto-renewals)
* serverDeleteProhibited
 
3. Once locked, any attempt by the registrar to update, renew or delete the domain will be refused by the registry, as will any attempt by another registrar to transfer it.
 
4. When the registrar wishes to change a domain that is locked, or remove a domain from the list, they must submit a support ticket to request that the domain be unlocked.
 
5. The registry will authenticate the request by contacting the registrar by telephone and verifying the details of the request. Once verified, the lock will be removed from the domain.
 
6. The registrar may then make the changes required via the Registrar Console or EPP system.
 
7. When the required changes have been made, the registrar submits a further support ticket to request that the domain be re-locked. The registry will automatically re-lock the domain after 24 hours.
 
23.10.2 Billing
 
Registrars will be charged on a monthly basis for each domain that is subject to a registry lock. These fees will be added to the standard monthly invoice.
 
23.11 Personnel Resources of CentralNic
 
The technical, operations and support functions of the registry will be performed in-house by CentralNic's personnel. These personnel perform these functions on a full-time basis.
 
23.11.1 Technical Operations
 
Technical Operations refers to the deployment, maintenance, monitoring and security of the registry system, including the SRS and the other critical registry functions. Technical Operations staff design, build, deploy and maintain the technical infrastructure that supports the registry system, including power distribution, network design, access control, monitoring and logging services, and server and database administration. The Technical Operations team also performs internal helpdesk and incident reporting. The Technical Operations team performs 24x7 monitoring and support for the registry system and mans the Network Operations Centre (NOC) from which all technical activities are coordinated.
 
CentralNic maintains a Technical Operations team consisting of the following positions. These persons will be responsible for managing, developing and monitoring the registry system for .TICKETS on a 24x7 basis:
 
* System Administrator(s)
 
* Network Operations Engineer(s)
 
* Operations Engineer(s)
 
* Security Engineer
 
23.11.2 Technical Development
 
The Technical Development team develops and maintains the software which implements the critical registry functions, including the EPP, Whois, zone file generation, data escrow, reporting, back office and web-based management systems (intranet and extranet), and open-source registrar toolkit software. All critical registry software has been developed and maintained in-house by this team.
 
CentralNic maintains a Technical Development team consisting of the following positions. These persons will be responsible for maintaining and developing the registry software that will support .TICKETS:
 
* Senior Technical Developers (2)
 
* Technical Developers (3)
 
23.11.3 Technical Support
 
Technical Support refers to 1st, 2nd and 3rd line support for registrars and end-users. Areas covered include technical support for systems and services, billing and account management. Support personnel also deal with compliance and legal issues such as UDRP and URS proceedings, abuse reports and enquiries from law enforcement.
 
1st line support issues are normally dealt with by these personnel. 2nd and 3rd line support issues (relating to functional or operational issues with the registry system) are escalated to Technical Operations or Technical Development as necessary.
 
The Technical Support team consists of the following positions:
 
* Operations Manager
 
* Support Manager
 
* Support Agent(s)
 
Our overseas account managers also perform basic support functions, escalating to the support agents in London where necessary.
 
23.11.4 Key Personnel
 
23.11.4.1 Gavin Brown - Chief Technology Officer
 
Gavin has worked at CentralNic since 2001, becoming CTO in 2005. He has overall responsibility for all aspects of the SRS, Whois, DNS and DNSSEC systems. He is a respected figure in the domain industry and has been published in several professional technical journals, and co-authored a book on the Perl programming language. He also participates in a number of technical, public policy and advocacy groups and several open source projects. Gavin has a BSc (hons) in Physics from the University of Kent.
 
23.11.4.2 Anna Ogneva - Operations Manager
 
Anna has worked at CentralNic since 2013. She has a background of working in business administration and operations in technology companies for 10+ years, playing an integral role in startups growing into multinational corporate businesses. Her main responsibilities are project management and operations for new gTLDs. Anna has a BA (Hons) in Marketing from London Metropolitan University.
 
23.11.4.3 Kareem Ali - Network Operations Engineer
 
Kareem has worked at CentralNic since 2012. He has overall responsibility for the company's network infrastructure, global Anycast DNS network, network security, and improving the overall performance and reliability of distributed systems. He is also responsible for the company's internal communication system. Kareem graduated with a BSc in Control and Systems Engineering from University of Technology in Baghdad, and is a certified Cisco and Juniper network engineer. He previously worked for IraqSat.
 
23.11.4.4 Alex McFall - System Administrator
 
Alex has worked at CentralNic since the beginning of 2013. He is responsible for provisioning, maintaining and securing server systems for the varied services that the company provides. This includes development and maintenance of the Galera cluster database system, deploying the Puppet configuration management system and building robust monitoring systems. Alex has an MSc in Computer Science from Cardiff University.
 
23.11.4.5 Milos Negovanovic - Senior Technical Developer
 
Milos has worked at CentralNic since 2009. He has a background in building rich web applications and protocol servers. His main areas of responsibility are the Registrar Console, EPP and back office functions.
 
23.11.4.6 Mary O'Flaherty - Senior Technical Developer
 
Mary has worked at CentralNic since 2008. She plays an integral role in the ongoing design, development and maintenance of the registry as a whole and has specific experience with the EPP system, Registrar Console and Staff Console. Mary has a 1st class Honors degree in Computer Science from University College Cork and has previously worked for Intel and QAD Ireland.
 
23.11.4.7 Matt McLeary - Customer Support Manager
 
Matt joined CentralNic in 2014, but has been in the domain name industry for over five years and oversees the, Group's support department, responsible for handling all incoming registrar and end-user support.
 
23.11.5 Job Descriptions
 
CentralNic will maintain its Technical Operations and Technical Development teams in order to perform technical duties in relation to .TICKETS and other gTLDs. The following job descriptions are used to define these roles and select candidates with suitable skills and experience.
 
23.11.5.1 Operations Engineer
 
Operations Engineers assist in the maintenance and development of the network and server infrastructure of the registry system. Operations Engineers have a good knowledge of the TCP/IP protocol stack and related technologies, and are familiar with best practice in the areas of network design and management and system administration. They should be competent system administrators with a good knowledge of Unix system administration, and some knowledge of shell scripting, software development and databases. Operations Engineers have 1-2 year's relevant commercial experience. Operations Engineers report to and work with the Senior Operations Engineer, who provides advice and mentoring. Operations Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.
 
23.11.5.2 Security Engineer
 
Security Engineers enhance and assure the security of the registry system. Day-to-day responsibilities are: responding to security incidents, performing analysis and remediating vulnerabilities, conducting tests of access controls, refining system configuration to improve security, training other team members, reviewing source code, maintaining security policies and procedures, and gathering intelligence relating to threats to the registry. Security Engineers have 1-2 year's relevant commercial experience. This role reports to and works with the Senior Operations Engineer and CTO. Security Engineers participate in manning the NOC on a 24x7 basis and participate in the on-call shift rota.
 
23.11.5.3 Technical Developer
 
Technical Developers maintain the software that supports the registry. Day-to-day responsibilities are developing new systems in response to requests from management and customers, correcting bugs in existing software, and improving performance. Technical Developers have a good knowledge of general programming practices including use of revision control and code review systems. Developers have a good awareness of security issues, such as those described in advisories published by the oWASP Project. Developers have at least one years' commercial experience in developing applications in programming languages such as PHP, Perl, and Python, although knowledge of domain technologies such as EPP and DNS is not critical. Technical Developers work as part of a team, with advice and mentoring from the Senior Technical Developers, to whom they report.
 
23.11.5.4 Resource Matrix
 
To provide a means to accurately and objectively predict human resource requirements for the operation of the registry system, CentralNic has developed a Resourcing Matrix, which assigns a proportion of each employee's available time to each aspect of registry activities. These activities include technical work such as operations and development, as well as technical support, registrar account management, rights protection, abuse prevention, and financial activity such as payroll, cash collection, etc. This matrix then permits the calculation of the total HR resource assigned to each area.
 
A copy of the Resourcing Matrix is included as Appendix 23.2. It is important to note that the available resources cover the operation of CentralNic's entire registry operations: this includes CentralNic's own domain registry portfolio (uk.com, us.com, etc), the .LA and .PW ccTLDs, as well as other gTLDs which CentralNic provides registry services for.
 
The actual proportion of human technical resources required specifically for .TICKETS is determined by the relative size of .TICKETS to the rest of CentralNic's operations. This calculation is based on the projected number of domains after three years of operation: the optimistic scenario is used to ensure that sufficient personnel is on hand to meet periods of enhanced demand. CentralNic has calculated that, if all its new gTLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names.
 
Since the optimistic projection for the number of domains registered in .TICKETS after three years is 10,000 domains, .TICKETS will therefore require 0.22% of CentralNic's total available HR resources in order operate fully and correctly. In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


24. Shared Registration System (SRS) Performance:
describe

Except where specified this answer refers to the operations of the Accent Media's outsource Registry Service Provider, CentralNic.
 
24.1 Registry Type
 
CentralNic operates a "thick" registry in which the registry maintains copies of all information associated with registered domains. Registrars maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and contact information associated with registered domains. The Extensible Provisioning Protocol (EPP) adopted supports the thick registry model. See S25 for further details.
 
24.2 Architecture
 
Figure 24.1 provides a diagram of the overall configuration of the SRS. This diagram should be viewed in the context of the overall architecture of the registry system described in S32.
 
The SRS is hosted on CentralNic's resilient infrastructure which includes multiple operations centres. It is connected to the public Internet via multiple diverse upstream connections. Figure 32.1 provides a diagram of the outbound network connectivity. Interconnection with upstream transit providers is via BGP routers that connect to the firewalls, which implement access controls over registry services.
 
Within the firewall boundary, connectivity is provided to servers by means of resilient gigabit Ethernet switches implementing Spanning Tree Protocol.
 
The registry system implements two interfaces to the SRS: the standard EPP system (described in S25) and the Registrar Console (described in S31). These systems interact with the primary registry database (described in S33). The database is the central repository of all registry data. Other registry services also interact with this database.
 
An internal "Staff Console" is used by CentralNic personnel to perform management of the registry system.
 
24.3 EPP System Architecture
 
A description of the characteristics of the EPP system is provided in S25. This response describes the infrastructure that supports the EPP system.
 
A general network diagram for the EPP system is provided in Figure 24.2. This design is replicated at each operations centre.
 
CentralNic's EPP system has a two-layer logical and physical architecture, consisting of load balancers and a pool of application servers. Each layer can be scaled horizontally in order to meet demand.
 
Registars establish TLS-secured TCP connections to the load balancers on TCP port 700. Load is balanced using DNS round-robin load balancing.
 
The load balancers pass sessions to the EPP application servers. Load is distributed using a weighted-least-connections algorithm. The application servers run the Apache web server with the mod_epp module. These servers implement the EPP session state machine and handle commands received from registrars using application business logic.
 
Each component of the system is resilient: multiple inbound connections, redundant power, high availability firewalls, load balancers and application server clusters enable seamless operation in the event of component failure. This architecture also allows for arbitrary horizontal scaling: commodity hardware is used throughout the system and can be rapidly added to the system, without disruption, to meet an unexpected growth in demand.
 
The EPP system at each operations centre comprises the following systems:
 
* 2x load balancers (1U rack mount servers with quad-core Intel processors, 16GB RAM, 40GB solid-state disk drives, running the CentOS operating system using the Linux Virtual Server [see http://www.linuxvirtualserver.org/])
 
* 8x EPP application servers (1U rack mount servers with dual-core Intel processors, 16GB RAM, running the CentOS operating system using Apache and mod_epp)
 
24.3.1 mod_epp
 
mod_epp is an Apache server module which adds support for the EPP transport protocol to Apache. This permits implementation of an EPP server using the various features of Apache, including CGI scripts and other dynamic request handlers, reverse proxies, and even static files. mod_epp was originally developed by Nic.at, the Austrian ccTLD registry. Since its release, a large number of ccTLD and other registries have deployed it and continue to support its development and maintenance. Further information can be found at http://sourceforge.net/projects/aepps. CentralNic uses mod_epp to manage EPP sessions with registrar clients, and to convert EPP commands into internal Apache requests, which are then handled by backend application code.
 
24.3.2 Performance
 
CentralNic performs continuous remote monitoring of its EPP system, and this monitoring includes measuring the performance of various parts of the system. As of writing, the average round-trip times (RTTs) for various functions of the EPP system were as follows:
 
* <login>: 66ms
 
* <hello>: 12ms
 
* <check>: 35ms
 
* <create> (host): 74ms
 
* <delete> (host): 1450ms
 
* <logout>: 13ms
 
These figures include an approximate latency of 2.4ms due to the distant between the monitoring site and the EPP system. They were recorded during normal weekday operations during the busiest time of the day (around 1300hrs UTC) and compare very favourably to the requirement of 4,000ms for session commands and 2,000ms for query commands defined in the new gTLD Service Level Agreement. RTTs for overseas registrars will be higher than this due to the greater distances involved, but will remain well within requirements.
 
24.3.3 Scaling
 
Horizontal scaling is preferred over vertical scaling. Horizontal scaling refers to the introduction of additional nodes into a cluster, while vertical scaling involves using more powerful equipment (more CPU cores, RAM etc) in a single system. Horizontal scaling also encourages effective mechanisms to ensure high-availability, and eliminate single points of failure in the system.
 
Vertical scaling leverages Moore's Law: when units are depreciated and replaced, the new equipment is likely to be significantly more powerful. If the average lifespan of a server in the system is three years, then its replacement is likely to be around four times as powerful as the old server.
 
For further information about Capacity Management and Scaling, please see S32.
 
24.4 Registrar Console
 
The Registrar Console is a web-based registrar account management tool. It provides a secure and easy-to-use graphical interface to the SRS. It is hosted on a virtual platform that is replicated at each operations centre. The virtual platform is described in Figure 24.3.
 
The features of the Registrar Console are described in S31.
 
The virtual platform is a utility platform that supports systems and services which do not operate at significant levels of load, and which therefore do not require multiple servers or the additional performance that running on "bare metal" would provide. The platform functions as a private cloud, with redundant storage and failover between hosts.
 
The Registrar Console currently sustains an average of 6 page requests per minute during normal operations, with peak volumes of around 8 requests per minute. Volumes during weekends are significantly lower (fewer than 1 requests per minute). Additional load resulting from this and other new gTLDs is expected to result in a trivial increase in Registrar Console request volumes, and CentralNic does not expect additional hardware resources to be required to support it.
 
24.5 Quality Assurance
 
CentralNic employs the following quality assurance (QA) methods:
 
1. 24x7x365 monitoring provides reports of incidents to NOC
 
2. Quarterly review of capacity, performance and reliability
 
3. Monthly reviews of uptime, latency and bandwidth consumption
 
4. Hardware depreciation schedules
 
5. Unit testing framework
 
6. Frequent reviews by QA working group
 
7. Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
 
8. Revision control software with online annotation and change logs
 
9. Bug Tracking system to which all employees have access
 
10. Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
 
11. Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
 
12. Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
 
13. Evidence-based project scheduling
 
14. Specification development and revision
 
15. Weekly milestones for developers
 
16. Gantt charts and critical path analysis for project planning
 
17. ISO-9001 certified quality management system
 
Registry system updates are performed on an ongoing basis, with any user-facing updates (ie changes to the behaviour of the EPP interface) being scheduled at specific times. Disruptive maintenance is scheduled for periods during which activity is lowest.
 
24.6 Billing
 
CentralNic operates a complex billing system for domain name registry services to ensure registry billing and collection services are feature rich, accurate, secure, and accessible to all registrars. The goal of the system is to maintain the integrity of data and create reports which are accurate, accessible, secured, and scalable. The foundation of the process is debit accounts established for each registrar. CentralNic will withdraw all domain fees from the registrar's account on a per-transaction basis. CentralNic will provide fee-incurring services (e.g., domain registrations, registrar transfers, domain renewals) to a registrar for as long as that registrar's account shows a positive balance. CentralNic's system also supports a credit-based billing system which is available upon request and following a credit check.
 
24.7 Registrar Support
 
CentralNic provides a multi-tier support system on a 24x7 basis with the following support levels:
 
* 1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer's information and to determine the customer's issue by analyzing the symptoms and figuring out the underlying problem.
 
* 2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
 
* 3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues.
 
CentralNic provides a support ticketing system for tracking routine support issues. This is a web-based system (available via the Registrar Console) allowing registrars to report new issues, follow up on previously raised tickets, and read responses from CentralNic support personnel.
 
When a new trouble ticket is submitted, it is assigned a unique ID and priority. The following priority levels are used:
 
1. Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
 
2. Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
 
3. Severe: serious issue with a primary feature necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Handled by 2nd level support.
 
4. Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support.
 
Depending on priority, different personnel will be alerted to the existence of the ticket. For example, a Priority 1 ticket will cause a notification to be emailed to the registrar customer support team, but a Priority 4 ticket will result in a broadcast message sent to the pagers of senior operations staff including the CTO. The system permits escalation of issues that are not resolved within target resolution times.
 
24.8 Enforcement of Eligibility Requirements
 
The SRS supports enforcement of eligibility requirements, as required by specific TLD policies.
 
Figure 24.4 describes the process by which registration requests are validated. Prior to registration, the registrant's eligibility is validated by a Validation Agent. The registrant then instructs their registrar to register the domain. The SRS returns an "Object Pending" result code (1001) to the registrar.
 
The request is sent to the Validation Agent by the registry. The Validation Agent either approves or rejects the request, having reconciled the registration information with that recorded during the eligibility validation. If the request has been approved, the domain is fully registered. If it is rejected, the domain is immediately removed from the database. A message is sent to the registrar via the EPP message queue in either case. The registrar then notifies the registrant of the result.
 
24.9 Interconnectivity With Other Registry Systems
 
The registry system is based on multiple resilient stateless modules. The SRS, Whois, DNS and other systems do not directly interact with each other. Interactions are mediated by the database, which is the single authoritative source of data for the registry as a whole. Individual modules perform "CRUD" (create, read, update, delete) actions upon the database. These actions then affect the behaviour of other registry systems: for example, when a registrar adds the "clientHold" status to a domain object, this is recorded in the database. When a query is received for this domain via the Whois service, the presence of this status code in the database results in the "Status: clientHold" appearing in the whois record. It will also be noted by the zone generation system, resulting in the temporary removal of the delegation of the domain name from the DNS.
 
24.10 Resilience
 
The SRS has a stateless architecture designed to be fully resilient in order to provide an uninterrupted service in the face of failure or one or more parts of the system. This is achieved by use of redundant hardware and network connections, and by use of continuous "heartbeat" monitoring allowing dynamic and high-speed failover from active to standby components, or between nodes in an active-active cluster. These technologies also permit rapid scaling of the system to meet short-term increases in demand during "surge" periods, such as during the initial launch of a new TLD.
 
24.11 Synchronisation Between Servers and Sites
 
CentralNic's system is implemented as multiple stateless systems, which interact via a central registry database. As a result, there are only a few situations where synchronisation of data between servers is necessary:
 
1. Replication of data between database cluster nodes. (see S33). CentralNic implements redundancy in its database system by means of synchronous, multi-master replication. The Galera clustering technology provides automatic and reliable clustering, synchronization. Automated monitoring and failover is implemented on application servers to to ensure continued access to the database following a failure of any part of the database system.
 
2. Asynchronous replication is used to synchronise data between each operations centre (see S34). Database updates are replicated between sites in real-time via a secured VPN, providing a "hot" backup site which can be used to provide registry services in the event of a failure at the currently active site.
 
24.12 Operational Testing and Evaluation (OT&E)
 
An Operational Testing and Evaluation (OT&E) environment is provided for registrars to develop and test their systems. The OT&E system replicates the SRS in a clean-room environment. Access to the OT&E system is unrestricted and unlimited: registrars can freely create multiple OT&E accounts via the Registrar Console.
 
24.13 Resourcing
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


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

Except where specified this answer refers to the operations of the Accent Media's outsource Registry Service Provider, CentralNic.
 
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. EPP defines generic object management operations and an extensible framework that maps protocol operations to objects. EPP has become established as the common protocol by which domain registrars can manage domains, nameservers and contact details held by domain registries. It is widely deployed in the gTLD and ccTLD registry space.
 
CentralNic has operated its EPP system since 2005, and it currently operates at significant load in terms of registrars, sessions and transaction volumes. CentralNic's EPP system is fully compliant with the following RFC specifications:
 
* 5730 - Base Protocol
 
* 5731 - Domain Names
 
* 5732 - Host Objects
 
* 5733 - Contact Objects
 
* 5734 - TCP Transport
 
* 3735 - Extension Guidelines
 
* 3915 - RGP Extension
 
* 5910 - DNSSEC Extension
 
25.1 Description of Interface
 
EPP is a stateful XML protocol layered over TCP (see RFC 5734). Protected using lower-layer security protocols, clients exchange identification, authentication, and option information, and engage in a series of client-initiated command-response exchanges. All EPP commands are atomic (there is no partial success or partial failure) and designed so that they can be made idempotent (executing a command more than once has the same net effect on system state as successfully executing the command once).
 
EPP provides four basic service elements: service discovery, commands, responses, and an extension framework that supports definition of managed objects and the relationship of protocol requests and responses to those objects.
 
EPP servers respond to client-initiated communication (which can be either a lower-layer connection request or an EPP service discovery message) by returning a greeting to a client. The server then responds to each EPP command with a coordinated response that describes the results of processing the command.
 
EPP commands fall into three categories: session management, queries, and transform commands. Session management commands are used to establish and end persistent sessions with an EPP server. Query commands perform read-only object information retrieval operations. Transform commands perform read-write object management operations.
 
Commands are processed by a server in the order they are received from a client. The protocol includes features that allow for offline review of transform commands before the requested action is completed. In such situations, the response clearly notes that the command has been received but that the requested action is pending. The corresponding object then reflects processing of the pending action. The server will also notify the client when offline processing of the action has been completed. Object mappings describe standard formats for notices that describe completion of offline processing.
 
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation. These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.
 
25.1.1 Objects supported
 
Registrars may create and manage the following object types in the CentralNic EPP system:
 
* domains (RFC 5731)
 
* host objects (RFC 5732)
 
* contact objects (RFC 5733)
 
25.1.2 Commands supported
 
CentralNic supports the following EPP commands:
 
* <hello> - retrieve the <greeting> from the server
 
* <login> and <logout> - session management
 
* <poll> - message queue management
 
* <check> - availability check
 
* <info> - object information
 
* <create> - create object
 
* <update> - update object
 
* <renew> - renew object
 
* <delete> - delete object
 
* <transfer> - manage object transfer
 
25.2 EPP state diagram
 
Figure 25.1 describes the state machine for the EPP system. Clients establish a connection with the server, which sends a greeting. Clients then authenticate, and once a login session is established, submits commands and receive responses until the server closes the connection, the client sends a logout command, or a timeout is reached.
 
25.3 EPP Object Policies
 
The following policies apply to objects provisioned via the EPP system:
 
25.3.1 domains
 
1. Domains must comply with the syntax described in RFC 1035 S2.3.1. Additionally, the first label of the name must be between 1 and 63 characters in length.
 
2. Domains must have a registrant attribute which is associated with a contact object in the database.
 
3. Domains must have an administrative contact attribute which is associated with a contact object in the database.
 
4. Domains must have a technical contact which attribute is associated with a contact object in the database.
 
5. Domains may have an billing contact attribute which is associated with a contact object in the database.
 
6. Domains may have between 0 (zero) and 13 DNS servers. A domain with no name servers will not resolve and no records will be published in the DNS
 
7. The host object model for domains is used rather than the host attribute model.
 
8. Domains may have a number of status codes. The presence of certain status codes indicates the domain's position in the lifecycle, described further in S27.
 
9. Where policy requires, the server may respond to a <domain:create> command with an "Object Pending" (1001) response. When this occurs, the domain is placed onto the pendingCreate status while an out-of-band validation process takes place.
 
10. When registered, the expiry date of a domain may be set up to ten years from the initial date of registration. Registrars can specify registration periods in one-year increments from one to ten.
 
11. When renewed, the expiry date of a domain may be set up to ten years from the current expiry date. Registrars can specify renewal periods in one-year increments from one to ten. Domains which auto-renew are renewed for one year at a time. Domain names may not be renewed more than ten years into the future.
 
12. Domains must have an authInfo code which is used to authenticate inter-registrar transfer requests. This authInfo code may contain up to 48 bytes of UTF-8 character data.
 
13. Domains may have one or more DS records associated with them. DS records are managed via the secDNS EPP extension, as specified in RFC 5910.
 
14. Only the sponsoring registrar of the domain may submit <update>, <renew> or <delete> commands for the domain.
 
25.3.2 Host objects
 
1. Host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
 
2. In-bailiwick hosts must have at least one IPv4 or IPv6 address. They may have additional IP addresses of either type.
 
3. Sponsorship of hosts is determined as follows: if an object is in-bailwick (ie child of a domain in the database, and therefore also child to a TLD in the system), then the sponsor is the sponsor of the parent domain. If the object is out-of-bailiwick, the sponsor is the registrar which created the contact.
 
4. If a registrar submits a change to the name of a host object, if the new host name is subordinate to an in-bailiwick domain, then that registrar must be the sponsor of the new parent domain.
 
5. Registrars are not permitted to create hosts that are subordinate to a non-existent in-bailiwick domain, or to change the name of a host object so that it us subordinate to a non-existent in-bailiwick domain.
 
6. A host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see S28).
 
7. Inter-registrar transfers are not permitted.
 
8. Only the sponsoring registrar of the host may submit <update> or <delete> commands for the object.
 
25.3.3 Contact objects
 
1. Contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
 
2. Phone numbers and email addresses must be valid as described in RFC 5733 S2.5 and S2.6.
 
3. Contact information is accepted and stored in "internationalized" format only: that is, contact objects only have a single <contact:postalInfo> element and the type attribute is always "int".
 
4. The <contact:org>, <contact:sp>, <contact:pc>, <contact:phone> and <contact:fax> elements are optional.
 
5. Contacts must have an authInfo code which is used in inter-registrar transfers. This code may contain up to 48 bytes of UTF-8 character data.
 
6. A contact cannot be deleted if one or more domains are associated with it.
 
7. Only the sponsoring registrar of the contact may submit <update> or <delete> commands for the object.
 
25.4 EPP Extensions
 
CentralNic supports the following EPP extensions. CentralNic's implementations fully comply with the required specifications.
 
25.4.1 Registry Grace Period Mapping
 
Various grace periods and hold periods are supported by the Registry Grace Period mapping, as defined in RFC 3915. This is described further in S27.
 
25.4.2 DNSSEC Security Extensions Mapping
 
Registrars may submit Delegation Signer (DS) record information for domains under their sponsorship. This permits the establishment of a secure chain-of-trust for DNSSEC validation.
 
CentralNic supports the specification defined in RFC 5910. This supports two interfaces: the DS Data Interface and Key Data Interface. CentralNic supports the former interface (DS Data), where registrars submit the keytag, algorithm, digest type and digest for DS records as XML elements, rather than as key data. Key data is stored if provided as a child element of the <secDNS:dsData> element. The maxSigLife element is optional in the specification and is not currently supported.
 
25.4.3 Launch Phase Extension
 
CentralNic has assisted development of a standard EPP extension for registry "launch phases" (ie Sunrise and Landrush periods), during which the steady-state mode of "first-come, first-served" operation does not apply. This extension permits registrars to submit requests for domains with claimed rights such as a registered trademark. The extension is currently described in the Internet-Draft draft-ietf-eppext-launchphase-02. It is intended that this draft will eventually be published as an RFC.
 
CentralNic's system implements this extension and will support the most recent version of the draft during the initial launch of .TICKETS. Once .TICKETS enters General Availability, this extension will no longer be available for use by registrars.
 
25.4.4 Fee Extension
 
The Fee extension provides a means for registrars to query the fees applicable to billable transactions such as domain name registration, renewal, and transfer. The specification for this extension was developed by Gavin Brown, CentralNic's CTO, and is in widespread use among other gTLD registries. The extension is specified in an Internet-Draft at http://tools.ietf.org/html/draft-brown-epp-fees-02.
 
25.5 Registrar Credentials and Access Control
 
Registrars are issued with a username (their registrar ID) and a password. This password cannot be used to access any other service and only this password can be used to access the EPP system. Registrar officers with the "Management" access level can change their EPP password via the Registrar Console.
 
RFC 5730 requires "mutual, strong client-server authentication". CentralNic requires that all registrars connect using an SSL certificate. This certificate may be obtained from a recognised certificate authority, or it may be a self-signed certificate registered with CentralNic via the Registrar Console. Registrar officers with the "Management" access level can upload SSL certificates for their account.
 
25.6 Session Limits and Transaction Volumes
 
During normal operations, there are no limits on the number of active sessions a registrar can maintain with the server. Similarly, there are no limits on the volume of transactions a registrar may send. However, during initial launch periods when there is an increased demand from registrars, the number of concurrent connections per registrar will be restricted and a "speed limit" imposed on each connection, to ensure equal access to all registrars.
 
25.7 Transaction Logging and Reporting
 
All "transform" commands are logged. Transform commands are: <create>, <renew>, <update>, <delete> and <transfer>. The system logs the time and date when the command was received, the registrar that submitted it, the request and response frames, the result code and message. All commands, whether successful or not, are logged.
 
The transaction log is stored in the primary registry database. Registrars have access to the log for their account via the Registrar Console. The log viewer permits filtering by command, object type, object ID (domain, host name, contact ID), result code and timestamp.
 
Query commands (<check>, <info>, <poll op="req">) and session commands (<login>, <logout> and <hello>) are not logged due to the large volume of such queries (particularly <check> queries). The EPP system uses counters for these commands to facilitate generation of monthly reports.
 
25.8 EPP Message Queue
 
The EPP protocol provides a message queue to provide registrars with notifications for out-of-band events. CentralNic currently supports the following EPP message notifications:
 
* approved inbound transfer
 
* rejected inbound transfer
 
* new outbound transfer
 
* cancelled outbound transfer
 
* approved or rejected domain registration request (where TLD policy requires out-of-band approval of <domain:create> requests, such as during Sunrise)
 
25.9 Registrar Support, Software Toolkit
 
CentralNic has supported EPP for many years. CentralNic has released a number of open source client libraries for several popular programming languages. These are used by registrars and registries around the world. CentralNic maintains the following open source EPP libraries:
 
* Net::EPP, a general purpose EPP library for Perl.
 
* Preppi, a graphical EPP client written in Perl.
 
* Pepper, a command line EPP client written in Perl.
 
* Net_EPP, a PHP client class for EPP.
 
* Simpleepp, a Python client class for EPP.
 
* tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python.
 
These libraries are available for anyone to use, at no cost. CentralNic develops these libraries, and accepts submissions and bug reports from users around the world.
 
CentralNic's open source software is published at https://gitlab.centralnic.com/.
 
25.10 Quality Assurance, RFC Compliance
 
To ensure that its EPP system fully complies with the relevant specifications documents, CentralNic has implemented the following:
 
25.10.1 Schema Validation
 
The EPP system automatically validates all response frames against the XSD schema definitions provided in the RFCs. Should a non-validating response be sent to a registrar, an alert is raised with the NOC to be investigated and corrected.
 
25.10.2 Multi-stage Deployment and Testing
 
EPP system code is developed, tested and deployed in a multi-stage environment:
 
1. Developers maintain their own development environment in which new code is written and changes are prepared. Development environments are configured with the highest level of debugging and strictness to provide early detection of faults.
 
2. All changes to the EPP system are subjected to peer review: other developers in the team must review, test and sign off the changes before being committed (or, if developed on a branch, being merged into the stable branch).
 
3. Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance.
 
25.10.3 Registrar Feedback
 
Registrars are provided with an easy way to report issues with the EPP system, and many perform schema validation on the responses they receive. When issues are detected by registrars, they are encouraged to submit bug reports so that developers can rectify the issues.
 
25.10.4 Resourcing
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.


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

Whois is one of the oldest Internet protocols still in use. It allows interested persons to retrieve information relating to Internet resources (domain names and IP addresses). Whois services are operated by the registries of these resources, namely TLD registries and RIRs.
 
Whois is described by RFC 3912, which serves as a description of existing systems rather than requiring specific behaviours from clients and servers. The protocol is a query-response protocol, in which both the query and the response are opaque to the protocol, and their meanings are known only the server and to the human user who submits a query. Whois has a number of limitations, but remains ubiquitous as a means for obtaining information about name and number resources.
 
26.1 Compliance
 
The Whois service complies with RFC3912 and Specifications 4 and 10 of the New gTLD Registry Agreement. The service is provided to the general public at no cost. If ICANN specify alternative formats and protocols (such as RDAP) then CentralNic will implement these as soon as reasonably practicable.
 
CentralNic monitors its Whois system to confirm compliance. Monitoring stations check the behaviour and response of the Whois service to ensure the correctness of Whois records. CentralNic maintains a public Whois contact to which bug reports and other questions about the Whois service can be directed.
 
26.2 Domain Name Query
 
By default, any query is assumed to be a domain name unless a keyword is prepended to the query. If the domain exists, then registration is returned, including the following fields:
 
* Domain ROID
 
* Domain Name
 
* Domain U-label (if IDN)
 
* Creation Date
 
* Last Updated
 
* Expiration Date
 
* EPP status codes
 
* Registrant Contact Information
 
* Administrative Contact Information
 
* Technical Contact Information
 
* Billing Contact Information (if any)
 
* Sponsoring Registrar ID
 
* Sponsoring Registrar Contact Information
 
* DNS servers (if any)
 
* DNSSEC records (if any)
 
The Domain ROID is the Repository Object Identifier as described in RFC 5730, S2.8. The ROID field corresponds to the <domain:roid> element of EPP <info> responses.
 
A domain may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP mnemonics. A domain may have any of the following status codes:
 
* pendingCreate - a <domain:create> command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
 
* addPeriod - the domain is in the Add Grace Period
 
* clientHold - the registrar has requested that the domain be temporarily removed from the DNS
 
* clientdeleteProhibited - the registry will refuse any attempt by the registrar to delete the name unless the registrar removes this status first
 
* serverDeleteProhibited - the registry will refuse any attempt by the registrar to delete the name
 
* inactive - the domain has no DNS servers
 
* pendingDelete - the domain has left the Redemption Grace Period and is scheduled for deletion
 
* pendingDeleteRestorable - the domain is in the Redemption Grace Period
 
* pendingRestore - a restore request has been received, but the Restore Report has not been received
 
* pendingTransfer - there is an active inter-registrar transfer for the domain
 
* renewProhibited - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
 
* clientRenewProhibited - the registry will refuse any attempt by the registrar to renew the name unless the registrar removes this status first
 
* serverRenewProhibited - the registry will refuse any attempt by the registrar to renew the name
 
* serverHold - the registry has removed the domain from the DNS
 
* transferPeriod - the domain is in the Transfer Grace Period
 
* clientTransferProhibited - the registry will refuse any attempt by another registrar to transfer the name unless the sponsoring registrar removes this status first
 
* serverTransferProhibited - the registry will refuse any attempt to transfer the name
 
* clientUpdateProhibited - the registry will refuse any attempt by the registrar to update the name unless the sponsoring registrar removes this status first (or includes removal of this status as part of the update)
 
* serverUpdateProhibited - the registry will refuse any attempt by the registrar to update the name
 
* OK - present if none of the above apply.
 
The Registrant, Administrative, Technical and Billing Contact sections of the Whois record display the contact information for the contact objects that are associated with the domain. The information displayed replicates the information showed for a contact query (see below). The server shows similar information for the sponsoring registrar.
 
Domains may have 0-13 DNS servers. If a domain name has no DNS servers, then the "INACTIVE" status code appears in the Status section. If the registrant provided DS records for their DNSSEC-signed domain, then these are included. For each DS record, then the key tag, algorithm, digest type and digest are displayed.
 
An example of a domain query response is included in Appendix 26.1.
 
26.3 Contact Query
 
Users can query for information about a contact by submitting a query of the form "contact [ID]", where "[ID]" is the contact ID equivalent to the <contact:id> element in EPP <info> responses. This is also the ID used when referring to contacts in domain responses.
 
The following information is included in Dontact records:
 
* Contact ID
 
* Sponsoring Registrar
 
* Creation Date
 
* Last Updated Date
 
* EPP Status Codes
 
* Contact Name
 
* Organisation
 
* Street Address (1-3 fields)
 
* City
 
* State/Province
 
* Postcode
 
* Country Code (2 character ISO-3166 code)
 
* Phone number (e164a format)
 
* Fax number (e164a format)
 
* Email address
 
A contact object may be associated with one or more status codes. These are represented in Whois responses as phrases rather than EPP code mnemonics. A contact object may have any of the following status codes:
 
* DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
 
* TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
 
* UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
 
* PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
 
* LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status
 
An example of a contact query response is included in Appendix 26.2.
 
26.4 Host Object Query
 
Users can query for information about a host object by submitting a query of the form "nameserver [HOST]". The following information is included in host records:
 
* Server Name
 
* IPv4 address (if any)
 
* IPv6 address (if any)
 
* EPP status codes
 
* Sponsoring Registrar
 
* Creation Date
 
* Referral URL (if any)
 
Host objects may only have two status codes:
 
* INACTIVE - the host is not associated with any domain names
 
* LINKED - the host is associated with one or more domain names
 
The Referral URL is the website of the Sponsoring Registrar for this host. If the host is subordinate to a domain name in .TICKETS, this will be the sponsoring registrar of the parent name. If the host is out-of-bailiwick, then the sponsoring registrar is the registrar who issued the original <create> request.
 
An example of a host query response is included in Appendix 26.3.
 
26.5 Character Encoding
 
Responses are encoded as UTF-8. Queries are assumed to be encoded in UTF-8.
 
26.6 IDN Support
 
The Whois service supports Internationalised Domain Names. Users may submit queries for IDN domains using either the U-label or the A-label.
 
26.7 Bulk Access
 
CentralNic will provide up-to-date registration data to ICANN on a weekly basis (the day to be designated by ICANN). CentralNic will provide the following data for all registered domain names: domain name, repository object id (roid), registrar id (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars it will provide: registrar name, registrar repository object id (roid), hostname of registrar Whois server, and URL of registrar. Data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the above.
 
At ICANN's request, CentralNic will provide ICANN with up-to-date data for the domain names of de-accredited registrar to facilitate a bulk transfer. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. CentralNic will provide the data within 2 business days.
 
26.8 Load Projections
 
As described in S31, CentralNic's existing Whois system receives an average of 0.36 queries per day for each domain name in the registry, including misses for non-existent objects as well as hits.
 
CentralNic believes that the query rate observed for its own registry system is mainly affected by its efforts to deter abuse, and outreach to registrars, who often use whois to perform availability checks, to encourage them to EPP instead. CentralNic believes this query rate will also apply for .TICKETS. A projection of query load for the Whois system for the first 24 months of operation can be found in Appendix 26.4. This model also includes data transit rates and bandwidth projections for the same period. As can be seen, the data and bandwidth requirements are relatively small compared to those for the Shared Registry System and authoritative DNS.
 
26.9 Technical Implementation
 
Queries pass through the firewalls to front-end application servers. Round-robin DNS distributes queries between the devices. Application servers are configured in High Availability mode so that if one a server fails, another will resume service on its IP address until the server can be restored. The service can be scaled by adding new application servers.
 
26.9.1 Application Server Architecture
 
Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whoisng Apache module (see http://gitlab.centralnic.com/centralnic/mod_whoisng) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.
 
26.9.2 Caching
 
Application servers use caching to reduce database load. Subsequent identical queries are returned a cached record until the cache expires, after which a new record is generated. Records are currently cached for 600 seconds (ten minutes), so if a domain is updated immediately after its Whois record has been cached, the updated record will be visible after ten minutes. This compares favourably to the 60 minute requirement in the gTLD Service Level Agreement. Records are cached in a shared Memached server. Memcached is a high-performance caching server used by some of the largest sites in the world, including Wikipedia, Flickr, Wordpress.com and Craigslist.
 
26.9.3 Database
 
The Whois service draws data from a local replica of the primary database. Data is replicated from the primary database to the replica using MariaDB's native asynchronous replication. Replication delay is typically below one second. The local database server is also used to aggregate log data for use with the rate limiting system.
 
26.9.4 Web based Whois Service
 
The web Whois acts as a proxy to the port 43 Whois service: users enter a query into a form, and a server-side process submits the query to the Whois server, and displays the response. This service will not be subjected to rate, but users will be required to complete a CAPTCHA to prevent high-volume automated access.
 
26.9.5 Searchable Whois Service
 
The Searchable Whois Service (SWS) provides third parties with a search interface that allows queries for partial matches against a number of domain name properties, including:
 
* Domain name (partial match)
 
* Registrant name, organisation, address, email
 
* Administrative, technical and billing contact information
 
* Nameservers
 
* Nameserver IPv4/IPv6 address
 
Access to the SWS is restricted. Users must submit an account request via the website, and agree to the terms and conditions which governs their access to the the system. Once their request has been reviewed and approved, they are issued with credentials which permit them to login to the SWS.
 
To prevent abuse of the SWS, users may only make fifty queries per day initially. This limit can be increased upon request and demonstration of legitimate need.
 
26.9.6 Anti-Abuse Mechanisms
 
CentralNic has implemented measures to mitigate the threat of abuse of the Whois service. The primary threat to the Whois service are so-called "dictionary" attacks, where an attacker attempts to enumerate the database by flooding the server with queries for domains taken from a precompiled list: as zone files are easy to obtain, this presents a threat to the privacy of contact information in the registry database. The information harvested can be used to compile email databases for spamming, or to send domain renewal scam letters, for example.
 
The Whois service implements rate-limiting to impede dictionary attacks. For each query, a counter associated with the client IP address is incremented. For subsequent queries, this counter determines the number of queries received within the previous hour. If the number of queries exceeds a pre-set maximum (currently 240 queries per hour), then the server returns an error, warning the user that they have exceeded the permitted query rate. If the user stops sending queries, then eventually the query rate will drop below the limit, and subsequent queries will be permitted. If the user continues to send queries, and the query rate exceeds the limit by a further 25% (300 queries per hour), then the IP address is permanently blocked. For queries over IPv6 (where an attacker might have access to billions of IP addresses), the enclosing /48 will be blocked.
 
Experience indicates that is an effective mechanism for preventing abuse of the Whois. The rate limit has been tuned to ensure that legitimate uses of the Whois are allowed, but abusive use of the whois is restricted to levels that are unappealing for attackers.
 
CentralNic keeps a "white list" of IP addresses used by legitimate users of the Whois service, including law enforcement agencies and other research and anti-abuse entities. Registrar access lists are also incorporated into the white list, and IP addresses registered on ICANN's RADAR system will also be included. Queries from IP addresses that appear on the white list are not rate-limited. Interested parties can request addition to the white list by contacting CentralNic's public customer service team.
 
The web-based Whois does not implement rate-limiting, but users of this service must complete a CAPTCHA to access Whois records.
 
26.9.6.1 Denial-of-Service attacks
 
The rate-limiting system in place provides protection against DoS and DDoS attacks, as any host that attempts to flood the Whois service with queries will be quickly blocked. However, a DDoS attack could still saturate upstream links requiring filtering at the edges of CentralNic's network, as well as their upstream providers. Continuous surveillance and monitoring of the Whois system proactively detects these threats. As the Whois service uses local replicas of the primary SRS database, attacks against the Whois service cannot affect the rest of the SRS.
 
26.9.7 Monitoring and Logging
 
Remote monitoring is used to verify the availability of the service and to record the round-trip times for different queries (warm hit, warm miss). Local monitoring records query volumes.
 
26.10 Resourcing
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


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

Except where specified this answer refers to the operations of Accent Media's outsource Registry Service Provider, CentralNic.
 
The lifecycle of a domain in the registry is described in Figure 27.1, and closely follows that of domain names in existing gTLD registries. The lifecycle is described below.
 
27.1 Available
 
The domain is not registered. No delegation (or any other records) exist in the DNS, and the whois system will return a "NOT FOUND" response to queries. An EPP <check> command will return an "avail" status of 1.
 
27.2 Registered
 
A registar submits an EPP <create> command or registers the domain name via the Registrar Console. The registration fee is deducted from the registrar's balance. The initial registration period may be any whole number of years between one (1) and ten (10).
 
For five (5) calendar days after the registration of the domain, the registrar can delete the domain and receive a credit for the registration fee (subject to the Add Grace Period Limits Policy).
 
While the domain is registered, it is delegated to the specified name servers and will resolve normally. During this time, the registrar may update the domain name's DNS settings, lock statuses and contact associations, and may extend the registration period (subject to a maximum of ten (10) years) by submitting a <renew> EPP command or using the Registrar Console.
 
The domain may also be transferred to a different sponsoring registrar. Upon such transfer the domain name is automatically renewed for one year.
 
27.3 Expired
 
When the expiry date is reached, the domain name is automatically renewed for a period of one year, and the renewal fee is deducted from the registrar's account.
 
For forty-five (45) days after the auto-renewal (Auto-Renew Grace Period), the registrar can delete the domain and receive a credit for the renewal fee.
 
27.4 Redemption Grace Period
 
Should the registrar delete the domain, the domain enters the Redemption Grace Period. During this period, the domain name will no longer resolve as all delegation information is removed from .TICKETS zone.
 
For the first thirty (30) days after receipt of the delete request, the domain is in the "Pending Delete Restorable" state. During this time, the registrar may submit an RGP restore request via EPP or the Registrar Console. The domain is then placed into the "Pending Restore" state.
 
The registrar must then submit an RGP Restore Report detailing the reason why the restore request has been submitted. If the Restore Report is received within five (5) calendar days of the original restore request, then the domain is restored. However, if the Restore Report is not received within this period, then the domain falls back into the "Pending Delete Restorable" state.
 
27.4.1 Redemption Period State Diagram
 
Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.
 
27.5 Pending Delete
 
Forty (40) days after the receipt of the delete request, the domain leaves the "Pending Delete Restorable" and enters the "Pending Delete" status. The registrar cannot submit a Restore Request during this period.
 
27.6 Released
 
Five (5) days after the domain enters the "Pending Delete" status the domain name is purged from the database and is once again available for registration.
 
27.7 Other Grace Periods
 
The registry also implements the following grace periods. In general, these grace periods allow registrars to delete domain names following billable transactions and receive a refund.
 
27.7.1 Add Grace Period
 
As described above, the Add Grace Period (AGP) is the five (5) calendar days following the initial registration of the domain.
 
27.7.2 Auto-renew Grace Period
 
As described above, the Auto-renew Grace Period is the forty five (45) calendar days following the auto-renewal of the domain.
 
27.7.3 Renew Grace Period
 
The Renew Grace Period is the five (5) calendar days following the renewal of the domain via an EPP <renew> command, or via the Registrar Console.
 
27.7.4 Transfer Grace Period
 
The Transfer Grace Period is the five (5) calendar days following the successful completion of an inter-registrar transfer.
 
27.8 Hold Periods
 
The registry implements the following hold periods:
 
27.8.1 Registration Hold Period
 
The Registration Hold Period forbids inter-registrar transfers of domain names within sixty (60) days of initial registration.
 
27.8.2 Transfer Hold Period
 
The Transfer Hold Period forbids transfers of domain names within sixty (60) days of a previous inter-registrar transfer. This Hold Period does not affect disputed transfers that are undone by the registry following the outcome of a Transfer Dispute Resolution process.
 
27.9 Lock Statuses
 
The registry system permits the following lock statuses for domain names:
 
27.9.1 clientHold
 
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. Domains with this status are removed from the DNS and will not resolve.
 
27.9.2 clientDeleteProhibited
 
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can delete the domain.
 
27.9.3 clientRenewProhibited
 
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation). Registrars must remove the code using an EPP <update> command before they can renew the domain.
 
27.9.4 clientUpdateProhibited
 
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation), unless the <update> request frame includes a <rem> element to remove this status. Once the status has been removed, subsequent <update> commands will succeed.
 
27.9.5 clientTransferProhibited
 
This status may be set by registrars using an EPP <update> command, or via the Registrar Console. When set, all attempts by other registrars to submit a transfer request for the the domain using an EPP <transfer> command, or via the Registrar Console, will be refused with EPP response code 2304 (Status Prohibits Operation). The sponsoring registrar must remove this status before any other registrar can submit a transfer request.
 
27.9.6 serverHold
 
This status is set by the registry in accordance with policy. It cannot be removed by registrars. Domains with this status are removed from the DNS and will not resolve.
 
27.9.7 serverDeleteProhibited
 
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to delete the domain using an EPP <delete> command will be refused with EPP response code 2304 (Status Prohibits Operation).
 
27.9.8 serverUpdateProhibited
 
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to update the domain using an EPP <update> command will be refused with EPP response code 2304 (Status Prohibits Operation).
 
27.9.9 serverRenewProhibited
 
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to renew the domain using an EPP <renew> command will be refused with EPP response code 2304 (Status Prohibits Operation).
 
27.9.10 serverTransferProhibited
 
This status is set by the registry in accordance with policy. It cannot be removed by registrars. When set, all attempts by the registrar to transfer the domain using an EPP <transfer> command will be refused with EPP response code 2304 (Status Prohibits Operation).
 
27.10 Lifecycle Processing
 
Domain names move through the lifecycle in one of two ways: in real-time as a result of registrar activity, or during daily billing runs.
 
Billing runs take place once per day. The billing run performs the following batch jobs:
 
* auto-renewal of expired domains
 
* processing of registration and renewal fees for domains that move outside their grace periods
 
* processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
 
* purging of domains scheduled for deletion
 
The billing runs also perform registrar account management functions such as generation of invoices, sending balance warnings, and generation of internal reports.
 
27.11 Inter-Registrar Transfer Period
 
When a transfer request is received, the action date of the transfer is set to five (5) calendar days from the moment of the original request. Successful transfers are approved at the end of this period.
 
27.12 pendingCreate Status
 
The Registry system supports the "pendingCreate" status for domain names, as described in RFC 5731, S3.3. Domains in this state are fully registered in the database (subsequent <create> commands would fail with an Object Exists error) but are not present in the DNS.
 
This status is used when a particular TLD implements a policy whereby registration requests are verified by a third party such as a Sponsoring Organisation or Validation Agent. Following out-of-band review of the request, the registration may be approved or denied.
 
If a request is denied, then the domain is immediately purged from the registry system, and the registrar notified via email and the EPP message queue. The registrar also receives a credit for the registration fee. If approved, then the pendingCreate status is removed from the domain which begins to resolve.
 
27.13 Resourcing
 
The domain registration lifecycle is managed through automated backend processes that generally require no human intervention, and real-time business logic implemented in Shared Registry System application code. Operations personnel will be responsible for maintaining and developing the computing infrastructure which supports the lifecycle processing systems. Backend systems are hosted on a flexible virtual infrastructure hosted at the primary operations centre at the Goswell Road Data Centre in London.
 
The domain registration lifecycle does have customer and registrar support requirements, so a proportion of the time of the Operations Manager, Support Manager and Support Agent has been dedicated to this area. This time primarily relates to dealing with questions and comments from registrars and registrants about the status of their domain names.
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


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

Accent Media, working with CentralNic, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of .tickets. The specific measures include, but are not limited to:
 
* Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
* Committing to rapid identification and resolution of abuse, including suspensions;
* Ensuring completeness of WHOIS information at the time of registration;
* Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;
* Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.
 
ABUSE POLICY
The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.
 
The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.
 
Repeat violations of the abuse policy will result in a case-by-case review of the abuser(s), and the registry operator reserves the right to escalate the issue, with the intent of levying sanctions that are allowed under the TLD anti-abuse policy.
 
The below policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool.
 
.TICKETS Anti-Abuse Policy
The following Anti-Abuse Policy is effective upon launch of .tickets. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:
 
* Illegal or fraudulent actions;
* Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums;
* Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
* Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
* Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the owner's informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses.
* Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.
* Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or "zombies," or to direct distributed denial-of-service attacks (DDoS attacks);
* Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individual's system (often known as "hacking"). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).
 
Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.
 
The policy stated above will be accompanied by notes about how to submit a report to the registry operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).
 
ABUSE POINT OF CONTACT AND PROCEDURES FOR HANDLING ABUSE COMPLAINTS
The registry operator will establish an abuse point of contact.  This contact will be a role-based e-mail address of the form “abuse@registry.tickets”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. For tracking purposes, the registry operator will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. CentralNic will integrate its existing ticketing system with the registry operator’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.
 
The registry operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate.
 
In general, the registry operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.
 
The security function includes a communication and outreach function, with information sharing with industry partners regarding malicious or abusive behavior, in order to ensure coordinated abuse mitigation across multiple TLDs.
 
Assessing abuse reports requires great care, and the registry operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.
 
Different types of malicious activities require different methods of investigation and documentation. Further, the registry operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.
 
In general, there are two types of domain abuse that must be addressed:
a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised.  The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.
 
b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.
 
The standard procedure is that the registry operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this.  The registrar is the party with a direct relationship with - and a direct contract with - the registrant. The registrar will also have vital information that the registry operator will not, such as:
* Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
* The identity of a proxy-protected registrant;
* The purchaser’s IP address;
* Whether there is a reseller involved, and;
* The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).
 
Registrars do not share the above information with registry operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.
 
If a registrar does not take action within a time period indicated by the registry operator (usually 24 hours), the registry operator might then decide to take action itself. At all times, the registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.
 
The registry operator will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where the registry operator will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which the registry operator, although the operator in all cases will adhere to applicable laws and regulations.
 
When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:
* Registration information
* History of a domain, including recent updates made
* Other domains associated with a registrant’s account
* Patterns of registrant portfolio
 
Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. CentralNic sets a goal to respond to such requests within 24 hours.
 
The registry operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The registry operator could take advantage of a combination of the following resources, among others:
* Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus.
* Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.
* Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.]
The registry operator will keep records and track metrics regarding abuse and abuse reports. These will include:
* Number of abuse reports received by the registry’s abuse point of contact described above;
* Number of cases and domains referred to registrars for resolution;
* Number of cases and domains where the registry took direct action;
* Resolution times;
* Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;
* Phishing site uptimes in the TLD.
 
CentralNic's registry system includes effective measures to prevent the abuse of orphan glue records.
 
Firstly, the Shared Registry System will reject any request to create host object that is the child of a non-existent domain name. That is, if EXAMPLE.TLD does not exist, then NS0.EXAMPLE.TLD cannot be created. If the parent domain name does exist, then only the sponsoring registrar of that domain is permitted to create child host objects.
 
CentralNic's registry system currently follows the third model described in the SAC 048 report: orphan glue records are deleted from the registry and removed from the DNS when the parent domain name is deleted. If other domains in the database are delegated to orphan hosts that are removed, then the delegation is also removed from these domains.
 
METHODS TO PROMOTE WHOIS ACCURACY
 
Accent Media will operate a "thick" WHOIS system, in which all registrants' contact information will be stored in a single database maintained by the registry. Accredited registrars will have the ability to change the records in that database through the Shared Registration System. The Registry-Registrar agreement requires registrars to ensure that the WHOIS data is accurate at the time of submission and also requires the information provided on the system to be updated in a timely manner in case of any changes. Corresponding provisions also exist in the Registrar Accreditation Agreement (RAA), para. 3.7.7.
 
In addition to the standard measures described above, the Whois system will feature extra levels of reliability with regards to Whois information.
 
- Extra checks on WHOIS data
 
Accent Media, through its Registry-Registrar agreements, will require registrars to perform the following additional checks on the WHOIS data:
 
* Verify syntactic correctness of email addresses and phone numbers by validating them against the corresponding standards
 
* Verify that the domain holder receives email at the addresses listed in WHOIS as registrant's email address and administrative contact email address, by requiring them to click a unique web link that is sent to those addresses.
 
- Random audits of WHOIS records by the Registry
 
Accent Media will periodically (at least once every 12 months) perform a random check of WHOIS records for prima facie evidence of fraudulent or inaccurate WHOIS information. For those suspicious records that may be found, Accent Media will further require registrars to conduct a reasonable investigation and to respond with one of the three possible actions:
 
* confirm that the information provided in WHOIS is accurate, or
 
* correct the WHOIS information, or
 
* delete the domain name(s).
 
The measures described above exceed the ICANN requirements and are adequate to improve accuracy of WHOIS information while maintaining low implementation cost for registrars and good user experience for registrants.
 
REGISTRANT PRE-VERIFICATION AND AUTHENTICATION
 
One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).
 
Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.
* Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.
* Based on required WHOIS Data; registrant contact details (name, address, phone)
* If address/ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)
* If in-line processing and registration and EPP/API call would go to the verification clearinghouse and return up to 4 challenge questions.
* If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant.
* If WHOIS data is validated a token would be generated and could be given back to the registrar which registered the domain.
* WHOIS data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.
* A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers.
* Validation would be annually renewed, and validation date displayed in the WHOIS.
 
ABUSE PREVENTION RESOURCING PLANS
 
Accent Media and CentralNic will provide abuse response on a 24x7 basis. The resourcing to fulfill this function will be provided by a combined team of support and operations personnel. The first response function will be provided by support agents during normal office hours, with this responsibility being passed to the Network Operations Centre(NOC) during 24x7 operations.
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


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

We recognise that rights protection is a core responsibility of the TLD operator, and will be supported by a fully-developed plan for rights protection that includes:
 
- Establishing mechanisms to prevent unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies);
 
- Implementing a robust Sunrise program, utilizing the Trademark Clearinghouse, the services of one of ICANN’s approved dispute resolution providers, a trademark validation agent, and drawing upon sunrise policies and rules used successfully in previous gTLD launches;
 
- Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
 
- Complying with the URS requirements;
 
- Complying with the UDRP;
 
- Complying with the PDDRP, and;
 
- Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.
 
The response below details the rights protection mechanisms that shall be in place at the launch of the TLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, PDDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans.
 
 
Safeguards from right protection at the launch of .TICKETS:
The launch of this TLD will include the operation of a trademark claims service according to the defined ICANN processes for checking a registration request and alerting trademark holders of potential rights infringement.
 
The Sunrise Period will be an exclusive period of time, prior to the opening of public registration, when eligible trade mark and service mark holders will be able to reserve marks that are an identical match in the .TICKETS domain. Applicants in the Sunrise and Landrush will need to meet the eligibility criterias for .TICKETS. Following the Sunrise Period, Accent Media will open registration to eligible applicants.
 
The anticipated Rollout Schedule for the Sunrise Period will be approximately as follows:
 
- Launch of the TLD – Sunrise Period begins for trademark holders and service mark holders to submit registrations for their exact marks in the .TICKETS domain. All registrations in the Sunrise Period will be checked and validated by an ICANN approved Trademark Clearinghouse. In the case of multiple registrants applying for the same string there will be an auction between the applying Registrants. It will be possible to withdraw from the auction for Registrants who choose to not participate.
 
- Sunrise period will be 60 days. The Sunrise Period will be followed by a 30 day Quiet Period for testing and evaluation. After the 30 day Quiet Period a 15 day Landrush Period will be initiated followed by a 15 day Quiet Period and then .TICKETS will open to normal registrations.
 
In summary:
 
* Two months after launch –The Sunrise Period will close and will be followed by a one month Quiet Period for testing and evaluation.
 
* A 15 day Landrush Period and a 15 day Quiet Period will follow the Sunrise Period and the following Quiet Period.
 
* Four months after launch – .TICKETS domain will be live and resolving and registration in the .TICKETS domain will be open to qualified applicants on “first come - first serve” basis.
 
Sunrise Period Requirements & Restrictions:
 
Those wishing to reserve their marks in the .TICKETS namespace during the Sunrise Period must own a current trademark or service mark listed in the Trademark Clearinghouse.
 
Notice will be provided to all trademark holders in the Clearinghouse if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an Identical Match (as defined in the Trademark Clearinghouse) to the name to be registered during Sunrise.
 
Each Sunrise registration will require a minimum term of two years.
 
Accent Media will establish the following Sunrise eligibility requirements (SERs) as minimum requirements, verified by Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP). The SERs include: (i) ownership of a mark that satisfies the criteria set forth in section 7.2 of the Trademark Clearinghouse specifications, (ii) description of international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.
 
The SDRP will allow challenges based on the following four grounds: (i) at time the challenged domain name was registered, the registrants did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.
 
Ongoing rights protection mechanisms:
 
Several mechanisms will be in place to protect rights in the .TICKETS domain space. As described in our responses to questions #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and an experienced team is available to respond to legal actions by law enforcement or court orders.
 
This TLD will conform to all ICANN RPMs including URS (defined below), UDRP, PDDRP, and all measures defined in Specification 7 of the new TLD agreement.
 
Uniform Rapid Suspension (URS):
 
The Registry will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site as of writing, the Registry will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the Registry operator’s support staff, which is on duty 24/7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.
 
As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the registry operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
 
*  ServerUpdateProhibited, with an EPP reason code of “URS”.
 
*  ServerDeleteProhibited, with an EPP reason code of “URS”
 
*  ServerTransferProhibited, with an EPP reason code of “URS”
 
*  The Registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email.
 
The Registry operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.
 
The Registry operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.
 
As per the URS guidelines, if the complainant prevails, the Registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”
 
Rights protection via the RRA:
 
The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant Agreements:
 
*  The Registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:
 
a. to enforce Registry policies and ICANN requirements; each as amended from time to time;
 
b. that is not accompanied by complete and accurate information as required by ICANN requirements and/or Registry policies or where required information is not updated and/or corrected as required by ICANN requirements and/or Registry policies;
 
c. to protect the integrity and stability of the Registry, its operations, and the TLD system;
 
d. to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
 
e. to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and/or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
 
f. to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
 
g. as otherwise provided in the Registry-Registrar Agreement and/or the Registrar-Registrant Agreement.
 
Reducing opportunities for behaviours such as phishing or pharming:
 
In our response to #28, the Registry operator has described its anti-abuse program. Rather than repeating the policies and procedures here, please see our response to #28 for full details.
 
With specific respect to phishing and pharming, it should be noted by ICANN that this will be a single entity TLD in which .TICKETS has direct control over each registrant (they are typically on staff or otherwise contractually bound) and how each registration may be used. Further, there will be no open registration period for this TLD, as it will never be an “open” TLD. Since all criminal activity (such as phishing and pharming) is precluded by the mission, values and policies of the registry operator (and its parent organization), criminal activity is not expected to be a problem. If such activity occurs due to hacking or other compromises, the registry operator will take prompt and effective steps to eliminate the activity.
 
In the case of this TLD, .TICKETS will apply an approach that addresses registered domain names (rather than potentially registered domains). This approach will not infringe upon the rights of eligible registrants to register domains, and allows .TICKETS internal controls, as well as community-developed UDRP and URS policies and procedures if needed, to deal with complaints, should there be any.
 
CentralNic is a member of various security fora which provide access to lists of names in each TLD which may be used for malicious purposes.  Such identified names will be subject to the TLD anti-abuse policy, including rapid suspensions after due process.
 
Rights protection resourcing plans:
 
The Rights Protection Mechanisms described above include a combination of both technical and non-technical systems: for example, the Trademark Claims Service may (depending on the final specification published by ICANN) require development, maintenance and support of an EPP extension, as well as real-time integration with the TMCH API, whereas the UDRP is a primarily manual process of managing and responding to communications from complaints, respondents and UDRP service providers.
 
As can be seen in the Resourcing Matrix found in Appendix 23.2, CentralNic maintains a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to more than one full-time post.
 
CentralNic operates a shared registry environment where multiple registry zones (such as CentralNic's domains, the .LA and .PW ccTLDs, .TICKETS and other gTLDs) share a common infrastructure and resources. Since .TICKETS will be operated in an identical manner to these other registries, and on the same infrastructure, then .TICKETS will benefit from an economy of scale with regards to access to CentralNic's resources.
 
CentralNic's resourcing model assumes that the "dedicated" resourcing required for .TICKETS (ie, that required to deal with issues related specifically to .TICKETS and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that .TICKETS will use. After three years of operation, the optimistic projection for .TICKETS states that there will be 10,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to over 4.5 million domain names. Therefore .TICKETS will require 0.22% of the total resources available for this area of the registry system.
 
In the event that registration volumes exceed this figure, CentralNic will proactively increase the size of the Technical Operations, Technical Development and support teams to ensure that the needs of .TICKETS are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of .TICKETS for at least the first 18 months of operation.
 


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

 
Except where specified this answer refers to the operations of Accent Media's outsource Registry Service Provider, CentralNic.
 
CentralNic's Information Security Management System (ISMS) has been certified against ISO/EIC 27001:2005. A copy of the certificate issued by Lloyd's Register Quality Assurance (LRQA), a UKAS accredited certifier, is provided as Appendix 30.1. The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001.
 
30.1.1 Independent Assessment
 
As part of ISO 27001 compliance, CentralNic's security policies are subject to biannual external audit. Further details can be found in S30(b).
 
30.1.2 Augmented Security Levels
 
Accent Media believes that .TICKETS requires no additional security levels above those expected of any gTLD registry operator. Nevertheless, Accent Media and CentralNic will operate .TICKETS to a high level of security and stability in keeping with its status as a component of critical Internet infrastructure.
 
Registry systems are hardened against attack from external and internal threats. Access controls are in place and all systems are monitored and audited to mitigate the risk of unauthorised access, distribution or modification of sensitive data assets. The Authoritative DNS System has been designed to meet the threat of Distributed Denial-of-Service (DDoS) attacks by means of over-provisioning of network bandwidth, and deployment of Shared Unicast ("Anycast") addresses on nameservers. Whois services have been designed with built-in rate limiting and include mechanisms for protection of personal information. The stability of the registry is supported by use of high-availability technologies including a "hot" Disaster Recovery site in the Isle of Man, as well as a backup provider relationship with GMO Registry in Japan.
 
30.1.3 Commitments to Registrars
 
Accent Media and CentralNic will make the following commitments to .TICKETS registrars:
 
* The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
 
* The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
 
* The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.
 
* The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in S43).
 
* Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
 
* Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
 
* Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop.
 
30.1.4 Access Controls
 
CentralNic operates an access control policy for the registry system. For example, the web-based Staff Console which is used to administer the SRS and manage registrar accounts supports a total of ten different access levels, ranging from "Trainee", who have read-only access to a subset of features, to "System Administrator" who have full access to all systems.
 
Underlying server and network infrastructure is also subjected to access control. A centralised configuration manager is used to centrally control access to servers. Individual user accounts are created, managed and deleted via the configuration server. Access to servers is authenticated by means of SSH keys: only authorised keys may be used to access servers. Operations personnel can escalate privileges to perform administration tasks (such as updating software or restarting daemons) using the "sudo" command which is logged and audited as described below.
 
Only operations personnel have access to production environments. Development personnel are restricted to development, staging and OT&E environments.
 
30.1.5 Security Enforcement
 
Security controls are continually monitored to ensure that they are enforced. Monitoring includes use of intrusion detection systems on firewalls and application servers. Attempted breaches of access controls (for example, port scans or web application vulnerability scans) trigger NOC alerts and may result in the execution of the Security Incident Response Policy (see below).
 
Since CentralNic operates a centralised logging and monitoring system (see S42), access logs are analysed in order to generate access reports which are then reviewed by NOC personnel. This includes access to servers via SSH, to web-based administration systems, and to security and networking equipment. Unexpected access to systems is investigated with a view to correcting any breaches and/or revoking access where appropriate.
 
30.1.6 Security Incident Response Policy
 
CentralNic operates a Security Incident Response Policy which applies to all events and incidents as defined by the policy, and to all computer systems and networks operated by CentralNic.
 
The Policy provides a mechanism by which security events and incidents are defined (as observable change to the normal behaviour of a system attributable to a human root cause). It also defines the conditions under which an incident may be defined as escalated (when events affect critical production systems or requires that implementation of a resolution that must follow a change control process) and emergencies (when events impact the health or safety of human beings, breach primary controls of critical systems, or prevent activities which protect or may affect the health or safety of individuals).
 
The Policy established an Incident Response Team which regularly reviews status reports and authorises specific remedies. The IST conduct an investigation which seeks to determine the human perpetrator who is the root cause for the incident. Very few incidents will warrant or require an investigation. However, investigation resources like forensic tools, dirty networks, quarantine networks and consultation with law enforcement may be useful for the effective and rapid resolution of an emergency incident.
 
The Policy makes use of CentralNic's existing support ticketing and bug tracking systems to provide a unique ID for the event, and means by which the incident may be escalated, information may be reported, change control processes put into effect, and ultimately resolved. The Policy also describes the process by which an incident is escalated to invoke an Emergency Response, which involves Lock-Down and Repair processes, monitoring and capturing of data for forensic analysis, and liaison with emergency services and law enforcement as necessary.
 
30.1.7 Role of the Network Operations Centre (NOC)
 
In addition to its role in managing and operating CentralNic's infrastructure, the NOC plays a key role in managing security. The NOC responds to any and all security incidents, such as vulnerability reports received from registrars, clients and other stakeholders; monitoring operator and security mailing lists (such as the DNS-OARC lists) to obtain intelligence about new security threats; responding to security-related software updates; and acting upon security alerts raised by firewall and intrusion detection systems.
 
30.1.8 Information Security Team
 
CentralNic maintains an Information Security Team (IST) to proactively manage information security. The IST is a cross-functional team from relevant areas of CentralNic. These key members of staff are responsible for cascading rules, regulations and information to their respective departments. They are also the first port of call for their departmental staff to report potential security incidences and breaches, the IST are all members of an internal email group used to co-ordinate and discuss security related issues.
 
The IST is comprised of the CEO, CTO, Operations Manager, Senior Operations Engineer and Security Engineer.
 
IST responsibilities include:
 
* Review and monitor information security threats and incidents.
 
* Approve initiatives and methodologies to enhance information security.
 
* Agree and review the security policy, objectives and responsibilities.
 
* Review client requirements concerning information security.
 
* Promote the visibility of business support for information security company-wide.
 
* Manage changes to 3rd party services that may impact on Information Security
 
* Perform internal audits with the assistance of Blackmores.
 
30.1.9 Auditing and Review
 
ISO 27001 includes processes for the auditing and review of security systems and policies. Audits are performed annually by an independent assessor. The IST periodically reviews the ISMS and conducts a gap analysis, identifying areas where performance does not comply with policy, and where the Risk Assessment has identified the need for further work.
 
30.1.10 Testing of Controls and Procedures
 
CentralNic will conduct bi-annual penetration tests of its registry systems to ensure that access controls are properly enforced and that no new vulnerabilities have been introduced to the system. Penetration tests will include both "black box" testing of public registry services such as Whois and the Registrar Console, "grey box" testing of authenticated services such as EPP, and tests of physical security at CentralNic's offices and facilities.
 
CentralNic will retain the services of a reputable security testing company such as SecureData (who, as MIS-CDS, performed the 2009 assessment of CentralNic's security stance). The results of this test will be used in annual reviews and audits of the ISMS.
 
30.1.11 Accent Media's Security Policy
 
Accent Media has physical security measures including locked offices manned by a separate reception area, visitor log, all visitors are required to wear badges, and any equipment or documents left in the office must be locked away in secure cabinets.
 
Accent Media uses best practices in computer security. All computers are required to have a lock screen protected by a password consisting of a minimum of 8 characters being a mixture of upper and lower case characters and numerals. Operating systems are required to be the latest version and scanned for viruses monthly by antivirus software that is kept up to date. Email and other accounts are managed centrally by a nominated IT account manager.
 
Network security is maintained through the use of firewalls and secure password-protected wifi. Data security is maintained through the use of remote cloud-based storage of files in password-protected zones. Data is encrypted using the AES-256 standard. Access to the cloud-based servers are maintained and monitored centrally using a corporate-level management tool which allows the IT administrator comprehensive audit logs to track what is being shared, and who by. Easy-to-use controls restrict access, while remote wipe secures data if a device is lost.
 
Accent Media is working with CentralNic and other security experts to enhance site and network security measures in addition to policy development, employee training, and enhanced physical, data and network security measures.
 



© Internet Corporation For Assigned Names and Numbers.