ICANN New gTLD Application

i. Applicant was founded with a pioneering vision: to help entrepreneurial financial advisors establish successful businesses through which they may offer independent financial guidance and advice. Through our vision and dedication, Applicant has become a strong and reputable brand within the financial sector. We believe that the establishment of our gTLD will only serve to enhance this brand recognition in our industry and among our end clients.
In the past, Applicant has been the victim of internet fraud and misrepresentation that, if not properly managed, may have had an impact on our reputation. Applicant has always been proactive in combatting these abuses in order to ensure that our reputation does not suffer. We have invested resources and taken measures to protect against these vulnerabilities. Applicant believes that establishing a secure internet environment through a proprietary TLD will not only add value to our brand, but will also create a safe haven for our company, our financial advisors, and our end-clients.

ii. The .lpl TLD will give us an edge on our competition. It will set us apart as a “first mover” in our industry, as we believe we will be among the first companies to have acquired its own gTLD. This fact will convey a positive message to our customers and position us as an innovator in the marketing space.
The .lpl TLD will also allow us to provide our financial advisor partners with their own domain name, branded with our strong corporate identity. Through the .lpl TLD, Applicant believes the trust that financial advisors place in the its brand will be shared with its end clients. The .lpl TLD will help our end clients understand that while our financial advisors are independent, they are strongly supported by the brand.

Moreover, as we have described above, the financial industry sector is very often the victim of internet security breaches, and we therefore expect to use the TLD as an opportunity to provide a secure internet environment not only for Applicant as a firm, but also for our financial advisors in their ordinary business practices.

iii. The .lpl TLD will guarantee authenticity and security. This is a very important consideration for firms within the financial services sector, because internet users, our financial advisors, and our end clients are often targets of the malicious conduct by third parties who misuse domain names in order to obtain personal and sensitive information. Through our gTLD, we believe our end-clients will gain certainty and comfort that they are obtaining secure and accurate information from their advisors.

Applicant will at all times implement and adhere to any and all consensus policies introduced by ICANN, so as to further the development and stability of the internet and the global Internet community. Applicant will also create a governance committee that will consists of legal, technical, commercial and business advisors to review and propose policies and ensure that all polices are adhered to.

A brief description of our registration polices is summarized below:

• Prior to issuing .lpl domain names, Applicant intends to reserve a number of generic words, phrases, character and⁄or digits as second-level domain and third level that relate specifically to the activities of Applicant. These domain names will be allocated in accordance to the requirements as set out by Applicant. The purpose of these domains is to ensure the continuous operations of the Applicant.

• In addition, Applicant also intends to block words and phrases which it, in its sole and exclusive discretion, considers to be abusive, obscene and⁄or offensive, thereby preventing any reputational loss to our brand or any user confusion. These domain names will come up as unavailable.

• Similarly, Applicant intends to reserve all two character labels and all country and territory names, taking into account the relevant provisions laid down in Specification 5 of the Registry Agreement. More information in this respect will be provided in our answer to Question 22.

Restricted registration: In order to comply with the above strategy, Applicant will, at least initially, restrict the .lpl TLD for corporate use only by Applicant. Going forward, it will allow its financial advisors to apply for a domain name within the .lpl TLD. Furthermore, the Applicant plans to include specific provisions in its registry-registrar agreement in order to ensure that Applicant’s mission and vision outlined above are implemented to their fullest extent possible. By doing so, Applicant will ensure that the restricted policies described above and below are adhered to, allowing for a smoother implementation of the issuance of the domain names.

All domain name applications will be presented to Applicant’s marketing department through a centralized, web-based, request system. The marketing department will determine whether or not the request is approved. Once a particular domain name is approved, the marketing department will request the domain name registration through a Registrar. All domain names under the .lpl TLD must be linked in a direct way to (i) the services offered under the brand or (ii) services, products, trademarks, or company names registered in name of the our financial advisors, our product sponsors, or our affiliates. In addition all information provided under these domain names will be reviewed through an advertising compliance process led by our marketing department to ensure compliance with our regulatory requirements.

Applicant intends to launch the .lpl TLD in several phases:

Phase One: Allocation of domain names that are linked to services specific to Applicant as well as the allocation of domain names that are currently being held directly by Applicant. This phase will last at least for a period of one year. The length of this period will allow us to ensure a smooth transition phase and will provide internal and external users with the opportunity to be familiarized with the transition.

Phase Two: In accordance to ICANN’s policies, Applicant will implement a sunrise period for 30 days, enabling its financial advisors to register their corresponding trademarks within .lpl TLD, as discussed in section 29.

Phase Three: This phase will not be open to the general public but as provided above will only be open up to financial advisors, product sponsors, or affiliates of Applicant that are eligible to register domain names within the .lpl TLD. All domain names will be submitted through a request process prior to registration in order to ensure that i) the domain name applied for corresponds with a trademark, company name, or service and products that are provided by our financial advisors and ii) the domain name complies with the anti- abuse registration polices as set out by our governance committee (see sections 28 and 29).

