Application number: 1-1867-3276 for DNS.be vzw

DNS.be vzw

Ubicenter, Philipssite 5
Leuven 3001
BE

+32 16 284970

+32 16 284971

http:⁄⁄www.dns.be

Mr. Philip Du Bois

General Manager

+32 497 514031

+32 16 284971

philip.dubois@dns.be

Mr. Peter Vergote

Legal & Admin. Manager

+32 474 790096

+32 16 284971

peter.vergote@dns.be

not-profit institution

Act of 2 May 2002 concerning national and international not for profit associations and foundations. Published in the National Stateʹs Journal of 11 December 2002.

Not Available

Christian Vanhuffel
Director
Danielle Jacobs
Director
Piet Spiessens
Chairman

David Goelen
Operations Manager
Lut Goedhuys
Marketing & Comms. Manager
Maarten Bosteels
Development Manager
Peter Vergote
Legal & Admin. Manager
Philip Du Bois
General Manager

brussels

Not Available

To the Applicant’s knowledge, there are no operational or rendering problems concerning the applied-for gTLD string. It is not an IDN string but in strict ASCII format (.brussels) and very similar to already existing gTLD’s like .asia. Applicant doesn’t seek to apply for neither wants to reserve this gTLD string in other scripts such as Greek or Cyrillic. 

Response to Question 18a - Mission⁄Purpose

Applicant is introducing the application for the .brussels gTLD with the support of the Government of the Brussels Region. 

Applicant (DNS.be vzw) is the registry operator for .be, the country code TLD for Belgium. Belgium is a federal state that consists of a federal governmental level (representing the country) and several regional governmental levels (representing the different regions Flanders (Vlaanderen), Brussels (Brussel⁄Bruxelles) and Wallonia (Wallonie)) and each having distinct competences. Both the federal level and the regional levels have their own Governments and Parliaments, responsible for policy making and execution. The federal level is competent for matters such as defense, justice, foreign policy, interior⁄home affairs and social security while the regional levels have authority for matters such as economic affairs, foreign trade, energy, housing, education, employment, environment, social welfare, transport, culture and sport. 

The Government of the Brussels Region, representing in this perspective both the Brussels Region as the city of Brussels, decided to participate in the new gTLD application program with the aim of having the gTLD .brussels attributed to the Applicant. The Government of the Brussels Region published an official request for proposals (RFP) on 7 March 2012 in the Official Journal of the European Union in order to award a service concession contract to a private partner. The private partner would be responsible for applying for the gTLD .brussels through ICANN’s new gTLD program and – if attributed by ICANN – for managing the gTLD as its registry operator for a period of 10 years. DNS.be vzw responded to the RFP by submitting a proposal and was subsequently selected by the Government of the Brussels Region and awarded the service concession contract on 22 March 2012.

According to the Applicant, the purpose of the TLD is manifold, as will be further explained below:

i. enable inhabitants, companies, organizations and local government institutions the usage of specific domain names that are closely linked with the geographical region and city in which they are residing;
ii. enhance the digital presence of the Brussels Region and the city of Brussels;
iii. strengthen the visibility of Brussels as a region and as a brand name and enhance city marketing possibilities for Brussels as capital city of Belgium⁄Europe;
iv. allow interested parties from within and outside the Brussels Region to make use of the new gTLD in order to reach potential customers of the region with their offer for services or goods;
v. having a gTLD, matching its geographical name, at its disposal will allow the Brussels Region and the city of Brussels to further develop their identity both on-line as off-line. 

Response to Question 18b - Mission⁄Purpose

According to the Applicant, the proposed gTLD has clear goals, offering more choice and enhanced competition, resulting in a number of benefits for registrants and Internet users. At the same time, a clear and open registration policy has to guarantee a fair, broad and non-discriminatory access to the new gTLD in full conformity with national and supra-national rules and regulations. The new gTLD will be operated on a strictly not-for-profit basis thus allowing the community to take full advantage of its existence. This will lead to fair prices for domain name registrations and renewals and re-investment of resources of the registry in further enhancement (technical, operational, marketing) of the proposed gTLD. 

i. The goal of the .brussels gTLD is to provide users and registrants (both private persons and businesses) with the possibility to choose for a domain name registration with an obvious link to and entirely matching with the geographical region of Brussels and the territory of the capital city of Brussels. 

ii. From the Applicant’s perspective, .brussels will bring a high degree of recognition and specialization to the currently existing name space. Where in most cases the specific connotation that has been initially given to the gTLDs (or even ccTLDs) has disappeared, the .brussels top-level domain will be unambiguously linked to the region and capital city of Brussels and will provide a unique online identifier for local governments, businesses and private persons from within that area. Alternatively, it will also provide the resources for businesses and private persons from outside the region of Brussels but with a clear link to the region and city (e.g. expatriates) to get in touch with the local community. As many domain names are already registered in the national .be top-level domain the new .brussels TLD will provide many users with a new chance to register those domain names that are linked to their interests or business. 

iii. As mentioned in the vision ⁄ mission statement before, some of the key reasons why Applicant is applying for .brussels are:

1. Direct link between proposed TLD and the region and city of Brussels, enabling its inhabitants, businesses and government entities to apply for a domain name with local character; 

2. Enhance digital presence of the Brussels Region and capital city of Brussels and strengthen their visibility and identity;

3. Assurance for users and registrants that TLD will be operated in their best interest given the not-for-profit model and the fact that the national ccTLD operator will be the registry operator for .brussels;

iv. The Applicant intends to implement the following policies and procedures with respect to the registration of domain names in the .brussels top-level domain including but not limited to:

1. Reservation and exclusion of domain names. These names include:
a) descriptive names, referring to the actual day-to-day business activities of the Applicant;
b) geographical names, referring to the government entities and public authorities within the Brussels Region and capital city;
c) domain names considered illegal, harmful or not suited for public usage can be put on an exclusion list and will not be available for registration;

2. Launch of the TLD:
a) Sunrise: allow government entities, physical persons, organizations and companies that meet the eligibility requirements in force at that point in time to choose the domain names that are identical to their rights (trademarks, trade names, geographical names, etc.);
b) General availability: other available domain names may be registered by physical persons, organizations and entities that meet the eligibility requirements in force at that point in time to choose the domain names in accordance with the applicable terms and conditions. 

3. Security measures regarding quality of whois data:
a) Screening of whois data of newly registered domain names: upon registration all whois data linked to new domain names will be examined on obviously false, fraudulent or missing information in order to discourage fraudulent or suspicious registrations;
b) Screening of whois data of registrations made by non-Belgian users: upon registration all whois data linked to new domain names of users from outside Belgium will be examined in order to verify the accuracy of the provided contact information;
c) If the examination under a) or b) reveals fraudulent or inaccurate information that obstructs the identification of the domain name holder, Applicant will initiate a breach procedure allowing the registrant to complement and correct his contact information where needed within a time period of 14 days. If registrant fails to correct his contact information, the domain name will be deleted by Applicant. 

v. Given the fact that the Applicant is an organization that is established in Belgium, it is subject to both national and European privacy and data protection rules and practices. Applicant intends to provide users and registrants of .brussels the same level of protection that is also in place for users and registrants of .be domain names. In that perspective a distinction will be made between corporate registrations (registrations for companies, organizations, government agencies and other legal persons) and private registrations (registrations for private individuals). While full whois disclosure is intended for corporate registrations, private registrants will be allowed to opt out for full whois disclosure of the personal data linked to their domain name registrations. Nevertheless, all registrants will have the full obligation to provide (during registration of the domain name) and maintain (as long as they remain registrant of the domain name) full and accurate whois data. This is necessary in order to allow Applicant to disclose the contact data of the registrant in situations where the applicable data protection rules allow such a disclosure e.g. when a third party wants to start a litigation against the registrant for alleged breach of specific rights the third party could have in relation to the domain name registered by the registrant. Disclosure of the personal data requires the party seeking such a disclosure to follow a specific procedure and file a motivated request with Applicant. After legal examination and verification of the motivation of the requestor, personal data may be communicated to requestor by Applicant. The obligation to provide and maintain accurate whois data in combination with the enhanced protection for private registrants is specifically aimed at preventing practices whereby registrants deliberately provide inaccurate or fake personal data at the time of registration. Such occurrences would jeopardize the overall quality and reliability of the databases managed and operated by Applicant and might have a negative influence on how the .brussels TLD would be perceived by users.

The Applicant intends to achieve the above listed benefits by reaching out and communicate in the following ways:

-The Government of the Brussels Region and the Applicant will establish working groups and committees to determine the details of the registration policy, the rules for sunrise phases and applications, possible exclusion of domain names (exclusion list), protection of rights mechanisms such as alternative dispute resolution (ADR), pre-sunrise reservation possibilities for governments. All policies agreed upon will be communicated in a broad way in order to assist registrars and registrants and help them prepare their applications and registration requests. As the Applicant is the registry operator for the .be ccTLD, it already has a solid reputation and will not have to face difficulties in getting widespread attention for the communication of policy details for the new gTLD;

-The Applicant is under contract by the Government of the Brussels Region to operate the new gTLD on a pure not-for-profit model and Applicant is in itself a not-for-profit entity. This means that the growing number of new registrations and renewals will create additional income over time while costs stay more or less at the same level. This will allow Applicant to lower the set fee levels for new registrations and renewals. By lowering the fee levels, access to the new gTLD will be further widened, providing also very small businesses and individual users opportunity to register domain names;

-The Government of the Brussels Region has a very clear determination to use the new gTLD as the primary TLD for all its administrations, agencies, ministries, etc. This means that those entities will gradually migrate from the .be domain names towards the .brussels equivalents. The Government of the Brussels Region will of course make usage of .brussels in all publications and statements, both internally as addressed to the public at large. This will assist in making the new gTLD visible and tangible for registrants and Internet users;

-The Government of the Brussels Region has worked in close cooperation with the organization VisitBrussels, a not-for-profit entity especially established for the marketing and communication for the Brussels Region. VisitBrussels is the official communication agency of the Tourist Information Services of the Brussels Region and is in charge for the promotion of Brussels as a region and city and to introduce its culture and touristic value to visitors. VisitBrussels is in charge of every aspect hereof including communication and organization of large events. VisitBrussels will adopt a new marketing⁄communication plan end 2012 or by mid 2013 at the very latest and intends to make the .brussels gTLD its focal point of the global plan. The .brussels gTLD will be massively present in all marketing and communication of the Brussels Region and city. 

Response to Question 18c - Mission⁄Purpose

i. The Applicant will organize the registry operation for .brussels in such a manner that it will minimize the likelihood of having disputes about multiple applications for a particular domain name. This can be achieved in the following ways:

1. Prior to the launch of the Sunrise Period for the .brussels top-level domain, the Government of the Brussels Region and the Applicant will decide whether or not to work with exclusion- and⁄or reservation lists. An exclusion list would enumerate all .brussels domain names that are blocked from registration and will not become available (not during the Sunrise Period and not after the start of the normal registration process). This list could contain words, expressions or phrases that are considered harmful, illegal or inappropriate in public use. A reservation list could be established for multiple purposes. It could provide opportunity for the Applicant to reserve for itself a number of domain names corresponding to its function as registry operator e.g. nic.brussels or registry.brussels. It could also provide the different government entities the same possibility to reserve for themselves a number of domain names that correspond with the name of their organizations or their geographical descriptions. Important is that the existence of such lists need to be communicated to registrars and public at large well in advance of the start of the Sunrise Period so that it becomes clear that those domain names are unavailable;

2. Prior to the start of normal registrations based upon the “first come, first served” principle, there will be a multi-phased Sunrise Period. During phase 1 holders of national and European established trademarks, governmental entities seeking to protect their geographical or social name and entities disposing of a protected designation of origin or a geographical indication, will be able to apply for the domain name corresponding to the rights they wish to claim. In phase 2 registrants will be able to apply for domain names corresponding with their trade name or company name. Finally, it is also under consideration to provide a 3rd phase during which private individuals would be allowed to apply for the domain name corresponding with their family name. In all phases of the Sunrise Period, applicants will have to substantiate the applied for domain names with legal proof of the rights they wish to claim. The invoked rights will need to match exactly with the domain name for which the application is introduced and all applications will be validated by an independent reviewer that will perform that function under contract awarded by the Applicant. Sunrise applications will receive a time stamp and will be validated in chronological order as far as the applicant manages to accompany his application with the required legal proof for the right he wishes to invoke;

3. At the start of the normal registration process, subject to the actual domain name registration policy adopted by the Applicant and in force at the time of registration, domain names will be allocated on a first-come, first-served basis. As registry operator for .be and as operational, technical partner during the start-up of the .eu TLD, Applicant has acquired the necessary experience to cope with high volume demands for registration of domain names and will deploy adequate technical resources for the start of the so called Landrush phase avoiding to the maximum extent possible any loss of time, elevated costs or high degrees of frustration for individual or business users wishing to register a .brussels domain name. 

4. It is to be noted that Applicant does not seek to introduce procedures or methods enabling reservation of domain names or so called waiting-list services. Applicant has considerable experience with Sunrise and Landrush procedures (both for .be and for .eu) and has noticed that service offers enabling applicant-registrants to make a reservation for a specific domain name often involve high costs without any guarantee that the desired domain name can be obtained during the sunrise period or afterwards at the start of normal registrations. 

ii. The Applicant is a not-for-profit organization and has committed to the Government of the Brussels Region to operate and manage the .brussels TLD on a not-for-profit basis. This means that revenues coming from new registrations and renewals will be directly linked with the costs of operating the TLD without any aim of generating profit for the Applicant. It is Applicant’s view that fees for new registrations and renewals could decrease considerably when the registration of domain names takes up. 

iii. The Applicant does not intend to provide specific clauses concerning fee levels and possible price mechanisms in the Registration Terms & Conditions for registrants. This would force Applicant to change the Terms & Conditions each time one of the fee levels is altered. Obviously, Applicant will follow all provisions from the registry agreement concerning pricing of its services. As explained above, Applicant anticipates gradual price declinations in function of the number of registrations. Moreover, Applicant has committed through the concession agreement with the Government of the Brussels Region to re-invest a substantial part of the revenue in the further development of the gTLD as soon as the operations of the TLD services are financially break-even. 

No

Not Available

Yes

Response to Question 22 - Protection of Geographic Names

Introduction

Applicant envisages to undertake considerable effort with regard to the protection of geographic names on the second level of the .brussels gTLD. Given that the applied for gTLD is in itself matching with the territory of an important geographic region in Belgium and its capital city, and is supported by the relevant Government of that territory, it would be very problematic to overlook the protection of geographic names within the proposed gTLD and to omit the creation of rules and procedures related to the release and⁄or reservation of such names.

Applicant wants to foresee three distinct levels of protection:
1) Protective measures installed prior to the start of operations;
2) Protection during the multi-phased Sunrise Period;
3) Procedures providing protection after the start of the registrations on “first come, first served” base.

The proposed measures for protection refer to the principles laid down in Specification 5 of the new gTLD Registry Agreement, those described in the GAC’s document “Principles regarding New gTLD’s” and current practices already in place for the .be ccTLD. 

Protective measures installed prior to the start of operations

Applicant wants to deploy a number of protective measures concerning geographic names prior to the start of the Sunrise Period and – in a later phase – the normal registrations on “first come, first served” base. It is the intention to maintain these protective measures even after a number of years will have elapsed since the start of normal registrations in the gTLD. The proposed measures involve the blocking of certain geographic names and strings.
Applicant will exclude certain names from registration and will provide clear and detailed provisions in the Registration Terms & Conditions. Specifically with regard to geographic names and references, Applicant wishes to reserve or block all 2-character labels. A large number of possible 2-character labels matches with previously defined ISO 2-character descriptions for country codes. Other possible 2-character labels have no country code counterpart but it is not excluded that new country codes will be attributed by the ISO Maintenance Agency in the future. It is therefore appropriate to extend the level of protection in order to prevent potential conflicts in the future. This can be achieved by reserving or blocking all 2-character labels. In accordance with Specification 5 of the proposed gTLD Registry Agreement, Applicant will only release possible 2-character names to registrants that can demonstrate authorization (or a formal no objection statement) from the relevant Government or ccTLD registry manager that is corresponding with the 2-character label. 

