Application number: 1-1192-28569 for HEXAP SAS

HEXAP SAS

10 rue de la Paix
Paris 75002
FR

+33 613 179 098

+33 957 843 489

http:⁄⁄www.hexap.com

Mr. Jerome Lipowicz

CTO

+33 613 179 098

office@hexap.com

Ms. Daniele Laubie

President

+33 622 840 376

laubie@hexap.com

SOCIETE PAR ACTIONS SIMPLIFIEES

Articles L227-1 to L227-20 and L244-1 to L244-4 of French Code de Commerce

Not Available

Daniele LAUBIE
President

Jerome LIPOWICZ
CTO
Joseph LIPOWICZ
Chairman

AB SURGERY
Not Applicable
Jerome LIPOWICZ
CTO
Joseph LIPOWICZ
Chairman

med

Not Available

As the .MED gTLD is depicted in US-ASCII ⁄ Standard Latin Script only, no
particular operational or rendering issues are to be expected.
As is the case with any new TLD that is added to the DNS root zone, some general
technical acceptance issues with the delegation of this TLD are expected. The
back-end registry services provider selected by the Applicant has a significant
experience in introducing TLDs to the DNS root, including previous launches of
.eu, .be and recently the .sx ccTLD.
The following tests have been carried out in order to review whether the .MED
TLD presented any operational or rendering issues. This included the deployment
of a testing infrastructure that operated:
- an SRS for the .MED TLD of which the features have been limited to what was
strictly necessary to carry out the tests described below;
- a WHOIS system, displaying domain names registered in the test environment
of the .MED registry;
- an EPP and web interface for registrars;
- a DNS system, serving authoritative responses for the .MED TLD;
- a web server on which different basic websites were deployed; and
- an email server with mailboxes linked to various test domain names
registered in the TLD and entered into a limited zone file which was made
available through the DNS system referred to above.
The following integration tests have been carried out, by connecting various
clients to the infrastructure described above: 
- logging into the .MED SRS with a registrar account – using both EPP and Web
interfaces;
- perform basic transactions (create, update, delete, transfer, allocate name
servers, etc.) with this registrar test account;
- generation of a test-zone file for this TLD;
- navigation to and within websites using both direct navigation to the
respective domain names and navigation through hyperlinks displayed on the
web sites that were hosted in the testing environment;
- sending WHOIS queries to and receiving answers from port 43 in the testing
environment;
- sending email messages to and receiving email messages from domain names
registered in the TLDʹs testing environment.
Within each of the above steps, the Applicant and its selected back-end
registry operator reviewed:
- whether registrar transactions with respect to these domain names were
performed successfully;
- whether the zone file was correctly generated and deployed in the DNS of
the test environment;
- whether domain names registered in the TLD displayed correctly in browser
address bars and email clients; and
- whether email filters, spam detectors, etc. were correctly functioning.
Using the most common web browsers, email, SSH clients, etc., these tests
have been carried out successfully. Therefore, to the Applicantʹs best knowledge
and belief, no specific issues are to be expected as regards the operation and
rendering of the .MED gTLD.

For over 15 years, workgroups and commenters have been seeking ways to provide
reliable medical information on and, where allowed, offer genuine healthcare
products over the Internet, and this for the benefit of patients all over the
world. Indisputably, a lot of health-related information currently available on
the Internet is sometimes completely inaccurate, because it has been posted by
individuals who are not qualified or entitled to practice healthcare-related
services, like doctors, surgeons, life scientists, etc.

Up to now, no clear, structured and universally accepted methods have been found
in order to effectuate these goals.

HEXAPʹs mission and purpose for the .MED gTLD are threefold:

 (1) federate certified and licensed practitioners in the health care sector
 under a clear, common, and easy to remember identifier on the Internet;

 (2) provide stakeholders within the health care sector with a platform on
 which they can disseminate information in relation to medical topics, and
 offer products and services to businesses, consumers and, more in 
 particular, patients;

 (3) provide Internet users in general, looking for genuine and reliable
 medical information, products and services with a clear and unambiguous
 identifier which provides them access to such information.

HEXAP is a limited liability company that has been founded by health care
professionals. Bowing on its unparalleled experience in providing Internet-based
solutions for the health care sector, HEXAP intends the .MED extension to be a
community-based gTLD, for which it has obtained the supported from various
organizations representing many sectors, sub-sectors and branches of the health
care industry. This shows that there is a clear demand for a centralized
platform for quality health care information.

A list of organizations, companies and individuals that are endorsing this
initiative is detailed in our response to Question 20.

The missions of the .MED gTLD are the international transpositions of what HEXAP
founders have achieved these last years in collaboration with the French medical
Colleges with respect of their ethical codes.

Therefore, the .MED gTLD purports to be:

 - an exclusive namespace where registrations are only open to licensed health
 care professionals and with eligibility rules;

 - a new zone protected by colleagues who validate the authenticity and
 qualifications of registrants; and

 - an application serving patientsʹ interests with unambiguous and verified
 contact details of the licensed health care WHOIS service providing
 professional details on registrants.

Currently, a lot of information with respect to health care, health issues,
pharmaceutical products, methods, etc. can be found on the Internet. Absent
any specific oversight over this information or the individuals,
organizations and companies that make such information available, this
clearly poses a number of risks for individuals who are looking for
health-related information.

For more than a decade, various national and international organizations,
have pointed on various occasions to risks relating to medical information
and products provided ⁄ distributed over the Internet, self-medication, etc.

The .MED gTLD intends to be the top-level domain in which professionals from
the health care industry will be entitled to register domain names in view
of protecting the interests of consumers ⁄ patients. Although the Applicant
-when awarded the .MED gTLD by ICANN- will not review the information
provided by registrants under .MED domain names, it will review the
qualifications and licenses of registrants in order to ensure that at least
the source of such information can be considered reliable.

By restricting the registrants to licensed practitioners and health care
entities, the .MED TLD has therefore the potential to become the domain in
which quality information with respect to health care can be found, and
reliable (contact) information with respect to domain name registrants ⁄
health care practitioners can be retrieved.

This model has been successfully implemented by HEXAPʹs sister company,
PROMOPIXEL, which has secured more than 2,100 sector-based domain name
registrations up to today in the following three second level domain names :

- chirurgiens-dentistes.fr (targeted at dental surgeons)
- pharmacien.fr (targeted at pharmacists)
- medecin.fr (targeted at physicians)

These three zones are regulated by specific policies that include legal elements
from the French Codes of Medical Practice.

This successful cooperation with the 3 French medical, dental and pharmaceutical
Orders lead our team to propose a community-based gTLD, operated under the
highest ethical standards. This initiative is supported by both medical
authorities and practitioners, and piloted by HEXAP founders, some of which have
sworn by the Hippocratic Oath, which sets the duties of qualified professionals
in their relation with patients and respect for colleagues.

The .MED gTLD will thus give benefits to:

- medical professionals (i.e., members of the ʺ.MED Communityʺ) who would like
 to become a registrant in the .MED TLD;

- Internet users in general who are looking for genuine health care related
 information, products or services from reliable sources, being recognized
 professionals that are entitled to practice medicine or other health care
 related professions; and

- patients seeking to exchange information in a secure environment: in addition
 to DNSSEC, internet users will be able to check on .MED WHOIS services various
 verified information regarding the registrant occupation (license id,
 professional address, diplomas).

1. SERVICE LEVELS

 The .MED gTLD proposes a new safe namespace for the medical community,
 maintained by recognized and licensed practitioners in the health care
 sector. It is supported by various organizations and will be monitored by
 national and international stakeholders with whom the Applicant, its sister
 company (PROMOPIXEL) and their respective founders are working with for
 several years.

 It is therefore a TLD for the medical professions, managed and controlled by
 medical practitioners.

 In terms of service levels, HEXAP will ensure a quality application
 dedicated to health care professionals using combined 20 years experience in
 medical publishing and 3 years experience in registry operating:

 - legal issues regarding medical practicing;
 - medical information publishing on the Internet with regional scopes;
 - establishing relationships with health care providers and stakeholders;
 - guiding colleagues on the Internet for good medical practices;
 - ethics on the web;
 - helping the patients finding a practitioner with a neutral attitude; and
 - helping colleagues in finding a registrar with no discrimination.

 HEXAPʹs application is guided by the sense of ethics that HEXAPʹs founders
 have consistently demonstrated in their business dealings, and reinforced by
 the technical expertise renowned for partners and clients. Furthermore,
 HEXAPʹs founders are medical practitioners who are unaffiliated with any
 medical or pharmaceutical company or organization. This continuous
 commitment guarantees that the .MED TLD will be operating independently from
 influences from industry.

2. INNOVATION

 As of today, except in France for physicians, dentists and pharmacists,
 there is no opportunity for a health care provider to register a domain name
 at second or third level under a regulatory framework defined by Medical
 Colleges or Boards. While some ccTLDs do offer third level domain names for
 physicians (Brazil, Comoros, Ecuador, Estonia, Haiti, Libya, Oman, Panama,
 Saudi Arabia, Sudan and Vietnam), none of these are currently supervised by
 any representative health authority. Some of them do not even require a
 proof of license of registrants, or are only carrying out limited and random
 identification clearances. Most of these second level name spaces are also
 restricted to physicians only. None of them offers the possibility for any
 Internet user to check the registrant professional credentials.

 The .MED gTLD establishes a relationship of trust with patients by setting
 up a highly monitored namespace, handled by HEXAPʹs Medical Clearinghouse.
 This specific clearinghouse is an advanced tool derived from our
 smallregistry.net clearance engine that is used on a daily basis by French
 Colleges and regulating authorities during the past 3 years.

 The Medical Clearinghouse will offer the following services, which certainly
 sets apart the .MED gTLD from any other TLD currently available in the DNS:

 - mandatory professional identification: any new registrant creating a
 domain name will have to prove its profession, occupation and⁄or
 professional qualifications (see life cycle description in our answer to
 Question 27);

 - continuous license checking: every domain name renewal will be subject to
 an automatic re-verification of the registrantʹs credentials, similar to
 the verification set out above; any registrant who has lost its
 accreditation, license, or professional accreditation will consequently
 also not be entitled to renew its domain name registration (see our answer
 to Question 20);

 - professional account credential provider for third party authentication:
 using a single combination of email and password, .MED domain name
 registrant will be able to be authenticated on websites and devices
 granted by the Registry Operator. This single sign-in service will
 benefit:

 * .MED domain name registrants being identified as a health care provider
 without sharing their logins and passwords; and

 * companies willing to identify health care provider upon sign-up on their
 websites and devices, by connecting to the Medical Clearinghouse. This
 implemented service is using OAuth, an open protocol to allow secure
 authentication in a simple and standard method for desktop or web
 application, mobile phones and living room devices. This protocol is
 already widely used by developers who are working with various major
 service providers (Facebook, Twitter, Google, Microsoft, LinkedIn,
 MySpace, Yahoo, Netflix, etc.). It is a safe way for any service
 provider to give clearance to authenticated and verified practitioners
 who allow to share limited, revocable and non-critical information with
 the service provider. This service will be free for every registered
 developer.

 - Advanced WHOIS web interface: the WHOIS data will be complemented with a
 full description of the domain ownerʹs health care license, and made
 available to Internet users (however always bearing in mind that privacy
 restrictions may apply);

 - In order to increase visibility of the .MED TLD and its domain name
 registrants, the Applicant will also distribute SSL certificates and
 deliver seals of authenticity for web publishers, in addition to the
 default DNSSEC implementation. These certificates intend to reinforce the
 security and safety aspects of .MED.

 All these processes, tools and technologies are aimed at establishing a
 unique relationship of trust between, on the one hand, domain name
 registrants in .MED and, on the other hand, Internet users at large.

 In this respect, .MED is all about offering safety, security, transparency
 and oversight for the benefit of the patients.

3. USER EXPERIENCE

 The user experience of the .MED gTLD will be entirely different from any TLD
 that is currently on the market, considering the combination of the
 following features:

 - .MED is a short string, easy to write and remember;

 - it is understandable in over 70 languages as an abbreviation or the first
 characters of the word “medicine” in English, Spanish, French, Italian ,
 German, Portuguese, Spanish, etc.;

 - a new semantic and meaningful namespace with a high chance of search
 engine optimization value;

 - the .MED policies will be focused on serving the best interests of
 patients: a web search that resolves in a .MED domain name should provide
 genuine information regarding health and health care;

 - increase the visibility of a .MED registrant by making use of the Medical
 Clearinghouse: by way of this tool, the registry will capture and verify
 the following information from a registrant: profession, specialization,
 professional address, as well as public information relating to the
 registrantʹs qualifications and licenses. All this information will be
 made public through the WHOIS interface, the SSL certificate and seals to
 be displayed on the registrant website; and

 - it will add to Health 2.0 initiatives, considering the fact that
 authentication of registrants is a cornerstone function of .MED. Because
 registrants are authenticated, patientsʹ medical files can be exchanged
 with and between .MED registrants, respecting the confidentiality of such
 data, for example during a regulated telemedicine session; and a secure
 registration process with minimal impact on registrars and no specific
 proprietary EPP scheme for easier integration.

4. REGISTRATION POLICIES 

 The .MED registration policy is inspired by the principles reflected by the
 Hippocratic Oath, as well as Medical Good Practices established by various
 national and international organizations and institutions. These establish
 the obligation imposed upon the registrant to respect the interests of
 patients as well as the medical deontology.

 Given the fact that the registration of domain names will be monitored at
 all times by the .MED Registry Operator, these principles will apply during
 the registration process, but also as regards the use the registrant is
 making of such domain name.

 Eligible registrants must be part of the designed community and are
 classified under two categories:

 - practitioners: these consist of licensed health professionals and health
 associate professionals only. Regional restrictions may apply for all
 professions as not all of these professions are recognized by local
 authorities. They are defined by the International Standard Classification
 of Occupations (ISCO), 2008 revision 8 (ISCO-08), which forms part of the
 international family of economic and social classifications of the United
 Nations and is mapped by the World Health Organization (
 http:⁄⁄www.who.int⁄hrh⁄statistics⁄workforce_statistics⁄en⁄index.html ):

 * Generalist medical practitioners
 * Specialist medical practitioners
 * Nursing professionals
 * Midwifery professionals
 * Traditional and complementary medicine professionals
 * Paramedical practitioners
 * Dentists
 * Pharmacists
 * Environmental and occupational health and hygiene professionals
 * Physiotherapists
 * Dieticians and nutritionists
 * Audiologists and speech therapists
 * Optometrists and opthalmic opticians, orthoptists
 * Chiropractors, Osteopaths

 - entities:
 * Hospitals, health care facilities
 * Ambulances
 * Pharmacies
 * Medical laboratories
 * Schools, Universities
 * Pharmaceutical industries
 * Libraries
 * Scientific and Academic publishers
 * Public health journals
 * Boards, Orders, Colleges, Government related councils
 * Public administrations, ministries
 * Academies
 * Scientific organizations
 * Professional associations
 * Health care professionals unions

 Conditions of qualification are made available in our response to Question
 20c. However, this list is subject to change, which is mainly inspired and
 driven by changes implemented by the International Standard Classification
 of Occupations (ISCO) and changes in the law.

 If the registrant is a practitioner, he or she must certify that he or she
 is a health care professional who is licensed to practice in the country
 where he purports to be working. Any such information will need to be
 reported to the Medical Clearinghouse and must be kept up-to-date at all
 times throughout the lifecycle of the domain name.

 Any domain name registered in .MED must be used in the best interest of
 patients or other health care practitioners. Parking domain names will not
 be allowed.

 Any registered domain name must also contain either an MX or an A, CNAME or
 AAA record in order to be able to use it and refer users to a website whose
 content is related to human health. Such website can but must not
 necessarily be a website under a .MED domain name.

 The holder of a domain name is committed to serve and share information
 aimed at patients, always considering the best interests of patients, their
 dignity and privacy. Furthermore, the registrant commits to provide
 information in accordance with the state of the art (scientific sources),
 and that is honest, clear, appropriate and meets the needs of patients with
 whom they engage under the .MED domain name.

 The holder of a domain name undertakes to respect his peers, colleagues and
 competitors with whom he communicates by using the .MED platform.

 When registering a domain name, the registrant must acknowledge that
 complaints can be filed with the Registry Operator or Medical Clearinghouse
 for various reasons, including but not limited to a breach of the
 eligibility requirements, if the information of the registrant is inaccurate
 or no longer up-to-date, non-compliance with the Registry Operatorʹs
 policies, trademark infringement, impersonation, illegal activities, etc.

 Furthermore, the registrant must acknowledge that any supervising authority
 will be entitled to request the Registry Operator to suspend a domain name
 if such domain name is used in an illegal manner, or if the registrant no
 longer meets the eligibility requirements.

 The domain name must be composed of 3 to 63 characters, case insensitive,
 alphanumeric characters and may consist of hyphens (however: a domain name
 cannot begin or end with a hyphen), and contain the name or the name of the
 holder, its brand, business identifier or company name. Eligible
 practitioners are entitled to include a prefix or suffix to their name, such
 as a civilian, military, academic or honorary title, specialization, degree,
 location where they are practicing medicine, etc.

 As part of the landrush, the Registry Operator may release so-called
 ʺpremium domain namesʺ to any person or entity that meets the eligibility
 requirements, provided that:

 - the use that is made of such domain name complies with the rules of good
 medical practice;
 - the domain name chosen is consistent with the exercise or holderʹs name; 
 - the domain name will only be used for the benefit of patients; and 
 - the domain name cannot cause confusion about the profession of the
 registrant or its field of activities.

 These rules of conduct continue to apply throughout the life cycle of the
 premium domain name.

