Application number: 1-1322-54903 for Gemeente Amsterdam

Gemeente Amsterdam

Amstel 1
Amsterdam 1011PN
NL

+31205523262

+31205522214

http:⁄⁄www.amsterdam.nl

Mr. Egbert Evert Wolf

Design Manager

+31205523262

e.wolf@amsterdam.nl

Mr. Hubert Welleman

New Business Manager

+31 26 35 25 500

+31 26 35 2 55 05

hubert.welleman@sidn.nl

government institution (municipality)

Gemeentewet (municipality law) of The Netherlands

Not Available

Eberhard E. van der Laan
Mayor

amsterdam

Not Available

As far as the applicant is aware of there are no known operational or rendering problems with regard to the .TLD-string

The mission of the proposed “.amsterdamʺ TLD is to provide the community, stakeholders of and visitors to the City of Amsterdam with a TLD that will be the new address of the ʺdigital cityʺ, reflecting their bond with the City and its values. The TLD will provide a virtual space in which digital communication and connections are stimulated and business can increasingly flourish: interest groups, institutions, communities, individuals and corporations are stimulated to adopt the new TLD as a valuable tool for business, communication or expression, but also as a means to express their connection to the City in the broadest sense of the word. The international brand awareness and recognizability and uniform spelling of the name of the City will contribute significantly to the adoption and use of this TLD.

The new ʺ.amsterdamʺ TLD aims to provide the stakeholders of the City of Amsterdam with an address that is both recognizable as having a link to the City, while being ‘personal’ as well. Being used as a part of Amsterdamʹs branding strategy, a geographic TLD like .amsterdam is expected to create and support the local identity for enterprises, institutions, and individuals and with the aim to result in a stronger sense of community. It is planned that Amsterdam’s marketing strategy and the creation of a maximum branding value will be substantially supported by communication activities on domain names such as http:⁄⁄visit.amsterdam, to name but one example. The introduction and the ‘maintenance’ of the branding of the TLD will be supported by the City’s Marketing department, which has invested significantly in the branding of the City over the past eight years. The Registry will be offering tools for the marketing of domain names in the “.amsterdam” TLD realm to third parties with the aim of maximizing a rapid recognizability of the TLD.

By actively using the City’s own domain names as described above, but also highly stimulating (through marketing and agreements) the actual usage of the TLD, the Registry firmly believes the TLD will grow to be of high value to its registrants by means of actual public usage and search engine ranking.

The marketing strategy of the City of Amsterdam will be in line with the “I amsterdam” City Marketing strategy that already has a high recognizability in the City as it has been running for close to eight years now. Furthermore, the City aims to use the TLD for its services to the public. To that purpose a number of domain names will remain reserved for the exclusive use by the City of Amsterdam. Next to that a number of domain names will be reserved and issued in batches to parties with a specific interest in the entire batch of domain names in conjunction with the obligation for the registrant to actively use these domains in line with such specific interest. Thus, the Registry can –for a fairly limited but important range of domain names- guarantee valuable experiences for the public.

Examples of these ‘batches’ mentioned above would be “wonen.amsterdam”,“woningen.amsterdam”,“koopwoningen.amsterdam” and “huurwoningen.amsterdam”. By offering these four domain names for sale as a ‘batch’, with the conditions of active use within a short period after purchase (to be determined) we can achieve rapid public availability of these strategic domain names. On top of that, by auctioning these batches, we create a level playing field allowing all interested parties to acquire those names (with the conditions mentioned being a part of the sale), while at the same time offering the new owner the strategic advantage of having acquired a coherent set of domain names, which can be considered to be of premium strategic value. The Registry also believes that this mechanism will prevent domain name squatting for these important domain names. Domain name squatting could otherwise have a very negative effect on the actual use of and the sentiments surrounding the new TLD.

The Registry anticipates that“.amsterdam” will add to the current space more differentiation in the way that it provides registrants the opportunity to have a distinct new possibility to show⁄promote their brand, shop or business, identity or community via a TLD that is “not distant” in many ways. In terms of competition the Registry will provide a TLD that will add more consumer choice in a market dominated by the national “.nl” TLD. In terms of innovation the City of Amsterdam has traditionally been a national leader in providing IT Services to its citizens and will make all efforts so that the new TLD will reflect that ongoing innovation.

REGISTRY’S VISION
The Registryʹs vision is that as the internet has reached global coverage, the internet will enter the ‘capillary system’ of society, with a strong focus on local relevance. The TLD we apply for reflects that local relevance and should become the City’s platform for business and communication for all of its stakeholders. The Registryʹs mission is to know the local (digital) needs and how the new TLD can facilitate both the commercial, functional and emotional aspects of bringing the new TLD to the City and its stakeholders

The Registryʹs strategy is to collaborate with acknowledged leaders in Internet technologies and service providers to expand Internet capacity in an orderly manner through new charter TLDs.

Market
There are already nearly 5 million “.nl” domain names, and the Netherlands has the highest domain density (number of domains per capita) in the world with currently 0.39 domains per capita and has one of the most extensive internet infrastructures in the world. “.amsterdam” ,being the TLD for the capital city of the Netherlands clearly expects to profit from the extremely high interest in registering and using domains and in the internet as a whole.

Statistics
The City of Amsterdam has registered:
-780.152 inhabitants
-72.000 enterprises
-18.000 enterprises with Amsterdam in their name
-400.000.nl domain names registered to addresses in the Amsterdam Region
-20.000 .nl domain names with Amsterdam in their name
-14.000 .nl domain names ending with “amsterdam”
-350 hotels
-150 neighborhoods
-5.000 streets
-7.000 shops
-100’s of foundations and associations
These numbers reflect a clear indication of the quantitative potential for domain name registrations and use of the TLD at the same time. We are confident there’s far greater potential than the numbers in our business plans – addresses can become domain names (like http:⁄⁄rokin14.amsterdam), which has the potential to multiply the number of domain names sold in the business plan by an order of magnitude.

The Registry has in total a wide target audience. At the end of the first year the Registry estimates a potential of 7.000 domain names. By organizing a sunrise, landrush and open registration that will follow, all efforts are made to maximize the amount of domain names being bought and used at the moment of the launch. During sunrise trade names and trademark holders can be the first to claim their domain name. This will generate a positive sentiment, by guaranteeing that rightful prospective owners will not need to take reactive and costly actions, but are guaranteed the ownership of a domain name in a well established, well branded and positively acknowledged TLD, tied to one of the best known cities in the world.

During landrush the Registry will start selling specific generic domain names that are likely to encounter a higher than average level of interest for purchase. This in order to prevent the domain names to fall into the hands of domain name squatters, limiting the actual use of these important domain names.

After that, the remaining domain names will be issued on a first come first serve basis.

The Registry projects that the number for registrations in the new .Amsterdam TLD would reach at the start 3.500 in 2013, climbing to 7.000 at the start of 2014 and 14.000 at the start of 2015

The “.amsterdam” TLD will benefit registrants, Internet users and others in a number of ways.

i. The goal of the proposed TLD is to provide the City of Amsterdam, her citizens, trademark holders, partners, cultural and other target audience to promote themselves through the domain names with the TLD “.amsterdam”. The most powerful benefits for the target audience is that they have a new, easy and powerful way, namely the “.amsterdam” TLD, to connect with each other, search for local identities, enterprises or other City related activities. The reputation of the City is very powerful due to its history of over seven centuries and the current “I amsterdam” branding strategy, which in itself is already a likely motivation to register domain names – the City generally is “something to be proud of” and this will likely to be perceived as to be reflected in the TLD. The international brand awareness, recognizability and uniform spelling of the name of the City, will also contribute significantly to the adoption and use of the this TLD.

ii.
The Registry anticipates that “.amsterdam” will add to the current space more differentiation in the way that it provides registrants the opportunity to have an important new means of showing and⁄or promoting their brand or shop, identity or community via a TLD that reflects a locality and a bond (to the City and its citizens) in a positive way. This TLD is family of and yet distinctly different from the “.nl” TLD – the most successful TLD in The Netherlands. In terms of competition the Registry will provide the community, stakeholders and visitors of the City of Amsterdam with a TLD that will strengthen their bond to the City and its values and adds more consumer choice in a market dominated by the national “.nl” TLD. Many of the domain names desired by local businesses had been taken by companies elsewhere in The Netherlands and the introduction of the “.amsterdam” TLD gives them a good chance to claim a ‘prime’ domain name for their business again. In terms of innovation the City of Amsterdam has traditionally been a national leader in providing IT Services to its citizens and would like the new TLD to reflect that ongoing innovation. With respect to domain name registration the innovative element can be found in the concept that a number of domain names will be reserved and issued in batches to parties with a specific interest in the entire batch of domain names in conjunction with the obligation for the registrant to actively use these domains in line with such specific interest. An example would be the grouping of domain names offered for sale in the area of ‘housing’: wonen.amsterdam, woningen.amsterdam, koopwoningen.amsterdam, huurwoningen.amsterdam. The prospective buyer of this cluster has the advantage of owning related domain names to maximize his potential, with the obligation to actively publish and refresh those domain names within a short time frame and with a high frequency after acquisition.

Also, the purchaser of a domain name will be offered the option to receive a gift card, so the acquired domain name can become a present to friends or family – the branding campaign of the City will be used to emphasize these kinds of possibilities.

iii.
The goals of the proposed TLD in terms of user experience is that the TLD will first of all strengthen the bond between the target audience and the City of Amsterdam. It should provide the citizens, companies, institutions and communities with a domain that enhances their communities and⁄or commerce, while allowing them to express their ties to the City. The “.amsterdam” domain names should therefore be highly visible in the City and online and the major source for any information on the City. Promotion will include all imaginable marketing materials, gift cards (allowing a domain name to be bought and given as a present) - all of which will contribute to the goal of rapid acceptance, recognizability and usage of the TLD. Part of the marketing strategy is to offer domain name holders tools to market the activities on their newly acquired domain name as well. The Registryʹs plan envisages the use of an extensive public relations campaign -starting with the City of Amsterdam’s existing marketing campaign “I amsterdam”-, direct mail to target audiences, use of promotional strategies (gifts for the first domain name, such as t-shirts with the .TLD) and media. The Registry also recognizes that marketing for “.amsterdam” ultimately depends on its relationship with registrars as equal partners. Registrars will be the primary point of contact with potential registrants on these TLDs, and the Registry will utilize the channels already developed by registrars of its technical partner SIDN. An important aspect for the user experience will also be that availability of domain names via a broad range of registrars and resellers. SIDN cooperates with around 1.800 registrars on the “.nl” TLD. Amongst them are a number of Netherlands based and also many international ICANN Accredited Registrars who provide domain registration services directly and via resellers to registrants. The response under the Dutch ICANN Accredited Registrars with regard to the “.amsterdam” initiative has been extremely positive and a high availability of registrars and resellers offering “.amsterdam” domain names is therefore to be expected.


18b iv
The registration policies in order to reach these goals the Registry aims to put in place several specific guidelines in the registration process.

The Registry plans to set up the following registration policy:

I - pre-launch
This phase will be used for determining optimal pricing strategies after consultation with registrars, local media partnerships and the branding of the TLD. As there have been relatively few TLD’s other than “.nl”, we feel we need to place emphasis on setting our “.amsterdam” TLD as a brand.

II- sunrise
During sunrise tradenames and trademark holders can be the first to claim their domain name. This will be a positive experience in the sense that the rightful trademark or tradename holders can prevent someone else claiming their domain names. Thus In this way internet users will find the relevant information of the holder that they expect at this domain name.

III - landrush
This period is both critical in generating the right kind of positive public attitude towards the new TLD as it is for the business plan of the Registry. Therefore most resourcing of the companies involved with be aimed at preparing for and execution during this period. The Registry will reserve several domain names for the City of Amsterdam, which they could use for the promotional activities and offering its services to the public. These reserved domain names for the City of Amsterdam contribute directly to the City of Amsterdam’s city marketing goals and those of her Partners. For Example schiphol.amsterdam and airport.amsterdam (Amsterdam Airport) 

Next to that a number of domain names will be reserved for the City of Amsterdam and its institutions, several domain names are sold in batches to parties with a specific interest in the entire batch of domain names in conjunction with the obligation for the registrant to actively use these domains in line with such specific interest. Examples of these ‘batches’ mentioned above would be “wonen.amsterdam”, “woningen.amsterdam”, “koopwoningen.amsterdam” and “huurwoningen.amsterdam”. By offering these four domain names for sale as a ‘batch’ during the landrush period sale, with the conditions of active use within a short period after purchase (to be determined) we can achieve rapid public availability of these strategic domain names. On top of that, by auctioning these batches, we create a level playing field allowing all interested parties to acquire those names (with the conditions mentioned being a part of the sale), while at the same time offering the new owner the strategic advantage of having acquired a coherent set of domain names, which can be considered to be of premium value.

