Application number: 1-1312-75662 for Metaregistrar B.V.

Metaregistrar B.V.

Jaagpad 20
Gouda 2802 AZ
NL

+31 182 477 000

+31 877 867 300

http:⁄⁄www.metaregistrar.com

Mr. Evert Wouter de Graaf

Business Unit Manager

+31 628 901 768

info@metaregistrar.com

Mr. Jan Hendrik de Jong

Owner

+31 6 5122 9332

henri@mijndomein.nl

Private Company (Besloten Vennootschap)

Dutch Law

Not Available

H2 Beheer B.V.

Henkjan de Krijger
Director
Jan Hendrik de Jong
Director

H2 Beheer B.V.
Not Applicable

J.H. de Jong Beheer B.V.
Not Applicable
J.H. de Krijger Beheer B.V.
Not Applicable

FRL

Not Available

The requested string is very simple and straightforward, not unlike any country- or geographic top-level domain. No specific rendering problems are to be expected with this string.
The string is not an IDN string and the character set is Latin left-to-right, so there will be no Bi-Directional issues.
To address potential operational problems, we have conferred with Matthieu Weill of the .FR registry to ask if he sees any problems with a new string that resembles the existing .FR string.
We have agreed that both strings have a very different public. There have been earlier attempts to warm the Frisian public to the FR string, but these attempts have gone without response. The Frisians recognize FRL als a common representative string of their own province, language and culture.
To further mitigate problemens that might arise between the FR and FRL registries, we have agreed with Mr Weill that a number of important .FR second-level domain names will be reserved in the FRL registry.

Friesland (http:⁄⁄en.wikipedia.org⁄wiki⁄Friesland) is one of the most northern provinces of The Netherlands. The people of Friesland refer to themselves as Frisians (http:⁄⁄en.wikipedia.org⁄wiki⁄Frisians), and are a very independent and close-knit community. The Frisians have their own (internationally recognized) language, which is recognized as an official language both in The Netherlands and in Germany. All towns, villages and communities have a Dutch name and a separate Frisian name that is shown on road signs and official maps.

Friesland is governed by the Provincie Fryslân, which is the official governing body of this province. The Provincie Fryslân first started plans for its own TLD as early as 2006, but due to political issues and changing political landscape this TLD still has not been realized. Together with SIDN, the Provincie Fryslân has conducted an extensive study of the potential for a Top-Level-Domain name in Friesland. The study focussed mainly on governments and businesses in Friesland, and concluded that there is a market for at least 40.000 domain names there. If we add to this the potential consumer market, we see a business case for 100.000 domain names in Friesland.
 
 In december 2011 the Provincie Fryslân started a public tender for the .FRL gTLD, and Metaregistrar entered this tender. From all the parties, Metaregistrar was willing to take full responsibility for both the application and the funding, and was selected as preferred partner by the Provincie Fryslân.

During the years that an own TLD for Friesland was in the making, several alternatives were considered: .FRIESLAND (but that is Dutch language, not Frisian), .FRYSLAN (but that would need an accent on the A) or .FRYSLÂN (that would be an IDN application, which would make e-mailing difficult for many people in The Netherlands). From the alternatives, FRL was selected, because many Frisians already identify themselves with an FRL sticker on the backs of their cars, and within The Netherlands, FRL is widely recognized as short for Friesland.

According to ISO3166-2, the official code for Friesland would be NL-FR. However, both NL and FR are already taken as 3166-1 country codes, and NLFR would not be a tld that speaks to the heart of the Frisians because it still starts with NL.

The .FRL domain extension is targeted at Frisian people living in Friesland, Frisians living in other part of the Netherlands, and Frisians living abroad and wanting to identify themselves with the Frisian culture and heritage.

This means that the FRL top-level domain will serve the Frisians not only in the province (between 600.000 and 700.000 people), but also the Frisians that have moved into the rest of The Netherlands or abroad. Also, the northerns parts of Germany have a Frisian community that strongly identifies with the Frisians in The Netherlands. The general feeling is that people from Friesland will stay Frisian for their whole lives, and are very willing to identify themselves with anything coming from Friesland.

The Netherlands are populated with about 17.000.000 people, and the .NL registry holds almost 5.000.000 second-level domain names. If we extrapolate these numbers to the Frisian population, we can expect conservatively 100.000 second-level registrations, but 200.000 registrations would be very possible from the inhabitants of Friesland alone. And that is not counting the Frisians living in other parts of the Netherlands or Frisians living abroad. Add this to the fact that most Frisian names have 3 means of spelling: Dutch spelling, Frisian spelling without accents and Frisian spelling with accents, this all adds up to a very valid business case for a gTLD.

When enough Frisians adopt a .FRL domain name, this TLD will serve as glue between the Frisians living in Friesland and the Frisians living elsewhere, giving the people living abroad a means to visually identify themselves with the Frisian community in Friesland.

An additional benefit to using a .FRL tld is the use of Internationalized Domain Names (IDNs). The Frisian language contains many words that require special characters to be spelled correctly. For example, the government of Friesland is reachable under www.fryslan.nl, however the correct spelling would be fryslân.nl. Since SIDN has not rolled out IDN support yet, this domain name is not possible. With the use of new gTLDs, the province will be able to register the domain name fryslân.frl. We expect a boost in websites that feature the Frisian language, and many website owners wanting to register not only the IDN variant but also the variant without special characters, if only to be able to send and receive e-mail correctly.

The whois services of the FRL registry will adhere to the Dutch privacy laws. This means that for the public whois services only a limited amount of data will be shown. Any party having a legitimate right to all the whois information will be able to contact the registry and gain access to the private whois service. Connected registrars will also have access to the private whois service to enable them to execute the domain transfer policies correctly.

The web-based whois service will show more information than the publicly available port 43 whois, but will be protected with a captcha to prevent harvesting of data.

Registration of .FRL domain names will be open and unrestricted to any ICANN-accredited registrar. There are no intentions to restrict registration to people originating from Friesland only, because many Frisian people live in other parts of The Netherlands or Germany or have moved abroad. It is these people we want to give the chance of identifying with the Frisian community by registering a .FRL domain name.

As stated in the ICANN policies, all names like example.frl, www.frl, iris.frl, nic.frl and whois.frl will be reserved in the domain name system, as all the names of countries and territories that are specified in the ICANN newGtld documentation. Domain names with hyphens are allowed, but no two hyphens may be next to each other in a domain name. This way, domain names starting with xn—will not be accepted by the registry.

Numbers in domain names are allowed. Domain names can start or end with any number.
All 1 character and 2-character domain names are reserved, and can only be released after ICANN approval.

Internationalized Domain Names (IDNs) will be allowed, but only the characters that relate to the Frisian and Dutch languages. Since no character table exists in the IANA tables with that specification, a new table will be added.

In addition to this, all names of Frisian villages and cities will be reserved, where necessary in three variants: Dutch language, Frisian language and Frisian language with special characters. We are working together with the Frisian Academy for a exhaustive list of names. Together with the Province Fryslân we will encourage all local governments to claim their domain name(s), we will use an external party to verify those claims.

Every domain name can be registered for a period of 1 to 10 years. At this time, no discount pricing has been established for registrations longer than 1 year.

The sunrise and landrush stages will be performed as follows:
1. Sunrise for trademark holders and companies
Any party holding a trademark or registered name will be able to apply for domain names in the .FRL gTLD. Each claim will be checked and verified by an external party, capable of verifying these claims. Whenever a claim is approved, the trademark holder will receive an authcode for that specific domain name. 
We do not expect many trademark holders wanting to claim a domain name in this period of time, so multiple applications for the same domain name will be handled on a first-come first-serve basis. That is, after the documentation supporting the claims have been verified.
At the same time, all companies and institutions will receive a letter with their company domain name that can be claimed. This will raise awareness with the new TLD. The companies and institutions can use the authcode in that letter to register their domain name. If they want to register more domain names, they will have to use the next sunrise (for the Frisian community) or the open registration (landrush) period.


