DotMusic Limited

19 Mesolongiou Street Lemesos - 3032 CY

+1 310 985 8661

+357 25363193

http://music.us

Constantinos Roussos

Founder

+1 310 985 8661

costa@music.us

Jason Schaeffer

COO

+1 267 971 6513

jason@music.us

Limited Liability Company (Ltd)

Cyprus Companies Law Republic of Cyprus, Ministry of Commerce, Industry and Tourism Department of Registrar of Companies and Receiver, Nicosia

Attachments are not displayed on this form.

MUSIC

Yes

The name of the community served is the ʺMusic Community” (ʺCommunityʺ). The parentheses below reflect ICANN’s Applicant Guidebook 4.2.3 Criterion Definitions; Delineation; Extension; Nexus; Uniqueness; Eligibility; Name Selection; Content and Use; Enforcement; Support; Opposition.
DotMusic will use clear, organized, consistent and interrelated criteria to demonstrate Community Establishment beyond reasonable doubt and incorporate safeguards in membership criteria “aligned with the community-based Purpose” and mitigate anti-trust and confidentiality⁄privacy concerns by protecting the Community of considerable size⁄extension while ensuring there is no material detriment to Community rights⁄legitimate interests. Registrants will be verified using Community-organized, unified “criteria taken from holistic perspective with due regard of Community particularities” that “invoke a formal membership” without discrimination, conflict of interest or “likelihood of material detriment to the rights and legitimate interests” of the Community:
(i) Qualification criteria as delineated by recognized NAICS codes corresponding to Community member classification music entity types. This classification-based delineation will also be consistent with registrant Premium Channel membership criteria (“ELIGIBILITY”)
(ii) Domain naming conditions (“NAME SELECTION”)
(iii) Restrictions relating to domain usage and content (“CONTENT & USE”)
(iv) Enforcement mechanisms to uphold Community Establishment and meet Nexus Criteria, consistent with our clear, organized delineation of the Community (“ENFORCEMENT”)
The Community is a strictly delineated and organized community of individuals, organizations and business, a “logical alliance of communities of a similar nature (“COMMUNITY”)”, that relate to music: the art of combining sounds rhythmically, melodically or harmonically. ʺMUSICʺ has no other significant meaning or name beyond the definition offered by popular dictionaries and encyclopedias that define ʺMUSICʺ as relating to “combining sounds rhythmically, melodically or harmonically (“UNIQUENESS”).” The Community corresponds to the community relating to “the art of combining sounds rhythmically, melodically and harmonically” (“IDENTIFY”). The Community is distinct, sharing similar needs and attitudinal and behavioral patterns in relation to music-related activities, music production and its consumption. The ʺMUSICʺ string matches the name (“NAME”) of the Community and is the established name by which the Community is commonly known by others, such as the traditional media using phrases such as the “MUSIC” artists, “MUSIC” producers and “MUSIC” publishers to classify commonly known Music Community entity types (“NEXUS”). “MUSIC” matches the name of the Community entirely and is unique since no-one commonly refers to classes relating to the “MUSIC” Community using alternative words to replace the established Community word “MUSIC” identifying the Community (“UNIQUENESS”). For example, using a “COMMUNITY string” plus “CLASS” methodology, no-one refers to “MUSIC” “ARTISTS” as “SONG” “ARTISTS.” The string “MUSIC” clearly identifies the Community and is unique and rarely replaceable in the Community language context perspective. Also the “MUSIC” string is commonly used in classification systems such as ISMN, ISRC, ISWC, ISNI and Dewey. For example, the Dewey Decimal Classification system, published in 1876 (LONGEVITY;PRE-EXISTING), has code 780 relating to “MUSIC”.
The Community served is defined as music stakeholders being structurally organized using pre-existing, strictly delineated classes (“DELINEATION”) and recognized criteria to clearly organize the Community (“ORGANIZED”) classified by:
• North American Industrial Classification System codes (NAICS) used by the Census Bureau (www.census.gov⁄eos⁄www⁄naics) and Federal statistical agencies as the classification standard for the purpose of collecting, analyzing, and publishing statistical data related to the U.S.
• United Nations International Standard Industrial Classification (ISIC) system (www.unstats.un.org⁄unsd⁄publication⁄seriesM⁄seriesm_4rev4e.pdf), to “delineate according to what is the customary combination of activities” (www.unstats.un.org⁄unsd⁄class⁄family⁄family2.asp?Cl=17), such as those representing the Community.

The Music Community is strictly delineated using established NAICS codes that align with the (i) characteristics of the globally recognized, organized Community, and (ii) .MUSIC global rotating multi-stakeholder Advisory Board model of fair representation, irrespective of locale, size or commercial⁄non-commercial status, organized with the following delineation (corresponding NAICS code in parenthesis):

• Musical groups and artists (711130)
• Independent music artists, performers, arrangers & composers (711500)
• Music publishers (512230)
• Music recording industries (512290)
• Music recording & rehearsal studios (512240)
• Music distributors, promoters & record labels (512220)
• Music production companies & record producers (512210)
• Live musical producers (711130)
• Musical instrument manufacturers (339992)
• Musical instruments & supplies stores (451140)
• Music stores (451220)
• Music accountants (541211)
• Music lawyers (541110)
• Musical groups & artists (711130)
• Music education & schools (611610)
• Music agents & managers (711400)
• Music promoters & performing arts establishments (711300)
• Music promoters of performing arts with facilities (711310)
• Music promoters of performing arts without facilities (711320)
• Music performing arts companies (711100)
• Other music performing arts companies (711190)
• Music record reproducing companies (334612)
• Music, audio and video equipment manufacturers (334310)
• Music radio networks (515111)
• Music radio stations (515112)
• Music archives & libraries (519120)
• Music business & management consultants (541611)
• Music collection agencies & performance rights organizations (561440)
• Music therapists (621340)
• Music business associations (813910)
• Music coalitions, associations, organizations, information centers & export offices (813920)
• Music unions (813930)
• Music public relations agencies (541820)
• Music journalists & bloggers (711510)
• Internet Music radio station (519130)
• Music broadcasters (515120)
• Music video producers (512110)
• Music marketing services (541613)
• Music & audio engineers (541330)
• Music ticketing (561599)
• Music recreation establishments (722410)
• Music fans⁄clubs (813410)

The Music Community’s geographic breadth is inclusive of all recognized territories covering regions associated with ISO-3166 codes and 193 United Nations countries (“EXTENSION”) with a Community of considerable size with millions of constituents (“SIZE”).

The Community has bought, sold, and bartered music for as long (“LONGEVITY”) as it has been made (R. Burnett, International Music Industry, 1996 and P. Gronow, International History of the Recording Industry, 1998). The Community is a delineated network where production and distribution of music occur in a process relying on labor division and technology. Under such structured context music consumption becomes possible regardless whether the transaction is commercial and non-commercial (M. Talbot, Business of Music, 2002). The foundation for the structured and strictly delineated Community only resulted from the interplay between the growing music publishing business and an emerging public music concert culture in the 18th century (“PRE-EXISTING”). Consequently, music publishers and concert promoters assumed the function of institutional gatekeepers of the Music Community who decided which music reached consumers and in what form, thus setting the parameters within which creativity was able to unfold (P. Tschmuck, Creativity & Innovation in the Music Industry, Institute of Culture Management & Culture Science, 2006).

