ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Stockholms kommun

String: stockholm

Originally Posted: 13 June 2012

Application ID: 1-1078-1796


Applicant Information


1. Full legal name

Stockholms kommun

2. Address of the principal place of business

Ragnar Östbergsplan 1
Stockholm 11855
SE

3. Phone number

+46 8 5082 9000

4. Fax number

+46 8 5082 9970

5. If applicable, website or URL

http:⁄⁄www.international.stockholm.se

Primary Contact


6(a). Name

Ms. Evelyn Anna Gertrud Felicitas Lahrmann

6(b). Title

Client Manager

6(c). Address


6(d). Phone Number

+46 704 410084

6(e). Fax Number


6(f). Email Address

evelyn.lahrmann@dipcon.com

Secondary Contact


7(a). Name

Ms. Marthe Alice Viberg

7(b). Title

Business Area Manager

7(c). Address


7(d). Phone Number

+46 707 260011

7(e). Fax Number


7(f). Email Address

marthe.viberg@dipcon.com

Proof of Legal Establishment


8(a). Legal form of the Applicant

Swedish municipality

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

Kommunallag (1991:900)
1.kapitlet, §1

http:⁄⁄www.riksdagen.se⁄sv⁄Dokument-Lagar⁄Lagar⁄Svenskforfattningssamling⁄Kommunallag-1991900_sfs-1991-900⁄?bet=1991:900

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

Attachments are not displayed on this form.

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


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


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


Applicant Background


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


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

Clas Gunnar Bengt BjörkmanVice Chief Executive Officer
Eric Staffan IngvarssonVice Chief Executive Officer
Iréne Margaretha Lundqvist SvenoniusChief Executive Officer

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


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


Applied-for gTLD string


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

stockholm

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


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


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


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


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


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


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


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

Attachments are not displayed on this form.

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


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


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

16 The applicant for .stockholm - Stockholms kommun, hereafter called the City of Stockholm - has made all efforts to ensure the smooth and secure running of the .stockholm registry and the second-level domain names registered under this gTLD to avoid technical or rendering problems. Only experienced service providers for the .stockholm Registry Services -  Afilias Limited (Afilias) and Registry Data Escrow Service - NCC Group Inc (NCC Group) were chosen. 

Afilias is a global operator in registry services and provides a wide range of capabilities essential to the City of Stockholm’s operation of the domain registry. Afilias has operated since 2001 with the most successful launch of .INFO as one of seven new top domains. Afilias has previous experience of managing both small and large top level domains e.g. .INFO, .ASIA, .ORG, .AG and .IG which makes them a trusted partner in the operation of the new gTLD for the City of Stockholm.

NCC Group has been active in the domain name community since 2008 when they assisted ICANN with the development of the gTLD Registry Failover Plan. NCC Group is now an escrow provider for a number of registries and registrars worldwide with major operations in both Europe and North America. NCC Group’s services are compliant with both US and EU law which makes them a good choice for the City of Stockholm’s Data Escrow Services for .stockholm.

With consciously choosing well-renowned and highly reliable Registry Service and Data Escrow providers, the City of Stockholm is of the opinion that the City has made all efforts to ensure the smooth running of the .stockholm registry. In conclusion, no known operational or rendering problems concerning the .stockholm gTLD are known to either the City of Stockholm or one of the City’s providers.

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

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

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


Mission/Purpose


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

18A

The purpose of the City of Stockholm’s own gTLD .stockholm is twofold:

First, .stockholm will be a strong marketing tool, being part of a greater strategy for the City of Stockholm, aimed at the international business public. The purpose is that the City of Stockholm once more states its strong position as a highly modern and innovative city, using cutting edge technology to deliver the infrastructure needed in order to enable its business community to be successful in their area of expertise and to continue to attract international companies for investment.

Secondly, .stockholm shall be used as reliable and trusted communication tool for the citizens of Stockholm in their contacts with the city and its service providers. It will be the official channel for communication from its own institutions like municipal offices, schools, hospitals, events etc. to the citizens of Stockholm. .stockholm will be used as a strong communication tool aimed at Stockholm’s citizens, ensuring the origin of message, communicated either by email or web, leading to enhanced consumer trust in the field of online communication and marketing. .stockholm is part of a greater plan to enable the citizens of Stockholm the ultramodern lifestyle they expect from their city.

1. Stockholm – an innovative capital
Cities around the world are growing fast and as much as 75% of the world’s population is believed to live in cities by 2050. Globalization is increasing and country borders become vaguer with the help of digital technology. This means that large cities are complementing the identity-building role previously communicated by nation-states. The population of Stockholm is increasing quickly, both in the city itself, the county and region of Stockholm. This puts high demand on service, accessibility and sustainability. Thus Stockholm has a long term commitment to be a world class city by 2030.
Stockholm is one of the world’s most innovative cities. In 2009, Stockholm received the Intelligent Community of the Year Award by New York based think-tank Intelligent Community Foundation. Stockholm is home of world leading corporations in ICT, life science, environmental technology and more. The city attracts people who come here to live, work and carry out research, from other parts of Sweden and from all over the world.

To have its own gTLD is one mile stone in a long and intense commitment, which Stockholm has taken on since the 1990’s. In 2000 Stockholm was announced as “ICT-capital of Europe” by Newsweek. Stockholm has 100% broadband coverage, fiber and mobile, which has been developed since 1994. It is the world’s largest open city network, with 1 200 000 kilometers of fiber. By the end of this year, all apartment buildings and companies will have access to fiber connections.