During this phase Applicant plans to adhere to the trademark claim services as set out by ICANN for a period of 60 days from the start of the phase. This allows trademark holders that are connected to the trademark clearinghouse to be informed if any of the domain names being applied for infringe their trademark.

iv. The only personal information the will be collected is that which is required to comply with ICANN’s WHOIS standards. In the event that we obtain any other personal information, Applicant shall comply with the applicable U.S. privacy laws and regulations. The Applicant that will ensure compliance with all data privacy laws. In the event that other personal information is collected by the Registrants, we will require that all Registrants and the applicable Registrars adhere to applicable U.S. privacy laws and regulations.

v. Our goal is to achieve greater brand recognition and to increase the recognition of our financial advisors’ services through the .lpl TLD application. In order to reap the benefits from this gTLD, we will plan an appropriate communication to the relevant audience at the time of our application.In order to create awareness about the .lpl TLD, we will make the most of our existing advertising channels. This includes, among others, social media dialoguing, advertising campaigns, interviews, and internal leadership announcements.

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 Applicant has therefore chosen to outsource the technical back-end operations for the domain name Registry to Sensirius (the Registry Service Provider). Sensirius 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 Sensirius 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.
Sensirius’ 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. Sensirius has offices in Luxembourg and Belgium.
Sensirius 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 Sensirius team has 20 years of experience in developing and managing sophisticated solutions for Registrars and Registry Operators. The Sensirius 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.
Sensirius 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, Sensirius 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,… ) 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.
Sensirius 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;
• Trade and transfer control 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 transfer or trades;
• On-hold status can be set pending an Alternative Dispute Resolution (ADR) case;
• Domain Name Monitoring module exposes typo-squatters by listing similar domain names;
• The Registrant extranet puts Registrants in charge of their domain names.
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 domain name 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. Internationalized Domain Name (IDN) Compatible
The Registry Platform is IDN compatible and does not rely on the 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.
A detailed description of the implementation of IDN is provided in the response to question 44.
2.7. Nameserver Groups
The Registry Platform can create nameserver groups. A nameserver group contains a list of nameservers that can be linked to a domain name. This can be used instead of individual nameservers on a domain name. When one nameserver is replaced by another, nameserver groups deal with this change in one update that is then propagated to all domain names linked to that group. When using individual name-servers, all domain names using the old name servers need to be updated.
2.8. Extranet
The extranet option allows the Registrant to access and, when permitted, modify his data at the Registry Operator level. It can also be used by the Registrant to approve trade or transfer of a domain name. If needed, the Registrant can be given access to the extranet to switch on some levels of control. For instance, the Registrant can ask to be informed of any change of data made by the Registrar. Similarly, the Registrant can choose to be informed by e-mail when his domain name is scheduled for deletion. In this case, the modification or deletion can only be executed after confirmation from the Registrant.
2.9. 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.10. Validation Management
The Registry Platform can provide a direct link to any Trademark Clearinghouse that ICANN 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.11. 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.12. 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.13. 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.14. 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.15. Variable Renewal Period
The Registry Platform allows for configuration of the renewal period, with a maximum of 10 years. By default, domain names are renewed every year, but this could be set to any other period, within the limits imposed by ICANN.
2.16. 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.17. String Blocking
This feature allows for blocking of simple or complex ‘strings’ from being used in domain names. Examples could include the name of competitors of the Registry Operator for a brand TLD, parts of that name, or foul language.
2.18. Automatic Transfer and Trade Handling
The Registry Platform is capable of automatically handling all transfers and trades using a proven automated process of approval by the registrants. When a transfer is initiated, the current owner receives an e-mail requesting approval. In case of a trade, the new owner also receives an e-mail. Only when all parties involved have electronically given their approval is the transfer or trade scheduled for automatic execution.
2.19. 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.20. 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.
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 allows for both an automated as well as an explicit renewal. Both options occur at the end of the month in which the renewal is due. 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. Extranet
If applicable, the extranet option allows the Registrant to access and, when permitted, modify his data at the Registry Operator level. It can also be used by the Registrant to approve his trade or transfer. If needed, the Registrant can be given access to the extranet to switch on some levels of control. As a first level, the Registrant can ask to be informed of any change of data made by the Registrar. Similarly, the Registrant can choose to be informed by email when his domain name is scheduled for deletion. If the Registrant chooses the second level of security, the modification or deletion can only be executed after confirmation from the Registrant.
4.3. 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.4. Validation Management
The Registry Platform can provide a direct link to any Trademark ClearingHouse that ICANN may choose to operate, 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.5. 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 the registration, by authorized Registrars, of domain names and modification of information associated with that name on the Registry.
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 Question 33 (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 Applicant will comply with the relevant existing RFCs. The Registry will also, where 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 conformance 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 username and 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 per Registrar, subject to evaluation).
2.3. Registrar Web Interface
The Applicant will, in addition to the EPP server system, also run a Registrar web interface. This web interface can be used besides or in place 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 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 domains, 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 far 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 far 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 far 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 for where the Registrar can be reached by the Registry for administrative, technical and financial purposes;
• 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, domains 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 username and password is required;
• 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 be 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 out 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;
• State-full 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 plain;
• 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... all use the core database.