IV launch - 
The remaining domain names will be sold on first come, first serve basis.
Wide promotion for the use of the TLD appealing to both wide audiences and specific markets, has the goal of broad acceptance and achieving at least the amount of growth that was projected in the business plan. Promotion will include all imaginable marketing materials, gift cards (allowing a domain name to be bought and given as a present) etc.

While registration and auctions will remain a key element of the Registry’s business the first year, they will be supplemented by an increasing focus on the provision of a complete range of services, by either the Registry or the Registrars, to enable its customers to grow their e-commerce.

v. With regard to the protection of the privacy or personal information of registrants and users the Registry will not impose any specific measures. The Registry will consider applying for the permission to restrict WHOIS in accordance with the limitations requested by Fundació puntCAT, the registry operator for the .cat TLD.

The registry refers to the RSEP procedure initiated by Fundació puntCAT on October 5, 2011 under the name ‘Whois changes according to EU data protection legislation’. As the registry is based in Amsterdam, the Netherlands, it is, as the .cat and .tel registries subject to the EU Data Protection Legislation which is in this case implemented into Dutch law. In short the acceptance of this amendment to the regular WHOIS will lead to the non disclosure of the data associated to the domain names registered by individual registrants that choose so.

The registry chooses however to request the allowance to provide such amended whois services at this stage only as an alternative to the regular whois services that the registry will implement if reaching an agreement on the amended whois services may not be feasible as a result of the current application procedure or if the evaluation of this application is seriously hampered by any discussion or the necessity of extended evaluation.

Although the amended whois is a serious and important element for the Registry, it is at the same time more important for the registry to obtain the delegation in due time. In that case the Registry expects that Registrars will offer Privacy Protect services to (prospective) registrants and will apply for an amended WHOIS via the ICANNʹs Registry Services Evaluation Process (RSEP).

The Registry will adopt a number of operational rules and other measures to eliminate or minimize social costs and other negative consequences and costs imposed on consumers.

18 c i. In general the Registry has the goal to minimize social costs by implementing a Sunrise period that is aimed at delivering domain names to those parties that have an established right to those names and at preventing ‘cyber squatting’ for specified generic domain names. In order to achieve that goal, we will implement mechanisms for selling those specified generic domain names that guarantee fair, transparent and market based pricing. As the usage by The City of “.amsterdam” is a contributing factor to the overall success of the adoption of the TLD, The City will keep reserved for its own use a set of domain names that are particular to the City, its bodies and its institutions.

Domain names that are considered to be offensive, or have the potential of tarnishing the reputation of the City, will be blocked for use.
 
As a part of the policy the Registry will prepare a blocked list of domain names that can not be registered. On this list are names that are blocked for legal reasons or by the policies of ICANN. Examples would be 112.amsterdam (with 112 being the European standardized emergency number) and icann.amsterdam. The Registry will also prepare a list of reserved names. On this list will be names we will not distribute at all (like “sex.amsterdam”), or those that we want to distribute to the City of Amsterdam, its political system, officals, offices, institutions and other affiliated bodies or Partners. Examples would be “gemeente.amsterdam”, “ggd.amsterdam”, “pvda.amsterdam” and “klm.amsterdam”.
Overall the City will take a liberal stance on the registration of domain names, realizing that generally speaking not the domain name itself would be objectionable, but the contents of the website running on the domain name. However, as the City in this particular case clearly aims to disassociate itself from certain reputations deemed to be negative, a few domain names related to those negative reputations would be blocked.


Sunrise Period
During the sunrise period, we aim to minimize the social costs to legitimate owners of Trade Names and Trade Marks. Every request for a domain name will be evaluated and judged by an indepependant Sunrise Service Provider.

Land Rush Period
In this phase The Registry will start selling specific generic domain names that are likely to encounter a higher than average level of interest for purchase. Among those specific generic domain names are:

- named parts of the City

- activities related to the City

- communities in the City

- commercial activities in the City


The following selling mechanisms will be implemented:

- sale of single and generic domain names against a price fixed by The Registry. If multiple parties are interested in a single domain name, we will use a bid mechanism to select the registrant.

- Sale of specific domain names that are related to geographical areas of the City (like the names of streets, boroughs, areas and the likes), those of communities, whereby the following factors carry weight in selecting who will be able to acquire the domain name:

o Projected active use of the domain name

o The ability of a person, community or legal entity to claim the right to, or support for the application of that domain name, based on public criteria to be set in advance.

- Auctioning of single and generic domain names, for which no fixed price will be set in advance.

- Auction of clustered, themed generic domain names that represent a higher combined value to the prospective owner. By selling certain domain names as a cluster, we will significantly reduce the costs for the prospective owner, as he or she needs not apply for multiple domain names at the same time.


After that, the remaining domain names will be sold on first come, first serve basis.

18.c.ii
We aim to offer registrants as many cost advantages as is possible by:

- Preventing cyber squatting and therefore inflation of domain name prices by third parties

- Offering all available protection mechanisms for Trade Mark and Trade Name owners in acquiring their domain names, including the offering the tools for acquiring (at a significant discount) all domain names that include the most likely typo’s (utilizing a Typo Tool)

- having the domain names offered by as many Registrants as is possible, maximizing competition and attrative pricing for Registrants. The Registry expects in this respect to directly profit from the excellent relations SIDN already has with a large number of registrars.


18.c.iii 
We will not offer domain names for any period longer than ten years. Furthermore, we do not intend to offer any contractual agreements with our Registrants regarding price increases. 

No

Not Available

Yes

Measures for protection of geographic names in the .amsterdam top-level are being taken for Country and territory names (conform Specification 5 in the Base Agreement).

Registry Operator will exclude all country and territory names from registration on the second level, the only level in which registrations will be offered by Registry Operator, specified in Specification 5 of the Base Agreement:

5.1. the short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉;
5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;. 

The names on these lists will be shown in the registries’ Whois with status ‘excluded’.

Registration of these names will be limited during the entire lifetime of the .amsterdam top level domain to registrants who are designated by the government or public authority of the concerned country or territory. Authentication of representation is based on the existing methodology developed for release of country names in the .INFO top-level domain.
A government or public authority wanting to register their country or territory name under .amsterdam has to get an authentication by GAC Secretariat. This authentication and the name of the designated beneficiary need to be transferred to Registry Operator, who will issue an authorisation number to the designated beneficiary in the country concerned. The domain name can be registered through an accredited registrar with the designated beneficiary as the registrant, using the authorisation number.
The registrant of these domain names can only be changed after registration if the new designated registrant also has been authenticated by GAC Secretariat.

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.

All infrastructure, systems, procedures and processes used for supporting registry services of .amsterdam will be based on SIDN’s infrastructure, systems, procedures and processes for supporting registry services for .NL. 
SIDN deploys a fully redundant infrastructure. All systems supporting registry services (with the exception of the public DNS services) are located at two geographically separated production sites that together form one logical network. The public name servers are geographically spread with a gravitational centre in The Netherlands. This suits the need of the .amsterdam top level, which is also aimed at the Dutch community.
SIDN is an ISO 27001 certified organization. Procedures and processes related to registry services at SIDN are based on the principles of this standard.

23.1 Domain Registration Services
Domain Registration Services are provided to all .amsterdam Accredited Registrars through the Shared Registration System. The SRS for .amsterdam is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web-interface. Both interfaces are available to all accredited registrars and offer the same functionality. Both interfaces are available through IPv6 and the SRS supports IPv6 AAAA Resource Records in all relevant information fields.

The SRS is compliant with all EPP RFC’s (3735, 3915, 5730, 5731, 5732, 5733, 5734 and 5910) and performs well within the ranges as specified by the SLA Matrix set by ICANN in Specification 10 to the Base Agreement.

Registration transactions for domain names eligible for registration (i.e. domain names that are not excluded or reserved) are handled fully automated by the SRS. Registration transactions are: 
 - create, update, renew, transfer and deletion of a domain name;
 - acknowledgement or refusal of a transfer request;
 - restore of a domain name in redemption grace period;
 - create, update and deletion of a contact;
 - create, update and deletion of a name server.

Upon expiration of a domain name, the registry will automatically renew the registration with one year. If the domain name is deleted or successfully transferred to another registrar within 45 days of this auto-renewal, the charge made for the auto-renewal will be credited.

Deleted domain names are quarantined in a Redemption Grace Period for 40 days before becoming available for registration anew.

The SRS accepts DNSKEYs for signed delegated domain names and the DS record for the child zone will be computed by the registry.

Not all registration transactions are always allowed. For a full description, please see the answer provided to Evaluation Question #27 ‘Registration Life Cycle’.

Excluded domain names will be listed in the registry agreement and honour ICANN’s requirements regarding reserved domain names. Domain names excluded from registration are not in the .amsterdam zone file, have a Whois status ʹexcludedʹ and cannot be registered by anyone. An EPP «create» command will be rejected by the shared registration system.

Reserved domain names can only be registered by a designated or authorized registrant. Policies and procedures regarding the dissemination of reserved domain names will be provided in the registry agreement and published on the registry website for .amsterdam.
After registration, updates of the registrant are blocked in the registration system. An EPP «create», «update» or «transfer» command will be manually reviewed by .amsterdam registry operator and has to be authorized before it will be processed by the registration system.

A test environment of the SRS will be made available to registrars, providing all needed functionality to create and test administrative interfaces.

23.2 DNS and DNSSEC Services
At launch, .amsterdam will be set up with 2 geographically separated name servers (clusters) and an Anycast name server. The Anycast name server will have a minimum of 5 nodes. If and when demand rises above SIDN’s capacity baseline threshold, additional name servers or nodes will be introduced.

All public name servers for .amsterdam are reachable via IPv4 and IPv6 addresses.

The zone file for .amsterdam will be signed with DNSSEC and checked for integrity and accuracy before being published. Zone file generation and publication will be done every half hour, matching the requirements specified in Specification 10 of the Base Agreement. NSEC is used for authenticated denial of existence.

SIDN requires registrants to obey the rules set out in a ‘technical requirements document’ that defines minimal technical requirements for the registration (and delegation) of domain names (in the DNS). Most of the technical requirements are enforced by technical controls in the shared registration system. Other requirements are checked once the domain is delegated, by means of an in-house developed tool called the ‘DNS crawler’. This tool produces monthly feedback on the DNS quality of the domain names registered to registrars. It also reports violations of the technical requirements and DNS errors to registrars and to our compliance monitoring team.

A publicly available name server check will be provided on the website of .amsterdam. This name server check is identical to SIDN’s name server check (https:⁄⁄www.sidn.nl⁄en⁄about-nl⁄registering-a-domain-name⁄dns-check⁄) and provides DNS and DNSSEC information about both delegated and undelegated domain names.

23.3 Registration Information Services
.amsterdam’s WHOIS will be offered publicly through a website and as a command-line protocol over port 43. 
The HTML version of the public WHOIS will be accessible through http:⁄⁄whois.nic.amsterdam and will be protected by a Captcha mechanism. The output of the WHOIS service on port 43 is text based (ASCII). Every line is terminated with CRLF as is specified by RFC3912. Besides the standard port-43 WHOIS, we also support a HTML-based WHOIS and an XML-based WHOIS. The WHOIS data is updated in real-time.

Additionally, an ‘IS’ service will be provided for retrieving domain registration statuses. This is a domain availability service, which only shows the status of a domain name. This function could be provided by IRIS⁄CRISP⁄DCHK, but those standards are not commonly used or known. 

Accredited Registrars also have access to an XML-based WHOIS, which is partly based on the IRIS specifications (RFC3982 DREG). This WHOIS is only available to accredited registrars and shows full registration information. A free client code is offered through Perl CPAN (Net::Whois::SIDN). The data returned is in UTF-8 format, to support international characters.
Additionally, registrars can retrieve registration information through the EPP interface of the SRS. 

SIDN will comply with new standards if and when they are introduced, for example standards based on the results achieved by the IETF WEIRDS group .
Developments in the area of RESTful WHOIS services are studied and our technical advisors work closely with the IETF (IETF WEIRDS WG) community to get this to a standard. When a standard for RESTful WHOIS arises, it will be implemented on IPv4 and IPv6.