DotMusic is a member of:
- International Federation of Arts Councils & Culture Agencies (IFACCA) serving a global community of arts councils and government ministries of culture representing over 70 countries (www.ifacca.org)
- American Association of Independent Music (A2IM) serving the independent Music Community (www.a2im.org)
- National Association of Recording Manufacturers (NARM) the music business association formed in 1958 (www.narm.com)
DotMusic was founded in 2004 under the Music.us umbrella by Community member Constantine Roussos, an independent musician, songwriter and certified sound engineer, who also produced albums for artists such as Family of Snail, Katie Quinlan, Some Change from US, Pigeon’s Rhythm and David Silverman. It was through his interactions with the Community that he recognized the opportunity for a safer and more trusted innovative, community-based music-themed TLD. He is also a member of the National Association of Recording Industry Professionals and other music organizations.
Other DotMusic team members include:
Robert Singerman: NARAS member with over 30 years of experience as an agent, manager, label executive, consultant, producer, venue programmer and music supervisor; represented R.E.M, Gipsy Kings, James Brown, Suzanne Vega, 10,000 Maniacs and others; directed the European Music Office for the European Commission (EU) and the French Music Export Office in the U.S; represents Brazilian music, funded by APEX, the Brazilian trade organization.
Ken Abdo: A known artist advocate; a life-long multi-instrumentalist⁄songwriter and former DJ; served as legal counsel to artists including Jonny Lang, Michelle Branch, Owl City and Hall & Oates.
Bob Donnelly: Music industry attorney with over 35 years of experience; 41-awarded platinum albums.
John Simson: A singer-songwriter; managed country artists who sold over 10 Million albums and won 6 Grammys; ex-director of SoundExchange, the first performing rights organization formed to collect digital performance royalties for sound recording copyright owners & artists; co-founded the Washington Area Music Association; ex-president of the NARAS⁄Grammys D.C. chapter; National Trustee of the Academy; Board of the Alliance of Artists & Record Companies; member of the Folk Alliance and the Country Music Association.
Paul Bezilla: Bassist in various bands; entertainment lawyer for over 25 years; clients included Frank Sinatra, Cher, Quincy Jones, Warner Bros, and Disney.
DotMusic is the only Community member with advanced professional technical, policy, and operational TLD management experience led by DNS veteran Tina Dam to meet DotMusic’s primary role: to launch, operate and maintain trusted Music Community-based TLD.
RELATION TO MUSIC COMMUNITY
Pursuant to its mission, DotMusic has been conducting extensive outreach to the Community since 2008 to brand itself and its mission to convey the benefits of .MUSIC and requesting Community support letters. Since 2008 DotMusic has led Music Community efforts to the ICANN community through dedicated participation at ICANN meetings and other DNS⁄new TLD related events. The mCMO domain allocation method during the Landrush phase was created by DotMusic to allow Community members to register through established Community organizations. During the General Registration phase the TLD is open to all Community members for registration but also restricted by Eligibility, Use and other Policies, including enhanced safeguards.
DotMusic has been a strong Community supporter and participant as demonstrated in its ongoing efforts to build a sustainable TLD with policies dedicated to match the needs of the Community using a multi-stakeholder model, while ensuring it is implemented in a manner fulfilling DNS and ICANN technical, political and legal requirements.
DotMusic has publicly branded itself in an open, transparent and accessible manner through differentiated .MUSIC-related sites, social media, online marketing and through tens of thousands of web discussions⁄media mentions. Over 1,500,000 have signed the .MUSIC Initiative petition; over 5 million have liked⁄followed DotMusic in popular social media sites; and a significant number of leading mCMOs have signed support⁄interest letters as demonstrated in response to question 20f.
Other activities include sponsorships of Community events such as SxSW, Midem, Billboard, CMJ, Digital Music Forum, SF Music Tech, SoundCtrl, Social Media Week, ASCAP Expo, Popkomm, Miami Music Festival, Future of Music Policy Summit, Bandwidth, New Music Park Thing and others.
Social Media presence includes:
- Myspace, the Internet’s largest music artist community (4.2 million friends: www.myspace.com⁄musicextension)
- Facebook, the world’s largest social media site (Over 100,000 likes on www.facebook.com⁄musicextension and www.facebook.com⁄DotMusic and about 5,000 group members on www.facebook.com⁄groups⁄46381289474)
- Twitter, the world’s largest micro-blogging site (220,000+ followers on www.twitter.com⁄mus, about 50,000 followers on www.twitter.com⁄DotMusic, about 60,000+ followers on www.twitter.com⁄musicextension, about 31,000+ on www.twitter.com⁄dot_music, about 21,000+ followers on www.twitter.com⁄musicdomain) and other social media sites
DotMusic also branded itself through earned media including:
- Forbes, Billboard, Hollywood Reporter, Los Angeles Times, Washington Post, World Trademark Review (www.music.us⁄news.htm), other mainstream publications, online press and thousands of blogs and social media mentions
- Google and Bing search engines have ranked the official DotMusic site (www.music.us) on the top of search engine results for the term “music” ((#23 Google, #25 Bing – March 6th, 2012), one of the most competitive keyword terms on the web according to Google Adwords (277 million global searches on Google, costing advertisers over $9k a day in clicks - www.music.us⁄adwords⁄google-adwords-keyword-music.jpg)
- The official DotMusic site ranks on the top of both Google’s and Bing’s search engines for terms such as “dotmusic”, “dot music”, “music domain”, “music TLD”, “music gTLD”, “music top-level domain”, “music generic top level domain” (www.music.us⁄seo)
A complete list of events relating to the ongoing outreach campaign can be found on www.music.us⁄events.htm
DotMusic will continue its active outreach and participation efforts in the Community and anticipates receipt of additional support letters from Community members throughout and beyond the ICANN TLD evaluation process.
ACCOUNTABILITY MECHANISMS
DotMusic will be accountable to the Community by serving them without conflicts of interest and:
- Creating and managing a trusted safe online haven for music consumption
- Establishing a safe home on the Internet for Community members to differentiate themselves regardless of locale, segment or size
- Enforcing registration policies that enhance and preserve the integrity of the Community
- Enabling music discovery & Community member promotion through Premium Channels
- Protecting intellectual property & fighting piracy
- Supporting musiciansʹ welfare, rights & fair compensation
- Promoting music and arts, cultural diversity and music education
- Following a neutral multi-stakeholder governance of fair representation of all global music constituents
- Soliciting Community advice through the Advisory Committee
- Offering registration from a proven, scalable registry platform with 100% DNS availability
The rotating, global Advisory Committee will represent all Community stakeholder groups per the NAICS codes list, such as musicians, songwriters, composers, industry professionals, collection agencies, associations, unions, businesses, education, arts councils⁄export offices⁄government agencies, managers, promoters and agents. The Committee will operate under Bylaws central to the .MUSIC Mission, Core Values, and commitment to serve the Community and public interest.

The .MUSIC mission⁄purpose is:
• Creating a trusted, safe online haven for music consumption
• Establishing a safe home on the Internet for Music Community members regardless of locale or size
• Protecting intellectual property and fighting piracy
• Supporting musiciansʹ welfare, rights & fair compensation
• Promoting music and the arts, cultural diversity and music education
• Following a multi-stakeholder approach of fair representation of all types of global music constituents, including a rotating regional advisory board working in the best interests of the Music Community

The Music Community encompasses global reaching commercial and non-commercial stakeholders, and amateur stakeholders.

.MUSIC will effectively differentiate itself by addressing the key online usage issues of safety, trust, consistency, brand recognition as well as communicate a websiteʹs content subject-matter: music-related content. The exclusivity of the .MUSIC TLD will be established by protection mechanisms for established Music Community entities, while also allowing Do-It-Yourself artists to register and use their .MUSIC domain consistent with .MUSIC Use Policy.

In addition to .MUSIC domain registrations, DotMusic will provide related services which have been established through ongoing outreach efforts. Music Community members need to be able to distinguish themselves from illegal and right infringing websites, a critical factor for the Music Community to ensure that monies flow to the right holders. DotMusic launch-related services are:

1. Developing the Music Community Social Network Premium Domain Channels (Premium Channels) sorted by NAICS classifications and category types e.g. genre⁄language. They will leverage Search Engine Optimization (SEO) best practices to improve .MUSIC site search result rankings. The objective is for .MUSIC domains to signal a badge of trust that enables search engines to provide music consumers more relevant and safer search results while reducing infringing and unlicensed rogue websites. Premium Channel development will also include a global Song Registry
2. Enriching society with artistic and cultural diversity; promoting arts and music through sponsorships, events and Music Community activities
3. Advancing music education and the study of music in school curriculum by donating proceeds of domain registrations to relevant causes
4. Re-inventing music discovery and search innovation by leading the way to establish the global music standard for official music websites to benefit the at-large global Music Community and the Internet

The .MUSIC mission and purpose has been established by interactions with Community members through numerous outreach activities and upon experiences gained in previous ICANN new gTLD launches. The mission⁄purpose is consistent with ICANN’s Affirmation of Commitments (AoC) and Basic Principles of the International Music Registry (IMR - with participants including RIAA, IFPI, SCAPR, ACTRA, SAMRO, IRSC, ECAD, CIAM), including:

- the “vital importance of transparency, openness and non-discrimination.” (www.internationalmusicregistry.org⁄portal⁄en⁄basic_principles.html) and
- “ensuring accountability, transparency and the interests of global Internet users”, “enhancing the operational stability, reliability, resiliency, security, and global interoperability of the DNS” and “promoting competition, consumer trust, and consumer choice” while “adequately addressing consumer protection, malicious abuse, and rights protection issues” (www.icann.org⁄en⁄about⁄agreements⁄aoc⁄affirmation-of-commitments-30sep09-en.htm).

DotMusic mission⁄purpose guiding principles:

TRANSPARENCY OPENNESS & ACCOUNTABILITY
DotMusic has been an accessible and transparently visible .MUSIC applicant since 2008 communicating its intentions publicly at music events, online through its website and social media outreach, and through mainstream and non-mainstream media. The .MUSIC registration policies and protection mechanisms have been developed using a bottom-up, multi-stakeholder methodology with input from international Music Community members in both the commercial and non-commercial sector.

DotMusic serves the Community without conflicts of interest and is accountable to the Community by establishing a Music Community Advisory Committee with representation from each constituency in the Community. The Committee will advise and provide perspective on .MUSIC issues such as broad policy matters and introductions of new services to meet the Community needs.

INTERNATIONAL COMMUNITY PARTICIPATION, COMMUNICATION AND OUTREACH
Since 2008, DotMusic has participated in over one hundred public events globally (full list: www.music.us⁄events.htm), including public speaking engagements, keynote addresses, major music and domain conferences, festivals, events and expos; earned media (broadcast, online and print) in major mainstream publications, online press, and thousands of blog and social media mentions; over 1.5 million emails of support; top search engine results for DotMusic website; and over 5 million social media followers; sponsored major Music Community events globally to explain the intended benefits of the .MUSIC TLD, requesting support and letters of intent or interest by supporters or Music Community Member Organizations (mCMO) for this .MUSIC application.

Specific details of the these activities can be found in response to question 18b(vi). Support letters are attached in response to question 20f (updated list can be found on www.music.us⁄letters).
.MUSIC is trademarked in over 20 countries; has been using the brand in commerce (www.music.us⁄commerce), advertising and sponsorships, in domain registrations as an authorized reseller, merchandising and other commercial activities.

STANDARDS COMPLIANCE, SECURITY, RESILIENCY, AND STABILITY
Afilias is the DNS Registry provider for .MUSIC. Details of technical and operational capabilities matching the .MUSIC mission are provided in responses to questions #24-44.

COMPETITION, INNOVATION, FAIRNESS, AND CONSUMER CHOICE
Balanced domain registration restrictions and an inclusive, delineated Community definition ensures the entire Music Community can register .MUSIC domains, provides fairness in .MUSIC domain availability, offers a branding advantage, avoid conflicts of interest, anti-competitive concerns and anti-trust actions.

The Premium Channels will maximize the competitive landscape and innovation in both the music and domain space.

INTELLECTUAL PROPERTY PROTECTION AND TRUST
In consultation with major music constituents, including multiple Coalitions (such as a Coalition that includes the RIAA, ASCAP, BMI, SESAC, IFPI, A2IM, FIM, CISAC, IMPALA, NMPA, SABAM, FIM and others), DotMusic has developed policies to protect intellectual property, fight piracy and ensure .MUSIC domains are allocated in fair methods so that music consumers and Internet users are assured the highest level of trust and authenticity when they visit a .MUSIC domain.

A Global Protected Marks List (GPML) will reserve all major music brands and established artists, such as RIAA-certified platinum-selling bands.

Phased launches provides rights holders a first-come in the .MUSIC Sunrise, auction of multiple initial landrush domain inquiries, and eventually allows all stakeholders of the Music Community to register. All registrants must adhere to restricted Use, Name and Anti-Abuse policies and other enhanced safeguards to prevent detrimental practices that harm the Community.

Dispute mechanisms, compliance efforts, and data validation processes will provide an added level of trust.

DotMusic will conduct reviews of the applicability, usability, overall Music Community satisfaction. Results will be publicly provided to the Music Community for feedback and looks forward to providing review results and expertise in the ICANN Post-Launch New gTLD Review.

No

DotMusic protects geographic names at the second level of .MUSIC by the following described measures. These have been developed in response to the GAC’s Principles regarding New gTLDs, dated March 28, 2007, and to adhere to the requirements of the ICANN Registry Agreement Specification 5.

In correspondence with GAC principle 2.7, DotMusic will block all country and territory names as registrations under .MUSIC. To accomplish this DotMusic will prior to launch (i) place the names on a reserved list that can solely be released as second-level registrations under .MUSIC by an agreement with the respective country or territory and with ICANN; and (ii) include in its registration policies that country and territory names are prohibited at lower levels.

The names reserved as country and territory names will correspond to the requirements in the ICANN Registry Agreement Specification 5, paragraph 5; and paragraph 2 where all two-character labels will be reserved for registration to ensure that any release of such names is done to the appropriate corresponding country or territory and thereby avoid user confusion.

When DotMusic is launching Internationalized Domain Names DotMusic will place translated versions of country and territory names on a reserved list that also only can be released for registration if an agreement has been reached with the corresponding country or territory and ICANN.

DotMusic will implement multiple dispute resolution policies to address dispute over any names not reserved by the above provisions; see response to question #20e and #28 and #29. In particular all domains awarded to registrants are subject to the Uniform Domain Name Dispute Resolution Policy (UDRP), and to any properly-situated court proceeding. DotMusic will ensure appropriate procedures to allow governments, public authorities or IGO’s to challenge abuses of names with national or geographic significance at the second level. DotMusic will institute a provision in the registry-registrar agreements and the registrar-registrant agreements, to suspend domains names in the event of a dispute. DotMusic may exercise that right in the case of a dispute over a geographic name.


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

DotMusic will be working closely with the International Federation of Arts Councils and Culture Agencies, with national members from over 70 countries comprised of governments’ Ministries of Culture and Arts Councils covering all continents, to ensure country names protection and the promotion of government-related cultural and music initiatives. Strategic partners include UNESCO, African Arts Institute, Asia-Pacific Regional Centre of the Culturelink Network, European League of Institutes of the Arts, European Research Institute for Comparative Cultural Policy and the Arts, European Commission Directorate General Education & Culture, Fundació Interarts, International Conference on Cultural Policy Research, International Network for Contemporary Performing Arts, International Federation of Coalitions for Cultural Diversity, International Network for Cultural Diversity, ISPA - International Society for the Performing Arts Foundation, National Assembly of State Arts Agencies, Organization of American States, Observatory of Cultural Policies in Africa, Organización de Estados Iberoamericanos, Caribbean and Pacific Group of States, United Cities and Local Governments.

Ministries of Culture Agencies and Arts Councils include:

Albania (Ministry of Tourism, Culture, Youth & Sport)
Armenia (Ministry of Culture)
Australia (Australia Council for the Arts)
Bahamas (Ministry of Youth, Sports & Culture)
Belgium (Fédération Wallonie-Bruxelles, Cabinet de la Culture)
Belgium (Ministry of the Flemish Community, Arts & Heritage)
Belize (National Institute of Culture & History)
Botswana (Department of Arts & Culture, Ministry of Youth, Sport & Culture)
Bulgaria (National Culture Fund)
Cambodia (Ministry of Culture & Fine Arts)
Canada (Canada Council for the Arts)
Cayman Islands (Cayman National Cultural Foundation)
Chile (Consejo Nacional de la Cultura y las Artes)
China (CFLAC - China Federation of Literary & Art Circles)
Colombia (Ministerio de Cultura de Colombia)
Cook Islands (Ministry of Cultural Development)
Croatia (Ministarstvo Kulture - Ministry of Culture)
Cuba (Ministerio de Cultura de la República de Cuba)
Denmark (Kulturstyrelsen - Danish Agency for Culture)
Egypt (Ministry of Culture)
England (Arts Council England)
Fiji (Fiji Arts Council)
Finland (Arts Council of Finland)
France (Ministère de la Culture et de la Communication de France)
Gambia (National Council for Arts & Culture of The Gambia)
Grenada (Grenada Arts Council)
Guyana (National Trust of Guyana, Ministry of Culture, Youth and Sport)
Hong Kong (Home Affairs Bureau, Culture Section Government of Hong Kong)
Iceland (Ministry of Education, Science & Culture)
India (Ministry of Culture)
Ireland (Arts Council of Ireland - An Chomhairle Ealaíon)
Jamaica (Ministry of Youth, Sport & Culture)
Japan (Japan Foundation)
Kenya (Bomas of Kenya)
Lithuania (Ministry of Culture)
Luxembourg (Ministère de la Culture)
Malawi (Ministry of Tourism, Wildlife & Culture)
Malaysia (Ministry of Information, Communication & Culture)
Maldives (Ministry of Tourism, Arts & Culture)
Malta (Malta Council for Culture and the Arts)
Mongolia (Ministry of Education, Culture & Science)
Mozambique (Ministério da Cultura)
Namibia (National Arts Council of Namibia)
Netherlands (Mondriaan Fund)
Netherlands (Nederlands Fonds voor Podiumkunsten, Fund for Performing Arts)
Netherlands (Nederlands Letterenfonds - Dutch Foundation for Literature)
Netherlands (Raad voor Cultuur - Council for Culture)
Netherlands (SICA - Stichting Internationale Culturele Activiteiten)
New Zealand (Creative New Zealand - Toi Aotearoa)
Niger (Ministere de la Communication, des Nouvelles Techonologies de lʹInformation et de la Culture)
Nigeria (National Council for Arts & Culture)
Northern Ireland (Arts Council of Northern Ireland)
Norway (Norsk Kulturråd - Arts Council Norway)
Palau (Ministry of Community & Cultural Affairs)
Papua New Guinea (Ministry of Culture & Tourism)
Philippines (National Commission for Culture & the Arts)
Portugal (Direcção-Geral das Artes)
Qatar (Ministry of Culture, Arts & Heritage)
Romania (Ministry of Culture & National Heritage)
Saudi Arabia (Ministry of Culture & Information)
Scotland (Creative Scotland)
Senegal (Ministère de la Culture et du Tourisme)
Serbia (International Cultural Centre Belgrade)
Seychelles (Ministry of Community Development, Youth, Sport & Culture)
Singapore (National Arts Council of Singapore)
Slovenia (Ministry of Education, Science, Culture and Sport)
Solomon Islands (Ministry of Culture & Tourism)
South Africa (National Arts Council of South Africa)
South Korea (Arts Council Korea)
Spain (Secretaría de Estado de Cultura, España)
Swaziland (Swaziland National Council of Arts and Culture)
Sweden (Statens Kulturråd - Swedish Arts Council)
Switzerland (Pro Helvetia - Swiss Arts Council)
Tanzania (Basata: National Arts Council)
Tunisia (Ministry of Culture)
United Arab Emirates (Sharjah Museums Council)
USA (National Endowment for the Arts)
USA (National Endowment for the Humanities)
Vietnam (Ministry of Culture, Sports & Tourism)
Wales (Cygnor Celfyddydau Cymru - Arts Council of Wales)
Zambia (National Arts Council of Zambia)
Zimbabwe (National Arts Council of Zimbabwe)

DotMusic also has support from the International Association of Music Information Centres (IAMIC), a global network of organizations which document and promote the music from our time. IAMIC will also help .MUSIC with its outreach efforts relating to the protection of country-name domains and the allocation of the domains to the proper government authorities to promote culture and music from those territories. IAMIC “supports the work of 40 member organizations in 37 countries. Music Information Centers across the world bear fundamental similarities: they provide specialized music resources for music students, performers, composers and music teachers; they act as visitor centers for any member of the public with an interest in learning about national musical heritage; they develop audiences for new music through educational and promotional projects.”
These include:
Australia (Australian Music Centre)
Austria (MICA - Music Information Center Austria)
Belgium (Flanders Music Centre)
Belgium (CEBEDEM - Belgian Centre for Music Documentation)
Belgium (MATRIX)
Brazil (CIDDIC-Brasil⁄UNICAMP)
Canada (Canadian Music Centre)
Croatia (Croatian Music Information Centre KDZ)
Cyprus (Cyprus Music Information Center - CyMIC)
Czech Republic (Czech Music Information Centre)
Denmark (Danish Arts Agency - Music Centre)
England (Sound and Music - SAM)
Estonia (Estonian Music Information Centre)
Finland (Finnish Music Information Centre Fimic)
France (CDMC - Centre de documentation de la musique contemporaine)
Georgia (Georgian Music Information Centre)
Germany (German Music Information Centre)
Greece (Greek Music Information Centre ⁄ Institute for Research on Music and Acoustics)
Hungary (BMC Hungarian Music Information Center)
Iceland (Iceland Music Information Centre)
Ireland (Contemporary Music Centre, Ireland)
Israel (Israel Music Information Centre ⁄ Israel Music Institute)
Italy (CIDIM ⁄ AMIC)
Latvia (Latvian Music Information Centre - LMIC)
Lithuania (Lithuanian Music Information and Publishing Centre)
Luxembourg (Luxembourg Music Information Centre)
Netherlands (Netherlands Music Information Centre)
New Zealand (Centre for New Zealand Music - SOUNZ)
Norway (Music Information Centre Norway)
Poland (Polish Music Information Centre)
Portugal (Portuguese Music Research & Information Centre ⁄ Miso Music Portugal)
Scotland (Scottish Music Centre)
Slovakia (Music Centre Slovakia)
Slovenia (Slovene Music Information Centre)
South Africa (Music Communication Centre of Southern Africa - MCCOSA)
Sweden (Svensk Musik)
Switzerland (Fondation SUISA pour la musique)
USA (American Music Center)
Wales (Ty Cerdd - Welsh Music Information Centre)

DotMusic already holds support from multiple music export offices from different countries⁄territories. The music export offices are typically run by government agencies, and have expressed and signed letters of interest to administer the corresponding [countryname⁄territoryname.MUSIC] in an appropriate manner that benefits the music industry for that corresponding country⁄territory. The support gathered this far is attached in response to question #20, is publicly available at www.music.us⁄letters. DotMusic expects additional interest expressed from other countries and territories as the DotMusic outreach continues.

Other GAC Principles regarding New gTLDs are defined elsewhere in this application, for example methods for limiting the need for defensive registrations in paragraph 2.9 is described in response to question #18b and #20e.

Throughout the technical portion (#23 - #44) of this application, answers are provided directly from Afilias, the back-end provider of registry services for this TLD. DotMusic chose Afilias as its back-end provider because Afilias has more experience successfully applying to ICANN and launching new TLDs than any other provider. Afilias is the ICANN-contracted registry operator of the .INFO and .MOBI TLDs, and Afilias is the back-end registry services provider for other ICANN TLDs including .ORG, .ASIA, .AERO, and .XXX.

Registry services for this TLD will be performed by Afilias in the same responsible manner used to support 16 top level domains today. Afilias supports more ICANN-contracted TLDs (6) than any other provider currently. Afilias’ primary corporate mission is to deliver secure, stable and reliable registry services. This TLD will utilize an existing, proven team and platform for registry services with:
• A stable and secure, state-of-the-art, EPP-based SRS with ample storage capacity, data security provisions and scalability that is proven with registrars who account for over 95% of all gTLD domain name registration activity (over 375 registrars);
• A reliable, 100% available DNS service (zone file generation, publication and dissemination) tested to withstand severe DDoS attacks and dramatic growth in Internet use;
• A WHOIS service that is flexible and standards compliant, with search capabilities to address both registrar and end-user needs; includes consideration for evolving standards, such as RESTful, or draft-kucherawy-wierds;
• Experience introducing IDNs in the following languages: German (DE), Spanish (ES), Polish (PL), Swedish (SV), Danish (DA), Hungarian (HU), Icelandic (IS), Latvian (LV), Lithuanian (LT), Korean (KO), Simplified and Traditional Chinese (CN), Devanagari (HI-DEVA), Russian (RU), Belarusian (BE), Ukrainian (UK), Bosnian (BS), Serbian (SR), Macedonian (MK) and Bulgarian (BG) across the TLDs it serves;
• A registry platform that is both IPv6 and DNSSEC enabled;
• An experienced, respected team of professionals active in standards development of innovative services such as DNSSEC and IDN support;
• Methods to limit domain abuse, remove outdated and inaccurate data, and ensure the integrity of the SRS, and;
• Customer support and reporting capabilities to meet financial and administrative needs, e.g., 24x7 call center support, integration support, billing, and daily, weekly, and monthly reporting.

Afilias will support this TLD in accordance with the specific policies and procedures of DotMusic (the “registry operator”), leveraging a proven registry infrastructure that is fully operational, staffed with professionals, massively provisioned, and immediately ready to launch and maintain this TLD.

The below response includes a description of the registry services to be provided for this TLD, additional services provided to support registry operations, and an overview of Afilias’ approach to registry management.

Registry services to be provided
To support this TLD, DotMusic and Afilias will offer the following registry services, all in accordance with relevant technical standards and policies:
• Receipt of data from registrars concerning registration for domain names and nameservers, and provision to registrars of status information relating to the EPP-based domain services for registration, queries, updates, transfers, renewals, and other domain management functions. Please see our responses to questions #24, #25, and #27 for full details, which we request be incorporated here by reference.
• Operation of the registry DNS servers: The Afilias DNS system, run and managed by Afilias, is a massively provisioned DNS infrastructure that utilizes among the most sophisticated DNS architecture, hardware, software and redundant design created. Afilias’ industry-leading system works in a seamless way to incorporate nameservers from any number of other secondary DNS service vendors. Please see our response to question #35 for full details, which we request be incorporated here by reference.
• Dissemination of TLD zone files: Afilias’ distinctive architecture allows for real-time updates and maximum stability for zone file generation, publication and dissemination. Please see our response to question #34 for full details, which we request be incorporated here by reference.
• Dissemination of contact or other information concerning domain registrations: A port 43 WHOIS service with basic and expanded search capabilities with requisite measures to prevent abuse. Please see our response to question #26 for full details, which we request be incorporated here by reference.
• Internationalized Domain Names (IDNs): Ability to support all protocol valid Unicode characters at every level of the TLD, including alphabetic, ideographic and right-to-left scripts, in conformance with the ICANN IDN Guidelines. Please see our response to question #44 for full details, which we request be incorporated here by reference.
• DNS Security Extensions (DNSSEC): A fully DNSSEC-enabled registry, with a stable and efficient means of signing and managing zones. This includes the ability to safeguard keys and manage keys completely. Please see our response to question #43 for full details, which we request be incorporated here by reference.

Each service will meet or exceed the contract service level agreement. All registry services for this TLD will be provided in a standards-compliant manner.

Security
Afilias addresses security in every significant aspect – physical, data and network as well as process. Afilias’ approach to security permeates every aspect of the registry services provided. A dedicated security function exists within the company to continually identify existing and potential threats, and to put in place comprehensive mitigation plans for each identified threat. In addition, a rapid security response plan exists to respond comprehensively to unknown or unidentified threats. The specific threats and Afilias mitigation plans are defined in our response to question #30(b); please see that response for complete information. In short, Afilias is committed to ensuring the confidentiality, integrity, and availability of all information.

New registry services

No new registry services are planned for the launch of this TLD.

Additional services to support registry operation
Numerous supporting services and functions facilitate effective management of the TLD. These support services are also supported by Afilias, including:
• Customer support: 24x7 live phone and e-mail support for customers to address any access, update or other issues they may encounter. This includes assisting the customer identification of the problem as well as solving it. Customers include registrars and the registry operator, but not registrants except in unusual circumstances. Customers have access to a web-based portal for a rapid and transparent view of the status of pending issues.
• Financial services: billing and account reconciliation for all registry services according to pricing established in respective agreements.

Reporting is an important component of supporting registry operations. Afilias will provide reporting to the registry operator and registrars, and financial reporting.

Reporting provided to registry operator
Afilias provides an extensive suite of reports to the registry operator, including daily, weekly and monthly reports with data at the transaction level that enable the registry operator to track and reconcile at whatever level of detail preferred. Afilias provides the exact data required by ICANN in the required format to enable the registry operator to meet its technical reporting requirements to ICANN.

In addition, Afilias offers access to a data warehouse capability that will enable near real-time data to be available 24x7. This can be arranged by informing the Afilias Account Manager regarding who should have access. Afilias’ data warehouse capability enables drill-down analytics all the way to the transaction level.

Reporting available to registrars
Afilias provides an extensive suite of reporting to registrars and has been doing so in an exemplary manner for more than ten years. Specifically, Afilias provides daily, weekly and monthly reports with detail at the transaction level to enable registrars to track and reconcile at whatever level of detail they prefer.

Reports are provided in standard formats, facilitating import for use by virtually any registrar analytical tool. Registrar reports are available for download via a secure administrative interface. A given registrar will only have access to its own reports. These include the following:
• Daily Reports: Transaction Report, Billable Transactions Report, and Transfer Reports;
• Weekly: Domain Status and Nameserver Report, Weekly Nameserver Report, Domains Hosted by Nameserver Weekly Report, and;
• Monthly: Billing Report and Monthly Expiring Domains Report.

Weekly registrar reports are maintained for each registrar for four weeks. Weekly reports older than four weeks will be archived for a period of six months, after which they will be deleted.

Financial reporting
Registrar account balances are updated real-time when payments and withdrawals are posted to the registrarsʹ accounts. In addition, the registrar account balances are updated as and when they perform billable transactions at the registry level.

Afilias provides Deposit⁄Withdrawal Reports that are updated periodically to reflect payments received or credits and withdrawals posted to the registrar accounts.

The following reports are also available: a) Daily Billable Transaction Report, containing details of all the billable transactions performed by all the registrars in the SRS, b) daily e-mail reports containing the number of domains in the registry and a summary of the number and types of billable transactions performed by the registrars, and c) registry operator versions of most registrar reports (for example, a daily Transfer Report that details all transfer activity between all of the registrars in the SRS).