Applicant will also exclude from registration on second level (and - if applicable - on any other level within the TLD that would be under operation of Applicant) the following names:
- Short form country and territory names contained on the ISO 3166-1 list, including the European Union. All names on the version of the ISO 3166-1 list available at the time of establishing the exclusion list, will be integrated. Further names could be added, provided that they have not already been registered before being added to the ISO 3166-1 list;
- Names of countries that appear in the Technical Reference Manual for the Standardization of Geographical Names of the United Nations;
- Names of the United Nations member states in the 6 official UN languages (in as much as this is applicable for .brussels which will not allow registrations in other scripts than Latin).

Applicant does not seek to block those country and territory names on a permanent base. In strict conformity with the provisions of Specification 5 of the new gTLD Registry Agreement, such names could be delegated to anyone who applies for them, provided that agreement is reached with the relevant government or if specific policy procedures would be adopted by ICANN upon review of the GAC.

Protection during the multi-phased Sunrise Period

Applicant envisages a multi-phased Sunrise Period that goes beyond the sole protection of trademark holders. During the first phase of the Sunrise Period local governments and government entities, public authorities and intergovernmental organizations will have the opportunity to apply for domain name registrations that are matching with their names (geographical name or name of organization) or acronyms. 
Alternatively and subject to discussions with the Government of the Brussels Region, Applicant could provide a pre-Sunrise Phase for above mentioned category of right holders in order to avoid any collision with trademark holders wishing to apply for identical domain names during the first phase of the Sunrise Period.

Procedures providing protection after the start of the registrations on “first come, first served” base

Finally, it should be noted that Applicant wants to implement a UDRP mechanism with broad scope and low access. Applicant has put in place an innovative and efficient UDRP system for the .be ccTLD and would like to import its benefits for the new proposed gTLD. Among other things, the UDRP for .be offers governments equal rights to initiate procedures and claim back domain names upon which they can vest certain rights as to holders of trademarks. In that perspective it is noteworthy to mention that the Belgian Federal Government managed to claim back the domain name belgie.be (country name of Belgium in Dutch language). The same possibilities exist for governments of all levels as well as other public authorities with regard to the protection or recovery of domain names matching with their geographic name, name of organization, acronym or other protected right under the rules for the .be alternative dispute resolution procedures. 

Response to Question 23 (Registry Services)

The applicant, DNS.be (being the ʺRegistry Operatorʺ) will outsource the
technical operations of the Registry to ʺTLD-Box Registrydienstleistungen GmbHʺ,
and a signed contract for the provision of those services with TLD-Box
(hereinafter referred to as the ʺBack-End Registry Operatorʺ) exists. A more
detailed description of that outsourcing relation is described in response to
question 31.

The Registry operating the proposed gTLD will provide the following Registry 
Services (Services are numbered according to the Questions and Notes in ICANNʹs
application guidebook):

* (A), (i): ʺReceipt of data from registrars concerning registration of domain
 names and name serversʺ: The interface for receipt of such data (Shared
 Registry Service - SRS) is fully based on the Extensible Provisioning Protocol
 (EPP) and conforms to the relevant RFCs (see answer to Question 25). Beyond
 the standard EPP object mappings and commands, no proprietary EPP extensions
 are used (unless ICANN requirements necessitate the use of draft level
 specifications, i.e. for the Trademark Clearing House integration). This
 Registry Service is operated on a cluster of at least two physically
 independent servers as an active-active load-balanced group which interact
 with a clustered registry database backend (detailed in response to Question
 33). Access to that interface is controlled by two-factor authentication
 mechanisms with one factor being the IP address of the registrarʹs EPP client
 and the second factor being the registrarʹs credentials (username⁄password).
 Traffic is encrypted with TLS. Access attempts from IP addresses that are not
 registered with the Registry Operator are denied. A detailed specification of
 the EPP interface is contained in answer to Question 25, while the
 architecture of the EPP frontend is included in response to Question 32. The
 software used to provide the EPP service is readily available at the time of
 this writing. The software is based on the EPP software used to provide
 Registry services for the ʺ.atʺ, ʺ.noʺ, and ʺ.bhʺ ccTLDs with the domain
 lifecycle and periods adapted to the requirements for new gTLDs. The EPP
 service is available over both IPv4 and IPv6 transport.

* (ii): ʺProvision to registrars of status information relating to the zone
 servers for the TLDʺ: The registry operator will operate an announcement
 mailing list where updates regarding the operational status of the zone
 servers of the TLD will be posted. Additionally, registrars can query for the
 zone server status of an individual domain name under the TLD via the EPP or
 WHOIS interfaces - both interfaces will contain the relevant EPP status values
 (refer to the answer to Question 27 Registration Life Cycle which lists the
 domainʹs zone server status depending on the domain status).

* (B), (iii): ʺDissemination of TLD zone filesʺ: Zone generation and the
 subsequent DNSSEC signing of that zone is performed in parallel on two
 physically separate zone generators based on the current data in the registry
 database. After performing offline checks for the integrity of the zone file,
 the TLD zone file is loaded onto two hidden master nameservers (the zone file
 of the second zone generator is only used in case of an emergency situation
 with the first zone generator). These hidden masters supply the public
 nameserver network with the current zone file. For zone dissemination the
 standard DNS mechanisms of NOTIFY and IXFR⁄AXFR, protected by TSIG, are used.
 Integrity checks are performed to detect errors such as incomplete zone
 generation, incorrect DNSSEC key usage, key signing keys not matching DS
 records in the parent zone or an NSEC⁄NSEC3 chain problem.

 The DNS query based verification procedures include the following set of
 checks on the published KSK and ZSK: 
 * Check if the published KSK matches a published DS-Record in the parent
 zone 
 * Check if the signature of the SOA and the Zone-NS-Records are included and
 correct 
 * Query (with DO-bit set) for 20 predefined existing domain names, check the
 results and validate the received signatures
 * Query (with DO-bit set) for 20 predefined non-existing zone names, check
 the results and validate the received signatures
 * Query (with DO-bit set) for 20 new (or changed) domains since the last
 zone generation, check the result and validate the received signatures
 (the zone generator generates a diff-file with the changes made and the
 verification tools choose 20 records randomly)
 * Query (with DO-bit set) for the predefined end-of-zone-record of the zone,
 check the results and validate the received signatures. 

 Only if these checks succeed, the zone file is propagated to the hidden
 masters - otherwise the rollout of this zone file is stopped and operations
 staff is notified. Consistency checks of the loaded zone file is also
 performed on the hidden masters. Zone file access as required by ICANN is also
 provided. These procedures are the result of practical experience and
 knowledge gained from operating the ʺ.atʺ TLD for over 15 years.

* (iv) ʺOperation of the Registry Zone serversʺ: The TLD zone servers will
 consist of a mix of Anycast and Unicast servers, mainly delivered by DNS.be.
 An additional anycast mesh will be foreseen by IPCom (daughter of nic.at) in
 order to ensure high availability in accordance with ICANN SLA requirements
 and to achieve a high level of diversity in terms of software and IP
 connectivity. A stable high-performance DNS network with 100% availability is
 one of the major key components of a successful gTLD operation. As a result
 the DNS network is carefully designed to fulfil those requirements.
 Anycast-DNS with multiple geographic locations is utilized to minimize
 latency, distribute traffic and increase resilience against attacks. Unicast
 servers are used to increase diversity across the DNS network. The zone for
 the gTLD will not contain any wildcards or other means to modify NXDOMAIN
 responses. More details about the DNS network structure is contained in
 response to Question 35.
 
* (C), (v) ʺDissemination of contact and other information concerning domain
 name registrationsʺ (WHOIS service): A port-43 WHOIS (and a lightweight
 alternative) as well as a web-based WHOIS will be provided. In accordance with
 Specification 4 of the Registry Agreement, the WHOIS service is fully
 compliant with RFC 3912, and provides information about domain names,
 registrars and name servers. Free public access to that information is
 granted. Web based access is also supported. The service is based on a
 scalable and redundant architecture to meet the required SLAs. To address
 privacy considerations, rate limiting on a per-IP-address basis is employed on
 the WHOIS interfaces. In addition to the WHOIS service, the Registry will also
 offer a ʺDomain Availability Serviceʺ using the ʺFingerʺ protocol as defined
 in RFC 1288. This service can be used by registrars to check whether a domain
 name is available or not but does not provide any other information. The
 implementation is fully RFC compliant. Since finger is a very simple protocol
 with a minimum of overhead, requests can be processed quickly by the registry
 systems, which saves on computing resources for both the registry and
 registrar. The Finger service is a read-only interface and does not pose any
 security risks for the registry. Instead, providing such an interface (which
 is functionally identical to the IRIS dchk) offloads pure ʺavailabilityʺ
 checks from the more heavyweight WHOIS and EPP interfaces which helps to
 improve the overall performance of those services.

* (D) ʺInternationalized Domain Namesʺ: The registry will offer IDNs as detailed
 in the response to Question 44. IDN support in the proposed registry will
 strictly adhere to all relevant standards. Only labels with explicitly
 permitted code points will be allowed. The registry will be conservative in
 allowing additional code points and will only allow code points that do not
 carry risks such as user confusion or technical issues caused by lack of
 client support etc.

* (E) ʺDNS Security Extensions (DNSSEC)ʺ: The registry will perform zone signing
 activities in accordance with ICANN requirements and industry best practice.
 The respective Delegation Signer (DS) Records will be sent to IANA for
 inclusion in the root zone to establish a chain of Trust. The EPP interface of
 the Registry will also accept key material to extend that chain of trust down
 to individual domain name registrations. Further information about DNSSEC
 procedures is contained in response to question 43.

Regarding ICANNʹs ʺConsensus Policiesʺ, the Registry will provide the necessary
services to comply with these policies (as well as any Temporary Policies as
adopted by ICANN). This includes support for ICANNʹs UDRP and URS processes.
The Registry Operator will also restrict Registrar use of the ʺAdd Grace
Periodʺ (AGP) as required by the ʺAdd Grace Period Limits Policyʺ.

A ʺSunriseʺ will be foreseen for the proposed gTLD, more information about that
process can be found in the answer to question 18b.

The registry system (software, documentation, test infrastructure) providing the
above mentioned Registry Services is readily available at the time of this
writing and most of the components are in production use by one or more TLDs.

All registry services are based on well-known industry standards and implement
RFCs developed by the Internet Engineering Task Force. 

The Registry will not operate any services that are specific or unique to the
particular TLD. Hence, it is expected that potential registrars will require
only minimal effort to connect to the Registry Systems to be able to perform
registrations of domain names under the TLD.

Registrar Web: Registrars will be provided with a ʺRegistrar Webʺ, a web site
specifically targeted at registrars that will support registration procedures
and allow registrars to change the configuration of their Registry account.
This will include administration of their EPP login (particularly their client
IP addresses) details, invoice downloads and financial functions such as
topping up prepaid credit with the registry. Terms and
conditions as well as registry policies are also available for download. 
Moreover the registrar web page provides statistics to registrars, gives them an
overview of transactions requiring payment and shows available credit.

Registrar Helpdesk: A helpdesk will also be provided by DNS.be (the registry
operator itself) for registrars. This helpdesk will handle technical, legal and
administrative inquiries from registrars. Helpdesk agents can be reached via
email, telephone and fax. A professional ticketing system and qualified agents
will ensure that all queries are handled within an appropriate turnaround time.
Helpdesk services will be available during working hours on business days and an
additional emergency contact will be available 24⁄7. 

Security: The Registry Operator takes significant measures against (1) the
unauthorized disclosure, alteration, insertion or destruction of Registry data
and (2) the unauthorized access to or disclosure of information or resources on
the internet. This includes a detailed security policy (contained in answer to
Question 30), a secure architecture (see response to Question 32), a 
multi-layered backup strategy (details in response to Question 37) and a domain
name lifecycle that makes it extremely unlikely that third parties can gain
control over the registration record of a domain (see response to Question 27).

Stability: The operation of the TLD and the Registry Services offered do not
involve any technology or business practice that has the potential to adversely
affect the stability of the TLDʹs services and⁄or the DNS as a whole. All
protocols used are based on authoritative standards published by
well-established and recognized standards organizations. For example, the DNS
service provided for the TLD is in strict compliance with the relevant RFCs
created by the Internet Engineering Task Force and as a result will be fully
compatible with existing and deployed internet technology. Specifically, the TLD
will not engage in any DNS ʺtricksʺ such as wildcard or NXDOMAIN redirection and
will ensure that no conditions affecting the throughput, response time,
consistency or coherence of responses to Internet servers or end systems arise.

In order to fulfill the functions described above, the Back-End Registry Operator
also performs operations of standard business components, such as:

* Permanent office location infrastructure in two cities (Vienna and Salzburg),
 including three meeting rooms, with additional emergency office space
 contracted.
* Rented datacenter space at various locations.
* Billing and Financial administration and infrastructure
* Technical office infrastructure such as IT systems (file storage, email⁄fax
 systems, document management), call-center enabled PBXes with integrated
 mobile devices, Teleconferencing equipment, fail-safe networking
 infrastructure between office locations themselves, and between office and
 datacenter locations.

These basic ʺbusiness building blocksʺ are established since nearly 15 years,
and are used for the day to day operations of the registry Back-End Registry
Operations.
Since some of the elements listed above are assumed to be standard business
commodities that are not specific to the operations of a gTLD registry, they are
not described in further detail in subsequent answers (eg. enterprise PBX). 

A number of the Back-End Registry Operatorʹs staff are actively engaged in
numerous working groups within the Internet Engineering Task Force, particularly
those focused on DNS, ENUM, emergency services and geographic location. In
addition several of these employees are authors of published and draft IETF
RFCs.

Response to Question 24 (SRS Performance)

1. High-level SRS systems description
-------------------------------------

The Shared Registry System is based on the Extensible Provisioning Protocol (EPP) and employs a multi-tiered architecture with public facing interfaces completely segregated from backend functions (such as database and management interfaces). An overview of the functionality provided by the SRS is as follows:
* Registrars connect to and authenticate against the EPP frontend systems.
* Those frontends receive and parse all EPP commands to perform checks of business logic (including any policy requirements) and subsequently perform (or reject) the requested action against the back-end data storage.
* The back-end data storage is handled by a Relational Database Management System (described in detail in response to Question 33).

The server elements used for the SRS employ a number of technologies to ensure service availability and reliability. These include the use of multiple, virtualised Linux servers and several layers of high-availability functionality such as active-active load balancing, standby components and replication of full virtual machine images. A significant amount of design and implementation effort has focussed on removing any potential single point of failure in the SRS architecture. This architecture has also been fully tested and verified on a functionally identical prototype system, and is operational for the “.bh” migration. Some of that work included training and verification by independent third party system architecture experts, in particular the critical system availability functions such as cluster failover and real-time block device level replication.

The SRS software itself is readily available at the time of this submission. It is implemented and operated in accordance with the requirements of Specification 6 („Registry Interoperability and Continuity Specifications“) and the respective SLAs in Specification 10. The SRS uses EPP as its core provisioning protocol and supports, amongst other RFCs, the following provisioning RFCs as required in Section 1.2 of Specification 6:
* RFC 5730 (EPP Base Specification)
* RFC 5731 (EPP Domain Name Mapping)
* RFC 5732 (EPP Host Mapping)
* RFC 5733 (EPP Contact Mapping)
* RFC 5734 (EPP TCP Transport). 
* RFC 3735 (EPP Extension Guidelines)
* RFC 5910 (DNSSEC Mapping)
* RFC 3915 (Grace Period Mapping)

For maximum interoperability, only EPP functionality that is documented in the above RFCs is implemented – i.e. there are no proprietary EPP extensions used in the SRS. Further details about the implementation of the EPP Registry Services are contained in response to Question 25 (“EPP”).

It is understood that SRS availability and 100% data integrity are absolute key requirements for the deployment of a successful TLD operation. As a result the SRS implementation was developed with a strong focus on those key factors.