Stockholm is also home to Europe’s leading companies within ICT, most of which are found in Kista Science City. Through a close cooperation between the private sector, research institutions and universities, Kista Science City has turned into one of Stockholm’s most important areas of economic growth, and an international center for wireless technology, broadband, mobile applications and services within bio-technology. There are more than 1400 ICT companies in the area – employing approximately 25 000 people. In order to continue this positive development, the City of Stockholm has to keep up the pace, taking advantage of new possibilities such as controlling its own gTLD .stockholm in order to remain the top city of innovative forerunners.

Digital technology is not only important in order to improve service, but also from a sustainability perspective. Having a well developed service sector and a wide use of broadband services among citizens, schools and companies gives the opportunity for a sustainable life style. Thus Stockholm was appointed Europe’s first Environmental Capital by the EU in 2010. Stockholm sees its own gTLD .stockholm as natural further development of the digital services already offered to the local business community as of today.


2. Stockholm, a modern city to live in
The ambition is to make living in Stockholm easy for the citizens. To get to and from the office, pick up children from pre-school, make it on time for after school activities, to shop and meet up with friends – it all takes a bit of coordinating and planning to make both ends meet in our everyday life.

.stockholm is a major mile stone in Stockholm´s mission to offer operations, services and communication tools that the citizens can rely on. Stockholm is a city for everyone and for all parts of life. One goal is to provide high accessibility, smooth running traffic and top quality welfare services available whenever needed.

The City of Stockholm has developed e-services and a strong digital presence for many years. The aim is to be available 24⁄7, and offer fast and professional response and guidance. The development of services will continue and Stockholmers will be offered increased diversity of services. All operations and services run by Stockholm need to be efficient. The City’s task is to support and facilitate life for its citizens.

Stockholm’s investments in digital services have yielded good results. Through e-services communication have been facilitated between the City administration and the citizens, and significantly shortened processing time for the administration of Stockholm.

Efforts in developing and launching digital services are made by the public sector, as well as by Stockholm’s private sector. The City of Stockholm has invested 650 million SEK in improving communication and e-services for its citizens and the City administrations over the last years. E-services for everything from building permits to pre-school places lead to more efficient management and an increased use of mobile and fixed broadband networks. By the end of 2012, the municipality will have launched approximately 60 e-services.

The results are already positive. Nine of ten Stockholmers apply for pre-schools online, as do half of the people applying for residential parking permits.

However, with more and more services available online, the city’s need for a high control and security level increases. The demand is for 100% reassurance when using e-services with private data. Communicating with the City’s inhabitants via .stockholm websites and email addresses, will have the possibility to enhance citizens trust that can increase the citizen´s use of city e-services.

Stockholm´s focus on e-services in combination with having its own gTLD .stockholm confirms the long term commitment. The broadband infrastructure and high level of web use being the foundation of this development. Sweden tops the International Telecommunication Union Index over household IT access and prices of phone and broadband services in 154 countries worldwide and in Stockholm the use is concentrated.


Conclusion - Objectives of the gTLD .stockholm
Stockholm is growing and sustainability and smart services are used to attract citizens, investors, business people and visitors. The City of Stockholm wants to take an active part in shaping the Internet of the future, and contribute to the digital development. Therefore, the City of Stockholm is investing in creating its own gTLD for all city services and activities.

In conclusion, the objective of .stockholm is to:

• Increase the visibility of the City of Stockholm, as well as the accessibility and usability of e-services for its citizens.
• Attract companies and coveted business people to the Stockholm region and to enable them a smooth and successful business entry by facilitating information transparency and increasing service availability.

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

18 B

.stockholm – a special gTLD
The specialty of the .stockholm gTLD is that it incorporates all official information about the City of Stockholm from a business, citizen and tourist perspective. The aim of the city’s own gTLD is to create a trusted communication platform which guarantees secure, integer and credible information and services to the city’s inhabitants and corporations.

Service levels of .stockholm
The objective of .stockholm is to deliver a high service level with great accessibility, where important quality values are 99.7% uptime for all web services offered under .stockholm. In contrast to the current second-level domain portfolio, registered and hosted randomly, all second-level domains under .stockholm will be registered on standard name servers by the City’s IT operating contractor with DNSSEC as standard and SSL certificates where needed. Due to .stockholm, the City of Stockholm will be able to easily and unhindered register second-level domain names for their municipal offices, schools, etc. Earlier, the city had to instead register alternative but less intuitive second-level domains. The result is a domain name portfolio of less relevance and lower quality as these second-level domains are more difficult for users to remember and the related e-services or city information will conclusively be more found by use of search engines than by direct navigation via the original second-level domain in question. Thanks to .stockholm a clear and simple second-level domain and marketing strategy can be created, which will result in the successful reach out to more Stockholm citizens. Being the registry over its own gTLD, the City of Stockholm will be able to create its own structure and second-level domain strategy and is thus easily able to set up standards for their gTLD and registered second-level domains and through this reach a high security level for their users. With decisions and important personal information sent from a .stockholm email address, the recipient shall feel safe that this email really is from the City of Stockholm. SPF records could be part of the City’s strategy to reach this. If information is checked on a .stockholm homepage there is no doubt that the content provided on this website originates from the official channels of the City of Stockholm. The result will be consumers’ enhanced reassurance about the addresser’s identity.