The Applicant will implement a thick Registry model, and as such the full data is present in the Registryʹs core database. Thereʹs 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 Applicant is using hot-standby database replication for redundancy and fail-over, and if the load on the system would require, 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 Applicant 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:
o One or more protocol versions supported by the server
o One or more languages for the text response supported by the server
o One or more 〈objURI〉 elements which identify the objects which the server is capable of managing
o 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 Applicant 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).

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 Trade Mark ClearingHouse (Module V of ICANN’s Applicant Guidebook).
At the moment, no party has been appointed to perform the Trade Mark 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 Trade Mark Clearinghouse.
3. 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 Applicant 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.
4. Resourcing Plan
4.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).
4.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 Applicant 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 Registry. The standard WHOIS service will provide a central location for all authoritative Registry data. The Applicant also provides a front-end web interface to allow convenient user access to the WHOIS service.

The Applicant 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 registry database. If and when 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 asynchronously via streaming replication, which gives 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-conformant service provided by the Applicant 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 Applicant, 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;
• The format of the following data fields are 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-conformant 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.

2.3. WHOIS Data update frequency

The Applicant 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, 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 Applicant will protect the privacy of an individual where required. When such legislation is in place, 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 maker 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

2.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.

2.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 (both A-label and U-label for IDN domain names, see response to Question 44 on Internationalized Domain Names);
• 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 Trade Mark ClearingHouse, in accordance with Specification 7 in the applicant guidebook).
2.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”).
2.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.
3. Nameserver name
4. IP address (if applicable, IPv4 and⁄or IPv6)
5. 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.
6. Contact ID
7. Contact Name
8. Contact Organization
9. Contact Address, City, State⁄Province, Country + 3 street fields
10. Contact Postal Code
11. Contact Phone, Fax (if available), E-mail
12. Create Date
13. Contact Last Updated Date
14. Contact Status (several contract status codes can be shown here, such as OK or LINKED, a pending action status and⁄or restriction flags)
15. 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.
16. Registrar ID (conforming to the IANA registrar-ids registry)
17. Registrar Name
18. Registrar Address, City, State⁄Province, Country
19. Registrar Postal Code
20. Registrar Phone, Fax, E-mail
21. Registrar Administrative Contacts
22. Registrar Technical Contacts
23. 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. Also here the number of queries per day per IP address is capped.
- Data-mining techniques are implemented to monitor the distribution of the querying clientsʹ IP addresses. Anomalies will be brought under the attention of the human operator for further evaluation.

Often the reason for bulk access to the WHOIS service is to querying the availability of the domain name (e.g. from Registrarsʹ web front-ends). Therefore the domain name Registry 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 indicates whether the given domain name is still available for registration or not.

The query format: whois -p 4343 EXAMPLE.TLD

The response format:
24. Domain Name: EXAMPLE.TLD
25. Available: yes
26. 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 a private brand domain name Registry is completely different than for an open brand domain. Many of the requirements for open TLDs are not relevant for domain names which have a limited number of names under management and which will, most likely, use a very limited number of Registrars (most likely just one).

It is also likely that the domain names registration will not be traded, sold on the secondary market and transferred from one Registrar to another. In addition, it is likely that the names will be “registered” for very long life cycles (max. 10 years) within the life of the domain name registry itself.

This makes quarantine handling unnecessary.
• All transactions via a limited number of Registrars;
• Create Registrant, technical and billing contact;
• Register domain;
• Add or edit name servers, ns-groups;
• Transfer⁄trade (including execution date) not necessary‏;
• Delete (including deletion date)⁄undelete provided but probably not used;
• Transfer from quarantine not provided;
The following pages give an overview of the different processes that can be used by the Registrar to influence the state of a domain name. Some might change the state of the domain name. Others might just alter the domain nameʹs information such as name servers, contacts and others. Some processes also involve interactive tasks on the domain name Registryʹs side. There are two distinct phases in the TLD history which lead to different behavior. The first phase does not allow free registration. It typically consists of a number of sunrise periods where different parties under different circumstances are allowed to register certain domain names. The second phase is what is often referred to as general availability. It could start with a so called ʹland rushʹ period that allows the domain name registry to identify popular names.
2. Registration Lifecycle
(View attachment for Figure 1: Domain Timeline)
2.1. Registration (or Sunrise)
• Use EPP⁄web - first come-first served ⁄ validation via Trademark clearing house (TMCH)
• Create or reuse existing billing contact
• Create or reuse (at least 1) technical contact
• Create or reuse (at least 1) administrative contact
• Create or reuse Registrant contact
• Register domain (apply in case of sunrise)
• Confirm domain name through IPClaims service
• Domain is active (possibly after approval via TMCH)
2.2. Update
• Update tech, admin, billing contacts
• Update name servers, ns-groups
• Update Registrants
• Special policies possible e.g. only update Registrant ʹnameʹ (private) or ʹcompanyʹ (company)
• Additional : monitor transaction if needed?