The core software platform employed by the SRS, with its powerful modular policy functionality has been in production use for the „.at“ ccTLD (nic.at) since 2003, additionally the „.no“ ccTLD (norid) successfully migrated to the registry software over the course of 2010. Another installation of the software was recently rolled out to support the migration of the “.bh” ccTLD (Kingdom of Bahrain) from the incumbent operator to the Regulatory Authority of Bahrain. Furthermore, this core software is currently being used to provide SRS implementations for ENUM (Electronic Numbering) Registries in Austria (+43) and Ireland (+353). Finally, test instances of this customised software for ENUM are deployed in The Netherlands and Australia. 

The modular and highly extensible structure of the SRS software allows for customized per-TLD policies that are implemented on top of an identical core registry system. This allows for code reuse between different TLD implementations, regardless of the policy framework required.

The implementation of this software, specifically for this new gTLD, has been customized to the needs of the registry operator and to meet or exceed ICANN’s policy and SLA requirements set out in the Applicant Guidebook for new gTLDs. A detailed description of the architecture supporting the SRS software is contained in answer to Question 32 (Architecture). 

Details for the DNS elements of the TLD service, including zone file creation, signing, dissemination and testing procedures are contained in answers to Question 35 (DNS) and answers to Question 43 (DNSSEC). 

Policy and additional documentation about Internationalized Domain Name (IDN) usage in the TLD is contained in answer to Question 44 (IDN). 

The SRS is fully IPv6 compliant: It accepts IPv6 addresses as Glue Records for host objects and is reachable via native IPv6 transport. Additional details about IPv6 support are contained in answer to Question 36 (IPv6). 

For reference, the Performance Specifications relevant to the SRS as required by Specification 10 (Registry Performance Specifications) are included in Table Q24-01. As indicated, the SRS performance meets or exceeds all SLA requirements and significant effort has been taken to verify these SLA requirements on a physical installation of the SRS architecture⁄software. Hence, the performance metrics included in Table Q24-01 are real measurements, rather than theoretical assumptions or estimations.

Note: The performance SLAs have been verified by setting up a prototype system that is functionally and architecturally identical to the registry system, but has limited hardware resources compared to the proposed production architecture. Hence, the performance of the actual production system is expected to exceed the measured performance values on the prototype system indicated in Table Q24-01. Details on the measurements are contained in the responses to Question 33.

Table Q24-01: see attachment

The measurements used to achieve the individual Service Levels are discussed in the following sections:

2. Performance – Shared Registry Service (EPP)
----------------------------------------------

2.1. EPP service availability

The EPP interface of the SRS is provided by two front end server processes on two physically separate machines. Both front ends are accessible via a single IP address, and the load is dynamically shared between these two frontends. In the case that a single frontend system is unresponsive, it is automatically removed from the load balanced group. When a frontend returns to service, it is automatically added back into the load balanced group configuration. In addition, alerts to the NOC are triggered for all such events so that the operations team is notified of error conditions immediately.

For security reasons, access to all EPP interfaces is restricted and is only permitted from network ranges of authorized registrars. 

Using this architecture, the SRS for the proposed TLD will exceed ICANN’s „EPP service availability“ requirement of 98%. A production implementation of the Registry System (for the “.at” TLD) with similar software & architecture has surpassed 99.6% monthly availability for each month during 2009, 2010 and 2011 (with most months above 99.9% availability). 

2.2. EPP command performance notes

The performance of the SRS for EPP session, query and transform commands was extensively evaluated. Please refer to the response to question 33 for the measurements and figures indicating the performance under a realistic base load of the proposed registry system. These figures show that the EPP session, query and transform command RTTs clearly meet the 2000ms and 4000ms thresholds, respectively, for at least 90% of the commands.

2.3. Additional Performance figures

The response to Question 33 (Database) contains some additional performance figures for the SRS, again gathered on a prototype system.

3. Network Overview & Number of Servers
---------------------------------------

The SRS servers make use of the two data center locations “Vienna” and “Salzburg”, (distance approximately 300km⁄185miles). The data centers are equipped with multiple, independent upstream connections to the internet (from different service providers) and two Layer 2 crosslinks. The backend registry operator also operates a Local Internet Registry (LIR), allocates IP space from its own address pool, and operates its own Autonomous Systems (ASes). The high-level network structure is shown in Figure Q-24-02.

As shown, a significant focus of the network design work has been to remove any single point of failure. Also, each server is connected to two access routers, so that an outage of any single network component does not affect server and consequently service availability. More information about the network infrastructure at each individual location is contained in response to Question 35.

The server infrastructure of the gTLD’s SRS consists of the following set of machines (this list does not include the actual DNS network):
* Two, physically separate, servers running SRS frontend instances and the production database, clustered in active-active (Frontends) and active-standby (Database) configuration. Database as well as SRS frontends are segregated from each other via virtualization. In terms of scalability, should the TLD exceed 500,000 registered domains, provisions are in place to add further, dedicated machines as needed.
* A total of 6 physical machines provide the additional functions of the gTLD, including zone generation, DNSSEC signing, zone deployment (via Hidden Masters), backup, management, and a test instance of the SRS. The functions on those 6 “infrastructure” machines are shared among up to 4 gTLD installations, and adding more machines is planned depending on growth projections for each individual TLD. The existing infrastructure scales to at least 500,000 domain names per TLD without requiring additional servers. Services on those physical servers are again segregated from each other using virtualization.
* Additionally, several other servers are involved in supplementary functionality, such as monitoring, tape backup, logging & reporting services.

All servers used for the operation of the TLD are (and will be) rack mountable, data center grade machines with active maintenance contracts from the supplier. A complete and detailed overview of machinery in place for this TLD is given in Table Q32-11 of the answer to Question 32.

3.1. Interconnectivity with other Registry Services

The SRS, as well as the infrastructure required to perform the other critical Registry Services are installed on servers located in the same data center (under emergency conditions, services may be moved to servers in the backup data center). Therefore, the services are inter-connected using either Local Area Networking (LAN) or redundant private layer 2 links (linking the “Vienna” and “Salzburg” locations). In addition to the redundant layer 2 links, infrastructure is in place to securely tunnel traffic between those two locations over the public internet in the unlikely case that both the private site cross-links fail. From a security perspective, multiple firewall layers are used to filter network traffic between the various network segments, i.e. between the public Internet, perimeter and internal networks.

Zone dissemination or transfer from the hidden primary to the public nameserver network is performed over the public internet however all such communications are cryptographically secured. Both locations have redundant upstream connectivity from independent providers with a minimum total bandwidth of 2x1 Gbit⁄s.

Both networks are also connected to the “Vienna Internet Exchange” (VIX), where peering relationships with many other organizations have been established. This provides an optimal routing path to the Registry Systems and services for those organisations.

In terms of data integrity and consistency the following provisions have been put in place to ensure correct synchronization of Registry systems:
* The active and standby database servers are synced in real-time using block device level replication functionality provided by the DRBD technology.
* DNS zone servers are synchronized every 15 minutes.
* For failover purposes, full machine images or snapshots of all virtual machines are copied to the standby data center once per day (please see the response to Question 37 for details)
* Synchronization between SRS and registry helpdesk systems occurs every few minutes.
* It is important to note that as WHOIS data is provided directly from the backend registry database there is no need to synchronize WHOIS data.

The synchronization strategy used differs from service to service. For the SRS frontends themselves, an active-active setup with OSPF-based load-balancing is employed. The registry database uses an active-standby setup with real-time synchronization and automatic failover. 

3.2 Resourcing Plan

It should be noted that the architecture and basic development work for the SRS software has already been completed at the time of this submission (except policy adjustments for the TLD), which reduces the time and number of personnel required to perform the necessary development and maintenance work.

The Registry Backend Operator employs 4 developers (totalling to 3 FTEs) responsible for developing and maintaining the SRS software, for example implementing per-TLD policy customisations. Those developers also work on the development and maintenance of RDDS, and their work is shared amongst the operation of multiple TLDs.

Additionally, 2 system engineers (2 FTEs) are responsible for performing the actual deployment of the SRS for a new TLD including the subsequent hand over of the newly installed systems to the Network Operations team.

A minimum of 8 people are fully trained to perform day-to-day and ongoing maintenance operations of the SRS systems and software.

The required hardware for the SRS is described above and all related costs are bundled with the “Software as a Service” fees that the Registry Operator pays to the Registry Backend Operator. This also includes all resources that are required to operate the hardware for the SRS, such as data center or other infrastructure expenses, maintenance contracts and hardware replacement.

Response to Question 25 (EPP)
 
1. Overview 
-------------
The SRS of this proposed gTLD will use EPP for communication with registrars. 
The EPP interface is in full compliance with the following RFCs and, where 
possible, entirely based on common standards: 

* RFC 5730 - Extensible Provisioning Protocol (EPP)
* RFC 5731 - Extensible Provisioning Protocol (EPP) Domain Name Mapping
* RFC 5732 - Extensible Provisioning Protocol (EPP) Host Mapping
* RFC 5733 - Extensible Provisioning Protocol (EPP) Contact Mapping
* RFC 5734 - Extensible Provisioning Protocol (EPP) Transport over TCP
* RFC 5910 - Domain Name System (DNS) Security Extensions Mapping for the 
 Extensible Provisioning Protocol (EPP) 
* RFC 3915 - Domain Registry Grace Period Mapping for the Extensible 
 Provisioning Protocol (EPP)
* RFC 3735 - Guidelines for Extending the Extensible Provisioning Protocol (EPP) 

Note that the objective is to base the EPP interface entirely on published RFCs 
and it is hence not planned to use any proprietary EPP commands. However, it is 
understood that some functionality required by ICANN cannot be implemented by
means of EPP extensions specified in published RFCs. 

This includes support for:
* Trademark Clearing House: integration in the domain registration process 
 (sunrise and claiming phase)
* IDN: exposure of language tags in the EPP interface
* IDN: selection of variants to be included in the DNS zone

Currently the following documents related to the topics listed above are
available:
* draft-tan-epp-launchphase
* draft-obispo-epp-idn
* draft-kong-epp-variants-mapping

The registry backend operator participates in the standardization process and
understands that the community is currently working on the respective 
documents. It is expected that specifications are published and implementable
before the registry goes operational, which allows the registry operator to
stick to its strategy of using only IETF RFC specified EPP extensions. 
However, if such specifications are not available in a timely manner before the 
registry intends to go operational, draft specifications that reflect
industry and community consensus will be considered instead in order to cover
ICANNs functional requirements.

Via EPP, the following objects can be managed by registrars:
* domain objects
* host objects
* contact objects

The following commands are supported by the EPP interface:
* Session Management
 * Login
 * Logout
 * Poll
 * Hello
* Domain Commands
 * Check domain
 * Info domain
 * Create domain
 * Delete domain
 * Renew domain
 * Transfer domain
 * Update domain (including “restore”)
* Host commands
 * Check host
 * Info host
 * Create host
 * Delete host
 * Update host
* Contact commands
 * Check contact
 * Info contact
 * Create contact
 * Delete contact
 * Update contact

According to the definitions in RFC 5730, the registry operator will apply for
an EPP repository identifier with the IANA registry
(http:⁄⁄www.iana.org⁄assignments⁄epp-repository-ids).

The only language supported for message elements in EPP is English.


2. Session Management
----------------------
The transport layer between EPP clients and the SRS EPP interface is
protected using TLS with X.509 certificates. The registry will only use
strong ciphers such as those required by the EPP RFC and listed below,
but reserves the right to modify the list of ciphers depending on
cryptographic developments.

* TLS 1.0 [RFC2246]: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
* TLS 1.1 [RFC4346]: TLS_RSA_WITH_3DES_EDE_CBC_SHA
* TLS 1.2 [RFC5246]: TLS_RSA_WITH_AES_128_CBC_SHA

On top of the TLS based identity verification, login to the SRSʹs EPP
interface is protected using two additional authentication factors, with
one factor being the IP address of the client and the other factor being
the clientsʹ credentials. Failed login attempts are logged and reported.
The administration of authorised IP address ranges can be performed by
registrars via the Registrarʹs web interface or by contacting the
helpdesk. Passwords can be changed via the EPP login command as
described in RFC 5730, Section 2.9.1.1.

EPP sessions will be terminated by the server either after an idle timeout of
20 minutes or after the maximum session length of 24 hours. The registry
operator reserves the right to restrict the number of concurrent EPP sessions
per registrar (a limit of three sessions is currently defined but this may be
amended depending on registry and TLD scaling requirements).

The EPP service also employs infrastructure elements and software measures to
perform rate-limiting of EPP sessions (such measures may, for example,
be required during landrush phases).
The SRS does not support EPP command pipelining. 

3. Object Management
--------------------
The registry supports the provisioning of contact, host and domain objects as
defined in the respective RFCs and according to the lifecycle described in
response to question 27.

Registration periods apply for domain objects only (in one year increments).
The default initial registration and renewal period is 1 year. The client may
choose another period of up to 10 years when issuing the respective request
(the total registration period of a domain must never exceed 10 years).

Since the registry uses grace periods, the grace period mapping of RFC 3915 is
supported by the EPP interface. In particular, a restore command is issued as an
extension to the update command, as described in this RFC.
Furthermore, the restore report is also delivered to the registry via EPP.

The registry operator reserves the right to perform a garbage collection process
on unlinked contact and unlinked external host objects. Internal hosts follow
the lifecycle of their superordinate domain and are not subject to garbage
collection (for details refer to responses to questions 27 and 28).

For contact objects, only internationalized postalInfo elements are supported.
All child elements as listed in the RFC are supported. Note that since the
registry does not support contact transfers, contact authInfo is not used.

For the provisioning of DNSSEC trust chains, the EPP interface supports the
extension described in RFC 5910 for accepting DS data (key data interface is not
supported). Details on DNSSEC support are contained in response to question 43.

4. Domain Transfer
------------------
The domain transfer command has several subcommands. Note that a transfer can
only be requested on domain objects but that the registry system will auto-
matically transfer subordinate host objects when the superordinate domain is
transferred. Contact objects are never transferred.

The set of transfer commands consists of the following subcommands: 
 “request”, “approve”, “reject”, “cancel” and “query”.
To request a domain transfer, the requestor sends a transfer request with a
valid authInfo. The losing registrar is subsequently notified and can either
reject or approve this request. In the event that the losing registrar doesn’t
explicitly reject or approve the request, the registry will auto-approve the
request after 5 calendar days. Before the transfer is approved, auto-approved or
rejected, (i.e., the domain is in pendingTransfer state) the requestor may
cancel it. A detailed description of the domain transfer lifecycle is contained
in response to question 27 (Figure Q27-02).

AuthInfo is required for all domain objects. This information is necessary in
order to authenticate a domain transfer process. The registry system requires
that the authInfo is at least 8 characters long with a maximum length of 32
characters. Furthermore, at least one alphanumeric character (‘A’ to ‘Z’; both
lower and uppercase letters) and at least either one numeric character
 (‘0’ – ‘9’) or one special character are required for each authInfo.

5. Status values
----------------
The domain object supports the following status values
 (as described in Section 5 of RFC 5731):
* inactive (to indicate that no hosts are associated with the object).
 This status value is set automatically by the server.
* ok (default status) set automatically by the server.
 This status value is never combined with any other status values.
* pendingTransfer is set by the server when the domain name is subject
 to a pending transfer
* pendingDelete is set by the server when the domain name is subject
 to deletion. Note that the registry also supports the RGP grace periods -
 redemption and pending delete as listed below.
* serverHold⁄clientHold is set when the domain object should not appear in the
 zone.
* serverUpdateProhibited⁄clientUpdateProhibited set when the domain name cannot
 be updated due to server or client policy.
* serverTransferProhibited⁄clientTransferProhibited set when the domain name
 cannot be transferred due to server or client policy.
* serverDeleteProhibited⁄clientDeleteProhibited set when the domain name cannot
 be deleted due to server policy or client provisions.
* serverRenewProhibited⁄clientRenewProhibited set when the domain name is not
 eligible for renewal.

Each domain object will always have at least one associated status value.
Additionally, domain objects support the following status values related to the
grace period mapping as per RFC 3915, Section 3.1:
* addPeriod
* autoRenewPeriod
* renewPeriod
* transferPeriod
* redemptionPeriod
* pendingRestore
* pendingDelete