Aims for reputation with .stockholm
The City of Stockholm has already earned the reputation of a highly innovative, modern city, one of Europe’s hubs within the ICT business and Scandinavia’s focal point for technology investments. However, as well-known – innovation and modernity are no long-term merits but have to be constantly strived after and actively worked with in order to keep a justification to describe the city of Stockholm with such fine adjectives. With its own gTLD, the City of Stockholm would once more show its capacity of being a forerunner, able to use cutting edge possibilities and technologies in order to enforce its reputation as one of the world’s most innovative and modern cities.

ii. .stockholm and the current space
Stockholm wants to take part in developing the future of the Internet, and create a credible and visible sender for international visitors, authorities, future citizens and businesses. The goal is to promote Stockholm as a city with great opportunities in hand for everyone who is ready to take them on. Stockholm shall be known as a city to count on when it comes to thinking outside the box and enabling its citizens an ultramodern lifestyle on a competitive level like other attractive large international cities.

Differentiation - .stockholm, a role model
Due to the complexity, costs, and resources needed for application as well as running of the future registry, an own gTLD will definitely differentiate the City of Stockholm from other cities. It will also differentiate the City of Stockholm on an international level - being the Swedish capital – it will differentiate Sweden from other countries. This is a differentiation on both a commercial, citizen and tourist level, as the City of Stockholm will earn a communication tool only few cities will have and which will be used to make living, visiting and simply dealing with administrative errands easier.
The Scandinavian community, being as tight as it is with a long history of close collaborations between the states, .stockholm and the specific use of it as the main communication channel of the City of Stockholm will definitely be seen as role model for more gTLD applications to come in a future round by ICANN. .stockholm will create a sense of positive competitiveness that fosters creativity and innovation not only between the other Scandinavian but also the other European capital cities.

Differentiation - .stockholm and the brand “Sweden”
With its own gTLD the City of Stockholm will once more state its capacity as a European capital to count on, a technology forerunner with a young and modern attitude and an uncomplicated way of looking at life. It is obvious that the City of Stockholm has made the conscious decision years ago to become one of Northern Europe’s most attractive locations for business investment and technology innovation. Repeated award nominations and articles in such renowned forums and magazines as the New York based foundation Intelligent Community and Newsweek have affirmed the front position of the City of Stockholm in terms of a modern, innovative and future-oriented lifestyle, possible to lead in this City. .stockholm will thus be a further brand building stone presenting the unique opportunity for the City of Stockholm to become remarkably more visible in the Internet space. The impact of .stockholm will not be limited to merely the City of Stockholm but will also affect the entire country, being another corner stone to manifest the brand of Sweden, a modern and innovative country with a readiness to mount technology barriers effortlessly.

.stockholm – an innovative approach
The innovative edge of .stockholm lies specifically in the unique communication tool as well as the amount of e-services that the City of Stockholm will be able to easily promote and provide to its citizens. The City of Stockholm as well as other cities with similar approach concerning their own gTLD write history on the accessibility to reach their e-services and information 24⁄7, the simplicity to find due to easy memorable second-level domains, the reliability to know that information from this channel is the official sender and to profit from the City administrations’ increased efficiency with shorter processing time of errands.

iii. .stockholm’s goals with regard to user experience
As one of Sweden’s largest public service providers, user experience was in focus when developing the objectives for .stockholm. It is the citizens of Stockholm together with visitors and business people in need of information about Stockholm who will primarily use the .stockholm gTLD. In order to succeed in the usage of the .stockholm second-level domains in the future - who will eventually replace the current second-level domain portfolio under .se - the advantages experienced by consumers are several.
Clarity
The main objective in terms of user experience of websites under .stockholm is clarity. As only the City of Stockholm including its municipal offices, schools, museums etc. will be eligible to register second-level domains under .stockholm in the name of the City of Stockholm, communication from this channel will be very clear. With the growing knowledge about the City’s own gTLD, a website under .stockholm will even become a characteristic, for citizens easy to recognize, whether an institution e.g. a school is privately or publicly funded and will also in this way facilitate clarity and transparency.

Credibility
The City of Stockholmʹs trade mark survey shows that stockholmers view the City as a very trustworthy organization. This fact is actively used in the Cityʹs development of its digital presence.
For many years, Stockholm has had an IT security policy to ensure that all City operations maintain the highest standards in terms of security and integrity for, among other things, administration of errands and personal data. The City of Stockholm has therefore already implemented DNSSEC and SSL certificates for all websites and services under its main second-level domain stockholm.se to guarantee user integrity.
The City of Stockholm has since the late 1990ʹs aimed at being one of the worldʹs most accessible cities for people with disabilities. Therefore, the City of Stockholm has since 2008 implemented tough guide lines when it comes to accessibility (easy to read services, sign language and more) for development of websites and e-services. All of the above will serve as a benchmark and quality guarantee for all new second-level domains under .stockholm.

Simplicity
In the technology age we live with constant information overload, it is especially crucial to make important information as easily and simple to access as possible. However, due to .stockholm the City of Stockholm will be easier to find and will have an easily recognizable address for an international, as well as a national audience.

iv. Registration policies of .stockholm
Registration responsibility within the City of Stockholm organization
In order to deliver high quality under .stockholm, the registration regulations are designed so that the user’s needs, experience and security always is in focus. To guarantee proper, internal compliance and follow-up of the regulations, the responsibility for registry operations and follow-up will be separated within the City’s organization. Registry operations with regard to order and delivery of second-level domains will be handled by the City Operations themselves via appointed registrar’s website.
The City Executive Office IT Department will be responsible for the actual registry operations such as registration regulations and follow-up of the same, as well as follow-up of compliance with legal requirements of the ICANN agreement for the gTLD and handling of any abuse cases etc.
City of Stockholm will be the registered owner of all second-level domains under .stockholm. Internally, the ordering and thus by the registrar invoiced municipal entity, will be seen as owner of the relevant second-level domains and held responsible.