.amsterdam will further provide Zone File Access to the public and Bulk Registration Data Access to ICANN entirely in line with the requirements as specified in Specification 4 to the Base Agreement

The .amsterdam registry will provide periodic reporting to ICANN as specified in the Base Agreement and Specifications.

Registrars will receive monthly reports regarding registration transactions (also used as a specification to billing) and feedback on the DNS quality of the registered domain names (through the output from the DNS Crawler).

24 SRS Performance

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD. 

The Shared Registration System for .amsterdam is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.

Access to the SRS for both interfaces is restricted to registrars through a username and password and connections are only allowed for registered networks (IP-whitelisting). The web interface is secured by HTTPS. The EPP interface uses TLS for encryption of the transport layer.

Both interfaces are available through IPv6 and the SRS supports IPv6 AAAA Resource Records in all relevant information fields.

The EPP interface is based on the following standards:
 - Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) – RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt), 
 - Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
 - Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
 - Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
 - Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
 - Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)

The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
 - After being idle for 10 minutes;
 - After being open for 24 consecutive hours;
 - Upon receiving a ‘logout’ command.

Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.
For more information regarding EPP, please see the answer provided to Evaluation Question #25 ‘EPP’. 

The Shared Registry System is an in-house developed system. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see the answers provided to Evaluation Question #30 ‘Security Policy’ for more details).

Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q24-Tuvit’).

SIDN deploys a fully redundant infrastructure. All systems supporting registry services (with the exception of the public DNS services) are located at two geographically separated production sites that together form one logical network. 
Both data centres hosting the production locations are certified and offer high quality security and support services. For a more detailed description, please see the answers provided to Evaluation Question #34 ‘Geographic Diversity’. 
Contracts with both data centre providers are available and added as an attachment to Evaluation Question #39 ‘Registry Continuity’.

Although these locations are marked as ‘primary’ and ‘secondary’, there is no active⁄passive location setup. Both locations provide active services and have accurate (mirrored) data. All registration data in use by registry services is maintained in a database that is synchronized over both production locations. At both locations an additional standby database is present. This makes it possible to switch between locations without loss of data for committed transactions. Both production sites have active systems for all applications needed to provide SRS and WHOIS-services and the hidden primary name server. With this setup, the Recovery Point Objective for registry services is negligible. 
Testing for recovery of services is done at least once a year. During the last test SIDN performed, the recovery time for all registry services was less than 10 minutes. This is far below the required Recovery Time Objective of 4 hours.

Both production locations are connected through a Dense Wavelength Division Multiplexing (DWDM) based dark fibre ring, owned and operated by SIDN. This fibre ring is designed so that fibres never share the same physical path or the same duct. This setup provides the locations with active connections, even in the event of a fibre cut. Connectivity to the internet is also set up redundantly, through multiple connections and via different network operators, both commercial and non-commercial. These connections are terminated on separate routers and geographically separated locations. Furthermore all network equipment is fully redundant. This applies to routers, switches, firewalls and load balancers and even network interface cards in a number of servers (by means of link aggregation aka bonding or ‘NIC teaming’).

Bottlenecks in the systems-design and –infrastructure are avoided by making sure that there is always a surplus in capacity, calculated over peak-times and monitored on a constant basis. This is handled by the ITIL ‘capacity management process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for more information).
Our Test Department conducts load- and performance tests regularly on software that is developed or in use, in order to detect issues early on. The standards for these tests are set quite high. Soft- and hardware will not pass the testing, if it is not able to deal with multiple times the load that is expected to have under predicted peak-conditions. Trend analysis is performed on all systems to support these predictions.
In the exceptional event of needing to handle unusual large amounts of traffic, systems for traffic-shaping are present. Traffic-shaping provides the abilities to cut off or limit access to specific abusive users, while keeping the services available for others.

Diagrams depicting SRS systems are enclosed in the attachment ‘Q24-SRSdiagrams’ and include:
 - Production location diagram ⁄ access layer
 - Registry Application Server Diagram
 - Registry Services Systems

The SRS is based on diskless Linux systems, with separate storage servers containing the file systems. Management of the database file systems on the storage layer is done by Oracle Enterprise Manager⁄Grid Control (http:⁄⁄www.oracle.com⁄us⁄products⁄enterprise-manager⁄index.html). One of both locations runs the primary database. All mutations on the primary database are directly shipped to all standby databases. Every transaction that is committed on the primary database is secured on the standby database. Therefore no committed data can ever be lost in a disaster scenario where the primary database gets lost.
Both production locations contain additional standby databases, configured with fast-start failover, available for production. One standby database is used as the current standby database for production; the other one is used for cloning of a production database in order to investigate incidents that require a database with production data in it. In case of a server malfunction, it’s easy to switch over to a standby database. However, this is no resolution for data corruption. Therefor a daily backup is made of the production databases. This backup is copied to the central backup server and put on tape.
Database replication puts high demands on network latency and packet-loss. The dark fibre ring and the selection of the locations for our data centres allow for extremely short round-trip times, often less than 1 ms and generally not above 5 ms. Packet-loss baselines are set to 0% for ‘normal’ operations and cannot exceed 1%. Exceeding of this threshold leads to closer investigation via the ‘Incident Management Process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for details on this process). 
Monitoring of the connections to the public internet depend on network-distances and show round-trip times well below 300 ms in general. Packet-loss for public internet connections is very low as well, way below 10%, due to carefully selected network-operators and tight monitoring.

SIDN is researching cost-efficient alternatives for the current Oracle database management system setup. Requirements for any alternative solution include matching of all functionalities and service levels for database management and reporting capabilities as described in the answers to the Evaluation Questions. If a feasible solution is found and tested, it will be implemented for .amsterdam’s registry services. Details of such implementation will be available to ICANN for evaluation and testing before implementation.

Currently, SIDN operates SRS services for .NL that are well in range of the SLA’s described in Specification 10 of the Base Agreement. Measurements based upon the definitions in this Specification show the following performance for current SRS services:

EPP Service availability
 - SL SIDN: 99,955% (Q4 2011)
 - SLR Specification 10: 〈= 864 min of downtime (˜ 98%)
EPP session command RTT
 - SL SIDN: 〈= 360 ms, for at least 90% of the commands
 - SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands
EPP query command RTT
 - SL SIDN: 〈= 350 ms, for at least 90% of the commands
 - SLR Specification 10: 〈= 2000 ms, for at least 90% of the commands
EPP transform command RTT
 - SL SIDN: 〈= 750 ms, for at least 90% of the commands
 - SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands

Performance for SRS services for .amsterdam will be in line with current performances for .NL.

Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .amsterdam SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.

For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

SIDN therefore has all necessary resources on hand to provide all services described in this answer.

25 EPP

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD. 

The Shared Registration System for .amsterdam is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.

The EPP interface is based on the following standards:
 - Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
 - Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) – RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt), 
 - Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
 - Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
 - Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
 - Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
 - Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
 - Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)

The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
 - After being idle for 10 minutes;
 - After being open for 24 consecutive hours;
 - Upon receiving a ‘logout’ command.

Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.

25.1 EPP objects and commands
EPP is used to create or edit three types of objects: domain names, contact persons and name servers. The object domain name refers to existing contact persons (registrant, administrative contact and technical contact) and name servers.

The SRS supports the following EPP commands:
Sessions 
 Hello⁄greeting
 Login
 Logout
 Poll
Domain names 
 Domain check
 Domain info
 Domain create
 Domain update
 Domain delete
 Domain transfer
 Domain renew
Contact persons 
 Contact check
 Contact info
 Contact create
 Contact update
 Contact delete
Name servers 
 Host check
 Host info
 Host create
 Host update
 Host delete

 25.2 Configuration Settings

clTRID
The clTRID element can be used with all commands in order to link the registrars’ identification to the command. When responding to this command, SRS sends this value back. The value for this element is freeform and should be unique. No checking is performed on this field by the registry.

Domain object
 - Domain.ns: The ‘hostObj’ implementation is chosen for authoritative name servers for a domain name. The number of authoritative name servers has been limited to a maximum of thirteen but can be left empty. A domain should have a minimum of 2 name servers before the domain name is published in the zone.
 - Domain.registrant: The registrant attribute is mandatory.
 - Domain.contact: Only the ‘admin’ and ‘tech’ contact person types are supported and the following additional rules apply:
 - a minimum of one and a maximum of one ‘admin’ must be submitted for a domain name
 - a minimum of one ‘tech’ must be submitted for a domain name
 - Domain.authInfo: The authInfo attribute is only used in the transfer procedure. Consequently, this attribute is only used in the Domain transfer (op=“request”) command and it is also issued in the response message to the Domain info command and in the response message after a successful transfer. 
 Note: this attribute is mandatory in the Domain.create command in EPP and will be filled with a value generated automatically by the SRS (see ‘Proprietary EPP Extension’).
 - Domain.status: The following contact domain statuses are not used in the SRS:
 - PendingUpdate
 - PendingRenew
 - PendingRestore. The domain name status ‘pendingRestore’ is not used in the SRS, since a restore report is a mandatory element of the restore-command.