The contact object supports the following status values
 (as described in Section 2.2 of RFC 5733):
* linked (when the object is used in at least one domain name object)
* ok (default status)
* serverUpdateProhibited⁄clientUpdateProhibited (for server or client policy
 reasons, modifications to the object are not allowed)
* serverDeleteProhibited⁄clientDeleteProhibited (for server or client policy
 reasons removal of the object from the registry is not allowed)

Each contact object will always have at least one associated status value.

The host object supports the following status values
 (as described in Section 2.3 of RFC 5732):
* linked: Set by the registry when a host is referenced by at least one domain
* ok (default status)
* pendingTransfer: Set on internal host objects when the superordinate domain
 is pending transfer.
* serverDeleteProhibited⁄clientDeleteProhibited 
 (for server or client policy reasons removal of the object from the registry
 is not allowed)
* serverUpdateProhibited⁄clientUpdateProhibited 
 (for server or client policy reasons, modifications to the object
 are not allowed)

Each host object will always have at least one associated status value.

6. EPP Server Implementation
----------------------------
The EPP server implementation is based on the Apache HTTP server, with the HTTP
protocol handler replaced with a custom, Perl-based EPP handler. This allows for
the reuse of Apache’s session management, logging and resource allocation
functionality. EPP systems based on this software have been deployed in
production since 2004. The software has been continuously developed, in order to
accommodate policy changes and scalability requirements.

The EPP software variant for the proposed TLD is already available and has
already been deployed on prototype systems (with the exception of functionality
where specifications are unclear at the time of this writing, i.e. Trademark
Clearing House integration).

Since no proprietary extensions are planned, no EPP templates and no EPP
extension schemas are provided in response to this question. Schemas and
examples of the commands supported are included in the respective RFCs.

7. Resource Planning
--------------------
The technical resources required for the operation of the EPP server (as part of
the SRS) are described in response to questions 32 and 24.
For EPP development and evaluation of related issues, the Back-End Registry
Operator has a highly skilled research & development team of 5 persons, of which
3 people are intimately familiar with the details of the EPP protocol. They also
monitor and contribute to the discussions within the IETF regarding future
developments of EPP (“provreg” mailing list).

All technical staff are trained on the day-to-day operations of the EPP service.
The helpdesk team is trained and experienced in troubleshooting EPP support
problems with Registrars, and can escalate to the EPP experts or even core
developers in case of more complex problems.

Response to Question 26 Whois
 
1. Overview
-------------
As detailed in Specification 4 “Specification for Registration Data Publication
Services” (RDPS), the Registry Operator will operate a fully compliant
“Registration Data Directory Service” (RDDS), will provide “Zone File Access”
as required and will grant ICANN the required “Bulk Registration Data Access”.
These services will fulfil the requirements stated in the respective
specification, and will also meet or exceed the respective RDDS SLAs as required
in Specification 10.

In addition to the requisite WHOIS service, a lightweight variant of the RDDS,
a so-called “Domain Availability Interface”, based on the “finger” protocol,
will be provided. This service will supplement the WHOIS service, and exposes a
very limited subset of the information already available via the RDDS, namely,
whether or not a certain domain name is available for registration.

2. Registration Data Directory Services
-----------------------------------------
A WHOIS service will be available via port 43 in compliance with RFC 3912.
Additionally a web-based directory service, to be made available at
ʺwhois.nic.brusselsʺ, will provide a free, publicly accessible, query-based
interface which will provide information regarding “Domain Name”, “Registrar”
and “Nameserver” objects. The data format used for those objects is specified
below. It is understood that ICANN reserves the right to require alternative
formats and protocols, and upon such specification, such changes will be
implemented as soon as reasonably practicable.

Specifically, the WHOIS service fulfils the following requirements:
* The server is fully compliant with RFC 3912
* Free public query-based access is provided
* The service runs on “whois.nic.brussels” on TCP port 43
* Data objects represented by key⁄value pairs, with multiple key⁄value pairs
 with the same key in case of fields with more than one value
* Additionally, web-based access on “whois.nic.brussels” is provided
* In order to prevent abuse, highly configurable volume access limitations are
 deployed
* The architecture is robust, implements a number of failsafe mechanisms and is
 in compliance with the RDDS SLA’s outlined in Specification 10.
 
2.1 Architecture

The technical architecture of the WHOIS system (servers, switches, routers, etc)
is depicted in Figure Q26-02, and employs the following components:

* Connectivity to the internet is handled via the two redundant access routers
 of the registry system. Each server is connected to each of the two routers,
 with one connection serving as an active path, and the second path (to the
 other router) serving as a failover path in case of failure of the first.
* Two virtual machines on physically separate hardware run the frontend
 Whois⁄Finger⁄HTTP daemons.
* The WHOIS service on each server operates as part of an active-active cluster.
 Both servers announce their respective service addresses to the routers via
 OSPF with the routers distributing traffic between the two front-ends by means
 of OSPF load sharing logic.
* Both active instances are connected to the active registry database using
 persistent database connections to reduce session handling overhead.
 The frontend servers switch automatically to the registry standby database
 in the event of a database failover.
* In the case where one of the frontend servers fails, the OSPF announcement for
 that server automatically ceases and traffic is redirected to the remaining
 active node within a few seconds.
* Access is restricted to TCP port 43 (for Whois), TCP port 79 (for Finger) and
 TCP port 80 (HTTP) using firewall access lists on the routers.
* The codebase for the WHOIS and Finger servers was developed in-house using the
 “C” programming language and is based on state-of-the art design concepts to
 ensure a robust and stable operation. This software has been actively
 developed for a number of years and is currently in production at the “.at”
 and “.no” TLD registries.
* The software is also highly configurable, allowing query limits to be set
 based on source IP address⁄blocks for both IPv6 and IPv4 addressing formats.
 It also allows for fine grained control of specific rate-limits on a per
 network block basis.
* The software actively generates access and service statistics for monitoring
 and management purposes.
* The RDDS uses the “live” registry database and as a result updates to the
 registry database are reflected in real-time to the WHOIS server. However, in
 the event that the WHOIS load starts to impact the performance of the
 Registry database, provisions are in place to move the WHOIS server to an
 alternate read-only replica of the “live” database if necessary.

2.2 Access Limitations and Access Restrictions

Access control lists (ACLs) protect the RDDS service hosts against unwanted
access but grant public access to the defined services (WHOIS, finger, HTTP).
In addition to this general protection of the service infrastructure, the RDDS
must also make provision to address the following scenarios:
* Bulk requests from public unknown sources (e.g. to grab data)
* High speed ⁄ high volume requests from known source addresses
 (e.g. from registrars)

In order to handle the above scenarios the WHOIS software supports the following
configurable service policies:
* The number of allowed requests (within a specific time frame) on a per IP
 address (or per IP subnet) basis, for either IPv4 or IPv6 and with support for
 a “most specific” matching rule of those entries. This provides the ability to
 set different limitations for different user groups ⁄ network ranges.
 Violations of those limits are included in the daily WHOIS service reports
 sent to the operations team.
 
2.3 WHOIS Input Format

The data format complies with the requirements of Specification 4 of the
“new gTLD agreement”. The definitions below apply to the command line WHOIS
interface (port 43) as well as the web interface:
* Queries can be issued for domain name, registrar and nameserver objects
* Queries that include the argument “registrar” trigger a search for registrar
 data objects. If the argument is “nameserver”, a search for nameserver objects
 is actioned, while queries without any such prefix trigger a search for a
 domain or nameserver.
* Wildcard searches and substring searches are not supported.
* Using the option “-C” (“charset”) as part of the command line WHOIS query
 specifies a character encoding for the protocol. This setting applies to the
 both the input and output character encoding, and supports the following
 values: “US-ASCII”, “ISO-8859-1” and “UTF-8”. The default character set is
 “UTF-8”. On the web interface the character encoding will always be set to
 UTF-8 with modification of this option not available.
* In the case of IDNs, the search string must be in the A-Label format of the
 domain or nameserver. Searches based on the U-Label format are not supported.
 
Example queries (including the command line “whois” client itself):
* Domain name data: whois -h whois.nic.brussels example.brussels
* Domain name data (with character set parameter):
 whois -h whois.nic.brussels -- -C us-ascii example.brussels
* Registrar data: whois -h whois.nic.brussels “registrar Example Company”
* Nameserver data by name: whois -h whois.nic.brussels ns1.example.brussels
* Nameserver data by IP address:
 whois -h whois.nic.brussels “nameserver 10.0.0.10”

Note: In the case where a host is registered for the origin of a delegated
 domain, i.e. both domain “example.brussels” and nameserver
 “example.brussels” exist, the query will match and return both the
 domain name and nameserver data objects.
 
2.4 WHOIS Output Format

The output format of the WHOIS server follows that outlined in Specification 4
of the “new gTLD agreement”:

Domain Name Data: 

Domain ID: D1234567-BRUSSELS
Domain Name: EXAMPLE.BRUSSELS
Updated Date: 2009-05-29T20:13:00Z 
Creation Date: 2000-10-08T00:45:00Z 
Registry Expiry Date: 2010-10-08T00:44:59Z 
Sponsoring Registrar: EXAMPLE REGISTRAR LLC 
Sponsoring Registrar IANA ID: 5555555 
Domain Status: clientDeleteProhibited 
Domain Status: clientRenewProhibited 
Domain Status: clientTransferProhibited 
Domain Status: serverUpdateProhibited 
Registrant ID: 5372808-BRUSSELS 
Registrant Name: EXAMPLE REGISTRANT 
Registrant Organization: EXAMPLE ORGANIZATION 
Registrant Street: 123 EXAMPLE STREET 
Registrant City: ANYTOWN 
Registrant State⁄Province: AP 
Registrant Postal Code: A1A1A1 
Registrant Country: EX
Registrant Phone: +1.5555551212 
Registrant Phone Ext: 1234 
Registrant Fax: +1.5555551213 
Registrant Fax Ext: 4321 
Registrant Email: EMAIL@EXAMPLE.TLD 
Admin ID: 5372809-BRUSSELS 
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE 
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION 
Admin Street: 123 EXAMPLE STREET 
Admin City: ANYTOWN 
Admin State⁄Province: AP 
Admin Postal Code: A1A1A1 
Admin Country: EX 
Admin Phone: +1.5555551212 
Admin Phone Ext: 1234 
Admin Fax: +1.5555551213 
Admin Fax Ext: 
Admin Email: EMAIL@EXAMPLE.TLD 
Tech ID: 5372811-BRUSSELS 
Tech Name: EXAMPLE REGISTRAR TECHNICAL 
Tech Organization: EXAMPLE REGISTRAR LLC 
Tech Street: 123 EXAMPLE STREET 
Tech City: ANYTOWN 
Tech State⁄Province: AP 
Tech Postal Code: A1A1A1 
Tech Country: EX 
Tech Phone: +1.1235551234 
Tech Phone Ext: 1234 
Tech Fax: +1.5555551213 
Tech Fax Ext: 93 
Tech Email: EMAIL@EXAMPLE.TLD 
Name Server: NS01.EXAMPLEREGISTRAR.TLD 
Name Server: NS02.EXAMPLEREGISTRAR.TLD 
DNSSEC: Signed
DS Key Tag 1: 54135
Algorithm 1: 5
Digest Type 1: 1
Digest 1: 〈DIGEST〉
DS Key Tag 2: 54135
Algorithm 2: 5
Digest Type 2: 2
Digest 2: 〈DIGEST〉

% Copyright (c) 20XX by NIC.BRUSSELS
% Restricted rights.
% Response generated on: 2011-10-13 11:11:25 UTC

Note that the “Domain Name” field will always contain the A-Label format of the
domain. In cases where an IDN response is returned (and an appropriate character
encoding was requested), the response will contain an additional field, the
so-called “Domain U-Label”, containing the U-Label format of the respective
Domain, for example: Domain U-Label: exämple.brussels

In the case where data for an unsigned domain is returned, the “DNSSEC” field
will contain the value “unsigned” and the other DNSSEC-related fields will be
excluded from the response.

Registrar Data: 

Registrar Name: Example Registrar, Inc. 
Street: 1234 Admiralty Way 
City: Marina del Rey 
State⁄Province: CA 
Postal Code: 90292 
Country: US 
Phone Number: +1.3105551212 
Fax Number: +1.3105551213
Email: registrar@example.tld 
Registrar IANA ID: 55566677

% Copyright (c) 20XX by NIC.BRUSSELS
% Restricted rights.
% Response generated on: 2011-10-13 11:11:25 UTC

Nameserver Data:

Server Name: NS1.EXAMPLE.TLD
IP Address: 192.0.2.123 
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Registrar IANA ID: 55566677

% Copyright (c) 20XX by NIC.BRUSSELS
% Restricted rights.
% Response generated on: 2011-10-13 11:11:25 UTC

2.5 Web-based RDDS

In addition to the command line based WHOIS service described above, the
Registry Operator will, in line with requirements, provide a web-based WHOIS
interface. The web-based interface supports the following classes of users in
accordance with stated policies:

1) The general public (“anonymous access”):
 Anonymous users can retrieve a limited amount of responses from the web
 based interface. To avoid unwanted bulk access and to prevent users from
 data harvesting the following access restrictions are deployed:
 a. maximum number of requests per client (based on IP ranges)
 b. users must pass a CAPTCHA for every request
 
2) Registrars and other authenticated users:
 Registrars and other approved users are issued with an authentication token
 that allows them to retrieve a greater number of WHOIS records via the web
 interface. “Other qualified users” could for example include ICANN staff,
 URS and UDRP providers, and will be decided case by case.
 
All transactions on the web-based WHOIS are also logged and daily usage reports
are sent to operations staff. The web-based WHOIS supports the same object
types and query formats as the command line interface above, with the exception
of the ʺ-C“ (character set) switch. The contents of a response from the
web-based WHOIS service are also identical to the command line service, but may
be reformatted and styled using HTML⁄CSS to aid presentation and display.

2.6 Searchable WHOIS

Searchable WHOIS functionality is not provided. This is to prevent bulk data
harvesting and further data merging using extensive request combinations and
Boolean search techniques. This is done intentionally to comply with data
protection laws and privacy obligations.

Any request from legal institutions and law enforcement agencies for information
outside of that supplied by any of the WHOIS services is dealt with directly by
the legal department of the registry.

As a result there is no future intention to offer a broad search functionality,
this applies to both the WHOIS protocol interface (port 43) and the web-based
WHOIS interface
 
2.7 Lightweight RDDS Access (“Finger”)

In addition to the required WHOIS interface a lightweight domain availability
interface is supported. This interface is based on the “Finger” protocol,
specified in RFC 1288, and exposes a very limited subset of data (already
available in WHOIS), namely whether or not a certain domain name is available
for registration. It provides faster response times than the standard WHOIS
interface and places less load on the registry systems.
The service will be operated accordingly:
* Lightweight access based on the “finger” protocol according to RFC 1288
* Lightweight access runs on finger.nic.brussels on port 79
* No exposure of any information additional to that already available via
 the WHOIS RDDS
* Query format (command line example):
 “finger example.brussels@finger.nic.brussels”
* Response format (example): “example.brussels IS NOT available”

2.8 IPv6 Support

All RDDS services (WHOIS, web-based WHOIS, Finger and bulk data access) fully
support IPv6. In summary there is no difference in service quality levels or
service responses between IPv4 and IPv6 for these services.
A detailed description of IPv6 support can be found in response to Question 36.

2.9 Service Level Compliance

The RDDS service complies with the SLA requirements (as defined in
Specification 10) as shown in Q26-02 figure.pdf
 
2.9.1 RDDS Availability

The redundant and resilient architecture of the WHOIS system is described above,
and is served by architecture as outlined in response to question 32. It is
designed, at a minimum, to meet the required availability levels of 98%. It is
understood that a reliable RDDS system is vitally important for TLD operations.

2.9.2 RDDS query RTT

The internal response time of the WHOIS system is significantly below the RDDS
query RTT limit of 2000 ms so that it can be expected that for 95% of the
queries this SLA requirement will be met. On test installations of the service,
the query RTT is less than 500 ms, even in the event of a significant number of
concurrent connections.