Registration policies of .stockholm
Who may order a .stockholm second-level domain?
Operations controlled by City administration, Companies owned by the municipality, City collaboration projects with operations directed towards citizens, businesses or visitors.

Second-level domains under .stockholm - regulations:
Names are not allowed to violate regulations for registrations of trademarks.
Swedish geographical names outside Stockholm cannot be registered without written consent or approval from the locally responsible County Council, District, County Administrative Board or council.
Names of countries and regions will not be allowed for registration along with ICANN New Registry Agreement Specification 5 for reserved names.
All two label second-level domain names will be blocked for registration.
NIC, WWW, IRIS and WHOIS will initially be blocked and only used in line with ICANN regulation.
Names with the use of hyphens in the third or fourth position will not be allowed in line with ICANN regulation.
In addition, the label “example” will be blocked on all levels in line with ICANN regulation.
Second-level domain names are provided on a first come first served basis.

Websites and services under .stockholm - requirements:
Mission of the website must comply with the goals stated by City Council
Content must follow national regulations regarding copyright.
Regulations outlined by the City’s IT Security Policy must be followed.
Technical security measures determined in City’s IT-program must be followed.
Integrity issues regarding handling and presentation of personal data must follow national regulations (Personal Data Act, PUL)
The City of Stockholm name-servers must be used for all domain-names under the new gTLD

Registering, renewal and termination of second-level domains
Registering a second-level domain - process:
1. The municipal entity visits an internal website
2. The municipal entity states:
Entity name and corporate identification number
Full legal name
The entity’s complete address including email address and phone number
External billing address and cost center
Object description
If an Information Security Classification has been conducted in line with the City’s IT security policy (yes⁄no)
Personal data will be administered (yes⁄no)
Duration of the registration (1,2 or 3 years)

3. The ordered second-level domain nameis synchronized with the list of blocked and already registered domain names if available for registration, an order can be placed at the appointed registrar.
4. The registrar sends the order information to the registry service provider by EPP code and confirms the successful registration of the second-level domain to the City of Stockholm after positive notice from Afilias. Standardized handle registration information will be used for owner, administrative, technical and billing information, to which an auto-generated email will be sent according to agreement between the City of Stockholm and the appointed registrar.
5. The City’s IT operating contractor carries out security audits in line with the registry rules as well as zone records creation on the City’s standard name servers. The Executive Office IT department will be notified in its role as registry for compliance with registration policies.
6. The ordering municipal entity will be invoiced by the registrar for the registration⁄renewal fee of its second-level domains.

Renewal of a second-level domain - process:
A renewal reminder will be sent to the registered billing handle information by e-mail three months prior to the expiration date, with additional reminders according to the registrar’s routine.
Domain name registration data need to be reviewed and approved by the billed municipal entity in connection with the renewal, to ensure that the domain’s purpose and use remain the same.
All renewed second-level domain names are sent to the City Executive Office IT Department for information.
In the event of non-payment one month after the expiry date, an e-mail is sent to the City Executive Office IT Department for verification of removal of the second-level domain.

Termination of a second-level domain - process:
The City of Stockholm can terminate a domain name at any time.
The second-level domain registration fee cannot be refunded.
The termination shall be sent in writing to the registrar.
Terminated second-level domains are notified to the City Executive Office IT Department.
Deregistration or blockage of a second-level domain can also take place in the event of breach of registry regulations.

Handling of violations of registry regulation - procedure
Legal claims and notifications of breaches of regulations can be posted via the .stockholm registry’s official, publicly available website.. The notifications will be forwarded to the registrar for acknowledgement, and to the City Executive IT Department for assessment.
Breach of regulation leads to:
A warning
The termination of the second-level domain
The blockage of the second-level domain
Blockage of second-level domain
In addition, the City Executive Office IT Department will conduct an annual audit of selected registered domains to ensure compliance with the regulations.

Warning
In the event of breech of the following, a warning will be issued to the domain owner first hand:
Changing the purpose of the second-level domain significantly without notifying the City Executive IT Department.
Introducing new features concerning e.g. personal data without the relevant safety measures
The contents of the site or the services violates the registration policies

Termination
A termination could be issued if:
The municipal entity invoiced for the second-level domain has consistently breached the City’s policy for IT security.
The relevant website is believed to pose a serious security risk for the users.
The domain is believed to breach the regulations for Swedish geographical names.
The municipal entity invoiced for the second-level domain has significantly changed the purpose of the website, and in such a way that it could breach the regulations, or is used in a way that is not in line with the goals and⁄or set guidelines of the City Council.
The municipal entity invoiced for the second-level domain is consistently breaching copyright laws.

Blockage of second-level domain
Registered second-level domains that breach the regulations for international geographical names and registered trademarks, will be terminated and blocked in connection with the positive assessment of the breach. Second-level domains may also be terminated and blocked if there is a breach of any other ICANN regulations.

Conclusion
Based on the above stated regulations, the goals of the user experience of .stockholm are believed to be achieved.
Clarity – A clear and credible sender is guaranteed by only allowing registration of second-level domains for municipal entities part of the City of Stockholm.
Credibility – Proper security and credibility is guaranteed due to the high overall demands concerning technology and integrity that are put on all websites and e-services constructed under .stockholm second-level domains.
Simplicity – It will be easy for citizens to identify the sender, and to know where to turn with questions, since all of the City’s municipal entities will be gathered under the .stockholm domain.