Afilias approach to registry support
Afilias, the back end registry services provider for this TLD, is dedicated to managing the technical operations and support of this TLD in a secure, stable and reliable manner. Afilias has worked closely with DotMusic to review specific needs and objectives of this TLD. The resulting comprehensive plans are illustrated in technical responses #24-44, drafted by Afilias given DotMusic requirements. Afilias and DotMusic also worked together to provide financial responses for this application which demonstrate cost and technology consistent with the size and objectives of this TLD.

Afilias is the registry services provider for this and several other TLD applications. Over the past 11 years of providing services for gTLD and ccTLDs, Afilias has accumulated experience about resourcing levels necessary to provide high quality services with conformance to strict service requirements. Afilias currently supports over 20 million domain names, spread across 16 TLDs, with over 400 accredited registrars.

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

With over a decade of registry experience, Afilias has the depth and breadth of experience that ensure existing and new needs are addressed, all while meeting or exceeding service level requirements and customer expectations. This is evident in Afilias’ participation in business, policy and technical organizations supporting registry and Internet technology within ICANN and related organizations. This allows Afilias to be at the forefront of security initiatives such as: DNSSEC, wherein Afilias worked with Public Interest Registry (PIR) to make the .ORG registry the first DNSSEC enabled gTLD and the largest TLD enabled at the time; in enhancing the Internet experience for users across the globe by leading development of IDNs; in pioneering the use of open-source technologies by its usage of PostgreSQL, and; being the first to offer near-real-time dissemination of DNS zone data.