2.9.3 RDDS update time

Since the WHOIS system queries the “live” registry database, there is no update
delay and hence the RDDS update time of 60 minutes for 95% of the updates can
be assured.

3. Zone File Access
-------------------
In accordance with Section 2 of Specification 4 of the Agreement (Zone File
Access), the Registry Operator will enter into an agreement with any internet
user to provide access to download the zone file data and will cooperate as
required with Centralized Zone Data Access (CZDA) Providers. This will be
facilitated as follows:
* A dedicated FTP server will be set up for access to the zone file data. The
 name of that server will be: brussels.zda.icann.org (pending allocation of
 that hostname by ICANN zone administrators).
 The zone file and associated checksum files will be available for download for
 the previous 3 days. Files will be generated once a day and named according to
 Section 2.1.3 of the Agreement.
* The file format follows exactly the specification which is based on the Master
 Zone File format defined in RFC 1035, according to Section 2.1.4 of the
 agreement.
* A specific user ID and password has to be assigned for each user to restrict
 access to accredited users and to prevent unauthorized access. This user has
 to access the server with this specific user ID to be able to transfer data.
* Access will be free of charge but limited to one download per day.
* All logins and data transfers are logged, monitored and reported. Access
 statistics will be available to the registry operator as well as to others if
 required.
 
The Registry Operator will also cooperate with ICANN and CZDA Providers as
required in Section 2.2 of the agreement. Additional access is granted to ICANN
itself (or its designee) and any designated Emergency Operator if required.

4. Bulk Registration Data Access
--------------------------------
As an operator of a Thick Registry, the Registry Operator will operate in
compliance with Section 3.2 of Specification 4 of the ʺnew gTLD Agreementʺ
(“Exceptional Access to Thick Registration Data”) as well as in compliance with
Section 3.1 of Specification 4 (“Periodic Access to Thin Registration Data”),
and will provide ICANN with the required data in the required format.
The data will be provided in conformance with Specification 2 (“Escrow”) of
the Agreement, as required.

5. Resources
-------------
Regarding development of the RDDS interfaces, it shall be noted that most of the
work is already complete at the time of this writing (eg. WHOIS and finger
daemon are fully deployed and operational for other TLDs). Therefore, only
minimal development work is required, and hence within TLD-Box’s development
team, only a half FTE is necessary (and planned for) for the continuous adaption
and maintenance of the RDDS software itself.

For the actual operation of the RDDS interfaces, all technical operations staff
members are trained on the various infrastructure and software components of the
system, and manpower resources are accounted for in the general Network
Operations Center budget.

The research & development team of the Registry Backend Operator is aware of
ICANN’s SSAC work regarding WHOIS
(eg. http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac051.pdf), and also
participates in the IETF’s proposed “WEIRDS” working group, in order to stay
up-to-date with developments in the fields of domain data related publication
services.

The RDDS makes use of virtual machines on the hardware provisioned for the TLD
(and described in responses to Question 32 and 24). Therefore, no additional
hardware resources are needed, however, the required bandwith in order to
provide the RDDS services are accounted for in the general network topology
of the Registry System.

Response to Question 27 (Registration Life Cycle)

1. Registration Life Cycle
--------------------------

The domain registration life cycle of .brussels follows ICANNs “Life Cycle of a Typical gTLD Domain Name” (http:⁄⁄www.icann.org⁄en⁄registrars⁄gtld-lifecycle.htm). By using this standard model life cycle, Registrars have only minimal effort in order to become familiar with the registration procedures under the proposed TLD. Figure Q27-01 (see attachment) shows the life cycle of a domain with the various states. The description below lists EPP status values, DNS status, and typical allowed transactions for each of the domain states. It also describes whether Whois information is available and what information is provided in a finger request (note: for reasons of clarity the transfer process is shown in a separate figure).

Since the registry system supports the Redemption Grace Period (RGP) extensions as specified in RFC 3915, the domain states ‘REDEMPTION’ and ‘PENDING DELETE’ refer to the respective RGP states.

1.1 Typical Life cycle of a Registration

A typical domain life cycle is initiated by a create domain EPP command for an AVAILABLE name. The domain is now in a ‘REGISTERED’ state. Whilst in this state the information associated with a domain may be updated by the respective registrar (using the update domain command). A domain may also be transferred to another registrar (domain transfer, see detailed state diagram below). A domain is always registered for a specific period (maximum 10 years). At any time Registrars can manually renew domains (given that the maximum registration period is not exceeded). The registry system is also supporting an auto-renew option. The auto-renew option can be deactivated on the request of a Registrar (on a per-Registrar basis), but is enabled by default to ensure that domains do not expire unintentionally.

When a domain is deleted by either the ‘delete domain’ command, or alternatively expires (not manually renewed and auto-renew disabled for the registrar), the domain first enters the ‘REDEMPTION’ state. Whilst in this state, a registrar is allowed to restore domains for the respective domain holder in case the non-renewal was unintentional. When the domain is successfully restored while in the REDEMPTION state (a restore report via EPP is required), the domain enters the ‘REGISTERED’ state again. Domains which are not restored after 30 days in the ‘REDEMPTION’ state enter the ‘PENDING DELETE’ state. Whilst in this state, a domain cannot be restored and will become AVAILABLE for re-registration after a period of 5 days.

Note that domains do not enter the ‘REDEMPTION’ state when they are deleted within the add grace period. Instead, such a domain is immediately deleted and AVAILABLE for re-registration. 

Furthermore, additional EPP status values set on a domain may affect the allowed transactions (operations), e.g. status values of serverUpdateProhibited or clientUpdateProhibited, serverTransferProhibited or clientTransferProhibited, serverDeleteProhibited or clientDeleteProhibited and serverRenewProhibited or clientRenewProhibited will prohibit the respective transaction. Such server states are for example used when a domain is LOCKED.

To discourage and to address problems with abusive registrations, the proposed registry will follow policies described in response to question 28.
For domains under dispute, the registry will use the LOCKED status, and will also set appropriate status values on the associated host and contact objects, as required by the specific dispute scenario (e.g. URS).

1.2 Domain States and Properties

This section describes the individual Domain States, as outlined in figure Q27-01 (see attachment). For each of these states, it is described what the trigger points to reach the status are, whether the domain is included in DNS, which transactions are allowed on the object, whether WHOIS information is available, and what the boolean response for the lightweight RDDS interface (finger) is. Furthermore the EPP (base and RGP) status values set on the domain are listed.

Note that in addition to the commands listed below “check domain” is always possible and the commands “info domain” and “transfer query” are always allowed on existing domain objects, regardless of their status.

Also note that in addition to the EPP status values listed below, the value “inactive” is set for domains without associated host objects.

* AVAILABLE: 
 * Trigger points: Initial status of “new” domains, final deletion of a “PENDING DELETE” domain, deletion of a domain during Add Grace Period.
 * in DNS: No
 * Allowed Transactions: create domain
 * in WHOIS: No
 * Finger results: “available”
 * EPP status values: n⁄a
* REGISTERED:
 * Trigger points: “create domain” command, Restore Report received, disputes resolved
 * in DNS: Yes*
 * Allowed Transactions: update domain, transfer domain (request), delete domain, renew domain
 * in WHOIS: Yes
 * Finger results: “unavailable”
 * EPP status values: serverTransferProhibited (during first 60 days), ok (after the first 60 days if not inactive and no other status value is set)
* REDEMPTION:
 * Trigger points: “delete domain” command, domain expiration, disputes resolved, restore report not received.
 * in DNS: No
 * Allowed transactions: restore domain
 * in WHOIS: Yes
 * Finger result: “unavailable”
 * EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:redemptionPeriod
* PENDING DELETE:
 * Trigger points: domain not restored, delete locked domain
 * in DNS: no
 * Allowed Transactions: none
 * in WHOIS: Yes
 * Finger result: “unavailable”
 * EPP Status values: pendingDelete, serverUpdateProhibited, serverHold, serverTransferProhibited, serverRenewProhibited, rgp:pendingDelete
* PENDING RESTORE:
 * Trigger points: “restore domain” command, dispute resolved
 * in DNS: Yes*
 * Allowed transactions: update domain (including delivery of the restore report), delete domain, renew domain. 
 * in WHOIS: Yes
 * Finger result: “unavailable”
 * EPP status values: pendingDelete, serverTransferProhibited, rgp:pendingRestore
* LOCKED:
 * Trigger points: Opening of a dispute over the domain name
 * in DNS: Yes**
 * Allowed transactions: renew domain
 * in WHOIS: Yes
 * Finger result: “unavailable”
 * EPP status values: serverUpdateProhibited, serverDeleteProhibited, serverTransferProhibited, (serverHold**)

*Note: Domain is only included in the DNS if the domain object is linked to host object(s), and neither serverHold nor clientHold are set on the domain object.
**Note: Depending on the individual dispute case, the Registry may be instructed to set the serverHold flag on the domain, and subsequently, the name would be excluded from the DNS.

The EPP status values pendingCreate, pendingRenew and pendingUpdate are never set on domain objects since there is no human review or third-party action necessary to complete these actions. However, we will screen all new registrations after they are registered and became active. More information about this procedure can be found in the answer to question 18b.

1.3 Transfers

The transfer life cycle of the proposed gTLDs complies with ICANNs “Policy on Transfer of Registrations between Registrars” (http:⁄⁄www.icann.org⁄en⁄transfers⁄policy-12jul04.htm), specifically to its Section 6 (Registry Requirements). The life cycle is illustrated in Figure Q27-02 (see attachment).

A transfer request must have valid ‘authInfo’ in order to be successful. Note that only one transfer request for a domain can be pending at any one time. Transfer requests for a domain name object that is already in the “pending Transfer” state are hence rejected.

Additionally, only domains that have been registered for more than 60 days (counted from the date of the initial registration) can be transferred.
Pending transfers can be either approved or rejected by the currently sponsoring Registrar. After a period of 5 days, any un-actioned requests are auto-approved by the Registry. Pending transfers may also be cancelled by the requesting registrar.

In the “pending Transfer” state, the following transactions on a domain name are not allowed:
* transfer (op=request)
* delete
(update, renew, and all other transfer sub-commands are allowed). All EPP commands are specified in RFC 5731.

A successful transfer extends the validity period of the transferred domain. The default validity period extension is 1 year but clients may request longer periods in the “transfer op=request” command), between one and 10 years (whole years only; as always, the maximum registration period is capped at 10 years).

1.4 Host Objects

The life cycle of host objects is contained in the response to this question because internal host objects can be affected by transactions on their respective superordinate domain (parent domain). They “follow” the status of their parent domain in order to avoid issues with stale glue records. 

Figure Q27-03 (see attachment) shows the life cycle of internal host objects (comprised of a domain name in the .TLD namespace), and Figure Q27-04 (see attachment) shows the simpler life cycle of an external host object (comprised of a domain name outside the of .TLD namespace). In Figure Q27-03 (see attachment), bold solid lines indicate states and transactions created by transactions on the host object itself, while dotted lines indicate effects on the internal host object that are created indirectly by transactions⁄states on the superordinate domain of the host object.

Internal host objects can only be created when the superordinate domain exists.
When the superordinate domain is deleted within the create grace period, the internal subordinate host is also immediately released.

The description of the individual states of the Host objects is as follows:
* AVAILABLE: The host object does not exist in the Registry, and can be created using the “create host” EPP command.
* REGISTERED: The host object exists, and can be used in domain names in order to refer to the domain name’s name server.

Internal hosts additionally follow the states of their respective superordinate domain as follows (Status values in the list below refer to the status of that domain):

* REGISTERED (PENDING TRANSFER): The host object will be transferred together with the superordinate domain (in case the transfer is completed successfully).
* REDEMPTION: For the redemption period of the superordinate domain, the host object glue will continue to be included in the TLD, even if the superordinate domain is not included in the zone anymore. 
* PENDING DELETE: The glue record will not be included in the DNS anymore. On final deletion of the host object, all references to this host object will be removed too.

More information regarding this process in order to avoid stale glue records is included in response to Question 28 (Abuse Prevention and Mitigation).

1.5 Grace Periods

The following grace periods are supported for domains:
* add grace period: the add grace period lasts 5 calendar days from the date of initial registration. When a domain is deleted in this period, it is immediately deleted and available for re-registration. The registrar is credited for an amount corresponding to the registration fee (unless the registrar is already over its monthly allowance of add grace transactions). A ‘renew’ command ends the add grace period. Note that it is impossible to perform a domain transfer in the add grace period (in fact, the first transfer is only allowed after 60 days of registration). To prevent misuse and domain tasting in particular, a policy applies as to the number of delete requests per month that are refunded during the add grace period (see below). Deletions in the add grace period exceeding this limit are not refunded. 
* transfer grace period: the transfer grace period is currently 5 calendar days following a successfully completed domain transfer. If a domain is deleted in this timeframe, the sponsoring registrar is credited for the amount billed during the domain transfer. The transfer grace period is terminated when a restore, renew or subsequent domain transfer is performed. 
* renew grace period: after each renew command, a 5 calendar day long renew grace period starts. When the domain is deleted in this timeframe, the registrar is credited for the corresponding fee and the domain enters REDEMPTION. A deletion, restoration or approved transfer of a domain immediately ends the renew grace period. 
* auto-renew grace period: every auto-renew is followed by an auto-renew grace period (45 calendar days). If a domain is deleted or transferred within this period the fee for the renewal is refunded to the registrar. However, when a renew command is performed there is no grace period credit any more. 

Refunds for deleting domains during an add grace period will follow ICANN’s Add Grace Period Limits Policy, available at: http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm (including implementation notes). 

The registry system supports the following pending periods in which certain operations are not allowed:
* Redemption Grace Period: consisting of
 * Redemption Period: Whilst in this 30 day period, a domain can be restored after a deletion action (only if domain is not within the add grace period) 
 * Pending Restore: in order to successfully restore a domain in the redemption period, a restore report is required. This report has to be submitted within 7 days of this pending restore period. If no restore report is submitted, a new 30 day long redemption period begins. 
 * Pending Delete: If a domain is deleted and not restored, it is placed into the pending delete period following the redemption period. After 5 days in this period, the domain is finally available for re-registration. 
* Pending Transfer Period: lasts for a maximum of 5 days after the initial transfer request command. The losing registrar has 5 days to approve or reject the request. The requestor may also cancel the transfer within this period. If no action is taken by the losing or gaining registrar, the registry auto-approves the transfer.

This registration life cycle matches the business model of the proposed gTLD. The proposed registry software fully supports this life cycle and the technical resources needed to run a registry based on the life cycle as described are readily available.

1.6 Resourcing

Three staff members of TLD-Box (the “Back-End Registry Operator” of the proposed gTLD) are experts in domain name life cycle, and have designed life cycles for the “.at”, “.bh” TLD, as well as consulted some other TLDs on their domain life cycle. 
All other technical staff members as well as support staff (both at the ʺBack-End Registry Operatorʺ as with the ʺRegistry Operatorʺ) are trained on the operational aspects of the Domain Name Life Cycle. 

There are only minor staff and⁄or infrastructure resources needed for the day to day operations in relation to the domain life cycle itself (since once developed, the resources to run the life cycle come from resources operating the EPP servers). In terms of on-going maintenance, it is expected that about 5 person days per year are required in order to clarify details, corner cases and relations to other business processes of the registry. Those 5 person days are budgeted for in the general maintenance time & resource budget of the registry.

Response to Question 28 Abuse Prevention

1 Overview

Abusive activities during the operation of a gTLD registry system can be categorized as follows:

•Abusive registrations of names under a gTLD.
•Abusive use of a domain name under that TLD („Malicious Use“)
•Abuse of the registration processes, the technical interfaces and infrastructure of the Registry system and the DNS network itself.

Regarding the first (and also parts of the second) category, ICANN’s “RAP” WG (Registration Abuse Policies Working Group) has produced an illustrative categorization of known abuses in their “Registration Abuse Policies Working Group Final Report” (http:⁄⁄gnso.icann.org⁄issues⁄rap⁄rap-wg-final-report-29may10-en.pdf, dated 29 May 2010). 