2. Sunrise for the Frisian community
Worldwide acceptance of the .FRL tld will stand or fall with acceptance by the Frisian community itself. We have agreed with the Provincie Fryslân that the FRL registry will supply all addresses in Friesland with discount codes to pre-register a domain name. Each physical address will receive 2 discount codes: one for themselves and one to use for a relative or friend abroad. This way we will raise the awareness of .FRL existence, and let all people in Friesland (and Frisians abroad) know that this extension is available for registration. The discount code will give a discount of at least 50% on the regular domain name price.

The discount codes will be accepted by the EPP server of the registry, and can be used by any ICANN accredited registrar approved and connected to the .FRL registry. We will encourage people asking for the .FRL extension with their local domain name provider, because every extra selling point of domain names will benefit the whole .FRL registry.

Multiple registrations for the same domain name will be handled on a first-come first-served basis.

3. General availability
After the Frisian pre-registration, registration will open up without use of coupon codes. No restrictions are imposed on the registrants; anyone will be able to register a .FRL domain name.

Multiple registrations for the same domain name will be handled on a first-come first-served basis.

Since the Frisian community and the Provincie Fryslân are strong supporters of the independent Frisian language, our sister company Mijndomein.nl has plans to open a domain name registration page in the Frisian language. 

The Provincie Fryslân has already opened a page on their website to ask the Frisian people if they are willing to register a FRL domain name, and the name of their registrar. This information will be used by the registry to actively contact the Frisian domain name registration and hosting companies and get them connected with the Frisian Top-Level domain either with their own ICANN accreditation or via a reseller agreement with one of the connected registrars.

The registry is already in contact with the (currently 9) ICANN accredited registrars in The Netherlands, and has received several intentions to connect with the registry and sell FRL domain names.

Multiple requests for the same domain name will be handled on a first-come, first-served basis. Since the FRL registry will become and stay a relatively small registry, we do not expect many problems in this area. Where problems arise with multipe parties wanting the same domain name, the legal personnel of the registry will solve these issues together with the parties involved.


Domain name pricing
The Provincie Fryslân has produced an extensive report on the FRL tld in 2011, stating that with a price of EUR 40 for a domain name, it would be possible to register 40.000 domains, and have a valid business case. However, this plan did not include the large consumer market in The Netherlands, consumers that are accustomed to much lower prices per domain name than 40 euro.

To accommodate the consumer market, the registry will start pricing at EUR 15,- per domain name. This will allow ICANN-accredited registrars to set their pricing at 20 – 30 euro, acceptable for consumers and businesses alike. With the Provincie Fryslân an agreement has been proposed, that on higher numbers of registrations the price will automatically drop, to a minimum of EUR 2,50 per domain name when total numbers of registrations hit 800.000 or more. Price increases are not expected. If a price increase would be deemed necessary, ICANN will be notified and asked for permission, as well as timely notification to all registrars that are connected to the registry. There are no specific plans for price increases. We are convinced that the 100.000 domain names in our plan is very well achievable, and that there is a high probability that domain name registrations will exceed 100.000 domains. At that point prices will drop, and not increase. There are no commitments to registrants about price escalation, only a commitment to the Provincie Fryslân about price decreases.

Together with the Provincie Fryslân a plan has been made to address all Frisian companies and citizens. In the first stages the sunrise (where trademark holders can apply) all companies that have a head office in Friesland will receive a letter from the Province that a top-level domain name can be registered for their company. This letter will contain a domain name for the company, and a authorization code to register specifically that domain name. The auth code is not bound to a specific registrar.

In the second stage, where all Frisians can apply, we will send letters to all Frisians and companies in Friesland with discount ⁄ auth codes. These codes will allow registration of Frisian domain names at a discount price (5,00 euro per domain name). The discount codes are not bound to a specific registrar.
When letters with discount codes are sent to the addresses in Friesland, these codes will allow any ICANN-accredited registrar to pay only EUR 5.- per domain name (the discount is part of the marketing costs⁄budget). When the ‘Frisian sunrise’ is over and the general landrush has arrived, the normal price of EUR 15 per domain name will apply. In this phase, discount codes will still be accepted, and will still only charge EUR 5,- for a domain name to the ICANN-accredited registrar during the first year.

No

Not Available

Yes

he FRL registry will reserve all country-specific domain names that are indicated in the ICANN documentation. However, we do not expect any country (except the Dutch government) to be interested in a domain extension that is so specifically targeted at a province of The Netherlands.

The registry will reserve all names of Frisian cities, communities and villages. Together with the ʹFrisian Academyʹ, a specialist in the Frisian language, we have compiled and publishad a comprehensive list, in three ways:
- In the Frisian language, with IDN (e.g. feanwalsterwâl.frl or xn--feanwalsterwl-teb.frl)
- In the Frisian language, but without accents or special characters (e.g. feanwaldsterwal.frl)
- In the Dutch language (e.g. veenwoudsterwal.frl)

This list of reserved community, city and village domain names can be found at
http:⁄⁄metaregistrar.com⁄reserved-community-domain-names⁄

All these names will be added into the registry administration as ‘reserved’. A list of reserved names will be published as general accessible document on the website of the registry.
In the early sunrise phase, all cities and villages will receive notice about the opportunity to register their name with the .FRL registry. They will be able to register through any ICANN accredited registrar, provided that this registrar has entered into an agreement with the FRL registry.

Whenever a claim is made on a reserved domain name, the registry will use an independent law firm to check the claim on its validity. Every valid claim will give the authorities the choice of the 3 different domain names mentioned before.
Every authority that has succesfully claimed a domain name from the reserved list will receive an authcode for every claimed domain name. With this authcode the domain name can be registered through any ICANN-accredited registrar. The authcode will work only for the domain name it was issued to.


Upon a domain check, the reserved names will return the status string ‘reserved’. When the whois information is checked, these reserved names will not display whois information, nor will they be added to the DNS zone.

Protection of geographic names at the second level.
All geographic names specified by ICANN in specification 5 of the draft registry agreement will be listed as reserved and can only be registered through a special procedure.
A list of reserved country names can be found at http:⁄⁄metaregistrar.com⁄reserved-country-domain-names⁄
Any country-specific domain name that is brought to our attention by the GAC, and has passed GAC internal procedures, will be added to the list of reserved domain names, published on our website.

The ICANN specification 5 also mentions “the list of United Nations Member states in the 6 official languages of the United Nations”. To reserve these names will technically not be possible, since many of those names (russian, chinese) contain characters that are not supported by the registry. They cannot be registered with the FRL registry anyway.

Since this TLD is targeted at a specific part of a small country, we expect very little interest for country-named domain names. Even with a very large registry like .INFO many country names are still reserved. And many countries have no interest in the English version of their country name.

Any country or region interested in obtaining their own domain name that is on the reserved list, will first have to be approved by the GAC and ICANN. Only after these approvals the second-level domain name will be released to the requestor.

All services below are hosted on duplicated infrastructure in separate networks for failover and data backup security.

1. An RFC-compliant EPP service
This service takes care of all host, contact and domain object registrations, alterations and deletions.

The EPP service is written entirely in Java 1.7 by the programming staff of our mother company H2 Services, and designed with stability, speed and security as basis of the code. The server will only accept connections coming from IP addresses that have been registered by the clients of the FRL registry. Any request coming from another IP address will be rejected. The service will be protected against DDOS attacks with a webbased DDOS scrubber or local applicance.