2.3. Transfer
• Transfer: changing Registrar, same Registrant
• Registrar notified to acceptance or rejection of transfer or trade
• Extends registration period if possible
• Different scenarios are possible, including
• Request by Registrar using authorization code
2.4. Renew
Registrars use the Renew Domain command to extend the registration period of a domain object. A Registrar can only renew domain names for which it is the sponsoring registrar. The Renew Domain command must be specified with a registration period, from one to ten years. The resulting expiry date must not be more than 10 years in the future.
• Domain name is renewed automatically
• Domain name is renewed on a yearly basis
• Accepted transfer is paying
• Explicit renewal of period possible (period can be extended up to 10 years)
2.5. Delete
• Deletion can be canceled before effective execution date (RGP)
• Deleted from zone-file instantly
• Deleted domain can be restored (redemption period)?
2.6. Redemption
• Domain name is no longer available in DNS (serverHold)
• Can be restored
2.7. Available
• Domain comes back in the pool of available domain names
• First come - first served
• The time between release of the domain name and putting it back in the pool of available domain names, is fully configurable.
3. RFC5731-Compliant Domain Name Status Codes
The status information on a domain name object 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 object will be rejected.
• clientHold, serverHold: DNS delegation information is not published for the object.
• clientRenewProhibited, serverRenewProhibited: Requests to renew the object are rejected.
• clientTransferProhibited, serverTransferProhibited: Requests to transfer the object are rejected.
• clientUpdateProhibited, serverUpdateProhibited: Requests to update the object, other than to remove this status, are rejected.
• Inactive: Delegation information has not been associated with the object. This is the default status when a domain object 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 an object 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 object has been received and is being processed or evaluated.
• pendingDelete: Request to delete an existing object has been received and is being processed or evaluated.
• pendingRenew: Request to renew an existing object has been received and is being processed or evaluated.
• pendingTransfer: Request to transfer an existing object has been received and is being processed or evaluated.
• pendingUpdate: Request to update an existing object 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 Applicant.
4. RFC3915-Compliant Domain name status code
RFC3915 defines extra flags on the domain name that can be set or referenced by EPP. These flags are add to provide the following functionality
• An ʺadd grace periodʺ after the initial registration of a domain name. 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 registration.
• An ʺauto-renew grace periodʺ 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.
• A ʺrenew grace periodʺ 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.
• A ʺtransfer grace periodʺ 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.
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.
• addPeriod: This 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 registry provides a credit to the Registrar for the cost of the registration.
• autoRenewPeriod: This 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 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 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.
• pendingRestore: This status value is used to describe a domain that is in the process of being restored after being in the redemptionPeriod state.
pendingDelete: This status value is used to describe a domain that has entered the purge processing state after completing the redemptionPeriod state. A domain in this status MUST also be in the pendingDelete status described in the EPP domain mapping.
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
o pendingCreate
o pendingTransfer
o pendingDelete
o pendingUpdate
o 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)
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)
A number of these status flags and settings are irrelevant to the Applicant’s model.
As a single-Registrar Registry, transfer of domain names is not provided, nor is a quarantine registration state applicable. Therefore all flags linked to transfer can be ignored and the handling of domain names in quarantine is greatly simplified. The domain name life cycle can be found in the attached flow chart.
(View attachment for Figure 2: Registration State Diagram)

9. Resourcing Plan
9.1. 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 Registration Lifecycle in the Registry Platform is under the authority of the Software Developer, under control of the Operations Manager.


1.	Introduction

The .lpl TLD application concerns a restricted gTLD, which means that for the first phase of the gTLD launch only the Applicant will be entitled to register domain names. In phase two the Applicant will organize a sunrise period where Applicant’s financial advisors will be allowed to apply for a domain name that corresponds with its trademark or company name(s) (see our response to question 29). During the third phase product sponsors and affiliates of the Applicant and the Applicant itself will be allowed to register domain names that correspond both directly or indirectly. It is important to note that the domain name registrations for .lpl TLD will never be open to the general public. 

These limitations, requirements and procedures will be reflected in the following:
- the policies for the registration of domain names, which will contain provisions regarding:
o	how domain names will be allocated;
o	the responsibility of the various parties involved in the registration process, including the Registrars sponsoring a domain name registration in the .lpl TLD; and
o	the measures taken by Applicant  and its accredited Registrars in order to prevent abuse made by any Registrant of a domain name in the .lpl gTLD, as well as measures to suspend or delete any domain name registrations made in this extension above and beyond the mandatory policies and procedures set out by ICANN;

-	the registry-Registrar agreement, which will contain provisions regarding:
o	the authentication of candidate Registrants of domain names in the gTLD;
o	the verification in cooperation with the Applicant’s Marketing department (see next page) – on a continuous  basis – of whether these Registrants meets these requirements;
o	etc.