The anti-abuse measurements of the proposed gTLD registry largely follow the RAPs recommendations for the individual abuse scenarios. More details on the individual countermeasures are included below.
 
Furthermore, the proposed registry does also consider ICANN Security and Stability Advisory Committee’s document “SAC 048” (“SSAC Comment on Orphan Glue Records in the Draft Applicant Guidebook”) as well as “SAC 023” (“Is the WHOIS Service a Source for email Addresses for Spammers?”).

2 General Provisions against Abuse under .brussels

2.1 Legal Safeguards

The Registration Terms & Conditions will contain specific safeguards with regard to abusive registrations under .brussels.

It will allow the registry – upon receipt of appropriate instructions or proof from competent legal or administrative entities – to start up a revoke procedure. If the reported breach of the Registration Terms & Conditions is not remedied within 14 days, the registry will revoke the domain name for which abusive registration has been determined.

Breaches of the Registration Terms & Conditions are the usage of domain names under .brussels:

1°to infringe or otherwise violate the rights of a third party;
2°for an unlawful purpose;
3°in violation of any applicable laws or regulations, such as a name that helps to discriminate on the basis of race, language, sex, religion or political view;
4°is contrary to public order or morality (e.g. obscene or offensive names).

2.2 WHOIS Accuracy Measures

There will be formal verification of registrant data for all applications made during the different stages of the Sunrise Period. The contact data or Whois data of the registrant will have to correspond with the data of the applicant that applied for a certain .brussels domain name and has proved his prior right allowing that party to register the applied for domain name.

As soon as the phase of normal registrations starts, there will be no formal a priori verification of the registrant data.

The applicable Registrant Terms & Conditions will contain the obligation to provide and maintain at all times correct registrant data. The registry will provide an online form that can be used to report inaccurate or false registrant data linked with a specific .brussels domain name. The registry will – if the complaint seems well-founded – start up a revoke procedure for the specific domain name and inform the registrant and his registrar of the inaccuracies in the registrant data. If the registrant fails to correct the registrant data within 14 days, the domain name will be revoked by the registry.

The registry will perform a screening of the newly registered domain names within a 24 hour time frame (on business days) after registration and will identify any domain names whose registrant data seem obviously inaccurate or false. This will be a high level screening and not an in depth verification of all registrant data linked with all new domain name registrations. If registrant data appear to be inaccurate or false at first sight, the data will be closely examined. If the registry estimates that the registrant data are indeed inaccurate or false, it will start up the revoke procedure mentioned above. If the registrant fails to correct the registrant data within 14 days, the domain name will be revoked by the registry. Depending on feasibility in terms of manpower and labor cost, the registry will evaluate whether the screening will not only apply to new registrations but also for all updates of existing registrant contacts that are linked to an active .brussels domain name.

The Registration Terms & Conditions will also explicitly exclude the possibility of so called proxy registrations. These are registrations whereby the identity of the real domain name holder is shielded and replaced by the contact data of the proxy. There might be examples of good usage of proxy services (e.g. protection of privacy) but it is commonly known that proxy services are often used to shield off domain name holders that breach rights of third parties or make malicious use of domain names. Moreover, Registry Operator will make a distinction between domain names registered by entities en those of private individuals. The contact data for private registrants will be in the registry database but not accessible through whois services. This also means that private registrants do not need to make use of proxy services in order to protect their privacy. 

3 Abuse Contact and Abuse Handling Provisions

The .brussels Registry Operator establishes and publishes on his website a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the .brussels gTLD through all registrars of record, including those involving a reseller.

The contact information of the abuse contact will consist of:

•an e-mail address
•a phone number
•the postal address of the abuse contact (premises of the registry operator)

Communication submitted to the abuse contact will be handled as follows: 

All reported abuses will have to be deposited in written form through usage of a specific complaint⁄report form. Even in the case of a telephone exchange with the abuse point of contact, this contact will need to be followed up by a formal deposit through the complaint⁄report form.

All deposited abuses will be reviewed internally by competent administrative, paralegal or legal staff. Spam messages and other non-relevant reports will be discarded immediately. Non-applicable or ill-founded complaints or requests will be provided a short answer with – to the extent possible – advise on how the complaint or request can be validated. For this type of incoming reports the registry estimates that a reply (on business days) can be rendered within 24 hours after deposit of the complaint or request.

For validated complaints⁄requests a case file number will be opened and a formal enquiry will take place. Competent staff will review the allegations and deposited documents, identify the specific domain name and responsible registrar, contact the registrar and competent legal or administrative instances for as much as necessary and provide a first response to requestor. 

If the abuse report emanates from legal or administrative entities and is provided with corresponding legal documents e.g. court order, the registry will respond and start the appropriate procedure within 24 hours (on business days) after the report. 

If the abuse report emanates from other stakeholders, the registry cannot commit to a specific time frame since the registry itself will have to transmit the reported elements to the competent legal or administrative entity for examination. The registry will however proceed with the procedure (providing answer to the requestor or start specific procedure) within 24 hours (on business days) after having received a valid and clear instruction from the contacted legal or administrative entity.

4 Potential Registration Abuse Categories and Countermeasures

As outlined above ICANN’s RAPWG has identified a number of potential abuse categories (see chapter 5 of their document). These correspond to the first bullet point of the potential abuses of a Registry as listed above (“Abusive Registrations”). The proposed registry system addresses these individual categories as follows:

4.1 Cybersquatting

Abuses from cybersquatting cases in the proposed gTLD will be addressed by an Alternative Dispute Resolution (ADR) procedure that is entirely based on ICANN’s existing and well know Uniform Dispute Resolution Process (“UDRP”). However, registry staff will also closely follow developments regarding Rights Protection Mechanisms within ICANN, and will investigate potential paths towards adoption of such processes once they are clearly defined for the gTLD registry space.

4.2 Front-Running

Even though the RAP does not recommend any specific action regarding this issue, the proposed registry will treat log files and other information that reflects user interests in a certain domain name confidential. Such data and log information will only be available to staff with actual requirements to access those files for operational purposes.

4.3 Gripe Sites; Deceptive and Offensive Domain Names

In line with the RAP WG recommendation, the proposed gTLD registry will not develop best practices to restrict the registration of offensive strings. It is believed that the existing UDRP, in addition to court decisions (which the registry will obviously oblige to) allows for neutral and sufficient action against such potentially abusive names.

The registry does not exclude the possibility that the stakeholders of the community which .brussels is to serve, can establish an exclusion list of domain names that may not be registered. Such exclusion list will be established before the start of the Sunrise Period and will be publicly available. 

4.4 Fake Renewal Notices

The registry will – in line with the RAPs recommendation – not implement any specific countermeasure on the registry side, since this is believed to be an issue that cannot be solved on this level as long as the registry is also required to provide accurate and complete WHOIS information for domain names (which is believed to be the source for such notices). It is expected that ICANN monitors this issue, and takes respective countermeasures against registrars following such practices.
The registry will, however, post warnings on their website about clearly fraudulent (and clearly illegal) renewal and expiration notices of which its staff becomes aware, and will take legal measures against registrars performing such illegal and fraudulent acts.

4.5 Name Spinning

This practice is considered a tool that is mostly used by registrars in a legitimate way to offer users more choice and⁄or alternatives should their desired name already be taken. As such, it is believed that it is within the registrar’s responsibility to use those techniques in a considerate way. The registry cannot even differentiate between a name that the user has manually entered, or a name that was “spun” by the registrar.
In case that name spinning would lead to trademark infringements in a domain name, the UDRP allows for taking appropriate action against the holder of such a name.
This follows the RAP’s recommendation.

4.6 Pay-Per-Click

In agreement with the RAP point of view, this is considered a pure web issue, and not an issue of the registration of a certain name. In most cases, pay-per-click is a legitimate revenue source for domain name owners ⁄ web site operators. Any potential misuse of such practices is out of scope of the Registry – trademark cases are expected to be brought up using the UDRP.

4.7 Traffic Diversion

In line with the RAP point of view, this is a web issue, and no measures against it are performed or considered for the registry operations.

4.8 Domain Kiting ⁄ Tasting

In order to prevent mass domain kiting ⁄ tasting (as it was observable in gTLD and ccTLD registries), the Registry will implement the “Add Grace Period Limits Policy” (http:⁄⁄www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm), which efficiently removes the financial advantage of domain kiting ⁄ tasting, and hence significantly reduces the volume of such registrations. All registrars will obviously be treated identically, and no exemptions from that policy will be made.

5 Abusive Use of a Domain Name

The malicious use of domain names is a complex issue and often puts a Registry Operator in an uneasy position. It is beyond doubt that the malicious usage of domain names in a TLD has a detrimental influence on the reliability, quality and attraction of that TLD and is to be avoided as much as possible. However, it should also be noted that the malicious use is often linked with the content of a website connected with the domain name. Even if the content of the website is of illegal nature or constitutes an offence or crime, it is beyond the competence of a Registry Operator to evaluate this behavior in the same way as a magistrate of a competent court of law would be able to do.

If a Registry Operator acts upon notices of abusive usage of domain names, it should realize that it is only a question of time before it will be held liable for its actions and interventions. As a Registry Operator working on a not-for-profit base, DNS.be cannot afford to step in and make unsound judgments leading towards questionable decisions and potential damage for domain name holders. Therefore, in dealing with abusive registrations, Registry Operator makes a distinction between the following situations.

5.1 Requests from law enforcement agencies

Registry Operator has already a procedure in place (for .be operations) in order to deal with requests from law enforcement agencies. Requests from law enforcement agencies for blocking or deleting of domain names are carried out within 24 hours after notice for as much as the request is signed by an appropriated magistrate. If the request is not supported by signature of a magistrate, Registry Operator will not proceed with the request but will inform law enforcement contacts that the proper procedures should be followed. If the request is indeed signed by the competent magistrate, Registry Operator will in any case proceed with the request and execute it. 

5.2 Execution of court decisions

Often a party previously involved in a law suit concerning a domain name, will approach the Registry Operator in order to have a domain name transferred or deleted. Registry Operator will advise that parties involved in a law suit should first engage for a voluntary execution of the court’s decision. If a party can point out that the other party refuses to execute the court’s decision and therefore leaving the case unsolved despite of the legal ruling, Registry Operator will intervene and execute the decision by having the domain name transferred to the requestor or deleted accordingly.
The procedure above is in principle limited to decisions made by the Belgian courts. However, Registry Operator is prepared to examine if a similar approach can be followed for decisions by foreign courts. However, much will depend of the specific circumstances of each case.

5.3 Notice and take down procedure

Registry Operator wants to address specific attention towards malicious use of domain names which could be evaluated with the assistance of certain government entities or public services. Obvious cases of malicious usage are: the offer of counterfeited goods, illegal gambling sites, economical fraud and breaches of e-commerce regulations, breaches of tax regulations, sale of fake medicines, phishing and identity theft etc. In most of these cases specific government entities or public services have the authority to assess the situation, evaluate whether applicable legislation has been breached or not, propose appropriate action and sanction the offender. 
Registry Operator is currently examining, together with relevant government entities, how these issues could best be addressed. A workable solution would be that Registry Operator and relevant government entities or public services sign an agreement for cooperation with reciprocal tasks for either party. The government partners would provide the assessment if a reported case is actually to be qualified as abusive or malicious use of a domain name. The Registry Operator would commit to act upon request from government partners and proceed with suspension or taking down of domain names. Liability for Registry Operator would be limited in as much as the agreed procedure are integrated in the Registration Terms & Conditions. 

6 Registry Interfaces Abuse

The registry will employ the following countermeasures against abuse of the registry system and the DNS network itself:

6.1 WHOIS data harvesting

WHOIS access is a critical and vital functionality of any gTLD registry, and the Registry will obviously comply to ICANN’s requirements for WHOIS access.

However, as indicated in SSAC’s document “Is the WHOIS Service a Source for email Addresses for Spammers?”, WHOIS abuse can be considered as one of the primary sources for email addresses for unsolicited email, particularly mass harvesting of WHOIS information. It is also believed that WHOIS constitutes the major source of data for fake renewal notices. As a countermeasure against harvesting of registration data (and particularly, email addresses), the registry will employ the following countermeasures:

•WHOIS query rate limits: Access to whois data will be query rate limited on a per-IP-address basis (for IPv4) and a per-prefix basis (for IPv6), with a daily limit of 25 WHOIS queries per IP address⁄prefix. Once the limit is reached, the WHOIS server responds with a respective notification instead of the actual answer (The query limit may be reviewed and adapted by the Registry operator from time to time). IP-Ranges of accredited registrars (and other IP-ranges, eg. ICANN itself, UDRP and URS service providers) will be excluded from that rate limiting measure. While this will still allow legitimate queries to the service, it will effectively make it very hard to harvest data on a broad scale.

•Email⁄Phone⁄Fax privacy: The EPP implementation of the “contact” contains an mechanism that allows a registrar to define whether or not the “email”, “phone”, “fax” field of contact information shall be publicly disclosed or not (“contact:disclose” element). The registry will set these fields to “do not disclose” by default, however, registrars can modify this default setting via the normal EPP command stream. When a flag for a certain field is set to “do not disclose”, the respective field will be omitted from anonymous WHOIS outputs, providing a minimum level of privacy to registrants. To allow for various business processes, IP Ranges of accredited registrars (and other IP-ranges as needed, eg. ICANN itself, UDRP and URS service providers) will still see the full data set, including the fields marked as “do not disclose”.
The implementation mentioned above will have to be examined with the existing privacy legislation which is applicable throughout the European Union. A basic principle in European Privacy Law is the right for a private individual (in this case referring to a private person registrant) to request the omission of his personal data of information services such as Whois. The registry will be based in EU territory and will be obliged to align its policies with applicable domestic and EU legal requirements. 

•WHOIS monitoring: The WHOIS service will be monitored in order to identify unusual activity on the interface

The countermeasures above provide a well-balanced compromise between the requirements on access to WHOIS data and basic data protection for registrants. More information about the WHOIS service provided by the registry is contained in response to Question 26.

6.2 EPP Interface Abuse

As described in the answers to the SRS and security questions (Question 25 and 30, respectively), the EPP interfaces of the Registry are heavily firewalled, only accessible from IP-ranges of accredited registrar, and protected by EPP authentication. As such, abuse of those interfaces (such as DDoS, brute-force attacks against username⁄password combinations) can only be performed from networks of parties with whom the Registry Operator has a legal agreement. Additionally, EPP interfaces are rate-limited on the network layer.

Registrars that are found abusing the EPP interface and causing harm or nuisance to the technical operations of the registry, will be revoked as registrar. The registrar agreement will contain specific clauses regarding abuse of EPP interface and other technical systems of the registry. Noted abuses will in that context be regarded as breach of contract by the registrar and can lead towards termination of the contract. 

6.3 DNS Interface Abuse

Public name servers, hidden masters and the signing infrastructure is configured and firewalled so that they allow NOTIFYs and UPDATEs from the required addresses only. In order to prevent zone walking and load peaks, zone transfers from the DNS infrastructure is disallowed (and disabled). 

7 Management and removal of orphan glue records

It is understood, that inline with the SSAC’s comments in http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf, glue records have a vital function in the correct and ordinary operation of the DNS, but can be used for malicious purposes. 
In order to prevent such malicious purpose, the registry performs management of glue records according to the following policy:

•Provisioning of host objects with glue: In line with the EPP RFCs, glue record (“internal”) host objects can only be provisioned when the superordinate (parent) domain name exists in the registry. Host objects that are not under the TLD managed by the registry (“external hosts”) can never have A or AAAA records

•Deletion of domain with subordinate glue record hosts: When a domain name transitions from “REGISTERED” into the “REDEMPTION” status (for example, via the EPP “delete domain” command, or via expiration), the domain name itself is removed from the DNS, but any glue records under the deleted domain that are still in use for other delegations are kept in the zone for now. Other registrars who are affected by a potential reduction of the DNS reachability due to the upcoming removal of the host from their domains receive a respective notification via the EPP message queue. 

•Subsequently, when the domain name continues transition from “REDEMPTION” into “PENDING DELETE”, the glue records under the affected domain name are revoked from the DNS, but still exist in the SRS database.

