Application number: 1-1760-71167 for National Association of Real Estate Investment Trusts, Inc.

National Association of Real Estate Investment Trusts, Inc.

1875 I Street, NW
Suite 600
Washington DC 20006-5413
US

+12027399400

+12027399401

http:⁄⁄www.nareit.com⁄

Mr. Victor Dristas

Vice President, Operations

+12027399441

+12027399453

vdristas@nareit.com

Mr. Gavin Brown

Chief Technology Officer

+448700170900

+448700170901

tas-nareit-secondary@centralnic.com

NAREIT is a nonprofit corporation as determined by the United States Internal Revenue Service (IRS) pursuant to Section 501(c)(6) of the IRS Internal Revenue Code.

Please see the IRS website at http:⁄⁄www.irs.gov⁄charities⁄nonprofits⁄article⁄0,,id=96107,00.html for reference

Not Available

David J. Neithercut
Board Member
Debra A. Cafaro
Bord Member
Donald C. Wood
Chair
Edward J. Fritsch
Board Member
Jon E. Bortz
Board Member
Michael A. J. Farrell
Board Member
Michael D. Fascitelli
Treasurer
Richard B. Clark
Board Member
Richard J. Campo
Board Member
Rick R. Holley
Board Member
Robert S. Taubman
Board Member
Ronald L. Havner, Jr.
Second Vice Chair
Steven B. Tanger
Board Member
Thomas W. Toomey
Board Member
W. Edward Walter
First Vice Chair

Michael Grupe
EVP, Research & Investor Outreach
Sheldon M. Groner
EVP, Finance & Operations
Steve A. Wechsler
President and CEO
Tony Edwards
EVP& General Counsel

REIT

Not Available

The string consists of 4 ASCII characters, each one of which currently occurs as part of existing and operational gTLD strings. We are not aware of any possible rendering problems concerning the string ʺREITʺ
We are aware of the issue of universal acceptability and accept that some incorrectly configured third-party software may consider ʺREITʺ to be an invalid string, in the same way that other TLDs such as ʺ.INFOʺ and “.MUSEUMʺ are also at times considered ʺinvalid.ʺ Applicant will work to raise awareness of the issue of universal acceptance of .REIT and other new gTLDs. CentralNic has previously contributed to these efforts, such as by publication of TLD Verification code for the PHP programming language.
We are aware that a significant fraction of queries sent to the DNS root servers are for invalid TLDs such as ʺ.LOCALʺ or ʺ.LANʺ, and that the delegation of these TLDs could cause previously undiscovered configuration errors to result in operational problems for other operators. We have reviewed the research in this area, including the SAC 045 report from ICANNʹs Security and Stability Advisory Committee, data from the Day In The Life of the Internet project, and other sources, and are not aware of any significant volume of invalid root server queries related to .REIT. Therefore we feel confident that the delegation of this string will not result in any operation problems for Internet users. 

The National Association of Real Estate Investment Trusts (NAREIT) has chosen to apply for the .reit TLD on behalf of and for the benefit of the Real Estate Investment Trust (REIT) community worldwide. REITs are companies that own and most often actively manage income-producing commercial real estate; they were first established in the United States in 1960 and now exist throughout the world. Although the U.S. remains the largest market (in terms of market capitalization), REITs are becoming increasingly prominent throughout the world and other major markets include Australia, France, the UK, Japan, Singapore, Canada, the Netherlands, Hong Kong, and Malaysia to name just a few. 

The .reit TLD will provide a designated namespace and an online home for REITs worldwide – allowing REITs (regardless of what acronym they are known by in their home country) to register a .reit domain name corresponding to their registered or business name. The TLD will therefore allow REITs to obtain the most appropriate domain name possible as their web address in addition to assuring internet users that any domain name ending in .reit belongs to a genuine REIT. The namespace will communicate that any entity ⁄ organization which has registered a .reit domain name is legitimate, and will therefore promote ICANNʹs goals of consumer protection and promoting consumer trust in the new gTLD space. 

The .reit TLD will be a trusted zone, providing consumers and internet users with information about REITs in a safe, controlled, verified, and monitored environment – protecting the reputation of REITs and shielding internet users from non-genuine and unregulated “pseudo-REITs.” A stringent validation process will verify that only genuine members of the REIT community are able to register .reit domains, and, once registered, the domains will be monitored to ensure that any websites built conform to the strict, community-based use requirements. The domains will be held to strict security and stability standards and will operate on CentralNicʹs new TLD-compliant registry platform. 

The .reit TLD has been specifically designed to meet the requirements of the global REIT community while satisfying ICANNʹs goals of promoting innovation and increasing consumer choice and trust. The domain will provide REITs with the opportunity to register the shortest, most intuitive, and most descriptive domain name possible while certifying their online presence as a verified and legitimate REIT. 

The domain will simultaneously promote awareness of REITs to the public and educate the wider population about the nature of REITs. Internet users will automatically know that .reit websites represent genuine REITs, instilling faith in the REIT brand and the DNS and encouraging them to seek out information from these domains as a trusted point of contact and information. The domains will not only be verified and promote consumer trust and protection from an information perspective but will also do so from a technical view by operating at the highest levels of technical stability and security as required from the new gTLD program. 

REITs are becoming more and more common worldwide, and they are being introduced to new markets at a rapid rate. Since the development of REITs in the United States in 1960, REITs are now found in one form or another in 35 countries (as at September 2011), with many European and other REIT regimes coming into existence only within the last decade. As a result of the rapid introduction of these highly sophisticated and regulated products into new markets, it is crucial that both REITs and the public have access to the most appropriate domain names and accurate product information in order to maintain their success and stellar reputation as effective investment vehicles. The .reit TLD will provide both, and it is expertly positioned to grow in size and significance along with the REIT market. 

NAREIT has undertaken extensive outreach efforts to ensure our international counterparts are aware of our efforts to launch the .reit TLD and understand the benefits .reit domains will pose for members. NAREIT has been in touch with the following organizations: 
• The Association for Real Estate Securitization (ARES - Japan) 
• British Property Federation (BPF - UK) 
• European Public Real Estate Association (EPRA - Europe) 
• Property Council of Australia (PCA) 
• Real Property Association of Canada (REALpac) 
• Federation des Societes Immobilieres et Foncieres (FSIF - France) 

.reit will provide a reliable technical service for REITs, with an unprecedented level of technical security and stability meeting all new gTLD requirements. A battery of logging and monitoring tools will protect the TLD from attack and disruption – allowing REITs worldwide and internet users to be sure that the domains have complete, uninterrupted functionality and uncompromised content. 

ii. The .reit TLD will be the first TLD specifically designed to serve the needs of the global REIT community and will perform the dual purpose of supplying REITs with the most appropriate domain name for their corporate entity while providing the public with a filter to ensure they obtain genuine, accurate information about REITs. .reit will ensure that not only do the domains belong to genuine REITs, but also that information disseminated on the domains is legitimate and genuine. At this time, no other TLD provides equally significant levels of service for an industry association as well as for the general public, and NAREIT intends for the .reit domain to pave the way for innovation and differentiation in the new TLD space by ensuring that the .reit TLD becomes one of many trusted zones protecting registrants, rights holders, and internet users. 

NAREIT will engage with our international partners and colleagues to promote the .reit domain worldwide, ensuring community take-up and user awareness. Innovative domain registration and validation opportunities will be afforded by the .reit registration portal, which will allow .reit registrants to apply directly for their application and track and monitor the registration and validation process, providing an exceptional and unique customer service experience from pre-registration onward. 

.reit will provide a key service to the REIT community and the internet alike. REITs as entities are currently expanding and proliferating concurrent with severely decreased availability in the DNS (traditional zones); the existence of the .reit TLD in providing simple, navigable, and intuitive domain names to an increasingly significant and global product will prove crucial to the effective establishment of of REITsʹ internet presences as well as the ʺtidying upʺ of the DNS. 

iii. Only legitimate and validated REITs worldwide will be eligible to register a .reit domain name corresponding to their registered business name, and the TLD has been designed to host explanatory, helpful, and websites about specific REIT entities, providing information to the public and investors (potential and actual). The domain will serve as a badge of authentication for web content about REITs and will disseminate accurate information about REITs as they grow in significance and importance worldwide. As a result, the .reit TLD will serve as a navigable, predictable, and trusted internet zone, allowing web users to safely and securely obtain information about REITs worldwide. Web users will be able to visit any .reit domain secure in the knowledge that the REIT is recognized under jurisdictional law and the content posted complies with all regulations governing REITs. 

iv. The .reit TLD is open to registrations by legitimate REITs worldwide – regardless of the acronym by which they are known in their country of origin (SIIC, J-REIT, etc.). NAREIT will engage with partner and corresponding organizations worldwide to inform member REITs about the .reit opportunity and encourage them to register their domain names. A global, top-down outreach initiative will ensure that REITs are aware of the TLD and encourage them to register and make use of their .reit domain from availability onward. Although individual organizations may wish to adopt their own informative strategies corresponding specifically with their home markets’ preferences, the common denominator will remain providing detailed information about the benefits of .reit domain purchase both for REITs and also the public at large. 

Registrations at the second level must correspond directly to the registered name of the entity (or an acceptable abbreviation thereof) or the name by which it is known in business. This ensures that each REIT will be able to obtain the most appropriate domain name possible and will not have to settle for long, inappropriate, or difficult-to-remember generic or ccTLD domain names. This will be increasingly important as the size and scale of the REIT market worldwide continues to grow. 

Each REIT may register only one domain corresponding to the business name; this criterion is an important safeguard against the excessive proliferation of domains within the .reit zone and the dissemination of non-objective content by third parties seeking to register commercial domains such as info.reit, about.reit, invest.reit, etc. which could potentially give unfair competitive advantage over other .reit domains and thus other REITs. NAREIT believes that no third party entity should be able to register these domains as they would open the door for subjective commercial websites detrimental to the globally accommodating nature of the TLD and contradicting the cultivation of a trusted internet zone. 

NAREIT will require potential applicants to submit certain criteria in order to verify that not only is the applicant a valid REIT but also one in good financial standing. This criteria will protect not only the integrity of the .reit TLD but also ensure internet users are only exposed to information from legitimate and verified REITs. 

A complete list of the criteria required to register a .reit domain name is available in the answer to question 20 of this application. 

The .reit TLD will feature an acceptable use policy to ensure that domains are used only for the dissemination of accurate information about REITs and specific REIT entities (this is unlikely to be necessary given the nature of the registrants; however, NAREIT wishes to ensure that the zone remains stringently protected), and the UDRP, URS, and all other ICANN-required rights protection mechanisms will form an integral part of the domain. 

v. Applicant in its capacity of a TLD registry operator will not be providing any special services for protecting privacy or confidential information of registrants or end-users apart from those required by applicable laws, policies, agreements or technical standards. Some registry services include as their integral part, protection of usersʹ confidential information. Examples of such services are: 

• SRS (protecting confidentiality of the EPP transfer authorisation codes) 
• Dissemination of TLD zone files (protecting confidentiality of zone file FTP accounts credentials) 

All registry services, including those described above, will be provided in accordance with the ICANN requirements and specifications to the Registry Agreement. The data security measures adopted by the Applicant are described in detail in the answer to question 30 ʺSecurity Policyʺ. 

vi. NAREIT has undertaken significant outreach efforts to ensure that other member organizations of the REIT community and their members are aware of the .reit domain. Following the delegation of the .reit domain, NAREIT will undertake further efforts to ensure market takeup and enthusiasm for the domain among existing and future REITs. NAREIT will then work with other REIT associations to inform members and members of their respective publics about the domain and its intrinsic benefits. The inherent nature of the TLD and the chosen stringʹs inextricable association with the nature of the intended registrants (REITs) will ensure that the public is aware of, trusts, and understands the TLD. 

The .reit TLD has been developed to serve the REIT community as well as protect the general public, so the elimination of social costs has been interwoven into the fabric of the TLD’s design. A description of how it will both serve and protect members of the sponsored community and the general public follows: 