-	putting in place an Abuse Complaints Point of Contact, who will investigate any non-compliant or infringing domain name registrations at no cost to the third party complainant who is of the opinion that a domain name has been registered without the Registrant meeting the eligibility requirements referred to above, and⁄or a domain name has been registered that potentially infringes the rights or legitimate interests of such complainant.

2. Proposed Policies and procedures
As already stated due to the restricted nature of .lpl TLD, occurrences of domain name abuse are inherently prevented. Nevertheless Applicant ensures that extensive measures will be taken in order to manage domain name abuse in compliance with ICANN regulations as described in the following paragraphs. 

2.1.	An implementation plan to establish and publish on its website a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in .lpl TLD.

Applicant  commits itself to addressing matters regarding abuse in an expedient fashion and to provide a timely response to all abuse complaints concerning domain names registered in .lpl TLD. As will be documented in  Applicant’s Domain Name Anti-Abuse Policy scope this application concerns a restricted gTLD, meaning:
-	There will be a limited number of Registrants:
o	Applicant;
o	Financial advisors of Applicant;
o	Product sponsors and affiliates of the Applicant ;
Operating a restricted gTLD will in itself limit the possibilities of domain name abuse, however to comply to ICANN’s requirements Applicant intends to appoint a single point of contact to address matters regarding domain name abuse. As described in the Applicant’s  Domain Name Anti-Abuse Policy, it is the intention of the Applicant to create a specialized governing body (Governance Committee) within Applicant’s  organization to create and maintain the Applicant’s  Domain Name Anti-Abuse Policy. 

This Governance Committee will consist of highly skilled professionals with extensive experience in legal, business and technical domain name matters, trained to handle abuse complaints. In addition to handling possible abuse complaints, they will also correlate these complaints to create new procedures or to improve Applicant’s  Domain Name Anti-Abuse Policy. 

To further minimize abusive registrations and other activities that have a negative impact on Internet users, all domain name applications will be presented to Applicant’s marketing department through a centralized, web-based, request system.  The marketing department will determine whether or not the domain name request is approved. This approval process will ensure that the domain name applied for corresponds with a trademark, company name, or service and products that are provided by financial advisors and product sponsors and affiliates and that the domain name complies with the abuse registration polices as set out by the Governance Committee.

2.2.	Policies for handling abuse complaints.

As mentioned earlier, as a result of the restricted nature of .lpl, Applicant does not foresee any actual domain name abuse or any misuses. This is due to the fact that all domain names that will be registered will be either directly or indirectly linked to Applicant’s services and products and⁄or their financial advisors, products sponsors and affiliates their products and⁄or services and because all domain names will be submitted to an internal compliance check by the marketing department before any domain name is registered. Nevertheless, should any complaints be filed, the Applicant will have a mature policy in place to act accordingly. This policy will be published on the website.
 As will be described in Applicant’s Domain Name Anti-Abuse Policy it is the intention of the Applicant to handle complaints regarding abuse and⁄or misuse, by means of a Governance Committee, created to oversee policy non-compliance. According to the level of the complaint Applicant  will reserve the right to: 
-	deny or cancel any registration or transaction;
-	place any domain name(s) on registry lock, hold or similar status during the resolution of a dispute.

This in order to:
-	protect the integrity and stability of the registry; 
-	to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; 
-	to avoid any liability, civil or criminal, on the part of the Applicant , as well as its affiliates, subsidiaries, officers, directors, and employees; 
-	to correct mistakes made by Applicant.

Applicant will create a Domain Name Anti-Abuse Policy containing clear definitions of what constitutes abuse.
 

A high-level description of the Domain Name Anti-Abuse Policy can be found below.

The objective of the Anti-Abuse Policy is to define abusive uses pertaining to domain name registration and domain name usage. Consequently, the Applicant intends to define “abuse” as follows:

Abuse is an action that:
-	Causes actual and substantial harm, or is a material predicate of such harm;
-	Is illegal or illegitimate, or is otherwise considered contrary to the intention and design of a stated legitimate purpose, if such purpose is disclosed.

In the section below a distinction is made between Registration Abuses and Malicious Use of Domain Names (Domain Name Usage Abuses), as a failure to do so could lead to confusion.
Registration Abuses
The following practices are considered registration abuses and will result in sanctions taken by the Applicant:
-	Cyber squatting;
-	Front-running;
-	Gripe sites;
-	Deceptive, pornographic and⁄or offensive domain names;
-	Fake renewal notices;
-	Name spinning;
-	Cross-gTLD Registration Scam;
-	Domain kiting.
Detailed descriptions of these abuses will be available in the Domain Name Anti-Abuse Policy that will be provided to all Registrants.

Malicious Use of Domain Names
Malicious use of domain names will apply to what a Registrant  does with his or her domain name after the domain is created—the purpose the Registrant puts the domain to, and⁄or the services the Registrants operates on. As stated earlier, due to the restricted nature of the gTLD the probability of any malicious use of domain names is severely reduced. 