•In the last step of deletion (transition from “PENDING DELETE” to “AVAILABLE”), the glue record host objects are deleted together with the domain, and are also removed from any other domain name in the registry that still uses those hosts.
This policy effectively prevents misuse of orphan glue records in the registry, since the status of a host object always follows the status of the superordinate domain, and glue records can never exist for domains that are not in the registry database. Additionally, keeping the glue records in the zone during the redemption period together with the notification significantly reduces the risk of other domains becoming less reachable (or unreachable), and reduces the effort required from a registrar in case such a domain gets restored. 

However, in addition to this procedural policy outlined above, the registry operator will also act on evidence in written form that glue is present in connection with malicious conduct, and will subsequently remove such glue manually.

8 Resourcing Plan

8.1 CERT.at is a department of the backend provider

Note that the Austrian CERT (Computer Security Emergency Response Team), staffed with 5 full-time-equivalents is a department of nic.at, and shares offices with the registry operations team. Hence, world class security and anti-abuse competence is available, literally „next door“, to the registry operations centre.

8.2 DNS.be staff available for .brussels

The registry for .brussels will share its premises with DNS.be, the registry operator for .be. DNS.be disposes of sufficiently trained and experienced staff (total head count of 22) that will also be deployed for .brussels operations. 

DNS.be has integrated an increase in staff resources in its business plan and budget outlook in order to provide maximum support for the gTLD’s it will have under its care. Additions in staff resources will also be deployed for the administrative, legal and regulatory units and thus for handling of incoming complaints, reports of abuses or relevant questions concerning those topics. 

Response to Question 29 Rights Protection Mechanisms

As required by specification 7 of the new gTLD Agreement, Registry Operator will implement and adhere to any right protection mechanisms (ʺRPMsʺ) that are mandated by ICANN. 

Registry Operator will deploy all necessary means to be fully compliant with the existing UDRP for gTLDʹs. To the extent possible, Registry Operator would like to add certain features to the existing UDRP in order to enhance the protection for right holders. The enhanced protection concerns: the use of local languages for UDRP, reimbursement of UDRP fees, cost effective and efficient procedures at the startup of UDRP and a broad scope of protected rights under the UDRP.

Registry Operator will comply with PDDRP, RRDRP (insofar applicable) and URS procedures, and will implement and adhere to the remedies ICANN imposes via those processes.

Registry Operator will implement the required RPMs described in the Trademark Clearinghouse function (once adopted by ICANN), and understands that ICANN may revise such requirements from time to time. Registry Operator will not mandate that owners of applicable intellectual property rights have to use any other trademark information aggregation, notification or validation service in addition or instead of the ICANN-designated Trademark Clearing House. Registry Operator will also deploy a multi-phased Sunrise Period in order to allow trademark holders and various other right holders to protect their rights and to register .brussels domain names matching those rights. 

All the mandated and independently developed right protection mechanisms will be included in the registration policy terms & conditions for registrants and in the registry-registrar agreement (where needed) for the TLD. 

Registry Operator will also take reasonable steps to investigate and response to any reports from law enforcement, governmental and quasi-governmental agencies of illegal conduct under the TLD, and understands that Operator will not be required to take any action that contradicts applicable law.

The Registry Operator will put measures in place on a continuous basis whereby the rights and legitimate interest of third parties are safeguarded. Details about the implementation of the various right protection mechanisms are included below.

a) Sunrise Period and Trademark Claims services 

The Registry Operator will organize the following Sunrise services and Trademark Claims services at the start of the registration process. 

1) Sunrise Services

The Registry Operator will implement a Sunrise process, whereby holders of trademarks and certain other rights will be entitled to safeguard the domain names that are identical to the name(s) to which they hold rights.

Prior to the start of normal registrations based upon the ʺfirst come, first servedʺ principle, there will be a multi-phased Sunrise Period. During the first phase of the Sunrise Period holders of (national and European) established trademarks, governmental entities seeking to protect their geographical or social name and entities disposing of a protected designation of origin or geographical indication, will be able to apply for the domain name corresponding to the rights they wish to claim. During the second phase of the Sunrise Period registrants will be able to apply for domain names corresponding with their trade name or company name. Finally, it is also under consideration and subject to further decisions in cooperation with the Government of the Brussels Region, to provide a 3rd Sunrise phase during which private individuals would be allowed to apply for the domain name corresponding with their family name. In all phases of the Sunrise Period, applicants will have to substantiate the applied for domain names with legal proof of the rights they wish to claim. The invoked rights will need to match exactly with the domain name for which the application is introduced and all applications will be validated by an independent reviewer that will perform that function under contract awarded by the Applicant. Holders of trademarks can make use of the services of the Trademark Clearing House and would in that case not need to have their applications validated. Trademark holders that do not want to make use of the Trademark Clearing House may of course also choose to apply directly and have their trademark rights validated by the independent reviewer. Sunrise applications will receive a time stamp and will be validated in chronological order as far as the applicant manages to accompany his application with the required legal proof for the right he wishes to invoke. 

Registry Operator estimates that the total Sunrise Period will span a period of 4 months. During the first 2 months only applicants with phase 1 type of rights will be able to file an application. After this initial phase applicants with phase 2 type of rights will be able to introduce their applications for a period of 2 months. During the last month of this second period, also applicants with phase 3 type of rights would be allowed to introduce applications. Applicants with phase 1 type of rights would be able to introduce their applications during the second period but have to realize that their rights will coincide with those of phase 2 type of right holders (during first month of second period) and even those of phase 3 type of right holders (during second month of second period). Also, applicants with rights typical for phase 2 should be aware of the risk for coincidence with the rights applicants wish to claim in phase 3 during the last month of the Sunrise Period.

Registry Operator will provide a technical platform for the introduction of the applications in the different phases and for the upload of legal proof for the invoked rights. Validation of applications could be prepared by legal staff of the Registry Operator but the ultimate validation decision will be made by an independent reviewer and not by Registry Operator nor members of its staff. Registry Operator will launch a request for proposals in order to select an independent reviewer who will be awarded a contract for the validation process. 
 
2) Trademark Claims (Trademark Clearing House)

It is understood that - according to the Trademark Clearing House definition draft dated April 15, 2011 - ICANN is going to define a Trademark Clearinghouse provider who will in turn supply two primary functions (see Section 1.2 of the draft), of which function (ii) (ʺserving as a database to provide information to new gTLDsʺ) will be directly relevant to the operation of this TLD.

It is also understood that ICANNʹs work towards the establishment of such a Trademark Clearinghouse is still in progress. Therefore, it is not yet possible to describe the process by which the Registry will support the Trademark Clearinghouse requirements.

The Registry Operator will, however, implement any reasonable measures and processes that are required by the Trademark Clearinghouse function and the Trademark Claims service.

The Registry Operator will implement the processes of the Trademark Clearinghouse and the Trademark Claims service for at least the duration indicated in ICANNʹs Applicant Guidebook and may even have this process in place for a longer term. In any event will this process remain in place for the whole period of the different Sunrise phases.

b) Safeguard against violation of the TLDs eligibility restrictions

After the various phases of the Sunrise Period as described above, the TLD will be opened up for registrations on ʺfirst come, first servedʺ base. Although Registry Operator and the Government of the Brussels Region still have to decide on the eligibility criteria, it is anticipated that the TLD will be open for registrants worldwide and that no specific link with the Brussels Region will be required from registrants. 

Nevertheless, Registry Operator will put in place a number of safeguards against violation of the eligibility criteria. Domain names that are excluded for registration (in case exclusion list would be established) or that not match the technical eligibility standards (not supported IDN scripts or characters, more than 63 characters, ...) will be automatically rejected by the technical registration system. Registry Operator will also perform a screening of all newly registered domain names and will undertake a high level verification of whois contact information. Specific details concerning the efforts that will be made with regard to accuracy of whois data and consequences for domain name holders that provide inaccurate or fraudulent data are answered in question 28. It is to be noted that the specific procedures used to deal with inaccurate or false whois data are also of use in combatting abuses such as phishing and pharming. Registry Operator is already linked with several mailing lists in order to be alerted for phishing, pharming and other abuses involving .be domain names. If domain names are identified in that perspective, Registry Operator immediately proceeds with an in depth verification of the whois contact information of the registrant. In nearly all known cases registrants using domain names for abusive practices such as phishing will not link valid contact data with the registered domain name. In those cases a specific ʺbad whoisʺ procedure is initiated against the domain name holder whereby the domain name is immediately removed from the zone file in order to disable a linked website. In case the registrant data are not updated, the domain name is ultimately deleted at the end of the procedure. It is the intention of Registry Operator to use this procedure also for the .brussels domain names.

Registry Operator will also work together with law enforcement agencies and government entities that report abusive usage of domain names under the TLD. More detail is provided in section g) below.

The verification of eligibility criteria, screening of whois data and cooperation with law enforcement and government will be managed by paralegal and legal staff of Registry Operator. The current staff is already performing those functions for the .be ccTLD and will expand their tasks for the .brussels TLD. 
 
c) Uniform Dispute Resolution Procedures (UDRP) Support

It is understood that ICANNʹs Uniform Dispute Resolution Process mostly concerns registrars. Hence, the Registry Operator does not need to implement any specific process in order to support the UDRP specifically. However, Registry Operator will support registrars in case of UDRP cases around their domain names under the TLD, and will cooperate with approved Dispute Resolution Service Providers in order to assist in their work. Registry Operator is able in that context to provide a secure access to its technical platform allowing a UDRP provider for instance to ʺlockʺ domain names that become subject to a UDRP filing.

As stated above, Registry Operator would like to add certain features to the existing UDRP in order to enhance the protection for right holders and make provisions so that parties can proceed with UDRP in French or Dutch in addition to English. Since .brussels is matching with the territory of the Brussels Region (the part of Belgium with official bilingual (French⁄Dutch) status), it is imperative that the local languages can be offered as procedural language for the UDRP. Furthermore, Registry Operator would also like to implement two additional features that are used for the UDRP process for .be domain names: a reconciliation phase and UDRP fee reimbursement for successful complainants. Often a domain name holder offers to transfer ownership of a domain name once the UDRP procedure has been initiated. In order to avoid unnecessary costs and loss of valuable time, Registry Operator would like to implement a reconciliation phase at the start of the UDRP procedure. If the domain name holder is willing to give up the domain name, the procedure can be kept as short and efficient as possible. Secondly, Registry Operator has been working (for the .be ccTLD) with the principle that a successful complainant is reimbursed for the costs of the UDRP fees he had to pay and that those costs are charged back by Registry Operator from the domain name holder that was held responsible for breaching the rights of complainant. It is a fair compensation for the complainant and helps making UDRP accessible for a broad range of right holders. It is also working positively towards the avoidance of cybersquatting since such behavior might not only lead towards the loss of the domain name but also impose additional costs for the UDRP on behalf of the former holder of the domain name involved. Finally, Registry Operator wants to see the scope for the UDRP broader than only trademarks and related rights. Under the UDRP for .be also geographical names, trade names, company names, names of origin and personal⁄family names are protected. We would like to extend that level of protection also for .brussels. 
 
d) Uniform Rapid Suspension (URS) Support

The Registry Operator will comply with ICANNʹs requirements regarding the Uniform Rapid Suspension (URS) process, and understands that the following services are required (and will be provided) during the operation of the TLD:
- Contact Information: Registry Operator will provide email and other contact information to accredited URS Providers so that Notices and other communication regarding URS cases can be communicated efficiently.
- Notice and Locking of a Domain: Upon receipt of a respective Notice from an accredited URS Provider, Registry Operator will ʺlockʺ the affected domain name within 24 hours by means of putting it into the DISPUTE status. This means that modifications (including transfers) on the domain name and registration data will be rejected, but the name will still resolve in the DNS. Registry Operator will immediately notify URS Provider upon locking the domain.
- Remedies: In order for the URS Provider to implement the Remedy, Registry Operator will subsequently modify the registration (for example, by changing name servers to the URS Providerʹs own hosts), or removed the ʺlockʺ status on the domain, or implement other measures, as instructed by the URS Provider.
- Extend Registration: Registry Operator will support successful Complainants if they wish to extend the registration period for one year at commercial rates.
Registry Operator wishes to note that authentication of URS Providers is a critical issue, since Notices and other instructions may be sent via email to Registry Operator, and email itself does not provide any means of authentication. Hence, additional measure such as cryptographically signing such emails is deemed necessary in order to identify a Notice as authentic, and subsequently authorize requests to the Registry Operator.
URS Providers will dispose of a specific interface giving access to the technical platform of the registry and allowing them to lock a domain name for which the URS procedure has been activated. This access will be granted after signing an agreement with the registry.
If the URS Provider does not want to sign an agreement (or in the event such an agreement would not be established) with the registry, he must submit the Notice to a dedicated e-mail account with the registry (e.g. legal@nic.brussels) and the appropriate support division will take the necessary action to lock the domain name within 24 hours after receipt of the Notice. It is to be noted however, that in such case receipts will only be treated during working days and business hours.

e) Post-Delegation Dispute Resolution Procedure (PDDRP)

The Registry Operator agrees to participate in the procedures required by the Post-Delegation Dispute Resolution Procedure, and be bound to all determinations that are the result of said procedure. The process implemented by the Registry Operator for actual complaints will be as follows:
- Once a Complaint is received electronically or in paper notice form from the Provider, Registry Operator will verify the content requirements of the Complaint, according to section 7.2 of the current PDDRP specification (dated Sep 19 2011). The Complaint will be reviewed by legal staff of the Registry Operator.
- The Registry Operator will notify the Provider about the receipt of a complaint.
- If deemed necessary, the Registry Operator will submit papers within 10 days of receipt of the Complaint.
- Registry Operator will subsequently follow the process regarding implementation of the remedies, as described in the PDDRP specification.

f) Registration Restriction Dispute Resolution Policy (RRDRP)

The Registry Operator also agrees to participate in the procedures required by the Registration Restriction Dispute Resolution Policy, and be bound to the determinations that are the result of said procedure, in accordance to Section 2a of Specification 7 of the New gTLD Agreement. The actual administrative steps for handling Complaints based on the RRDRP will be identically process-wise to the PDDRP process described above.

g) Other Reports

Other reports need to be addressed to the usual support contact with the registry. Any such notices will immediately be transferred to paralegal or legal staff that will examine the report and verify which action can⁄needs to be taken in conformity with the applicable Registration Terms & Conditions.

1) Dispute-related technical functionality in the Registry System

In order to handle any disputes concerning a domain in the .brussels TLD according to the RPMs defined, the Registry Administation Panel includes functionality to manually put domains into the ʺDISPUTEʺ status (see Answer to question 27 - Registration Lifecycle). The dispute related functions base on more than 12 years of experience in managing disputes under the ʺ.atʺ TLD, and provides the following functionality:
- Search for domain names and display WHOIS as well as registrar data
- For each domain, the following tasks can be performed:
 - Delete the domain immediately (domain immediately enters PENDINGDELETE state and thus cannot be restored by a registrar)
 - Put the domain into the DISPUTE state (which prevents modifications and transfers on the domain name, and also prevents modifications on the associated registrant contact).
 - Add the ʺserverHoldʺ status to domain names under DISPUTE (so that the name is excluded from the DNS, and hence technically disabled),
 - Remove the ʺserver Holdʺ status from a domain
 - Change back domain names in DISPUTE to their previous state (most commonly, ACTIVE).
 - For each action, the system allows for selecting one of several ʺreasonsʺ to record with the action.
 - An additional free-form text box allows for recording additional information, such as pointers to external documents, or case numbers.
- List all domain names in DISPUTE status
- Display data, reasons, and additional information of domains under DISPUTE
- Display historical data about such cases

2) Request from law enforcement agencies and government entities

Registry Operator has already a number of procedures in place (for .be operations) in order to deal with requests from law enforcement agencies and government entities: 
- Requests from law enforcement agencies for blocking or deleting of domain names are carried out within 24 hours after notice for as much as the request is signed by an appropriated magistrate.
- Requests for disclosure of whois contact data for domain names from private holders introduced by law enforcement, government entities or lawyers are examined and answered within 24 hours provided that the requestor has used the correct webform and has sufficient legal grounds.
- Reports and complaints concerning abusive use of domain names (based on content of webpage linked to it) are examined in view of the abuse policy and notice and action policy documents and appropriate action is taken. 