5. PRIVACY

 The purpose of the MED gTLD is to establish a stronger trust between
 patients and health care providers on the Internet. It is then essential to
 first protect the interests of the patients by setting up unambiguous
 registration rules and give a full transparency on registrant identity:

 - no anonymous records will be allowed;

 - registrants must provide their full professional address and phone number
 verified records, reflected in the WHOIS, will include the registrantʹs
 occupation, specialization, license ID, and the name of the issuing
 authority;

 - furthermore, these records will include academic, honorific and military
 titles;

 - optional information: year of establishing, year of main diploma,
 university, other diploma recognized by the practitionerʹs regulation
 board;

 - the WHOIS will expressly mention the last date on which the registrantʹs
 information has been verified by the Registry Operator; and

 - other domain names owned by the registrant will be available by request on
 the Medical Clearinghouse.

 These information are available with a free access to the WHOIS from port
 43, the WHOIS service on the registry platform website and on the Medical
 Clearinghouse website equipped with domain name and registrant search
 engines.

 These information are checked for every domain name creation, renewal,
 transfer and trade. These information will also be monitored by the .MED
 scientific council and accredited medical colleges, and will be open to any
 authority wanting to be a .MED stakeholder and supervise regional and
 professional scoped registrations.

6. COMMUNICATION

 PROMOPIXEL, of which HEXAP is a spin-off company, has already entered into
 registry-registrar agreements with 7 ICANN accredited registrars and over 70
 European registrars, and is hence already dealing with thousands of health
 care professionals;

 HEXAP founders worked with over 12.000 entities and leading healthcare
 providers over these last 20 years, including but not limited to Councils,
 Medical Colleges, Academics, medical publishers, scientific organizations,
 medical suppliers, industries, web 2.0 communities, health care social media
 platforms, hospitals, and universities;

 During the same period, HEXAP founders have established close relationships
 with specialized media and various medical journals in Europe and North
 America, which will present an attractive promotional and sales channel by
 publishing advertisements and information about the .MED gTLD.

OPERATING RULES OVERVIEW

 In line with our mission statement and purpose for the .MED gTLD, it is
 important for us to ensure that social costs and operational problems or
 issues in relation to the .MED gTLD are minimized to the maximum extent
 possible. 

 First of all, the founders of HEXAP have built up a reputation as
 a leading and independent provider servicing the needs of the members of
 various medical professions and want to avoid the unduly exploitation of
 that reputation in the domain name space by third parties.

 The protection mechanisms HEXAP intends to put in place do therefore not
 only extend to the actual registration, delegation and use of the TLD, but
 also to the domain names that are registered therein, and how these domain
 names are used.

 In order to ensure that .MED will be and remain for the foreseeable future a
 reliable, trustworthy, safe and secure space, HEXAP will devise policies in
 that will contain clear guidelines and rules in relation to:

 - the types of domain names that will be registered;

 - who will be entitled to select which domain names will be registered;

 - who will be entitled to register such domain names;

 - who will be entitled to use such domain names; and

 - which types of use of such domain names will be allowed or recommended.

 As we believe that the development and implementation of one or more
 business cases could likely take a couple of months or even years, we have
 herein only focused on a number of high-level characteristics of our plans
 in relation to the operation of the .MED gTLD.

 By all means, it is in HEXAPʹs vested interest to make the
 most of this initiative, promote the interests of its registrants (be it
 legal entities or individuals), and mitigate risks for the .MED gTLD, the
 reputation of HEXAP and its members, whilst also reducing the (social) costs
 for others.

 The Medical Clearinghouse, which will be established by HEXAP, will play a
 pivotal role in this respect.

 In this context, we will devise policies that encompass and comprise the
 following features:

1. LAUNCH PROCESS

 The .MED start-up processes are made of three specific periods.

 - SUNRISE A: this period will be focused on trademark holders only willing
 to put a domain on a «do-not-sell» list. This list will be handled by the
 Registry for a 10-years period (or for the entire term of the Registry
 Agreement). Requests will be verified by the Registry Operator using the
 Trademark Clearinghouse only.

 - SUNRISE B: this period will be focused on trademark holders only, where
 contention between two parties holding an identical trademark for a
 particular string will be resolved by auction. Registrants must meet the
 eligibility requirements, thus requests will be verified by the Registry
 Operator using the Trademark Clearinghouse and the Medical Clearinghouse.

 - LANDRUSH: this period will allow registration of ʺselected premium domain
 namesʺ with an auction process. Registrants must meet the eligibility
 requirements, thus requests will be verified by the Registry Operator
 using the Medical Clearinghouse.

 Following the end of the .MED start-up process, registrations of domain
 names will be done on a first-come, first served basis.

 Both during and after the Sunrise period, any and all domain name
 registration requests will be verified by the Registry Operator in order to
 guarantee their compliance with policies that have been set by the Registry
 Operator.

2. REGISTRATION COSTS

 At this stage, no particular discounts have been foreseen. Nonetheless,
 HEXAP reserves the right to implement certain cost benefits for registrars,
 considering the additional complexities in dealing with verification
 processes handled by the Registry Operator only that will be implemented in
 order for potential registrants to register domain names in .MED.

3. REGISTRY AGREEMENT

 Currently, HEXAP foresees to increase its prices with 5% annually; insofar
 and to the extent this price increase will be kept, this threshold will be
 included in the Registry-Registrar Agreement.

 Furthermore, HEXAP envisages registering a fair number of generic words that
 are directly or indirectly related to the services and products offered to
 and the activities organized by the various members of HEXAP.

 Prior to effectively registering such domain names in the .MED gTLD, HEXAP
 will require its legal and intellectual property department to review the
 list of these domain names on a regular basis in order to satisfy itself
 that they will not infringe the rights of third parties.

 In any case, HEXAP will claim to have a legitimate interest in these domain
 names, as they are merely descriptive of the activities, products or
 services of HEXAP offered to its members. So even if one or more of these
 domain names would be protected by a registered trademark, held by a third
 party, it is likely that a claim under the Uniform Dispute Resolution Policy
 or Uniform Rapid Suspension policy will fail.

 As regards the names referred to in Specification 5 to the template Registry
 Operator Agreement, HEXAP will follow the processes and procedures
 established by ICANN and the Governmental Advisory Committee.

 However, HEXAP will at all times be entitled to restrict, limit or expand:

 - the category or categories of stakeholders who will be entitled to
 register one or more domain names in the .MED gTLD, including their
 criteria for qualification, however in any case excluding stakeholders who
 are not a member of HEXAP or do not have a sufficient link to the HEXAP
 community;

 - the choice of domain name(s) registered in the .MED gTLD by and per such
 eligible stakeholder (category);

 - the use made by an and per eligible stakeholder of a domain name
 registered in the .MED gTLD;

 - the transfer of domain names registered in .MED;

 - etc.

 HEXAP shall reserve the right to subject the registration or use of a domain
 name to internal approval processes and procedures, at each and every step
 of the domain name life cycle.

Yes

1. COMMUNITY PURPOSE
The .MED gTLD is a new extension dedicated to the medical community. The
medical community is defined by all:
- Health care providers (practitioners, facilities);
- Boards, Councils, Ministries, Orders and Colleges;
- Schools and universities; and
- Academies, scientific organizations and professional associations.
The .MED application is for a gTLD created by health care professionals,
open to colleagues around the world for serving the best interests of the
patients. The .MED gTLD is a string understandable in more than 70
languages, including English, Spanish, French, Russian, Portuguese, German,
Italian, etc.
The .MED gTLD is a professional namespace where the medical community will
be able to publish information for peers and patients.
2. COMMUNITY MEMBERS
.MED is a comprehensive zone that includes all licensed professionals with
specific rules per country. These health professionals are not only limited
to physicians and doctors but include a wide although limited range of
health providers and stakeholders. Thus, a list of eligible registrants has
been determined for the .MED TLD, which takes into account regional
particularities, legal specifications and licensing procedures, and
considers different national regulations regarding some medical practices.
Specific restrictions will be implemented for a limited list of occupations
that are not recognized nor authorized by the relevant Council or competent
Ministry of the country for specific registrants eligible for .MED. Defined
in the .MED gTLD policies, these lists will be produced by HEXAPʹs Medical
Clearinghouse which communicates with the Registry Back-End Operator for
verifying and approving domain name creations, renewals and transfers.
The Medical Clearinghouse is supervised by HEXAPʹs scientific council, which
is consulted for providing guidelines with the help of relevant stakeholders
in matters of ethics, lack of local regulation or if a questionable domain
name registration occurs.
Members of the designed community are classified in two categories (full
list in attached document), further detailed below in our response to
Question 20 (c):
- practitioners: These qualified health and health associate professionals
are defined by the International Standard Classification of Occupations
(ISCO), 2008 revision 8 (ISCO-08), which forms part of the international
family of economic and social classifications of the United Nations and is
mapped by the World Health Organization [1]. All these licensed
professionals are regulated by health departments, ministries, boards,
councils and orders. Number of identified practitioners is evaluated to
45,225,207 [2]
- entities: This group is composed of licensed health care providers,
professional associations and health-related organizations:
* Facilities: hospitals, clinics, maternity hospitals, medical nursing
homes, geriatric cares facilities, dialysis centers, blood transfer and
blood donation centers, ambulances (no recent study has quantified
them; estimated at 230,000)
* Pharmaceutical industries
* Medical schools and universities (1,943 institutions recognized by the
World Health Organization [3], 2,218 by the Foundation for Advancement
of International Medical Education and Research[4])
* Scientific and academic publishers, public health journals (estimated at
26,262 [5])
* Academies, Boards, Orders, Colleges, Government-related councils and
public health administrations (over 640 identified administrations)
Professional associations and unions (estimated at 300,000)
3. COMMUNITY STRUCTURE
The medical profession is not structured in a particular way, but consist of
many different organisations, institutions, etc. that focus on specific
practise areas. The .MED application conceived by HEXAP received the
greatest attention from a lot of stakeholders coming from various countries
and institutions. HEXAP is well aware that giving an endorsement to a third
party is a particular sensitive issue in the medical worlds, as well as
publishing the names of those who provided us with a letter of support.
Reference is made to the various institutions, hospitals, research
organizations, universities, companies and individuals who have endorsed our
application. Please see our response to Question 20 (b) for more information
about these entities.
[1] Sources and classification of health workforce statistics - World Health
Organization, http:⁄⁄www.who.int⁄hrh⁄statistics⁄workforce_statistics⁄en
[2] Global Health Observatory Data Repository - World Health Organization
http:⁄⁄apps.who.int⁄ghodata⁄?vid=92000
[3] Avicenna Directories - World Health Organization, University of Copenhagen
http:⁄⁄avicenna.ku.dk
[4] Mapping the Worldʹs Medical Schools, FAIMER
http:⁄⁄www.faimer.org⁄resources⁄mapping.html
[5] National Library of Medicine Catalog -
http:⁄⁄www.ncbi.nlm.nih.gov⁄nlmcatalog

1. ETHICS
HEXAP is a limited liability company that has been founded by health care
professionals who have sworn by the Hippocratic Oath, setting the duties of
qualified professionals with patients and respect for colleagues. They worked
with over 12.000 entities and leading healthcare providers over these last 30
years, including but not limited to Councils, Medical Colleges, Academics,
medical publishers, scientific organizations, medical suppliers, industries,
web 2.0 communities, health care social media platforms, hospitals, and
universities.
Relying on the unparalleled experience of HEXAPʹs predecessors and founders in
providing Internet-based solutions for the health care sector, HEXAP intends
the .MED extension to be a community-based gTLD. For this matter, the
applicant is appointed and supported by various organizations representing
many sectors, sub-sectors and branches of the health care work forces and
industry. Furthermore, these supports come from both traditional institutions
and the Internet web 2.0 communities from abroad: the .MED application thus
brings together different generations and cultures of medical stakeholders.
These organizations will work closely with the applicant in order to implement
the .MED gTLD in the manner described in Q18.
The .MED gTLD is guided by the sense of ethics that HEXAPʹs founders have
consistently demonstrated in their business dealings, and reinforced by the
technical expertise renowned among partners and clients. Furthermore, HEXAPʹs
founders are medical practitioners who are unaffiliated with any medical or
pharmaceutical company or organization. This continuous commitment guarantees
that the .MED gTLD will be operating independently from influences from
industry.
2. ENDORSEMENTS
Various organizations and companies have endorsed the .MED application by
HEXAP, which clearly underlines a strong need and demand for having an
unambiguous platform for quality health care information, products and
services. Relying on the experience and expertise of HEXAPʹs founders and
predecessors in similar projects, which have been applauded by medical
professionals, these organizations and companies have endorsed HEXAPʹs plans
for this new and unique name space that will not only serve the needs,
requirements and demand from the targeted medical community, but also the need
for patients to find reliable sources when seeking such information, products
and services.
2.1. FDI WORLD DENTAL FEDERATION (FDI), SWITZERLAND
http:⁄⁄www.fdiworldental.org - The FDI is an international federation of
approximately 200 national dental associations and specialist groups,
including the American Dental Association (ADA). The FDI is a member of the
World Health Professions Alliance (WHPA http:⁄⁄www.whpa.org); an alliance of
dentists, doctors, nurses and pharmacists. WHPA represents more than 20
million health care professionals worldwide and assembles essential knowledge
and experience from key health care professions. The FDI currently has a
membership of approximately 200 member associations from more than 130
countries, representing more than 1 million dentists globally.
2.2. CONSEIL NATIONAL DE LʹORDRE DES MEDECINS, FRANCE
http:⁄⁄www.conseil-national.medecin.fr - The French Medical Order of
physicians is the national authority and is particularly involved in
Information Technology and eHealth. It and has published in 2011 a Code of
Ethics on the Internet (ʺDeontologie Medicale sur le Webʺ http:⁄⁄goo.gl⁄qFqDq
). This white paper defines guidelines for online good medical practices and
makes a clear reference to the .MED gTLD with the intention to reconsider its
domain name policy for physicians. It also founded in 1971 the European
Council of Medical Orders ( http:⁄⁄www.ceom-ecmo.eu⁄en ) and is represented by
its General Secretary since 2011. The Order is regulating about 265,000
physicians.
2.3. CONSEIL NATIONAL DE LʹORDRE DES CHIRURGIENS-DENTISTES, FRANCE
http:⁄⁄www.ordre-chirurgiens-dentistes.fr - For more than 13 years the French
Dental Surgeons Order has maintained a transposition of the Code of Ethics on
the Internet dedicated to online information publishing (http:⁄⁄goo.gl⁄JNxQo).
The Order also released guidelines for patients regarding dental information
web browsing (http:⁄⁄goo.gl⁄4Y3Y3). The Order has founded in 2000 the
Federation of Dental Competent Authorities
(http:⁄⁄www.fedcar.eu⁄index.php?lang=en) and is the General Secretary as of
2011. The Order is regulating close to 50,000 dental surgeons.
2.4. CONSEIL NATIONAL DE LʹORDRE DES SAGES-FEMMES, FRANCE
French Chamber of Midwives - http:⁄⁄www.ordre-sages-femmes.fr⁄
The Order is regulating 23,365 practitioners as of September, 2011.
2.5. ACADEMIE NATIONALE DE CHIRURGIE DENTAIRE, FRANCE
http:⁄⁄www.academiedentaire.fr - The French National Academy of Dental Surgery
has a current total membership of 317 doctors.
2.6. STANFORD UNIVERSITY SCHOOL OF MEDICINE - MEDICINE X, USA
http:⁄⁄medicinex.stanford.edu - Medicine X is a catalyst for new ideas about
the future of medicine and health care. Under the direction of Dr. Larry Chu,
Assistant Professor of Anesthesia, Medicine X is a project of the Stanford AIM
Lab.
2.7. MAYO CLINIC CENTER FOR SOCIAL MEDIA, USA
http:⁄⁄socialmedia.mayoclinic.org⁄ - Mayo Clinic is a nonprofit worldwide
leader in medical care, research and education for people from all walks of
life. The Mayo Clinic Center for Social Media exists to improve health
globally by accelerating effective application of social media tools
throughout Mayo Clinic and spurring broader and deeper engagement in social
media by hospitals, medical professionals and patients.
2.8. CANCER CAMPUS, FRANCE
http:⁄⁄www.cancer-campus.com - Cancer Campus is creating an environment, with
particular emphasis on the field of cancerology, in which innovative life
science and healthcare companies can establish themselves and expand.
2.9. GLOBAL MEDIA SANTE, FRANCE
http:⁄⁄www.gmsante.fr - Communication group specializing in the health field.
2.10. RADBOUD UNIVERSITY NIJMEGEN MEDICAL CENTRE, NETHERLANDS
http:⁄⁄www.radboudreshapecenter.com⁄
2.11. BUZZMED, USA
http:⁄⁄buzzmed.net⁄ - Current total membership of 15,000 doctors.
2.12. DOCTORS.NET.UK, UNITED KINGDOM
http:⁄⁄www.doctors.net.uk⁄ - Professional service available to UK-registered
doctors in primary and free accredited education allowing doctors to maintain
Continuing Professional Development. It has a current total membership of
192,000 doctors.
2.13. COLIQUIO, GERMANY
http:⁄⁄www.coliquio.de - Coliquio is already used by over 57,000 physicians
from all disciplines and is one of the most active German physicians networks.
2.14. EUGENOL, FRANCE
http:⁄⁄www.eugenol.com - First French online community for healthcare
professionals, Eugenol allows dentists to manage their network, to broadcast
surgery casesʹ videos, to vote or advise products, to submit scientific
articles, to exchange about day to day matters, etc. Eugenol has a current
total membership of 41,000 dentists.
2.15. CONSENSUS, FRANCE
http:⁄⁄www.consensus-online.fr - Consensus has a current total membership of
4,500 cardiologists.
2.16. CARENITY, FRANCE
http:⁄⁄www.carenity.com - Carenity is the first french social network
dedicated to patients suffereing from chronic diseases. Launched in 2011, it
counts 7,000 active users and 30 different patients communities.
2.17. APRES MON CANCER DU SEIN, FRANCE
http:⁄⁄catherinecerisey.wordpress.com - Notorious french e-patient blog about
breast cancer.