Contact object
 - Contact.name: In the EPP standards, the name is part of the «postalInfo» group. Both localized (unrestricted UTF-8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for a name in order to avoid a situation where different names for the contact person are included in both formats.
 - Contact.org: In the EPP standards, this field is reserved for the name of the organization. In the SRS implementation, however, it has been decided to use this field for the name of the department with which the contact person is associated (affiliated). The proprietary EPP extension contains two fields to describe legal registration information of companies (see ‘proprietary EPP extension’ below) and the organizations’ name is to be provided in Contact.name. 
 - In the EPP standards, the «org» attribute is part of the «postalInfo» group. Both localized (unrestricted UTF 8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for the name in order to avoid a situation where different names are included in both formats.
 - Contact.status: The following contact person statuses are not used in the SRS:
 - clientDeleteProhibited
 - clientTransferProhibited
 - clientUpdateProhibited
 - pendingCreate
 - pendingDelete
 - pendingTransfer
 - serverDeleteProhibited
 - serverTransferProhibited
 - serverUpdateProhibited
 Consequently, the responsible registrar is also unable to set ‘client’ statuses.
 - Contact.postalinfo: A maximum of 1 is allowed. Only type=ʺlocʺ is supported.
 - Contact.street: A maximum of 1 is allowed. A PO Box may not be entered in the first street tag.
 - Contact.sp: The optional state⁄province attribute is not implemented.
 - Contact.pc: This field is mandatory if country code “NL” is used. In this case, the postal code must always start with four digits and end in two letters (regular expression: ʺ[0-9]{4}[A-Z]{2}ʺ).
 - Contact.voice: The telephone number is mandatory.
 - Contact.trDate: This attribute is not implemented, since contact persons cannot be transferred in the SRS. 
 - Contact.authInfo: This attribute is not implemented, since contact persons cannot be transferred in the SRS.
 Note: this attribute is mandatory in the Contact create command in EPP and will be filled with a value generated automatically by the SRS.
 - Contact.disclose: This attribute is not implemented. Only the sponsoring client (responsible registrar) and the server (SIDN) may view the information for a contact person in the SRS.
 - Contact.id: The submitted value of this attribute will be ignored in the SRS and the server will automatically generate an ID (= handle). The handle that is generated by SIDN follows the format XXX999999-YYYYY (regular expression: [A-Z]{3}[0-9]{6}[-][A-Z0-9]{5}). The first part of this handle is used to identify the contact. The second part is used to identify the maintaining registrar. If a domain name is transferred, all related contacts are copied to a new contact maintained by the gaining registrar. In that case, the contact-identifying part of the handle is unchanged and the registrar-identifying part is updated to reflect the new maintainer.

Host object
 - Host.status: The following name server statuses are not used in the SRS:
 - clientDeleteProhibited
 - clientUpdateProhibited
 - serverDeleteProhibited
 - serverUpdateProhibited
 - pendingCreate
 - pendingDelete
 - pendingTransfer
 Consequently, the responsible registrar is also unable to set «client» statuses.
 - Host.name: The name for a name server cannot be updated in the SRS. Consequently, the chg attribute is not implemented in the Host update command.
 - Host.IP-adres: The number of IP addresses has been limited to a maximum of ten.
 - secDNS.keyData: The Key Data Interface is chosen, implementing ‘secDNS.keyData’. As a consequence secDNS.dsData is not supported. 
 - secDNS.maxSigLife: This optional attribute is not implemented. 

25.3 Proprietary EPP extension
SIDN provides a proprietary EPP extension (compliant with RFC 3735). The extension scheme is provided in the attachment ‘Q25-sidn-ext-epp-1.0.xsd’.
Since the proprietary extension is also used for registration of other TLD’s, including .NL domains, there may some elements present that are only in use for those TLD’s and will be ignored for .amsterdam. At the moment of writing, this is the case for elements containing the field ‘optOut’ (used for shielding privacy sensitive information in the .NL-Whois) and fields in the element ‘trnData’ (used in messages regarding escalation of transfers through the registry for .NL). Since .amsterdam is aimed at the same audience as .NL, we strive for an alignment in registry services and EPP-commands, however, if various policies lead to an unclear extension, we will decide to split the xsd to support only .amsterdam functionality.

This extension contains elements for the legal registration of companies in The Netherlands. This information specific to the Dutch market and relevant to the .amsterdam TLD. 

The proprietary extension also contains a status element ‘limited’. This status is a more fine-grained setting of the ‘serverProhibited’ status, allowing for:
 - Prohibition of changes to parts of an object (e.g. a domain object can be updated, but the registrant cannot be changed);
 - Authorization of commands before execution by Registry Operator (a command is validated before being accepted or denied).
This status is used for controlling the registrant of specific reserved domains where a validated registrant may not be changed, but contact details for the registrant may be updated as needed by the registrar. 
The EPP interface will show if the status ‘limited’ is present for objects and indicates that a command for this object will be rejected or pended. It doesn’t show the various types of this status used internally by the registry and the specific consequences involved. 

To facilitate various specific TLD policies for transferring domain names (including .NL, where transfer policy compliancy is supported by escalation procedures at the registry), the SRS generates unique values for the authInfo attribute upon creation of the object. These values are reset and generated anew when the following transactions occur: transfer, restore by non-maintaining registrar, registrant update and bulk transfer. A reset and regeneration of this value can be requested by the registrar-of-record at any time through the regular support channels.


Proprietary extension attributes and elements
 - Domain info
 Extension for status limited in response message
 - Domain cancelDelete
 Message extension used for .NL
 - Domain transfer (op = ʺrequestʺ)
 Extension for authInfo-value (“pw”) in response message
 - Contact info
 Extension for legal form, registration number and limited in response message
 - Contact create
 Extension for legal form and registration number
 - Contact update
 Extension for legal form and registration number
 - Host info
 Extension for limited in response message
 - All
 Extension for message with field, code and message in response messages


 25.4 Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .amsterdam SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

Next to the Development Team (10 staff responsible for the software development at SIDN), SIDN has a dedicated Test Team of 4 staff. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing.

SIDN therefore has all necessary resources on hand to provide all services described in this answer.

26 Whois

All core registry services for .amsterdam will be provided by .amsterdam’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD. 

SIDN acknowledges that Whois services are a good and proven way of disseminating information about domain name registrations and are therefore an integral part of the registry services.

SIDN has relevant experience in offering Whois services. The zone file for .NL is not publically accessible in full, a side effect of which is the emergence of a significant strain on the Whois services for .NL. Whois services for .amsterdam will be offered through the same technical infrastructure and based upon similar processes and functionalities as Whois for .NL. 

.amsterdam’s Whois will be offered publicly through a website and as a command-line protocol over port 43. Additionally, an ‘IS’ service will be provided for retrieving domain registration statuses. Accredited Registrars also have access to an XML-based Whois (and can retrieve registration information through the EPP interface of the SRS). 

.amsterdam will further provide Zone File Access to the public and Bulk Registration Data Access to ICANN entirely in line with the requirements as specified in Specification 4 to the Base Agreement. 

26.1 Whois for .amsterdam
The offered Whois service is RFC3912 compliant. 

Web-based 
The HTML version of the public Whois is accessible through http:⁄⁄whois.nic.amsterdam and is protected by a Captcha mechanism.

Port 43
The output of the Whois service on port 43 is text based (ASCII). Every line is terminated with CRLF as is specified by RFC3912. Besides the standard port-43 Whois, we also support a HTML-based Whois and an XML-based Whois. The Whois data is updated in real-time. 

IS function
As many other registries, SIDN offers a service within the Whois, called the ‘IS’ function. This is a domain availability service, which only shows the status of a domain name. This function could be provided by IRIS⁄CRISP⁄DCHK, but those standards are not commonly used or known. 

SIDN will comply with new standards if and when they are introduced, for example standards based on the results achieved by the IETF WEIRDS group. Developments in the area of RESTful Whois services are studied and our technical advisors work closely with the IETF (IETF WEIRDS WG) community to get this to a standard. When a standard for RESTful Whois arises, it will be implemented on IPv4 and IPv6.

XML-based 
SIDN offers a proprietary XML-based Whois, which is partly based on the IRIS specifications (RFC3982 DREG). This Whois is only available to accredited registrars and shows full registration information. A free client code is offered through Perl CPAN (Net::Whois::SIDN). The data returned is in UTF-8 format, to support international characters.

26.2 Data and Output
The data presented by the public Whois of .amsterdam will be compliant with Specification 4 of the Base Agreement. EPP standards RFC5730-5734 are followed regarding data format rules, ensuring a uniform response over different interfaces.

At the same time the .amsterdam hereby alternatively applies for a restricted Whois service in line with the current request to limit the publication of personal information via Whois from Fundació puntCAT the registry operator for the .cat TLD. 
.amsterdam refers to the RSEP procedure initiated by Fundació puntCAT on October 5, 2011 under the name ‘Whois changes according to EU data protection legislation’. 
As .amsterdam is based in the Netherlands, it is, as the .cat and .tel registries subject to the EU Data Protection Legislation which is in this case implemented into Dutch law. Because of this privacy legislation the Whois for the .nl domain currently publishes only limited information. An ‘open’ Whois in line with Specification 4 will clearly not be compliant with the Dutch privacy law where the .cat Whois proposal will as the acceptance of that proposal will lead to the non-disclosure of the data associated to the domain names registered by individual registrants that choose so. .amsterdam therefore wishes to implement .cat’s proposed amendment. 
.amsterdam is aware that .cat’s proposal has not been decided on by ICANN but would like to have the opportunity to consider the possibility to implement the Whois in line with the final outcome. 
Although this alternative to the full Whois is important for .amsterdam, .amsterdam wishes to make clear that it proposes the amended Whois services at this stage only as an alternative to the regular full Whois services and that .amsterdam will implement the full Whois if reaching an agreement on the amended Whois services may not be feasible as a result of the current application procedure, if the evaluation of this application is seriously hampered by any discussion on this subject or leads to extended evaluation.
For .amsterdam it is explicitly more important to obtain the delegation in due time than to have an (extended) discussion on the amended Whois proposal. In that case .amsterdam expects that the Registrars will offer Privacy Protect services to (prospected) registrants and will apply for an amended Whois via the ICANNʹs Registry Services Evaluation Process (RSEP).

26.3 Conditions of use
Use of Whois is subject to the ‘Whois Terms and Conditions of Use’, stating the following conditions:

Information is made available through the Whois service for the following purposes:
 - To enable technical problems associated with the working of the Internet to be resolved.
 - To facilitate the process of applying to register new domain names.
 - To help to protect intellectual property rights.
 - To help to prevent and combat illegal and harmful Internet content.

 A. Information obtained using the Whois service may be used only for the legitimate purposes described above and in accordance with Dutch privacy legislation. Under no circumstances may such information be used or allowed to be used:
 1. to facilitate the dissemination of solicited or unsolicited commercial or advertising material, by post, e-mail, telephone or otherwise; or
 2. in the context of bulk automated processes that make use of or query any SIDN computer system.

 B. Without SIDN’s explicit written permission, information obtained from the Whois service may not be compiled, recorded, duplicated (which here includes stored in an automated retrieval system) and⁄or published by printing, photocopying or any other means.
 C. SIDN reserves the right to restrict use of and access to the Whois service in the interest of operational stability.
 D. SIDN reserves the right to restrict or block use of and access to the Whois service for any party that contravenes these conditions.
 E. SIDN may revise these conditions at any time.

 SIDN does not guarantee the accuracy of the information made available via the Whois service. All intellectual property rights and database rights to the Whois database and the register from which that database is derived are held by SIDN.

26.4 Performance specifications
Currently, SIDN operates Whois services for .NL that are well in range of the SLA’s described in Specification 10 of the Base Agreement. Measurements based upon the definitions in this Specification show the following performance for current Whois services:

RDDS availability 
 - SL SIDN: 99,4% uptime 
 - SLR Specification 10: 〈= 864 min of downtime (˜ 98%)
RDDS query RTT 
 - SL SIDN: 〈= 50 ms, for at least 95% of the queries
 - SLR Specification 10: 〈= 2000 ms, for at least 95% of the queries
RDDS update time 
 - SL SIDN: = 5 min for at least 95% of the probes 
 - SLR Specification 10: 〈= 60 min, for at least 95% of the probes

Performance for Whois services for .amsterdam will be in line with current performances for .NL.
The following measures are taken to prevent abusive use of the Whois service:
 - A rate limitation of 20 requests per second per client, with a maximum of 100 requests per second overall is set on the port-43, and XML-based Whois;
 - A rate limitation of 20 requests per second per client, with a maximum of 500 requests per second overall is set for the IS function;
 - The web-based Whois is protected with a Captcha mechanism.

26.5 Network, infrastructure and management
Whois services are accessible through redundant interfaces. There are multiple instances of the Whois services, located in protected VLAN’s in two geographically dispersed data centres in the Netherlands. These two data centres are mirrored production sites. If one location fails or is unreachable, the other location automatically takes over. Access to the Whois service is separated from the Internet through firewalls and load balancers.

The Whois service will consist of two Java based Application Servers. Two F5 Local-Traffic Managers (LTM’s) will balance the traffic to these two Whois servers. When demand rises to the Whois service, more servers can be added to the service. The LTM will provide a virtual service, to which servers are added or deleted when necessary. A minimum of downtime is ensured for upgrading the Whois service (e.g. due to changing or adding functionality). Traffic shaping is also done by the LTM’s. Two firewalls will deliver a security layer (as a first line of defence) on the Whois service. 

See attachment ‘Q26-Whois_Architecture’ for a depiction of the Whois infrastructure.

The F5 LTM’s and the firewalls are shared with services for .NL. This also applies to the IT infrastructure, which provides the interoperability between the two data centres for production and SIDN’s office location as the overall command and control location. The infrastructure provides a transparent Layer 2 over 10Gbps paths over dark fibre between all locations. The highest throughput possible at this moment is 30Gbps.

The infrastructure has two independent uplinks to the Internet. One connection is directly connected to the AMS-IX (SIDN is member of AMS-IX since 1998). The other connection is connected through the BIT network, which is connected to AMS-IX, DE-CIX, LINX and local parties like NL-IX, GN-IX and NDIX.

At the back-end, the Whois servers are connected to the Shared Registry Systems’ database. The Whois servers have a read-only access to the data needed for Whois services in the database. Direct access to the database ensures real-time information provided in answers to Whois requests. More details are provided in the answers to Evaluation Question #32 ‘System and Network Architecture’.

All Whois requests are logged and kept for one week. After this period, statistical data will be extract from the logging, and the logging will be removed from the systems.

Patch management is actively applied to all systems that support registry services. Common practices (like the Security Configuration Guides from NSA) are followed. SIDN is ISO27001 certified, which reflects a high security awareness of the employees. More details are provided in the answers to Evaluation Question #30, Security Policy.

26.6 Zone File Access 
As described already above, also zone file access will be provided via the back end services of SIDN. 

.amsterdam will offer via the Centralized Zone Data Access Provider its standardized Zone File Access Agreement to grant any interested internet user who provides identification and contact details free access to the Zone Files using a sub format as described in Specification 4 under 2.1.4 of the Standard Master format defined in RFC 1035, Section 5 including all the records present in the actual zone used in the public DNS.
The zone file will be made available via the ICANN specified and managed URL .amsterdam.zda.icann.org. This will be done in conformance with the details under 2.1.3.
The agreement will contain the limitations to the right to use the zone file as specified in 2.1.5 and the right and grounds for the CZDA Provider and Registry Operator to reject access or revoke access as further detailed under 2.1.1. .amsterdam will provide access for a period of 3 months with the possibility of renewal.

.amsterdam will further co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by permitted users and provide bulk access to the zone files to ICANN, or its designee and to Emergency Operators designated by ICANN on a continuous basis in the manner that ICANN may reasonably specify from time to time. 


26.7 Bulk Registration Data Access to ICANN 
.amsterdam will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Thin Registration Data as specified in Specification 4 under 3.1.1 and in the format specified under 3.1.2 and make it available as specified under 3.1.3. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN. 

.amsterdam will further in case of a registrar failure, de-accreditation, court order, etc. that prompts the temporary or definitive transfer of the domain names to another registrar, at the request of ICANN, provide ICANN with up-to-date data for the domain names of the losing registrar. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. Registry Operator will provide the data within 2 business days. Unless otherwise agreed by Registry Operator and ICANN, the file will be made available for download by ICANN in the same manner as the data specified in Section 3.1. of Specification 4 to the Base Agreement.

26.8 Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .amsterdam SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.

For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

SIDN therefore has all necessary resources on hand to provide all services described in this answer.

27 Registration Life Cycle

A depiction of the Registration Cycle for .amsterdam is provided in the attachment ‘Q27-Registration_Life_Cycle.pdf’.

All ʹcommonʹ domain names eligible for registration (i.e. domain names that are not excluded or reserved) follow the domain name life cycle described below. 

Available
Domain name is available for registration. Whois status is ʹfreeʹ. 
Available transaction: EPP «create»

Pending Create
After receiving an EPP «create» command, the domain name goes through a ʹpending createʹ phase until the registration system has handled the request. This phase is skipped for regular domain names and is used for manual review of registration of reserved domain names (see ʹreserved domain namesʹ below). 
If registration is pre-authorized or no manual review is required, the domain name will automatically proceed to ʹregisteredʹ within milliseconds. 

OK (Registered)
Domain name is registered with an Accredited Registrar and is linked to one registrant and at least one administrative contact and one technical contact. Whois status is ʹactiveʹ or ʹinactiveʹ (if no nameservers are linked to the registration). 

Possible transactions for registered domain names
 - EPP «update» (via registrar of record)
 Updates registration details (registrant, contacts, nameservers, EPP client status). Command not possible with EPP status serverUpdateProhibited. 
 EPP status clientUpdateProhibited only allows for removal of this status, all other updates are rejected. 
 - EPP «renew» (via registrar of record)
 Expiration date is changed (prolonged by 1 to 10 years with a maximum of 10 years from renewal date). Domain status is unchanged. Command not possible with EPP status clientRenewProhibited or serverRenewProhibited.
 - EPP «transfer» (via all accredited registrars)
 Domain name enters ʹpending transferʹ until transfer is completed (or rejected). Command not possible with EPP status clientTransferProhibited or serverTransferProhibited.
 - EPP «delete» (via registrar of record)
 Domain enters ʹredemption graceʹ. Command not possible with EPP status clientDeleteProhibited or serverDeleteProhibited.

Pending Transfer
Domain name is in a transfer process from one registrar to another. Whois status shows active or inactive, depending on the number of associated nameservers. EPP status is ʹpendingTransferʹ.

Upon receiving a transfer request, the registration system sends EPP messages to the registrar of record and the gaining registrar with information on the received transfer request. The registrar of record can approve or reject the requested transfer within a 5 day transfer period. The gaining registrar can cancel the transfer request during the 5 day waiting period.

If the registrar of record approves the transfer or doesnʹt respond within the 5 day waiting period, the transfer will be successfully completed. The domain name will be registered with the gaining registrar and moves to the ʹregisteredʹ phase. The registrant and contact persons are copied to the gaining registrar. If the registrant and contact persons already exist in the gaining registrarʹs data, the existing handles are copied to a new contact maintained by the gaining registrar. The contact-identifying part of the handle is unchanged and the registrar-identifying part is updated to reflect the new maintainer. The name servers also transfer to the gaining registrar and can be updated after completion of the transfer.
A one year renewal will be charged to the gaining registrar and added to the expiration date (unless the expiration date exceeds 10 years from the transfer date).
Notifications of transfer completion are sent through the registration systemʹs EPP interface to both registrars.

If the registrar of record rejects the transfer or if the gaining registrar cancels the transfer request within the 5 day waiting period, the transfer is cancelled. The domain name remains registered with the registrar of record and moves to the ʹregisteredʹ phase.
Notifications of transfer completion (rejection) are sent through the registration systemʹs EPP interface to both registrars.

No other transactions are possible until the transfer process has been completed. After a completed transfer the domain name will be in the ʹregisteredʹ phase and a default renewal of one year is added. If the domain name was in ʹauto-renew graceʹ when the transfer was requested, and the transfer is rejected, then the domain name returns to ʹauto-renew graceʹ as long as the auto-renew grace period hasnʹt expired.

Redemption Grace
Domain name has been deleted and will be in redemption grace for 40 days. Whois status is ʹin quarantineʹ. EPP status is ʹpendingDeleteʹ. During this period all accredited registrars can restore the domain for the registrant of record. A restore report is a mandatory element of the «update» command with «rgp:restore» element. The EPP-status will be ʹpendingDeleteʹ until a restore (with restore report) is submitted and the domain name is restored to the phase ʹregisteredʹ.
After expiration of the redemption grace period, the domain name will automatically become available for registration (see ʹavailableʹ above).

Auto-renew Grace
After expiration of the domain name, the registry will automatically renew the registration with one year. If the domain name is deleted or successfully transferred to another registrar within 45 days of this auto-renewal, the charge made for the auto-renewal will be credited.
All available transactions and statuses are equal to the ʹregisteredʹ state.

Auto-renew grace ends when the registration is renewed or deleted by the registrar, if the domain name is successfully transferred to another registrar or after 45 days.
27.1 Excluded and Reserved Domain Names
Domain names excluded from registration are not in the .amsterdam zone file, have a Whois status ʹexcludedʹ and cannot be registered by anyone. An EPP «create» command will be rejected by the registration system.

Excluded domain names are:
Exclusions based on Specification 5 in the Base Agreement.
 - The label ʹexampleʹ;
 - All two-character labels;
 Labels that include hyphens in the third and fourth position (the .amsterdam registry does not offer IDN);
 - The labels ʹnicʹ, ʹwwwʹ, ʹirisʹ and ʹwhoisʹ (some of these labels will be used by the registry operator).

Exclusions based on technical requirements for .amsterdam
 - All one-character labels;
 - Labels containing more than 63 characters;
 - Labels that contain other characters than letters, numbers and hyphens;
 - Labels containing hyphens that are not between letters and⁄or numbers.

Reserved domain names can only be registered by a designated or authorized registrant. 

After registration, updates of the registrant are blocked in the registration system. An EPP «create», «update» or «transfer» command will be manually reviewed by .amsterdam registry operator and has to be authorized before it will be processed by the registration system.

gTLD registry and registry operator names
This list contains the names reserved for usage by gTLD registry and to be transferred with the Registry Database in the event of reassignment. Only the gTLD registry or gTLD registry operator can be the registrant of these names. 

Country and territory names
Registration of these names will be limited to registrants who are designated by the government or public authority of the concerned country or territory. 
A government or public authority wanting to register their country or territory name under gTLD has to get an authentication by GAC Secretariat. This authentication and the name of the designated beneficiary need to be transferred to gTLD operator, who will issue an authorisation number to the designated beneficiary in the country concerned. The domain name can be registered through an accredited gTLD registrar with the designated beneficiary as the registrant, using the authorisation number.
The registrant of these domain names can only be changed after registration if the new designated registrant also has been authenticated by GAC Secretariat.

List of country and territory names, conform Specification 5 in the Base Agreement
 - 5.1. the short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union (http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU); 
 - 5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and 
 - 5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names; 

27.2 Resources
SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD. Running the .nl TLD is the main activity of SIDN. More than 95% of all the time and resources are dedicated to this significantly important task. The work of SIDN is well regarded by its registrars and the Dutch Government. SIDN is a highly experienced and knowledgeable registry provider and from the date of its conception an active participant in ICANN and also active in IETF and for example the CENTR Community. SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed. 

As back end registry operator of .amsterdam SIDN will provide as a service all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.

For the services to .amsterdam the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.

SIDN will further provide all registrar and registrant support and handle abuse notices via its Support Desk. The SIDN support desk currently consists of a team of 14 highly skilled, well trained and experienced staff who handle all support questions (including abuse) and calls for the .NL TLD and the 1.3.e164.arpa ENUM delegation, also operated by SIDN. Together they serve about 1,800 registrars and about 2,7 million unique registrants. All support is provided in Dutch as well as in English. The SIDN support desk is organized in a first (9 staff) and second line (4 staff), with a dedicated manager who is a member of SIDN’s Management Team. The staff has a diverse background including experience on technical, policy and legal aspects in its ranks. The SIDN support desk has direct access to all the other specialists of SIDN who may act as a third line of support. The SIDN support desk handled on average in 2011 950 phone calls and 1625 mail calls per month.

SIDN which is ISO 27001 certified, has its own Security Officer who is responsible for all security related matters (physical as well as technical) of SIDN and therefore of SIDN services as back end provider. SIDN also has a legal counsel employed who is experienced in domain name law and policy matters and may support .amsterdam where necessary and act as a liaison to ICANN. 

SIDN therefore has all necessary resources more than available to provide all services described in the answers to the questions of the applicant guidebook for gTLDs.

Abuse prevention and mitigation will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry. The operations for .amsterdam will be conducted based on the same standards and procedures that SIDN has in place for .NL. This suits the needs of the .amsterdam top level, which is also aimed primarily at the Dutch community.

SIDN is very proud that .NL, being the 7th largest TLD with almost 5 million registrations, is one of the safest domains according, to amongst others, these independent reports by Norton and McAfee:
Norton Cybercrime Report (2011) -http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄
McAfee Mapping the Mal Web (2010) – http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf

SIDN is further an ISO 27001 certified organization. Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle. Abuse prevention and mitigation is an integral part of SIDN’s security policies. For more details regarding security, please see the answers provided to Evaluation Question #30 ‘Security Policy’.

What will be regarded as abuse?

Abuse has, as SIDN has seen in the 16 years as a TLD registry operator, many different forms and modes. This varies from the direct infringement of (IP)rights and cybersquatting, to unauthorized domain transfers, to registering domains with false data, but also registrars simply forgetting to change the contact information of the registrant after relocating to a new address and content issues such as phishing, malware distribution, the spreading of child pornography, et cetera.

What is regarded abuse under .NL, is defined in its general terms and conditions for the registrant. Under .amsterdam there will be no direct contractual relation between the registry operator and the registrant and therefore the description of what is abusive will be something that the registrars need, as will be provided for in the RRA, to put in their contracts with the registrants. 

In general the following will be regarded as abuse:
 - The registrant infringes the technical requirements set for .amsterdam. These technical requirements are based on ICANN’s requirements and the relevant RFC’s;
 - The registrant does not provide correct name and⁄or contact details of himself or the other contacts, or fails to keep these accurate;
 - The registration or the use of the domain name infringes the rights of a third party, or is unlawful or illegal in any other way;
 - A domain name is transferred to another registrar or to another registrant without the authorization of the registrant. 

The abuse and its mitigation referred to in this Evaluation Question is mainly focused on abusive actions from the side of the registrant, but there are all other kind of ‘abuses’ that a registry operator has to deal with. E.g. Abuse of DNS by overloading the name servers with queries, or abuse of the registration system by registrars ‘hammering’ the SRS to obtain domains falling out of redemption grace period. SIDN developed an array of procedures, technical solutions, rules and regulations to prevent these types of abuse and mitigate possible detriment. These types of abuse and mechanisms to control risks are discussed in the answers to other Evaluation Questions, such as #30 ‘Security Policy’. In the answer to this Evaluation Question, we now however focus on the registrant’s abuse as defined above.

28.1 Single abuse point of contact & handling of notices of abuse
The central registry operator’s website for .amsterdam will, on the homepage, have a clearly visible ‘report abuse’ sign where every visitor of the site may find contact details (e-mail, telephone, postal address) that may be used to report abuse. As specified in Specification 6 to the Registry Base Agreement, these details will also be provided to ICANN in the form in which ICANN would like to receive them. These contact details will all lead to the support desk of SIDN which will also make sure that upon any changes to these details ICANN will be promptly notified and the information on the registry operator’s website will be updated.

The SIDN support desk currently consists of a team of 14 highly skilled, well trained and experienced staff who handle all support questions (including abuse) and calls for the .NL TLD and the 1.3.e164.arpa ENUM delegation, also operated by SIDN. Together they serve about 1,800 registrars and about 2,7 million unique registrants. All support is provided in Dutch as well as in English.

The SIDN support desk is located at SIDN’s main office location in Arnhem and is organized in a first (9 staff) and second line (4 staff), with a dedicated manager who is a member of SIDN’s Management Team. The staff has a diverse background including experience on technical, policy and legal aspects in its ranks. The SIDN support desk has direct access to all the other specialists of SIDN who may act as a third line of support.
The primary focus of the SIDN support desk is on registrars. SIDN services around 1800 registrars for .NL, accounting for around 65% of all the incoming calls (e-mail and telephone). The SIDN support desk also has extensive experience assisting and handling abuse notices and complaints from registrants and third parties. The mission of the SIDN support desk is to help everyone as good and as fast as possible by listening to the issues and where necessary clarifying the question or complaint, providing answers, solving issues whenever possible, providing information, explanations or clarifications on policies, rules and regulations and⁄or redirecting the person involved to a more adequate internal or external source that might be able to resolve the issue. SIDN also has a legal counsel employed who is experienced in domain name law and policy matters and may support .amsterdam where necessary and act as a liaison to ICANN.

The primary support channels for the SIDN support desk are e-mail and telephone. Post and fax are mostly used for administrative purposes but are also available for contacting the support desk. The SIDN support desk is directly reachable during SIDN office hours (Monday-Friday 08:00 – 18:00 Netherlands time, which is UTC+1). During these hours telephone calls are answered directly. When more incoming calls occur than employees are available to answer them, the calls are placed in a queue. The current planning is very adequate: telephone queues are a rare occasion and last only one minute at the maximum. The incoming e-mail calls are also queued. E-mails receive a receipt-notification with a ticket number for references immediately and are answered in maximum 2 days. The queue however is monitored constantly for urgent messages which will of course be given the necessary priority. The SIDN support desk is further reachable 24⁄7 for registrars through a voicemail system for reporting technical disturbances and critical problems. Reports of critical problems outside office hours are responded to within 30 minutes.

The SIDN support desk works with a CRM-system to log in detail all calls and responses. This system can provide extensive differentiated reports (e.g. source, channel or type). 

All calls received via whatever media including all abuse notices are screened for urgency during working hours and handled accordingly.

The desk further utilizes clear and extensive work instructions that provide baseline texts that may be used depending on the specific situation and assist the staff in handling the more or less regular or frequently asked questions. These work instructions are drafted by the staff of the desk in conjunction with the necessary technical, procedural and legal specialists. The work instructions are constantly being reviewed to keep them up to date. Amongst others, specific work instructions are available for handling notices of incorrect WHOIS information and the ‘Notice-And-Take-Down’ procedure (see ’28.3.1 Incorrect WHOIS details’ and ’28.3.4 Unlawful or criminal use of a domain name’ below). The work instructions are available in Dutch and can be provided if requested. 

SIDN participates in various partnerships that deal with IT security, like for example the Dutch National Cyber Security Centre (NCSC). This enables us to quickly engage into a nationwide coordination with the NCSC and Dutch ISP’s in case of security incidents. It also provides us with a network for sharing information regarding malicious or abusive behaviour with industry partners and eventually engage in a rapid takedown or suspension of a domain name through what’s called a ‘Notice-And-Take-Down’ agreement. SIDN has a Security Officer (CSO) and a Computer Security Incident Response Team (CSIRT; formed in 2004) with experts from various disciplines within the organization. This team acts as a ‘quick reaction force’ in case of a security incident related to the registry- and DNS functions of SIDN. (See the answers provided to Evaluation Question #30 ‘Security Policy’ for more detailed information.)

On a non-formalized basis SIDN, being the ‘de facto’ national Dutch registry, has many direct and warm contacts with Law Enforcement, Government and members of the technical community on different levels. In the case of extreme urgent matters SIDN may and will be reached 24⁄7 and is fully capable to take any action necessary.

28.2 Mitigating abuse in general

Mitigating abuse will be done by a series of different measures:

.amsterdam will first of all, as described above, have a central abuse contact published and available and an professional experienced support department ready to handle any abuse notices.

.amsterdam will further mitigate abuse by taking technical measures to make sure that certain types of abuses simply cannot occur. For example, the registration system will not allow registration attempts of domains with a length of less than 2 characters or more than 63 (one of the technical requirements) and makes it technically impossible to register names on the excluded names list. Types of abuse that cannot be completely prohibited, will be made less likely through technical controls (e.g. by the obligatory use of the AuthInfo Code for domain name transfers).

.amsterdam will also implement automated signalling systems to inform the registrars of possible abusive behaviour of the registrants, for example via reports from what is called the ‘DNS Crawler’ and an alerting system to registrars for domains that are being used in Phishing. (See ‘3. Infringement of technical requirements’ below).
 
.amsterdam will further mitigate abuse by holding a sunrise before the start of the landrush, provide a Trademark Claims Service, available during the landrush and 60 days after the opening of .amsterdam for registrations, and supporting UDRP and URS. Next to that .amsterdam will implement a variant of the current .NL- ‘Dispute Resolution System for .NL Domain Names’. This resolution procedure (a UDRP variant administered by WIPO) serves as a mechanism for settling disputes that concern trademarks, trading names, the names of governmental and other bodies and personal names. Disputes are settled by impartial legal experts, who are specialists in this field. The Dutch language is supported in this resolution procedure. More detailed information on this and the other rights protection measures mentioned will be provided in the answer to Evaluation Question #29 ‘Rights Protection Mechanisms’.

.amsterdam will next to the forgoing inform and educate the public with regard to possible abuse issues, the availability of remedies and the how and where to obtain these in detail via its website, apart from the clear notice of the abuse contact and how to contact them.

.amsterdam will further pick the fruits of using SIDN as the back end provider as SIDN is in its role as the .NL registry already constantly working on the enhancement of the trust in the .NL-domain environment and in that respect working hard to prevent and mitigate abuse and develop new methods, policies, practices and measures to fight abuse.

28.3 Specific abuse policies

In the above the overall approach towards abuse has been described. Underneath please find a more detailed description of policies and mitigation measures in place. As said a detailed description of the rights protection measures already named in the above is to be found in the answer to Evaluation Question #29. All measures described below will also be made available for the .amsterdam registry.

28.3.1 Incorrect Whois details
.amsterdam will follow in principle the same rules and regulations SIDN does for .NL with regard to registering domains and providing correct registration data. This means that the registrant will have a contractual obligation to present correct information and to keep the information correctly updated during the full registration period. The registrars will further have a contractual obligation to take all reasonable steps to ensure the accuracy of the registered data and the traceability of the registrant or party that commissioned the registration. The registrar shall not register any data that the registrar knows or suspects to be inaccurate and shall, upon independently ascertaining or learning from SIDN or a third party that an item of registered data is inaccurate, immediately replace the data in question with accurate data. If requested to do so by SIDN, the registrar shall provide evidence of the accuracy of the registered data. Under ICANN’s ‘Whois Data Reminder’ Consensus Policy, registrars are obliged to at least annually present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.

.amsterdam will have a procedure available to handle notices of possible incorrect Whois details which will be a version of the current procedure used by SIDN. For .NL SIDN has a detailed script with regard to the actions to be taken upon the receipt of an abuse notification. In general SIDN will contact the registrar and request the registrar to verify the alleged incorrect information and have the registrant provide proof of the correctness of the alleged incorrect information. In general the registrant is provided the opportunity to update incorrect information but will have to provide proof of the correctness of the updated information. The registrant will not be given this chance if the information provided is clearly or purposely incorrect. In that case SIDN will cancel the registration.

SIDN is currently actively investigating the possibilities to implement an active and on-going Whois accuracy check at the registry level. If and when this will be implemented for .NL, .amsterdam will investigate the possibilities to implement this for .amsterdam too. Incorrect information found will then be presented to the sponsoring registrars and proceedings will follow the path described above.

28.3.2 Information requests by law enforcement
Law enforcement agencies may require for example historical registrant data or other registration data. Dutch law provides for a number of different grounds to force a registry to provide such information and SIDN has a clear notice what these grounds are, how these requests have to be provided and how they have to be handled. In practice the General Counsel of SIDN more than once assisted law enforcement in directing them to the correct articles in the law. SIDN of course makes sure that these requests are handled with due care and within the timeframes provided by law. SIDN is currently working on a detailed work instruction so that the correct handling of these requests is clearly described and documented.

28.3.3 Infringement of technical requirements (including orphan glue records)
SIDN requires registrants to obey the rules set out in a ‘technical requirements document’ that defines minimal technical requirements for the registration (and delegation) of .NL-names (in the DNS). The current version of this .nl-document that will be updated for .amsterdam is attached to the answer of this question. 

Most of the technical requirements are enforced by technical controls in the shared registration system. Other requirements are checked once the domain is delegated, by means of an in-house developed tool called the ‘DNS crawler’. This tool produces monthly feedback on the DNS quality of the domain names registered to registrars. It also reports violations of the technical requirements and DNS errors to registrars and to our compliance monitoring team. The specifications to this tool are provided as an attachment (Q28-DNS_Crawler_Specifications’).

The Shared Registry System has controls in place, at several layers, to prevent so called ‘orphaned glue records’ as is mentioned in the SSAC comment on Orphan Glue Records in the Draft Applicant Guidebook (SAC048). The controls preventing orphaned glue records are described below.
When malicious conduct on domain names is verified, the procedure ‘Notice-And-Take-Down’ is started (see ‘4. Unlawful or criminal use of a domain name’ below). This procedure handles the take down of domain names on which malicious conduct finds place. SIDN is also on the NXDomain mailing list to track requests for take down of domain names. Furthermore, SIDN takes part in the Conficker working group.

Detailed information on Orphaned Glue
With respect to orphaned glue, the following controls are in place to mitigate the danger of having orphaned glue:
 - When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name. 
 - If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers.
 - If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file. This approach is in line with policy 3 of SAC048, section 4.3.
Apart from these controls, additional checking of the zone file is in place, including checks on orphaned (and missing) glue records. See the answers provided to Evaluation Question #35 ‘DNS’ for more details.

Registrars will be informed about their registrations with less than the minimum required number of name servers through the monthly reports sent out by the ‘DNS crawler’ (see ‘3. Infringement of technical requirements’ above). 
When a domain name has no linked host objects (registration state is inactive), the registrar will be directly notified and asked to correct this situation.

28.3.4 Unlawful or criminal use of a domain name
SIDN is one of the prime movers behind the Dutch ‘Notice-And-Take-Down’ Code (http:⁄⁄www.samentegencybercrime.nl⁄NTD⁄NTD_English?p=content). Developed in 2008 under the auspices of the former NICC (National Infrastructure against Cybercrime), the Code, a form of voluntary industry self-regulation, describes how Dutch Internet service providers should respond if someone complains that the content of a website is unlawful or criminal. SIDN advocates use of the Code by its registrars and by other ISPs around the world. SIDN has implemented its own variant of the Notice-And-Take-Down Code.
The Notice-And-Take-Down code is provided as an attachment to this answer (‘Q28-NTD’). 

The legal basis for Notice-And-Take-Down is article 21 in SIDN’s general terms and conditions:

21.1. If SIDN is of the opinion that a .nl domain name that has been brought to its attention is being used in an unlawful or criminal manner (for example, to publish unlawful or criminal content on a website), SIDN shall be entitled to immediately remove the .nl domain name temporarily or permanently from the zone file, unilaterally terminate its registration and take any other action that SIDN considers necessary at the time.

21.2. Any party that believes that a .nl domain name is being used in an unlawful or criminal manner may draw the matter to SIDN’s attention by following the Notice and Take Down Procedure published at www.sidn.nl. SIDN shall deal with any such report in the manner described in the said procedure.

21.3. SIDN shall not be liable either towards the registrant or towards any third party for any damages suffered as a result of any act or omission in the implementation of this article.

Being the registry, SIDN’s role in the context of Notice-And-Take-Down (NTD) is limited. It is an ultimate last resource measure available for clear cut cases. The procedure is detailed in the Notice-And-Take-Down Code for .NL domain names. The current .NL version is attached to the answer to this question (‘Q28-NTD_NL’).

Via the NTD procedure anyone can first of all obtain contact details of the registrant in the case of obvious unlawful or criminal use of a domain name. Under .NL this is important as the Whois does not publish the contact details of the registrant. Under .amsterdam this of course isn’t an issue and the procedure will be amended to exclude this part.

Secondly and for .amsterdam more relevant, anyone can request the registry to actually take down a domain name in the case of obvious unlawful or criminal use of that domain name. Take down would in this case mean removing the domain from the published zone file. Ultimately SIDN may decide to end the entire registration of the domain. 

As said it is an ultimate last resort action. The Dutch NTD Code is based on the principle that the person or organization that has most control over the content should be approached first. If that person or organization does not respond or refuses to take down the content, the matter should be taken up with the person or organization with the next most control, and so on. The registry does of course have no control over the content published via the use of the domain and can only render the domain registration inactive, not take the related information off the internet. Take downs on a registry level are therefore (also because of DNS caching issues) usually not very effective. Secondly these take downs are not quite subtle as they do not target any specific illegal or criminal information on a website but completely blocks the use of a domain. Because of all these reasons, it is extremely rare for SIDN to take down domains. On the other hand it is a very strong signal that the .NL-registry implemented the Dutch code. Most notices received so far are redirected to registrars, hosting providers or the registrant and sufficiently solved by these parties.

28.3.5 Phishing feed
Under .NL SIDN has a fully automated phishing feed that provides for a fast signalling of and action against phishing attempts under .NL-domain names. 
SIDN has agreed a deal with Netcraft (http:⁄⁄news.netcraft.com⁄), an internet security authority that for several years has offered a wide range of services aimed at eliminating internet fraud, including phishing. It was Netcraft, for example, who developed the Anti-Phishing Toolbar that many internet users now rely on to check the authenticity of websites. The toolbar provides Netcraft with an enormous volume of data, which they are then able to make available to clients.

Every five minutes or so, SIDN checks Netcraft’s suspect URL database, which is constantly being updated. Every time a .nl URL is added to the database, an e-mail message is automatically sent to the relevant registrar’s administrative contact e-mail address. In other words, the system does not rely on periodic reporting, but on almost immediate individualised e-mail contact. It therefore provides a basis for very rapid intervention.

The e-mail sent to draw a registrar’s attention to the fact that a client is running a website that may be fraudulent will include the following information:
 - Suspected phishing site URL
 - Host: the IP address of the system running the website
 - Country: the country of origin of the IP address
 - Date: the date and time that the suspect site was detected
 - Target: the name of the company that seems to be targeted

As the registrars only receive information that is specifically relevant for them and their customers, these e-mails receive high attention and usually lead to swift actions from the registrar, ending the phishing attempts.

Rights protection mechanisms are a part of abuse prevention mechanisms. As already mentioned in the answer to Evaluation Question #28, abuse prevention and mitigation under .amsterdam will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry, being worldwide the 7th largest TLD with almost 5 million domain registrations. 

SIDN’s support desk will act as the single abuse point for .amsterdam as is described in detail in the answer provided for Evaluation Question #28. SIDN’s support desk with a total number of 14 staff is experienced in working with right protection mechanisms and supporting rights holders, registrars and registrants when they are confronted with right infringement matters and procedures. SIDN provides these services under the registry back end services contract with .amsterdam.

With regard to rights protection .amsterdam will implement all currently by ICANN prescribed measures by holding a sunrise before the start of the landrush, provide a Trademark Claims Service available during the landrush and 60 days after the opening of TLD for registrations, and supporting UDRP and URS. Next to that .amsterdam will implement a variant of the current .NL- ‘Dispute Resolution System for .NL Domain Names’. This resolution procedure (a UDRP variant administered by WIPO) serves as a mechanism for settling disputes that concern trademarks, trading names, the names of governmental and other bodies and personal names. Disputes are settled by impartial legal experts, who are specialists in this field. The Dutch and English language are supported in this resolution procedure.

.amsterdam will evidently adhere to any other or any amended rights protection mechanisms (RPMs) that may be mandated by ICANN. .amsterdam will include all ICANN mandated and independently developed RPMs in the registry registrar agreement. .amsterdam will not mandate any rights holder to use any other trademark information, aggregation, notification or validation service in addition to or instead of the Trademark Clearinghouse. 

.amsterdam will further comply with the dispute resolution mechanisms (PDDRP and RRDRP) and implement and adhere to any remedies ICANN imposes following a determination by a panel under the DRPs and will accept to be bound by such determinations.

In following section, the different measures and the role of the registry operator are described in more detail.

29.1 Sunrise

.amsterdam will hold a sunrise of at least 30 days before the landrush period. In the sunrise period .amsterdam will give holders of a trademark or tradename protected under Dutch law the opportunity to pre-register the corresponding domain name that is an exact match of the trademark⁄tradename. In addition the rights holder will be given an opportunity to pre-register up to 5 ‘typo’s’ of the trademark⁄tradename.

.amsterdam will for the sunrise make use of a reputable sunrise service provider who will assist .amsterdam with the drafting of the actual sunrise policy and also perform the validation of the claimed rights. .amsterdam will further be assisted in the sunrise by its back end provider SIDN which has held a successful sunrise at the time of the introduction of its numerical domains in 2008. 

The sunrise will, as is mandated by ICANN, make use of the services of the yet to be set up Trademark Clearinghouse. During the sunrise period trademark holders in the Clearinghouse will receive a notification if someone is seeking a sunrise registration for a domain name that is an Identical Match (conform the definition in current Trademark Clearinghouse documentation) of a trademark registered in the Trademark Clearinghouse. The .amsterdam Sunrise Policy will have clear sunrise eligibility requirements which will include the minimum as described in the current Trademark Clearinghouse document (11 January 2012) under section 6.2.3. .amsterdam will, for domain names applied for via the sunrise period and based on trademarks registered in the Trademark Clearinghouse, use the data available via the Clearinghouse to verify if the trademark is eligible. The Sunrise Policy will further include a Sunrise Dispute Resolution Policy allowing challenges at the minimum on the basis of the four grounds described in the current Trademark Clearinghouse document (11 January 2012) under section 6.2.4.

29.2 Trademark Claims Service

During the projected landrush period and during the first 60 days after the start of the availability of the shared registry system for general registrations, the .amsterdam will offer a Trademark Claims Service in cooperation with the Trademark Clearinghouse and its registrars according to the then available procedures. During this period all requested registrations will be checked by .amsterdam for Identical Matches (conform the definition in the current Trademark Clearinghouse document) with trademarks registered in the Trademark Clearinghouse. If such a match is detected .amsterdam will send a Trademark Claims Notice in Dutch and English via its sponsoring registrar to the prospective registrant to inform him about the match and make sure that by still registering the name the registrant warrants the reception of the notice, that he has understood it and that, to the best of his knowledge, the registration or use of the domain will not infringe on the specific trademark rights. 

Under the Registry Registrar Agreement the registrar will be obliged to promptly notify the trademark holder via the registrar’s interface with the Trademark Clearinghouse after the registration is effectuated.

29.3 Unified Domain Name Dispute Resolution Policy (UDRP)

.amsterdam supports the UDRP procedure, which is one of the formal consensus policies, and will oblige registrars via the Registry Registrar Agreement to support it and to have the registrants accept the applicability of the UDPR via the Registry Registrant Agreement.

29.4 Uniform Rapid Suspension

The support organization for the .amsterdam, which will be made available through SIDN as the backend service provider, will handle URS notices received from the URS providers in line with the final URS rules. As the current draft URS Rules require the registry to lock the domain within 24 hours after the reception of the notice, the registry will implement a procedure to make sure that these notices are timely signaled, the domains in question are locked via the SRS and the URS Provider receives a Notice of Lock. The registry will then await further notices from the URS Provider and act accordingly by or:
 a. immediately unlocking the domain; or
 b. suspending the domain, redirecting the name servers for the domain to the webpage provided by the URS Provider and publish in the Whois that the domain name will not be able to be transferred, deleted or modified for the life of the registration. 

The registry will do the same if it receives notice of the outcome of an appeal. 

The registry will not renew the registration of a, because of the outcome of a URS procedure suspended, domain name except if it receives a request from the registrar for the domain name to renew the domain for one year upon a request by the successful complainant. Please note that the actual and detailed implementation will depend on the final URS rules.

29.5 Dispute Resolution System for .amsterdam Domain Names

SIDN has implemented in 2008 its own amended version of the UDRP as a successor to its earlier formal arbitration procedure. This UDRP based system is administered by WIPO and serves as a mechanism for settling disputes that concern domain names that, according to the complainant, infringe trademarks, trading names, the names of governmental and other bodies and personal names. The scope is therefore broader than the UDRP. Disputes are settled by impartial legal experts, who are specialists in this field. The Dutch and English language are supported in this resolution procedure.

The only available remedy under the current regulations is a change of registrant, whereby the complainant becomes the registrant instead of the respondent.

The grounds for a successful complaint are stated in article 2 of the regulations of the ‘Dispute Resolution System for .NL Domain Names’:

2.1. Complaints may be submitted by any party which asserts and establishes that:
 a. a domain name is identical or confusingly similar to:
 I. a trademark, or trade name, protected under Dutch law in which the complainant has rights; or
 II. a personal name registered in the General Municipal Register (‘gemeentelijke basisadministratie’) of a municipality in the Netherlands, or the name of a Dutch public legal entity or the name of an association or foundation registered in the Netherlands under which the complainant undertakes public activities on a permanent basis; and
 b. the registrant has no rights to or legitimate interests in the domain name; and
 c. the domain name has been registered or is being used in bad faith.
The procedure does only offer a decision by a single panelist and there is no appeal. SIDN locks the domain name during the procedure and if the complainant wins the procedure, SIDN will accept a requested transfer of a domain name from the registrant to the complainant. SIDN will however wait for a period of 10 days to give the losing registrant the opportunity to commence a court case in The Netherlands against the complainant in relation to the registration of the domain name at issue. In the latter case SIDN will not cooperate with a transfer request and await the outcome of the court case. 

Administration costs and panelist fees currently are € 1,500 for 1 – 5 names and € 2,000 for 6 – 10 domain names and will have to be paid by the complainant. WIPO handles around 80 cases per year under this .nl procedure.

The current version of the regulation is attached to this answer (‘Q29-DRP_NL’). .amsterdam aims to have a similar procedure available for rights holders as the UDRP only protects trademark holders and .amsterdam feels it very important to also provide an extra protection mechanism for other rights holders, such as governmental organizations, holders of trade names that do not have a trademark (local SME’s) and (famous) persons. The current .nl procedure will therefore be amended by .amsterdam in close consultation with SIDN and WIPO. One of the elements to be discussed is the relation and possible conjunction with the UDRP.

29.6 Domjur.nl

SIDN publishes since 2001 legal rulings and articles about court and ADR cases involving domain names in The Netherlands (many on the basis of rights infringement claims) on the website http:⁄⁄www.domjur.nl. The information on this site (in Dutch only) gives a nearly complete overview of all domain name related cases in the Netherlands since the upcoming of the internet and is aimed primarily at lawyers, but there is also information that may be of interest to ‘lay’ visitors.

Summaries of all relevant rulings are provided on the website. Rulings with particular legal significance are also annotated by leading internet lawyers. The DomJur website is maintained jointly by SIDN and the Tilburg Institute for Law, Technology, and Society (TILT) of Tilburg University.

DomJur will of course also publish any domain name cases that might arise under .amsterdam and will be a good source for (lawyers of) rights holders to learn about the whereabouts of domain name disputes. 

The back-end registry operator for .amsterdam is SIDN, the .NL-registry. All operations for .amsterdam will be conducted by the same standards and procedures that SIDN has in place for .NL. The security policy for .amsterdam will be the same as SIDNʹs security policy for .NL.
SIDN is very proud that .NL, being one of the largest ccTLD’s with almost 5 million registrations, is one of the safest domains according to these independent reports by Norton and McAfee:
Norton Cybercrime Report (2011) - http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄
McAfee Mapping the Mal Web (2010) - http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf 

SIDN is an ISO 27001 certified organization. (See attachment ’Q30-ISO27001_SIDN.) Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle.

Almost all this documentation is written in Dutch. We have summarized and translated the relevant information from this extended documentation regarding our security policy. Full information is available in Dutch and can be provided if needed.

More detailed information on these topics is provided in the answer to part b of this Evaluation Question.

1. Security Management

Information security is defined as the process of assessing the required reliability of information systems in terms of availability, integrity and confidentiality, including describing, maintaining and validating a coherent set of related management controls.

SIDN has a pro-active attitude towards information security, aimed at mitigation of consequences and timely recovery of emergencies, and minimizing contingencies. Information security is not regarded as an impediment or cost, but as a way of thinking and working that facilitates SIDN to optimize the role of domain name registry. Attention and efforts regarding information security are taken into account early on in all decision making processes. 

The SIDN Security Policy is carried out and fulfilled by all SIDN employees. The CEO of SIDN is overall responsible for security and has assigned a dedicated security officer to handle all security issues for the SIDN.
Segregation of functions is used as a preventive measure to avoid risks of abuse through separating tasks, authorisations and responsibilities. 

SIDN approaches security management on three levels: strategic, tactical and operational. On each level, a dedicated security team is responsible for security management. 

SIDN actively participates in several international security-related organisations, including:
 - DNS Changer Working Group (http:⁄⁄www.dcwg.org⁄)
 - The Dutch National Cyber Security Centre (NCSC https:⁄⁄www.ncsc.nl⁄english)
 - Dutch Knowledge Centre for Information Security (Dutch only: PVIB - http:⁄⁄pvib.nl⁄) 
 - CENTR Security Working Group (http:⁄⁄centr.org⁄)
 - DNS OPSEC-Trust (https:⁄⁄ops-trust.net⁄)
 - SATIN (Securing and Trusting Internet Names - http:⁄⁄conferences.npl.co.uk⁄satin⁄)
 - DNS⁄OARC (https:⁄⁄www.dns-oarc.net⁄)
 - OpenDNSSEC (http:⁄⁄www.opendnssec.org⁄) 
 - Conficker Working Group (http:⁄⁄www.confickerworkinggroup.org⁄)

2. Audits and Performance Measurement

SIDN maintains a ‘performance-measurement’ program in order to demonstrate the effectiveness of the ISMS and the controls in place. This program consists of auditing, periodic assessments and measurement of Key Performance Indicators.
Apart from audits, SIDN performs internal monitoring on a structural basis to measure Key Performance Indicators. Key Performance Indicators (KPI’s) are variables used for analysing the effectiveness of the implemented security controls. 

Audits are performed on both processes and infrastructure. SIDN performs 4 types of audits:
 - Financial process audit. This audit results in annual accounts that are approved by a certified public accountant. 
 - Functional audit on system administration processes.
 - Technical audit and penetration tests.
 - Checks on Key⁄Quality Performance Indicators.

3. Information Classification 

The goal of Information Classification is to provide consistent and structured management of documentation regarding traceability, reproducibility and quality. 

Document management describes the document process flow from initiation to management approval, the form and content of documents and the management documents.
The SIDN Information Classification policy divides SIDN information into 4 categories: Public, Internal, Confidential and Secret. It prescribes when to use these classifications, how to transport it and who may see information.

4. Access management 
4.1 Logical Access Management
The general policy for providing access to SIDN’s infrastructure prescribes that:
 - Only SIDN authorized equipment is permitted access to SIDN’s ICT infrastructure.
 - Authorizations and access rights for a specific system are based on the classification of information (Public, Internal, Confidential, Secret) present in that system.
 - All users are registered.
 - Access and rights are granted on a need-to-know basis.
 - Accounts and passwords are strictly personal and not to be shared. Role- or group-accounts should be avoided whenever possible. Users are not allowed to use someone else’s account or password.
 - The user of an account is responsible for using the account and password.
 - Account information and password must be communicated to the account user separately. 
 - Passwords must be stored securely and must not be communicated to third parties.
 - Usage of accounts (specifically logons) will be logged and monitored at all ICT systems.
 - An account name must not reveal any information about its authorization and access rights. An exception is made for default accounts on generic operating systems.
 - Special privileges or the usage of accounts with special privileges must be granted formally by the system or application owner or responsible manager and with a temporal validity. Usage of (accounts with) special privileges should be restricted as much as possible.
 - Access rights and authorizations must be assessed and (re-)evaluated at least twice a year.
 
The usage of accounts and passwords is the most common way to gain access to ICT systems. SIDN maintains a password guideline for safe usage of passwords. For information systems which contain a classified higher level of information (e.g. Confidential or Secret), additional forms of authentication are in use, such as IP-whitelisting, certificates and chip cards. 

System access to all registry systems and network equipment is restricted to employees in specific functions and related roles and is subject to tighter security. 

4.2 Physical Access Management
Physical Access Management describes the policies and procedures for access to SIDN’s office location and specific area’s and rooms therein and SIDN’s production locations where the infrastructure providing registry services resides.

SIDN locations are only accessible for authorized persons with RFID-tagged access cards that need to be worn visibly. Access cards are strictly personal and only one card per person can be in use. Access to SIDN locations is specific to areas and rooms. Access to server-areas, archive rooms and storage rooms is limited to authorized persons.
 - Access for SIDN employees is based on a personal access card (combined with biometric authentication) linked to specific authorizations. Temporary staff will have access cards with limited validity that need to be renewed periodically.
 - Access for employees of suppliers and partners is based on a personal access card combined with biometrics (2 factor authentication) linked to specific authorizations;
 - Visitors need to report to reception and will be provided a distinguishable visitor access card with limited authorizations. Visitors are accompanied by an SIDN employee at all time during access to the location. This employee is responsible for the visitor during the whole access period. Visitors’ access cards have a standard validity of one day.

Access to SIDN’s production locations is limited to SIDN personnel in specific functions and related roles.

5. System Security
5.1 Systems and networks
SIDN establishes a baseline including security elements for all information systems (see ‘Risk Management’ below). From a security perspective, these minimal requirements are set for the baseline:
 - All systems have the most recent (security) patches installed;
 - Systems are maintained via encrypted connections only;
 - All non-required software and features are deactivated or removed;
 - System accounts are strictly personal;
 - All system accounts comply with SIDN’s password policy;
 - Usage of the root account is limited to necessary situations only;
 - All systems are monitored and backups are made periodically;
 - System logging is monitored;
 - System logging is archived. Archives are maintained on a separate system;
 - All core systems are located at one of SIDN’s two production locations. All other systems are preferably located at one of SIDN’s two production locations;
 - System administration and maintenance sessions are terminated after a specified duration of inactivity;
 - All HTTPS-web interfaces are based on qualified and valid certificates;
 - All passwords are stored encrypted;
 - Systems are behind firewalls, unless specified otherwise;
 - Configuration of firewalls is based strictly on a ‘closed-unless’-principle.

5.2 DNS
To ensure the correctness of updates between the registry systems and the pool of available DNS servers the following mechanisms are in place:
 - DNS zone file is generated using the registry database;
 - Zone file is checked for missing glue records and if ok, transferred to the DNSSEC signer machines;
 - On the signer machines, the zone file is DNSSEC signed;
 - Next to that validity checks are in place to ensure the correctness and completeness of the zone file;
 - If still ok, the zone file if transferred to the pool of master DNS servers;
 - The master DNS servers send notify messages to all slaves telling an update is available;
 - The slaves contact the master servers to retrieve the updates.

The communication between master and slave name servers is TSIG protected. This means that all data is exchanged in a secure way. Next to that a firewall cluster only allows access to the master DNS servers when traffic is coming from a slave IP address (ether IPv4 or IPv6).

Orphaned Glue
With respect to the orphaned glue, apart from the zone file checks, the following measures are in place to mitigate to danger of having orphaned glue.
When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name. If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers. If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file.

DNS Abuse
Abuse prevention and mitigation is part of the security policies regarding DNS. SIDN’s DNS servers are intended to enable people to find .amsterdam domains in the context of normal Internet use. However, it sometimes comes to SIDN’s attention that the servers are being used for other purposes. Such abuse puts unwanted pressure on system capacity and, in extreme circumstances, could prevent the servers from being used for their proper purpose. This could constitute a denial of service (DoS) attack and compromise the working of the Internet.

Abuse in this context is defined as any form of DNS server usage that isn’t part of normal Internet use. SIDN always regards the following as abuse: A single party’s prolonged or repeated generation of traffic whose volume exceeds the total volume of all normal Internet traffic.
SIDN has policies prescribing specific actions for handling DNS abuse upon detection.

5.3 Back-Up
Availability of information is critical to SIDN’s business processes. Depending on the type of information, data is duplicated and stored. Stored data and backups are made periodically. All information has a dedicated ‘owner’ who is responsible for backup schemes.
Backups are stored physically and geographically separated from the operational information systems. The information systems themselves are located at two geographically separated locations. Backups are stored at a certified supplier of data-backup storage.

5.4 Logging and Monitoring
All core systems are logged and logging is stored and processed through a Log Management System. Stored logging is kept for a minimum of 1.5 years and contains Syslog and system values (e.g. interface throughput, use of memory, processor usage).
The Log Management System also checks logs for at least:
 - Errors;
 - Failed logins;
 - Suspected user logins;
 - Successful Backups;
 - Network changes, configuration backups;
 - Loss of redundant network interfaces;
 - Performance of firewalls;
 - Types of Spam.

All core systems and applications are monitored. Monitoring is done by comparing pre-defined baseline values and thresholds to actual values and parameters. By crossing of a threshold, alerts are generated. These alerts generate notifications to multiple dedicated SIDN employees. If an alert relates to an incident, an incident ticket is created. 

5.5 External Network Connections 
External interfaces are interfaces that have access to SIDN’s infrastructure from a third party network or environment. Authorisation to connect to SIDN’s infrastructure can only be obtained after signing of a Non-Disclosure Agreement by the third party and signing the policy for connecting external interfaces. Risks involved in maintaining these interfaces are managed through a policy.

5.6 Software Development 
The Shared Registry System is an in-house developed system and many of our other registration services systems and connections between systems rely on proprietary software. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see section 6 below).

SIDN maintains a full DTAP (Development, Test, Acceptance, Production) street for development. With separated systems supporting each phase.

Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q30-Tuvit’).

Development at SIDN is based on ‘test driven development’. This requires starting with a unit test before developing new functionality. SIDN requires that 80% of all written code is covered by unit testing. Next to the Development Team, SIDN has a dedicated Test Team. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing.

6. Processes

SIDN’s ICT department has several security-related management processes based on ITIL and employees are required to apply them in the following ICT management processes:
 - Security Incident Management
 - Change Management
 - Problem Management
 - Configuration Management
 - Release Management
 - Capacity Management
 - Vulnerability Management
 - Patch Management

7. Risk Management

The Risk Management Process is an integral part of the ISO27001 methodology and covers a systematic and periodic approach to all activities aimed at:
 - Identification and quantification of possible risks;
 - Establishment and implementation of mitigating measures to both reduce the chance of occurrence and limit consequences of risks. 

As part of a yearly cycle within the Risk Management Process, all primary business processes are reviewed and scored for business impact. Every process and information system is qualified as ‘normal’, ‘relevant’ or ‘critical’ on three aspects (availability, integrity and confidentiality). 

SIDN works with a risk matrix that relates inventoried risks to baseline measures from the ISO 27001 standard and to additional measures taken through the risk management process. The full matrix is quite elaborate and written in Dutch. An excerpt with the most relevant threats and assessments is translated in English. Both documents are provided as an attachment to 30b.
 
8. Business Continuity Management
Business Continuity Management (BCM) is the process that structurally approaches detrimental internal and external influences and threats to business processes and mitigates them to an acceptable level. SIDN distinguishes between a regular and an emergency BCM process. 
The regular BCM process covers the process of description, operation, monitoring and reviewing during regular operations. The emergency BCM process covers the process of identification of a disaster, recovering from it and coming back to normal operation as soon as possible. 

The scope of the BCM processes are focused on critical business processes. BCM ensures maximum availability of the core business services. The CEO of SIDN has overall responsibility for the whole organisation and thus for Business Continuity Management.

SIDN’s infrastructure is redundantly spread out over several locations, with geographically separated locations for infrastructure supporting registry services, DNS services and system management.

SIDN has contingency plans to facilitate relocation of both infrastructure and staff in case of emergency. All systems providing registry services are hosted at two production locations that are both operational and both contain accurate data and available services. DNS services are supported by a widely distributed system, consisting of several unicast name server clusters and three anycast networks, all hosted at certified data centres. SIDN’s office location contains no systems supporting registry functions. Infrastructure relocation is tested periodically and showed a recovery time of all registry services in less than 10 minutes during the last test, with no outage for DNS services.
In case SIDN’s office location is lost (e.g. through fire or flooding), a backup site is available. This backup site also provides facilities for a partial relocation (e.g. if primary communication channels are lost). Relocation to the backup site is tested annually. These tests show that in case of a relocation, full office functionality is restored within 4 hours.