i. NAREIT has taken great care to develop the most fair registration policy possible. We will offer a phased launch consistent with ICANN requirements to ensure the protection of Trademark holders and the satisfaction of potential registrants. The ICANN-mandated Sunrise period open to TM holders who also satisfy the community eligibility criteria will precede a general availability period during which time eligible entities are able to acquire .reit domains on a first-come, first-served basis. Because we are currently unaware of any potentially conflicting REIT names (i.e. no two REITs currently have the same name), we do not foresee any issue with conflicting domain name requests. Because there may be a conflict in the future, the registry (NAREIT) will work with the applicant to agree upon a successful and acceptable alternative domain name (as fully described in response to question 20). NAREIT firmly believes this policy will satisfy all potential registrants. 

ii. NAREIT will not implement any promotions or registrant discounts. Not only will such promotions or discounts not be of benefit to potential registrants due to the size and financial capabilities of REITs, but also the work involved in validating that potential registrants are, in fact, legitimate REITs in good standing does not render the implementation of promotions and discounts financially viable. 

iii. .reit domain names will be available for registration on a one-year basis and are renewable provided that the REIT submits the required re-validation criteria and that the re-validation is approved. It will not be possible to register a .reit domain for more than one year. This requirement has been designed for the protection of the .reit zone as well as the general public, thereby ensuring that only legitimate REITs which remain in good standing continue to possess and use .reit domains (by requiring a thorough examination of the REIT on a yearly basis to ensure it remains in compliance with the requirements of the .reit TLD). Interim takedowns of non-compliant domains (or REITs) are possible, also to protect the integrity of the zone. 

Due to the unique and restricted nature of the TLD and the significant additional resources required for validating registrant applications, we expect registration fees to be significantly higher than those traditionally charged for traditional open TLDs. At this time we do not foresee a need to increase the registry fees, but the registry will certainly give ample notice of any change in fees as required by the Registry Agreement. 

Yes

The applicant, the National Association of Real Estate Investment Trusts® (NAREIT), is committing to serve the community of real estate investment trusts (REITs) around the world. REITs (pronounced “reets”) are companies that own, operate and finance commercial and residential real estate and play an important role in all facets of the real estate economy. NAREIT is the worldwide representative voice for REITs and listed real estate companies with an interest in U.S. real estate and capital markets, and its members primarily are REITs and other real estate businesses throughout the world.
Today, REITs operate in more than twenty developed and developing countries around the world. Viewing the world’s major economies through the prism of the Group of Twenty Finance Ministers and Central Bank Governors (G-20), 12 of the 19 member countries now embrace REITs through local laws, with several more, including China and India, expected to do so in coming years.
REITs worldwide have a large and growing footprint. The industry-leading global benchmark for listed REITs and real estate investment is the FTSE EPRA⁄NAREIT Global Real Estate Index, which is produced and managed by FTSE Group in partnership with NAREIT and the European Public Real Estate Association (EPRA). The index includes 391 listed REITs and real estate companies in 38 developed and emerging countries with a total equity market capitalization of $940 billion. Of these totals, REITs account for 67 percent of the equity market capitalization of the index, while non-REIT real estate companies account for the remaining 33 percent.
In the United States, REITs today are an appreciable segment of the commercial real estate marketplace. At the end of 2011, 273 REITs were registered in the United States with the Securities and Exchange Commission, with 176 listed on established United States stock exchanges (predominantly the New York Stock Exchange). Listed REITs in the U.S. have an equity market capitalization of more than $500 billion.
REITs in the U.S. own approximately 40,000 properties in all fifty states with a book value of about $800 billion comprising roughly 15-20 percent of all investment-grade commercial real estate. Properties include all types of commercial real estate, including, among others, retail, office, multifamily, health care, lodging, timber, industrial, self-storage and infrastructure.
REITs were first created by an act of the U.S. Congress in 1960 for the purpose of democratizing the ownership of large-scale, income-producing commercial real estate. Until REITs were created, typically only large institutional investors or wealthy individuals could afford to own such properties.
What the U.S Congress understood in 1960 and has endorsed through its consistent support for, and amendment of, the laws governing REITs for over 50 years is that, without such a model for commercial real estate investment, it would be far more problematic to make three key benefits of real estate investment available to individual investors from all walks of life: 1) dependable income; 2) long-term capital appreciation; and, 3) investment diversification.
Investment-grade, income-producing commercial real estate is one of a number of widely recognized and distinct core investment asset classes, which include, among others, equities, bonds, real estate, commodities and cash. As such, commercial real estate investment through REITs is a widely followed and researched component of a well-diversified, long-term investment portfolio of publicly traded securities.
Until REITs were created, only large institutional investors and very wealthy individuals could reap the economic benefits of commercial real estate investment, which they did by directly buying properties and leasing space in those properties to their tenants. REITs, however, offer all investors the opportunity to gain the same economic advantages by investing in the equities of these companies. By offering the opportunity to invest in real estate in securitized form, REITs have democratized this key asset class, providing access to all investors. Equity investment channeled into commercial real estate through REITs also fuels economic growth and provides the space a growing economy demands.
REITs worldwide are delineated from Internet users generally because they are, first, companies that own, operate and finance income-producing commercial real estate. Second, they are companies resident in nations that have adopted a REIT regime – a set of rules governing the operations of a REIT – and that are organized and operating under the requirements of that regime.
A REIT regime consists of four primary elements:
1) ownership must be widely held;
2) a majority of assets and income are real estate related;
3) a majority of income is distributed annually to shareholders (pursuant to applicable law; regulatory or stock exchange requirements or customs; or in order that its distributions be deductible from entity-level income tax); and,
4) there is only one level of tax on income distributed by the REIT.
This definition of a REIT is consistent with that of the Commentary on the OECD Model Tax Convention, which states: “A REIT may be loosely described as a widely held company, trust or contractual or fiduciary arrangement that derives its income primarily from long-term investment in immovable property, distributes most of that income annually and does not pay tax on that income related to the immoveable property that is so distributed.” See OECD, Tax Treaty Issues Related to REITs; Public Discussion Draft, available at www.oecd.org⁄dataoecd⁄23⁄44⁄39554788.pdf (Oct. 30, 2007).
As a supplemental delineation, REITs may be identified as companies that are classified as REIT constituents of well-established investment benchmarks of publicly traded real estate companies (such as the FTSE NAREIT All U.S. REIT Index; the Dow Jones Composite All REIT Index; MSCI US REIT Index; or the FTSE EPRA⁄NAREIT Global REIT Index, Dow Jones Global Select REIT Index, Wilshire Global REIT Index, S&P Global REIT Index).

i.NAREIT is the worldwide representative voice for REITs and listed real estate companies with an interest in U.S. real estate and capital markets. Its members primarily are REITs and other real estate businesses throughout the world that own, operate and finance commercial and residential real estate. In addition, individuals who advise, study and provide services to the REIT industry also are members.
Specifically, NAREIT’s members include 143 publicly listed REITs representing over 97 percent of the listed U.S. REIT industry’s equity market capitalization, as well as 38 non-listed REITs that represent a significant portion of the value of the public, non-listed U.S. REIT industry. Additionally, NAREIT’s REIT members include major REITs based in Europe and Asia.
NAREIT’s core mission is to preserve, perfect and promote the REIT approach to real estate investment. NAREIT pursues this mission through its three core business activities: public policy representation; research and investor outreach; and industry community-building.
With respect to public policy representation, NAREIT’s mission is to provide information and advice regarding REITs and the REIT industry to policymakers in the legislative, regulatory and financial standards arenas, both in the U.S. and in other countries around the world. The purpose of this activity is to foster a legislative and regulatory environment that enables REITs to operate their businesses efficiently, have access to capital markets, and support the industry’s growth.
The information NAREIT provides to policymakers frequently includes background on the operations of REITs, data and information about the REIT industry, and the role that REITs play in the commercial real estate marketplace and the broader economy. NAREIT also provides policymakers with perspective on how current and prospective tax, regulatory, accounting and trade rules affect or may affect the industry.
In the research and investor outreach area, NAREIT’s mission is to provide the investment community with information to help investors from all walks of life determine how REITs can support their long-term investment goals and strategies. Data gathering and research are key to this activity. Consequently, NAREIT is the primary source and publisher of data about the REIT industry’s size, structure and performance. In partnership with the index company FTSE Group, NAREIT publishes some of the most widely used investment benchmarks for U.S REITs and global listed REITs and real estate companies (in partnership with the European Public Real Estate Association (EPRA)). NAREIT also is the leading resource for research on the investment characteristics of REITs and the role of REITs in long-term, diversified investment portfolios.
NAREIT maintains a research and investor outreach staff that functions as a liaison on behalf of the global REIT industry to all cohorts of the investment community, including pension funds, endowments and foundations, defined contribution plan providers and sponsors, investment consultants, financial advisors and others, providing each of them with timely and useful information relevant to their investment activities. NAREIT also conducts major investor forums on REIT investment; maintains the industry’s leading web site, REIT.com, and its primary investor publication, REIT Magazine; and maintains active relationships with financial media who cover the REIT industry.
NAREIT supports community-building within the REIT industry by conducting an ongoing series of conferences and other events at which REIT management teams share their knowledge, experience and best practices with investors, analysts and each other. A number of NAREIT’s conference events are specific to professional disciplines within REITs, such as law, accounting, investment, finance, human resources, and others.
NAREIT’s community-building programs in support of the industry also include a variety of electronic newsletters and information sharing forums designed to keep REIT employees in a variety of disciplines aware of the latest developments impacting their companies.
ii. As noted, NAREIT’s members primarily include REITs, mostly REITs in the U.S. but also REITs in other countries. Thus, NAREIT works actively as appropriate to establish and support a uniform and comprehensive understanding of REITs by investors and policymakers worldwide in part through the compatibility, if not uniformity, of the laws, regulations and policies affecting REITs around the world.
Because many of NAREIT’s non-U.S. members also are members of other representative organizations in their respective countries, NAREIT works cooperatively from time to time with many of these representative organizations in pursuit of compatibility, if not uniformity, of legislation, trade rules, accounting standards and investment guidelines affecting the global REIT community. These organizations include but are not limited to: the Association for Real Estate Securitization (Japan), the British Property Federation, the European Public Real Estate Association, the Property Council of Australia, the Asia Pacific Real Estate Association, and the Real Property Association of Canada.
To facilitate the cooperative activities between and among these various representative organizations, NAREIT has joined with these organizations to form the Real Estate Equity Securitization Alliance (REESA), a forum for the sharing and coordination of global industry policy, research and investor outreach activities.
iii. NAREIT is accountable to both member and nonmember REITs in the United States and around the globe. Its accountability begins with its governance, through quorum voting requirements, an Executive Board, a Board of Governors and a Governance Committee.
NAREIT’s Executive Board is its policy and steering body, responsible for NAREIT’s long-range planning, its financial budgets and investments, and its public policy positions and statements. The Executive Board consists of fifteen individuals acting as CEOs of REITs and publicly traded real estate companies nominated by the Governance Committee and elected by NAREIT’s REIT members. Its Board of Governors is the advisory body to the Executive Board and consists of REIT CEOs recognized for their leadership and management skills. NAREITʹs Governance Committee develops procedures and membership eligibility criteria, with Executive Board approval, and lists of proposed candidates for nomination and election by all NAREIT corporate members to fill seats on the Executive Board, as well as for appointment to the Board of Governors and other roles within the organization. In short, NAREIT is accountable to the REIT community because its membership and leadership are composed of members of the REIT community.
NAREITʹs accountability to the global REIT community is derived in part from its active membership in REESA as described above. Accountability also is ensured, as discussed further in the answer to question 20(e) below, through adoption and implementation of a community enforcement policy for third parties to challenge .reit registrations on the grounds that the applicant does not meet the community eligibility criteria, as well as adoption and implementation of an eligibility reconsideration policy for members of the international REIT community who have failed to satisfy the community eligibility criteria in prior registration requests.