However, the following practices are considered malicious use of domain names and will result in actions taken by the Applicant.
-	Illegal or fraudulent actions;
-	Spam;
-	Phishing; 
-	Pharming; 
-	Traffic diversion;
-	False affiliation;
-	Wilful distribution of malware;
-	Fast flux hosting;
-	Botnet command and control;
-	Distribution of any pornography; 
-	Illegal Access to Other Computers or Networks.
-	Any ideas or opinions of any kind of philosophical matter

Detailed descriptions of these abuses will be available in the Domain Name Anti-Abuse Policy that will be provided to all of Applicant’s its Registrants. Non-compliance to the Anti-Abuse Policy will be monitored the marketing department and the governance committee 

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

The abusive uses, as defined above, undertaken with respect to applicable domain names can give rise to the right of the Applicant to take such actions in its sole discretion. Should a dispute occur, the domain name will be put on hold immediately. Within 48 hours after the domain name was put on hold the dispute will be resolved and the domain will be accessible again or will be removed.


2.3.	Proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct

As already stated, Applicant does not foresee any issues regarding orphan glue records. 

Glue records can only be inserted with the domain name itself. Inclusion is based on the fact that the name servers have the same extension as the domain name. These address records only exist 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 removed from the registration database. Should any evidence be provided that a domain name, registered with the Applicant  is present in connection with malicious conduct, the name and glue will be simultaneously be removed. This limits the possibility of orphan glue records. 

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.

2.4.	Adequate controls to ensure proper access to domain functions