v. Privacy⁄confidential information of registrant and users under .stockholm
Registrant information
According to the registration policy above, only the City of Stockholm will be able to register and own domain names under .stockholm. The City having full control over all second-level domains it is guaranteed that the content provided under this gTLD is the official and valid information. In accordance with regular gTLD whois information, the registration details for each second-level domain under .stockholm will be public information and visible to anybody. There is no need for privacy registrations under .stockholm, the City of Stockholm being the sole possible registrant.

Handling of user data
The City of Stockholm follows the national legislation for handling of personal data and guarantees the highest security for all its web presence. Web pages and services under the new gTLD will be developed along the City’s guidelines and be administrated by the City’s procured suppliers, from which the highest demands are required – guaranteeing a safe user experience. Examples of security measures taken as of today are SSL certificates and DNSSEC. This will be the future standard of all second-level domains under .stockholm.

The contribution of .stockholm
Many objectives of .stockholm are hard to measure being soft values by nature as branding, the creation of a certain perception of Stockholm and Sweden, only indirectly measureable by increase of business investments or numbers of overnight stays. Other factors are measurable such as number of e-services used⁄delivered and processing time savings per errand. By help of .stockholm, the City will have a clear thus strong communication and marketing tool to deliver its message to the world. Hence, .stockholm will definitely contribute to achieve the City’s above mentioned objectives.

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

18 C

Actions to reduce social costs

Reducing social costs within the City of Stockholm
The City of Stockholm is home to approximately 40 municipal companies and administrations. There are about 600 pre-schools, 150 schools, 30 elderly care centers and many more. Each of these entities shall have the possibility to register their organization name and more if wished, under .stockholm. The City of Stockholm will create an internal domain name strategy that thoroughly addresses aspects such as registration routine, cost estimation and DNS management and make this information available to its employees. The objective is to make second-level domain name registration under .stockholm as smooth and clear for the municipal entities in order to minimize resistance against the new gTLD. In summary, the various municipal entities will contact the .stockholm registry with an order for a second-level domain name registration and the registry will take care of the actual registration procedure with the registrar and confirm to the ordering entity when the domain name registration is completed. Hosting services in a standardized manner will be provided from one chosen provider, also here simplifying second-level domain name and DNS management for each entity by providing well-functioning services in a routinized and simple form to the City’s entities.

Reducing social costs for Stockholm citizens and more
It is clear that for such a large second-level domain portfolio that affects many thousand people on a daily basis, it will take time to get to change the users’ surfing habits and e.g. link savings. The City of Stockholm meets this challenge amongst others by informing the citizens through the official communication channel regularly used as the Internet, printed information in municipal buildings, information distributed via the intranet to municipal employees as well as PR through media such as the daily press.

Furthermore, under a transition phase probably at least two to three years, the City of Stockholm will keep its current second-level domain portfolio of .se domains alive and forward all traffic to the new .stockholm websites. This way, there will be a learning process for the users regarding the existence of the new .stockholm internet presence. After this transition phase, maybe only a parking site is informing the user about the correct homepage instead.

i. multiple applications for second level domain
In such a big organization, it is only to be expected that there will occur multiple applications for certain second-level domain names based on the fact that several entities share the same entity name as for example a number of pre-schools. In general second-level domain name applications will be handled on a first come⁄first serve basis with the exception of protected trademarks which are naturally not eligible to apply.
In the event that during the sunrise phase, multiple applications for a second-level domain name should be received, the City of Stockholm will handle this matter in the same way this problem is solved currently, by adding a a geographical appendix according to the city district the entity is located. This way the risk of confusion of the two similarly called entities will be eliminated .

ii. Advantageous pricing
It is the clear intention from the City of Stockholm to keep the costs as low as possible and there will be no actual registration price invoiced to the domain name ordering entities from the registry. Registrar registration fees will however be paid by each ordering entity directly to the registrar. The total costs of the registry and those costs in direct relation to .stockholm will be shared between the municipal body based on each entity’s size, in the same way IT costs are shared as of today. This means that each entity is only invoiced the cost price, which is as advantageous pricing as can be offered from the City of Stockholm and in complete parity with the overall objectives of the new TLD, which are not to make profit but to promote the City of Stockholm as an innovative and modern city with high living standard.

iii. Development of second-level domain costs
According to the Applicant Guidebook, an ICANN accredited registrar will be contracted in order to register .stockholm domain names. The future registrar will be able to register .stockholm second-level domains for one, two, three, five or ten years, however the City of Stockholm will probably mostly register second-level domains under .stockholm with a registration period of one, two or three years depending on the occasion. In order to reduce costs short registration lengths will be chosen for second-level domains for e.g. events or shorter projects, whereas long registration durations are thought for core domain registrations of municipal entities.
The disbursed second-level domain costs over time will not be raised without reason however, the divided domain cost for each municipal entity, which include as above stated also all fixed and running costs for the .stockholm registry will follow the cost development imposed on the City of Stockholm from all involved providers needed to run the gTLD.Naturally, the City of Stockholm will make all efforts to negotiate as advantageous terms of conditions, including the limitation of costs, as possible.

Community-based Designation


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

No

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


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


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


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


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


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

Attachments are not displayed on this form.

Geographic Names


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

Yes

Protection of Geographic Names


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

22.	Protection of Geographic Names

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

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