Domain names within the .reit TLD will be intended for registration and use only by REITs, companies that qualify or operate as REITs under relevant national law. For this purpose, national law will include the legislation and regulations of the relevant country, along with the regulations and customs of any applicable recognized stock exchanges or securities regulators; and the applying entity’s organizational documents to the extent consistent with the four-factor test described above. Domain names within the TLD will not be available to the general public, for purchase, sale or registration. Domain names within the TLD also will not be available to entities that do not qualify as a REIT under relevant national law, including REIT associations (e.g., the members of REESA), real estate companies, investors, industry professionals, academics, or individuals who advise, study or provide services to the REIT industry.
Because the TLD will be public facing, intended end-users will include not only REITs, but also general Internet users looking for original and authentic information about REITs from REITs.
NAREIT intends to operate a community registry in order to further the interests of the global REIT community. The purpose of the proposed .reit TLD is to continue to ensure integrity in the term “REIT,” so that both the general and investing public are informed, and awareness is heightened regarding the identities of members of the global REIT community. The .reit TLD will serve all REITs by working to preserve, perfect and promote the REIT approach to real estate investment through the online environment.

The applied-for TLD string, .reit, is identical to the generic, globally-recognized acronym for the international community of real estate investment trusts that NAREIT serves.
A myriad of international reference materials define the term “REIT” solely as “real estate investment trust.” See e.g. Merriam-Webster, REIT, available at http:⁄⁄www.merriam-webster.com⁄dictionary⁄reit (last visited January 27, 2012); Dictionary.Com, REIT, available at http:⁄⁄dictionary.reference.com⁄browse⁄reit (last visited January 27, 2012); Financial Times Lexicon, REIT, available at http:⁄⁄lexicon.ft.com⁄Term?term=REIT (last visited January 27, 2012); Boerse.ard.de, REIT, available at http:⁄⁄boerse.ard.de⁄lexikon.jsp?p=150&key=lexikon_109596&letter=R (last visited January 27, 2012); M-Words, REIT, available at http:⁄⁄m-words.jp⁄w⁄REIT.html (last visited January 27, 2012); Australian Securities Exchange, REIT, available at http:⁄⁄www.asx.com.au⁄products⁄asx-australian-real-estate-investment-trusts.htm (last visited, January 27, 2012); Canada.com, What is a REIT Anyhow?, available at http:⁄⁄www.canada.com⁄vancouversun⁄news⁄story.html?id=730da2fa-1ad0-4b16-b0cb-a55d649c03a8 (last visited January 27, 2012); SingaporeStocks.com, Understanding REITs, available at http:⁄⁄www.singaporestocks.com.sg⁄investing-tips-help⁄understanding-reits.php (January 27, 2012); Hong Kong Real Estate Investor, REIT, http:⁄⁄www.hkrei.com⁄reit⁄ (January 27, 2012).
Moreover, the term REIT is widely recognized even in the very few nations that have adopted foreign-language acronyms, including France, where REITs are more commonly referred to as Société d’Investissement Immobilier Côtée (“SIIC”). [See, e.g., http:⁄⁄www.paris-europlace.net⁄paris07⁄p8_dumortier.pdf .] Indeed, the term “REIT” is used around the world to signify the REIT approach to real estate investment, and entities that qualify as a REIT (or SIIC under French law) will be encouraged to register a domain name in the .reit TLD.
Identification of the global community of real estate investment trusts is tied directly to the applied-for .reit TLD string. NAREIT believes that the term “REIT” is a unique term that has come to signify the global community of real estate investment trusts.

NAREIT will establish a clear policy structure for determining an applicant’s eligibility to register a second-level name in the gTLD. Only a REIT will be deemed eligible to register a domain name in the TLD. Whether an entity applying for a domain name qualifies as a REIT will be determined by two criteria: 1) whether a REIT regime is in place in the nation in which the applicant is domiciled; and, 2) whether the applicant is, in fact, organized and operating as a REIT under the REIT regime established in that nation.
i. NAREIT will determine whether the nation in which the applicant is domiciled has a REIT regime in place. As stated in Question 20a, the core features of a REIT are: 1. ownership must be widely held; 2. a majority of assets & income are real estate related; 3. a majority of income is distributed annually to shareholders (pursuant to applicable law; regulatory or stock exchange requirements or customs; or in order that its distributions be deductible from entity-level income tax); and, 4. there is only one level of tax on income distributed by the REIT
NAREIT will also consider whether the nation of the applicant has a law which formally establishes a national REIT regime. If an applying entity is organized & operating as a REIT as described above pursuant to the REIT regime in the countries set forth in Appendix 20e.1, NAREIT will consider it eligible to register a domain name.
Several nations not listed in 20e.1 appear to have regimes in place or under consideration that may meet some or all of the criteria described previously. With additional clarifying information provided by an applicant, applicants from these nations (listed in Appendix 20e.2) may move in to the list of nations with qualifying regimes.
NAREIT regularly draws on major publications & compendiums of REIT regimes around the world, such as the EPRA Global REIT Survey, PWC Compare and Contrast: Worldwide Real Estate Investment Trust (REIT) Regimes; Ernst & Young Global Real Estate Investment Trust Report, as well as its own policy research to maintain its list of global REIT regimes. The primary list is neither meant to be static nor dispositive in the event the applicant is able to demonstrate that the nation or company in question meets the core criteria. Because laws change from time to time, NAREIT will update & publish this list on a regular basis as applicable laws change or as circumstances otherwise warrant.
The absence of a nation from either of the lists is not considered finally conclusive in the determination of whether the nation in which the applicant is domiciled has a REIT regime in place. Indeed, as noted above, NAREIT shall consider any relevant information and documentation provided by an applicant and will also consider whether commercial investment-oriented indexes of publicly traded REITs and real estate companies around the world include the applicant as a REIT in its nation of domicile.
ii. NAREIT will next determine whether the applying entity is indeed organized or operating as a REIT, with an emphasis on verification by the applicant providing third-party documentation. Possible forms of documentation include, but are not limited to: 1. Certified filings of the applicant with agencies of the relevant national government; or, 2. A letter written in English from independent outside counsel with REIT legal expertise. Unlike several existing sponsored Top-Level Domains (“sTLDs”), NAREIT will not rely on easily manipulated verification information, including links to established websites or community-based email addresses belonging to applicants.
In addition, to accommodate REIT regimes when such documentation is not available, applicants shall have the opportunity to briefly describe their claim to REIT status, such as by providing an English-language copy of a relevant national law governing REITs or REIT-like entities along with documentation establishing the REIT’s compliance with that law, or any other indicia of qualification or operation as a REIT. NAREIT shall reserve the right to require any applicant to provide further information or clarification regarding its request to register a domain name.
NAREIT will review all requests from applicants internally, through a dedicated six-member Determination and Verification Team (“Team”) composed of NAREITʹs: Executive Vice President and General Counsel; Senior Tax Counsel; Senior Vice President, Industry & Member Affairs; Vice President, Investment Affairs & Investor Education; Vice President, Operations; and, Industry Affairs Coordinator. As discussed further below, all eligibility determinations made by the Team are subject to reconsideration through the Eligibility Reconsideration Process administered by an independent board of global REIT community members.
The purpose of the TLD will be to advance the interests of the global REIT community by providing information and services relating to REITs. Accordingly, with regard to name selection, NAREIT will limit the registration of domain names in the TLD to the legal trade names of REITs, or the names by which REITs are commonly known, which may include acronyms, registered and common law trademarks, and exchange ticker symbols. NAREIT’s name selection policy will tie in with its verification policy, such that any certified documentation required for community eligibility should also clearly display the applicant’s trade or commonly known name. NAREIT may also require English-language copies of trademark registrations for name selection purposes or evidence of use in commerce, such as websites or marketing collateral.
NAREIT will implement a policy similar to the existing .jobs sTLD and both: impose a continuing obligation on applicants to maintain their trade names or commonly known names concurrently with their domain name registration; and retain discretion as the sole arbiter of determining whether the applicant meets the naming criteria—subject only to the discretion of a dispute resolution provider under the Community Eligibility Dispute Resolution Procedure (“CEDRP”) described below—as well as the appropriate level of documentation necessary to substantiate the applicant’s claim. Initially, NAREIT will prohibit registration of generic and descriptive terms relating to REITs on the second level that do not refer to the trade name of a specific REIT.
NAREIT will implement a strict “first come, first served” policy to vitiate the potential for multiple requests for the same second level domain name. Only in the event where a “first come, first served” policy is inadequate to settle demand for the same second level domain by multiple eligible applying entities, NAREIT may consider registration of geographic modifiers, such as “US-[REITʹs name].REIT” or “[REITʹs name]Asia.REIT” so long as no confusion is caused by such modifiers.
The TLD shall be used for the benefit of the community. All domain names must serve the needs of the REIT community, and can be cancelled if they do not. Serving the needs of the REIT community shall include providing information about or offering services relating to a registrant’s REIT. Thus, the TLD will ensure its integrity and purpose as an authorized source of REIT-related information and services for investors, media, interested members of the public, or people who use the services of REITs- such as tenants of REIT properties.
NAREIT will bolster this general policy with an affirmative duty upon registrants to establish use of all domain names within one year of registration, which may include forwarding the domain name to an existing TLD that serves the needs of the REIT community. In addition, as part of the regular renewal process for domain names, registrants shall reaffirm current eligibility as a REIT and use in accordance within the TLD content and use policy.
As reflected in NAREIT’s answers to Questions 28 and 29, NAREIT will further delineate the particular uses that are not allowable- for example: unlawful activities, spamming, causing consumer confusion, or reselling the domain names- and prominently display links to such policies on the TLD domain name registration website. NAREIT will also specifically prohibit registration of domain names “solely for the purpose of selling, trading or leasing the domain names for compensation.”
NAREITʹs 6-member Team described above shall ensure continued compliance with NAREITʹs eligibility, naming, content & use policies through random audits of all registered domain names on a regular basis. In addition, NAREIT will place a prominently displayed contact email on the TLD home page as a point of contact for this Team.
NAREIT will adopt a modified version of the ICANN Charter Eligibility Dispute Resolution Procedure, called the “Community Eligibility Dispute Resolution Procedure” (“CEDRP”), and NAREITʹs representatives are currently engaged in discussions with third party service providers to administer the CEDRP. Only slight modifications will be made to incorporate the eligibility policy above.
NAREIT will also adopt a robust Eligibility Reconsideration Policy (“ERP”), modeled after the existing .aero ERP, to ensure accountability of the TLD to the international REIT community through a reconsideration process of NAREIT decisions that: 1) a second level domain name applicant does not meet the eligibility requirements and so is not entitled to obtain a domain name; or, 2) that a registrant no longer meets the eligibility requirements and so its domain name is cancelled or transferred. The ERP shall be administered by a 7-member International Appeal Board that will be composed of REIT industry professionals representing expertise in: law relating to REITs; investment in REITs; accounting practices of REITs; and national or regional associations of REITs and real estate companies. All panelists will volunteer for rotating 2-year terms to be staggered for rotational purpose

Not Available

No

Applicant has considered the relevant provisions of the new TLD Registries Agreement, the GAC Advice ʺGAC Principles Regarding new TLDsʺ and the procedures adopted by other gTLD registries and intends to use the procedure described below with regards to protection of geographic names in the TLD. 

Prior to its launch Applicant will compile a list of country and territory names that will be reserved from delegation indefinitely on the second level. 

Pursuant to the specification provided in ICANNʹs Applicant Guidebook, the list will include country and territory names based on the following internationally recognized lists: 
* the short form (in English) of all country and territory names contained on the ISO 3166-1 list; 
* the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and 
* the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; 

As the above documents get updated from time to time, the exact list of reserved names will be compiled shortly before the TLD launch to account for any updates. The list of reserved names will be published on the Registry website. 

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

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

There are no other products or services, except those described above that the Registry Operator will provide (i) because of the establishment of a Consensus Policy, or (ii) by reason of Applicant 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 Applicant operating the registry will be addressed using rules and procedures established by ICANN such as the Registry Services Evaluation Policy.

Applicant proposes to operate the following registry services, utilising CentralNicʹs registry system:


23.1. Receipt of Data From Registrars

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

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

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