1. A COMPREHENSIVE ELIGIBLE REGISTRANTS LIST
Eligible registrants include the following:
- practitioners: Qualified health and health associate professionals as
defined in Q20a. Must provide a license identification from the relevant
health Agency, Board, Council, Order or College:
* Generalist medical practitioners
* Specialist medical practitioners
* Nursing professionals
* Midwifery professionals
* Traditional and complementary medicine professionals
* Paramedical practitioners
* Dentists
* Pharmacists
* Environmental and occupational health and hygiene professionals
* Physiotherapists
* Dietitians and nutritionists
* Audiologists and speech therapists
* Optometrists and opthalmic opticians, orthoptists
* Chiropractors, Osteopaths
Alternative occupation names may apply to fit regional features.
- entities: This group is composed of licensed health care providers,
professional associations and health related organizations:
* Facilities: hospitals, clinics, maternity hospitals, medical nursing
homes, geriatric cares facilities, dialysis centers, blood transfer and
blood donation centers, ambulances, medical laboratories. Must provide a
Business ID and credentials from the relevant national or the federal
Health, Trade, Industry, Economic Development or Commerce Ministry or
Department, Agency or authority
* Pharmaceutical industries: must provide a Business ID and comprehensive
credentials from the relevant national or the federal Health, Trade,
Industry, Economic Development or Commerce Ministry or Department,
Agency or authority.
* Schools and universities: must be listed in the International Medical
Education Directory (IMED - http:⁄⁄www.faimer.org⁄resources⁄imed.html )
maintained by the Foundation for Advancement of International Medical
Education and Research (FAIMER - http:⁄⁄www.faimer.org⁄ ), or the
Avicenna Directory of medical schools maintained by the University of
Copenhagen ( http:⁄⁄avicenna.ku.dk⁄ ), else must provide a comprehensive
confirmation from the related health or education national agency or
ministry.
* Medical Libraries: must provide a comprehensive accreditation.
* Scientific and academic publishers, public health journals: must provide
a valid ISO identifier such as International Standard Book Number (ISBN)
or International Standard Serial Number (ISSN) or International Standard
Audiovisual Number (ISAN).
* Academies, Boards, Orders, Colleges, Government related councils and
public health administrations: must provide official documents.
* Professional associations and unions: must provide a comprehensive
identification.
Intended end-users include any physical person who would like to obtain
access to or receive genuine information from a verified licensed
professional practitioner or entity active in the field of health care.
2. AN EXPERIENCED REGISTRY
As it is explained further in our application, HEXAPʹs experience in
managing domain name platforms has been generated in the context of the
activities of PROMOPIXEL, of which HEXAP is a spin-off company, and in
particular in relation to PROMOPIXELʹs product called SMALLREGISTRY.
Since 2009, the SMALLREGISTRY platform allows members of the medical
profession in France to register domain names in following second level
domains:
- medecin.fr (for physicians);
- chirurgiens-dentistes.fr (for dentists); and
- pharmacien.fr (for pharmacists).
Given the above, the team that has recently established HEXAP is already
equipped to handle the anticipated technical environment and operational
aspects that have been contemplated in this application for the .MED gTLD.
Currently, the SMALLREGISTRY product already encompasses all functionalities
required for the .MED gTLD, in particular as regards:
- the operation of a so-called Medical Clearinghouse;
- the operation of a domain name management platform;
- verification of registrants;
- dealing with registrars;
- etc.
Given the fact that there is a clear and continuous need for individuals to
obtain genuine information, products and services in relation to diseases and
health care, one of the cornerstones of the offering of the .MED TLD is clearly
to establish a platform for fulfilling these needs in the near and distant
future. Although no guarantees are given by the Registry Operator as regards the
accuracy of information, or the effectiveness of products or services that are
offered, it will at least provide for a trusted platform for qualified
professionals and entities to communicate with individuals and patients.

The .MED gTLD is an extension that is created by health care professionals and
is restricted to colleagues around the world for serving the best interests of
patients.
The .MED gTLD string is thus an unambiguous semantic namespace focused on
medical professionals, medical institutions, medical services.
Furthermore, the .MED gTLD is a string that is understandable in more than 70
languages, including but not limited to English, Spanish, French, Russian,
Portuguese, German, Italian, etc.
To the Applicantʹs knowledge, the string has no particular meaning outside of
the medical field, although it may function as an abbreviation for various sorts
of titles or names.

1. POLICY PRINCIPLES
The .MED registration policy is inspired by the principles reflected by the
Hippocratic Oath, as well as ʺmedical best practicesʺ established by various
national and international organizations and institutions. These establish
the obligation imposed upon the registrant to respect the interests of
patients as well as the medical deontology.
Given the fact that the registration of domain names will be monitored at
all times by the .MED Registry Operator, these principles will apply during
the registration process, but also as regards the use the registrant is
making of such domain name.
Please see our response to Question 20 (c) for more information.
2. ELIGIBILITY
Any credential and valid evidence of eligibility will be only requested by
the Medical Clearinghouse after the domain name has been registered.
Multiple verifications may occur, in particular if the registrant creates
domain names for different medical activities or purposes.
Registrants cannot be anonymous in that sense that they have to provide
accurate and full-contact information to the Registry Operator, which
information will be published in the .MED Whois.
In order to register a domain name, the candidate registrant must certify
that he or she is a health-care professional who is licensed to practice in
the country where he purports to be working. Any such information will need
to be reported to the Medical Clearinghouse, operated by HEXAP, and must be
kept up-to-date at all times throughout the lifecycle of the domain name.
3. COMMITMENTS
Any domain name registered in .MED must be used in the best interest of
patients or other health care practitioners. Parking domain names will not
be allowed.
Any registered domain name must also contain either an MX or an A, CNAME or
AAA record in order to be able to use it and refer users to a website whose
content is related to human health. Such website can but must not
necessarily be a website under a .MED domain name.
Furthermore, HEXAP intends to establish domain name registration policies
and acceptable use policies that will allow HEXAP to put domain names on
hold or even revoke any such names if and to the extent they are:
- defamatory or are being used for defamatory purposes;
- harming the reputation and good name of the .MED TLD, or are used for
these purposes;
- are infringing trademark or other intellectual property rights of third
parties;
- etc.
Furthermore, the registrant of a domain name will be committed to serve and
share information aimed at patients, always considering the best interests
of patients, their dignity and privacy. The registrant commits to provide
information in accordance with the state of the art (scientific sources),
and that is honest, clear, appropriate and meets the needs of patients with
whom they engage under the .MED domain name.
The holder of a domain name undertakes to respect his peers, colleagues and
competitors with whom he communicates by using the .MED platform.
When registering a domain name, the registrant must acknowledge that
complaints can be filed with the Registry Operator or Medical Clearinghouse
for various reasons, including but not limited to a breach of the
eligibility requirements, if the information of the registrant is inaccurate
or no longer up-to-date, non-compliance with the Registry Operatorʹs
policies, trademark infringement, impersonation, illegal activities, etc.
Furthermore, the registrant must acknowledge that any supervising authority
will be entitled to request the Registry Operator to suspend a domain name
if such domain name is used in an illegal manner, or if the registrant no
longer meets the eligibility requirements.
4. LABEL
The domain name must be composed of 3 to 63 characters, case insensitive,
alphanumeric characters and may consist of hyphens (however: a domain name
cannot begin or end with a hyphen), and contain the name or the name of
holder, its brand, business identifier or company name. Eligible
practitioners are entitled to include a prefix or suffix to their name, such
as a civilian, military, academic or honorary title, specialization, degree,
location where they are practicing medicine, etc.
5. PREMIUM DOMAINS
As part of the landrush, the Registry Operator may release so-called
ʺpremium domain namesʺʺ to any person or entity that meets the eligibility
requirements, provided that:
- the use that is made of such domain name complies with the rules of good
medical practice,
- the domain name chosen is consistent with the exercise or holderʹs name;
- the domain name will only be used for the benefit of patients; and
- the domain name cannot cause confusion about the profession of the
registrant or its field of activities.
These rules of conduct continue to apply throughout the life cycle of the
premium domain name.

Not Available

No

Given the fact that the Applicant is applying for a generic top-level domain
where geographic names as domain names could have a strong importance for health
care professionals and patients, it has a vested interest in providing its
visitors, clients and business partners a clear and predictable naming scheme in
the .MED gTLD. Given the sensitive nature of these domain names, the Applicant
may indeed develop plans in order to register domain names that exclusively
contain geographic names (country names, city names, names of regions, etc.), in
close collaboration with national authorities that are supervising the sale or
rendering of health care related products or services.

However, if such domain names will be registered, the Applicant will do so
considering the following confines:

 (1) these domain names will be exclusively registered in the name of the
 Applicant ⁄ Registry Operator, or in the name of such official supervising
 national body; these names will never be registered in the name of a third
 party, unless agreed upon otherwise with the authority competent for giving
 its consent in accordance with Specification 5 of the Registry Agreement;

 (2) where consents are required prior to the registration and use of a domain
 name referred to and in accordance with Specification 5 of the Registry
 Agreement, the Applicant will obtain such consents before actually
 registering, delegating and using these domain names.

In any case the registration, delegation and use of domain names corresponding
to geographic names will at all times be done in the best interest of:

 - the Applicant; and

 - in order to directly and indirectly promote local activity in the geographic
 locations of which the name has been registered in accordance with (1)
 above.

1. OVERVIEW

 The internet today, with 22 generic top-level domain names and approximately
 270 country code TLDs, is about to change. As the domain name space will be
 opened to organizations applying for gTLDs associated with particular
 interests and businesses sectors, this will help organizations and
 communities enhance branding, community building, security, and user
 interaction. Hundreds of new extensions may be introduced and each applicant
 will have to look for a stable and secure registry system and technical
 provider. The Registry Operator has therefore chosen to outsource the
 technical back-end operations for the domain name Registry to OpenRegistry
 (the Registry Service Provider). OpenRegistry combines a steady track record
 with modular software to help applicants take advantage of this opportunity.

 When it is stated that the Registry service Provider will perform certain
 services or comply with certain standards and processes, the Registry
 Service Provider will do this in the name and on behalf of the Applicant,
 who itself is committed to comply with these standards and processes towards
 ICANN under the Registry Agreement and the terms and conditions of the new
 gTLD program. Unless it is expressly stated otherwise, all services
 described in this question will be provided by the Registry Service Provider
 in the name and on behalf of the Applicant, who will monitor the Registry
 Service Providerʹs compliance with its contractual terms and the
 requirements laid down by ICANN on a regular basis.

1.1. REGISTRY SERVICE PROVIDER

 This document sets out the range of services that OpenRegistry offers to its
 customers in compliance with ICANNʹs new top level domain application
 process. The services are fully compliant with ICANNʹs requirements
 regarding the deployment and management of a gTLD Registry System.

 OpenRegistryʹs multilingual staff have over 20 years of combined experience
 in developing and managing sophisticated solutions for domain name
 Registrars, domain name Registrants (in particular brand owners) and
 Registry Operators, as well as being involved in the design of policies for
 and managing registrar relationships with several ccTLDs.

 All members of the team (including outsourced personnel) have been
 specifically trained on the Registry Platform and have an extensive
 knowledge and hands-on know-how about the DNS. OpenRegistry has offices in
 Luxembourg and Belgium.

 OpenRegistry was founded by the three key leaders involved in the successful
 creation and operation of the .be and .eu Registries, which combined
 currently represent over four million domain names. The OpenRegistry team
 has 20 years of experience in developing and managing sophisticated
 solutions for Registrars and Registry Operators. The OpenRegistry system
 draws on the best features of the .be and .eu systems, combined with new
 technology that has been introduced, which results in best practice system
 protocols and software design.

 OpenRegistry offers from a simple, totally outsourced product to a licensed
 version of the Registry software for clients who wish to manage their own
 infrastructure. In each and every case, the system meets and even exceeds
 ICANNʹs registry contract requirements. The software provides the
 flexibility to offer options to Registry Operators that are in line with its
 own specific operational and technical circumstances.

 (View attachment for Figure 1: Registry Software Capabilities)

 There are three key feature groups which address the ICANN evaluation
 process and which meet and even exceed ICANNʹs mission and core values to
 protect the stability of the global Internet. These are the technical
 features, financial features and third party modules that are detailed in
 the next sections.

 (View attachment for Figure 2: Registry Software Features Overview)