Every connection to the service is logged in the object administration; with every log a session time in milliseconds is also logged. Daily reporting from the server indicates if average session time is increasing or decreasing, giving the maintainers of the service a good indication if the service is performing within standards. These reports are also used as test for measuring compliance to internal and external Service Level Agreements (SLAs). The reporting module also reports numbers of sessions and session times per accredited registrar. Whenever a registrar crosses indicated thresholds, the registrar can be temporarily denied access to the EPP service. The thresholds can be set on a per-registrar basis, allowing larger registrars to have more and longer sessions than smaller ones.

 The EPP service will accept host objects, but not host attributes. Host objects will be unique for the whole registry. When host objects are registered by any user that is not the owner of the associated domain object, the host objects are automatically assigned to the owner of the domain object in the same administration. Only the host-object (and thus the domain-) owner can change attributes on the host object.

The EPP service is connected to a MySQL database that is normalized to the third normal form, allowing all possibilities in naming and objects that are described in RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734.
Every EPP command received by the server is checked against the xsd schemas using the Oracle JAXB (Java Architecture for XML Binding) technology. This forces the programmers to write proper xsd schemas for every extension that is made to the standard EPP implementation.
All connections to the EPP service are SSL encrypted. Every connection is monitored and logged for later inspection. Every command issued to the server is logged, with information about the type of command issues (info, create, modify, delete) and the amount of milliseconds it took to complete the command and answer to the registrar. These parameters are saved into a daily report of EPP operational statistics. The connected registries will also have access to their own statistical information.

2. Shared registration system
The registration system is a website where ICANN-accredited and FRL-approved registrars can administer the domain, contact and host objects they have created. They will have the possibility of creating and deleting objects, and viewing object status. The website will query the registry database on a read-only basis, and all object modifications submitted on the website are done via the EPP service. All connections to the website are SSL-encrypted.
Every registrar that has a contract with the .frl registry will be able to log in to this website, and see:
- The registrar’s current financial status. Registrations are done based on prepayment. Every registrar will have to pay in advance fee to be able to register domain names. Every registered domain name or transfer will be deducted from the prepayment. When prepayment levels are low, the registrar is warned that new payments must be done to get the prepayment level to an acceptable height. When there is no money left in the account, the registrar will not be able to register domain names.
In special cases, personnel of the FRL registry can assign a negative threshold to the prepayment levels, enabling the registrar to register domain names while payment is underway.
- The registrar’s invoices. Every month an invoice will be prepared for the registrar, for the totals of registered domain names and requested transfers that were completed. The addendum to the invoice will list all transactions that have a financial impact on that invoice.
- The registrar’s domain portfolio. The registrar will be able to list, search and maintain all domain names in its portfolio. A registrar can choose to create more then one account, and give each account specific access rights: some accounts can only view domain data (and for example no invoices), other accounts can see invoices or do payments, or maybe request a new domain name or a transfer.
All modifications of domain, host or contact objects that are requested via the website are done through the EPP server. The website itself is not allowed to do any modification to the domain administration, and has only viewing and listing rights to the database.
Like with the EPP service, all connections to the website are monitored and all actions on the website are logged. In case of EPP object modifications, the logging is done twice because the EPP service also logs the operation.


3. A DNSSEC enabled DNS service, based on NSD. All domain names that have nameserver information attached, will be automatically added to the zone database, which is published to a zone file every 5 minutes. Since the DNS servers have a huge amount of internal memory, almost all queried domain names remain in the cache, so the handout of ip addresses is very fast. The Infrastructure department that is used by the registry already has experience with the 500.000+ domain names that are maintained on our a Powerdns 2.x installation. These domain names are served without any problems, the uptime of the DNS services has been 100% over the past few years.


4. Port 43 and web-based whois services. 
Both services take their data directly from a read-only slave configuration of the MySQL registration database that is used by the EPP service. To protect the consumer, and to comply with Dutch legislation, the publicly available whois server will only show a limited set of information when the domain name is registered by a consumer.
ICANN-accredited registrars or other organizations that need access to all domain and registrant data can register their ip addresses for a more detailed whois information overview.
The whois server will show non-ascii characters in Unicode format. The whois webservice will use Unicode html to show non-ascii characters.
The web-based whois service will be searchable on the fields as described in specification 4 of the draft registry agreement: partial matches will be possible on domain name, contact names, registrant name, address information like street, city or province. State is not applicable in the Netherlands.

5. Internationalized Domain Names 
Since the Frisian language contains (and relies on) other characters then the Dutch language, IDN registrations will be accepted from the earliest phases.

6. RFC-based DNSSEC compliance 
The DNS service is based on NSD, and fully DNSSEC compliant. Registrars can register their DS keys via the EPP service, or via the web interface, which will also use the EPP service.

7. Registry Data Escrow deposits and Registry Backup Provider
The registry will enter into a contract with a data escrow provider to perform weekly and daily deposits of the applicable fields in the registry database. The registry escrow provider will release the data to ICANN when the registry data is unrecoverable.
Also, the registry will enter in to a contract with a registry backup provider, and perform yearly tests on registry backup and failover.

8. Monthly reporting to ICANN. The registry will perform the monthly reporting as specified in specification 3 of the draft registry agreement. The parameters saved by the DNS, EPP and website will be used to create automated reporting to an ICANN-specified address or location.

The heart of the shared registration system consists of a website for registrars and other parties that are connected to the registry, and the EPP service that administers domain, contact and host objects. The website of the registration system is allowed to query lists of domain, contact or host objects, but is not allowed to make object modifications. All modifications on the registry objects are done through the EPP service.

All services reside on redundant hardware, supported by both a hot standby and a cold standby facility on different physical locations. All data resides on storage solutions and is replicated automatically over the hot- and cold standby facilities. The hot standby is never more than a few minutes out of sync with the main facility. In case of a disaster on the main location, website and EPP services can switch to the hot standby facility within one hour. The cold standby data is replicated once a day.

All services have at least 2 instances running at different virtual machines. The load between the instances is handled by load balancers that will direct packets to the fastest-responding service.
When response times of the services drop below an acceptable level, new servers will be rolled out and load-balancers will be changed to include the new servers. The EPP servers are programmed to distribute load of requests over multiple instances of the servers.

Interoperability with other systems
The database of the registration system is queried on a read-only basis by the WHOIS service, and by the automated procedures that generate reporting to ICANN or other parties. 
The EPP service is used by the website for all modifications of EPP objects. The website has direct access to the EPP database, but that is a read-only access for generating lists. The website is not allowed to directly modify EPP objects, only through the EPP service. 



Registration System Performance
The following tests have been performed on the registry system via the EPP service. The tests were performed with a PHP program as a client and the java-written EPP service as server. This test is done on a single instance of the EPP service running at one single location.


50 concurrent connections: MIN,AVG,MAX are in milliseconds. Benchmark took 535 seconds to handle 150000 transactions. Average 269 transactions per second.

Type Min (msec) AVG (msec) MAX (msec) total 95th percentile (msec)
checkContact 1 22.7755 714 10000 65
checkDomain 9 34.8354 715 10000 83
checkHost 2 23.6579 705 10000 67
createContact 11 89.6172 1080 10002 201
createDomain 27 161.7708 1204 10001 350
createHost 11 83.2008 1076 10001 183
deleteContact 16 101.9805 1088 1995 228
deleteHost 11 82.4095 848 1966 178
infoContact 2 41.254 825 30000 111
infoDomain 12 44.3958 803 10000 116
infoHost 4 32.8313 1040 20000 92
login 21 48.5294 123 51 104
logout 5 15.2941 121 51 28
pollReq 5 111.8144 1325 10000 295
updateContact 16 101.6966 1076 10000 226
hello 14 40.9412 263 51 69
total 10.2 66.4042 849.5333 144067 186


runtime seconds: 535 
transactions⁄sec: 269.2841 



The registry system logs all issued commands, together with specific command type information (info, create, modify, delete) and object information (domain, contact, host object). This enables us to create detailed reports on the performance of the registry service. If performance is drops over time, the software is prepared to distribute requests over multiple instances of the registry service.

Resourcing plans
The resource indentifiers used in this document are detailed in the text of question 46