The ability to observe tightening resources for critical functions and the capacity to add extra resources ahead of a threshold event are factors that Afilias is well versed in. Afilias’ human resources team, along with well-established relationships with external organizations, enables it to fill both long-term and short-term resource needs expediently.

Afilias’ growth from a few domains to serving 20 million domain names across 16 TLDs and 400 accredited registrars indicates that the relationship between the number of people required and the volume of domains supported is not linear. In other words, servicing 100 TLDs does not automatically require 6 times more staff than servicing 16 TLDs. Similarly, an increase in the number of domains under management does not require in a linear increase in resources. Afilias carefully tracks the relationship between resources deployed and domains to be serviced, and pro-actively reviews this metric in order to retain a safe margin of error. This enables Afilias to add, train and prepare new staff well in advance of the need, allowing consistent delivery of high quality services.

THE RESPONSE FOR THIS QUESTION USES ANGLE BRACKETS (THE “〈” and “〉” CHARACTERS, or 〈 and 〉), WHICH ICANN INFORMS US (CASE ID 11027)
CANNOT BE PROPERLY RENDERED IN TAS DUE TO SECURITY CONCERNS. HENCE, THE ANSWER BELOW AS DISPLAYED IN TAS MAY NOT RENDER THE FULL RESPONSE AS INTENDED. THEREFORE, THE FULL ANSWER TO THIS QUESTION IS ALSO ATTACHED AS A PDF FILE, ACCORDING TO SPECIFIC GUIDANCE FROM ICANN UNDER CASE ID 11027.