1.2. STABILITY & SECURITY

 The Registry Platform that will be deployed for the applied-for gTLD, which
 meets and even exceeds the technical requirements set by ICANN, combined
 with the teamʹs experience in running ccTLD domain extensions, provide a
 solid basis to assist the Applicant to meet its commitments to ICANN. As a
 Registry Service Provider, OpenRegistry is an operationally secure company
 with highly skilled staff and appropriate premises for running Registry
 Services conform to the ISO27001 standard.

 DNS services are monitored at all times and external high quality any-cast
 providers are added in the mix to deliver excellent and premium class
 nameserver infrastructure all over the world.

 The main features of the Registry Platform include a complete and extendible
 set of functionalities that can be controlled by the administrator. Some of
 the more profound features include support for IPv4, IPv6 and DNSSEC. The
 Registry Platform relies on standards-based software, carrier-grade hardware
 and protocol compliant interfaces. These include enabling dynamic zone file
 updates for immediate use after registration, escrow services and advanced
 reporting. Extensible Provisioning Protocol (EPP) transactions are only
 accepted from pre-registered IP addresses and all transactions, whether web
 or EPP are protected by Secure Socket Layer (SSL). All transactions are
 monitored, traced and logged.

 The Registry Service Providerʹs staff are industry-trained (in Java, SQL,
 Linux) university-certified professionals each with over a decade of
 experience in building and managing network infrastructure (CISCO, Juniper,
 etc.) using quality hardware appropriate for the array of customers.

 Diverse audit trails of all activities across software, hardware, staff
 movement, building access to ensure the security of our systems, are
 provided. A penalty system ensures Registrars cannot flood the Registry
 Platform with invalid requests, which would potentially degrade the systemʹs
 performance. New connections (SYN packets) are limited on the domain name
 Registryʹs edge routers to minimize the impact of Denial of Service (DOS)
 and Distributed Denial of Service (DDOS) attacks. The system is further
 protected with a redundant intrusion detection⁄intrusion prevention system
 to exercise deep packet inspection and block risks on SQL-injection and
 cross site scripting.

 OpenRegistry offers a range of services to increase the security of
 communications between the Registry Operator and Registrars. By default, the
 communication channel is encrypted using Secure Socket Layer (SSL)⁄Transport
 Security Layer (TLS). On top of encryption, the following options are
 available:

 - User login with passwords and granular authorization;

 - Transfer with authorization code to prevent unintentional transfers;

 - Limited access per second to avoid data harvesting;

 - Monitored update allows ownership data to be changed only after manual
 checks;

 - Temporary take-over by the Registry Operator in case of Registrar
 bankruptcy;

 - Domain lock avoids malicious transfers;

 - On-hold status can be set pending an Alternative Dispute Resolution (ADR)
 case;

 The Registry Platform provides a minimum of two anycast addresses, nodes in
 52 locations around the world and a capacity of over 500 billion queries a
 day with a resolution rate of under one millisecond. Each node is set up in
 a redundant configuration so that a hardware failure on one machine does not
 prevent the node from responding to queries.

 The Registryʹs primary server location is located in Belgium, in a secure,
 state-of-the-art facility. Special care has been taken to provide several
 physical layers of security. The Registry database and application servers
 will be hosted there, with a mirror site in Luxembourg. The Registry
 Platform is connected using multiple Internet Service Providers (ISPs), all
 of them Tier 1 providers.

 The applications run on a blade infrastructure, allowing for immediate
 recovery in the case of failure of any one element and providing easy
 scalability. The setup provides micro-cloud functionality that allows for
 easy scalability and multiple layers of redundancy. The local backup (warm
 standby) server is kept current by a stream of write-ahead log records, so
 it can take over as the master server with minimal delay. Name servers are
 distributed over the world for load balancing and robustness. External
 parties provide anycast functionality. The unicast nodes provided are set up
 in a redundant configuration so that a hardware failure on one machine does
 not prevent the node from responding to queries.

 All the Registry data are stored on a cluster of database servers, both on
 the primary and on the mirror site. These databases are synchronized
 permanently. If the load on the production database is deemed too high to
 deliver excellent quality service, read-only copies are put in place for
 read-only service, such as WHOIS and Data Escrow, to off-load traffic from
 the main database. A special delayed recovery database is available on the
 primary site to be able to recover quickly from data corruption should it
 have spread to all on-line database servers.

 (View attachment for Figure 3: Registry Services interfacing the Registry
 Database)

 The Registry Platform is feature rich with a multitude of parameters that
 can be set to suit the applicantʹs requirements. At system level software
 modules and functionalities can be switched on and off by the system
 administrator.

 The Registry Platform contains all functionality required by ICANN for a TLD
 to operate efficiently through two main interfaces or more if necessary. The
 XML based EPP interface provides excellent means for Registrars who want to
 offer their customers a fully automated interface. A web interface provides
 extra functions that are difficult to automate next to a set of commands
 that are fully compatible with EPP.

 The audit trail ensures that from day one every single activity in the
 system is logged and copied, including all associated data. This allows for
 going back in time and examining the situation both before and after a
 transaction took place. Journaling is built straight in the database, so it
 is hassle free for programmers and works with all programming languages.

 The full and flexible audit log eliminates huge log files or endless
 searching. The audit log can be searched using filters and detailed search
 criteria, so the requested is found fast and efficiently.

 The system was created for the current gTLD Registry-Registrar-Registrant
 model but could easily accommodate a direct Registry-Registrant
 relationship, for which a web interface is particularly useful.

2. TECHNICAL FEATURES

2.1. WHOIS AND DOMAIN AVAILABILITY SERVICE (DAS)

 End users (Registrants) are expected to have access to the contact details
 of a domain name holder. The WHOIS module complies with the ICANN standards,
 but offers optional flexibility with two different accesses : the WHOIS
 giving the full details (if allowed) of the domain name holder, and DAS
 (Domain Availability Service) which only shows whether the domain name is
 available or not. WHOIS data is fully configurable to meet existing or
 future data protection requirements, with each field able to be switched on
 or off. It can be accessed via both a web interface (CAPTCHA protected,
 where the user needs to enter a verification code to avoid machine-generated
 queries) or via port 43.

 Open Registries may find other uses for their WHOIS data to benefit both the
 Registry Operator and Registrants, such as a search capable WHOIS on the
 domain name database to find domain names or registrants in a particular
 industry or area. Profiles can be set up to determine which information is
 displayed.

 WHOIS and DAS functionalities are described in detail in response to
 question 26.

2.2. DNSSEC ENABLED

 In compliance with ICANN requirements, the applied-for TLD will be DNSSEC
 enabled from day one. Additionally, a DNSSEC solution is offered for the
 Registrars that they can implement with minimum disruption to their own
 systems. The implementation of DNSSec is described in detail in response to
 question 43.

2.3. DNS SERVICE

 The DNS infrastructure consists of an own set of redundant unicast
 nameservers running various flavors of operating systems and DNS software,
 and a set of high quality anycast nameserver providers. These services are
 provided by machines distributed all over the world over the IPv4 and IPv6
 network and using DNSSEC.

 - Real-time DNS updates compliant with RFC 2136

 - DNS Services implemented using ISC BIND, compliant with RFC 1034, RFC
 1035, RFC 1101, RFC 2181, RFC 2182, and RFC 3007

 A detailed description of the DNS service is provided in the response to
 question 35.

2.4. TAILORED CONTACT TYPES

 When a domain name is registered, the Registrant must provide the Registrar
 of the domain name with valid and up-to-date contact information. In theory,
 by looking up the domain name in any public WHOIS database, anyone is
 supposed to be able to view this registration information, and thus contact
 the person or company that owns it (Registrant or Licensee). The Registry
 Platform allows specifying tailored contact types to suit the Registry
 Operatorʹs need. Each contact type can contain the default set of contact
 data or fields specified.

2.5. DYNAMIC ZONE FILES

 The Registry Platform provides a dynamic zone file update, ensuring that,
 when a domain name is registered, it is available for use immediately.

2.6. SUNRISE

 The Registry Platform accommodates multiple types of Sunrise arrangements,
 including first-come-first-served validations or a defined Sunrise window
 that sends all applications for validation. Rules for the sunrise period can
 be set such as the type and location of applicant and type, or the dates and
 geographical coverage of prior IP rights.

2.7. VALIDATION MANAGEMENT

 The Registry Platform can provide a direct link to any Clearinghouse that
 ICANN or the Domain Name Registry may choose, thus encouraging more brand
 owners to participate in the Sunrise. Validation options include selection
 of names which are excluded from registration, which are Premium names, and
 include an auction process for competing applications.

2.8. SRS REGISTRATION AND FLEXIBLE PERMISSIONS

 SRS is short for Shared Registry System. The Registry Platform offers,
 besides the access through EPP required by ICANN, the capability to register
 domain names via the web. The Registry Platform includes a module that
 allows for flexible permissions for all users. This is very useful to give
 different permissions to different types of users for different sets of
 actions, for example to define what certain Registrars or Resellers can or
 cannot do. These permissions can be applied to different transactions in the
 system, allowing staying in total control of the TLD.

2.9. REGISTRAR INTERFACE

 - Fully documented client Application Programming Interface (API)

 - Web interface to allow Registrars full control of names under their
 management

 - Easy to use and fully compatible with Extensible Provisioning Protocol
 (EPP)

 - Extra modules provide feature rich experience

2.10. EXTENSIBLE PROVISIONING PROTOCOL (EPP)

 - Full EPP compliance with RFC 3730 and RFC 4930

 - Supports standard EPP object mappings for an Internet Domain Name Registry
 RFC 4931, RFC 4932, and RFC 4933

 - Multi-layer authentication

 - Includes support for implementing EPP extensions

 - Highly configured EPP Service to ensure that Regulator and Registry
 Operator Policy is adhered to with minimal intervention

 - Works with any RFC compliant EPP server

 A detailed description of the implementation of EPP is provided in response
 to question 25.

2.11. HIDDEN MASTER NAMESERVERS

 The master nameserver, which interfaces directly with the Registry Database,
 provides all slave nameservers with the current registration and database
 information, but cannot be accessed by third party users. This provides
 optimal security and integrity for the Registry Database.

2.12. VARIABLE RENEWAL PERIOD

 The Registry Platform allows for configuration of the renewal period, with a
 maximum of 10 years. By default, the domain name registration period is
 extended with one year, but this could be set to any period within the
 limits imposed by ICANN during the explicit renewal.

2.13. LENGTH LIMITATIONS

 The Registry Platform allows for the definition of criteria in terms of the
 length of the registered domain name. This feature can be used for example,
 to avoid the creation of two and three letter domain names within the TLD.

2.14. STRING BLOCKING

 This feature allows for blocking of simple or complex ʹstringsʹ from being
 used in domain names. Examples include geographic names, sensitive medical
 terms, or foul language.

2.15. AUTOMATIC TRANSFER HANDLING

 The Registry Platform is capable of automatically handling all transfers
 using a proven automated process. When a transfer is initiated, the current
 registrar receives a notification. This procedure is described in our
 response to Question 27 (Domain Life Cycle) and the Domain Name Registration
 Policy.

2.16. REGISTRAR DASHBOARD

 The Registrar has a dashboard to verify the current status of the registrar
 account. This includes a number of statistics on domain names in portfolio,
 domain names recently registered, transferred in and out, etc. These
 statistics are also provided over a longer period of time, allowing the
 registrar to conduct statistical analysis of the portfolio. The interface
 also provides an overview of transaction failures and the reason why, if
 applicable. It also shows a detailed financial status.

2.17. REGISTRAR EXPORT

 The Registrar web provides a separate page where the Registrar has bulk
 access to the entire portfolio of domain names, contacts and all other
 useful information stored in the database linked to the Registrarʹs account.
 The data is available in various formats including XLS, CVS and XML. This
 provides the Registrar with ample facility to verify portfolio and import
 data into and verify data against any external system used by the Registrar.

2.18. INTERNATIONALIZED DOMAIN NAME (IDN)

 The Registry Platform is IDN compatible and does not rely on the domain name
 registrar to convert natural script into punycode. The Registrar simply
 needs to enter the required information in natural language and the Registry
 Platform will do the rest. This applies for both EPP and web interfaces.
 Activation of the IDN feature is not foreseen for the applied-for gTLD.

3. FINANCIAL FEATURES

3.1. PRICING MODEL

 The Registry Platformʹs management module allows the Registry Operator to
 create pricing models as needed. Prices can be set for each type of
 operation and can have an associated validity period. Price changes can
 easily be implemented and put in the system with a specific starting date.

3.2. PRE-PAYMENT SYSTEM

 For each domain name Registrar, an account is provisioned in the Registry
 Platform. Every paying transaction reduces the account balance by the
 corresponding fee. When the account does not contain enough funds, the
 transaction will not finish successfully. This method eliminates the risk of
 bad debtors. Invoices are generated at the end of each month for the
 transactions executed and paid for in the previous period. This flexible
 system also allows for a post-payment application.

3.3. CREDIT LINES

 While the pre-payment system does not allow a Registrar to execute paying
 transactions, such as registering a new domain name, a credit mechanism is
 available that allows the Registry Operator to give a Registrar a credit
 line for a specific period and a specific amount. During that period, the
 Registrarʹs account may temporarily run negative for the specified amount.

3.4. INVOICING

 The Registry Platform implements explicit renewals. Payments must be made
 with the Registrarʹs pre-payment accounts, although the Registry Operator
 can give a particular Registrar a credit line for a specific period. Monthly
 invoices, detailing all transactions that have occurred in the previous
 month, are generated by the Registry Platform.

3.5. PAYMENTS

 The Registry Platformʹs management module keeps track of all payments that
 have been entered into the system. Registrars can access their complete
 invoice and payment history via the web interface.

3.6. EARLY WARNING SYSTEM

 The Registry Platform contains a system of threshold to prevent the
 Registrarʹs account from going negative. When the prepay account drops below
 a certain threshold level, an email will be sent to the Registrar to inform
 him, thus allowing the Registrar to transfer sufficient funds into the
 account in time.

4. THIRD PARTY MODULES

4.1. ALTERNATIVE DISPUTE RESOLUTION (ADR) EXTRANET

 In the event that a dispute arises over a domain name, the status of the
 domain name in question needs to be blocked. This is required to prevent the
 current holder from changing crucial data. As timing is very important, the
 Registry Platform includes a simple interface for the Alternative Dispute
 Resolution (ADR) provider that allows placing the disputed name on hold or
 in use again according to the outcome of the deliberation. Furthermore, if a
 complaint is launched against a domain name, the Registry Operator can
 permit the ADR dispute resolution service provider to log in and suspend any
 transactions on the name until the process is complete. When the dispute is
 resolved, the ADR provider can either remove the suspension or force a
 transfer according to the applicable rules and procedures of the UDRP
 (Uniform Domain-Name Dispute Resolution Policy).

4.2. SUNRISE PROCESS MANAGEMENT

 The Registry Platform accommodates multiple types of Sunrise arrangements,
 including first-come-first-served validations or a defined Sunrise window
 that sends all applications for validation. Rules for the Sunrise period can
 be set, for example, the type and location of applicant and type, or the
 dates and geographical coverage of prior IP rights.

4.3. VALIDATION MANAGEMENT

 The Registry Platform can provide a direct link to any ClearingHouse that
 ICANN or the Domain Name Registry may choose, thus encouraging more brand
 owners to participate in the Sunrise. Validation options include selection
 of names which are excluded from registration, which are Premium names, and
 include an auction process for competing applications. The Registry Platform
 is by default compliant with the Trademark Clearinghouse.

4.4. ESCROW MODULE

 The escrow module allows for an easy transfer of full and incremental
 backups to one of ICANNʹs accredited escrow providers. Reports of all
 exchanges are kept and combined in a monthly report. Emergency backup
 procedures and verification scripts can be added.

 A detailed description of the data escrow is provided in the response to
 question 38.

1. OVERVIEW

 The Shared Registration System (SRS) is a computer system for managing a
 domain name Registry, and allows for the registration, by authorized
 Registrars, of domain names and modification of information associated with
 that domain name on the Registry level.

 The SRS has two matching subsystems: an Extensible Provisioning Protocol
 (EPP) server and a Registrar web interface.

2. HIGH-LEVEL SRS SYSTEM DESCRIPTION

2.1. INFRASTRUCTURE

 The SRS platform consists of several services. These services provide the
 Registrar with access to the database. Registrarʹs access is limited to
 objects created and maintained by the Registrar. No other means than the SRS
 are provided to the Registrar to modify objects. The SRS system runs on a
 virtualized and strictly separated infrastructure to maintain consistency
 and security and provide for scalability and availability. For more
 information, reference is made to the relevant sections in question 31
 (Technical Overview of the Proposed Registry), question 32 (System & Network
 Architecture) and Q33 (Database Capabilities).

2.2. EXTENSIBLE PROVISIONING PROTOCOL

 As required by Specification 6 (section 1.2) and as detailed in the answer
 on Question 25 on the Extensible Provisioning Protocol (EPP), the Registry
 Operator will comply with the relevant existing RFCs. The Registry Operator
 will also, if applicable, implement the relevant RFCs published in the
 future by the Internet Engineering Task Force (IETF) including all successor
 standards, modifications or additions thereto relating to the provisioning
 and management of domain names using the Extensible Provisioning Protocol
 (EPP) in compliance with RFCs 5910, 5730, 5731, 5732, 5733 and 5734.

 Extensive testing will verify that the software performs according to the
 performance specifications as required by Specification 10 for EPP.

 The response to question 25 provides full details on the EPP implementation.