Resourcing in the initial phase; This is for setup only, the functions already have been programmed and tested.
R.1 System engineer Infrastructure setup 2 days
R.7 Programmer Software setup 3 days
R.6 Project leader Project lead 2 days
R.8 Tester Website testing 1 day
R.11 Designer Website design 1 day

Resourcing for ongoing maintenance
R.2 Operations Engineer Maintenance of infrastructure 1 day ⁄ year
R.5 Support personnel Handles questions from registrars and registrants 100 days⁄year
R.6 Project manager Oversees changes to the system 2 days ⁄ year
R.7 Programmer Programming of changes 8 days ⁄ year
R.8 Tester Testing changes 2 days ⁄ year
R.9 Release manager Releasing software 2 days ⁄ year

T.5 Change board Approval of major changes to the websites As-needed basis

The EPP services of the FRP registry is compliant with all major EPP RFCʹs: RFC5730, RFC5731, RFC5732, RFC5733 and RFC5734. 

The EPP service of the FRL registry complies to RFC5730 to RFC5734 and RFC5910 for the DS keys of the DNSSEC protocol. The EPP service is written entirely in Java, and uses JAXB (Java Architecture for XML Binding) components to verify incoming XML EPP requests against the XSD’s. The JAXB components use the standard epp, eppcom, domain, host and contact namespaces, as well as the additional namespaces from the FRL registry to verify the incoming XML. Any incoming command that does not conform to the EPP specification will be rejected by the JAXB components. The EPP service does not contain modifications of the domain, host and contact objects, but makes use of the EPP extension protocol described in RFC5730 for any request that does not fit in standard EPP.

Internal structure of the EPP service

The EPP service is programmed into different thread pools that handle the following tasks:
1. EppServerConnection pool, handling incoming EPP connections
2. EppParser pool, Thread pool for validating and parsing the EPP request
3. EppMessageInterpreter pool, Thread pool for interpreting and handling EPP commands
4. ScheduledTasks pool, handles the tasks that require scheduling

Every pool can be replicated more then once within a single server for optimal performance and session handling. Pools can also be allocated to other virtual servers to distribute load between servers.

Database structure

The database structure for the registry service is derived directly from the EPP data objects as described in RFC5730 - RFC5734. This means that wherever the EPP dictates that more then one object can be created, the database structure has separate tables and foreign keys to match.
Databases are addressed in Java using the Hibernate database modelling tool. This tool supports the foreign key structures in the databases, and enables us to select a different database platform without major changes to the software.


Access to the EPP service

The FRL registry offers three different EPP services:
- The test service
- The staging service
- The live service

Any ICANN accredited registrar can receive access to the test EPP service. This way the registrar can test their systems for EPP compliance with the FRL registry.

When a registrar wants to use the live services, a registrar-registry agreement must be signed, that will outline the duties of the registry and of the registrar.
When the RRA is signed, the registrar will get access to the staging and live services of the registry.
When the registrar wants to use the live services for actual registrations, the registrar will have to add funds to the account of the registry. These funds can be in USD or in EUR. The balance of the registrar will be shown in the registration system. If the balance is positive, the registrar can register domain names or request transfers.

Domain transfers

Registrar to registrar transfers will be authcode based. Any registrar with a valid authcode will be able to start the transfer of a domain name to its own administration. The RRA will dictate that the registrar will inform the domain name registrant of the transfer and enable the registrant to stop it when the transfer is unwanted.
Changes of registrant will be the responsibility of the registrar. The registrars that request registrant changes will be fully responsible for any errors in the processing of these requests. Only in specific cases will the registry interfere with registrant changes.

Access to the service

ICANN-accredited registrars that have a signed RRA and access to the registry system will be able to create accounts that can access the EPP service. Specific accounts can be made with specific rights. The registrar can choose to make read-only accounts, or accounts that have no access to the account balance and invoicing, or accounts that can register but not transfer.
Any access to the service is logged with IP data. Daily reporting will show all registrar activity to the registry management. Active throttling mechanisms will prevent registrar abuse or misuse of the system.


Data logging and reporting

The EPP service has extensive logging of all commands that registrars will issue. Every command is logged with command type (info, create, update, delete) and object type (domain, contact, host). All commands are logged with session times and total duration of the session.
Daily reporting will show the management actual status of the EPP service and the session activity on the service.
Monthly reporting to ICANN will show domains registered, transfers done and all other parameters requested by ICANN.


Extra functionality

Two extra functions were added to the EPP service, to provide for requests that are not in standard EPP. For this we published our own schemas on the website of Metaregistrar.com. 
The extensions are made consistent with RFC3735 for extending EPP.

The first function is an extension to the Poll protocol. The standard poll has limited support for certain objects, and we needed more.

The second function is an extension to remove a domain name from quarantine. This is not covered in standard epp (the standard EPP RFC does not recognize the status ‘quarantine’). Since quarantine is supported, and there is a need to automatically recover domain names in quarantine, the EPP specification was extended with a undelete command. 

A third function that is not standard EPP, but did not require any additional XSD information is the use of authcodes to register reserved domain names. Any domain name that is on the reserved list can be registered by using a specific authcode. The authcode is valid to that domain name only. Any party with a succesful claim to a reserved domain name is entitled to receive the authcode and is able to register the domain name with any ICANN-accredited registrar.


Resourcing for the EPP services
The resource indentifiers used in this document are detailed in the text of question 46

To setup the EPP services, the following resources will be used
R.1 Systems engineer Design and prepare infrastructure 1 day
R.6. Project manager Determine changes or additions and delegate to programmers. 1 day
R.7. Programmer Change the software as needed. Perform system-acceptance tests. 1 day
R.8. Software tester Test changes against the functional design. Perform user-acceptance tests 1 day


To maintain the EPP services, the following resources will be used:
R.2 Operations Engineer Maintain hardware and infrastructure 1 day⁄year
R.5 Support employee Answer questions about the EPP service 20 days⁄year
R.6. Project manager Determine changes or additions and delegate to programmers 1 day⁄year
R.7. Programmer Change the software as needed. Perform system-acceptance tests. 8 days⁄year
R.8. Software tester Test changes against the functional design. 1 day⁄year
R.9 Release manager Release new software 1 day⁄year
T.5 Change board: approve changes to the functionality


Financials:
The EPP services were written for the mother company H2 Beheer BV. This is the company that leases the software to the FRL registry. With H2 Beheer BV an agreement is made that the software will be free for use until the Most Likely scenario of 100.000 domain names has been reached. At that time a fee for software usage will be determined.


XSD structures of the EPP extensions used by the FRL registry
All XSD files can be found at http:⁄⁄metaregistrar.com⁄epp-protocol-extensions⁄ 


ext-1.0.xsd, a base extension to enable extending the EPP system
This extension enables us to use the undelete command to retrieve domain names from quarantine. The quarantine function is further described in the answers to 
〈schema targetNamespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄ext-1.0ʺ xmlns:ext=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄ext-1.0ʺ xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ xmlns:domain=ʺurn:ietf:params:xml:ns:domain-1.0ʺ xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ elementFormDefault=ʺqualifiedʺ〉
〈!-- Import common element types. --〉
 〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:domain-1.0ʺ ⁄〉
〈annotation〉
 〈documentation〉Metaregistrar EPP extensions〈⁄documentation〉
 〈⁄annotation〉
〈element name=ʺextʺ type=ʺext:extTypeʺ ⁄〉
〈complexType name=ʺextTypeʺ〉
 〈sequence〉
 〈choice〉
 〈element name=ʺcommandʺ type=ʺext:commandTypeʺ ⁄〉
 〈⁄choice〉
〈⁄sequence〉
 〈⁄complexType〉