Due to the restricted nature of .lpl, some domain name functions will - at least initially not be allowed, such as domain name transfers. Access to other domain function requests, such as domain name update and deletion, are only possible through a centralized web-based request system owned and managed by the Applicant , after authentication via a strong password.  The following principles are used for strong passwords:
-	Users shall pick a password of sufficient complexity, which contain characters from at least 3 of following characteristics:
o	English uppercase characters (A through Z);
o	English lowercase characters (a through z);
o	Base 10 digits (0 through 9);
o	Non-alphabetic characters (for example, !, $, #, %).
-	A password should have a minimal length of 8 characters.
-	Passwords & PIN codes shall not be based on easily-guessable information, such as:
o	words from a dictionary;
o	data linked to a user (phone numbers, license plate, date or place of birth, ...);
o	significant portions of the userʹs account name or full name.

The usage of the strong passwords will be enforced, where possible, by the application used to access domain function.

2.5.	Measures to promote WHOIS accuracy.

As described in earlier, this application concerns a restricted⁄closed gTLD. WHOIS accuracy will be the responsibility of the Applicant. It is understood by the Applicant that is very important that the WHOIS maintains accurate and complete information. Consequently, the Applicant intends to take this responsibility for its account.  As all requests for a domain name application will be submitted to a prior approval to the marketing department, it will be the marketing department’s responsibility to ensure that all Whois related information is accurate and complete.
And due to the fact that only the Applicant, its financial customers and in a later stage its products sponsors and affiliates will only be allowed to apply and register a domain name within the TLD, Applicant will be able to ensure that the necessary background checks have been done and the contact details are correct.

2.6.	Other measures

All applied for domain names will be submitted to the marketing department in order to verify that the domain name applied for corresponds with the requirements as laid down in the registration policies.

3.	Resourcing plans 
As already stated above, Applicant intends to create a governance committee that will oversee the marketing department responsible for the initial implementation and ongoing maintenance of abuse prevention and mitigation. 

Both the Governance Committee and the marketing department will consist of highly skilled professionals, experienced in legal, business and technical domain name matters. In order to ensure that all staff that will be working on this project is up to date, periodical trainings in relation to abuse and misuse complaint handling and in all relevant fields will be provided.

In addition, as these domain names within the TLD will be provided as an additional service to it the Applicant current services, the Applicant does not foresee to hire any additional staff for this specific purpose. 

Due to the limited number of domain name registration and the restricted use of the TLD, Applicant is of the opinion that it is sufficient to dedicate 0.5 FTE. In the event that due Applicant would need to dedicate more staff than Applicant intends to allocate more resources. For more information, we refer to our response in questions 46 and 47.

1.Overview

As a well-known brand owner, the Applicant is very conscience about trademark protection. Therefore, Applicant understands ICANN’s concerns in relation to trademark protection and abuse on the Internet in general, and in the Domain Name System in particular, not only do trademark owners need to be protected but Internet users also need to be protected from malicious conduct. Consequently, the Applicant, after being delegated the TLD, will ensure that the .lpl TLD is a safe and secure name space for all Internet users by not only complying with Specification 7 of ICANN’s Agreement, but also by presenting a domain name registration policy that implements restrictions with respect to who can register domain names in this TLD. The Applicant will also be implementing takedown procedures as described below.

2. Prevent Abusive Registrations

In principle, the .lpl TLD will be a closed TLD and all domain name requests will go to the marketing department through a process that will be governed and overseen by a Governance Committee composed of employees who have a technical, legal and⁄or business background. The Governance Committee will ensure that the policies related to the TLD are observed. Because the .lpl will be a closed TLD, the domain name registration policy will contain clear restrictions. First, at least initially, only the Applicant will be entitled to register domain names in the .lpl TLD. Second, only Applicant’s financial advisors and product sponsors and affiliates will be able to register domain names that are directly or indirectly linked to their services and products including tag lines, slogans, etc. Furthermore, in addition to the Domain Name Abuse Policy (see response to question 28) we intend to protect third party rights and comply with ICANN’s requirements such as Sunrise, IP claims, URS, UDRP, PDDRP as specified in Specification 7.

As already stated, the Applicant intends to register in its name and on its behalf those domain names that are related to its core business (such as but not limited to: investors, financial advisors, banks, credits, clearing,…)The Applicant claims a legitimate interest in domain names that contain a generic description of the Applicant’s products and services offered in its normal course of business. All contacts associated with the domain names that are registered and delegated to the Applicant (i.e., administrative, technical and billing contact) will be associated with the Applicant.

During the second year or third year of operation, the Applicant intends to implement a sunrise service and trademark claims service, which will be organized as follows:

2.1. Sunrise Period

Applicant understands that, at minimum, it needs to implement a Sunrise Period of 30 days following the launch of the TLD allowing trademark holders to secure their domain names that correspond with their registered trademarks or any related IP rights.

Although the Applicant does not intend to open the gTLD to the general public it intends to implement a sunrise period in year 1 and year 2 under the following conditions: it will allow its financial advisors and products sponsors and affiliates to apply for a domain name that corresponds with their trademarks and that complies with the procedures laid down by ICANN and the Trademark Clearinghouse.

In no event will any entity or person other than parties that have entered into an agreement with the Applicant prior to a domain name allocation be able to register a domain name within the .lpl TLD. In order to ensure that this restricted policy is adhered to, the Applicant foresees that all domain names will be submitted to a clearance process whereby Applicant’s marketing department will be able to access and register domain names in name and on behalf of their clients within the gTLD. Applicant is aware of the fact that a clear process needs to be established and is committed to having this in place at the time it enters into the Registry Agreement. Furthermore, Applicant intends to publish this information on its website, so that it is clearly communicated to all internet users.

Furthermore, the Applicant will adhere to the terms and conditions as laid down by ICANN with respect to the interfacing with and use of the trademark clearinghouse. The Applicant ensures that it will deploy the necessary interfaces to the trademark clearinghouse in accordance with the technical specifications to be published by the trademark clearinghouse provider, and will also ensure that all records that are validated by the trademark clearinghouse provider and that meet the conditions of the Applicant’s polices will be registered within the .lpl TLD. However, and as already stated, in order to ensure that the domain name applications meet the conditions of registration, all domain name application will be submitted to internal clearance check prior to registration.

Furthermore, the Applicant intends to register all valid sunrise domain name registrations for a minimum period of 2 years or the remainder of the initial term of the Registry Operator Agreement with ICANN. However, the Applicant holds to right to delete any registered domain names that do not comply with the policy restrictions set unilaterally at the Applicant’s discretion.

2.2. Trademark Claims Services

The Applicant understands that at a minimum it must provide for a period of 60 days for trademark claim services. Under trademark claim services, Applicant understands that any third party that has eligible rights on a trademark, has submitted such evidence to the trademark clearinghouse, and has been validated will be entitled to send a notification when a Registrant applies for a domain name that is an exact match to his⁄her trademark.

Applicant also understands that in order to allow this service, its registry database will need to interface with the trademark clearinghouse so that trademark holders will automatically be notified when a Registrant applies for a domain name within TLD.

Applicant intends to implement this service at the same time as the Sunrise Period.

3. Identify and address the abusive use of registered on an ongoing basis

Applicant will comply with and implement decisions made according to the Trademark Post-Delegation Dispute Resolution Policy (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN. Applicant will also implement decisions made under the Uniform Domain Name Dispute Resolution (UDRP) and the Uniform Rapid Suspension (URS) procedures adopted by ICANN, including suspension of specific domain names within the registry. Applicant understands that such mechanisms constitute a minimum requirement.

Applicant intends to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Registry Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination.

By the “Post-delegation Dispute Resolution Procedure (PDDRP)”, we refer to the mechanism that allows a trademark owner to file a complaint against the Applicant claiming that one or more of its trademarks have been infringed, and that it has thereby been harmed, by the Applicant’s manner of operation or use of the .lpl TLD.

Applicant will therefore commit to answering each complaint within forty-five days after the date of the threshold review panel declaration. Applicant will also comply with the procedure, including additional rules and procedures laid down by the selected dispute service provider. Applicant will respect and implement the final decision by deleting the domain name registration in the event that the outcome of the process is in favor of the complainant.

Applicant understands that the “Registration Restriction Dispute Resolution Procedure (RRDRP)” is not applicable to the .lpl TLD due to the fact that this is a procedure between an established institution associated with a defined community (i.e. a community related to the gTLD string in the application that is the subject of the dispute) and the Applicant in the event that the latter does not respect the registry agreement.

Furthermore, and as already stated Applicant will set up a contact email where a responsible person will be in charge of making sure that the request from the relevant panels are being answered in due time. All requests will be managed by the marketing department.

The term “Uniform Domain Name Dispute Resolution Policy (UDRP)”, refers to a dispute resolution mechanism aiming at resolving disputes occurring between a Registrar and any party other than the Registrar over the registration and use of an Internet domain name registered by the Registrar. Applicant will implement the UDRP policy as laid down by ICANN and will publish this on its website.

In the event that the Applicant is made aware of a complaint, the domain name registration will be put on hold until it receives notification from WIPO. In the event that the complainant is successful, the domain name will be deleted.

We understand that the Uniform Rapid Suspension (URS) is a mechanism designed to offer trademark owners a quick and low-cost procedure to take down infringing websites. We also understand that a complaint will be submitted to an URS provider approved by ICANN. A decision in favor of the complainant will lead to the suspension of the domain name by the Applicant. Unless the decision is reversed, the domain name will lead to a mandatory URS placeholder page for the rest of the registration period.

Concerning the URS, Applicant understands that after the end of the administrative review (i.e. the review which aims at determining that the complaint contains all of the necessary information. This is not a determination as to whether a prima facie case has been established), the URS Provider will notify us immediately that the complaint is considered to be compliant with the filling requirements. Within 24 hours of receipt of the Notice of Complaint from the URS Provider, the Applicant will “lock” the domain, meaning that the Applicant shall restrict all changes to the registration data, including transfer and deletion of the domain names, but the name will continue to resolve. The Applicant will notify the URS Service Provider immediately upon locking the domain name (”Notice of Lock”). If after examination in default case, the examiner rules in favor of the Registrant, the URS service provider shall notify the Applicant to unlock the name and return full control of the domain name registration to the Registrant. Applicant understands it will be transmitted immediately the decision issued if the determination is in favor of the complainant. Immediately upon receipt of the determination, the Applicant will suspend the domain name, which shall remain suspended for the balance of the registration period and will not resolve to the original web site. The nameservers shall be redirected to an informational web page provided by the URS Service Provider about the URS. The URS Service Provider shall not be allowed to offer any other services on such page, nor shall it directly or indirectly use the web page for advertising purposes (either for itself or any other third party). The Whois for the domain name shall continue to display all of the information of the original Registrant except for the redirection of the nameservers. In addition, the Whois shall reflect that the domain name will not be able to be transferred, deleted or modified for the life of the registration.

4. Other mechanisms

The Applicant refers to its 1) domain name abuse policy and 2) internal checks.