2.2.1. SECURITY

 Access to the EPP server system is restricted in three ways:

 - Access control to the production EPP server is restricted by IP address
 filters;

 - SSL encryption is required for the communication channels between the
 Registrarʹs client system and the OT&E (Operation Test & Evaluation) and
 Production EPP servers;

 - Authentication by means of a user name and a strong password is required
 for session establishment.

 The EPP server requires that all three mechanisms must be correctly adhered
 to before access is granted.

 The IP addresses from which the Registrar wants to connect to the EPP server
 must be registered through the Registrar web interface (maximum 5 IP
 addresses per Registrar, subject to evaluation).

2.3. REGISTRAR WEB INTERFACE

 The Registry Operator will, in addition to the EPP server system, also run a
 Registrar web interface. This web interface can be used besides or instead
 of the EPP server interface to manage the registration and modifications of
 domain names and the information associated with those names.

 The web interface has two parts: managing the objects in the domain name
 Registry database, and managing the Registrarʹs business account
 information.

2.3.1. MANAGING OBJECTS IN THE DOMAIN NAME REGISTRY DATABASE

 The management of the objects in the database via the web interface is based
 on the same software code as for the EPP server implementation. The
 different subparts of managing the objects in the database are: maintaining
 domain names, maintaining contacts and maintaining hosts.

 - Maintain Domain: The interface allows to easily find, check, query, add,
 update, renew, transfer or delete domain names from the Registrar account.
 As an extra feature, the history of the domain name can be explored (as
 long as the domain name resides in the Registrarʹs account).

 - Maintain Contact: The interface allows to easily find, check, query, add,
 update or delete contact information. Also the history of the contact can
 be listed (as long as the contact stays in the Registrarʹs account).

 - Maintain Host: The interface allows to simply find, check, query, add,
 update or delete host information from the Registrar account. Also the
 history of the host object can be viewed (as long as the host object is in
 the Registrarʹs account).

2.3.2. MANAGING THE REGISTRAR ACCOUNT

 The Registrar Profile page allows the Registrar to:

 - View, add and update own contact information for administrative,
 technical, commercial and financial purposes;

 - Add and update the IP addresses required for access to the EPP server (see
 above);

 - Add and update the different email addresses of the Registrar where he can
 be reached by the Registry Operator for administrative, technical and
 financial purposes; and

 - View hitpoints (attributed when the EPP client software behaves
 erratically), and resume the Registrar account (when hitpoints reach a
 defined threshold, the Registrar account is suspended temporarily).

 The financial information pages reveals:

 - Account balance overview;

 - Overview of invoices and payments, with details; 

 - Overview of possible renewals in coming months.

 The reports page provides customized reports on gained and lost domain names
 (via transfers), on nearly expired domain names and on the latest
 transactions (per object type and transaction type).

 The export page offers downloads of full exports of contacts, domain names
 and hosts in different formats (CSV, XLS, XML), to allow the Registrar to
 consolidate and cross-check his own data.

2.3.3. SECURITY

 Access to the Registrar web interface is restricted in three ways:

 - HTTPS encryption is required for the communication between the Registrar
 and the OT&E and production Registrar web interfaces;

 - Authentication by means of a user name and password is required; and

 - Extra passphrase authorization to confirm transactional commands
 (create⁄modify⁄delete).

 All communication is encrypted and secured using the SSL⁄TLS protocol. The
 main idea of HTTPS is to create a secure channel over an insecure network.
 Adding a trusted and verified server certificate ensures reasonable
 protection from eavesdroppers and man-in-the-middle attacks.

 Security is augmented by requiring an extra passphrase authorization to
 complete all transactional commands on the SRS system.

2.3.4. REDUNDANCY & SCALABILITY

 The SRS system runs on a mini-cloud virtualizing all machine infrastructures
 needed (for further information on, for instance the number of servers, see
 question 32). Not only does this improve high-availability and scalability,
 it also allows for very fine grained access control improving security and
 mitigating network cross connections. The cloud can be distributed over the
 two sites allowing for a full hot-standby mirror site. Using network based
 traffic mirroring, resources are scaled and load balancing and fail-over are
 implemented.

 The synchronization scheme for the Registry database, which contains all
 information used by the Shared Registration System, is described in full
 detail in the response to question 33 (Database Capabilities). The database
 is continuously synchronized.

 Dynamic updates are implemented on the nameserver infrastructure. All
 changes to the database are immediately synchronized to the worldwide
 nameserver infrastructure, with an average delay of 10 seconds.

3. RESOURCING PLAN

3.1. TECHNICAL RESOURCES

3.1.1. NETWORK

 The Registry Platform is based on a full redundant network setup, based on
 different technologies that together form a reliable setup. The network
 setup is greatly detailed in the answer on Question 32 on Network & System
 Architecture, and consists of:

 - Multi-homed network with own IP-range and Autonomous System number (AS)
 announce via Border Gate Protocol (BGP);

 - Redundant routers and firewalls;

 - Fully redundant internal network for interconnection between the Registry
 Services.

 - Network security measures include: 

 - Traffic shaping (on SYN packets) on the routers to minimize impact of
 (Distributed) Denial Of Service attacks;

 - Stateful firewall to limit access to service ports only;

 - Limiting source IP addresses per Registrar to connect to EPP server
 system;

 - Network separation using VLAN (IEEE802.1q) technology to separate service
 and data plane;

 - Private firewall on every server.

3.1.2. SERVERS

 The EPP server and the Registrar web interface are running on their own
 respective machines. Virtualization is used to make the service machines
 independent of the underlying hardware.

3.1.3. INTERCONNECTIVITY WITH OTHER REGISTRY SERVICES 

 The Shared Registration System (SRS) maintains the objects in the core
 database from a Registrarʹs perspective. All other Registry systems such as
 the WHOIS service, the data escrow system, the (dynamic) zone file
 generator, etc. use the core database.

 The Registry Operator implements a thick Registry model, and as such the
 full data are present in the core database. There is no need to synchronize
 the data from different source databases into the master database.

 As detailed in the answer on Question 33 on Database Capabilities, the
 Registry Operator is using hot-standby database replication for redundancy
 and fail-over, and if the load on the system should require so, the WHOIS
 system can be off-loaded to another hot-standby read-only copy of the core
 database, which is near-synchronous with the main database.

 Note that the network and system setup on the primary site is duplicated on
 a mirror site.

 (View attachment for Figure 1: Interplay of Registry Services)

 Other services such as the dynamic updates of the zone file, zone file
 generation and escrow use the database or a trigger mechanism to update the
 relevant resources when the Registrar updates objects in the database.

 All changes to the database are tagged and linked to a transaction
 description also specifying the relevant time stamp, user and IP address.
 The information can be used to provide a full audit trail or to pinpoint
 invalid or illegal behavior.

3.2. PERSONNEL

 With regards to resourcing, reference is made to the global resourcing
 scheme as part of response to Question 31 (Technical Overview of the
 Proposed Registry). Implementation and maintenance of the Shared
 Registration System is under the authority of the Software Developer, under
 control of the Operations Manager. The technical infrastructure is
 implemented and maintained by the Network & System Administrator.
 

1. OVERVIEW

 The Registry Operator will comply with the latest version of the Extensible
 Provisioning Protocol (EPP). The domain name Registry is designed to strict
 EPP standards from the ground up. No proprietary EPP extensions have been
 developed. Upon selection of the Trademark Clearinghouse (TMCH) provider by
 ICANN, the EPP implementation will be complemented with an interface towards
 the TMCH, in line with community defined interface specifications.

2. EPP REGISTRY – REGISTRAR MODEL

 The domain name registry implementation features a ʺthickʺ model as
 represented by the rich object store managed by the centralized domain name
 registry.

 This object store can be managed by accredited Registrars via the EPP
 interface that will be using the interface protocol specified by the current
 EPP standard.

 The EPP specification is broken up into an extensible object design with
 each of the primary objects given an individual but consistent interface
 that meet the base EPP framework as described below.

2.1. EPP PROTOCOL HIGHLIGHTS

2.1.1. RFC 5730 - EXTENSIBLE PROVISIONING PROTOCOL (EPP)

 This document describes the foundation upon which all the specific objects
 (Domain names, Hosts, Contacts) must adhere to in order to maintain a
 consistent interface. A standard domain name registry specific extensible
 object management framework is also described in this document to handle any
 extra information need to satisfy policy or other agreements the domain name
 registry may be required to sustain.

2.1.2. RFC 5731 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) DOMAIN NAME MAPPING

 This document describes an EPP mapping for the provisioning and management
 of Internet domain names stored in a shared central repository. Specified in
 XML, the mapping defines EPP command syntax and semantics as applied to
 domain names.

2.1.3. RFC 5732 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) HOST MAPPING

 This document describes an EPP mapping for the provisioning and management
 of Internet host names stored in a shared central repository. Specified in
 XML, the mapping defines EPP command syntax and semantics as applied to host
 names.

2.1.4. RFC 5733 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) CONTACT MAPPING

 This document describes an EPP mapping for the provisioning and management
 of identifiers representing individuals or organizations (known as
 ʺcontactsʺ) stored in a shared central repository. Specified in XML, the
 mapping defines EPP command syntax and semantics as applied to contacts.

2.1.5. RFC 5734 - EXTENSIBLE PROVISIONING PROTOCOL (EPP) TRANSPORT OVER
TRANSMISSION CONTROL PROTOCOL (TCP)

 This document dictates the TCP connection strategies to use. The implemented
 transport layer is conform to RFC 5734 and RFC 2246. RFC 5734 specifies the
 low level transport and allows for a typical TCP connection to be used to
 serve as a client-server communication channel. To secure the communication
 between client and server, an obligatory Transport Layer Security (TLS)
 layer is run on top of the TCP connection, as specified in RFC 2246.

 A number of security settings no longer comply with current security needs
 and are prohibited in RFC 6176. The security algorithms that are allowed to
 communicate were chosen to be secure and compliant with a wide variety of
 implementations currently in use on most operating systems. These security
 algorithms include Advanced Encryption Standard (AES) and Triple Data
 Encryption Standard (TripleDES) for encryption and RSA for negotiation.

2.1.6. RFC 5910 - DOMAIN NAME SYSTEM (DNS) SECURITY EXTENSIONS MAPPING FOR THE
EXTENSIBLE PROVISIONING PROTOCOL (EPP)

 This document describes the DNSSEC Extensions Mapping for EPP for the
 provisioning and management of DNS security extensions stored in a shared
 central repository. Specified in XML, the mapping defines EPP DNSSEC
 extensions to the command syntax and semantics as applied to domain names.

2.1.7. RFC 3915 - DOMAIN REGISTRY GRACE PERIOD MAPPING FOR THE EXTENSIBLE
PROVISIONING PROTOCOL (EPP)

 This document describes the Registry Grace Period (RGP) Extensions Mapping
 for EPP for the management of domain names subject to ʺgrace periodʺ
 policies defined by ICANN. Specified in XML, the mapping defines EPP RGP
 extensions to the command syntax and semantics as applied to domains.

2.2. SUPPORTED COMMAND SET

 A full set of EPP commands is implemented, as specified in the above
 mentioned RFCs. The EPP service provides all commands specified in the RFCs
 5730, 5731, 5732, 5733, 3915 and 5910 in a fully functional fashion. The
 commands are implemented conform the specifications set forth in the RFCs.
 The fully compliant XSD schema describing the XML layout which can be used
 to validate the XML command can be found in RFC 5730-5733, 3915 and 5910.

 Please note that two extensions are implemented:

 - RFC 3915 is a specific extension to implement the ʺgrace periodʺ policies,
 both in providing extra information to the Registrar, as well as the
 possibility to restore a domain name from redemption.

 - RFC 5910 is a specific description to comply with the DNSSEC extension, as
 is required by the Applicant Guidebook, to manage the DNSSEC keys of the
 domain name.

 The domain name registry will provide the following command sets to support
 the Registry Service:

 - Greeting

 - Session management
 
 - Object Query

 - Object Transform 

 All commands from the EPP client to the EPP server run over an encrypted
 connection. The EPP client has to identify itself by using the predefined
 session management command 〈login〉 using unique and out-of-band communicated
 credentials.

 The command sets are described in detail below.

2.2.1. GREETING

 The EPP server will respond to a successful connection by returning a
 greeting to the client. The greeting response includes information such as:

 - The name of the server

 - The serverʹs current date and time in Coordinated Standard Time (UTC)

 - The features supported by this server, which may include:

 * One or more protocol versions supported by the server

 * One or more languages for the text response supported by the server

 * One or more 〈objURI〉 elements which identify the objects which the
 server is capable of managing

 * An optional 〈svcExtension〉 element that contains one or more 〈extURI〉
 elements that contain namespace URIs representing object extensions
 supported by the server. Here the EPP server will announce support for
 rgp-1.0 (as defined in RFC 3915) and for secDNS-1.1 (as defined in RFC
 5910).

 At any time a 〈hello〉 command can be used to receive a 〈greeting〉 response.

2.2.2. SESSION MANAGEMENT

 EPP provides two commands for session management: 〈login〉 to establish a
 session with a server, and 〈logout〉 to end a session with a server.

 - Login: The EPP 〈login〉 command is used to establish a session with an EPP
 server in response to a greeting issued by the server. A 〈login〉 command
 MUST be sent to a server before any other EPP command.

 - Logout: The EPP 〈logout〉 command is used to end a session with an EPP
 server.

2.2.3. OBJECT QUERY COMMANDS

 EPP provides three commands to retrieve object information: 

 - 〈info〉 to retrieve detailed information associated with a known object,

 - 〈check〉 to determine if an object is known to the server, and 

 - 〈transfer〉 to retrieve known object transfer status information. These are
 described into further detail below.

 Info: The EPP 〈info〉 command is used to retrieve information associated with
 a known object. The elements needed to identify an object and the type of
 information associated with an object are both object-specific, so the child
 elements of the 〈info〉 command are specified using the EPP extension
 framework.

 Check: The EPP 〈check〉 command is used to determine if an object is known to
 the server. The elements needed to identify an object are object-specific,
 so the child elements of the 〈check〉 command are specified using the EPP
 extension framework.

 Poll: The EPP 〈poll〉 command is used to discover and retrieve notification
 messages queued by the server for individual Registrars. Some elements are
 object-specific, so the child elements of the 〈poll〉 response are specified
 using the EPP extension framework.

 Transfer (Query): The EPP 〈transfer〉 command provides a query operation that
 allows a client to determine real-time status of pending and completed
 transfer requests. The elements needed to identify an object that is the
 subject of a transfer request are object-specific, so the child elements of
 the 〈transfer〉 query command are specified using the EPP extension
 framework.

2.2.4. OBJECT TRANSFORM COMMANDS

 EPP provides five commands to transform objects:

 - 〈create〉 to create an instance of an object with a server, 

 - 〈delete〉 to remove an instance of an object from a server,

 - 〈renew〉 to extend the validity period of an object,

 - 〈update〉 to change information associated with an object, and

 - 〈transfer〉 to manage changes in client sponsorship of a known object.
 These are described into further detail below.

 Create: The EPP 〈create〉 command is used to create an instance of an object.
 An object may be created for an indefinite period of time, or an object may
 be created for a specific validity period. The EPP mapping for an object
 MUST describe the status of an object with respect to time, to include
 expected client and server behavior if a validity period is used.

 Delete: The EPP 〈delete〉 command is used to remove an instance of a known
 object. The elements needed to identify an object are object-specific,
 therefore the child elements of the 〈delete〉 command are specified using the
 EPP extension framework.

 Renew: The EPP 〈renew〉 command is used to extend the validity period of an
 object. The elements needed to identify and extend the validity period of an
 object are object-specific, therefor the child elements of the 〈renew〉
 command are specified using the EPP extension framework.

 Transfer: The EPP 〈transfer〉 command is used to manage changes in client
 sponsorship of a known object. Clients may initiate a transfer request,
 cancel a transfer request, approve a transfer request, and reject a transfer
 request.

 Update: The EPP 〈update〉 command is used to change information associated
 with a known object. The elements needed to identify and modify an object
 are object-specific, therefore the child elements of the 〈update〉 command
 are specified using the EPP extension framework.

 All above transform commands can be processed by the Registry Operator in
 two ways:

 - immediately process the requested action;

 - initiate processing the requested action, but allow for off-line review or
 further interaction before completing the requested action. The response
 of the EPP server will clearly note that the requested action is 
 ʺpendingʺ.

 In the latter case the state of the corresponding object will clearly
 reflect processing of the pending action. For more information on the domain
 name states, reference is made to the response to Question 27 (Domain Name
 Lifecycle).

