ICANN New gTLD Application

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.

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.

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.

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.

Jerome LIPOWICZ	CTO
Joseph LIPOWICZ	Chairman

AB SURGERY	Not Applicable
Jerome LIPOWICZ	CTO
Joseph LIPOWICZ	Chairman

New gTLD Application Submitted to ICANN by: HEXAP SAS

String: med

Originally Posted: 13 June 2012

Application ID: 1-1192-28569

Applicant Information

1. Full legal name

2. Address of the principal place of business

3. Phone number

4. Fax number

5. If applicable, website or URL

Primary Contact

6(a). Name

6(b). Title

6(c). Address

6(d). Phone Number

6(e). Fax Number

6(f). Email Address

Secondary Contact

7(a). Name

7(b). Title

7(c). Address

7(d). Phone Number

7(e). Fax Number

7(f). Email Address

Proof of Legal Establishment

8(a). Legal form of the Applicant

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

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

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

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

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

Applicant Background

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

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

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

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

Applied-for gTLD string

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

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

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

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

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

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

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

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

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

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

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

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

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

Mission/Purpose

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

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

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

Community-based Designation

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

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

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

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

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

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

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

Geographic Names

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

Protection of Geographic Names

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

Registry Services

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

Demonstration of Technical & Operational Capability

24. Shared Registration System (SRS) Performance

25. Extensible Provisioning Protocol (EPP)

26. Whois

27. Registration Life Cycle

28. Abuse Prevention and Mitigation

29. Rights Protection Mechanisms

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

© Internet Corporation For Assigned Names and Numbers.