The SRS and EPP systems are described more fully in §24 and §25. The Registrar Console is described in §31.

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 - will be only active during the Sunrise phase, before the SRS opens for the general public. The extension is compliant with the current Internet Draft https:⁄⁄github.com⁄wil⁄EPP-Launch-Phase-Extension-Specification⁄blob⁄master⁄draft-tan-epp-launchphase.txt 

More information on EPP extensions is provided in §25.

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

 * Uniform Domain Name Dispute Resolution Policy
 * Inter-Registrar Transfer Policy
 * Whois Marketing Restriction Policy
 * Restored Names Accuracy Policy
 * Expired Domain Deletion Policy
 * AGP Limits Policy 


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

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

 1. Planned and unplanned maintenance;
 2. Denial-of-service attacks;
 3. unplanned network outages;
 4. delays in publication of DNS zone updates;
 5. security incidents such as attempted or successful breaches of access controls;
 6. significant changes in DNS server behaviour or features;
 7. DNSSEC key rollovers. 

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


23.3. Dissemination of TLD Zone Files

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

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

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

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

Applicant will provide zone files using a sub-format of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS.

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

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


23.4. Operation of the Registry Zone Servers

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

The DNS system is described further in §35.


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

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

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

CentralNicʹs Whois service supports a number of features, including rate limiting to prevent abuse, privacy protections for natural persons, and a secure Searchable Whois Service. The Whois service is more fully described in §26.

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


23.6. DNSSEC

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

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 will also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. CentralNic will publish its DPS following the format described in the “DPS-framework” Internet Draft within 180 days after that draft becomes an RFC.


23.7. Rights Protection Mechanisms

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

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

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


23.8. Registrar Support and Account Management

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


23.9. Reporting to ICANN

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


23.10. Personnel Resources of CentralNic

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


23.10.1. Technical Operations

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

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

 * Senior Operations Engineer(s)
 * Operations Engineer(s)
 * Security Engineer 


23.10.2. Technical Development

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

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

 * Senior Technical Developer x 2
 * Technical Developer x 3 


23.10.3. Technical Support

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

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

The Technical Support team will consist of the following positions:

 * Operations Manager
 * Support Manager
 * Support Agent(s) 

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


23.10.4. Key Personnel


23.10.4.1. Gavin Brown - Chief Technology Officer

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


23.10.4.2. Jenny White - Operations Manager

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


23.10.4.3. Adam Armstrong - Senior Operations Engineer

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


23.10.4.4. Milos Negovanovic - Senior Technical Developer

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


23.10.4.5. Mary OʹFlaherty - Senior Technical Developer

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


23.10.5. Job Descriptions

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


23.10.5.1. Operations Engineer

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


23.10.5.2. Security Engineer

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


23.10.5.3. Technical Developer

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


23.10.6. Resource Matrix

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

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

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

Since the optimistic projection for the number of domains registered in the TLD after three years is 1,000, the TLD will therefore require .02% 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 the TLD are fully met. Revenues from the additional registration volumes will fund the salaries of these new hires. Nevertheless, CentralNic is confident that the staffing outlined above is sufficient to meet the needs of the TLD for at least the first 18 months of operation.


23.11. Eligibility Verification Service

The TLD will only be open to Real Estate Investment Trusts and will maintain stringent eligibility requirements. Please see answer to question 20e for details about the eligibility and name selection criteria.

The Applicant will review all requests from applying entities internally, through a dedicated six-member Determination and Verification Team (“Team”) composed of the Applicantʹs (1) Executive Vice President and General Counsel, (2) Senior Tax Counsel, (3) Senior Vice President, Industry & Member Affairs, (4) Industry Affairs Coordinator, Vice President, Investment Affairs & Investor Education, and (6) Vice President, Operations. The Applicant will only authorize registrations if the eligibility and name selection criteria are met. All determinations made by the Team are subject to reconsideration through the Eligibility Reconsideration Process administered by an independent board of global REIT community members.

More information is available in answer to §20. 

Except where specified this answer refers to the operations of the Applicantʹ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 §25 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 §32.

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

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

The registry system implements two interfaces to the SRS: the standard EPP system (described in §25) and the Registrar Console (described in §31). These systems interact with the primary registry database (described in §33). 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 §25. This response describes the infrastructure which supports the EPP system.

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

CentralNic’s EPP system has a three-layer logical and physical architecture, consisting of load balancers, a cluster of front-end protocol servers, 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 protocol servers. Load is distributed using a weighted-least-connections algorithm. The protocol servers run the Apache web server with the mod_epp and mod_proxy_balancer modules. These servers process session commands (“hello”, “login” and “logout”) and function as reverse proxies for query and transform commands, converting them into plain HTTP requests which are then distributed to the application servers. EPP commands are distributed using a weighted-least-connections algorithm.

Application servers receives EPP commands as plain HTTP requests, which are handled using application business logic. Application servers process commands and prepare responses which are sent back to the protocol servers, which return responses to clients over EPP sessions.

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

The EPP system will comprise of the following systems:

 4x 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 protocol servers (1U rack mount servers with dual-core Intel processors, 16GB RAM, running the CentOS operating system using Apache and mod_epp)
 20x application servers (1U rack mount servers with dual-core Intel processors, 4GB of RAM, running the CentOS operating system using Apache and PHP) 


24.3.1. mod_epp

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


24.3.2. mod_proxy_balancer

mod_proxy_balancer is a core Apache module. Combined with the mod_proxy module, it implements a load-balancing reverse proxy, and includes a number of load balancing algorithms and automated failover between members of a cluster. CentralNic uses mod_proxy_balancer to distribute EPP commands to backend application servers.


24.4. Performance

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

 connect time: 87ms
 login time: 75ms
 hello time: 21ms
 check time: 123ms
 logout time: 20ms 

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.5. Scaling

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

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

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


24.6. Registrar Console

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

The features of the Registrar Console are described in §31.

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

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


24.7. Quality Assurance

CentralNic employs the following quality assurance (QA) methods:

 24x7x365 monitoring provides reports of incidents to NOC
 Quarterly review of capacity, performance and reliability
 Monthly reviews of uptime, latency and bandwidth consumption
 Hardware depreciation schedules
 Unit testing framework
 Frequent reviews by QA working group
 Schema validation and similar technologies to monitor compliance on a real-time, ongoing basis
 Revision control software with online annotation and change logs
 Bug Tracking system to which all employees have access
 Code Review Policy in place to enforce peer review of all changes to core code prior to deployment
 Software incorporates built-in error reporting mechanisms to detect flaws and report to Operations team
 Four stage deployment strategy: development environment, staging for internal testing, OT&E deployment for registrar testing, then finally production deployment
 Evidence-based project scheduling
 Specification development and revision
 Weekly milestones for developers
 Gantt charts and critical path analysis for project planning 

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


24.8. Billing

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

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


24.9. Registrar Support

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

 1st Level: initial support level responsible for basic customer issues. The first job of 1st Level personnel is to gather the customer’s information and to determine the customer’s issue by analyzing the symptoms and figuring out the underlying problem.
 2nd Level: more in-depth technical support level than 1st Level support containing experienced and more knowledgeable personnel on a particular product or service. Technicians at this level are responsible for assisting 1st Level personnel solve basic technical problems and for investigating elevated issues by confirming the validity of the problem and seeking for known solutions related to these more complex issues.
 3rd Level: the highest level of support in a three-tiered technical support model responsible for handling the most difficult or advanced problems. Level 3 personnel are experts in their fields and are responsible for not only assisting both 1st and 2nd level personnel, but with the research and development of solutions to new or unknown issues. 

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

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

 Normal: general enquiry, usage question, or feature enhancement request. Handled by 1st level support.
 Elevated: issue with a non-critical feature for which a work-around may or may not exist. Handled by 1st level support.
 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.
 Critical: A major production system is down or severely impacted. These issues are catastrophic outages that affect the overall Registry System operations. Handled by 3rd level support. 

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


24.10. Enforcement of Eligibility Requirements

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

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

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


24.11. Interconnectivity With Other Registry Systems

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


24.12. Resilience

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


24.12.1. Synchronisation Between Servers and Sites

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

 replication of data between active and standby servers (see §33). CentralNic implements redundancy in its database system by means of an active⁄standby database cluster. The database system used by CentralNic supports native real-time replication of data allowing operation of a reliable hot standby server. Automated heartbeat monitoring and failover is implemented to ensure continued access to the database following a failure of the primary database system.
 replication is used to synchronise the primary operations centre with the Disaster Recovery site hosted in the Isle of Man (see §34). Database updates are replicated to the DR site in real-time via a secured VPN, providing a ʺhotʺ backup site which can be used to provide registry services in the event of a failure at the primary site. 


24.13. Operational Testing and Evaluation (OT&E)

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


24.14. Resourcing

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

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

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

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

Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

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

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

 5730 - Base Protocol
 5731 - domains
 5732 - Host Objects
 5733 - Contact Objects
 5734 - TCP Transport
 3735 - Extension Guidelines
 3915 - RGP Extension
 5910 - DNSSEC Extension 


25.1. Description of Interface

EPP is a stateful XML protocol layered over TCP (see RFC 3734). 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

 domains must comply with the syntax described in RFC 1035 §2.3.1. Additionally, the first label of the name must be between 3 and 63 characters in length.
 domains must have a registrant attribute which is associated with a contact object in the database.
 domains must have an administrative contact attribute which is associated with a contact object in the database.
 domains must have a technical contact which attribute is associated with a contact object in the database.
 domains may have an billing contact attribute which is associated with a contact object in the database.
 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
 the host object model for domains is used rather than the host attribute model.
 domains may have a number of status codes. The presence of certain status codes indicates the domainʹs position in the lifecycle, described further in §27.
 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.
 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.
 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.
 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.
 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.
 only the sponsoring registrar of the domain may submit “update”, “renew” or “delete” commands for the domain. 


25.3.2. Host objects

 host names must comply with RFC 1035. The maximum length of the host name may not exceed 255 characters.
 in-bailiwick hosts must have an IPv4 address. They may optionally have an IPv6 address.
 multiple IP addresses are not currently permitted.
 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.
 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.
 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.
 a host cannot be deleted if one or more domains are delegated to it (the registry deletes hosts to remove orphan glue, see §28).
 inter-registrar transfers are not permitted.
 only the sponsoring registrar of the host may submit “update” or “delete” commands for the object. 


25.3.3. Contact objects

 contact IDs may only contain characters from the set [A-Z, 0-9, . (period), - (hyphen) and - (underscore)] and are case-insensitive.
 phone numbers and email addresses must be valid as described in RFC 5733 §2.5 and §2.6.
 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ʺ.
 the “contact:org”, “contact:sp”, “contact:pc”, “contact:phone” and “contact:fax” elements are optional.
 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.
 a contact cannot be deleted if one or more domains are associated with it.
 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 §27.


25.4.2. DNSSEC Security Extensions Mapping

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

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


25.4.3. Launch Phase Extension

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

CentralNicʹs system implements this extension and will support the most recent version of the draft during the initial launch of the TLD. Once the TLD enters General Availability, this extension will no longer be available for use by registrars. Example frames describing the use of this extension are included in Appendix 25.2. As of writing, the current draft does not include a full schema definition, but a schema from a previous version has been included in Appendix 25.3. When the Draft is updated to include a schema, it will be based on this version.


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

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


25.7. Transaction Logging and Reporting

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

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

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


25.8. EPP Message Queue

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

 approved inbound transfer
 rejected inbound transfer
 new outbound transfer
 cancelled outbound transfer
 approved or rejected domain registration request (where TLD policy requires out-of-band approval of “domain:create” requests) 


25.9. Registrar Support, Software Toolkit

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

 Net::EPP, a general purpose EPP library for Perl. See http:⁄⁄code.google.com⁄p⁄perl-net-epp⁄
 Preppi, a graphical EPP client written in Perl. See https:⁄⁄www.centralnic.com⁄company⁄labs⁄preppi
 Net_EPP, a PHP client class for EPP. See https:⁄⁄github.com⁄centralnic⁄php-epp
 Simpleepp, a Python client class for EPP. See https:⁄⁄bitbucket.org⁄milosn⁄simpleepp
 tx-epp-proxy, a EPP reverse proxy for shared-nothing client architectures written in Python. See https:⁄⁄bitbucket.org⁄milosn⁄tx-epp-proxy 

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