2.3. FUNCTIONALITY TO PROVISION REGISTRY SERVICES

 To comply with the current EPP standard, a fully functional set of commands
 is at the Registrarʹs disposal. These functions are based on the CRUD
 (Create – Read – Update – Delete) principle. The state of the data is
 maintained by creating (C), reading (R), updating (U) and eventually
 deleting (D) the data from the database.

 The following basic objects exist in the database:

 - Domain: The domain object contains all relevant information to the domain
 name. This includes registration date, renewal date, status and DNSSEC key
 material.

 - Host: A host object defines a hostname which might be linked to a domain
 name. It is intrinsically needed to get the domain name working. It
 contains at least a domain name, possibly IP addresses and other
 references.

 - Contact: The contact object specifies a person or an organization. It
 contains various fields to identify such party. When linked to a domain
 name, a specific role is attributed to the relation.

 The following commands, per object, allow for the full CRUD cycle to be
 implemented conform the above specified relevant RFCʹs. Please note that the
 read commands as referred to in the CRUD terminology are defined as query
 commands in the EPP-centric documentation. All objects are attributed to a
 specific Registrar and remain under its supervision. No other Registrar is
 granted access to these objects.

 Registrars should first verify if the object is manageable (and owned) by
 using the 〈check〉 command. To get the content of an object, use the 〈info〉
 command.

 (View attachment for Table 1: Commands per object type)

 By assigning a Registrar to all objects, a unique identifiable party is
 assigned to any object as the owner that is allowed to change and delete the
 object. To maintain a history of all changes, both a full trace log
 identifying Registrar, IP address, time and command as well as a history of
 the objects are stored in the database. This allows for a swift
 reconstruction of any interaction with the system. For more information we
 refer to the response to Question 33 of the evaluation criteria (Database
 Capabilities).
 
 To avoid confusion on the responsibility of contact objects, the Registry
 Operator will not allow transfers of such contact objects between
 Registrars. A contact object will always remain under maintenance of the
 Registrar that created it. As a consequence the Registry Operator will
 complete a transfer domain operation by implicitly cloning all contact
 objects attached to the domain under transfer, so that the gaining Registrar
 will have full control over his contact objects.

3. EPP EXTENSIONS

 In order to be compliant with ICANNʹs Applicant Guidebook, an additional
 extension to maintain the domain object is needed to integrate with the
 Trademark ClearingHouse (Module V of ICANNʹs Applicant Guidebook).

 At the moment, no party has been appointed to perform the TradeMark
 Clearinghouse function, hence no specifications for interfacing have been
 established.

 The function of the TradeMark Clearinghouse is to enable trademark holders
 to register their right in a central database, from where the trademark
 holder receives a validation code that can be used to apply for a domain
 name in a new TLD.

 To that extent, ongoing community effort led already to a Launch Phase
 Mapping for EPP. This Internet-Draft describes an extension mapping for EPP
 that specifies a flexible scheme that can be used to implement several
 common use cases related to the provisioning and management of launch phase
 extension in a domain name registry.

 This mapping enables the Registrar to apply for⁄claim a domain name in the
 sunrise phase using the Pre-Validation Result Code 〈pvrc〉 from the TM
 Clearinghouse.

4. SECURITY

 It is imperative to make sure the service is not blocked by Denial Of
 Service attacks (DOS). To prevent this from happening, a number of security
 barriers are in place:

 - rate limiting the number of connections on the border router;

 - allowing only specific IP addresses specified by the Registrar;

 - limiting the number of concurrent connections per Registrar.

 The EPP service will run on its own virtual machine. Resources available to
 the machine are constantly monitored. Early warnings are sent out in case
 any of the resources are deemed to be inadequately provisioned.

 Security is enhanced by limiting the access to the EPP server to a Transport
 Layer Security (TLS) connection using high-grade encryption.

 The Registrar is authenticated using the predefined session commands as
 defined in the above RFCs. The initial credentials are exchanged between the
 Registry Operator and the Registrar over an out-of-band channel.

 A strict object-to-Registrar link exists such that a Registrar can only
 view, access and modify its own managed objects.

5. RESOURCING PLAN

5.1. TECHNICAL RESOURCES

 This service is delivered by a JAVA application running on a TOMCAT server.
 To ensure the database is consistent at all times, a lock is set per
 Registrar to ensure multiple connections set up by a Registrar are
 serialized at the application level. To maintain high speed at all time, a
 locking mechanism is also active at the domain name level, ensuring no two
 domain name registrations for the same domain name are modified, while still
 allowing the necessary concurrency.

 Experience has learned that, under high load conditions, the bottleneck will
 rather be located at the database level, and not at the application level.
 If extra CPU power is required to deal with high volumes, an extra EPP
 service will be provided using an alternate IP address or using a load
 balancer.

 To improve database security, the EPP serverʹs access to the database is
 limited to a specific separate network. For a more complete and detailed
 picture, reference is made to the response to Question 32 of the evaluation
 criteria (System & Network Architecture).

5.2. PERSONNEL

 With regards to resourcing, reference is made to the global resourcing
 scheme as part of response to Question 31 (Technical Overview of the
 Proposed Registry). Implementation and maintenance of the Extensible
 Provisioning Protocol is under the authority of the Software Developer,
 under control of the Operations Manager. The technical infrastructure is
 implemented and maintained by the Network & System Administrator.

1. OVERVIEW

 The Registry Operator will operate a WHOIS service available via port 43 in
 accordance with RFC3912. This standard service is intended as a lookup
 service for Registry Operators, Registrars, Registrants, as well as for
 other individuals and businesses that wish to query details of domain names
 or nameservers stored in the domain name Registry and that are public. The
 standard WHOIS service provides a central location for all authoritative
 data the Registry has on the domain name. The Registry Operator also
 provides a front-end web interface to allow for convenient user access to
 the WHOIS service.

 The Registry Operator will also operate a Domain Availability Service (DAS)
 via port 4343. Reference is made to section 5 of this response for further
 detail.

 All WHOIS⁄DAS services are connected to the main domain name Registry
 database. If and when it is necessary for operational stability reasons, the
 WHOIS server can be duplicated, and connected to one or more read-only hot
 standby database mirrors. These mirrors are updated a-synchronously via
 streaming replication, which results in a near real-time data duplication.

2. WHOIS SERVICE

2.1. RFC-3912 COMPLIANT WHOIS

 The RFC3912-conformant WHOIS service is engineered to handle moderate
 transaction load and is part of the standard suite of Registry Services. The
 WHOIS service will return a single response per domain name or nameserver
 query. The RFC3912-conform WHOIS service will comply with the requirements
 of Specification 4 of the Registry Agreement.

 The RFC3912-compliant service provided by the Registry Operator will have
 the following features:

 - Standard protocol accessible over the common WHOIS port 43;

 - Near real-time updates;

 - The format of responses follows a semi-free text format outline below,
 followed by a blank line and a legal disclaimer specifying the rights of
 the Registry Operator, and of the user querying the database;

 - Each data object is represented as a set of key⁄value pairs, with lines
 beginning with keys, followed by a colon and a space as delimiters,
 followed by the value;

 - For fields where more than one value exists, multiple key⁄value pairs with
 the same key are allowed (for example to list multiple name servers). The
 first key⁄value pair after a blank line should be considered the start of
 a new record, and should be considered as identifying that record, and is
 used to group data, such as hostnames and IP addresses, or a domain name
 and Registrant information, together; and

 - The format of the following data fields is: domain status, individual and
 organizational names, street, city, state⁄province, postal code, country,
 telephone and fax numbers, email addresses, date and times conform to the
 mappings specified in EPP RFCs 5730-5734 so that the display of this
 information (or values return in WHOIS responses) can be uniformly
 processed and understood.

2.2. WHOIS SERVICE DATA ELEMENTS

 The RFC3912-conform service will include the following data fields:

 - The name of the domain name registered;

 - The IP addresses of the primary nameserver and secondary nameserver(s) of
 the name registered, if applicable, and the corresponding names of those
 nameservers;

 - The identity of the Sponsoring Registrar;

 - The original creation date and term of the registration;

 - The name, postal address, e-mail address, voice telephone number, and (if
 available) fax number of the domain name Registrant;

 - The name, postal address, e-mail address, voice telephone number, and (if
 available) fax number of the technical contact for the domain name
 registered;

 - The name, postal address, e-mail address, voice telephone number, and (if
 available) fax number of the administrative contact for the domain name
 registered; and

 - The occupation, speciality, license id, license issuing authority, last
 verification date of the registrant; these information are provided by the
 Medical Clearinghouse.

2.3. WHOIS DATA UPDATE FREQUENCY

 The Registry Operator will be running a thick registry model, so the data
 will be readily available and doesnʹt need to be collected from the
 Registrars. The WHOIS service will query the main database, or, if database
 load or operational reasons demand, will query a hot standby read-only
 database mirror. In case of querying the main database, the data is always
 up-to-date, in case of querying a mirror database, the data is updated
 continuously via streaming replication and is near real time up-to-date (in
 a matter of seconds or minutes).

2.4. PRIVACY CAPABILITY

 The Registry Operator will protect the privacy of an individual where
 required. If the Registrant of a domain name is an individual, the WHOIS
 service could disclose only limited information on the Registrant. If the
 Registrant wishes to disclose more information, he can instruct the
 Registrar to update the corresponding contact object in the Registry
 database (e.g. using the 〈contact:disclose〉 statement in EPP according to
 RFC5733).

 If legislation mandates to avoid automatic harvesting of the Registrantʹs
 details (because port 43 WHOIS is plain text), the WHOIS service could omit
 the Registrant details and refer the initiator of the query to the web-based
 WHOIS where the WHOIS data will be disclosed in a multiple-step process.

2.5 QUERY CONTROL – OBJECT TYPE CONTROL

 The following keywords restrict a search to specific object type:

 - Domain: Search only by domain objects. The input string is searched in the
 Domain Name field.

 - Contact: Search only contact objects. The input string is searched in the
 Contact ID field.

 - Nameserver: Search only by nameserver objects. The input string is
 searched in the nameserver field and the IP address field.

 - Registrar: Search only Registrar objects. The input string is searched in
 the Registrar ID and Registrar Name fields.

 By default, if no object type control is specified, then the Name field of
 the Domain object is searched.

3. WHOIS OUTPUT FIELDS

3.1. DOMAIN RECORDS

3.1.1. INTRODUCTION

 The WHOIS server can answer a domain name query in three different ways:

 - The domain name is registered in the domain name registry database, a
 typical response is detailed in section 3.1.2;

 - The domain name is not registered, nor available for registration, because
 of various reasons, such as appearing on the blocked or reserved list, as
 specified in the Applicant Guidebook (see article 2.6 of the Registry
 Agreement), or for policy reasons. A typical response is detailed in
 section 3.1.3.

 - The domain name registry has no information on the domain name in the
 request. A typical response is detailed in section 3.1.4.

3.1.2. DOMAIN NAME IS REGISTERED

 A WHOIS query that results in domain name information will return the
 following fields from the domain object and the associated data from host
 and contact objects. This set of data is also referred to as the Domain
 Record.

 - Domain Name;

 - Domain ID;

 - Domain Status (several domain status codes can be shown here, such as OK
 or INACTIVE, a pending action status and⁄or restriction flags. An overview
 can be found in the response to Question 27 on Domain Name Lifecycle);

 - Sponsoring Registrar (IANA-assigned identifier) and name of Registrar

 - Registrant, Administrative, Technical Contact Information including:

 * Contact ID

 * Contact Name

 * Contact Organization

 * Contact Address, City, State⁄Province, Country

 * Contact Postal Code

 * Contact Phone, Fax, E-mail

 - Names of Nameservers and IP addresses (IPv4 and⁄or IPv6) associated with
 this domain

 - Creation Date

 - Domain Expiration Date

 - Domain Last Updated Date

 - DNSSEC status of delegation (signedDelegation, unsigned)

 For domain names that are registered in the sunrise phase, the WHOIS can
 show additional labels containing sunrise information (depending on the
 information provided by Trademark ClearingHouse, in accordance with
 Specification 7 in the Applicant Guidebook).

 Because registered domains are subject to approval by the Medical
 ClearingHouse, the WHOIS will show additional labels containing information
 provided by the said Medical ClearingHouse, in accordance with Specification
 4 in the Applicant Guidebook.

 An example of the extra labels provided by the Medical ClearingHouse is:

 MCH Registrant Occupation: Physician
 MCH Registrant Speciality: Family doctor
 MCH Registrant Licence: 12345678
 MCH Registrant Licence Issuing Authority: Example State Medical Board
 MCH Registrant Last Verification Date: 2013-04-06T12:35:49+02:00
 MCH Registrant Professional Information: http:⁄⁄mch.med⁄12345678
 
3.1.3 DOMAIN NAME IS NOT REGISTERED, BUT NOT AVAILABLE

 A WHOIS query for a domain name that is not registered in the domain name
 Registry database, but is also not available for registration, will result
 in a single line with the reason of non-availability (f.i. ʺReserved by
 Registryʺ or ʺBlocked by Registryʺ).

3.1.4 NO INFORMATION ON DOMAIN NAME

 A WHOIS query for a domain name for which the domain name registry has no
 information, will result in a single line stating ʺNOT FOUNDʺ.

3.2. NAMESERVER RECORD

 A WHOIS query that results in nameserver information will return the
 following (this set of information is referred to as the Nameserver Record):

 - Nameserver name
 
 - IP address (if applicable, IPv4 and⁄or IPv6)

 - Sponsoring Registrar (IANA-assigned identifier)

3.3. CONTACT RECORD

 A WHOIS query that results in contact information will return the following.
 This set of information is referred to as the Contact Record.

 - Contact ID

 - Contact Name

 - Contact Organization

 - Contact Address, City, State⁄Province, Country + 3 street fields

 - Contact Postal Code

 - Contact Phone, Fax (if available), E-mail

 - Create Date

 - Contact Last Updated Date

 - Contact Status (several contact status codes can be shown here, such as OK
 or LINKED, a pending action status and⁄or restriction flags)

 - Sponsoring Registrar (IANA-assigned identifier)

3.4. REGISTRAR RECORD

 A WHOIS query that results in Registrar information will return the
 following (this set of information is referred to as the Registrar Record):

 - Registrar ID (conforming to the IANA Registrar-ids registry)

 - Registrar Name

 - Registrar Address, City, State⁄Province, Country

 - Registrar Postal Code

 - Registrar Phone, Fax, E-mail

 - Registrar Administrative Contacts

 - Registrar Technical Contacts

 - Registrar Billing Contacts

4. MEASURES FOR ABUSE MITIGATION

 Measures are taken to protect the WHOIS port 43 service against bulk access:

 - The number of queries is limited per querying IP address in two different
 ways: a maximum number of queries per second, and a capped number of
 queries per hour. Excessive querying will result in a denial of the result
 of the query.

 - The web-based WHOIS implements a multiple-step process to obtain the
 queried data, and is protected by a CAPTCHA image. Here the number of
 queries per day per IP address is also capped.

 - Data-mining techniques are implemented to monitor the distribution of the
 querying clientʹs IP addresses. Anomalies will be brought under the
 attention of the Registry Operator for further evaluation.

 Often the reason for bulk access to the WHOIS service is querying the
 availability of the domain name (e.g. from Registrarʹs web front-ends).
 Therefore the domain name Registry Operator will also introduce a Domain
 Availability Service (DAS).

5. DOMAIN AVAILABILITY SERVICE (DAS)

 The DAS service will run on port 4343 and implements a very simple protocol,
 similar to the WHOIS protocol. The DAS service only indicates whether the
 given domain name is still available for registration or not, thereby not
 giving more information regarding the Registrant.

 The query format:
 
 whois -p 4343 EXAMPLE.TLD

 The response format: 

 Domain Name: EXAMPLE.TLD
 Available: yes

 Domain Name: EXAMPLE.TLD
 Available: no

 Bulk access to the DAS service is not discouraged, but, if required by
 stability concerns, the number of queries per second can be capped.