〈complexType name=ʺcommandTypeʺ〉
 〈sequence〉
 〈choice〉
 〈element name=ʺundeleteʺ type=ʺext:undeleteTypeʺ ⁄〉
 〈⁄choice〉
 〈element name=ʺclTRIDʺ type=ʺepp:trIDStringTypeʺ minOccurs=ʺ0ʺ ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉
 〈complexType name=ʺundeleteTypeʺ〉
 〈sequence〉
 〈any namespace=ʺurn:ietf:params:xml:ns:domain-1.0ʺ maxOccurs=ʺ1ʺ minOccurs=ʺ1ʺ ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉
〈⁄schema〉


command-ext-1.0.xsd, a base extension to extend the domain, contact and host commands
This command extension supports extending domain, contact or host command structures.
〈schema targetNamespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-1.0ʺ xmlns:command-ext=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-1.0ʺ xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:eppcom=ʺurn:ietf:param:xml:ns:eppcom-1.0ʺ xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ elementFormDefault=ʺqualifiedʺ
〈!-- Import common element types. --〉
 〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ ⁄〉
〈annotation〉
 〈documentation〉 Metaregistrar EPP Command extensions 〈⁄documentation〉
 〈⁄annotation〉
〈element name=ʺcommand-extʺ type=ʺcommand-ext:commandExtTypeʺ ⁄〉
〈complexType name=ʺcommandExtTypeʺ〉
 〈choice〉
 〈any namespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄comman-ext-domain-1.0ʺ ⁄〉
 〈any namespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄comman-ext-contact-1.0ʺ ⁄〉
 〈any namespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄comman-ext-host-1.0ʺ ⁄〉
 〈⁄choice〉
 〈⁄complexType〉
〈⁄schema〉


command-ext-domain-1.0.xsd, extends the domain command
This extension supports the opt-out option to limit whois visibility
〈schema targetNamespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-domain-1.0ʺ xmlns:command-ext-domain=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-domain-1.0ʺ xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ elementFormDefault=ʺqualifiedʺ〉
〈!-- Import common element types. --〉
 〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ ⁄〉
〈annotation〉
 〈documentation〉 Metaregistrar EPP Command domain extensions 〈⁄documentation〉
 〈⁄annotation〉
 〈element name=ʺdomainʺ〉
 〈complexType〉
 〈sequence〉 〈element name=ʺoptOutʺ type=ʺbooleanʺ ⁄〉 〈⁄sequence〉
 〈⁄complexType〉
 〈⁄element〉
〈⁄schema〉


command-ext-contact-1.0.xsd, extends the contact commands
Empty at this point, for future use only if we want to extend contact commands
〈schema targetNamespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-contact-1.0ʺ xmlns:command-ext-contact=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-contact-1.0ʺ xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ elementFormDefault=ʺqualifiedʺ〉
〈!-- Import common element types. --〉
 〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ ⁄〉
〈annotation〉
 〈documentation〉
 Metaregistrar EPP Command contact extensions
 〈⁄documentation〉
 〈⁄annotation〉
〈element name=ʺcontactʺ〉
 〈complexType〉
 〈sequence〉
〈⁄sequence〉
 〈⁄complexType〉
 〈⁄element〉
〈⁄schema〉


command-ext-host-1.0.xsd, extends the host commands
This Empty at this point, for future use only, if we want to extend host commands
〈schema targetNamespace=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-host-1.0ʺ xmlns:command-ext-host=ʺhttp:⁄⁄www.metaregistrar.com⁄epp⁄command-ext-host-1.0ʺ xmlns:epp=ʺurn:ietf:params:xml:ns:epp-1.0ʺ xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ elementFormDefault=ʺqualifiedʺ〉
〈!-- Import common element types. --〉
 〈import namespace=ʺurn:ietf:params:xml:ns:epp-1.0ʺ ⁄〉
 〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ ⁄〉
〈annotation〉
 〈documentation〉 Metaregistrar EPP Command host extensions 〈⁄documentation〉
 〈⁄annotation〉
〈element name=ʺhostʺ〉
 〈complexType〉
 〈sequence〉
〈⁄sequence〉
 〈⁄complexType〉
 〈⁄element〉
〈⁄schema〉

The FRL registry will operate a whois service available via port 43 in accordance with RFC3912, and a web-based whois service at whois.nic.frl, providing a free and publicly available query-based access to the domain name and registrant information. The web-based service will be protected against abuse with a captcha element. The port 43 service will be protected against abuse with throttling capabilities and logging of IP addresses and search queries.

The format of the whois responses follows a semi-free text format, followed by a blank line and a legal disclaimer specifying the rights of the registry operator, and the rights of the user that queries the whois service.

The whois service will respond to domain name data, registrar data and nameserver data queries, as specified in specification 4 of the registry agreement.
The format of the data fields that show domain status, names of individuals or organizations, addresses, streets, cities, states⁄provinces, postal codes or countries will conform to the mappings specified in RFC 5730, 5731, 5732, 5733 and 5734.

The web-bases whois service at whois.nic.frl will be searchable with wildcards and partial matches on domain names, contact names, postal addresses and its subfields described in the EPP rfc’s. With boolean logical operators AND OR NOT users can combine several search criteria.

The whois services will log each search request for internal reporting, and for monthly reporting to ICANN.


Technical implementation

The whois implementation will consist of a set of whois servers, querying the EPP administration database on a read-only basis. Since the whois solutions found in the open source did not have search capability, we have decided to write the whois solution ourselves, using the java language protocols already in place. Whois queries will be dispersed by load balancers over multiple active whois servers.

The newly written whois servers have the following role:
1. Perform basic whois lookup capabilities for any internet user. This includes basic information about registrant, administrative contact, technical and billing contacts for a domain objects. Also it will show attached nameserver information and dates and times of information update. The whois solution will comply with Dutch privacy laws, displaying only data that is not privacy sensitive. For all whois information, authorities or other parties that have a right to see the complete whois can register with the registry to get access to the full whois, see role 2.
2. Perform advanced whois lookup for authorities or other parties requiring full whois lookup capability. The whois server will accept the IP address of the querying server to determine if full access is granted. Registrars that are connected to the registry will also be granted full whois lookup possibility, to the extent of 110% of the number of domain names in their portfolio per day.
3. Perform nameserver (host object) lookup functionality. This lookup can be performed by any internet user.
4. Perform registrar lookup functionality. Full contact lookup is only granted to authorities or other parties that have been granted full access.
5. Searchable whois, as described in specification 4 of the draft registry agreement.


Whois abuse prevention and mitigation
All whois servers are fitted with throttling capability, and will report on a daily basis on how many queries were done from which IP address. If an IP address or range of addresses will perform too many queries, the throttler will deny access to that address range for a specific amount of time.

If too many whois queries were done from one single IP address or range of IP addresses, the address range will be blocked whois access.

The whois services will comply to Dutch privacy regulations. That means that the whois services will only show a limited amount of data on private registrants. This makes the public whois service less interesting for abuse.
Parties having a legitimate right to all administrative domain name information have the possibility to request access the restricted whois service. They will be able to log an IP address range with the registry and query the web-based or port 43 whois from that IP address for full whois access.


Resourcing for the WHOIS functionality
The resource indentifiers used in this document are detailed in the text of question 46


Resourcing for the startup phase
R.1 System engineer Technical installation, server setup 1 day
R.6 Project manager Whois startup 2 days
R.7 Programmer Programming and testing 3 days
R.8 Tester User acceptance test 1 day



Resourcing for the management phase
R.2 Operations engineer Technical infrastructure management 1 day⁄year
R.5 Support engineer Handle whois support questions 20 days⁄year
R.6 Project Lead Oversee changes 2 days⁄year
R.7 Programmer Program changes 5 days⁄year
R.8 Tester User acceptance test 2 days⁄year
R.9 Release manager Software release 1 day⁄year

The registration lifecycle for a non-reserved and available .frl domain is as follows:


Stage 0: Domain available
In this phase the domain is available for registration. The whois of the domain name shows the status ‘free’. Domain names not showing this status cannot be requested for registration via the EPP service. When a domain name is listed as ‘reserved’, the party that has a rightful claim to the domain name can contact the support department to get the domain name. The support department will use an independent party to check the rights of the registrant, and issue a unique code that the registrant can forward to its preferred registrar to register the domain name.

Stage 1a: Domain is registered but not delegated
An ICANN accredited registrar has requested this domain name for registration, and has provided adequate contact information, however has not provided nameserver (host) information. The domain name is listed in the whois as ‘inactive’, that means registered, but not delegated into the DNS.
Registration of domain names may be done for periods of 1 to 10 years. The expiration date in the whois information will show the date and time the domain name will expire or will have to be renewed.

Stage 1b: Domain is registered and delegated
When the ICANN accredited registrar provides nameserver information with the registration of a domain name, or when the registrar uses the domain-change command to alter the domain with nameserver information, the domain name will be listed as registered and active. The whois information will show the status ‘ok’ for this domain name. This status means that the domain name is active on the internet.

Stage 1c: Domain is renewed
ICANN accredited registrar will have the choice to autorenew domains, or to manually renew every domain name. After autorenew or manual renewal, the domain name has the same internal status as with stage 1a or 1b. The expiration date in the whois information will show the date and time that the domain name will be up for renewal. Renewals may be done for periods of 1 to 10 years. For any domain name that has autorenew not enabled, renewal messages will be sent via EPP or on the registry website to the registrar of record.

Stage 2a: Domain is not renewed: quarantine
The FRL registry will not make use of RGP (Registry Grace Periods). When a domain name is not renewed, and the registrar has not made use of the option for autorenew, the domain name will be cancelled and go into quarantine. This is a period of 40 days in which the original registrar of record can reclaim the domain name. The whois information will show the status ‘quarantine’ and the date and time the quarantine period ends. The domain is removed from delegation to the nameservers, so it will not resolve any more.

Stage 2b: Domain name is cancelled: quarantine
When the registrar of record decides to actively cancel the domain name, the domain name will go into quarantine before the normal expiration date. The whois information will show the status ‘quarantine’ and the date and time the quarantine period ends. The domain is removed from delegation to the nameservers, so it will not resolve any more.

Stage 3: Domain is restored from quarantine
The domain name that is restored from quarantine goes back to the active status (stage 1). The domain goes back into delegation immediately after restore. The registrar can use an EPP extension to automatically restore the domain name. The expiration date is set to the original expiration date of the domain name before it was quarantined. There is no possibility to restore a domain name for multiple years, if the registrar wants to add years after a restore he has to use the renew command after restoring the domain name.


Stage 0: Domain name is available again
After the end of the quarantine period, the domain name is released and available for registration to any ICANN-accredited registrar that has a contract with the registry.

Stage A1: The domain name is locked by the registrar
The registrar of record can choose to lock a domain name for transfers. The domain name will get the status ‘clientTransferProhibited’. The whois information will also show this status. Any domain name with this status cannot be transferred to another registrar. Any transfer request will be denied with the message ‘domain is locked for transfer’

Stage A2: The domain name is locked by the registry.
The registry can also decide to lock domain names for various reasons. The statuses the registry can impose on a domain name are: serverDeleteProhibited, serverRenewProhibited, serverTransferProhibited, serverUpdateProhibited, or a combination of these states. In these states, certain actions (delete, renew, transfer, update) cannot be performed by the registrar, until the lock has been lifted. When a lock is put on a domain name, or when it is lifted, is to be decided by the registry or its personnel. These statuses will be visible on the whois information of the domain name.

Stage B1: The domain name is transferred to another registrant
The registrar of record can decide to change the registrant information on a domain name or to specify an new registrant contact for a domain name. The validation for these actions lies with the registrar, no rules will be imposed to validate if the transfer to another registrant is properly authorized. The responsibility for performing correct transfers lies entirely by the registrar of record. The registry will accept no liability for incorrectly validated changes of registrant. There is no special status information in the whois for domains that have been transferred to another registrant. The whois will simply show the updated information.

Stage B2: The domain name is transferred to another registrar
The registry software does not support host or contact transfer commands, but it does support domain transfer commands. Each domain transfer must be submitted with valid authorization information of that domain name. The authorization code of a domain name can only be requested by the registrar of record. In special cases, when the registrar of record does not respond to authcode requests, the registry can decide to hand the authcode directly to the registrant, provided that the identity of the registrant and the claims to the domain name are validated beyond any doubt.

When a correct transfer request is submitted with correct authcode information, the domain name will be transferred immediately to the new registrar. The new and the old registrar will receive information about the transfer via EPP or via the registry website. There is no special status information in the whois for domains that have been transferred to another registrant. The whois will simply show the updated information.
Transfers not legitimate for any reason can be undone by the registry.
The registrars in question will have to send mail to the registrants and admin contacts to inform them of the transfer. Since transfers are processed immedeately, they can only be undone or cancelled by registry personnel.



SRS services

The EPP server and website of the FRL registry will work in conjunction with each other to make these stages happen. Any ICANN-accredited registrar can make a contract with the registry to register .frl domain names. After the contracts have been signed, the registrar has 2 choices to start registering domain names:
1. Via EPP: The registrar can use our RFC57xx compliant EPP service. The EPP service has 2 extensions, programmed compliant with RFC3735 (guidelines for extending the EPP protocol): One extension is available to get more information on the EPP poll command, the other extension provides quarantine undeletes.
2. Via the website of the registry. This website makes use of the EPP service for modification to EPP objects. The website is not allowed to make modifications to host, contact or domain objects directly in the database, but will always make these modifications via EPP. This way the authentication and proper handling of modifications is ensured, also if actions are done via the registry website. The website also shows the poll messages of EPP and a history of transactions for any object in the administration.
For any registrar, the client support of the FRL registry can be reached over e-mail or by telephone. Client support will also help registrants of domain names with their questions.


Resource plan for registration support
The resource indentifiers used in this document are detailed in the text of question 46

Resourcing in the initial phase
R.1 System Engineer Setup infrastructure 1 day

Resourcing in the maintaining phase
R.5 Support personnel Answer queries from registrars and registrants and solve problems 30 days⁄year

Definition of Abuse
Abuse takes on many forms for an entity trying to perform critical registry functions. The forms of abuse we recognize and will actively act against are:
- Fraud in registering domain names: people giving the wrong contact details because they want to hide their identity, or misuse the identity of someone else
- Trying to access registry services with false or stolen credentials to transfer a domain name where there is no legal right
- Trying to retrieve domain name passwords or authorization codes from the registry or associated registrars where there is no legal right to this information
- Trying to block access to registry services by DOS, DDOS, spoofing or any attack directed at the critical registry services
- Misuse of whois services to gain information about domain names, registrants, admin contacts or technical contacts for spamming or other purposes of fraud.
- Domain names with websites containing malicious content, such as fake banking websites, fake transport websites, phishing (password-stealing) websites, fake shops
- Domain names with websites containing illegal content like child porn, stolen (digital) material, false accusations, anti-socal behaviour, harassment or private information about persons.
- Viruses and worms on websites that live on .FRL domain names
- Hacking activity, either on the website or the services from the registry.
- Orphaned glue records, where domain names are deleted to hide nameserver activity
- Registrars with malicious intent
- Registrar employees with malicious intent


Not strictly abuse, but also addressed in the answer to this question:
- Information in the registry database (or whois) being incorrect because people move house, e-mail address or telephone number.
- People specifying wrong information because they have a legitimate need to hide (part of) their identity.


The FRL registry is committed to prevent abuse where possible and to solve any indication of abuse on very short notice. We are aware that phishing and spam cause many problems, and are dedicated to close down spamming and phishing sites within 24 hrs after notification.
The registry adheres to the notice and takedown procedures that are commonly practiced in The Netherlands (an also by our sister company Mijndomein), which state: Any website containing fraudulent material that is unmistakable, indisputable and clearly visible must be taken down as soon as possible. In these cases the registrant or registrar will not be heard, but they will be notified of the takedown. In other cases, where fraud is assumed but not unmistakable or indisputable we will first hear the registrant or registrar and then take appropriate action. In case the registrant cannot be reached the website may be taken down.