As already stated in the response to question 28, the Applicant will not tolerate any abusive use or misuse of domain names or websites. For further details we refer to question 28.

In addition, the Applicant ensures that all domain name will be submitted to a clearance process in order to ensure that the domain name applied for complies with the abuse registration polices as set out by the governance committee

5. Resource Planning

As already stated above, Applicant intends to create a Governance Committee that will oversee the team within the marketing department that is responsible for the initial implementation and ongoing maintenance of abuse prevention and mitigation.
Both the Governance Committee and the marketing department will consist of highly skilled professionals, experienced in legal, business and technical domain name matters.

In addition, as these domain names within the gTLD will be provided as an additional service to the Applicant’s current services, the Applicant does not foresee to hire any additional staff for this specific purpose. Furthermore, Applicant’s marketing department consists out of approximately 90 professionals and is led by a chief marketing officer and supported by legal department that consists out of approximately 40 professionals.

At the start-up phase, Applicant intends to dedicate 0,5 FTE in the marketing department, who will be supported by the Applicant’s legal counsel. For more information, please see our response in questions 46 and 47.

Allen Russell Thorpe	Director
James Sellers Riepe	Director
James Steven Putnam	Director
Jeffrey Alan Goldstein	Director
Jeffrey Earl Stiefler	Director
John Joseph Brennan	Director
Mark Stephen Casady	Chairman of the Board and Chief Executive Officer
Richard Paul Schifter	Director
Richard Wallace Boyce	Director

Christopher Francis Feeney	Managing Director, Chief Technology Officer
Dan Hogan Arnold	Managing Director, Head of Strategy
Esther Marion Stearns	President, Chief Operating Officer
John Jerome McDermott, III	Managing Director, Chief Risk Officer
Jonathan Galen Eaton	Managing Director, Custom Clearing Services
Mark Robert Helliker	Managing Director, Broker⁄Dealer Support Services
Robert Joseph Moore	Chief Financial Officer
Stephanie Leigh Brown	Managing Director, General Counsel
William Edward Dwyer, III	President, National Sales & Marketing

Hellman & Friedman LLC	Not Applicable
TPG Partners, IV, L.P.	Not Applicable

New gTLD Application Submitted to ICANN by: LPL Holdings, Inc.

String: lpl

Originally Posted: 13 June 2012

Application ID: 1-1144-53270

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.