25.10. Quality Assurance, RFC Compliance

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


25.10.1. Schema Validation

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


25.10.2. Multi-stage Deployment and Testing

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

 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.
 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).
 Changes to EPP system code are then deployed in the OT&E environment. Registrars continually test this system as part of their own QA processes, and this additional phase provides an additional level of quality assurance. 


25.10.3. Registrar Feedback

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


25.11. EPP System Resourcing

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

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

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

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

Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

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

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


26.1. Compliance

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

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

The Whois service will additionally comply with all requisite data protection laws (with regards to the collection and retention of personal data), including all relevant European Union privacy directives.


26.2. Domain Name

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

 Domain ROID
 Domain Name
 Domain U-label (if IDN)
 Creation Date
 Last Updated
 Expiration Date
 EPP status codes
 Registrant Contact Information
 Administrative Contact Information
 Technical Contact Information
 Billing Contact Information (if any)
 Sponsoring Registrar ID
 Sponsoring Registrar Contact Information
 DNS servers (if any)
 DNSSEC records (if any) 

An example of a domain whois response is included in Appendix 26.1. The Domain ROID is the Repository Object Identifier as described in RFC 5730, §2.8. The ROID field corresponds to the “domain:roid” element of EPP “info” responses.

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

 PENDING CREATE - a “domain:create” command has been received through the SRS, but the registration has not yet been finalised as an out-of-band review process has not yet been completed.
 ADD PERIOD - the domain is in the Add Grace Period
 CLIENT HOLD - the registrar has added the clientHold status
 DELETE PROHIBITED - this may be present if the domain has either clientDeleteProhibited or serverDeleteProhibited (or both)
 INACTIVE - the domain has no DNS servers
 PENDING DELETE - the domain has left the Redemption Grace Period and is scheduled for deletion
 PENDING DELETE RESTORABLE - the domain is in the Redemption Grace Period
 PENDING RESTORE - a restore request has been received, but the Restore Report has not been received
 PENDING TRANSFER - there is an active inter-registrar transfer for the domain
 RENEW PERIOD - the domain is either in the Renew Grace Period or the Auto-Renew Grace Period
 RENEW PROHIBITED - this may be present if the domain has either clientRenewProhibited or serverRenewProhibited (or both)
 SERVER HOLD - the registry has added the serverHold status
 TRANSFER PERIOD - the domain is in the Transfer Grace Period
 TRANSFER PROHIBITED - this may be present if the domain has either clientTransferProhibited or serverTransferProhibited (or both)
 UPDATE PROHIBITED - this may be present if the domain has either clientUpdateProhibited or serverUpdateProhibited (or both)
 OK - present if none of the above apply. 

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

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


26.3. Contact

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

The following information is included in Dontact records:

 Contact ID
 Sponsoring Registrar
 Creation Date
 Last Updated Date
 EPP Status Codes
 Contact Name
 Organisation
 Street Address (1-3 fields)
 City
 State⁄Province
 Postcode
 Country Code (2 character ISO-3166 code)
 Phone number (e164a format)
 Fax number (e164a format)
 Email address 

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

 DELETE PROHIBITED - present if the contact object has either clientDeleteProhibited or serverDeleteProhibited (or both)
 TRANSFER PROHIBITED - present if the contact object has either clientTransferProhibited or serverTransferProhibited (or both)
 UPDATE PROHIBITED - present if the contact object has either clientUpdateProhibited or serverUpdateProhibited (or both)
 PENDING TRANSFER - there is an active inter-registrar transfer for the contact object
 LINKED - the contact object is associated with one or more domain names. A LINKED contact object automatically has the DELETE PROHIBITED status 


26.4. Host Objects

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

 Server Name
 IPv4 address (if any)
 IPv6 address (if any)
 EPP status codes
 Sponsoring Registrar
 Creation Date
 Referral URL (if any) 

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

Host objects may only have two status codes:

 INACTIVE - the host is not associated with any domain names
 LINKED - the host is associated with one or more domain names 

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


26.5. Character Encoding

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


26.6. IDN Support

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


26.7. Bulk Access

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

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


26.8. Load Projections

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

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

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


26.9. Technical Implementation

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

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


26.9.1. Application Server Architecture

Application servers are built on commodity hardware running CentOS. The service is provided using the mod_whois Apache module (see http:⁄⁄modwhois.sf.net⁄) which causes Apache to listen on port 43 and accept queries, which are then handled using a PHP script, which generates and returns the response.


26.9.2. Caching

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


26.9.2. Database

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


26.10. Web based Whois Service

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


26.11. Searchable Whois Service

Applicant will provide a Searchable Whois Service (SWS). This service will be made available on the TLD website. The 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. These terms are included as Appendix 26.5. 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.12. Anti-Abuse Mechanisms

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

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

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

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

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


26.12.1. Denial-of-Service attacks

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


26.13. 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.14. Resourcing

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

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

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

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

Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

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


27.1. Available

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


27.2. Registered

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

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

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

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


27.3. Expired

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

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


27.4. Redemption Grace Period

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

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

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


27.5. Redemption Period State Diagram

Figure 27.2 describes the state diagram for domain names in the Redemption Grace Period. This diagram is taken from RFC 3915.


27.6. Pending Delete

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


27.7. Released

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


27.8. Other Grace Periods

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


27.8.1. Add Grace Period

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


27.8.2. Auto-renew Grace Period

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


27.8.3. Renew Grace Period

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


27.8.4. Transfer Grace Period

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


27.9. Hold Periods

The registry implements the following hold periods:


27.9.1. Registration Hold Period

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


27.9.2. Transfer Hold Period

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


27.10. Lock Statuses

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


27.10.1. clientHold

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


27.10.2. clientDeleteProhibited

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


27.10.3. clientRenewProhibited

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


27.10.4. clientUpdateProhibited

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


27.10.5. clientTransferProhibited

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


27.10.6. serverHold

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


27.10.7. serverDeleteProhibited

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


27.10.8. serverUpdateProhibited

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


27.10.9. serverRenewProhibited

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


27.10.10. serverTransferProhibited

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


27.11. Lifecycle Processing

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

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

 auto-renewal of expired domains
 processing of registration and renewal fees for domains that move outside their grace periods
 processing of domains in the RGP state (from restorable to not restorable, checking for missing restore reports, etc)
 purging of domains scheduled for deletion 

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


27.12. Inter-Registrar Transfer Period

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


27.13. pendingCreate Status

The Registry system supports the ʺpendingCreateʺ status for domain names, as described in RFC 5731, §3.3. Domains in this state are fully registered in the database (subsequent “create” commands would fail with an Object Exists error) but are not present in the DNS.

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

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


27.14. Resourcing

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

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

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

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

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

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

Top Level Domain registries stand in a unique position within the global DNS infrastructure. 

TLD registries collect registrants’ registration data and so often “know” the entity responsible for a particular domain name. TLD registries record associations between domain names, registrars and registrants and therefore are in the core of the control chain for every domain name in the TLD. Registries also directly control the delegation records and therefore have the power to enable or disable a particular domain name in the DNS. 

This unique position gives power and calls for responsibility. Applicant as a future TLD registry recognizes its important role in maintaining law and order and is committed to acting in the best interests of the public. Hereby we provide a description of the principles and procedures we will apply to mitigate abusive conduct. 

28.1. Single Abuse Point of Contact 
To streamline the information flow and to facilitate ease of communication with the public, Applicant will dedicate a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD. The contact information will consist of at least an email address and a telephone number. This point of contact will be prominently published on the registry website by the commencement of the Sunrise period. Applicant will ensure that: 
* The e-mail account is continuously monitored and all communication securely stored 
* The telephone number is either answered by a live person or diverted to a monitored voicemail account. 
* Abuse contact information will be kept current and will be updated should it ever change in a timely manner 

Messages received through the published abuse point of contact will be processed via the same procedure and within the same timeframe as the signals coming from the monitoring systems. Each message, both via email and phone channels, triggers the creation of a support ticket in a dedicated queue and procedures for ticket escalation exist. Messages originating from law enforcement authorities are by default assigned an escalated level. For critical tickets personnel is available 24x7 to react accordingly. 

Applicant and CentralNic commit to responding to all abuse complaints within 24 hours of receipt (on a 24x7 basis). During the time periods when its global offices are open (typically 8am-6pm in London, Los Angeles and Dubai) response times are expected to be substantially faster, at around 2-3 hours. 

28.2. Policy on Handling Complaints Regarding Abuse 
Applicant is prepared to deal with situations where registry intervention may be required in order to stop illegal activity, prevent abusive conduct or to enforce the law. 

Applicant will adopt a comprehensive Eligibility and⁄or Acceptable Use Policy that will establish what constitutes acceptable use of the domain and will contain a description of the procedures registry that will apply to enforce the Policy. The initial policy is described in detail in section 20(e). 

An enforcement action may be triggered by a variety of events including complaints from the public, registrars or ICANN, decisions of a competent dispute resolution provider, outreach from a governmental agency or findings produced by internal investigation or monitoring processes. 

Normally if abusive behaviour in a TLD is encountered, the reports of such behaviour and the evidence available will be analysed by the Registry. If the Registry, in its sole discretion, concludes that a Domain Name Holder has indeed violated a TLD Policy, the registrant will be given a notice and opportunity to correct the breach. 

Furthermore, the registry reserves the right to lock the domain name or put it on hold (preventing domain resolution in the DNS). In extreme cases where a domain is involved in malicious or illegal activity there are provisions for rapid takedown of the domain name in question. The situations in which rapid takedown provisions may be applied, include, but are not limited to: 
* Phishing 
* Pharming 
* Distribution of illegal content 
* Distribution of malware 
* Fast flux hosting 
* Botnetting 
* Unauthorized access to information systems 
* Threats to the security and⁄or stability of the TLD 

The Eligibility and Acceptable Use Policy will be incorporated into the Registry-Registrar agreements and Registrars will be required to pass through the requirements to comply with the policy to the registrants. 

Applicant will take reasonable steps to investigate and respond to any reports of illegal activity in connection with the use of the TLD and will cooperate with the competent governmental agencies in such investigations. 

Applicant will utilize the expert services of its registry services provider CentralNic to implement and enforce all of our anti-abuse policies in our TLD. CentralNic has dedicated and scalable resources for this function, described below. 

CentralNic has long experience in the domain registry business, and is an industry leader with respect to its anti-abuse policies. CentralNic has a dedicated Dispute Resolution Policy in place with WIPO, found at WIPO’s website: http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. This policy mirrors the UDRP policy for new gTLDs and, as a result, CentralNic already has real-time experience working with WIPO to implement and execute a similar policy. CentralNic has trained personnel who handle interaction with WIPO, to ensure that panelists’ decisions are carried out expeditiously as required by the DRP. 

CentralNic also enforces a Policy on Phishing and Fraud, found at its dedicated Phishing & Abuse page at the following website: https:⁄⁄www.centralnic.com⁄support⁄abuse. Pursuant to clause 13, sections (f) and (h) of CentralNicʹs Terms and Conditions, CentralNic may cancel the registration or suspend registration of a domain name: 

(f) if CentralNic believes that the domain name was registered for use in a ʺphishingʺ attack or other illegal activity of any kind. 
(h) if inaccurate or false contact details are provided. 

Further to these conditions, CentralNic operates the following policy regarding suspected ʺphishingʺ domain names: 
- If we have a reasonable suspicion that a domain name registered at CentralNic is being used in a phishing attack, or otherwise being used for other illegal activities, we will place the domain name ʺOn Holdʺ and under a Registry Lock. 
- We will then notify the current registrar for the domain name. If the registrar can provide confirmation that the domain name was registered in ʺgood faithʺ by the registrant, then CentralNic will immediately unlock the domain name and place it on the ʺLiveʺ status.
 - If no confirmation is received, or the registrars agree that the domain name was registered in ʺbad faithʺ, the domain name will be placed onto ʺPending Deletionʺ, and will be fully deleted from the database after 45 days. 