6. SEARCHABLE WHOIS CAPABILITIES

 The web-based WHOIS service will also offer the possibility to partially
 match the domain name field. The search string must be at least 4
 characters, and the wildcard operator ʹ*ʹ must be added at the beginning
 and⁄or at the end of the search string. The WHOIS service will then return a
 HTML page with a maximum of 10 matching domain names, which can be clicked
 to view full details.

 The search capabilities can only be explored by legitimate authorized users.
 Candidate users of this service need to apply for access to these features,
 giving a legitimate reason why they would need the service.

 If the applicable privacy laws and policies allow to do so, more search
 capabilities can be enabled on the web-based WHOIS service, conform to
 Specification 4 of the Applicant Guidebook.

 To prevent abuse of the service, all queries are stored per user. The number
 of queries per month is capped.

 The searchable WHOIS capabilities offers the same privacy rules as described
 above.

 Security and StabilityThe WHOIS setup has multiple overload protection
 systems in place:

 - At the border of the network, rate limiting is implemented; 

 - The stateful firewall prevents abuse from a single IP address; 

 - The IDS⁄IPS prevents malformed WHOIS requests from passing; 

 - To be able to maintain a high load of WHOIS queries, a cluster of virtual
 machines is set up. By using port replication or broadcast MAC, no
 load-balancing single points of failure are introduced;

 - If the WHOIS service load on the database experiences decreasing
 performance, as many extra read-only copies of the Registry database as
 needed can be set up and used by the WHOIS server(s) to provide extra
 WHOIS capacity. The capacity of the WHOIS service is therefore only capped
 by the rate limiting that is implemented at the network edge;

 - All WHOIS (port 43) cluster nodes run as separate virtual machines.

 (View attachment for Figure 1: WHOIS Network & Infrastructure Overview)

7. RESOURCING PLAN

 With regards to resourcing, reference is made to the global resourcing
 scheme as part of response to question 31 (Technical Overview of the
 Proposed Registry). Implementation and maintenance of the WHOIS and DAS is
 under the authority of the Software Developer, under control of the
 Operations Manager. The technical infrastructure is implemented and
 maintained by the Network & System Administrator.

1. Overview

 The registration life cycle for .MED Domain Name Registry is etched on the
 life cycle of an open brand TLD.

 However a stricter registration policy will be applied: at all times the
 registration of a domain name will be subject to validation by at least one
 Clearinghouse. During sunrises A and B, the Trademark Clearinghouse will be
 consulted. Outside sunrise A, a specific .MED Clearinghouse (Medical
 Clearinghouse) will be used. Also the request to update the registrant
 handle (change of ownership) will be passed to the Medical Clearinghouse .

 The following sections give an overview of the different actions that the
 Registrar can perform to influence the state of a domain name. Some might
 just change the state of the domain name. Others might alter the domain
 nameʹs information such as name servers, contacts, DNSSEC keys and client
 flags.

 Some actions also involve interaction from the domain name Registry
 Operator.

 The domain name Registry Operator will never allow free domain name
 registrations: all requests to register a domain name will need validation
 by a clearinghouse. Hence the Domain Name Registry will be operating in a
 permanent sunrise regime.

2. REGISTRATION LIFECYCLE

 The time line of a domain name is schematically provided in Figure 1.

 (View attachment for Figure 1: Domain Timeline)

 The following paragraphs provide more detail on the different steps in the
 time line.

2.1 REGISTRATION (UNDER SUNRISE REGIME)

 - The Domain Name Registry Operator receives the domain create command

 - The domain name goes into state pendingCreate

 - The clearinghouse does validation of the domain name for the registrant

 - The domain name is registered if properly validated, or canceled
 otherwise.

2.2 UPDATE

 - Add, remove or change of tech, admin, billing contact handle possible

 - Add, remove or change of name servers possible

 - Add, remove or change of DNSSEC keys possible

 - Update registrant handle will put the domain name in the pendingUpdate
 state. The change of ownership has to be validated by the Medical
 Clearinghouse. The update proceeds if the validation is successful, or it
 will be canceled otherwise. A successful update of the registrant handle
 will result in the extension of the registration period with one year.
 Regardless the outcome of the validation by the clearinghouse, the
 operation will be billed to the registrar.

2.3. TRANSFER

 - Transfer: change of Registrar

 - Transfer command secured by authentication code

 - Losing Registrar notified to accept or reject the transfer (after
 consulting registrant and⁄or admin contact)

 - A successful transfer extends the registration period with one year (up to
 a maximum of ten years)

2.4. RENEW

 Registrars use the Renew Domain command to extend the registration period of
 a domain name. A Registrar can only renew domain names for which it is the
 sponsoring registrar. The Renew Domain command can be specified with a
 registration period, from one to ten years. The resulting expiry date must
 not lay further than 10 years in the future.

 - No auto renew by the Domain Name Registry on expiration of the domain
 name.

 - Explicit renewal of period needed in advance of the expiry date
 (registration period can be extended up to 10 years)

2.5. DELETE

 - Deletion puts domain name in redemption status

 - Deleted from zone file instantly (serverHold)

2.6. REDEMPTION

 - Domain name is no longer available in zone file (serverHold)

 - Domain name can be restored before the end of the redemption grace period
 (RGP)

 - The domain name will be purged after the pendingDelete interval

2.7 AVAILABLE

 Domain name comes back in the pool of available domain names.

3. RFC5731-COMPLIANT DOMAIN NAME STATUS CODES

 The status information on a domain name is in line with the flags described
 in RFC5731, section-2.2 and section 2.3. It is a combination of the
 following Status Value Descriptions:

 - clientDeleteProhibited, serverDeleteProhibited: Requests to delete the
 domain name will be rejected.

 - clientHold, serverHold: DNS delegation information is not published for
 the domain name.

 - clientRenewProhibited, serverRenewProhibited: Requests to renew the domain
 name are rejected.

 - clientTransferProhibited, serverTransferProhibited: Requests to transfer
 the domain name are rejected.

 - clientUpdateProhibited, serverUpdateProhibited: Requests to update the
 domain name, other than to remove this status, are rejected.

 - inactive: Delegation information has not been associated with the domain
 name. This is the default status when a domain name is first created and
 there are no associated host objects or attributes for the DNS delegation.
 This status can also be set by the server when all host-object
 associations are removed.

 - ok: This is the normal status value for a domain name that has no pending
 operations or prohibitions. This value is set and removed by the server as
 other status values are added or removed.

 - pendingCreate: Request to create a new domain name has been received and
 is being processed or evaluated.

 - pendingDelete: Request to delete an existing domain name has been received
 and is being processed or evaluated.

 - pendingRenew: Request to renew an existing domain name has been received
 and is being processed or evaluated.

 - pendingTransfer: Request to transfer an existing domain name has been
 received and is being processed or evaluated.

 - pendingUpdate: Request to update an existing domain name has been received
 and is being processed or evaluated.

 Following combinations are excluded:

 - ok cannot be combined with any other status

 - pendingDelete status cannot be combined with clientDeleteProhibited or
 serverDeleteProhibited status

 - pendingRenew cannot be combined with clientRenewProhibited or
 serverRenewProhibited status

 - pendingTransfer status cannot be combined with
 clientTransferProhibited or serverTransferProhibited status

 - pendingUpdate status cannot be combined with clientUpdateProhibited or
 serverUpdateProhibited status

 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer and
 pendingUpdate cannot be combined

 The status flags starting with the word ʹclientʹ can be changed and updated
 by the Registrar. The status flags starting with ʹserverʹ are handled by the
 domain name Registry Operator.

 The Domain Name Registry will implement the above statuses in full.

4. RFC3915-COMPLIANT DOMAIN NAME STATUS CODE

 These flags are referred to as the RGP flags (Registry Grace Period). The
 following flags are defined and can be found in a separately available EPP
 extension called the RGP extension (RFC3915).

 - addPeriod: This ʺadd grace periodʺ is provided after the initial
 registration of a domain name. If the domain name is deleted by the
 registrar during this period, the domain name registry provides a credit
 to the registrar for the cost of the registration.

 - autoRenewPeriod: This ʺauto-renew grace periodʺ is provided after a domain
 name registration period expires and is extended (renewed) automatically
 by the registry. If the domain name is deleted by the registrar during
 this period, the registry provides a credit to the registrar for the cost
 of the renewal.

 - renewPeriod: This ʺrenew grace periodʺ is provided after a domain name
 registration period is explicitly extended (renewed) by the registrar. If
 the domain name is deleted by the registrar during this period, the
 registry provides a credit to the registrar for the cost of the renewal.

 - transferPeriod: This ʺtransfer grace periodʺ is provided after the
 successful transfer of domain name registration sponsorship from one
 registrar to another registrar. If the domain name is deleted by the new
 sponsoring registrar during this period, the registry provides a credit to
 the registrar for the cost of the transfer.

 - redemptionPeriod: This status value is used to describe a domain for which
 a 〈delete〉 command has been received, but the domain has not yet been
 purged because an opportunity exists to restore the domain and abort the
 deletion process. This status must be combined with the pendingDelete
 status in the EPP domain mapping.

 - pendingRestore: This status value is used to describe a domain that is in
 the process of being restored after being in the redemptionPeriod state.
 This status must be combined with the pendingDelete status in the EPP
 domain mapping.

 - pendingDelete: This status value is used to describe a domain that has
 entered the purge processing state after completing the redemptionPeriod
 state without succesful restoration. This status must be combined with the
 pendingDelete status in the EPP domain mapping.

 The Domain Name Registry will partially implement the above RGP statuses:
 the statuses concerning the redemption of the domain name (redemptionPeriod,
 pendingRestore, pendingDelete).

 The following statuses will not be implemented:

 - addPeriod: since all registrations pass through a permanent sunrise using
 a Clearinghouse, no domain name tasting is implemented;

 - autoRenewPeriod: because the domain name registry does not automatically
 renew domain names;

 - renewPeriod: because the registrar has explicitly and successfully issued
 the renew command, no refund is granted;

 - transferPeriod: because the registrar has explicitly and successfully
 issued the transfer command, no refund is granted.

5. STATUS CODE MATRIX

 There are two types of status values. These may change as a result of the
 Client initiating a transform command referring to the commands referenced
 in the ʹClientʹ column or by the domain name Registry referring to the
 ʹServerʹ column. The last column referred to as ʹGeneralʹ contains flags
 that transitional status values.

 (View attachment for Table 1: Status Code Matrix)

 The Prohibited flags have no influence on the status of the domain object.
 They prevent the denoted command from being executed on the domain name
 object. As such when set, they prevent the transform command from being
 executed and hence block the specified domain name life cycle transition.
 They have no influence on state of the domain name object.

6. STATUS TRANSITIONS

6.1. GLOBAL STATUS TRANSITIONS

 The following domain name states can be determined:

 - The domain name status is defined as ʹavailable for registrationʹ (in
 short ʹavailableʹ) if the domain name is conform to the registration
 policy and the domain name object does not exist.

 - The domain name is registered (no pending actions).

 - The domain name has a pending action. This can be one of the following

 * pendingCreate

 * pendingTransfer

 * pendingDelete

 * pendingUpdate

 * pendingRenew

 (View attachment for Table 2: Exhaustive list of transitions)

 Some transitions might be influenced by the registration policy. For
 instance:

 - The create has to be verified by the domain name Registry to see if no
 conflicts or infringements are detected.

 - The name servers added to the domain name object have to comply with
 certain rules set forth in the policy.

 - Change of ownership has to be verified.

 - Domain name matches predefined rule set needing registry acceptance.

 This is a non-exhaustive list which should reflect domain name registration
 policy regulations.

6.2. REGISTRY GRACE PERIOD STATUS TRANSITIONS

 The following domain name states are added to the domain name object when it
 has the EPP pendingDelete status:

 - redemptionPeriod

 - pendingRestore

 - pendingDelete

 (View attachment for Table 3: Exhaustive list of 3c pendingDelete state
 transitions)

6.3. REGISTRATION STATE DIAGRAM

 The Registration state diagram shows all possible states and transactions
 between those states.

 The domain name life cycle can be found in the attached flow chart.

 (View attachment for Figure 2: Registration State Diagram)

7. TRANSITION COMMANDS

 The following domain object commands can be used to trigger status
 transitions:

 (View attachment for Table 4: Transition commands)

8. REGISTRY TRANSITIONS

 The following domain object commands can be used to trigger status
 transitions:

 (View attachment for Table 5: Registry status transitions)

9. RESOURCING PLAN

 With regards to resourcing, reference is made to the global resourcing
 scheme as part of response to Question 31 (Technical Overview of the
 Proposed Registry). Implementation and maintenance of the Registration
 Lifecycle in the Registry Platform is under the authority of the Software
 Developer, under control of the Operations Manager.

 

1. INTRODUCTION

 Next to ensuring that a TLD is operated in a technically stable and secure
 manner, it is also of utmost importance that the Internet community at large
 is safeguarded from abusive and malicious behavior. Existing TLDs have often
 suffered from such behavior and, gradually, best practices have been
 developed in order to not only counter abusive or malicious conduct, but
 also prevent such issues from happening.

 Abusive use of a domain name generally includes, but is not limited to the
 following:

 - illegal or fraudulent actions;

 - using domain names in the TLD in order to send or forward unsolicited bulk
 messages, generally referred to as ʺspamʺ;

 - distribution of malware: using domain names in order to disseminate
 software (e.g. computer viruses, key loggers, etc.) that is designed to
 damage or harm the integrity of computers;

 - phishing: displaying web pages that are intended to mislead Internet
 users, with the aim of obtaining in a malicious manner from such users
 their sensitive data such as logins and passwords of the pirated websites;

 - pharming: redirecting Internet users to fraudulent website, which is
 generally done by hijacking or poisoning the DNS or changing host files on
 the victimʹs computer;

 - fast-flux hosting and botnets;

 - Illegal access to Other Computers or Networks: Illegally accessing
 computers, accounts, or networks belonging to another party, or attempting
 to penetrate security measures of another individualʹs system (often known
 as ʺhackingʺ). Also, any activity that might be used as a precursor to an
 attempted system penetration (e.g., port scan, stealth scan, or other
 information gathering activity);

 - Using domain names in the TLD in order to disseminate illegal content,
 such as child pornography

 Given the fact that the applied-for TLD will likely be and remain a single
 registrant TLD, as explained in our response to Question 18 et seq., where
 only members of HEXAP will be entitled to register domain names in the TLD,
 the likelihood for any such abusive behavior in this TLD to materialize is
 lower. Nonetheless, HEXAP commits to implement the preventive and curative
 measures described in the following paragraphs, in order to ensure that the
 applied-for TLD is operated in a responsible manner.

2. CONTROL

 HEXAP ⁄ Registry Operator will put in place various tools in order to
 mitigate or even exclude the possibility that the reputation of the .MED TLD
 is not harmed in any way. Especially, these tools and techniques will ensure
 that HEXAP will have the ability at all times to exercise control over:

 - the registrant;

 - the domain name;

 - the contact information associated with any domain name; and

 - the products, services and information provided under such domain name.

 In order to effectuate this, a limited number of identified individuals
 within HEXAPʹs organization will be able to control the applied-for TLD and
 any and all domain names registered therein from one portal, which has the
 following functionalities:

 - validating the registrantʹs eligibility and user rights in order to
 register domain names in the applied-for TLD;

 - validating whether an (about to be) registered domain name in the
 applied-for TLD corresponds to the naming conventions that will be
 established by the Registry Operator for domain names registered in the
 applied-for TLD;

 - validating contact information associated with registered domain names, in
 particular these contacts that can exercise control over the domain name
 itself, the name servers associated with such domain name, etc.;

 - validating specific commands, including create, update and delete
 commands;

 - approving for some or all domain names any transfer or trade requests, or
 intervene in the execution of such requests where the Registry Operator
 suspects that such transfer or trade requests are initiated in bad faith;
 and

 - review whether the use that is made of a particular domain name
 corresponds with the Registry Operatorʹs use policy, and suspend domain
 name registrations or even delete name servers associated with domain
 names that are being used in a manner that does not comply with the types
 of uses that are allowed by the Registry Operator.

 Bearing in mind that the registry is intended to be single
 registrant-registry only certain individuals are involved in above mentioned
 processes, reducing the risk of registering and⁄or using domain names in bad
 faith by any party that is not a member of HEXAPʹs organization.

 Access to this portal will be given to the administrators of the Registry
 Operator; furthermore, the Complaints Point of Contact will also obtain
 access to a limited number of features explained above.