Reserved names for the City of Stockholm
There are 117 official City Districts within Stockholm’s City Council. As the objective of the gTLD .stockholm is to be solely registered and owned by the City of Stockholm for the marketing and communication purposes of municipal information to the citizens and businesses in Stockholm as well as to deliver official information to Stockholm visitors, local geographical names like City Districts are essential for the correct and meaningful usage of .stockholm. The names of these City Districts will be reserved for the City District Administrations to register. The City of Stockholm will also be able to register names of potential and actual new City District conversions in the future.

Thus, the following geographical names have been reserved for Stockholm’s City Districts beforehand and will be released when ordered internally from the municipal entity in question:

Abrahamsberg, Akalla, Alvik, Aspudden, Bagarmossen, Bandhagen, Beckomberga, Björkhagen, Blackeberg, Bredäng, Bromma Kyrka, Bromsten, Bällsta, Djurgården, Eneby, Enskede gård, Enskededalen, Enskedefältet, Fagersjö, Farsta, Farsta strand, Farstanäset, Flaten, Flysta, Fredhäll, Fruängen, Gamla Enskede, Gamla stan, Grimsta, Gröndal, Gubbängen, Gärdet, Hagsätra, Hammarbyhöjden, Hansta naturreservat, Herrängen, Hjorthagen, Husby, Hägersten, Hägerstensåsen, Hässelby gård, Hässelby strand, Hässelby villastad, Högdalen, Höglandet, Hökarängen, Johanneshov, Kista, Kristineberg, Kungsholmen, Kälvesta, Kärrtorp, Larsboda, Liljeholmen, Lilla Essingen, Liseberg, Lunda, Långbro, Långholmen, Långsjö, Marieberg, Mariehäll, Midsommarkransen, Mälarhöjden, Nockeby, Nockebyhov, Norra Djurgården, Norra Ängby, Norrmalm, Nälsta, Olovslund, Orhem, Reimersholme, Riddarholmen, Riksby, Rinkeby, Råcksta, Rågsved, Skarpnäcks gård, Skeppsholmen, Skrubba, Skärholmen, Sköndal, Smedslätten, Solberga, Solhem, Stadshagen, Stora Essingen, Stora mossen, Stureby, Sundby, Svedmyra, Sätra, Södermalm, Södra Hammarbyhamnen, Södra Ängby, Tallkrogen, Tensta, Traneberg, Ulvsunda, Vasastan, Vinsta, Vällingby, Västberga, Västertorp, Vårberg, Älvsjö, Äppelviken, Åkeshov, Åkeslund, Ålsten, Årsta, Örby, Örby slott, Östberga, Östermalm.

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

The City of Stockholm 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, the .stockholm registry will require a written request from the country’s GAC representative, or a written request from the country’s relevant Ministry or Department. The City of Stockholm 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.

Other Swedish geographical names including City Councils or City Districts, such as Malmö or Göteborg, cannot be registered without written consent or approval from the locally responsible County Council, Country District, County Administrative Board or Council.

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

If internationalized domains names (IDNs) are introduced in the TLD in the future, we will also reserve the IDN versions of the country names in the relevant script(s) before IDNs become available to the public. If the City of Stockholm finds it advisable and practical, it will confer with relevant language authorities so that the City can reserve the IDN domains properly along with their variants.

Regarding GAC advice regarding second-level domains not specified via Specification 5, paragraph 5: All domains awarded to registrants are subject to the Uniform Domain Name Dispute Resolution Policy (UDRP), and to any properly-situated court proceeding. The City of Stockholm will ensure appropriate procedures to allow governments, public authorities or IGO’s to challenge abuses of names with national or geographic significance at the second level. In its registry-registrar agreement, and flowing down to registrar-registrant agreements, the registry operator will institute a provision to suspend domains names in the event of a dispute. The City of Stockholm may exercise that right in the case of a dispute over a geographic name.

Eliminated risk of cyber-squatters and defensive registration
Based on the regulations of the .stockholm registry, only the City of Stockholm can register domain names under .stockholm for its municipal entities, which erases the risk of cyber-squatters completely. This means that defensive second-level domain registration will not be an issue at all under .stockholm, as other entities outside the administrative body of the City of Stockholm cannot register or own a .stockholm domain name, as it will not be an open gTLD. This in turn means that no registered trademarks of private actors can be registered under .stockholm. In conclusion, trademark owners need not to worry on trademark infringement on the Internet under .stockholm, which mostly is the reason for defensive registrations. .stockholm registry follows thus section 2.9 of the GAC Principles of new gTLDs.

In conclusion, it is the interest of the City of Stockholm to be a reliable and trustworthy registry according to the GAC principles of new gTLDs as well as ICANNs regulations. The registry is only more than interested to protect others countries’ and regions’ geographical names and thus will deliver registry guidelines and processes to minimize the risk of such registrations under .stockholm as well as to deliver all support needed in case the registry will be approached by governments, public authorities or IGOs.

Registry Services


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