28.3. Orphan Glue 
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.REIT does not exist, then NS0.EXAMPLE.REIT 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. 

28.4. Measures to Maintain Whois Accuracy 
Applicant 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. 

28.4.1. Extra checks on WHOIS data Applicant, 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. 

28.4.2. Random audits of WHOIS records by the Registry Applicant will periodically (at least once every 12 months) perform a random check of WHOIS records in for prima facie evidence of fraudulent or inaccurate WHOIS information. For those suspicious records that may be found, Applicant 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. 

28.5. Resourcing
Applicant and CentralNic will provide abuse response on a 24x7 basis. The resourcing to fulfil 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 will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to 75% of a full-time role. 

CentralNic operates a shared registry environment where multiple registry zones (such as CentralNicʹs domains, the .LA ccTLD, this TLD and other gTLDs) share a common infrastructure and resources. Since the TLD will be operated in an identical manner to these other registries, and on the same infrastructure, then the TLD will benefit from an economy of scale with regards to access to CentralNicʹs resources. CentralNicʹs resourcing model assumes that the ʺdedicatedʺ resourcing required for the TLD (ie, that required to deal with issues related specifically to the TLD and not to general issues with the system as a whole) will be equal to the proportion of the overall registry system that the TLD will use. After three years of operation, the optimistic projection for the TLD states that there will be 1,000 domains in the zone. CentralNic has calculated that, if all its TLD clients are successful in their applications, and all meet their optimistic projections after three years, its registry system will be required to support up to 4.5 million domain names. Therefore the TLD will require 0.02% of the total resources available for this area of the registry system. 

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

28.6. Periodic review of anti-abuse policies Applicant acknowledges that new types of abusive behaviour emerge in cyber space and is prepared to take steps to counter any new types of abuse. Applicant will periodically (once every 12 months, or more frequently depending on the circumstances) require CentralNic to provide reports regarding the received abuse-related complaints. Such reports should contain categorisation of the abusive behaviour reported, actions taken and response time. Applicant will analyse the reports and will review its anti-abuse policies to continually improve the handling of abuse complaints. 

28.7. Extra provisions for validation-based TLDs As mentioned above, registrations in the TLD will not be in real time. The registration process will involve manual verification of the identity of the applicant, correctness of its contact information and its compliance with the Eligibility restrictions. The manual verification process will ensure that only legitimate and reputable businesses will be able to register domain names in the TLD. Manual verification of contact information will further ensure unprecedented accuracy of WHOIS data. 
Applicant expects that this additional manual screening process, added on to the standard anti-abuse measures, will discourage abusive registrations and make any malicious activity extremely unlikely to occur in the TLD. 

28.8 Principles of Eligibility and Acceptable Use 
.REIT domains are available for registration by a limited pool of registrants whose registration and company details will undergo thorough background checks and authentication by the Registry, promoting complete and accurate WHOIS information. 

28.8.1. Eligibility 
NAREIT will establish a clear policy structure for determining an applicant’s eligibility to register a second-level name in the gTLD. Only a REIT will be deemed eligible to register a domain name in the TLD. Whether an entity applying for a domain name qualifies as a REIT will be determined by two criteria: 1) whether a REIT regime is in place in the nation in which the applicant is domiciled; and, 2) whether the applicant is, in fact, organized and operating as a REIT under the REIT regime established in that nation. 

i. NAREIT will first determine whether the nation in which the applicant is domiciled has a REIT regime in place. 

The core features of a REIT are: 
* ownership must be widely held; 
* a majority of assets and income are real estate related; 
* a majority of income is distributed annually to shareholders (pursuant to applicable law; regulatory or stock exchange requirements or customs; or in order that its distributions be deductible from entity-level income tax); and, 
* there is only one level of tax on income distributed by the REIT. 

NAREIT also will consider whether the nation of the applicant has a law which formally establishes a national REIT regime. If an applying entity is organized and operating as a REIT as described above pursuant to the REIT regime in the countries set forth in Appendix 20e.1, NAREIT will consider it eligible to register a domain name in the TLD. 

Several nations not listed in 20e.1 appear to have regimes in place or under consideration that may meet some or all of the criteria described previously. With additional clarifying information provided by an applicant, applicants from these nations (listed in Appendix 20e.2) may move in to the list of nations with qualifying regimes. 

NAREIT regularly draws on major publications and compendiums of REIT regimes around the world, such as the EPRA Global REIT Survey, PWC Compare and Contrast: Worldwide Real Estate Investment Trust (REIT) Regimes; Ernst & Young Global Real Estate Investment Trust Report, as well as its own policy research to maintain its list of global REIT regimes. The primary list is neither meant to be static nor dispositive in the event the applicant is able to demonstrate that the nation or company in question meets the core criteria. Because laws change from time to time, NAREIT will update and publish this list on a regular basis as applicable laws change or as circumstances otherwise warrant. 

The absence of a nation from either of the attached lists is not considered finally conclusive in the determination of whether the nation in which the applicant is domiciled has a REIT regime in place. Indeed, as noted above, NAREIT shall consider any relevant information and documentation provided by an applicant and will also consider whether commercial investment-oriented indexes of publicly traded REITs and real estate companies around the world include the applicant as a REIT in its nation of domicile. 

ii. NAREIT will next determine whether the applying entity is indeed organized or operating as a REIT, with an emphasis on verification by the applicant providing third-party documentation. 
Possible forms of documentation shall include, but are not limited to: 
* Certified filings of the applicant with agencies of the relevant national government; or, 
* A letter written in English from independent outside counsel with REIT legal expertise. 

Unlike several existing sponsored Top-Level Domains (“sTLDs”), NAREIT will not rely on easily manipulated verification information, including links to established websites or community-based email addresses belonging to applicants. 

In addition, to accommodate REIT regimes when such documentation is not available, applicants shall have the opportunity to briefly describe their claim to REIT status, such as by providing an English-language copy of a relevant national law governing REITs or REIT-like entities along with documentation establishing the REIT’s compliance with that law, or any other indicia of qualification or operation as a REIT. NAREIT shall reserve the right to require any applicant to provide further information or clarification regarding its request to register a domain name. 

NAREIT will review all requests from applicants internally, through a dedicated six-member Determination and Verification Team (“Team”) composed of NAREITʹs: 
1) Executive Vice President and General Counsel; 
2) Senior Tax Counsel; 
3) Senior Vice President, Industry & Member Affairs; 
4) Vice President, Investment Affairs & Investor Education; 
5) Vice President, Operations; and, 
6) Industry Affairs Coordinator. 

As discussed further below, all eligibility determinations made by the Team are subject to reconsideration through the Eligibility Reconsideration Process administered by an independent board of global REIT community members. 

28.8.2. Name Selection Rules 
NAREIT will limit the registration of domain names in the TLD to the legal trade names of REITs, or the names by which REITs are commonly known, which may include acronyms, registered and common law trademarks, and exchange ticker symbols. NAREIT’s name selection policy will tie in with its verification policy, such that any certified documentation required for community eligibility should also clearly display the applicant’s trade name or commonly known name. NAREIT may also require English-language copies of trademark registrations for name selection purposes or evidence of use in commerce, such as websites or marketing collateral. 

NAREIT will implement a policy similar to the existing .jobs sTLD and both: 
1) impose a continuing obligation on applicants to maintain their trade names or commonly known names concurrently with their domain name registration; and, 
2) retain discretion as the sole arbiter of determining whether the applicant meets the naming criteria—subject only to the discretion of a dispute resolution provider under the Community Eligibility Dispute Resolution Procedure (“CEDRP”) described below—as well as the appropriate level of documentation necessary to substantiate the applicant’s claim. Initially, NAREIT will prohibit registration of generic and descriptive terms relating to REITs on the second level that do not refer to the trade name of a specific REIT. 

Allowed character repertoire for consists of ASCII characters “A” to “Z”, the hyphen character (“-“) and digits “0” to “9”. Internationalized Domain Names cannot be registered on the second level. 

The resulting domain name label must conform to the requirements and limitations imposed by applicable technical standards for the Domain Name System and TLD naming requirements as outlined in response to question 20e. For instance, DNS labels cannot be longer than 63 characters (excluding the TLD suffix). 

28.8.3. Registration 
Following the Sunrise Period, NAREIT will implement a strict “first come, first served” policy to vitiate the potential for multiple requests for the same second level domain name. Only in the event where a “first come, first served” policy is inadequate to settle demand for the same second level domain by multiple eligible applying entities, NAREIT may consider registration of geographic modifiers, such as “US-[REITʹs name].REIT” or “[REITʹs name]Asia.REIT” so long as no confusion is caused by such modifiers. 

28.8.4. Acceptable Use Policy 
Domain names must be registered by eligible entities and for the benefit of the community. All domain names must serve the needs of the REIT community, and can be cancelled if they do not. Serving the needs of the REIT community shall include providing information about or offering services relating to a registrant’s REIT. 

Registrants must establish use of all domain names within one (1) year of registration, which may include forwarding the domain name to an existing TLD that serves the needs of the REIT community. Domains cannot be registered solely for the purpose of selling, trading or leasing the domain names for compensation. 

Domain names can only be used for lawful purposes. The Registry is committed to maintaining the environment free from online crime, malicious or illegal activities. The Registry will investigate all reports of illegal activity and will cooperate with the competent governmental agencies in such investigations. 

Applicant recognizes providing appropriate mechanisms to protect legal rights of others as one of the core objectives of the Registry. Applicant will follow rules and policies developed by ICANN with regards to Rights Protection Mechanisms (RPMs). Applicant will fully comply with Specification 7 of the new gTLD registry agreement (including the RRDRP which is specifically applicable to community-based applications such as .REIT) and will provide additional rights protection mechanisms over and above the ICANN requirements. Both standard and additional RPMs are described below. 

29.1. Sunrise Period 
Prior to the open registration phase Applicant will offer a priority registration period for owners of trademarks and service marks. This period will last at least 30 days. 

Applicant will support Trademark Clearinghouse (TCH) once it is implemented by ICANN. Owners of trademarks pre-validated by the Clearinghouse and meeting REIT community eligibility criteria will be able to secure their domain registrations during the Sunrise period without further verification of their intellectual property rights. 

The flowchart of the Sunrise and eligibility validation process is available in Figure 24.4. 

29.1.1. Sunrise Eligibility Requirements 
Any entity that holds a trademark or service mark and meets REIT community eligibility criteria will be qualified to register a domain during the Sunrise period. Registrations obtained during the Sunrise Period will be subject to challenge as described below. As a minimum, the Registry will recognize as qualifying all word marks that: 
* Are nationally or regionally registered and for which proof of use is available, or 
* Marks that have been validated by the court, or 
* Marks that are specifically protected by a statute or treaty. 

All the Sunrise Eligibility requirements will have to be met by the cut-off date which will be announced in due course. Full details of the Sunrise registration process will be finalized after the Trademark Clearinghouse service is implemented and full documentation, policies, terms and conditions are made available. For guidance, data items that will need to be provided by the qualifying applicant to apply for a Sunrise registration are listed below: 
* name or description of the trademark 
* registration number 
* registration date 
* country of registration 
* capacity of the applicant 
* reference to the Trademark Clearinghouse database record 
* representation that the information provided is true and correct 

29.1.2. Sunrise Challenge Process 
The result of the evaluation of Sunrise applications will be published on the Registry website. A process will be in place to allow third parties to dispute the registrant rights to own a domain name. Applicant will engage with a reputable adjudicator to manage the Sunrise challenge process. The adjudicator will charge a reasonable fee for Sunrise challenges. 

The Sunrise Challenge rules will allow challenges based on at least the following four grounds: 
* at the time the challenged domain name was registered, the registrant 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; 
* the domain name is not identical to the mark on which the registrant based its Sunrise registration; 
* 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 
* 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. 