3. REPORTING

 Also, the Registry Operator will obtain access to reports generated by its
 back-end registry services provider, which reports include:

 - number of DNS queries for each particular domain name registration;

 - number of new domain names registered;

 - number of new contacts created;

 - etc.

 If any suspicious activity is being detected following analysis of these
 reports, the Registry Operator will thoroughly investigate the matter and
 take appropriate action where required.

4. ANTI-ABUSE POLICY

 Prior to the delegation of the TLD, the Registry Operator will publish the
 terms and conditions for the registration of domain names in the applied-for
 TLD, which will include an anti-abuse policy. Highlights of such policy will
 include:

 - Complaints Point of Contact: the Registry Operator will put in place a
 Complaints Point of Contact. The Complaints Point of Contactʹs contact
 details will be mentioned on the home page of the Registry Operator,
 including on the web-based WHOIS interface.

5. MONITORING

 The Registry backend service provider, appointed by HEXAP, will put in place
 certain tools and methodologies in order to proactively screen for malicious
 conduct. Such tools include scanners that automatically scan for viruses or
 other forms of malware on all services deployed under applied-for domain
 names.

 These tools will operate in the background, and will not effect the
 functioning of the applied-for TLD.

6. PREVENTION OF ORPHAN GLUE RECORDS

 In compliance with SSAC recommendations, the Registry backend service
 provider, appointed by HEXAP, will check for the existence of glue records
 following the receipt of a deletion request for a particular domain name
 registration. If it would appear that no other domain names other than the
 domain name that is up for deletion are using the glue records associated
 with that domain name registration, the Registry Operator will remove such
 glue records after the domain name is deleted.

 Furthermore, any interested party will be entitled to file a complaint
 before the Complaints Point of Contact if it would appear that orphan glue
 records would still exist. If it would appear, following investigation by
 the Registry Operator, that orphan glue records would still exist in the
 zone file, such records will be promptly deleted from the zone file.

6.1 GLUE RECORD

 RFC 1034 defines glue as:

 A zone contains ʺglueʺ resource records which are not part of the
 authoritative data, and are address resource records for the servers.

 And specifies further that:

 These resource records are only necessary if the name serverʹs name is
 ʺbelowʺ the cut, and are only used as part of a referral response.

 In this specific case a glue record is the IP address of a name server held
 at the domain name registry. They are required when a set of name servers of
 a domain name point to a hostname under the domain name itself. For example,
 if the name servers of example.com are ns1.example.com and ns2.example.com:
 to make the domain name system work, glue records (i.e. the IP addresses)
 for ns1.example.com and ns2.example.com are required. Without the glue
 records for these name servers the domain name would not work as anyone
 requiring DNS information for it would get stuck in a loop.

 Example:
 What is the name server for example.com? -〉 ns1.example.com
 What is the IP address of ns1.example.com? -〉 donʹt know, try looking at
 name server for example.com
 What is the name server for example.com? -〉 ns1.example.com
 With the glue record in place the registry will hold the IP address and 
 the loop will not occur.
 
 Example:
 What is the name server for example.com? -〉 ns1.example.com
 What is the IP address of ns1.example.com? -〉 [IP Address]

6.2. ORPHAN GLUE

 The zone generation process could publish A-records ʺaddress-recordsʺ (also
 called ʺglueʺ records) regardless of whether or not the name server is
 referenced by any NS (name server) records. If an A-record is published and
 no zone delegations reference to such a record, it is called an orphan. Its
 presence in the zone is undesirable for a number of reasons, both
 administrative and technical.

6.3. OUT-OF-BAILIWICK RECORDS

 Records pointing to names of other zones besides the relevant registry zone,
 are called out-of-zone records or even out-of-bailiwick records. Any IP
 addresses linked to these names should in all circumstances be refused by
 the registry since they do not form part of the registryʹs zone. Most modern
 nameserver software will ignore these records by default.

6.4. EXCLUSION

 Glue records can only be inserted following the registration of a domain
 name and the creation of a host object. They can also only be included when
 the name servers have the same extension as the domain name.

 Example:

 A glue record can only be inserted if the name server of example.com is
 located in example.com
These address records only live by the grace of the
 domain name itself. Since the IP address is always linked to the domain
 name, the address will also disappear from the zone as soon as the domain
 name is eliminated from the registration database. This limits the
 possibility to register name servers within a domain name, because setting
 up circular referencing name servers is not allowed. In view of the
 possible risks and dangers, this is a very balanced choice of limitations
 and it allows for a flexible and consistent handling of glue records.

7. WHOIS ACCURACY

 The Registry Operator will include in its domain name registration policies
 the obligation to keep all information contained in the WHOIS accurate and
 up-to-date.

 As mentioned in response to Question 26, the applied-for WHOIS will be a
 ʺthickʺ WHOIS, where all key contact data relating to every domain name
 registered in the applied-for TLD will be stored at the level of the
 Registry Operator.

 Working closely with the accredited registrars for the applied-for TLD,
 Registry Operator will put in place measures whereby registrants are obliged
 to keep their WHOIS information accurate and up-to-date. Clauses will be
 inserted in the Registry-Registrar Agreement to that effect, in particular:

 - under the terms of the Registry-Registrar Agreement, accredited registrars
 will be required to impose upon their clients the obligation to maintain
 accurate and up-to-date WHOIS data at all times;

 - furthermore, accredited registrars will be instructed to send their
 customers who have registered a domain name in the TLD a request to
 confirm the accuracy of their WHOIS data and⁄or an email message whereby
 their obligation to keep WHOIS data accurate and up-to-date will is
 restated.

 - accredited registrars will have to demonstrate, upon the Registry
 Operatorʹs request, their compliance with the above, as well as any
 changes that have been made to WHOIS data following submission of such
 instructions.

 The above processes and requirements will in particular be relevant as of
 the moment that the applied-for TLD will no longer be a single registrant
 TLD, which entails that certain parties, other than the Registry Operator,
 will be entitled to register domain names in this extension.

 Furthermore, HEXAP ⁄ Registry Operator will display on the web-based WHOIS
 interface a link to the Complaints Point of Contact. Any party who is of the
 opinion that certain WHOIS data is inaccurate, incomplete or not up-to-date
 can contact the Complaints Point of Contact. The latter has the authority to
 commence investigations, and - in case of registrant non-compliance - take
 measures against such registrant. These measures include, but are not
 limited to, putting the domain name on hold, or revoking the domain name
 registration.

8. WHOIS ABUSE PREVENTION MEASURES

 Considering the fact that a WHOIS database contains quite some sensitive
 information that is available to Internet users at large over a web-based
 interface, the Registry Operator will put in place various methods in order
 to avoid abuse of such information by third parties.

 First of all, the Registry Operator will only display search results in
 response to a search query after the user has successfully entered the
 displayed CAPTCHA code together with such query, this in order to prevent
 the automatic harvesting of WHOIS data.

 Furthermore, private individuals (if at all allowed by HEXAP ⁄ Registry
 Operator to register and hold domain names within the TLD) will be allowed
 to indicate - through their registrars or via a web-based portal provided by
 HEXAP ⁄ Registry Operator - that certain personal data will not be
 automatically displayed following a successful WHOIS query. This measure is
 taken in order to comply with particular applicable laws and regulations
 regarding data privacy.

 However, parties demonstrating to the Registry Operator that they have a
 right or legitimate interest in order to obtain access to this hidden data
 can request access to a particular, identified record upon request to the
 Registry Operator. Positive responses to legitimate requests shall not be
 unreasonably withheld or delayed.

 The features described above can be temporarily or permanently disabled for
 specific eligible parties, such as law enforcement agencies, and this upon
 simple request by a competent authority. These eligible parties will then
 obtain access to all WHOIS information via a secure, web-based portal.

1. INTRODUCTION

 As has been explained above, the Registry Operator HEXAP intends the
 applied-for TLD to be a restricted and closely monitored gTLD. This
 characteristics are mainly inspired by HEXAPʹs desire
 to protect the reputation of the .MED TLD under any circumstances.

2. PREVENTING ABUSIVE DOMAIN NAME REGISTRATIONS

 In order to prevent abusive domain name registrations in the applied-for
 TLD, various steps in the domain name lifecycle will be controlled by HEXAP.
 In order to enable HEXAP to do this, it will provide access to a control
 panel (ʺportalʺ) to key individuals within HEXAPʹs organization. By way of
 this portal, these users can exercise at any time control over the
 applied-for TLD and any and all domain names registered in this extension,
 and in particular:

 1) validate on an ongoing basis the registrantʹs eligibility and user rights
 in order to register domain names in the applied-for TLD;

 2) validate whether a (about to be) registered domain name in the
 applied-for TLD corresponds to the naming conventions that will be
 established by the Registry Operator for domain names registered in the
 applied-for TLD;

 3) validate contact information associated with registered domain names, in
 particular these contacts that can exercise control over the domain name
 itself, the name servers associated with such domain name, etc.;

 4) validate specific commands, including create, update and delete commands;

 5) approve for some or all domain names any transfer or trade requests, or
 intervene in the execution of such requests where HEXAP suspects that
 such transfer or trade requests are initiated in bad faith; and

 6) review whether the use that is made of a particular domain name
 corresponds with HEXAPʹs use policy, and suspend domain name
 registrations or even delete name servers associated with domain names
 that are being used in a manner that does not comply with the types of
 uses that are allowed by HEXAP.

 Therefore, it is likely that for the term of the Registry Operator Agreement
 that will be executed between HEXAP and ICANN following award of the
 applied-for TLD by the latter to HEXAP, the Registry Operator will carefully
 monitor and manage all domain name registrations that are being made in the
 applied-for TLD.

 This way, HEXAP will put measures in place on a continuous basis whereby,
 first of all, the rights and legitimate interest of third parties are
 safeguarded, and, secondly, the reputation and good name of the .MED TLD
 will be underlined at all times.

3. INTERNAL VERIFICATION AND VALIDATION PROCESSES

 One of the most effective safeguards that will be implemented by HEXAP will
 be the screening of every domain name before this domain name gets
 registered and⁄or entered into the zone file of the applied-for TLD.

 During any of such screenings, the relevant legal and risk management
 departments of HEXAP will consider the following factors:

 - the likelihood of trademark infringement, if and when such domain name
 would become registered;

 - any potential harm being done to trademark owners when registering and
 using a particular domain name in the applied-for TLD, and the benefit
 such domain name would have for the registrant.

 Furthermore, as explained above and in various other sections of this
 application, HEXAP will be screening on an ongoing basis the use that is
 being made of any domain name registered in the applied-for TLD and will
 implement reasonable measures in order to avoid harm being done to third
 parties.

 Although the above processes will make it extremely unlikely that HEXAP will
 engage or encourage potentially malicious or infringing activities to be
 carried out under the applied-for TLD, these cannot be completely excluded.

 Therefore, in addition to monitor any domain names registered under the
 applied-for TLD and the use that is made of such domain names, the Registry
 will - in accordance with its domain name registration policies - at all
 times be entitled to intervene if any such activities have been detected.
 Measures that can be taken include the suspension, revocation and blocking
 of any domain name registration and, in general, take any action necessary
 in order to limit or outright avoid any harm being done to the interests and
 reputation of third parties, the Registry Operator and its eligible
 registrants.

4. SUNRISE

 When relevant, HEXAP will implement a Sunrise process, whereby holders of
 certain trademarks will be entitled to safeguard the domain names that are
 identical (or even confusingly similar) to the name(s) to which they hold
 rights.

 Such process would therefore most probably include providing the opportunity
 to brand owners - unrelated to HEXAP - to register as .MED domain names or
 block names to which such brand owners have rights, as demonstrated by the
 Trademark Clearinghouse.

 HEXAPʹs back-end registry operator OPEN REGISTRY has significant experience
 in managing Sunrise processes. In particular, various key staff members were
 heavily involved in designing and implementing Sunrise processes that
 preceded the launch of the .EU ccTLD, which is generally considered the most
 successful Sunrise process that has ever been implemented.

 At the time of submitting this application, the back-end registry operator
 is involved in the implementation of the Sunrise process for the .SX TLD.

5. TRADEMARK CLAIMS

 HEXAP will support ICANNʹs Trademark Claims process. Depending on the actual
 process that will be put in place by the Trademark Clearinghouse, HEXAP will
 implement these processes for at least the duration indicated in ICANNʹs
 Applicant Guidebook or may even have this process in place for a longer
 term.

 Similar processes have been put in place by various staff members of HEXAPʹs
 back-end registry operator, so also here HEXAP can bow on significant and
 hands-on experience in handling these types of processes.

6. COMPLAINTS POINT OF CONTACT

 As is the case for various other processes and proceedings whereby third
 partiesʹ interests can be harmed, the Complaints Point of Contact that will
 be put in place by HEXAP will also here play a pivotal role.

 Any party claiming that his trademark(s) are infringed due to the
 registration and use of a domain name in the applied-for TLD is able to file
 a complaint before the Complaints Point of Contact of HEXAP. Filing these
 complaints will be free of charge. The Complaints Point of Contact will
 generally provide a written response or even resolution of the matter within
 5-10 business days following the receipt of the complaint.

 Within this timeframe, the Complaints Point of Contact will investigate the
 complaint, and carry out ex officio investigations. As mentioned previously,
 the Complaints Point of Contact is entitled to suspend domain name
 registrations, delete name servers associated with infringing domain name
 registrations, or even outright revoke and block domain names from further
 registration if the Complaints Point of Contact is of the opinion that such
 domain name potentially infringes the rights of a third party, that no
 legitimate use is being made by the registrant of such domain name, and that
 there is bad faith involved.

 It is the true desire of HEXAP to have potential issues resolved by the
 Complaints Point of Contact. Therefore costly litigation can be avoided and
 issues resolved amicably.

7. UDRP and URS

 HEXAP will implement all domain name dispute resolution policies designed by
 ICANN, including but not limited to those described in Consensus Policies
 and Applicant Guidebook.

 In this respect, HEXAP will put any registered domain name on hold following
 receipt of a notification from the Uniform Dispute Resolution Policy or the
 Uniform Rapid Suspension Policy dispute resolution service provider that a
 complaint under such policies have been received.

 Furthermore, it will implement decisions rendered by such dispute resolution
 service providers, however taking into account at all times that eligibility
 restrictions may be in force for domain name registrations made in the
 applied-for TLD.

 This could entail that the only remedy available to a third party that is
 not entitled by HEXAP to register domain names in the applied-for TLD will
 be the revocation ⁄ deletion of the domain name. In order to ensure maximum
 compliance with any such decision, HEXAP will put such domain name on a
 blocked list (i.e. make this domain name unavailable for further
 registration) insofar and to the extent the UDRP ⁄ URS dispute resolution
 service provider was of the opinion that the domain name registered by any
 party other than the Registry Operator meets the requirements set out in the
 UDRP or URS.

8. RESOURCING PLAN

 The Applicant foresees that less than 1 FTE resource will suffice in order
 to oversee and execute the tasks described herein, in addition to the
 technical and operational resources put at the disposal by OpenRegistry in
 this respect.

The Registry Operator has outsourced the technical back-end registry operations
to OpenRegistry S.A., the (backend) Registry Service Provider. Within the
OpenRegistry group, Sensirius, doing business as OpenRegistry Belgium, as an
Affiliate of OpenRegistry S.A., is the operational entity that will be running
the registry operations for the entire group.

The Registry Service Provider has put in place an Information Security
Management System (ISMS) for its registry operation activities. For a full
description of the ISMS, reference is made to the response to question 30b. The
ISMS has been recently audited by Deloitte Bedrijfsrevisoren, Belgium. The
report for this independent assessment of the security system is attached to
question 30b.

For reasons of confidentiality, all elements related to security (including
elements indicated in question 30a and a summary of the security policy) have
been addressed in the response to question 30b. Attached to the response to
question 30b are also the policies that are put in place by the Registry Service
Provider for assuring the registry operations on behalf of the Registry
Operator.