23	Registry Services

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. The City of Stockholm 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.

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 the City of Stockholm (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, the City of Stockholm 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 the City of Stockholm to
review specific needs and objectives of this TLD. The resulting comprehensive plans are illustrated in technical responses #24-44, drafted by Afilias given the City of Stockholm’s requirements. Afilias and the City of Stockholm 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.

Demonstration of Technical & Operational Capability


24. Shared Registration System (SRS) Performance

24. SRS PERFORMANCE

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

25. Extensible Provisioning Protocol (EPP)

25 EPP

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

26. Whois

26	WHOIS

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.

27. Registration Life Cycle

27 Registration Lifecycle

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

28. Abuse Prevention and Mitigation

28 Abuse Prevention and Mitigation

The City of Stockholm, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the TLD. The specific measures include, but are not limited to:
• Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
• Committing to rapid identification and resolution of abuse, including suspensions;
• Ensuring completeness of WHOIS information at the time of registration;
• Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;
• Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.

Abuse policy
The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

Repeat violations of the abuse policy will result in a case-by-case review of the abuser(s), and the registry operator reserves the right to escalate the issue, with the intent of levying sanctions that are allowed under the TLD anti-abuse policy.

The below policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool.

.stockholm Anti-Abuse Policy
The following Anti-Abuse Policy is effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:
• Illegal or fraudulent actions;
• Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums;
• Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
• Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
• Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and Trojan horses.
• Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.
• Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
• Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to the registry operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).

Abuse point of contact and procedures for handling abuse complaints
The registry operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.stockholm”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. For tracking purposes, the registry operator will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. Afilias will integrate its existing ticketing system with the registry operator’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

The registry operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate.

In general, the registry operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

The security function includes a communication and outreach function, with information sharing with industry partners regarding malicious or abusive behavior, in order to ensure coordinated abuse mitigation across multiple TLDs.

Assessing abuse reports requires great care, and the registry operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, the registry operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:
a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.
b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.

The standard procedure is that the registry operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that the registry operator will not, such as:
• Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
• The identity of a proxy-protected registrant;
• The purchaser’s IP address;
• Whether there is a reseller involved, and;
• The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).

Registrars do not share the above information with registry operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by the registry operator (usually 24 hours), the registry operator might then decide to take action itself. At all times, the registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

The registry operator will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where the registry operator will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which the registry operator, although the operator in all cases will adhere to applicable laws and regulations.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:
• Registration information
• History of a domain, including recent updates made
• Other domains associated with a registrant’s account
• Patterns of registrant portfolio

Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. Afilias sets a goal to respond to such requests within 24 hours.

The registry operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The registry operator could take advantage of a combination of the following resources, among others:
• Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus.
• Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.
• Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.]

The registry operator will keep records and track metrics regarding abuse and abuse reports. These will include:
• Number of abuse reports received by the registry’s abuse point of contact described above;
• Number of cases and domains referred to registrars for resolution;
• Number of cases and domains where the registry took direct action;
• Resolution times;
• Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;
• Phishing site uptimes in the TLD.

Removal of orphan glue records
By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. These procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The registry operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.

Methods to promote WHOIS accuracy
The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in our response to question #26, WHOIS, the registry operator will manage a secure, robust and searchable WHOIS service for this TLD.

WHOIS data accuracy
The registry operator will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. The registry operator will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list. The Afilias WHOIS system is extensible, and is capable of using the VAULT system, described further below.

Similar to the centralized abuse point of contact described above, the registry operator can institute a contact email address which could be utilized by third parties to submit complaints for inaccurate or false WHOIS data detected. This information will be processed by Afilias’ support department and forwarded to the registrars. The registrars can work with the registrants of those domains to address these complaints. Afilias will audit registrars on a yearly basis to verify whether the complaints being forwarded are being addressed or not. This functionality, available to all registry operators, is activated based on the registry operator’s business policy.

Afilias also incorporates a spot-check verification system where a randomly selected set of domain names are checked periodically for accuracy of WHOIS data. Afilias’ .PRO registry system incorporates such a verification system whereby 1% of total registrations or 100 domains, whichever number is larger, are spot-checked every month to verify the domain name registrant’s critical information provided with the domain registration data. With both a highly qualified corps of engineers and a 24x7 staffed support function, Afilias has the capacity to integrate such spot-check functionality into this TLD, based on the registry operator’s business policy. Note: This functionality will not work for proxy protected WHOIS information, where registrars or their resellers have the actual registrant data. The solution to that problem lies with either registry or registrar policy, or a change in the general marketplace practices with respect to proxy registrations.

Finally, Afilias’ registry systems have a sophisticated set of billing and pricing functionality which aids registry operators who decide to provide a set of financial incentives to registrars for maintaining or improving WHOIS accuracy. For instance, it is conceivable that the registry operator may decide to provide a discount for the domain registration or renewal fees for validated registrants, or levy a larger cost for the domain registration or renewal of proxy domain names. The Afilias system has the capability to support such incentives on a configurable basis, towards the goal of promoting better WHOIS accuracy.

Role of registrars
As part of the RRA (Registry Registrar Agreement), the registry operator will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄ ).

Controls to ensure proper access to domain functions
Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to question #30b.

Validation and abuse mitigation mechanisms
Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation. Once analyzed and confirmed by the domain anti-abuse team members, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable the registry operator to only allow registrations by pre-authorized and verified contacts. These verified contacts are given a unique code that can be used for registration of new domains.

Registrant pre-verification and authentication
One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

• Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.
• Based on required WHOIS Data; registrant contact details (name, address, phone)
• If address⁄ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)
• If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions.
• If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant.
• If WHOIS data is validated a token would be generated and could be given back to the registrar which registered the domain.
• WHOIS data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.
• A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers.
• Validation would be annually renewed, and validation date displayed in the WHOIS.

Abuse prevention resourcing plans
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. Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. While all of Afilias’ 200+ employees are charged with responsibility to report any detected abuse, the engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