Answers for this question (#24) are provided directly from Afilias, the back-end provider of registry services for this TLD.

Afilias operates a state-of-the-art EPP-based Shared Registration System (SRS) that is secure, stable and reliable. The SRS is a critical component of registry operations that must balance the business requirements for the registry and its customers, such as numerous domain acquisition and management functions. The SRS meets or exceeds all ICANN requirements given that Afilias:
• Operates a secure, stable and reliable SRS which updates in real-time and in full compliance with Specification 6 of the new gTLD Registry Agreement;
• Is committed to continuously enhancing our SRS to meet existing and future needs;
• Currently exceeds contractual requirements and will perform in compliance with Specification 10 of the new gTLD Registry Agreement;
• Provides SRS functionality and staff, financial, and other resources to more than adequately meet the technical needs of this TLD, and;
• Manages the SRS with a team of experienced technical professionals who can seamlessly integrate this TLD into the Afilias registry platform and support the TLD in a secure, stable and reliable manner.

Description of operation of the SRS, including diagrams
Afilias’ SRS provides the same advanced functionality as that used in the .INFO and .ORG registries, as well as the fourteen other TLDs currently supported by Afilias. The Afilias registry system is standards-compliant and utilizes proven technology, ensuring global familiarity for registrars, and it is protected by our massively provisioned infrastructure that mitigates the risk of disaster.

EPP functionality is described fully in our response to question #25; please consider those answers incorporated here by reference. An abbreviated list of Afilias SRS functionality includes:
• Domain registration: Afilias provides registration of names in the TLD, in both ASCII and IDN forms, to accredited registrars via EPP and a web-based administration tool.
• Domain renewal: Afilias provides services that allow registrars the ability to renew domains under sponsorship at any time. Further, the registry performs the automated renewal of all domain names at the expiration of their term, and allows registrars to rescind automatic renewals within a specified number of days after the transaction for a full refund.
• Transfer: Afilias provides efficient and automated procedures to facilitate the transfer of sponsorship of a domain name between accredited registrars. Further, the registry enables bulk transfers of domains under the provisions of the Registry-Registrar Agreement.
• RGP and restoring deleted domain registrations: Afilias provides support for the Redemption Grace Period (RGP) as needed, enabling the restoration of deleted registrations.
• Other grace periods and conformance with ICANN guidelines: Afilias provides support for other grace periods that are evolving as standard practice inside the ICANN community. In addition, the Afilias registry system supports the evolving ICANN guidelines on IDNs.

Afilias also supports the basic check, delete, and modify commands.

As required for all new gTLDs, Afilias provides “thick” registry system functionality. In this model, all key contact details for each domain are stored in the registry. This allows better access to domain data and provides uniformity in storing the information.

Afilias’ SRS complies today and will continue to comply with global best practices including relevant RFCs, ICANN requirements, and this TLD’s respective domain policies. With over a decade of experience, Afilias has fully documented and tested policies and procedures, and our highly skilled team members are active participants of the major relevant technology and standards organizations, so ICANN can be assured that SRS performance and compliance are met. Full details regarding the SRS system and network architecture are provided in responses to questions #31 and #32; please consider those answers incorporated here by reference.

SRS servers and software
All applications and databases for this TLD will run in a virtual environment currently hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors. (It is possible that by the time this application is evaluated and systems deployed, Westmere processors may no longer be the “latest”; the Afilias policy is to use the most advanced, stable technology available at the time of deployment.) The data for the registry will be stored on storage arrays of solid state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources, thus reducing energy consumption and carbon footprint.

The network firewalls, routers and switches support all applications and servers. Hardware traffic shapers are used to enforce an equitable access policy for connections coming from registrars. The registry system accommodates both IPv4 and IPv6 addresses. Hardware load balancers accelerate TLS⁄SSL handshaking and distribute load among a pool of application servers.

Each of the servers and network devices are equipped with redundant, hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with a four-hour response time at all our data centers guarantee replacement of failed parts in the shortest time possible.

Examples of current system and network devices used are:
• Servers: Cisco UCS B230 blade servers
• SAN storage arrays: IBM Storwize V7000 with Solid State Drives
• SAN switches: Brocade 5100
• Firewalls: Cisco ASA 5585-X
• Load balancers: F5 Big-IP 6900
• Traffic shapers: Procera PacketLogic PL8720
• Routers: Juniper MX40 3D
• Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

These system components are upgraded and updated as required, and have usage and performance thresholds which trigger upgrade review points. In each data center, there is a minimum of two of each network component, a minimum of 25 servers, and a minimum of two storage arrays.

Technical components of the SRS include the following items, continually checked and upgraded as needed: SRS, WHOIS, web admin tool, DNS, DNS distributor, reporting, invoicing tools, and deferred revenue system (as needed).

All hardware is massively provisioned to ensure stability under all forecast volumes from launch through “normal” operations of average daily and peak capacities. Each and every system application, server, storage and network device is continuously monitored by the Afilias Network Operations Center for performance and availability. The data gathered is used by dynamic predictive analysis tools in real-time to raise alerts for unusual resource demands. Should any volumes exceed established thresholds, a capacity planning review is instituted which will address the need for additions well in advance of their actual need.

SRS diagram and interconnectivity description
As with all core registry services, the SRS is run from a global cluster of registry system data centers, located in geographic centers with high Internet bandwidth, power, redundancy and availability. All of the registry systems will be run in a 〈n+1〉 setup, with a primary data center and a secondary data center. For detailed site information, please see our responses to questions #32 and #35. Registrars access the SRS in real-time using EPP.

A sample of the Afilias SRS technical and operational capabilities (displayed in Figure 24-a) include:
• Geographically diverse redundant registry systems;
• Load balancing implemented for all registry services (e.g. EPP, WHOIS, web admin) ensuring equal experience for all customers and easy horizontal scalability;
• Disaster Recovery Point objective for the registry is within one minute of the loss of the primary system;
• Detailed and tested contingency plan, in case of primary site failure, and;
• Daily reports, with secure access for confidentiality protection.

As evidenced in Figure 24-a, the SRS contains several components of the registry system. The interconnectivity ensures near-real-time distribution of the data throughout the registry infrastructure, timely backups, and up-to-date billing information.

The WHOIS servers are directly connected to the registry database and provide real-time responses to queries using the most up-to-date information present in the registry.

Committed DNS-related EPP objects in the database are made available to the DNS Distributor via a dedicated set of connections. The DNS Distributor extracts committed DNS-related EPP objects in real time and immediately inserts them into the zone for dissemination.

The Afilias system is architected such that read-only database connections are executed on database replicas and connections to the database master (where write-access is executed) are carefully protected to ensure high availability.

This interconnectivity is monitored, as is the entire registry system, according to the plans detailed in our response to question #42.

Synchronization scheme
Registry databases are synchronized both within the same data center and in the backup data center using a database application called Slony. For further details, please see the responses to questions #33 and #37. Slony replication of transactions from the publisher (master) database to its subscribers (replicas) works continuously to ensure the publisher and its subscribers remain synchronized. When the publisher database completes a transaction the Slony replication system ensures that each replica also processes the transaction. When there are no transactions to process, Slony “sleeps” until a transaction arrives or for one minute, whichever comes first. Slony “wakes up” each minute to confirm with the publisher that there has not been a transaction and thus ensures subscribers are synchronized and the replication time lag is minimized. The typical replication time lag between the publisher and subscribers depends on the topology of the replication cluster, specifically the location of the subscribers relative to the publisher. Subscribers located in the same data center as the publisher are typically updated within a couple of seconds, and subscribers located in a secondary data center are typically updated in less than ten seconds. This ensures real-time or near-real-time synchronization between all databases, and in the case where the secondary data center needs to be activated, it can be done with minimal disruption to registrars.

SRS SLA performance compliance
Afilias has a ten-year record of delivering on the demanding ICANN SLAs, and will continue to provide secure, stable and reliable service in compliance with SLA requirements as specified in the new gTLD Registry Agreement, Specification 10, as presented in Figure 24-b.

The Afilias SRS currently handles over 200 million EPP transactions per month for just .INFO and .ORG. Overall, the Afilias SRS manages over 700 million EPP transactions per month for all TLDs under management.

Given this robust functionality, and more than a decade of experience supporting a thick TLD registry with a strong performance history, Afilias, on behalf of DotMusic, will meet or exceed the performance metrics in Specification 10 of the new gTLD Registry Agreement. The Afilias services and infrastructure are designed to scale both vertically and horizontally without any downtime to provide consistent performance as this TLD grows. The Afilias architecture is also massively provisioned to meet seasonal demands and marketing campaigns. Afilias’ experience also gives high confidence in the ability to scale and grow registry operations for this TLD in a secure, stable and reliable manner.

SRS resourcing plans
Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Over 100 Afilias team members contribute to the management of the SRS code and network that will support this TLD. The SRS team is composed of Software Engineers, Quality Assurance Analysts, Application Administrators, System Administrators, Storage Administrators, Network Administrators, Database Administrators, and Security Analysts located at three geographically separate Afilias facilities. The systems and services set up and administered by these team members are monitored 24x7 by skilled analysts at two NOCs located in Toronto, Ontario (Canada) and Horsham, Pennsylvania (USA). In addition to these team members, Afilias also utilizes trained project management staff to maintain various calendars, work breakdown schedules, utilization and resource schedules and other tools to support the technical and management staff. It is this team who will both deploy this TLD on the Afilias infrastructure, and maintain it. Together, the Afilias team has managed 11 registry transitions and six new TLD launches, which illustrate its ability to securely and reliably deliver regularly scheduled updates as well as a secure, stable and reliable SRS service for this TLD.

Answers for this question (#25) are provided by Afilias, the back-end provider of registry services for this TLD.

Afilias has been a pioneer and innovator in the use of EPP. .INFO was the first EPP-based gTLD registry and launched on EPP version 02⁄00. Afilias has a track record of supporting TLDs on standards-compliant versions of EPP. Afilias will operate the EPP registrar interface as well as a web-based interface for this TLD in accordance with RFCs and global best practices. In addition, Afilias will maintain a proper OT&E (Operational Testing and Evaluation) environment to facilitate registrar system development and testing.

Afilias’ EPP technical performance meets or exceeds all ICANN requirements as demonstrated by:
• A completely functional, state-of-the-art, EPP-based SRS that currently meets the needs of various gTLDs and will meet this new TLD’s needs;
• A track record of success in developing extensions to meet client and registrar business requirements such as multi-script support for IDNs;
• Supporting six ICANN gTLDs on EPP: .INFO, .ORG, .MOBI, .AERO, .ASIA and .XXX
• EPP software that is operating today and has been fully tested to be standards-compliant;
• Proven interoperability of existing EPP software with ICANN-accredited registrars, and;
• An SRS that currently processes over 200 million EPP transactions per month for both .INFO and .ORG. Overall, Afilias processes over 700 million EPP transactions per month for all 16 TLDs under management.

The EPP service is offered in accordance with the performance specifications defined in the new gTLD Registry Agreement, Specification 10.

EPP Standards
The Afilias registry system complies with the following revised versions of the RFCs and operates multiple ICANN TLDs on these standards, including .INFO, .ORG, .MOBI, .ASIA and .XXX. The systems have been tested by our Quality Assurance (“QA”) team for RFC compliance, and have been used by registrars for an extended period of time:
• 3735 - Guidelines for Extending EPP
• 3915 - Domain Registry Grace Period Mapping
• 5730 - Extensible Provisioning Protocol (EPP)
• 5731 - Domain Name Mapping
• 5732 - Host Mapping
• 5733 - Contact Mapping
• 5734 - Transport Over TCP
• 5910 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

This TLD will support all valid EPP commands. The following EPP commands are in operation today and will be made available for this TLD. See attachment #25a for the base set of EPP commands and copies of Afilias XSD schema files, which define all the rules of valid, RFC compliant EPP commands and responses that Afilias supports. Any customized EPP extensions, if necessary, will also conform to relevant RFCs.

Afilias staff members actively participated in the Internet Engineering Task Force (IETF) process that finalized the new standards for EPP. Afilias will continue to actively participate in the IETF and will stay abreast of any updates to the EPP standards.

EPP software interface and functionality
Afilias will provide all registrars with a free open-source EPP toolkit. Afilias provides this software for use with both Microsoft Windows and Unix⁄Linux operating systems. This software, which includes all relevant templates and schema defined in the RFCs, is available on sourceforge.net and will be available through the registry operator’s website.

Afilias’ SRS EPP software complies with all relevant RFCs and includes the following functionality:
• EPP Greeting: A response to a successful connection returns a greeting to the client. Information exchanged can include: name of server, server date and time in UTC, server features, e.g., protocol versions supported, languages for the text response supported, and one or more elements which identify the objects that the server is capable of managing;
• Session management controls: 〈login〉 to establish a connection with a server, and 〈logout〉 to end a session;
• EPP Objects: Domain, Host and Contact for respective mapping functions;
• EPP Object Query Commands: Info, Check, and Transfer (query) commands to retrieve object information, and;
• EPP Object Transform Commands: five commands to transform objects: 〈create〉 to create an instance of an object, 〈delete〉 to remove an instance of an object, 〈renew〉 to extend the validity period of an object, 〈update〉 to change information associated with an object, and 〈transfer〉 to manage changes in client sponsorship of a known object.

Currently, 100% of the top domain name registrars in the world have software that has already been tested and certified to be compatible with the Afilias SRS registry. In total, over 375 registrars, representing over 95% of all registration volume worldwide, operate software that has been certified compatible with the Afilias SRS registry. Afilias’ EPP Registrar Acceptance Criteria are available in attachment #25b, EPP OT&E Criteria.

Free EPP software support
Afilias analyzes and diagnoses registrar EPP activity log files as needed and is available to assist registrars who may require technical guidance regarding how to fix repetitive errors or exceptions caused by misconfigured client software.

Registrars are responsible for acquiring a TLS⁄SSL certificate from an approved certificate authority, as the registry-registrar communication channel requires mutual authentication; Afilias will acquire and maintain the server-side TLS⁄SSL certificate. The registrar is responsible for developing support for TLS⁄SSL in their client application. Afilias will provide free guidance for registrars unfamiliar with this requirement.

Registrar data synchronization
There are two methods available for registrars to synchronize their data with the registry:
• Automated synchronization: Registrars can, at any time, use the EPP 〈info〉 command to obtain definitive data from the registry for a known object, including domains, hosts (nameservers) and contacts.
• Personalized synchronization: A registrar may contact technical support and request a data file containing all domains (and associated host (nameserver) and contact information) registered by that registrar, within a specified time interval. The data will be formatted as a comma separated values (CSV) file and made available for download using a secure server.

EPP modifications
There are no unique EPP modifications planned for this TLD.

All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. These extensions are:
• An 〈ipr:name〉 element that indicates the name of Registered Mark.
• An 〈ipr:number〉 element that indicates the registration number of the IPR.
• An 〈ipr:ccLocality〉 element that indicates the origin for which the IPR is established (a national or international trademark registry).
• An 〈ipr:entitlement〉 element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
• An 〈ipr:appDate〉 element that indicates the date the Registered Mark was applied for.
• An 〈ipr:regDate〉 element that indicates the date the Registered Mark was issued and registered.
• An 〈ipr:class〉 element that indicates the class of the registered mark.
• An 〈ipr:type〉 element that indicates the Sunrise phase the application applies for.

Note that some of these extensions might be subject to change based on ICANN-developed requirements for the Trademark Clearinghouse.

EPP resourcing plans
Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

108 Afilias team members directly contribute to the management and development of the EPP based registry systems. As previously noted, Afilias is an active member of IETF and has a long documented history developing and enhancing EPP. These contributors include 11 developers and 14 QA engineers focused on maintaining and enhancing EPP server side software. These engineers work directly with business staff to timely address existing needs and forecast registry⁄registrar needs to ensure the Afilias EPP software is effective today and into the future. A team of eight data analysts work with the EPP software system to ensure that the data flowing through EPP is securely and reliably stored in replicated database systems. In addition to the EPP developers, QA engineers, and data analysts, other EPP contributors at Afilias include: Technical Analysts, the Network Operations Center and Data Services team members.

Answers for this question (#26) are provided by Afilias, the back-end provider of registry services for this TLD.

Afilias operates the WHOIS (registration data directory service) infrastructure in accordance with RFCs and global best practices, as it does for the 16 TLDs it currently supports. Designed to be robust and scalable, Afilias’ WHOIS service has exceeded all contractual requirements for over a decade. It has extended search capabilities, and methods of limiting abuse.

The WHOIS service operated by Afilias meets and exceeds ICANN’s requirements. Specifically, Afilias will:
• Offer a WHOIS service made available on port 43 that is flexible and standards- compliant;
• Comply with all ICANN policies, and meeting or exceeding WHOIS performance requirements in Specification 10 of the new gTLD Registry Agreement;
• Enable a Searchable WHOIS with extensive search capabilities that offers ease of use while enforcing measures to mitigate access abuse, and;
• Employ a team with significant experience managing a compliant WHOIS service.

Such extensive knowledge and experience managing a WHOIS service enables Afilias to offer a comprehensive plan for this TLD that meets the needs of constituents of the domain name industry and Internet users. The service has been tested by our QA team for RFC compliance, and has been used by registrars and many other parties for an extended period of time. Afilias’ WHOIS service currently serves almost 500 million WHOIS queries per month, with the capacity already built in to handle an order of magnitude increase in WHOIS queries, and the ability to smoothly scale should greater growth be needed.

WHOIS system description and diagram
The Afilias WHOIS system, depicted in figure 26-a, is designed with robustness, availability, compliance, and performance in mind. Additionally, the system has provisions for detecting abusive usage (e.g., excessive numbers of queries from one source). The WHOIS system is generally intended as a publicly available single object lookup system. Afilias uses an advanced, persistent caching system to ensure extremely fast query response times.

Afilias will develop restricted WHOIS functions based on specific domain policy and regulatory requirements as needed for operating the business (as long as they are standards compliant). It will also be possible for contact and registrant information to be returned according to regulatory requirements. The WHOIS database supports multiple string and field searching through a reliable, free, secure web-based interface.

Data objects, interfaces, access and lookups
Registrars can provide an input form on their public websites through which a visitor is able to perform WHOIS queries. The registry operator can also provide a Web-based search on its site. The input form must accept the string to query, along with the necessary input elements to select the object type and interpretation controls. This input form sends its data to the Afilias port 43 WHOIS server. The results from the WHOIS query are returned by the server and displayed in the visitor’s Web browser. The sole purpose of the Web interface is to provide a user-friendly interface for WHOIS queries.

Afilias will provide WHOIS output as per Specification 4 of the new gTLD Registry Agreement. The output for domain records generally consists of the following elements:
• The name of the domain registered and the sponsoring registrar;
• The names of the primary and secondary nameserver(s) for the registered domain name;
• The creation date, registration status and expiration date of the registration;
• The name, postal address, e-mail address, and telephone and fax numbers of the domain name holder;
• The name, postal address, e-mail address, and telephone and fax numbers of the technical contact for the domain name holder;
• The name, postal address, e-mail address, and telephone and fax numbers of the administrative contact for the domain name holder, and;
• The name, postal address, e-mail address, and telephone and fax numbers of the billing contact for the domain name holder.
The following additional features are also present in Afilias’ WHOIS service:
• Support for IDNs, including the language tag and the Punycode representation of the IDN in addition to Unicode Hex and Unicode HTML formats;
• Enhanced support for privacy protection relative to the display of confidential information.

Afilias will also provide sophisticated WHOIS search functionality that includes the ability to conduct multiple string and field searches.

Query controls
For all WHOIS queries, a user is required to enter the character string representing the information for which they want to search. The object type and interpretation control parameters to limit the search may also be specified. If object type or interpretation control parameter is not specified, WHOIS will search for the character string in the Name field of the Domain object.

WHOIS queries are required to be either an ʺexact searchʺ or a ʺpartial search,ʺ both of which are insensitive to the case of the input string.

An exact search specifies the full string to search for in the database field. An exact match between the input string and the field value is required.

A partial search specifies the start of the string to search for in the database field. Every record with a search field that starts with the input string is considered a match. By default, if multiple matches are found for a query, then a summary containing up to 50 matching results is presented. A second query is required to retrieve the specific details of one of the matching records.

If only a single match is found, then full details will be provided. Full detail consists of the data in the matching object as well as the data in any associated objects. For example: a query that results in a domain object includes the data from the associated host and contact objects.

WHOIS query controls fall into two categories: those that specify the type of field, and those that modify the interpretation of the input or determine the level of output to provide. Each is described below.

The following keywords restrict a search to a specific object type:
• Domain: Searches only domain objects. The input string is searched in the Name field.
• Host: Searches only nameserver objects. The input string is searched in the Name field and the IP Address field.
• Contact: Searches only contact objects. The input string is searched in the ID field.
• Registrar: Searches only registrar objects. The input string is searched in the Name field.
By default, if no object type control is specified, then the Name field of the Domain object is searched.

In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names. Deployment of these features is provided as an option to the registry operator, based upon registry policy and business decision making.

Figure 26-b presents the keywords that modify the interpretation of the input or determine the level of output to provide.

By default, if no interpretation control keywords are used, the output will include full details if a single match is found and a summary if multiple matches are found.

Unique TLD requirements
There are no unique WHOIS requirements for this TLD.

Sunrise WHOIS processes
All ICANN TLDs must offer a Sunrise as part of a rights protection program. Afilias uses EPP extensions that allow registrars to submit trademark and other intellectual property rights (IPR) data to the registry. The following corresponding data will be displayed in WHOIS for relevant domains:
• Trademark Name: element that indicates the name of the Registered Mark.
• Trademark Number: element that indicates the registration number of the IPR.
• Trademark Locality: element that indicates the origin for which the IPR is established (a national or international trademark registry).
• Trademark Entitlement: element that indicates whether the applicant holds the trademark as the original “OWNER”, “CO-OWNER” or “ASSIGNEE”.
• Trademark Application Date: element that indicates the date the Registered Mark was applied for.
• Trademark Registration Date: element that indicates the date the Registered Mark was issued and registered.
• Trademark Class: element that indicates the class of the Registered Mark.
• IPR Type: element that indicates the Sunrise phase the application applies for.

IT and infrastructure resources
All the applications and databases for this TLD will run in a virtual environment hosted by a cluster of servers equipped with the latest Intel Westmere multi-core processors (or a more advanced, stable technology available at the time of deployment). The registry data will be stored on storage arrays of solid-state drives shared over a fast storage area network. The virtual environment allows the infrastructure to easily scale both vertically and horizontally to cater to changing demand. It also facilitates effective utilization of system resources thus reducing energy consumption and carbon footprint.

The applications and servers are supported by network firewalls, routers and switches.
The WHOIS system accommodates both IPv4 and IPv6 addresses.

Each of the servers and network devices are equipped with redundant hot-swappable components and multiple connections to ancillary systems. Additionally, 24x7 support agreements with our hardware vendor with a 4-hour response time at all our data centers guarantees replacement of failed parts in the shortest time possible.

Models of system and network devices used are:
• Servers: Cisco UCS B230 blade servers
• SAN storage arrays: IBM Storwize V7000 with Solid State Drives
• Firewalls: Cisco ASA 5585-X
• Load balancers: F5 Big-IP 6900
• Traffic shapers: Procera PacketLogic PL8720
• Routers: Juniper MX40 3D
• Network switches: Cisco Nexus 7010, Nexus 5548, Nexus 2232

There will be at least four virtual machines (VMs) offering WHOIS service. Each VM will run at least two WHOIS server instances - one for registrars and one for the public. All instances of the WHOIS service is made available to registrars and the public are rate limited to mitigate abusive behavior.

Frequency of synchronization between servers
Registration data records from the EPP publisher database will be replicated to the WHOIS system database on a near-real-time basis whenever an update occurs.

Specifications 4 and 10 compliance
The WHOIS service for this TLD will meet or exceed the performance requirements in the new gTLD Registry Agreement, Specification 10. Figure 26-c provides the exact measurements and commitments. Afilias has a 10 year track record of exceeding WHOIS performance and a skilled team to ensure this continues for all TLDs under management.

The WHOIS service for this TLD will meet or exceed the requirements in the new gTLD Registry Agreement, Specification 4.

RFC 3912 compliance
Afilias will operate the WHOIS infrastructure in compliance with RFCs and global best practices, as it does with the 16 TLDs Afilias currently supports.

Afilias maintains a registry-level centralized WHOIS database that contains information for every registered domain and for all host and contact objects. The WHOIS service will be available on the Internet standard WHOIS port (port 43) in compliance with RFC 3912. The WHOIS service contains data submitted by registrars during the registration process. Changes made to the data by a registrant are submitted to Afilias by the registrar and are reflected in the WHOIS database and service in near-real-time, by the instance running at the primary data center, and in under ten seconds by the instance running at the secondary data center, thus providing all interested parties with up-to-date information for every domain. This service is compliant with the new gTLD Registry Agreement, Specification 4.

The WHOIS service maintained by Afilias will be authoritative and complete, as this will be a “thick” registry (detailed domain contact WHOIS is all held at the registry); users do not have to query different registrars for WHOIS information, as there is one central WHOIS system. Additionally, visibility of different types of data is configurable to meet the registry operator’s needs.

Searchable WHOIS
Afilias offers a searchable WHOIS on a web-based Directory Service. Partial match capabilities are offered on the following fields: domain name, registrar ID, and IP address. In addition, Afilias WHOIS systems can perform and respond to WHOIS searches by registrant name, postal address and contact names.

Providing the ability to search important and high-value fields such as registrant name, address and contact names increases the probability of abusive behavior. An abusive user could script a set of queries to the WHOIS service and access contact data in order to create or sell a list of names and addresses of registrants in this TLD. Making the WHOIS machine readable, while preventing harvesting and mining of WHOIS data, is a key requirement integrated into the Afilias WHOIS systems. For instance, Afilias limits search returns to 50 records at a time. If bulk queries were ever necessary (e.g., to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process), Afilias makes such query responses available to carefully screened and limited staff members at the registry operator (and customer support staff) via an internal data warehouse. The Afilias WHOIS system accommodates anonymous access as well as pre-identified and profile-defined uses, with full audit and log capabilities.

The WHOIS service has the ability to tag query responses with labels such as “Do not redistribute” or “Special access granted”. This may allow for tiered response and reply scenarios. Further, the WHOIS service is configurable in parameters and fields returned, which allow for flexibility in compliance with various jurisdictions, regulations or laws.

Afilias offers exact-match capabilities on the following fields: registrar ID, nameserver name, and nameserver’s IP address (only applies to IP addresses stored by the registry, i.e., glue records). Search capabilities are fully available, and results include domain names matching the search criteria (including IDN variants). Afilias manages abuse prevention through rate limiting and CAPTCHA (described below). Queries do not require specialized transformations of internationalized domain names or internationalized data fields

Please see “Query Controls” above for details about search options and capabilities.

Deterring WHOIS abuse
Afilias has adopted two best practices to prevent abuse of the WHOIS service: rate limiting and CAPTCHA.

Abuse of WHOIS services on port 43 and via the Web is subject to an automated rate-limiting system. This ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system.

Abuse of web-based public WHOIS services is subject to the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) technology. The use of CAPTCHA ensures that uniformity of service to users is unaffected by a few parties whose activities abuse or otherwise might threaten to overload the WHOIS system. The registry operator will adopt a CAPTCHA on its Web-based WHOIS.

Data mining of any sort on the WHOIS system is strictly prohibited, and this prohibition is published in WHOIS output and in terms of service.

For rate limiting on IPv4, there are configurable limits per IP and subnet. For IPv6, the traditional limitations do not apply. Whenever a unique IPv6 IP address exceeds the limit of WHOIS queries per minute, the same rate-limit for the given 64 bits of network prefix that the offending IPv6 IP address falls into will be applied. At the same time, a timer will start and rate-limit validation logic will identify if there are any other IPv6 address within the original 80-bit(⁄48) prefix. If another offending IPv6 address does fall into the ⁄48 prefix then rate-limit validation logic will penalize any other IPv6 addresses that fall into that given 80-bit (⁄48) network. As a security precaution, Afilias will not disclose these limits.

Pre-identified and profile-driven role access allows greater granularity and configurability in both access to the WHOIS service, and in volume⁄frequency of responses returned for queries.

Afilias staff are key participants in the ICANN Security & Stability Advisory Committee’s deliberations and outputs on WHOIS, including SAC003, SAC027, SAC033, SAC037, SAC040, and SAC051. Afilias staff are active participants in both technical and policy decision making in ICANN, aimed at restricting abusive behavior.

WHOIS staff resourcing plans
Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Within Afilias, there are 11 staff members who develop and maintain the compliant WHOIS systems. They keep pace with access requirements, thwart abuse, and continually develop software. Of these resources, approximately two staffers are typically required for WHOIS-related code customization. Other resources provide quality assurance, and operations personnel maintain the WHOIS system itself. This team will be responsible for the implementation and on-going maintenance of the new TLD WHOIS service.

Rights protection is a core responsibility of the TLD operator, and is supported by a fully-developed plan for rights protection that includes:
• Establishing mechanisms to prevent unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies);
• Implementing a robust Sunrise program, utilizing the Trademark Clearinghouse, the services of one of ICANN’s approved dispute resolution providers, a trademark validation agent, and drawing upon sunrise policies and rules used successfully in previous gTLD launches;
• Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
• Complying with the URS requirements;
• Complying with the UDRP;
• Complying with the PDDRP,
• Complying with the RRDRP and;
• Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.

The response below details the rights protection mechanisms at the launch of the TLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, PDDRP, RRDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans.

Safeguards for rights protection at the launch of the TLD
The launch of this TLD will include the operation of a trademark claims service according to the defined ICANN processes for checking a registration request and alerting trademark holders of potential rights infringement.

Sunrise Period

The Sunrise Period will be an exclusive period of time, prior to the opening of public registration, when trademark and service mark holders will be able to submit registration applications for domain names that correspond to their marks. Following the Sunrise Period, and Landrush Period DotMusic will open registration to first-come-first-serve registrants.

The anticipated Rollout Schedule for the Sunrise Period will be as follows:

Phase 1: 60 days Sunrise Period for trademark holders and service mark holders to submit applications for .MUSIC domain name registrations corresponding to their marks. To maximize fairness multiple registration applications for the same domain name will be decided upon via auctions. A 30 day Quite Period will follow the sunrise period for testing and evaluation.

Phase 2: 60 days Music Community Member Organization Landrush: a limited-time period reserved for members of DotMusic-accredited Music Community Member Organizations (mCMO). Multiple registration requests for the same string will be decided upon via an auction. A 30 day Quite Period will follow this phase as well to allow for testing and evaluation.

One month after close of Quiet Period – Registration in the TLD domain will be opened for general availability. Domains will be registered on a first-come-first-serve basis.

Sunrise Period Requirements & Restrictions
To be eligible for participation in the Sunrise Phase of .MUSIC a trademark holder must fulfill the requirements set forth in the 11 January 2012 ICANN Applicant Guidebook, Trademark Clearinghouse Specification, section 7.2; or any subsequent updates thereto.

Currently the Sunrise eligibility requirements (SERs) include: (i) ownership of a mark that satisfies the criteria set forth in section 7.2 of the Trademark Clearing House specifications, (ii) description of international class of goods or services covered by registration; (iii) representation that all provided information is true and correct; and (iv) provision of data sufficient to document rights in the trademark.

The Sunrise Dispute Resolution Policy (SDRP) will allow challenges based on the following four grounds: (i) at time the challenged domain name was registered, the registrants did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received. The established grounds may change as ICANN is finalizing Sunrise requirements in its Trademark Clearing House specification.

Sunrise registrations can be made in terms of 1, 2, 3, 5, or 10 year registrations.


Ongoing rights protection mechanisms
Several mechanisms will be in place to protect rights in this TLD. As described in our responses to questions #27 and #28, measures are in place to ensure domain transfers and updates are only initiated by the appropriate domain holder, and an experienced team is available to respond to legal actions by law enforcement or court orders.

This TLD will conform to all ICANN RPMs including URS (defined below), UDRP, PDDRP, and all measures defined in Specification 7 of the new TLD agreement.

Uniform Rapid Suspension (URS)
The registry operator will implement decisions rendered under the URS on an ongoing basis. Per the URS policy posted on ICANN’s Web site as of this writing, the registry operator will receive notice of URS actions from the ICANN-approved URS providers. These emails will be directed immediately to the registry operator’s support staff, which is on duty 24x7. The support staff will be responsible for creating a ticket for each case, and for executing the directives from the URS provider. All support staff will receive pertinent training.

As per ICANN’s URS guidelines, within 24 hours of receipt of the notice of complaint from the URS provider, the registry operator shall “lock” the domain, meaning the registry shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will remain in the TLD DNS zone file and will thus continue to resolve. The support staff will “lock” the domain by associating the following EPP statuses with the domain and relevant contact objects:
• ServerUpdateProhibited, with an EPP reason code of “URS”
• ServerDeleteProhibited, with an EPP reason code of “URS”
• ServerTransferProhibited, with an EPP reason code of “URS”
• The registry operator’s support staff will then notify the URS provider immediately upon locking the domain name, via email.

The registry operator’s support staff will retain all copies of emails from the URS providers, assign them a tracking or ticket number, and will track the status of each opened URS case through to resolution via spreadsheet or database.

The registry operator’s support staff will execute further operations upon notice from the URS providers. The URS provider is required to specify the remedy and required actions of the registry operator, with notification to the registrant, the complainant, and the registrar.

As per the URS guidelines, if the complainant prevails, the “registry operator shall suspend the domain name, which shall remain suspended for the balance of the registration period and would not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS provider about the URS. The WHOIS for the domain name shall continue to display all of the information of the original registrant except for the redirection of the nameservers. In addition, the WHOIS shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.”

Community TLD considerations
As described in response to question #20e and #28 DotMusic will implement several policies surrounding .MUSIC to fulfill the mission in support of Music Community needs. The applicable requirements will be validated at time of registration, and in addition ongoing use, naming, and anti-abuse policies are also in place to ensure continued establishment of a safe and secure TLD that is not only operated but used in the interest of the Music Community. A dedicated dispute resolution policy is in place to solve disputes concerning infringement of the .MUSIC Policy.

Rights protection via the RRA
The following will be memorialized and be made binding via the Registry-Registrar and Registrar-Registrant Agreements:

• The registry may reject a registration request or a reservation request, or may delete, revoke, suspend, cancel, or transfer a registration or reservation under the following criteria:
a. to enforce registry policies and ICANN requirements; each as amended from time to time;
b. that is not accompanied by complete and accurate information as required by ICANN requirements and⁄or registry policies or where required information is not updated and⁄or corrected as required by ICANN requirements and⁄or registry policies;
c. to protect the integrity and stability of the registry, its operations, and the TLD system;
d. to comply with any applicable law, regulation, holding, order, or decision issued by a court, administrative authority, or dispute resolution service provider with jurisdiction over the registry;
e. to establish, assert, or defend the legal rights of the registry or a third party or to avoid any civil or criminal liability on the part of the registry and⁄or its affiliates, subsidiaries, officers, directors, representatives, employees, contractors, and stockholders;
f. to correct mistakes made by the registry or any accredited registrar in connection with a registration; or
g. as otherwise provided in the Registry-Registrar Agreement and⁄or the Registrar-Registrant Agreement.

Reducing opportunities for behaviors such as phishing or pharming
In our response to question #28, the registry operator has described its anti-abuse program. Rather than repeating the policies and procedures here, please see our response to question #28 for full details.

With specific respect to phishing and pharming, it should be noted .MUSIC with its specified registration price, (detailed in response to questions #45-50), and restrictions and protections in regards to registrations and usage of the domains (detailed in response to question #20e) under it is considered a low risk target for such attacks. This is confirmed by McAfee’s 2011 security report (http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf stating that low-priced domains are more vulnerable for such attacks, and restricted TLDs bear low risks. Further, per the Anti-Phishing Working Group surveys and activities that is and will be monitored by DotMusic; the latest study shows that in 2011 only 2% of domain names used for phishing were targeting brand names, corresponding to 5,700 names.

Since all criminal activity (such as phishing and pharming) is a small percentage of domain registrations overall and precluded by the mission, values and policies of DotMusic and .MUSIC, criminal activity is not expected to be a problem. If such activity occurs due to hacking or other compromises, the registry operator will take prompt and effective steps to eliminate the activity.

In the case of this TLD, DotMusic will apply an approach that addresses registered domain names (rather than potentially registered domains). This approach will not infringe upon the rights of eligible registrants to register domains, and allows DotMusic internal controls, as well as community-developed UDRP and URS policies and procedures if needed, to deal with complaints, should there be any.

Afilias is a member of various security fora which provide access to lists of names in each TLD which may be used for malicious purposes. Such identified names will be subject to the TLD anti-abuse policy, including rapid suspensions after due process.

Rights protection resourcing plans
Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way.

Supporting RPMs requires several departments within the registry operator as well as within Afilias. The implementation of Sunrise and the Trademark Claims service and on-going RPM activities will pull from the 102 Afilias staff members of the engineering, product management, development, security and policy teams at Afilias and the support staff of the registry operator, which is on duty 24x7. A trademark validator will also be assigned within the registry operator, whose responsibilities may require as much as 50% of full-time employment if the domains under management were to exceed several million. No additional hardware or software resources are required to support this as Afilias has fully-operational capabilities to manage abuse today.

The answer to question #30a is provided by Afilias, the back-end provider of registry services for this TLD.

Afilias aggressively and actively protects the registry system from known threats and vulnerabilities, and has deployed an extensive set of security protocols, policies and procedures to thwart compromise. Afilias’ robust and detailed plans are continually updated and tested to ensure new threats are mitigated prior to becoming issues. Afilias will continue these rigorous security measures, which include:
• Multiple layers of security and access controls throughout registry and support systems;
• 24x7 monitoring of all registry and DNS systems, support systems and facilities;
• Unique, proven registry design that ensures data integrity by granting only authorized access to the registry system, all while meeting performance requirements;
• Detailed incident and problem management processes for rapid review, communications, and problem resolution, and;
• Yearly external audits by independent, industry-leading firms, as well as twice-yearly internal audits.

Security policies and protocols
Afilias has included security in every element of its service, including facilities, hardware, equipment, connectivity⁄Internet services, systems, computer systems, organizational security, outage prevention, monitoring, disaster mitigation, and escrow⁄insurance, from the original design, through development, and finally as part of production deployment. Examples of threats and the confidential and proprietary mitigation procedures are detailed in our response to question #30(b).

There are several important aspects of the security policies and procedures to note:
• Afilias hosts domains in data centers around the world that meet or exceed global best practices.
• Afilias’ DNS infrastructure is massively provisioned as part of its DDoS mitigation strategy, thus ensuring sufficient capacity and redundancy to support new gTLDs.
• Diversity is an integral part of all of our software and hardware stability and robustness plan, thus avoiding any single points of failure in our infrastructure.
• Access to any element of our service (applications, infrastructure and data) is only provided on an as-needed basis to employees and a limited set of others to fulfill their job functions. The principle of least privilege is applied.
• All registry components – critical and non-critical – are monitored 24x7 by staff at our NOCs, and the technical staff has detailed plans and procedures that have stood the test of time for addressing even the smallest anomaly. Well-documented incident management procedures are in place to quickly involve the on-call technical and management staff members to address any issues.

Afilias follows the guidelines from the ISO 27001 Information Security Standard (Reference: http:⁄⁄www.iso.org⁄iso⁄iso_catalogue⁄catalogue_tc⁄catalogue_detail.htm?csnumber=42103 ) for the management and implementation of its Information Security Management System. Afilias also utilizes the COBIT IT governance framework to facilitate policy development and enable controls for appropriate management of risk (Reference: http:⁄⁄www.isaca.org⁄cobit). Best practices defined in ISO 27002 are followed for defining the security controls within the organization. Afilias continually looks to improve the efficiency and effectiveness of our processes, and follows industry best practices as defined by the IT Infrastructure Library, or ITIL (Reference: http:⁄⁄www.itil-officialsite.com⁄).

The Afilias registry system is located within secure data centers that implement a multitude of security measures both to minimize any potential points of vulnerability and to limit any damage should there be a breach. The characteristics of these data centers are described fully in our response to question #30(b).

The Afilias registry system employs a number of multi-layered measures to prevent unauthorized access to its network and internal systems. Before reaching the registry network, all traffic is required to pass through a firewall system. Packets passing to and from the Internet are inspected, and unauthorized or unexpected attempts to connect to the registry servers are both logged and denied. Management processes are in place to ensure each request is tracked and documented, and regular firewall audits are performed to ensure proper operation. 24x7 monitoring is in place and, if potential malicious activity is detected, appropriate personnel are notified immediately.

Afilias employs a set of security procedures to ensure maximum security on each of its servers, including disabling all unnecessary services and processes and regular application of security-related patches to the operating system and critical system applications. Regular external vulnerability scans are performed to verify that only services intended to be available are accessible.

Regular detailed audits of the server configuration are performed to verify that the configurations comply with current best security practices. Passwords and other access means are changed on a regular schedule and are revoked whenever a staff member’s employment is terminated.

Access to registry system
Access to all production systems and software is strictly limited to authorized operations staff members. Access to technical support and network operations teams where necessary are read only and limited only to components required to help troubleshoot customer issues and perform routine checks. Strict change control procedures are in place and are followed each time a change is required to the production hardware⁄application. User rights are kept to a minimum at all times. In the event of a staff member’s employment termination, all access is removed immediately.

Afilias applications use encrypted network communications. Access to the registry server is controlled. Afilias allows access to an authorized registrar only if each of the authentication factors matches the specific requirements of the requested authorization. These mechanisms are also used to secure any web-based tools that allow authorized registrars to access the registry. Additionally, all write transactions in the registry (whether conducted by authorized registrars or the registryʹs own personnel) are logged.

EPP connections are encrypted using TLS⁄SSL, and mutually authenticated using both certificate checks and login⁄password combinations. Web connections are encrypted using TLS⁄SSL for an encrypted tunnel to the browser, and authenticated to the EPP server using login⁄password combinations.

All systems are monitored for security breaches from within the data center and without, using both system-based and network-based testing tools. Operations staff also monitor systems for security-related performance anomalies. Triple-redundant continual monitoring ensures multiple detection paths for any potential incident or problem. Details are provided in our response to questions #30(b) and #42. Network Operations and Security Operations teams perform regular audits in search of any potential vulnerability.

To ensure that registrar hosts configured erroneously or maliciously cannot deny service to other registrars, Afilias uses traffic shaping technologies to prevent attacks from any single registrar account, IP address, or subnet. This additional layer of security reduces the likelihood of performance degradation for all registrars, even in the case of a security compromise at a subset of registrars.

There is a clear accountability policy that defines what behaviors are acceptable and unacceptable on the part of non-staff users, staff users, and management. Periodic audits of policies and procedures are performed to ensure that any weaknesses are discovered and addressed. Aggressive escalation procedures and well-defined Incident Response management procedures ensure that decision makers are involved at early stages of any event.

In short, security is a consideration in every aspect of business at Afilias, and this is evidenced in a track record of a decade of secure, stable and reliable service.

Independent assessment
Supporting operational excellence as an example of security practices, Afilias performs a number of internal and external security audits each year of the existing policies, procedures and practices for:
• Access control;
• Security policies;
• Production change control;
• Backups and restores;
• Batch monitoring;
• Intrusion detection, and
• Physical security.

Afilias has an annual Type 2 SSAE 16 audit performed by PricewaterhouseCoopers (PwC). Further, PwC performs testing of the general information technology controls in support of the financial statement audit. A Type 2 report opinion under SSAE 16 covers whether the controls were properly designed, were in place, and operating effectively during the audit period (calendar year). This SSAE 16 audit includes testing of internal controls relevant to Afiliasʹ domain registry system and processes. The report includes testing of key controls related to the following control objectives:
• Controls provide reasonable assurance that registrar account balances and changes to the registrar account balances are authorized, complete, accurate and timely.
• Controls provide reasonable assurance that billable transactions are recorded in the Shared Registry System (SRS) in a complete, accurate and timely manner.
• Controls provide reasonable assurance that revenue is systemically calculated by the Deferred Revenue System (DRS) in a complete, accurate and timely manner.
• Controls provide reasonable assurance that the summary and detail reports, invoices, statements, registrar and registry billing data files, and ICANN transactional reports provided to registry operator(s) are complete, accurate and timely.
• Controls provide reasonable assurance that new applications and changes to existing applications are authorized, tested, approved, properly implemented and documented.
• Controls provide reasonable assurance that changes to existing system software and implementation of new system software are authorized, tested, approved, properly implemented and documented.
• Controls provide reasonable assurance that physical access to data centers is restricted to properly authorized individuals.
• Controls provide reasonable assurance that logical access to system resources is restricted to properly authorized individuals.
• Controls provide reasonable assurance that processing and backups are appropriately authorized and scheduled and that deviations from scheduled processing and backups are identified and resolved.

The last Type 2 report issued was for the year 2010, and it was unqualified, i.e., all systems were evaluated with no material problems found.

During each year, Afilias monitors the key controls related to the SSAE controls. Changes or additions to the control objectives or activities can result due to deployment of new services, software enhancements, infrastructure changes or process enhancements. These are noted and after internal review and approval, adjustments are made for the next review.

In addition to the PricewaterhouseCoopers engagement, Afilias performs internal security audits twice a year. These assessments are constantly being expanded based on risk assessments and changes in business or technology.

Additionally, Afilias engages an independent third-party security organization, PivotPoint Security, to perform external vulnerability assessments and penetration tests on the sites hosting and managing the Registry infrastructure. These assessments are performed with major infrastructure changes, release of new services or major software enhancements. These independent assessments are performed at least annually. A report from a recent assessment is attached with our response to question #30(b).

Afilias has engaged with security companies specializing in application and web security testing to ensure the security of web-based applications offered by Afilias, such as the Web Admin Tool (WAT) for registrars and registry operators.

Finally, Afilias has engaged IBM’s Security services division to perform ISO 27002 gap assessment studies so as to review alignment of Afilias’ procedures and policies with the ISO 27002 standard. Afilias has since made adjustments to its security procedures and policies based on the recommendations by IBM.

Special TLD considerations
Afilias’ rigorous security practices are regularly reviewed; if there is a need to alter or augment procedures for this TLD, they will be done so in a planned and deliberate manner.

Commitments to registrant protection
With over a decade of experience protecting domain registration data, Afilias understands registrant security concerns. Afilias supports a “thick” registry system in which data for all objects are stored in the registry database that is the centralized authoritative source of information. As an active member of IETF (Internet Engineering Task Force), ICANN’s SSAC (Security & Stability Advisory Committee), APWG (Anti-Phishing Working Group), MAAWG (Messaging Anti-Abuse Working Group), USENIX, and ISACA (Information Systems Audits and Controls Association), the Afilias team is highly attuned to the potential threats and leading tools and procedures for mitigating threats. As such, registrants should be confident that:
• Any confidential information stored within the registry will remain confidential;
• The interaction between their registrar and Afilias is secure;
• The Afilias DNS system will be reliable and accessible from any location;
• The registry system will abide by all polices, including those that address registrant data;
• Afilias will not introduce any features or implement technologies that compromise access to the registry system or that compromise registrant security.

Afilias has directly contributed to the development of the documents listed below and we have implemented them where appropriate. All of these have helped improve registrants’ ability to protect their domains name(s) during the domain name lifecycle.
• [SAC049]: SSAC Report on DNS Zone Risk Assessment and Management (03 June 2011)
• [SAC044]: A Registrantʹs Guide to Protecting Domain Name Registration Accounts (05 November 2010)
• [SAC040]: Measures to Protect Domain Registration Services Against Exploitation or Misuse (19 August 2009)
• [SAC028]: SSAC Advisory on Registrar Impersonation Phishing Attacks (26 May 2008)
• [SAC024]: Report on Domain Name Front Running (February 2008)
• [SAC022]: Domain Name Front Running (SAC022, SAC024) (20 October 2007)
• [SAC011]: Problems caused by the non-renewal of a domain name associated with a DNS Name Server (7 July 2006)
• [SAC010]: Renewal Considerations for Domain Name Registrants (29 June 2006)
• [SAC007]: Domain Name Hijacking Report (SAC007) (12 July 2005)

To protect any unauthorized modification of registrant data, Afilias mandates TLS⁄SSL transport (per RFC 5246) and authentication methodologies for access to the registry applications. Authorized registrars are required to supply a list of specific individuals (five to ten people) who are authorized to contact the registry. Each such individual is assigned a pass phrase. Any support requests made by an authorized registrar to registry customer service are authenticated by registry customer service. All failed authentications are logged and reviewed regularly for potential malicious activity. This prevents unauthorized changes or access to registrant data by individuals posing to be registrars or their authorized contacts.

These items reflect an understanding of the importance of balancing data privacy and access for registrants, both individually and as a collective, worldwide user base.

The Afilias 24⁄7 Customer Service Center consists of highly trained staff who collectively are proficient in 15 languages, and who are capable of responding to queries from registrants whose domain name security has been compromised – for example, a victim of domain name hijacking. Afilias provides specialized registrant assistance guides, including specific hand-holding and follow-through in these kinds of commonly occurring circumstances, which can be highly distressing to registrants

Security resourcing plans
Please refer to our response to question #30b for security resourcing plans.