Abuse prevention by the registry
- Single point of abuse notification. The website of the registry will contain a contact point that is easy to find for abuse matters. The registry – registrar agreement will state that every associated registrar must register an abuse e-mail address and telephone number, and will contain an SLA for the registrar to respond to queries from the side of the registry. Every abuse case is logged into our support systems. The registry will perform monthly reporting on abuse and support cases and adapt policies where necessary.
- Address checks: Every contact created in the registry database will be checked automatically to see if the address and postal code information match. Our company already has this address checks in place, using a downloaded database from Experian QAS. Because this database resides on local disk, we are able to do address checks within milliseconds, so the impact on the EPP command time is extremely low. The Experian database is renewed every 3 months, a contract for renewal is in place. At this point in time, our company only uses Dutch and German data from Experian, but this can easily be expanded to other countries.
- Registrar checks: Every ICANN-accredited registrar that signs up for a connection will be background and credit checked. Our company already has an automated background and credit check in operation, managed by Graydon Nederland B.V. This check is performed via an internet connection to the live databases of Graydon.
- Prevention of EPP service abuse: The EPP services require strong passwords and rigid monitoring of services. The EPP server will support password change on EPP login, and passwords are checked for strength. Simple passwords will not be accepted.
Registrars connecting to the server are prompted to change their EPP passwords from time to time. This password change will not be enforced, but messages via e-mail or EPP will encourage the EPP user to change passwords on a regular basis.
The connections at the EPP server are monitored for abuse prevention and for performance logging. Every session that is created logs start and end times, and these times are reported on a daily basis. If times exceed the standard parameters as set in the server, this is reported. Whenever one of the EPP users exceeds thresholds regarding session length or numbers of EPP sessions, this is reported and the registrar in question is contacted to see what the problem might be. Sessions taking to long can be broken off, and registrars opening too much sessions can be limited or even blocked for a specific period of time.
- Prevention of wrong people accessing EPP: The epp servers checks IP addresses of connecting servers. Each registrar can associate IP addresses with the accounts they have created for the employees that can access the website or the EPP server. Address violations and login attempts are logged and reported on a daily basis.
- Prevention of abuse by internal registrar employees: Every registrar can create accounts to logon to the Registry website or to EPP. The accounts created are associated with logon profiles, for example read-only accounts can be created, or accounts that have no access to invoicing or payment functions, or accounts that can alter but not create. Registrars will be able to create separate accounts for individual employees, and track activity of their own employees on EPP and on the website of the registry.
- DNS abuse prevention: To prevent DDOS attacks to the DNS service, the registry will employ DDOS protection servers sold by an external company. DNS services will be logged and screened on a daily basis. If usage of the service exceeds usage of the previous days by a large amount, support personnel will be alerted.
- WHOIS abuse prevention: The whois services of the registry will comply to Dutch privacy laws. That means that a non-registered user can only see a limited amount of information on a registrant. Full information is only available via the website whois, or when a party is entitled to full whois information, like a registrar or another party with a legitimate right to the full whois information.
Only parties that have a legitimate need for full whois access will be screened for that need and granted access based on IP address. These connections will be monitored even more to prevent abuse. The whois server will produce daily reports on whois usage.
The whois server will monitor and log all incoming sessions based on IP address. IP addresses consuming too many sessions will be blocked for a period of time. Unblocking of IP addresses can be done by contacting the registry. Registry personnel will verify the legitimacy of the access to the WHOIS and unblock where access is really needed. If usage of the WHOIS service exceeds usage of the previous periods by a large amount, support personnel will be alerted.
- Phishing sites, virus sites or mail spamming sites: The registry will perform a daily scan of all domain names against the databases of Google or other parties that scan for viruses. For all found incidents, mail will go to the registrar to alert the registar on the scam. The Registry-registrar agreement will hold a service level and penalty for registrars not responding. Metrics will be captured about registrars having more malicious sites then others, those registrars will be addressed.
- Measures for the accuracy of domain modifications: In addition to the measures that the registrars must take (see next section) the registry will send out messages to the owner contacts of every domain name that is transferred, deleted, or where the registrant is changed. This message is only for information, no answer is required. The message will contain information on how to contact the registry when a change is unwanted.
- Orphaned glue records: We are a strong advocate for the hard line on orphaned glue records. Whenever a domain name is cancelled or reaches the quarantine period without being renewed, all DNS information related to this domain name is removed. That includes glue records from nameservers connected to the domain name.
This policy might cause websites that rely on the removed domains dns service to stop functioning. We are aware of this, and will take that risk. In the case of a normal deletion, the nameservers that once belonged to this domain name will probably not function any more, so glue records pointing to those nameservers will be pointless. In the case of a malicious deletion, we do not want them to function anyway.
For the few cases where a domain name is cancelled and the nameservers should keep on functioning, the domain name owners will have to modify the nameserver information. Since the registry will operate the DNS from the starting point on, we can impose this strict rule on orphaned glue records from the very beginning.



Abuse prevention by the associated registrars
The registry – registrar agreement will have Service Levels and penalties in place for those registrars that do not respond quickly and accurately to complaints. It will be the responsibility of the registrar to make sure that its associated resellers respond quickly and adequately to the abuse notifications.
The agreements made with the registrars will be audited on a yearly basis for compliance. The regular (daily and monthly) reporting from the services will indicate registrars that do not adhere to the agreement and they will be contacted.
- WHOIS accuracy measures: Each registrar will be hold responsible for yearly whois accuracy checks. The registrar must send out notices to the registrants of websites to notify them of the information in the whois. This measure is already in place for several gTLDs, so registrars will easily be able to comply.
- All domain transfers are token (or authcode) based. Registrars are only allowed to hand domain transfer tokens to the registrant of the website. When a domain transfer is disputed, the registry will be allowed to revert the transfer.
- Measures for accuracy of domain modifications: Every registrar will be held to notice both the domain registrant and the administrative contact for every domain transfer, change of registrant or domain deletion that takes place. The registrar must enable the registrant or the administrative contact to answer this message by clicking a link to either acknowledge or cancel a change. When either one (registrant or admin contacts) answers with a negative reply, the change is not allowed to proceed.
The registry will perform a yearly contractual compliance audit on this matter. On every major change (domain transfer, registrant change or domain deletion) the registry will send out notification to the owner. This message is only for information, no answer is required.


Policies for structural abuse
The registry-registrar contracts will hold penalties for registrars that abuse the systems.
Any registrar that is caught on abusing the registry systems will be warned formally, and the following penalties can be invoked:
- Temporary denial of whois access
- Temporary denial of EPP access ⁄ website access
- Permanent denial of whois access
- Permanent denial of EPP access ⁄ website access
- Ending the Registrar-Registry agreement


Resources: 
The resource indentifiers used in this document are detailed in the text of question 46

Resourcing for abuse prevention in the startup phase
R.1 System Engineer Setup infrastructure and DDOS appliances 2 days
R.4 Information security manager Determine abuse procedures 3 days
R.6 Project lead Abuse prevention within the software 1 day
R.7 Programmer Program abuse prevention mechanisms 1 day
R.8 Tester Test mechanisms 1 day
R.10 General manager Determine abuse procedures 1 day

Resourcing for abuse prevention in the maintaining phase
R.2 Operations engineer Infrastructure maintenance 1 day⁄year
R.4 Information security manager Yearly review of abuse prevention procedures 1 day⁄year
R.5 Support personnel: Handles abuse calls that come from outside the registry. 30 days⁄year
R.6 Project lead Oversee programming changes 1 day⁄year
R.7 Programmer Program changes 5 days⁄year
R.8 Tester User acceptance test 1 day⁄year
R.9 Release manager Release software 1 day⁄year
R.10 General manager Abuse escalation procedures 2 days⁄year