This TLD’s anticipated volume of registrations in the first three years of operations is listed in response #46. Afilias and the registry operator’s anti-abuse function anticipates the expected volume and type of registrations, and together will adequately cover the staffing needs for this TLD. The registry operator will maintain an abuse response team, which may be a combination of internal staff and outside specialty contractors, adjusting to the needs of the size and type of TLD. The team structure planned for this TLD is based on several years of experience responding to, mitigating, and managing abuse for TLDs of various sizes. The team will generally consist of abuse handlers (probably internal), a junior analyst, (either internal or external), and a senior security consultant (likely an external resource providing the registry operator with extra expertise as needed). These responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

The exact resources required to maintain an abuse response team must change with the size and registration procedures of the TLD. An initial abuse handler is necessary as a point of contact for reports, even if a part-time responsibility. The abuse handlers monitor the abuse email address for complaints and evaluate incoming reports from a variety of sources. A large percentage of abuse reports to the registry operator may be unsolicited commercial email. The designated abuse handlers can identify legitimate reports and then decide what action is appropriate, either to act upon them, escalate to a security analyst for closer investigation, or refer them to registrars as per the above-described procedures. A TLD with rare cases of abuse would conform to this structure.

If multiple cases of abuse within the same week occur regularly, the registry operator will consider staffing internally a security analyst to investigate the complaints as they become more frequent. Training an abuse analyst requires 3-6 months and likely requires the active guidance of an experienced senior security analyst for guidance and verification of assessments and recommendations being made.

If this TLD were to regularly experience multiple cases of abuse within the same day, a full-time senior security analyst would likely be necessary. A senior security analyst capable of fulfilling this role should have several years of experience and able to manage and train the internal abuse response team.

The abuse response team will also maintain subscriptions for several security information services, including the blocklists from organizations like SURBL and Spamhaus and anti-phishing and other domain related abuse (malware, fast-flux etc.) feeds. The pricing structure of these services may depend on the size of the domain and some services will include a number of rapid suspension requests for use as needed.

For a large TLD, regular audits of the registry data are required to maintain control over abusive registrations. When a registrar with a significant number of registrations has been compromised or acted maliciously, the registry operator may need to analyze a set of registration or DNS query data. A scan of all the domains of a registrar is conducted only as needed. Scanning and analysis for a large registrar may require as much as a week of full-time effort for a dedicated machine and team.

29. Rights Protection Mechanisms

29	Rights Protection Mechanisms

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);
• Checking registrations against the Trademark Clearinghouse provided by ICANN;
• Implementing a professional trademark claims program that utilizes the Trademark Clearinghouse, and drawing upon models of similar programs used successfully in previous TLD launches;
• Complying with the URS requirements;
• Complying with the UDRP;
• Complying with the PDDRP, and;
• Including all ICANN-mandated and independently developed rights protection mechanisms (“RPMs”) in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.

The response below details the rights protection mechanisms at the launch of the TLD (Sunrise and Trademark Claims Service) which comply with rights protection policies (URS, UDRP, PDDRP, and other ICANN RPMs), outlines additional provisions made for rights protection, and provides the resourcing plans. It should be noted that this will be a single entity TLD in which the City of Stockholm has direct control over each registrant and how each registration may be used. Thus, there are no rights protection issues anticipated in this TLD, though consideration has been made to the general protection and defined below.

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⁄Trademark Clearinghouse
Applicant will check their registrations against the Trademark Clearinghouse per ICANN requirements. Given the proposed business model and the registry operator being the sole registrant, there are no anticipated trademark issues.

Notice will be provided to all trademark holders in the Clearinghouse if someone is seeking a Sunrise registration. This notice will be provided to holders of marks in the Clearinghouse that are an Identical Match (as defined in the Trademark Clearing House) to the name to be registered during Sunrise.

Each Sunrise registration will require a minimum term of five years.

The City of Stockholm will establish the following Sunrise eligibility requirements (SERs) as minimum requirements, verified by Clearinghouse data, and incorporate a Sunrise Dispute Resolution Policy (SDRP). The SERs include: (i) ownership of a mark that satisfies the criteria set forth in section 7.2 of the Trademark 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 SDRP will allow challenges based on the following four grounds: (i) at time the challenged domain name was registered, the registrants did not hold a trademark registration of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; (ii) the domain name is not identical to the mark on which the registrant based its Sunrise registration; (iii) the trademark registration on which the registrant based its Sunrise registration is not of national effect (or regional effect) or the trademark had not been court-validated or protected by statute or treaty; or (iv) the trademark registration on which the domain name registrant based its Sunrise registration did not issue on or before the effective date of the Registry Agreement and was not applied for on or before ICANN announced the applications received.

Ongoing rights protection mechanisms
Several mechanisms will be in place to protect rights in this TLD, though highly unlikely to be required given the City of Stockholm is the sole registrant in the 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.”


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 by ICANN that this will be a single entity TLD in which the City of Stockholm has direct control over each registrant (they are typically on staff or otherwise contractually bound) and how each registration may be used. Further, there will be no open registration period for this TLD, as it will never be an “open” TLD. Since all criminal activity (such as phishing and pharming) is precluded by the mission, values and policies of the registry operator (and its parent organization), criminal activity is not expected to be a problem. If such activity occurs due to hacking or other compromises, the registry operator will take prompt and effective steps to eliminate the activity.

In the case of this TLD, the City of Stockholm 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 the City of Stockholm internal controls, as well as community-developed UDRP and URS policies and procedures if needed, to deal with complaints, should there be any.

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. No additional hardware or software resources are required to support this as Afilias has fully-operational capabilities to manage abuse today. Given the proposed business model, there are no additional resources required by the City of Stockholm.

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

30a	Security Policy (Public)
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.



© Internet Corporation For Assigned Names and Numbers.