29.2. Trademark Claims Service The Trademark Claims service will be launched by the registry as soon as the open registration period starts and will be provided for at least 90 days (exceeding the period mandated by ICANN). The Applicant will review the effect of the Trademark Claims service and based on the results of such review Applicant is prepared to consider providing the Trademark Claims service on an ongoing basis. 

The essence of the Trademark Claims service is as follows: if a domain name registration is attempted for which there exists a matching record in the Trademark Clearinghouse database, then the prospective registrant will be presented with a notice that third party trademark rights exist for a matching designation and will be required to provide a statement that to the best of his or her knowledge, the registration and use of the requested domain name will not infringe on the rights of the trademark holders. 

If the registrant chooses to proceed with the registration, the corresponding trademark holder(s) will be notified that such registration has taken place. 

Operational rules of the Trademark Claims service are heavily dependent on the specific implementation of the Trademark Clearinghouse which is not yet available in writing. Therefore full details of the Trademark Claims service will be finalized after the TCH is implemented by ICANN and full documentation, policies, terms and conditions become available. 

29.3. Uniform Domain Name Dispute Resolution Policy (UDRP) 
The Uniform Domain Name Dispute Resolution Policy is an ICANN consensus policy for adjudication of disputes between domain name holders and owners of matching trademarks. Every registrant must agree to this mandatory administrative procedure in its Domain Registration Agreement with the registrar. Registrars have certain responsibilities to facilitate adjudication of UDRP disputes and to enforce the decisions of the arbitration panels. 

The TLD will comply with the Uniform Domain Name Dispute Resolution Policy or with any successor thereof. The UDRP will be incorporated by reference into Registry-Registrar Agreements. Similarly, Registrars will be required to incorporate it into their Domain Registration agreements with the Registrants. 

The UDRP process does not provide for any participation by the Registry and is fully borne by the Registrar, Registrant, Complainant and the Dispute Resolution Provider. However, Applicant is prepared to collaborate with all relevant stakeholders to ensure UDRP decisions are implemented. 
CentralNic, Applicant’s registry services provider, has maintained a similar dispute resolution policy with WIPO which is available at http:⁄⁄www.wipo.int⁄amc⁄en⁄domains⁄gtld⁄cnic⁄index.html. CentralNic has dedicated personnel trained to address these types of complaints and to communicate with WIPO and other relevant stakeholders. 

29.4. Uniform Rapid Suspension System (URS) 
The Uniform Rapid Suspension System (URS) described in the ICANN gTLD Applicant Guidebook is a new Rights Protection Mechanism for rapid takedown of domain names that by clear and convincing evidence infringe on legitimate trademark rights of third parties. 
As opposed to the UDRP procedure, registries are required to participate in the URS procedure and enforcement of the URS decisions. Applicant will comply with the URS policy once implemented by ICANN. 

The current URS procedure as described in the Applicant Guidebook is as follows: within 24 hours of receipt of the Notice of Complaint from a URS Provider, the Registry has to lock the domain, restricting all changes to the registration data, including transfer and deletion. The domain name will continue to resolve at this stage. The Registry will notify the URS Provider immediately upon locking the domain name. If the URS Determination is in favour of Complainant, upon receipt of the Determination the Registry will suspend the domain name which is intended to remain suspended for the balance of the registration period and will not resolve to the original web site. Instead, the nameservers will be redirected to an informational web page provided by the URS Provider about the URS. The Whois record for the domain name will continue to display all of the information of the original Registrant except for the redirection of the nameservers. In addition, the Whois will reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration. If the URS Determination is in favour of the Respondent, the Registry will remove the lock status from the domain name allowing the registrant to continue using it normally. 

The URS compliance function will be performed by CentralNic and overseen by the Applicant. Given CentralNic long-standing experience in dealing with trademark-related disputes in domain names, Aplicant has no doubt that this function will be performed by CentralNic flawlessly. 

29.5 Mediation 
CentralNic has implemented a solution that complements the UDRP by adopting a best practice employed by Nominet and other ccTLDs. CentralNic has experienced a high percentage of domain disputes resolved without the need for filing a formal and relatively expensive UDRP complaint, by offering informal mediation to any person or entity who submits a Request for Mediation to the registry. The Mediation rules that CentralNic intends to apply to gTLDs are copied below: 

ʺCentralNicʺ means CentralNic Ltd, 35-39 Moorgate, London EC2R 6AR, United Kingdom. 
ʺComplainantʺ means the party submitting a Request for Mediation concerning a Domain Name registration pursuant to the CentralNic Mediation Rules. 
ʺDomain Nameʺ means any domain name registered under a sub-domain provided by CentralNic. 
ʺMediationʺ means a mediation conducted by CentralNic in accordance with the CentralNic Mediation Rules that are incorporated by reference and made a part of the Registration Agreement. 
ʺPartyʺ means a Complainant or a Respondent. 
ʺRegistration Agreementʺ means the agreement between CentralNic and a Domain Name holder. 
ʺRespondentʺ means the holder of a Domain Name registration in respect of which a Request for Mediation is submitted pursuant to the CentralNic Mediation Rules. 

1. Request for Mediation: 
(a) Any person or entity may submit a Request for Mediation relating to a Domain Name registration in accordance with the CentralNic Mediation Rules. A copy of the Request for Mediation shall be sent to the Respondent and to CentralNic. 
(b) The Request for Mediation shall be submitted in writing by e-mail and shall: 
 (i) State that the Complainant wishes to submit the dispute to Mediation in accordance with the CentralNic Mediation Rules;
 (ii) Provide the name, postal and e-mail addresses, and the telephone and telefax numbers of the Complainant and of any representative authorized to act for the Complainant in the Mediation; 
 (iii) Specify a preferred method for communications directed to the Complainant in the Mediation (including person to be contacted, medium, and address information); 
 (iv) Provide the name of the Respondent and all information (including any postal and e-mail addresses and telephone and telefax numbers) known to Complainant regarding how to contact the Respondent or any representative of the Respondent, including contact information based on pre-Request dealings; 
 (v) Specify the Domain Name(s) that is⁄are the subject of the Request; 
 (vi) Contain a brief statement of the nature of the dispute. 
(c) The Request for Mediation may relate to more than one Domain Name, provided that the Domain Names are registered by the same Domain-Name holder. 

2. Commencement: 
(a) The date of commencement of the Mediation shall be the date on which the Request for Mediation is received by CentralNic. 
(b) CentralNic shall inform the Parties of the receipt by it of the Request and of the date of commencement of the Mediation. 

3. Mediation: 
(a) CentralNic shall conduct the Mediation in a manner which CentralNic, in its sole discretion, considers appropriate. 
(b) The language of the Mediation shall be English, unless decided otherwise by CentralNic. 
(c) CentralNic will not reveal details of the Mediation to any third parties unless ordered by a court of competent jurisdiction or required by applicable laws or regulations or except as may be provided under the CentralNic Dispute Resolution Policy and the Rules for CentralNic Dispute Resolution Policy. 

4. Termination of the Mediation: 
The Mediation will terminate ten (10) calendar days after the date of commencement. At the request of the Parties or on its own motion, CentralNic may, in exceptional cases, extend the period of time for the Mediation. The fact of termination shall be recorded by CentralNic. 

5. Fees: No fees shall be payable by either party for the conduct of the Mediation. 

6. Exclusion of Liability: Except in the case of deliberate wrongdoing, CentralNic shall not be liable to a Party for any act or omission in connection with the Mediation. 

7. Waiver of Defamation: The Parties agree that any statements or comments, whether written or oral, made or used by them or their representatives in preparation for or in the course of the Mediation shall not be relied upon to found or maintain any action for defamation, libel, slander or any related complaint, and this Paragraph may be pleaded as a bar to any such action. 

8. Amendments: CentralNic reserves the right to modify these Rules at any time. CentralNic will post the revised Rules at at least thirty (30) calendar days before they become effective. The version of these Rules in effect at the time of the submission of the Request for Mediation to CentralNic shall apply to the Mediation commenced thereby. 

Applicant notes this is CentralNic’s current policy for its current registry businesses. Applicant may make modifications to this Policy, without limitation by charging a reasonable fee and⁄or by specifying the mediation mechanism, as its business plans develop prior to launch of the TLD. However, Applicant remains committed to offering a less formal and less expensive procedure than the UDRP, and perhaps even the URS, to the extent commercially feasible. 

29.6 Abusive use⁄takedown policies Answer to question 28 contains a detailed description of measures that the Applicant will take to prevent and mitigate abusive registrations and the description of policies that the Applicant will apply to handle complaints regarding abuse and take down abusive registrations. To summarise, 
* Applicant will dedicate a single abuse point of contact. Correspondence and complaints coming through that point of contact will be continuously monitored and responded to within 24 hours. 
* Applicant will adopt a comprehensive Eligibility and⁄or Acceptable Use Policy that will set forth the limits of acceptable use of domains and the procedures the Registry will apply in case of violations of applicable laws or policies, including takedown procedures. The initial Acceptable Use Policy is described in section 20(e). 
* Applicant will delete orphan glue records once the parent domain is deleted to prevent abuse of these orphan glue records. 
* Applicant will require registrars to perform extra checks on WHOIS data to improve its accuracy. 
* Applicant will perform random audits of WHOIS data and will flag suspicious registrations via registrars. 

29.7. Post-Delegation Dispute Resolution Procedure 
Applicant reaffirms its intent to comply with the ICANN-mandated Post-Delegation Dispute Resolution Procedure (PDDRP). 

Applicant believes that its choice of TLD string and the way the TLD is intended to be operated represents a good faith offering of Top Level Domain Registry service and does not infringe on any legitimate third party trademark rights. 

Applicant also reaffirms its commitment to maintain the TLD free of violations of third party trademark rights through second level domain registration and use. Applicant has all the required resources, policies and procedures in place to address any situations of abuse without the need to invoke the PDDRP procedure. 

29.8. Resourcing 
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 TCH 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 will maintain a team of full-time developers and engineers which will contribute to the development and maintenance of this aspect of the registry system. These developers and engineers will not work on specific subsystems full-time, but a certain percentage of their time will be dedicated to each area. The total HR resource dedicated to this area is equivalent to half of a full-time role. 

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

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

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


29.9 Extra provisions for Validation-Based TLDs
As mentioned above, registrations in the TLD will not be in real time. The registration process will involve an additional step of manual verification of the identity of the applicant, correctness of its contact information and its compliance with the Eligibility restrictions. The manual verification process will ensure that only legitimate and reputable businesses will be able to register domain names in the TLD. Manual verification of contact information will further ensure unprecedented accuracy of WHOIS data. 

Applicant expects that this additional manual screening process, added on to the standard anti-abuse measures, will discourage abusive registrations and make any abusive or malicious activity extremely unlikely to occur in the TLD. 


29.10 Principles of Eligibility and Acceptable Use 
These principles are subject to all ICANN requirements for new gTLDs, including the URS and UDRP, and will be made compliant with any future ICANN requirements as and when necessary.

29.10.1. Eligibility 
NAREIT will establish a clear policy structure for determining an applicant’s eligibility to register a second-level name in the gTLD. Only a REIT will be deemed eligible to register a domain name in the TLD. Whether an entity applying for a domain name qualifies as a REIT will be determined by two criteria: 
1) whether a REIT regime is in place in the nation in which the applicant is domiciled; and, 
2) whether the applicant is, in fact, organized and operating as a REIT under the REIT regime established in that nation. 

i. NAREIT will first determine whether the nation in which the applicant is domiciled has a REIT regime in place. 
The core features of a REIT are: 
* ownership must be widely held; 
* a majority of assets and income are real estate related; 
* a majority of income is distributed annually to shareholders (pursuant to applicable law; regulatory or stock exchange requirements or customs; or in order that its distributions be deductible from entity-level income tax); and, 
* there is only one level of tax on income distributed by the REIT. 

NAREIT also will consider whether the nation of the applicant has a law which formally establishes a national REIT regime. If an applying entity is organized and operating as a REIT as described above pursuant to the REIT regime in the countries set forth in Appendix 20e.1, NAREIT will consider it eligible to register a domain name in the TLD. 