T.3 Quality assurance team Will audit the abuse prevention and mitigation procedures once a year.

Since the FRL registry is not a large registry, with probably less then 10 ICANN accredited registrars that connect, the staff to resource the abuse prevention mechanisms can be kept at a limited level. Some functions can be combined with other functions to keep staffing as optimal as possible.

The FRL registry sees the need for a swift and non-expensive solution for the protection of the legal rights of companies and individuals holding trademarks or reserved words.

The registry operator recognizes and will adhere to the following ICANN procedures:
URS: (Uniform Rapid Suspension): A cost-effective and fast procedure for suspension of domain names where the malicious intent of the registrant is clear and indisputable.
UDRP: (Uniform Dispute Resolution Procedure): An arbitration procedure where an appointed arbitrator settles the dispute and all parties (registrant and complainant) are held to the outcome.
PDDRP: (Post Delegation Dispute Resolution Procedure): A procedure between a trademark holder and the registry where the conduct of the registry operator infringes the trademarks of the complainant.
RRDRP: (Registry Restrictions Dispute Resolution Procedure): A procedure between registry and community that is targeted on community TLD’s where the conduct of the registry operator harms the community. The .FRL tld is requested as a geographic TLD, so this procedure would be not applicable in this case. However, since the Frisian people are a strong community, and the rights of this community might be harmed by the conduct of the registry operator, this procedure will also be followed when needed.

The FRL registry will hold registrars responsible as first point of action and reference in cases of domain disputes. This will be reflected in the registry-registrar agreement. It is only when the registrar does not comply it will be the task of the registry to block, cancel or delete domain names. This will only be done after an official court decision, or mediation arbitration or agreement between parties.

The following rights will be observed and protected by the registry:
The rights of trademark holders against cybersquatters that register domain names in bad faith either to capture internet traffic or sell the domain name to the rights holder.
The rights of countries, cities, communities or villages that want to register a domain name that is reserved in the registry.
The rights of individuals or companies having a legitimate right (in good faith) to register domain names that are in fact identical or similar to registered trademarks or reserved names.
The rights of the Frisian people to a top-level domain that is really theirs, and not polluted with different kinds of non-Frisian content or websites.

All mentioned parties have a right to a procedure that is fast and reliable, but not too expensive to use.

When a claim is made, the registry will have the right to disclose website ownership information to the claiming party. If and when the party wants to get into contact directly with the website owner, that is encouraged.

Because of this, the registry will implement a highly automated rights protection mechanism, that treats all complaints the same way and is as cost-effective as possible.
The procedure will use a website to capture all information that is needed by the URS, UDRP, PDDRP or RRDRP procedures, and limits the information that can be submitted to the amounts ICANN has set out in the description of these procedures.
If and when possible, the procedure will automatically check the trademark clearinghouse repository for active trademarks and attach this information to the case that is built. 


The software of the RPM website will save all e-mails and correspondence that was submitted with this the case for reference and then send the complete case to an ICANN-approved URS or UDRP provider. For the UDRP cases, we will make use of the already established WIPO arbitration. Since no URS providers are known to us at this moment, the selection of a URS provider will be done in a later state. At this point we want to urge ICANN to appoint URS providers not only in the US but also in Europe, our feeling is that a European URS provider will have more feeling and understanding for rights issues in our countries.

The cases that were saved by the RPM website will be used for reporting and prevention of future abuse. 

The registry-registrar contract will hold a clause that allows the registry to delete any domain name that violates the rights of companies or individuals. The normal flow of business is that the registrar holding the domain registration will perform any deletions or changes of ownership, but if registrars do not comply the registry will have the possibility to perform the deletion or the ownerchange without consent of the registrar. The contracts with the registrars will specify what is expected of registrars of FRL domain names.

When a registrar, registrant or trademark owner does not agree with a decision that was made by the registry, the complaint can be logged with an independent board that will register the complaint and mediate between registry and complainant.

Sunrise periods
The FRL registry recognizes the needs for two separate sunrise periods:
- One for trademark and other rights owners, combined with Frisian companies and legal institutions
- One for Frisian consumers.
After this the general availability period follows.

The registry will start with a sunrise period for trademark owners and owners of other rights. During this period, rights owners will be able to claim a domain name that corresponds with the right that is owned. An independent company will verify the claims, and when the claim is accurate, the company will use the registry website to issue an authcode that is unique to this domain name. With this code, the registrant can use any ICANN-accredited registrar to register only the domain name the code was created for. The cost of the company verifying the claims must be borne by the company requesting the trademark verification.

In combination with this sunrise period, there will be a registration period for Frisian companies and legal institutions. The FRL registry will work together with the chambers of commerce to address all the Frisian companies and send them a letter with an authcode connected to a domain name. The company in question can use the first sunrise period to register the domain name that is connected to their registered company name. This registration can be done via any ICANN-accredited registrar, provided that the authcode is supplied with the request.

The second sunrise period will be used for the Frisian consumers. They will receive an authcode that is not connected to any domain name. The consumers can register their unique domain names using these authcodes.

After this period, general registration will open, and registration will be free for anyone.


Resource planning
The resource indentifiers used in this document are detailed in the text of question 46

Resourcing for abuse prevention in the startup phase
R.1 System Engineer Setup infrastructure 2 days
R.3 Manager Infrastructure Management of personnel 1 day
R.4 Information security manager Determine abuse procedures 3 days
R.6 Project lead Software changes 1 day
R.7 Programmer Program rights protection mechanisms 1 day
R.8 Tester Test mechanisms 1 day
R.10 General manager Determine abuse procedures 1 day

Resourcing for abuse prevention in the maintaining phase
R.4 Information security manager Yearly review of rights protection procedures 1 day⁄year
R.5 Support personnel: Handles calls that come from outside the registry. 30 days⁄year
R.6 Project lead Oversee programming changes 1 day⁄year
R.7 Programmer Program changes 5 days⁄year
R.8 Tester User acceptance test 1 day⁄year
R.9 Release manager Release software 1 day⁄year
R.10 General manager RPM escalation procedures 2 days⁄year

External resources
Claims check by external company

Metaregistrarʹs Policy on Information Security ensures itʹs business continuity and minimizes the risk of damage by preventing security incidents and reducing their potential impact.
 
The Metaregistrar platform is designed and managed by a team of highly experienced engineers and is mostly based on the technology and experience from our sister company Mijndomein. The Mijndomein platform has an excellent track record for security and availability for the last 10 years, and is continiously improving their capabilities in this area.
 
The .frl gTLD does not require strict certification or industry compliance, however Metaregistrar and its subsidiaries are working hard to achieve ISO 27001 level within the next 2 years. An independent assessment report on security level and capabilities is planned within the next 8 to 12 months. As an additional service to its customers, Metaregistrar will allow high-profile clients to review the external assesment report or perform itʹs own security assessment if requested.
 
The policy uses the three main components to describe the measures: people, process and technology, a summary for each chapter is listed below:
 
People
· a description of roles and responsibilities concerning staff members and governance and resourcing of IT security
· a policy ensuring background checks, proper staff entry- and exit measures
 
Process
· a policy on regular internal and external audits, penetration testing and threat analyses
· a description of the business continuity management measures
· a description of the incident management process, ensuring a timely response, logging and analysis of incidents and 24⁄7 stand-by shifts
· a description of the change management process, ensuring proper approval, risk management and testing of changes
 
Technology
· a description of physical security measures taken to prevent unauthorised access and ensures business continuity
· a policy on logical access control and the access control list (ACL), the use of role based access control (RABC) and password policies
· a description of technical measures to ensure and monitor the availability of the platform and itʹs mission critical services, backup and restore procedures
· a policy on logging transactions and monitoring and detecting suspicious behaviour