Registry Operator intends to deploy the same procedures in order to assist requests and complaints from law enforcement agencies and governmental entities related to the operations for the .brussels TLD.

h) Resourcing plan for implementation and ongoing maintenance

As indicated above, a number of tasks will be carried out by professionals that are not belonging to the staff of the Registry Operator. This concerns mainly the validation of Sunrise applications, the function of the Trademark Clearing House and the tasks to be performed by UDRP and URS Providers. All other tasks will be carried out by support, paralegal and legal staff from the Registry Operator. Currently, those tasks are already being carried out for the .be ccTLD by a team of 5 full time equivalents (FTE). It is the intention of Registry Operator to expand the tasks of these already experienced and skilled staff members in order to include the .brussels operations. If and when necessary, due to the multiplication of the workload, additional staff members will be hired and trained. 

Basic functionality regarding rights protections mechanisms (domain locking, tracking of requests) is already implemented in the registry core system, hence no further resources are needed for this initial implementation.

However, it is understood that resources are necessary to implement further measures that require technical interaction with the registry system, as soon as they are clearly defined (especially the trademark clearing house process and sunrise). The implementation effort cannot be foreseen at the time of writing, hence the concrete resourcing plan for the technical part of the implementation and ongoing maintenance cannot be provided. However, the Registry Operator is aware of the fact that during Landrush and Sunrise more resources will be allocated to handle the increased load on the day to day operations as well performing necessary changes on the system after completion of Sunrise and Landrush if instructed by ICANN rules to do so.

Still, the Registry Operator will implement any reasonable measures and processes that are required by ICANN in respect to rights protection and resources will be allocated accordingly to have the functionality available for the operation of the registry. 

Response to Question 30a (Security Policy)

1. Registry Policy Framework
----------------------------

The Information Security Management System was developed in accordance with the international standard ISO 27001 and the Back-End Registry Operator is currently on the ISO 27001 certification path for the Information Security Management System (ISMS) to be completed before launching the registry. For the secondary datacenter in Salzburg the certification will be completed in 2012 and the primary datacenter in Vienna is already certified – please find ISO 27001 certification document in attachment 30a-06.

1.1. Back-End Registry Operator Security Organization

The role of the Chief Information Security Officer (CISO) is defined in the organization operating the Back-End Registry, and is staffed with an FTE. This person is responsible for the setup, operation and continuous improvement of the Information Security Management System and Business Continuity Management System. 

In the organization chart the CISO is located directly below senior management. This role is independent of operational management and directly reports to the upper management of the Back-End Registry Operator who in turn reports to the registry operatorʹs management. The CISO advises the management on all security related issues.

1.1.1. Information Security Management System (ISMS):

The ISO 27001 based ISMS supports and facilitates management in achieving the goals defined in the Corporate Security Policy and Security Standard. The ISMS as shown in diagram Q30a-01 provides the Deming - cycle (plan-do-check-act) in security concerns as referred to in ISO 27001.

The Security Policy Framework and Security Standard have a review cycle of a maximum of 1 year. The CISO is responsible for adhering to this review cycle.

1.1.2. Business Continuity Management System (BCMS)

Please find further details on BCMS in response to question 39.

2. Corporate Security Policy
----------------------------

The Corporate Security Policy is understood as the commitment by upper management to support and maintain information and IT security.

The main items are:

* The overall goal of these activities is to prevent security incidents and to minimize their impact.
* Prevention before damage reduction; personal responsibility and awareness before surveillance of employees.
* Information security and IT security are important quality metrics for the registry.
* Information security and IT security are core competences of the registry.
* Safeguarding the integrity and availability of the gTLDs Domain Name System
* In the event of a Security incident to minimize any potential damage. 

3 Corporate Security Standard
-----------------------------

The Corporate Security Standard, based on ISO 27001, defines the areas of responsibility for information - and IT security:

* IT Risk Management
* Continuous Improvement Process
* Audit Management
* IT Asset Management
* Information Classification and Processing
* IT Change Management
* Identity and Access Management
* Personal Management
* Security Incident Management
* IT Project Management
* IT Patch and Update Management
* Backup and Recovery
* Logging and Monitoring
* Spam and Antivirus
* Mobile Devices
* Media Disposal
* Network Security
* Physical Security
* External Suppliers

These areas will be discussed in more detail in the following sections.

3.1 IT Risk Management

Diagram Q30a-2 describes the risk management process in use at the registry.

The evaluation of risks is performed according to 4 different category types: 

* Finance: assesses any potential financial impact on the registry.
* Operating Tasks: assesses the influence on the main business processes or tasks of the registry.
* Corporate Image: assesses the effects of reputational damage or loss of trust in the registry.
* Compliance: assesses impact of contractual or legal damages.

The risks are evaluated and categorized into the following severity levels:

* Critical
* High
* Medium
* Low

The risks are further measured by their estimated frequency of occurrence:

* Very high probability: 1 per month or more frequently
* High probability: 1 per year
* Possible: every 10 years
* Highly unlikely: every 100 years
* Impossible: risk is not relevant (for example avalanches in Vienna)

The risk assessment is performed using the Delphi technique and involves management, the CISO and the head of IT. Within each category the worst cases are rated as the most important ones.

Aspects of risk management are also used for the vulnerability management.

ISO27001
Domain Name
6 Organization of information security
6.1 Internal organization
6.2 External parties
12 Information systems acquisition, development and maintenance
12.6 Technical vulnerability management

3.2 Continuous Improvement Process

The continuous improvement process is risk-management oriented, and shown in Figure Q30a-03: Continuous Improvement process. 

Regular organizational meetings are set up to trigger the process:

* IT security update: 
 * Participants: Head of IT, CISO
 * Topics: Operational tasks
 * Frequency: At least every 2 weeks
* Security jour fixe: 
 * Participants: CTO, CISO, optional head of IT
 * Topics: Planning, monitoring of projects, tasks, countermeasures
 * Frequency: At least every month
* Management security jour fixe: 
 * Participants: CEO, CTO, CISO, optional head of IT
 * Topics: Risk management, large scale management decisions

The management review has to take place at least once per year or as needed in the event that a potential risk arises.

3.3 Audit Management

The planning of all audit work including technical audits such as penetration tests and vulnerability scans is managed by the CISO.

Different kinds of technical security audits are accomplished:

* Regular basis
 * Vulnerability scans on systems at operating system level to identify problems in patch management or configuration processes
 * Penetration tests are executed by third party security consultants to identify design issues, organizational deficits or other security issues. The focus of the penetration tests is varied every year.
 * Web vulnerability scans (OWASP Top 10) are performed against all internal and external websites
* Prior to the launch of a new system:
 * Penetration testing of all business critical system elements
 * Vulnerability scans on the system at an operating system level
 * Web vulnerability scan (if the system is web-based)

ISO27001
Domain Name
6 Organization of information security
6.1 Internal organization
6.2 External parties
15 Compliance
15.1 Compliance with legal requirements
15.2 Compliance with security policies and standards, and technical compliance
15.3 Information systems audit considerations

3.4 IT Asset Management

All assets and their life cycles are fully documented. Assets are categorized as follows:

* Physical assets
* Software assets
* Information assets

ISO27001
Domain Name
7 Asset Management 
7.1 Responsibility for assets
7.2 Information classification
8 Human resource security
8.3 Termination or change of employment

3.5 Information Classification

All information is classified into the following categories:

* Public: For example data on public websites
* Internal: For example general company information
* Confidential: For example annual business reports before publication
* Highly confidential: For example person specific data, penetration testing reports

The data classification policy defines how to store, transmit and share these different kinds of information.

ISO27001
Domain Name
7 Asset management
7.1 Responsibility of assets
7.2 Information classification 
10 Communications and operations management
10.7 Media handling
10.8 Exchange of information
12 Information systems acquisition, development and maintenance
12.3 Cryptographic controls
15 Compliance
15.1 Compliance with legal requirements

3.6 IT Change Management

IT change management ensures that all modifications to IT systems can be reproduced, fulfill the organizational needs and are documented. Changes are categorized into following groups:

* Changes without approval
 * Below low risk
 * Implemented within 1 week
* Standard change
 * Low risk
 * Implemented within 1 month
* Emergency change
 * If availability of a service is dependent on a specific change
 * Has to be done as soon as possible
 * Canʹt be scheduled any more
 * Escalation to management is required

ISO27001
Domain Name
10 Communications and operations management
10.1 Operational procedures and responsibilities
12 Information systems acquisition, development and maintenance
12.6 Security in development and support processes

3.7 Identity and Access Management

All user rights are based on the ʺleast privilegeʺ and ʺneed to knowʺ principle. Roles are used to group the relevant user permissions where appropriate.

User accounts are personal accounts meaning that they identify one specific person. Group or role accounts are non-standard and have to be approved in writing by the CISO.

Administrative accounts have to be approved by the head of IT in writing. There are stronger policies, for example password policies.

External accounts (for third parties) also need written approval by the CISO. These types of accounts are deactivated after 30 days.

External administrative accounts need written approval by the head of IT and the CISO. Such accounts are subject to increased monitoring and logging. These types of accounts are also deactivated after 30 days by default.

If an employee leaves the company, his⁄her account is deactivated immediately. 

Inactive accounts are deleted after 60 days.

At least once a year there is a review of the accounts structure and user rights permissions performed by analyzing a sample of accounts.

ISO27001
Domain Name
11 Access controls
11.1 Business requirement for access control
11.2 User access management
11.3 User responsibility
11.5 Operating system access control
11.6 Application and information access control

3.8 Personnel Management

Checklists exist for employee entry and exit activities. Every new employee is added to these lists and registered. All new employees have to prove that they have not been previously prosecuted and do not have a criminal record which means that there are no relevant records in the police records. Every employee must attend a security awareness course.

3.8.1. Background checks for security personnel

All Computer Emergency Response Team (CERT) members and the CISO are background security checked by the Federal Ministry of Interior (§55 Sicherheitspolizeigesetz). 

ISO27001
Domain Name
8 Human resource security
8.1 Prior to employment
8.2 During employment
8.3 Termination or change of employment

3.9 Security Incident Management

A sister company of the Back-End Registry Operator also operates a CERT. This team consists of one Junior Security Analyst and a minimum of five Senior Security Analysts with at least 5 years and up to 15 years experience in IT Security. 

This team also operates the national CERT for the Republic of Austria (CERT.at) and together with the Federal Chancellery of the Republic of Austria, the Austrian Government CERT (GovCERT Austria). It is internationally accredited as a Forum of Incident Response Member (FIRST) and a Trusted Introducer. By achieving these memberships the registry has built an excellent formal and informal information network. As a result the registry is well prepared for the prevention of and response to security incidents.

In figure Q30a-04 the Security Incident Management Process is described.

Classification for the triage of security incidents

Urgency:
* Immediate: Reaction within 1h, invoke crisis organization if necessary
* Soon: Reaction within 8h or on the next business day
* Normal: Equivalent to a systems change, defined by change management procedures

Impacts:
* Critical
* High
* Middle
* Low

ISO27001
Domain Name
13 Information security incident management
13.1 Reporting information security events and weaknesses
13.2 Management of information security incidents and improvements

3.10 IT Project Management

A specific project management methodology has been defined.

ISO27001
Domain Name
6 Organization of information security
6.2 Internal organization
10 Communications and operations management
10.1 Operational procedures and responsibilities
10.3 System planning and acceptance
12 Information systems acquisition, development and maintenance
12.1 Security requirements of information systems
12.5 Security in development and support processes

3.11 IT Patch and Update Management

A formal vulnerability and patch management process has been defined (shown in Figure Q30a-05: Vulnerability Management). 

Patches are classified as: 
* Critical (remediation within hours)
* Non critical (remediation by the next patch day)

All patches are fully tested prior to being deployed. 

The effectiveness of the patching process is audited by vulnerability scans and by matching the actual software inventory with vulnerability databases.

Reports are discussed on a regular basis by management in order to guarantee continuous improvement.

ISO27001
Domain Name
10 Communications and operations management
10.1 Operational procedures and responsibilities
12 Information systems acquisition, development and maintenance
12.5 Security in development and support processes
12.6 Technical Vulnerability Management

3.12 Backup and Recovery

A full backup and recovery framework is in place. For details see the answer to question 37.

ISO27001
Domain Name
10 Communications and operations management
10.5 Back Up 
15 Compliance
15.1 Compliance with legal requirements

3.13 Logging and Monitoring

A logging and monitoring solution is in operation to identify malicious activities and unauthorized access. All authorized access is also logged.

All servers and systems are time synced using the Network Time Protocol (NTP).

The level of detail of logging:
* Varies with expected risks
* Requirements of business processes
* Requirements of data integrity and confidentiality

Minimum details are
* User ID
* Date and time
* Type of access
* Software
* Non authorized access
 * Not working action
* Administrator actions
 * System start and stop
 * Change of system configuration
 * Activation and de-activation of security components
* Security components alarms
* Error protocol
* Security protocol, for example anti virus software

All relevant systems of the gTLD registry are controlled by a host-based intrusion detections system (HIDS). All events are logged on a central device.

The HIDS allows to: 
* Check of host integrity.
* Check of file integrity.
* Port monitoring
* Programs using specific ports
* Process checks
* Login⁄logoff

The HIDS and the other log sources are integrated into a central monitoring tool. This tool can trigger certain events.

Analysis of logging and monitoring information is performed continuously to detect security incidents and performed as needed in the event of a security incident.

ISO27001
Domain Name
10 Communications and operations management
10.2 Third party service delivery management
10.10 Monitoring 
15 Compliance
15.1 Compliance with legal requirements

3.14 Spam and Anti virus

All office systems are protected by anti malware software. Servers are checked on a regular basis, if real time protection is not possible.

ISO27001
Domain Name
10 Communications and operations management
10.4 Protection against malicious and mobile code
10.6 Network security management
13 Information security incident management
13.1 Reporting information security events and weaknesses

3.15 Mobile Devices

All smartphones and mobile devices (for example notebooks) must use full hard disk encryption if technically possible. If possible it should be combined with remote wipe functionality.

The actual standard for smartphones are to use Blackberry devices with a corporate policy.

Every loss of a device has to be reported to the IT department as soon as possible.

ISO27001
Domain Name
7 Asset management
7.1 Responsibility for assets
11 Access control
11.7 Mobile computing and teleworking

3.16 Media Disposal

Information in paper form must be shredded if it is classified as confidential or higher. 

Hard disk drives (HDD) and other storage media are deleted or destroyed in conformance with policy requirements.

For example:
* Overwrite HDDs multiple times with random data
* Shredder CDs

Media disposal policies apply to all relevant devices, e.g. also HDDs in printer or other media devices.

ISO27001
Domain Name
9 Physical and environmental security
9.2 Equipment security
10 Communications and operations management
10.7 Media handling

3.17 Network Security

The aspects of integrity, confidentiality and availability are considered as essential aspects in our network design.

Integrity, confidentiality:
* Encryption on network layers between:
 * Data centers
 * Offices and data centers

Availability
* Redundant physical paths via multiple carriers

Access to the network itself is restricted by means of security zone definitions, for example no direct connection is available to the corporate network from visitor meeting rooms etc.

All controls are audited on a regular basis, for example by penetration tests.

ISO27001
Domain Name
10 Communications and operations management
10.6 Network security management
11 Access control
11.4 Network Access Control 
12 Information systems acquisition, development and maintenance
12.3 Cryptographic controls

3.18 Physical Security

The physical security risks are again evaluated on an annual basis.

The gTLD systems themselves are operated in two different data centers with state-of the art security provisions in place, e.g. heavily restricted access to data center and locked racks.

For details see answer to question 39.

ISO27001
Domain Name
9 Physical and environmental security 
9.1 Secure areas
9.2 Equipment security

3.19 External Suppliers

For external suppliers either the same restrictions as those for internal personnel or further restrictions are applied.

Domain Name
6 Organization of information security
6.2 External parties
10 Communications and operations management
10.2 Third party service delivery management