Several nations not listed in Appendix 20e.1 appear to have regimes in place or under consideration that may meet some or all of the criteria described previously. With additional clarifying information provided by an applicant, applicants from these nations (listed in Appendix 20e.2) may move in to the list of nations with qualifying regimes. 

NAREIT regularly draws on major publications and compendiums of REIT regimes around the world, such as the EPRA Global REIT Survey, PWC Compare and Contrast: Worldwide Real Estate Investment Trust (REIT) Regimes; Ernst & Young Global Real Estate Investment Trust Report, as well as its own policy research to maintain its list of global REIT regimes. The primary list is neither meant to be static nor dispositive in the event the applicant is able to demonstrate that the nation or company in question meets the core criteria. Because laws change from time to time, NAREIT will update and publish this list on a regular basis as applicable laws change or as circumstances otherwise warrant. 

The absence of a nation from either of the attached lists is not considered finally conclusive in the determination of whether the nation in which the applicant is domiciled has a REIT regime in place. Indeed, as noted above, NAREIT shall consider any relevant information and documentation provided by an applicant and will also consider whether commercial investment-oriented indexes of publicly traded REITs and real estate companies around the world include the applicant as a REIT in its nation of domicile. 

ii. NAREIT will next determine whether the applying entity is indeed organized or operating as a REIT, with an emphasis on verification by the applicant providing third-party documentation. 

Possible forms of documentation shall include, but are not limited to: 
* Certified filings of the applicant with agencies of the relevant national government; or, 
* A letter written in English from independent outside counsel with REIT legal expertise. 

Unlike several existing sponsored Top-Level Domains (“sTLDs”), NAREIT will not rely on easily manipulated verification information, including links to established websites or community-based email addresses belonging to applicants. 

In addition, to accommodate REIT regimes when such documentation is not available, applicants shall have the opportunity to briefly describe their claim to REIT status, such as by providing an English-language copy of a relevant national law governing REITs or REIT-like entities along with documentation establishing the REIT’s compliance with that law, or any other indicia of qualification or operation as a REIT. NAREIT shall reserve the right to require any applicant to provide further information or clarification regarding its request to register a domain name. 

NAREIT will review all requests from applicants internally, through a dedicated six-member Determination and Verification Team (“Team”) composed of NAREITʹs: 1) Executive Vice President and General Counsel; 2) Senior Tax Counsel; 3) Senior Vice President, Industry & Member Affairs; 4) Vice President, Investment Affairs & Investor Education; 5) Vice President, Operations; and, 6) Industry Affairs Coordinator. As discussed further below, all eligibility determinations made by the Team are subject to reconsideration through the Eligibility Reconsideration Process administered by an independent board of global REIT community members. 

29.10.2. Name Selection Rules 
NAREIT will limit the registration of domain names in the TLD to the legal trade names of REITs, or the names by which REITs are commonly known, which may include acronyms, registered and common law trademarks, and exchange ticker symbols. NAREIT’s name selection policy will tie in with its verification policy, such that any certified documentation required for community eligibility should also clearly display the applicant’s trade name or commonly known name. NAREIT may also require English-language copies of trademark registrations for name selection purposes or evidence of use in commerce, such as websites or marketing collateral. 

NAREIT will implement a policy similar to the existing .jobs sTLD and both: 
1) impose a continuing obligation on applicants to maintain their trade names or commonly known names concurrently with their domain name registration; and, 
2) retain discretion as the sole arbiter of determining whether the applicant meets the naming criteria—subject only to the discretion of a dispute resolution provider under the Community Eligibility Dispute Resolution Procedure (“CEDRP”) described below—as well as the appropriate level of documentation necessary to substantiate the applicant’s claim. Initially, NAREIT will prohibit registration of generic and descriptive terms relating to REITs on the second level that do not refer to the trade name of a specific REIT. 

Allowed character repertoire for consists of ASCII characters “A” to “Z”, the hyphen character (“-“) and digits “0” to “9”. Internationalized Domain Names cannot be registered on the second level. 

The resulting domain name label must conform to the requirements and limitations imposed by applicable technical standards for the Domain Name System and TLD naming requirements as outlined in response to question 20e. For instance, DNS labels cannot be longer than 63 characters (excluding the TLD suffix). 

29.10.3. Registration 
Following the Sunrise Period, NAREIT will implement a strict “first come, first served” policy to vitiate the potential for multiple requests for the same second level domain name. Only in the event where a “first come, first served” policy is inadequate to settle demand for the same second level domain by multiple eligible applying entities, NAREIT may consider registration of geographic modifiers, such as “US-[REITʹs name].REIT” or “[REITʹs name]Asia.REIT” so long as no confusion is caused by such modifiers. 

29.10.4. Acceptable Use Policy
Domain names must be registered by eligible entities and for the benefit of the community. All domain names must serve the needs of the REIT community, and can be cancelled if they do not. Serving the needs of the REIT community shall include providing information about or offering services relating to a registrant’s REIT. 

Registrants must establish use of all domain names within one (1) year of registration, which may include forwarding the domain name to an existing TLD that serves the needs of the REIT community. Domains cannot be registered solely for the purpose of selling, trading or leasing the domain names for compensation. 

Domain names can only be used for lawful purposes. The Registry is committed to maintaining the environment free from online crime, malicious or illegal activities. The Registry will investigate all reports of illegal activity and will cooperate with the competent governmental agencies in such investigations. 

Except where specified this answer refers to the operations of the Applicantʹs outsource Registry Service Provider, CentralNic.

30(a).1. Introduction

CentralNicʹs Information Security Management System (ISMS) implements all the mandatory requirements of the EIC⁄ISO 27001:2005 standard. The scope of the management system covers all of CentralNicʹs registry systems and facilities. CentralNic is working towards achieving full ISO 27001 certification and has secured the services of Lloydʹs Register Quality Assurance (LRQA) for this certification. A letter from LRQA confirming this engagement is included in Appendix 30(a).1. Stage One of this process was successfully completed during May of this year and Stage Two of the assessment is scheduled to be completed by July 10th. CentralNic will provide a copy of the assessment report to ICANN for consideration, and a copy of the certificate once it has been issued.

The ISMS is part of a larger Management System which includes policies and procedures compliant to ISO 9001. 

30(a).2. Independent Assessment

As part of ISO 27001 compliance, CentralNicʹs security policies will be subjected to annual external audit. Further details can be found in §30(b).


30(a).3. Augmented Security Levels

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

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


30(a).4. Commitments to Registrars

Applicant and CentralNic will make the following commitments to the TLD registrars:

 The SRS will be operated in a secure manner. Controls will be in place to prevent unauthorised access and modification of registry data.
 The Whois service will prevent unauthorised bulk access to domain name registration data, and provide tools to protect personal information.
 The DNS system will be designed to provide effective defence against DDoS attacks. The registry will proactively monitor the DNS system to provide early warning against threats to the stability of the TLD.
 The DNSSEC system will be operated in accordance with best practices and recommendations as described in the relevant RFC documents (described in §43).
 Security incidents reported by registrars, registrants and other stakeholders will be acted upon in accordance with the Security Incident Response Policy (see below).
 Security vulnerabilities reported to the registry will be acknowledged and remediated as quickly as possible.
 Registrars will be promptly notified of all incidents that affect the security and stability of the registry system and their customers, and will be kept informed as incidents develop. 


30(a).5. Access Controls

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

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

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


30(a).6. Security Enforcement

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

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


30(a).8. Security Incident Response Policy

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

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

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

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


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

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


30(a).10. Information Security Team

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

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

IST responsibilities include:

 Review and monitor information security threats and incidents.
 Approve initiatives and methodologies to enhance information security.
 Agree and review the security policy, objectives and responsibilities.
 Review client requirements concerning information security.
 Promote the visibility of business support for information security company-wide.
 Manage changes to 3rd party services that may impact on Information Security
 Perform internal audits with the assistance of Blackmores. 


30(a).11 Auditing and Review

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


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

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

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


30(a).13. Applicant Security Policy

Controls to restrict access to confidential data relating to the TLD:

NAREIT maintains controls to assure that all financial information and sensitive data, including data relating to the TLD is restricted to authorized staff only. NAREITʹs controls are audited every year by a third party independent auditing firm.

Storage of records:

These records will be stored in both hard copy paper and electronic data format.

Controls to store and secure credentials used to access registry services and other third party systems:

These credentials will be stored in a password protected file on a secure and restricted network server which requires membership in a specific security group and a username and password to access the data.

Access logs to data and credentials:

Access to data and credentials is logged, and automatic alerts are in place to inform system administrators of any unauthorized access. The logs are also manually audited on a regular basis to assure access has not been compromised.

Information processing facilities to be used:

NAREIT will use a secure firewall protected network infrastructure with hardware redundancy, secure Windows 2008 Active Directory server and Windows 7 Ultimate workstations, secure electronic MS Exchange 2010 email server, 3 redundant high speed secure Internet connections, the Office 2010 Professional productivity suite, and Microsoft Great Plains 2010 financial accounting software in to process information in relation to the TLD.

Access controls in place to prevent unauthorised access to information processing facilities:

All of NAREITʹs servers are locked in a separate climate controlled data room within the NAREIT suite. Access to the data room is restricted to authorized staff only. All servers and staff workstations require a username and password for access and have password enabled screen savers that engage after 10 minutes of inactivity. All of NAREITʹs systems and data are stored behind a corporate firewall to prevent unauthorized access. Any remote access into the system requires security credentials and those credentials are required to be changed at a minimum of every 45 days. Access to the financial accounting system is restricted to authroized staff only.

Controls in place to ensure physical security:

Building: The office NAREIT is located in is a secure building with 24-hour on-site security presence and monitoring. Access to the building is only possible with an electronic building key card.

Offices: Once in the building, access to NAREITʹs suite is only possible through an electronic key card which has been specifically programmed to grant access to our suite. After business hours, access is even further restricted as elevator access to the 6th floor (the floor where NAREITʹs suite is located) is only possible with a specifically programmed electronic key card. Suite access doors are also remotely monitored by Kastle Systems to assure suite security. NAREIT maintains video surveillance for its suite entrances as well.

Computer Equipment: All staff workstations require a username and password for access and have password enabled screen savers that engage after 10 minutes of inactivity. All laptops must be signed out for use outside the office and are routinely re-imaged back to a standard image.

Network Equipment: All of NAREITʹs network equipment and servers are locked in a separate climate controlled data room within the NAREIT suite. Access to the data room is restricted to authorized staff only.

Network Infrastructure: Suite access is limited to authroized staff only and electronic key cards are required to access the suite where network infrastrcture is in place.

Electronic Network Storage: All application CD⁄DVDs are stored in a locked fireproof cabinet in the locked data room in the NAREIT suite.
Physical Documents: Physical documents per policy should never leave the NAREIT office. NAREIT maintains locked filing systems for hard copies of any sensitive data and access to these files are restricted to authorized personnel only.

Controls in place to restrict access to networks:

All network access resides behind a secure firewall and all network access from outside the office is restricted to authorized password protected accounts only. Wireless networks require password access and guest access is on a separate VLAN that is kept isolated from NAREITʹs main network.

Controls in place to mitigate the risks from malware:
All of NAREITʹs systems are monitored for virus and malware via a centrally managed Symantec Endpoint Protection server. Security updates are pushed directly to all clients via a centrally managed server. All workstations have locked centrally managed Windows Active Directory Group Policies in place to prevent with tampering of existing security controls.

Controls in place to mitigate the risk from unpatched vulnerabilities in software:
All worktations have locked centrally managed Windows Active Directory Group Policies in place to prevent with tampering of existing security controls. All workstations receive security and software patches and updates via a centrally managed server which automatically applies the patches and updated to all clients.

Policies in place regarding user accounts and passwords:
All user accounts have passwords that expire every 45 days with specific restrictions on password reuse and specific requirements for password length, special characters, etc.

Maintaining contacts with relevant authorities:
NAREIT is able to maintain communications with relevant authorities via telephone communications through its own secure PBX system and cellular phones, secure electronic email or web based communications, US Postal mail, delivery services (such as FedEX and UPS), and courier services.